신규 기능 개발, 기존 기능 개선, 품질 보증, 기술 부채 상환, 고객 문의 대응──
개발 조직이 다뤄야 할 이니셔티브는 해마다 다양해지고 있으며, 한정된 리소스 안에서 “어디에 얼마나 투자해야 하는가”를 판단하기는 그 어느 때보다 어려워졌습니다. 프로덕트의 성장 단계에 따라 최적의 투자 배분은 달라지지만, 바쁜 일상 업무 속에서 이를 체계적으로 정리해 파악하기란 결코 쉽지 않습니다.
AI의 발전으로 코드 생성과 조사 업무의 자동화가 빠르게 진행되면서, “만드는” 과정 자체의 효율성은 크게 향상되었습니다. 그 결과 개발팀이 만들어낼 수 있는 산출물의 양과 속도는 분명히 높아지고 있습니다. 하지만 구현이 빨라질수록, “이 개발 투자가 사업의 어떤 성과로 이어지는가?”, “왜 지금 이 작업에 리소스를 투입하고 있는가?”라는 질문에 명확히 답해야 할 필요성 역시 커지고 있습니다.
이러한 상황 속에서 ㈜스페이스마켓은 Findy Team+의 ‘프로젝트 투자 분석’ 기능과 Jira를 연동하여, 개발 투자 구조를 가시화하는 작업에 착수했습니다. 이미 딜리버리(개발 생산성) 지표 개선을 일정 수준 이상 달성한 이 회사는, 이제 “다음 단계”로서 개발 이니셔티브와 사업의 KGI·KPI를 어떻게 연결하고, 전략에 기반한 리소스 배분과 의사결정으로 이어갈지 재정비하는 단계에 들어섰습니다.
본 기사에서는 스페이스마켓이 어떤 문제의식을 바탕으로 개발 투자 비율의 가시화에 나섰는지, 그리고 Jira 운영 프로세스를 어떻게 재설계했는지 살펴봅니다. 그 과정에서 얻은 인사이트와 의사결정 방식의 변화도 함께 짚어봅니다.
나리하라 소이치로(成原聡一郎)
엔지니어링 매니저 1988년 삿포로 출생. 23세에 웹의 세계에 매료되어 독학으로 디자인 등을 공부하며 웹 디자이너로 커리어를 시작. 수탁 제작 회사에서 수년간 경험을 쌓은 뒤, 웹 분야에서 JavaScript가 가진 가능성에 매료되어 프론트엔드 엔지니어로 전향. 스페이스마켓 입사 후 엔지니어링 영역에서의 매니지먼트가 가진 재미와 깊이를 깨닫고 엔지니어링 매니저로 활동 중.
나리하라: 개발팀으로서 매일 다양한 이니셔티브에 대응해 왔지만, 정작 그 투자가 어디로 얼마나 향하고 있는지 제대로 파악하지 못하고 있다는 점이 고민이었습니다. 적절하게 인원을 배치하고 있는지도 불투명했고, 판단의 기준이 될 데이터조차 갖춰져 있지 않았던 것 같습니다.
단발성(Ad-hoc) 대응이나 KPI에 직접 연결되지 않는 작업도 일정 비율 존재했습니다. 그 작업 자체가 잘못된 것은 아니지만, 전체에서 어느 정도 비중을 차지하는지, 사업적으로 어떤 위치에 있는지를 설명하려고 하면 결국 감에 의존한 이야기로 흐를 수밖에 없었습니다.
딜리버리 관점에서는 그동안 꾸준히 개선을 이뤄왔다는 실감이 있습니다. 풀 리퀘스트(이하 PR) 리드타임이나 배포 빈도 같은 이른바 실행 지표(Leading Indicators)들에 대해서는 이미 일정 수준 이상 궤도에 올려놓은 상태였습니다. 거기서 한 단계 더 나아가 “왜 이 기능을 만들고 있는가?”, “이 투자가 사업의 어느 부분에 기여하는가?”라는 한 레벨 높은 시각에서 논의할 수 있는 환경을 만들고 싶었습니다. 그러려면 먼저 우리가 지금 어디에 투자하고 있는지 구조적으로 파악해야 했습니다.
KPI 진행 상황 역시 수치로는 확인하고 있었지만, 그 숫자가 어느 정도의 개발 투자를 통해 만들어진 것인지까지는 보이지 않았습니다. 결과적으로 선택과 집중을 하고 싶어도 판단 근거가 부족한 상황이었다고 생각합니다.
나리하라: 이전부터 Jira에서 라벨을 사용하긴 했지만, 체계적으로 관리되지 않아 과거에 쓰던 라벨이 방치되어 있었습니다. 결국 무슨 용도의 라벨인지조차 알 수 없는 상태가 되어 있었죠. 분류 기준으로서 제 역할을 못 하는 라벨이 늘어나면서, 투자 관점에서 활용하려고 하면 오히려 혼란만 더해지는 상황이었다고 생각합니다.
한때는 차라리 라벨 운영 자체를 중단하는 편이 낫지 않겠느냐는 이야기가 나올 정도였습니다. 그러한 상황에서 Findy Team+의 프로젝트 투자 분석 기능을 접했고, 기존 Jira 데이터를 활용하면서도 투자 구조를 정리할 수 있겠다는 확신이 들었습니다. 라벨을 정비해 투자 배분을 가시화할 수 있다는 점이 매우 매력적이었습니다.
또한 경영진이나 프로덕트 조직과 소통할 때 수치에 기반해 논의할 수 있다는 점도 중요했습니다. 이전에는 “대략 이 부분에 공수를 들위고 있다”는 식의 설명에 그치기 일쑤였지만, 투자 카테고리별로 정돈된 데이터가 있다면 논의의 기준점을 맞추기가 훨씬 수월해질 것이라 느꼈습니다.
나리하라: 스페이스마켓은 대규모 스크럼(LeSS, Large Scale Scrum) 방식으로 개발을 진행하고 있습니다. 성장을 담당하는 Growth Unit과 품질을 담당하는 Trust Unit이 있으며, 각 Unit 아래 여러 팀이 속해 있습니다. 백로그는 Unit별로 나뉘어 있고, 같은 Unit 내 팀들이 프로덕트 백로그 아이템(이하 PBI)을 공유합니다. PBI는 “이 단위로 사용자에게 유의미한 가치를 전달할 수 있는가”를 최우선으로 고려해 정의하고 있습니다.
과제 아이디어는 먼저 기획서 형태로 정리하고, 기획·개발 회의에서 추진 여부를 결정합니다. 진행이 확정되면 기획 내용을 바탕으로 PO가 이를 에픽(EPIC) 또는 PBI로 전환합니다. 이후 엔지니어까지 참여해 어떻게 분할할지, 어느 팀이 담당할지를 논의합니다. 에픽은 PBI 단위로 쪼개고 스토리 포인트를 부여한 뒤 리파인먼트(Refinement)를 진행합니다. 그 과정에서 요구사항을 구체화하고 수용 조건(Acceptance Criteria)을 명시합니다.
합의가 이루어진 항목은 서브태스크로 세분화하여 개발을 진행하는 흐름입니다. 실제 작업 관리는 서브태스크 중심으로 이루어지며, 서브태스크가 완료됨에 따라 최종적으로 PBI와 에픽이 클로즈됩니다. 개발 프로세스 자체는 비교적 잘 정돈되어 있었고, 일상적인 운영에서 큰 어려움을 느끼지는 않았습니다.
한편, 가시화 관점에서는 과제가 있었습니다. 리파인먼트부터 플래닝에 이르는 과정에서 요구사항 정의와 설계를 오가는 일이 일상화되어 있었고, Jira의 상태 변경(Status transition)만 봐서는 어디서 시간이 지연되는지 직관적으로 파악하기 어려운 상태였습니다. 따라서 프로젝트 투자 분석 기능을 활용하기 위해서는, 먼저 이 Jira 운영 방식, 특히 라벨을 다루는 방식부터 재정비할 필요가 있다고 느끼고 있었습니다.
나리하라: 실제로 Findy Team+에서 가시화를 추진하면서, 라벨을 한 번 전수 점검하고 정리했습니다. 다행히 최근에는 라벨을 거의 활용하지 못하고 있었기 때문에, 과거 운영 방식에 얽매이지 않고 제로부터 새롭게 설계할 수 있었다고 생각합니다.
라벨 부여 방식의 경우, 에픽이 생성되는 시점에 해당 투자 카테고리 라벨이 자동으로 부여되도록 Jira 오토메이션을 설정했습니다. 또한 에픽 하위 이슈(유저 스토리 및 일부 태스크)에도 에픽과 동일한 라벨이 자동으로 상속되도록 했습니다. 이를 통해 에픽 계층 전체에서 투자 카테고리가 일관되게 정렬되도록 만들었습니다.
다만 운영 부담은 크지 않습니다. 주 1회, 약 15분 정도 라벨 부여 상태를 점검하는 수준으로 지속하고 있으며, 구성원들에게 새로운 작업을 강하게 요구하는 일도 없습니다.
투자 카테고리를 어떻게 판단할지에 대해서는, 기획서에 명시된 목적과 목표를 기준으로 삼고 있습니다. 대부분의 이니셔티브는 신규 기능 개발이거나 기존 기능 개선 둘 중 하나로 분류할 수 있기 때문에, 개인의 감각에 따라 판단이 크게 달라지는 경우는 많지 않습니다.
품질 보증이나 시스템 신뢰성과 관련된 과제는 트러스트 팀이 중심이 되어 대응하고 있습니다. 문의 대응이나 페이지 속도 개선처럼 에픽이 아닌 태스크 단위에서 시작되는 작업도 많아, 이 부분은 아직 라벨 운영을 본격적으로 체계화하지 못한 영역입니다.
앞으로 어떻게 구조화할지에 대해서는 추가 검토가 필요하다고 느끼고 있습니다. 전반적으로는 Jira 운영을 크게 변경하지 않으면서도, 최소한의 조정으로 투자 분석에 연결할 수 있었다는 감각을 가지고 있습니다.
나리하라: 실제로 프로젝트 투자 분석 기능을 사용하기 시작하면서 가장 먼저 느낀 점은 “생각했던 것보다 보이지 않던 부분이 훨씬 많았다”는 것이었습니다. 그동안 사업의 KGI와 KPI를 의식하며 개발하고 있다고 생각했지만, 이를 투자 배분의 관점에서 정리해보니 반드시 그에 충분히 몰입하고 있다고는 할 수 없는 경우가 있다는 것을 알게 되었습니다. 에픽 단위로 보았을 때, 애초에 KPI와 직접적으로 연결되지 않은 에픽이 섞여 있다는 점도 깨달았습니다.
신규 기능, 기존 기능 개선, 품질 보증과 같은 투자 카테고리별로 살펴보면서 “어느 영역에 얼마나 리소스를 쓰고 있는지”를 처음으로 한눈에 파악할 수 있게 되었습니다. 예를 들어 신규 기능에 대한 투자 비율은 높은 반면, 품질 보증은 별도의 팀이 담당하고 있는 영향으로 수치상으로는 낮게 보이는 구조라는 점도 분명해졌습니다.
이러한 결과는 팀 전체와도 공유하고 있습니다. Growth Unit 전체 회고 자리에서 수치를 공유하거나, 스프린트 단위 회고에서 “이 기간의 투자 비율은 어땠는가”를 논의하고 있습니다.
가시화된 수치가 존재함으로써 “선택과 집중이 실제로 이루어지고 있는가”, “현재의 투자 밸런스가 적절한가”와 같은 논의를 감각이 아닌 사실에 기반해 진행할 수 있게 되었습니다. 아직 개선 과정에 있지만, 논의의 전제가 정렬되었다는 점 자체가 큰 진전이라고 느끼고 있습니다.
나리하라: 앞으로는 이 투자 분석 결과를 단순히 “회고를 위한 데이터”로 남겨두지 않고, 실제 의사결정에 활용하고자 합니다. 특히 우리가 일상적으로 수행하는 태스크와 사업의 KGI·KPI를 어떻게 연결할 것인가가 핵심입니다.
눈앞의 태스크에 몰두하다 보면, 그 작업이 사업의 어디에 기여하고 있는지를 놓치기 쉽습니다. 투자 카테고리로 정리된 데이터가 있다면 “이 기간에는 어떤 영역에 집중했는가”, “그 방향이 현재 사업 단계와 부합했는가”를 되돌아볼 수 있습니다. 이러한 회고를 통해 다음에 어디에 투자할지 더욱 의식적으로 결정하고자 합니다.
이번 분석을 통해 실감한 점은, 우리가 가지고 있던 정성적 감각과 실제 측정된 수치 사이에 생각보다 큰 차이가 존재한다는 것이었습니다. 체감상으로는 적절하다고 여겼던 투자 배분도, 수치로 보면 20~30%가량 차이가 나는 경우가 결코 드물지 않았습니다. 이러한 편차를 정확히 인식하고 관리함으로써, 조직 차원에서 더 나은 리소스 배분이 가능해질 것입니다.
또한 조직 체계나 채용 등 리소스 배치 관점에서도 활용할 수 있다고 느끼고 있습니다. 투자 배분과 사업의 현황을 함께 바라보면 “인력을 늘려야 하는가”, “방식을 바꿔야 하는가”와 같은 판단을 감각이 아닌 데이터 기반으로 논의할 수 있게 됩니다. 경영진과의 커뮤니케이션 측면에서도 이 가시화는 큰 의미를 갖습니다. 그동안 인건비를 포함한 투자 논의는 추상적으로 흐르기 쉬웠지만, 실제 투자 배분을 제시하며 설명할 수 있다면 사업 측이 생각하는 예산 규모와의 정렬도 한층 수월해질 것이라 생각합니다.
나리하라: 우리 엔지니어의 존재 의의는 “프로덕트를 통해 사용자에게 가치를 제공하는 것”입니다. 그러나 ‘가치 제공’이라는 말은 매우 추상적입니다. 그래서 주어진 과제를 고민 없이 받아들이는 것이 아니라, Why·What부터 스스로 해석하고, 엔지니어링을 통해 가치를 빠르게 실현할 수 있는 조직을 만들어가고자 합니다.
자신의 일에 자부심을 가지면서도, 사용자 가치 제공을 최우선으로 생각하고 행동할 수 있는 분. 그리고 개인에 머무르지 않고 팀으로서 더 큰 미래를 그리는 데 동기를 느끼는 분. 과제의 Why·What을 스스로 고민하고, 사용자에게 가치를 전달하는 다이내믹한 환경에 관심이 있는 분이라면 최고의 환경이 될 것입니다!