소규모 개발 조직의 리드타임을 3분의 1로 줄이는 방법: 정직원 2명 스타트업 mento는 어떻게 Four Keys를 개선하고 독목 현상을 해결했는가?

퍼스널 코칭 서비스 'mento(メント)'를 개발·운영하는 주식회사 mento에서는 엔지니어 조직의 개인 회고와 조직 과제 발굴에 엔지니어 조직 생산성 향상 플랫폼 'Findy Team+'를 활용하고 있습니다.

이번에는 mento의 CTO인 마츠야마 님, 엔지니어 요시타니 님과의 인터뷰를 진행했습니다. 'Findy Team+' 도입 전 가졌던 조직의 과제와 도입 후의 노력, 개발 생산성 측정의 이점을 어떻게 느끼고 있는지 들어봅니다.

리뷰 정체로 인한 정체감과 결과 지표의 부재가 과제

—— 먼저 두 분의 주요 경력과 현재 담당 업무에 대해 말씀해 주세요.

마츠야마: 2014년 신입으로 주식회사 리크루트에 입사해 줄곧 소프트웨어 엔지니어로 일했습니다. 2019년 11월 mento에 입사해 CTO를 맡고 있습니다. 역할상으로는 경영과 엔지니어링 매니지먼트를 담당하지만, 팀 규모가 작아 코드도 직접 작성하고 있습니다.

비율로 따지면 경영 20%, 매니지먼트 40% 정도이며, 남은 40%는 코드를 작성하는 이미지입니다. 이 외에 사내 코퍼레이트 엔지니어링 분야도 함께 총괄하고 있습니다.

요시타니: 2017년 신입으로 주식회사 FiNC Technologies에 입사했고, 3년 전 mento로 이직했습니다. 엔지니어로서 스크럼 팀 내에서 코드를 작성하는 한편, 팀이 더욱 생산적으로 일할 수 있도록 프로세스를 개선하는 역할을 주로 맡고 있습니다.

—— 개발 조직의 규모와 체계, 그리고 지향하는 미션에 대해 말씀해 주실 수 있나요?

마츠야마: 전사 조직 규모는 현재 정직원 17명입니다. 시리즈 B 투자 유치를 준비하는 단계로, 투자 라운드로 보면 시리즈 A에 해당하는 아리 스테이지 스타트업입니다.

개발 조직 체계는 소규모로, 정직원은 저와 요시타니 2명뿐입니다. 프로덕트 팀 관원에서는 외주/외주 파트너 여러분의 도움을 받고 있으며, 디자이너, PdM, 데이터 사이언티스트가 포함된 스크럼 팀 전체 인원은 7명 정도입니다.

개발 조직의 미션은 'Findy Team+'를 활용해 개발 리드타임을 추적 관리하는 것, 그리고 채용입니다. 조직 차원에서 최종 입사 승낙 수를 채용 KPI로 관리하고 있어, 현재는 이 두 가지를 조직의 핵심 미션으로 두고 있습니다.

—— 'Findy Team+'를 도입하기 전에는 어떤 과제가 있었나요?

요시타니: 몇 가지가 있었는데, 첫 번째는 팀 구조에 관한 과제였습니다. 원래는 소규모 팀 안에 엔지니어, 프로덕트 매니저, 비즈니스 담당자가 함께 섞여 있는 구조였습니다.

당시 엔지니어의 역량이 제대로 발휘되지 못하는 과제 패턴이 있었고, 이로 인해 부담감을 느끼는 팀원도 있었습니다. 이에 따라 엔지니어링에 온전히 집중할 수 있도록 엔지니어 전담 팀을 별도로 분리하기로 결정했습니다.

또 다른 과제는 코드 리뷰의 정체였습니다. 리뷰를 담당하는 인원이 특정인에게 편중되어 있었고, 외주 파트너의 Pull Request(PR)는 구조상 리드타임이 길어지는 등 여러 원인이 복합적으로 작용해 리뷰가 쌓이고 있었습니다. 이 때문에 막연한 정체감이나 일이 제대로 돌아가지 않는다는 느낌을 받았습니다.

마츠야마: 리뷰 과제와 관련해 덧붙이자면, 정량적인 결과 지표가 없었습니다. 리뷰가 지연됨으로써 우리 팀의 어떤 부분이 구체적으로 안 좋은 상태인지 파악하기 어려웠습니다. 무언가 찜찜한 느낌은 있지만, 어디에 어떤 병목이 발생하는지 공통의 인식대를 형성하지 못했던 것이 가장 큰 과제 중 하나였습니다.

—— 'Findy Team+'를 도입하게 된 배경이나 계기는 무엇이었나요?

마츠야마: 조직 개편 논의가 시작되면서 엔지니어 팀을 분리할 때 엔지니어 팀의 KR(Key Results)을 어떻게 설정할지 고민했습니다. 산출물(Output)에만 편중되어 고객 가치로 이어지지 않는 프로덕트를 만드는 팀이 되지 않도록 성과(Outcome) 목표를 두고 싶었습니다. 하지만 막 분리된 팀이 곧바로 성과 지표까지 추적하려고 하면 실행력이 떨어질 수 있었습니다.

따라서 우선은 산출물 지표부터 설정하기로 하고, 글로벌 스탠다드 지표인 Four Keys를 기준으로 삼고자 했습니다. 다만 Four Keys를 자체적으로 시각화하는 것은 공수가 많이 드는 작업이라 대안을 찾던 중 'Findy Team+'를 알게 되었습니다. 이후 관련 행사 부스에서 실제 'Findy Team+' 데모를 확인한 뒤 바로 다음 날 도입을 문의했습니다.

정의를 두고 논쟁하는 시간을 줄일 수 있다는 점이 장점

—— 'Findy Team+'를 도입하기 전에는 개발 생산성 측정 관련 시도가 있었나요?

마츠야마: 전혀 없었습니다. 기본적으로 "이 정도 분량은 이 정도 기간 내에 만들면 좋겠다"라는 식의 막연한 합의 아래 스크럼 이터레이션을 진행했습니다. 회고에서 "좀 더 잘할 수 있었을 텐데" 같은 이야기는 나왔지만, 회고 주기 자체가 길었고 실질적인 개선으로 이어지지 않았습니다.

—— 'Findy Team+' 도입 과정에서 사내 설득이나 공감대는 어떻게 형성하셨나요?

마츠야마: 도입 결정 권한이 저에게 있었기 때문에 대표를 별도로 설득해야 하는 과정은 없었습니다. 하지만 Four Keys 측정 프로그램을 직접 개발하는 선택지 대신 'Findy Team+'를 도입한 데에는 분명한 이유가 있습니다.

KR을 설정할 때 각 지표의 세부 정의를 두고 논의가 길어지는 경우가 많습니다. 예를 들어 Four Keys에서 '변경 사항의 리드타임'을 어디서부터 어디까지로 정의할 것인가 같은 문제죠. 하지만 이러한 정의를 논의하는 시간 자체는 아무런 가치를 창출하지 못하므로 비효율적이라고 생각했습니다. 정의가 무엇이든 일단 기준을 빠르게 확정한 뒤 실제 코드를 작성하는 것이 중요합니다.

'Findy Team+'의 경우 "이 항목은 이렇게 측정합니다"라는 표준 정의가 이미 세팅되어 있습니다. 따라서 해당 기준을 그대로 수용하고, 그 수치를 개선하는 데 집중하고자 했습니다. 개선 활동을 진행하면서 지표가 당사 상황과 맞지 않거나, 우리 프로세스상 정의를 변경할 필요가 생기면 그때 가서 수정하면 된다고 판단했습니다.

지표 정의에 소모되는 시간을 아낄 수 있다는 점이 'Findy Team+'의 큰 장점이었습니다. 사내에도 표준 지표에 맞춰 진행할 것임을 공유했고, 덕분에 원활하게 도입을 추진할 수 있었습니다.

—— 도입 후 개선을 추진하는 과정에서 어려웠던 점은 없었나요?

요시타니: 'Findy Team+'에서 제공하는 지표가 다양하다 보니, 어떤 지표를 어떻게 해석하고 대처해야 할지 판단하기 어려웠습니다. 그러던 중 CS(Customer Success) 담당자와의 미팅에서 "우선 리드타임부터 단계를 밟아 살펴봅시다"라는 가이드를 받았고, 덕분에 해당 지표에 집중할 수 있었습니다.

특히 리드타임 중에서도 '리뷰 요청부터 승인(Approve)까지', '승인부터 머지(Merge)까지'의 구간을 개선해 나가는 방향성을 잡은 것이 큰 도움이 되었습니다. 목표가 명확해지자 이후 개선 작업은 속도감 있게 진행되었습니다.

다만, 아직 모든 팀원이 'Findy Team+'를 주도적으로 확인하는 단계까지는 이르지 못해, 현재는 저와 마츠야마 님이 지표를 모니터링하고 팀에 공유하는 방식으로 운영 중입니다. 'Findy Team+'는 데이터 시각화가 잘 되어 있고 깊이 있게 분석할 수 있는 자료가 풍부한 만큼, 앞으로 팀 차원에서 더욱 적극적으로 활용해 나갈 계획입니다.

주 2회 리뷰회를 개최해 구성원 전체의 리뷰 우선순위 제고

—— 코드 리뷰 지연 과제는 어떻게 개선해 나갔나요?

요시타니: 리뷰 작업이 저에게 과도하게 집중되어 있던 점이 주요 원인이었기 때문에, 모든 엔지니어가 리뷰에 참여하고 리뷰 작업의 우선순위를 높이기로 팀 내 합의를 이뤘습니다. 구체적으로는 화요일과 목요일에 각각 1시간씩 '리뷰회' 시간을 고정으로 배정하여 엔지니어 전원이 함께 리뷰를 진행하고 있습니다.

리뷰 요청이 들어오는 즉시 처리하는 것이 이상적이지만, 컨텍스트 스위칭(Context Switching)에 따른 비용이 발생합니다. 따라서 전용 리뷰 타임을 지정해 쌓여 있는 리뷰를 집중적으로 소화하는 구조를 정착시켰습니다.

—— 리뷰회를 별도로 신설하는 것에 대해 팀 내 우려나 부정적인 반응은 없었나요?

요시타니: 리뷰회를 도입하기 전을 돌아보면, '코딩이 아닌 리뷰에 별도의 시간을 정기적으로 할애해도 되는가'에 대한 불확실성이 있었습니다. 직접 코드를 작성하는 것이 더 생산적인 행위처럼 느껴지다 보니, 리뷰 시간에 투입하는 공수 대비 효과를 직관적으로 체감하기 어려웠던 것 같습니다.

마츠야마: 개발 효율에 대한 막연한 불안감이 존재하는 것이죠. 이는 효율성을 바라보는 관점의 차이에서 비롯됩니다. 많은 이들이 모든 엔지니어가 100% 가동률로 코드를 작성하는 상태를 가장 효율적인 상태라고 오해하곤 합니다.

엔지니어를 단순한 자원(Resource) 관점에서 볼 때는 그것이 최적화처럼 보일 수 있지만, 최종 프로덕트를 시장에 배포(Delivery)하는 관점에서는 다릅니다. 모두가 코드 작성에만 매달리면 리뷰 단계에서 병목이 발생해 결과적으로 전체 배포 효율은 저하됩니다.

개개인의 작업 효율이 다소 떨어지더라도, 리뷰와 QA를 신속하게 진행하는 편이 제품이 실제로 출시되는 속도를 높입니다. 이러한 논리를 이론적으로는 이해하더라도, 실제 현장에 적용할 때는 확신을 갖기 어렵습니다. 하지만 정량적 결과 지표가 시각화되어 있으면, 현재 추진하는 개선 활동이 올바른 방향임을 데이터로 검증할 수 있어 팀의 추진력과 확신으로 이어집니다.

요시타니: 덧붙이자면, 리소스 효율이 100%에 도달하지 않는 상황에 대한 심리적 부담은 여전히 존재합니다. 예를 들어 4명의 엔지니어가 참여하는 1시간의 리뷰회에서 제가 리뷰 물량을 3명에게 분배할 때가 있습니다.

이때 작업 전달이 매끄럽지 않으면, 프론트엔드 엔지니어의 경우 당장 리뷰할 대상은 없지만 10분 뒤에 동작 확인 단계로 넘어가는 식의 대기 시간이 발생합니다. 이로 인해 10분 정도의 공백이 생기게 됩니다.

이처럼 프로세스가 멈추는 시간이 발생하는 것에 대한 경계심이 있습니다. 향후 조직 규모가 10명 이상으로 확대되면 이러한 대기 시간이 더욱 늘어날 수 있습니다. 따라서 이러한 구조적 한계를 인식하면서, 대기 시간 동안 다른 업무를 병행하는 식의 유연한 운영 방식을 모색하고 있습니다.

향후 과제는 배포 효율 개선 및 배포 품질 측정

—— 개발 생산성을 정량 측정하면서 느낀 가장 큰 이점은 무엇인가요?

요시타니: 목표를 명확한 수치로 설정할 수 있고, 실행 결과에 따른 개선 추이를 데이터로 확인할 수 있다는 점입니다. 도입 첫 달에는 기존에 누적되어 있던 PR을 소화하는 기간이었기에 수치상 큰 변화가 없었지만, 이에 대해 팀 내 공감대가 형성되어 있었습니다. 지연된 PR이 모두 처리된 이후부터는 수치가 가파르게 개선되었고, 이 과정이 시각적으로 증명되어 유용했습니다.

실제로 도입 초기인 2023년 11월 기준 94.8시간이었던 전체 사이클 타임(Cycle Time)은 2024년 4월 기준 26.1시간으로 줄어들어, 약 3분의 1 이하 수준으로 대폭 개선되었습니다.

—— 팀원들의 인식이나 작업 방식에서 나타난 변화가 있나요?

요시타니: 엔지니어 사이에서 리뷰 작업을 최우선으로 처리해야 한다는 인식이 확실히 정착되었습니다. 최근에는 OKR 설정 시 PR 리드타임 대신 Jira 티켓의 리드타임을 지표로 활용하고 있습니다. 이에 따라 엔지니어뿐만 아니라 프로덕트 매니저 등 전체 구성원이 작업의 지연을 방지하고 빠른 완료(DONE)를 지향하는 문화가 형성되었습니다.

또한, 태스크를 작고 세부적인 단위로 분할하여 관리하는 습관이 정착된 것도 주요 변화 중 하나입니다. 작업 단위를 작게 나누어 자주 리리스하는 방식의 중요성을 팀 전체가 공감하고 있습니다.

사용자 영향도를 최소화하는 다크 론치(Dark Launch) 방식을 활용해 정기적으로 배포를 진행함으로써 배포 주기(Release Frequency)가 단축되었고, 단일 PR의 규모도 슬림해졌습니다. 'Findy Team+' 데이터상으로도 코드 변경 줄 수(Lines of Code)가 지속적으로 감소하고 있으며, 이로 인해 리뷰에 소요되는 시간 역시 줄어드는 선순환이 이루어지고 있습니다.

—— PR 단위를 작게 유지하는 문화는 인위적인 독려 없이 자연스럽게 정착된 건가요?

요시타니: 그렇습니다. 자연스럽게 문화로 자리 잡았습니다. 리뷰 주기가 길어지면 PR에 지속적으로 변경 사항이 누적되어 단위가 커질 수밖에 없습니다. 하지만 주 2회 고정 리뷰회를 운영하고 사전에 상시 리뷰가 이루어지면서, PR이 과도하게 커지는 현상이 자연스럽게 방지되었습니다.

—— 개발 생산성 측정과 관련하여 향후 시도하고자 하는 과제는 무엇인가요?

요시타니: 현재는 정직원 2명, 외주 파트너 4명 규모로 리뷰회를 운영하고 있습니다. 향후 엔지니어가 10명, 20명으로 늘어나더라도 이러한 모범 사례가 조직 문화로 지속되기를 바랍니다.

마츠야마: 배포 효율은 조직의 건강 상태를 나타내는 '건강 지표'라고 생각합니다. 일정 기준치에 도달하면 그 이상의 극단적인 단축을 목표로 삼는 것은 실익이 적습니다. 예컨대 "PR당 변경 줄 수를 무조건 5줄 이내로 제한하자" 같은 목표는 현실적이지 않기 때문입니다.

따라서 적정 수준을 달성한 후에는 이를 건강 지표로 설정하고, 조직 컨디션이 저하되었을 때 이를 정상화하는 회귀력으로 작동하도록 만드는 것이 핵심입니다. 현재는 적정 기준을 확립해 나가는 단계이며, 향후에는 이를 기준점으로 삼아 정기적으로 모니터링하고 유지하는 데 집중할 계획입니다.

또 다른 과제로, Four Keys의 핵심 축 중 하나인 '배포 품질' 영역을 아직 충분히 측정하지 못하고 있습니다. 최근 에러율 관련 이슈가 제기되었으나, 현재 핫픽스(Hotfix) 운영 체계가 미비하거나 서비스 운영에 영향을 주지 않는 운영 장애 등이 존재하여 'Findy Team+' 상에서 변경 실패율(Change Failure Rate)이 정확히 집계되지 않는 상태입니다.

향후 이러한 품질 지표 역시 플랫폼 내에서 체계적으로 관리하고 조직의 핵심 목표로 추적해 나갈 계획이며, 이는 명확한 다음 단계의 로드맵입니다.

—— 마지막으로 mento 개발 조직만의 강점이나 아필 포인트를 말씀해 주세요.

요시타니: 가장 큰 강점은 프로세스 개선 활동을 긍정적이고 유연하게 수용하는 팀 분위기입니다. 모든 구성원이 프로덕트와 서비스가 제공하는 고객 가치에 집중하고 있으며, 이를 위한 조직 차원의 개선 노력을 적극적으로 지지합니다.

마츠야마: 수평적이고 기민한 조직 구조 역시 강력한 장점입니다. 엔지니어링 팀 분리나 산출물 중심의 KR 설정 등 주요 의사결정을 독단적으로 진행하지 않고, 구성원 간의 충분한 논의와 피드백을 거쳐 요시타니 님과 함께 결정해 왔습니다.

단순한 엔지니어링 영역에 국한되지 않고, 조직 전체의 목표 수립이나 채용 전략에 이르기까지 개인이 원한다면 광범위한 영역에 주도적으로 기여할 수 있는 환경이 갖춰져 있습니다. 성장 단계의 소규모 조직인 만큼, 엔지니어라는 직무의 틀에 자신을 가두지 않고 다방면에서 영향력을 발휘하고자 하는 분들에게 매우 흥미롭고 역동적인 환경을 제공합니다.

—— 마츠야마 님, 요시타니 님, 소중한 말씀 감사합니다!