속도와 품질 두 마리 토끼를 잡은 개발팀의 비결

이 기사 요약

도입 전: 해결하고자 했던 과제

개발 생산성의 가시화가 부족하여 개선 포인트의 특정과 신속한 가치 제공이 과제였음

Findy Team+를 도입한 이유

Four Keys를 포함한 개발 데이터를 시각화함으로써 과제 식별과 개선 사이클을 가속화할 수 있다고 판단했기 때문임

도입을 결정한 계기

‘Four Keys’, ‘SPACE’ 등의 지표를 손쉽게 시각화할 수 있고, 사업과 연계된 지속적인 개선에 활용할 수 있다고 판단했기 때문임

도입 후: 성과

KPT와 설문을 통해 과제를 ‘자기 일’로 인식하는 문화가 정착되었고 주체적인 개선이 추진되면서 배포 빈도가 약 2배 향상되었음

KPT와 설문을 통해 ‘자기 업무화’를 촉진. 배포 빈도 2배를 실현한 ONE CAREER의 개발 생산성 향상 전략은?

IT×HR 영역에서 서비스를 전개하는 주식회사 원캐리어(ONE CAREER). 동사는 급속한 사업 성장에 따라 개발 조직의 확장과 생산성 향상에 힘쓰고 있습니다. 이번에는 Findy Team+를 활용한 개발 생산성의 가시화와 조직 개선에 대해 CTO 이와모토(Iwamoto)님과 시니어 엔지니어링 매니저 야마구치(Yamaguchi)님에게 이야기를 들었습니다.

─ 귀사에 대해 소개해 주세요.

Iwamoto：저희는 ‘사람 수만큼 커리어를 만든다’는 미션을 내걸고, 커리어와 관련된 정보를 올바르고 폭넓게 전달하기 위한 플랫폼을 제공하고 있습니다. 현재 개발 조직은 정규직이 약 30명, 외주 및 장기 인턴을 포함하면 약 50명 규모입니다. 개발은 3개의 그룹으로 나뉘어 있으며, 프로덕트 개발부터 인프라 정비까지 폭넓은 업무를 담당하고 있습니다.

─ 개발 조직에서는 어떤 미션을 내세우고 있나요?

Yamaguchi：저희는 ‘소프트웨어는 자산이다’라는 생각을 바탕으로, ‘자산이 되는 소프트웨어를 개발한다’는 점을 중시하고 있습니다. 한 번 개발한 소프트웨어가 지속적으로 수익을 창출할 수 있도록 품질과 확장성을 특히 중요하게 생각하고 있습니다.

좋은 개발자 경험을 좋은 성과로 연결하기 위해... 프로세스 개선을 위한 첫걸음

─ 개발 생산성 측정을 시작하고 툴 도입을 검토하게 된 계기는 무엇이었나요?

Yamaguchi：“좋은 것을 만드는 것”뿐만 아니라, “어떻게 만들고 있는가”를 파악하고 지속적으로 개선해 나가는 것의 필요성을 느낀 것이 계기였습니다. 특히 개발 프로세스에서 병목 현상이나 비효율적인 부분을 정량적으로 파악하지 못하고 있었던 것이 과제였습니다. 2021년 9월부터 개발 생산성 측정을 시작했고 리드 타임이나 PR 작성 수 등을 포함한 데이터를 시각화하기 위해 Findy Team+ 도입을 결정했습니다. 이를 통해 엔지니어 스스로가 개선 의식을 갖고, 사업 성장까지 의식한 행동을 유도할 수 있는 구조를 만들 수 있다고 생각했습니다.

── Findy Team+를 도입한 이유는 무엇인가요?

Yamaguchi：“지금 어디가 지연되고 있는가?”, “어떤 프로세스에 문제가 있는가?”를 정량적으로 파악하고 싶었던 것이 도입의 계기였습니다. 물론 GitHub이나 자체 스프레드시트를 통해 어느 정도 경향은 볼 수 있었지만, 작업이 사람에게 의존되고 수작업의 부담이 크다는 것이 문제였습니다. Findy Team+는 리드 타임이나 PR 수 등 데이터를 자동으로 수집하고 시각화해 주는 점이 큰 매력이었죠. 저희들이 애써 집계하던 정보를 간단히 대시보드에서 확인할 수 있게 된 것입니다. 도입 전에 데모를 봤을 때, 이와모토도 “이거야말로 우리가 찾고 있던 도구다”라고 즉각 반응했을 정도였습니다.

또한 툴 도입을 검토하면서 “수치를 기반으로 의사결정하는 문화를 사내에 정착시키고 싶다”는 의지가 강하게 있었습니다. Findy Team+는 단순히 시각화에 그치지 않고, 구성원이 과제를 ‘자기 일’로 인식하게 만드는 계기가 될 수 있다고 느낀 것도 도입을 결정한 이유 중 하나였습니다.

── 실제로 과제를 특정하기 위해 어떤 프로세스를 거치셨나요?

Iwamoto：우선 “확인할 수 있는 데이터부터 시작해 보자”는 접근으로 시작했습니다. 처음 주목한 것은 PR 작성부터 머지까지의 리드 타임과 디플로이 빈도였습니다.

실제로 Findy Team+를 도입해 데이터를 확인해 보니, 전체 리드 타임의 40% 이상이 리뷰 대기 시간이라는 사실이 드러났습니다. 이건 꽤 충격적이였죠. 엔지니어들은 “바쁘니까 어쩔 수 없지”라고 생각하고 있었던 듯하지만, 수치로 가시화되니 설득력이 전혀 달랐고 그 순간 팀 전체가 술렁였습니다.

더 깊이 파고들어 보니, 리뷰에 대한 심리적 장벽이나 리뷰 담당자가 고정되어 있는 구조가 원인이라는 사실을 알게 되었습니다. “그럼 어떻게 해야 하지?”라는 논의가 이어졌는데 랜덤한 페어 프로그래밍이나 주간 회고 회의를 도입하기로 했습니다. 이런 대응을 결정할 수 있었던 것도 Findy Team+가 제시해 주는 데이터 덕분에 구체적인 액션으로 이어졌기 때문이라 생각합니다.

가시화에서 사업 연계로─‘가치를 전달한다’를 중심에 둔 개발 생산성 개선의 4단계

─ 개발 생산성 향상을 위한 활동의 변화 과정을 알려주세요.

Iwamoto：저희의 활동은 크게 4단계로 나눌 수 있습니다.

• 페이즈 1：일단 ‘가시화’부터 시작

Iwamoto：무엇보다도 우선은 현황 파악이었습니다. PR 수, 리드 타임, 디플로이 빈도 등 “측정 가능한 것부터 측정하자”는 단순한 출발이었죠. 초기에는 “PR 수가 적다”, “리뷰가 느리다”와 같은 정성적인 피드백은 있었지만 수치로 제시하자 과제 의식이 팀 전체에 급속히 퍼졌습니다. “이건 좀 심각하네”라는 공통 인식을 공유하게 된 것이 큰 전환점이었습니다.

• 페이즈 2：수치를 기반으로 한 개선 액션으로 전환

Iwamoto：가시화된 데이터를 바탕으로 리뷰 체계 재정비나 디플로이 절차 간소화에 착수했습니다. 특히 집중한 것은 페어 프로그래밍 도입이었습니다. 처음에는 “시간 낭비 아니야?”라는 우려도 있었지만, 막상 시행해보니 지식 공유가 활발해지고 리뷰의 질도 향상되었죠. 그 결과 리드 타임은 도입 전 대비 30% 이상 단축되었습니다.

• 페이즈 3：정성적 요소 반영과 문화 정착

Iwamoto：숫자만을 추적하다 보면 멤버가 지치거나 “수치 목표 달성을 위한 개발”이 되어버릴 위험도 있습니다. 그래서 회고 기능이나 설문 기능을 활용해 “왜 이 수치를 개선해야 하는가”를 팀에서 함께 고민하는 시간을 마련했습니다. 멤버로부터 “요즘 리뷰가 빨라져서 스트레스가 줄었다”, “다른 팀과 교류할 기회가 늘어 재미있다”는 이야기가 나온 것도 매우 반가운 변화였습니다.

• 페이즈 4（현재）：사업과의 연계 강화

Iwamoto：현재는 개발 생산성과 사업 KPI를 연결시키는 데 집중하고 있습니다. 단순히 디플로이 속도가 빨라지는 것만으로는 의미가 없습니다. 진정 중요한 것은 “사용자에게 얼마나 빠르게 가치를 전달했는가”입니다.

실제로 디플로이 빈도를 2배로 늘린 결과, 사용자 피드백을 바탕으로 신속히 개선할 수 있게 되었고, 서비스 이용 지속률이 상승하는 긍정적인 순환이 일어나고 있습니다.

Yamaguchi：이 활동을 진행하는 과정에서 여러 번 “왜 이걸 하는가?”라는 질문을 던졌습니다. 가시화나 개선은 어디까지나 수단일 뿐, 목적은 “사용자에게 계속해서 가치를 전달하는 것”입니다. 이 핵심 목적을 잃지 않고 지속해 온 것이 지금의 성과로 이어졌다고 생각합니다.

“목소리를 내는 것”이 당연한 문화로. Findy Team+가 키우는 대화와 인식의 문화

─ 회고 기능과 서베이 기능은 어떻게 활용되고 있나요?

Yamaguchi：Findy Team+의 회고 기능과 서베이 기능은 개발 생산성 향상 활동 중에서도 특히 중요한 역할을 하고 있습니다. 예전부터 팀 단위로 KPT(Keep, Problem, Try)를 진행해 왔지만 회고가 형식적으로 끝나거나 멤버 간에 솔직한 의견을 나누기 어려운 문제가 있었습니다.

Findy Team+의 회고 기능을 도입한 이후에는 정량적인 데이터(리드 타임, PR 수, 디플로이 빈도 등) 를 바탕으로 대화를 나눌 수 있게 되어, “왜 이 수치가 떨어졌을까?”, “다음에는 어디를 개선해야 할까?”와 같은 구체적인 논의가 훨씬 쉬워졌습니다.

예를 들어, 어느 주에 리드 타임이 급격히 늘어난 적이 있었는데 회고 기능을 통해 데이터를 확인한 결과, ‘리뷰 담당자가 특정 멤버에게 편중되어 있었던 것’이 원인으로 드러났습니다. 이에 따라 페어 프로그래밍의 로테이션화나 리뷰 담당자 분산을 실행했고, 다음 주에는 수치가 개선되었습니다. 문제 발견부터 개선까지의 속도가 확실히 빨라졌다는 점을 실감하고 있습니다.

또한 서베이 기능을 통해 멤버의 심리적 안정감이나 업무 만족도를 정기적으로 파악할 수 있게 되었습니다. 특히 도움이 되는 것은 수치로는 보이지 않는 정성적인 피드백입니다. 최근 서베이 결과에서는 한 팀으로부터 “최근 디플로이가 자주 이루어져 속도감은 있지만, 그만큼 문서화가 따라가지 못하고 있다”는 의견이 나왔습니다. 수치상으로는 문제가 없어 보이지만 현장에서는 다른 과제가 숨겨져 있는 경우도 있습니다. 이러한 피드백은 개선의 우선순위 결정이나 의사결정에 크게 도움이 됩니다.

무엇보다도, 회고 기능과 서베이 기능을 통해 “자신의 목소리를 내는 것이 당연하다”는 문화가 점차 뿌리내리고 있는 것이 가장 큰 변화입니다. 특히 신입이나 젊은 엔지니어로부터 “내 의견이 팀 개선에 반영되어 기쁘다”는 이야기를 들었을 때, 이 활동의 의의를 강하게 느꼈습니다.

Iwamoto：개발 생산성 향상은 숫자로만 측정할 수 있는 것이 아닙니다. 팀 분위기와 멤버의 동기 역시 똑같이 중요합니다.

Findy Team+의 회고 기능과 서베이 기능은 데이터와 감정 양쪽을 가시화할 수 있다는 점에서 큰 매력이 있습니다. 이를 통해 “무엇을 개선해야 하는가”뿐 아니라, “왜 그것을 개선해야 하는가”, “어떻게 하면 모두가 더 잘 일할 수 있을까”라는 본질적인 논의를 할 수 있게 되었습니다.

앞으로도 이 도구를 단순한 수치 관리 수단이 아니라, 팀 전체가 긍정적으로 성장할 수 있는 장을 만드는 계기로 활용해 나가고자 합니다.

개발자 경험뿐만 아니라, ‘디플로이 두 배 계획’ 추진 배경과 그 성과

─ 앞으로 새롭게 추진하시는 ‘디플로이 두 배 계획’의 배경에 대해 알려주세요.

Iwamoto：저희 회사에서는 원래 매일 디플로이가 당연하게 이루어지고 있었습니다. 그러나 개발 조직이 확대되는 가운데 “지금 이 속도로 정말 충분한가?”라는 의문이 들기 시작했죠. 사용자에게 더 빠르게 가치를 전달하기 위해서는 한 단계 더 속도를 높일 필요가 있다고 느꼈습니다.

시작은 “지금의 디플로이 빈도는 정말 한계인가?”라는 자문이었습니다. 데이터를 다시 살펴보니 기술적인 문제보다는 멤버의 인식이나 습관이 병목이 되고 있다는 사실을 알게 됐습니다. 예를 들어 “이 변경은 다음 주에 몰아서 내자”는 식으로 무의식적으로 미루는 경우가 있었죠. 그래서 “우선 인식부터 바꾸자”는 생각으로 디플로이 두 배를 목표로 내걸게 되었습니다.

─ 계획을 실행하면서 어떤 성과가 보였나요?

Yamaguchi：시작 후 불과 2주 만에 디플로이 횟수는 전월 대비 약 두 배로 증가했습니다. 더 놀라웠던 것은 숫자 이상의 변화, 즉 “빠르게 릴리스하는 것이 당연하다”는 인식이 팀에 정착되었다는 점입니다.

‘두 배’라는 목표를 향해 나아가는 과정에서 멤버들이 자발적으로 “어떻게 하면 더 안전하고 빠르게 릴리스할 수 있을까?”를 고민하며 개선에 나섰습니다. 예를 들어 리뷰 조기 착수, CI/CD 파이프라인 최적화, 릴리스 플로우 재검토 등 각 영역에서의 작은 시도들이 쌓이면서 개발 사이클 전체가 단축되었습니다.

물론 품질 유지도 중요합니다. 디플로이 빈도가 높아진 만큼 테스트 자동화와 단계적 릴리스 전략도 강화했습니다. 그 결과, 오히려 장애 발생률은 감소했고, 속도와 안정성의 양립에 성공했습니다.

─ 이번 활동을 통해 조직에는 어떤 변화가 있었나요?

Iwamoto：이 계획을 통해 사내에는 “속도는 가치 전달의 무기다”라는 인식이 확산되었습니다. 고객으로부터도 “릴리스가 빨라졌다”, “버그 수정 반영이 빠르다”는 피드백을 받게 되어 사용자 만족도 향상에도 이어졌습니다.

또한 멤버의 주체성이 높아진 것도 큰 성과입니다. 계획 발표 당시에는 “정말 가능할까?”라는 불안도 있었지만, 실제로 실행에 옮기자 “의외로 되잖아!”라는 성공 체험이 자신감으로 이어졌습니다. 지금은 “개선할 여지는 항상 있다”는 긍정적인 분위기가 팀 전체에 정착되어 있습니다.

앞으로도 이 흐름을 이어가며, 단지 ‘빠른’ 것에 그치지 않고 ‘가치 있는 디플로이’를 실현하고자 합니다. 속도와 품질의 양립을 통해 사용자에게 가장 빠르게 가치를 전달하는 것, 그것이 저희 개발 조직이 지향하는 모습입니다.

목적을 잃지 않기 위해... 개발 생산성의 ‘왜?’를 모두 함께 고민한 실천

─ 개발 생산성 향상 활동 중 특히 어려웠던 점은 무엇이었나요?

Iwamoto：가장 큰 과제는 “왜 이 활동을 하는가?”를 팀 전체가 공유하는 것이었습니다. 디플로이 빈도를 높이고 리드 타임을 단축하는 것은 어디까지나 수단일 뿐, 목적이 아니죠. 그러나 수치 목표를 쫓다 보면 본래의 목적을 잊기 쉬워집니다. 예를 들어 “디플로이 횟수를 두 배로”라는 것이 목적이 되어버리면 그저 횟수를 채우는 데 급급하게 됩니다. 그러나 사용자에게 가치를 전달하지 못한다면 아무 의미가 없습니다. 그래서 멤버들과 반복해서 대화를 나누며 “최종 목표는 사용자에게 더 빠르고 더 좋은 기능을 전달하는 것이다”라는 공통 인식을 갖는 것을 항상 중요하게 생각했습니다.

Yamaguchi：개선 활동을 진행하면서 “숫자만을 쫓는 일이 되지 않도록 하는 것” 또한 큰 벽이었습니다. Findy Team+를 도입하면 Four Keys 등의 지표를 손쉽게 확인할 수 있게 됩니다. 그러나 수치의 상승·하강에 휘둘리기보다는 “왜 이런 결과가 나왔는가?”를 생각하는 것이 중요하다고 느꼈습니다.

도입 초기에는 수치를 보다가 논의가 엉뚱한 방향으로 흘러가는 일도 있었지만 그럴 때마다 Findy Team+ 데이터를 바탕으로 구체적인 원인을 깊이 파악하는 데 집중했습니다.

예를 들면

• “리드 타임이 길어진 건 리뷰에서 병목이 생긴 건가?”

• “그럼 어떻게 하면 더 원활해질까?”

라는 식으로, 수치를 계기로 실제 액션으로 연결하는 것이 중요합니다. 데이터는 어디까지나 문제를 발견하기 위한 도구이며, 목적을 잃지 않고 개선에 활용하려는 태도를 항상 유지하려고 했습니다.

─ Findy Team+를 도입해서 특히 좋았던 점은 무엇인가요?

Iwamoto：Findy Team+의 매력은 “개발 생산성의 현황을 누구나 즉시 이해할 수 있다”는 점입니다. 리드 타임, 디플로이 빈도, 변경 실패율 등이 직관적인 그래프로 시각화되어 있기 때문에 엔지니어는 물론, 프로덕트 매니저나 비즈니스 측 멤버들도 즉시 상황을 파악할 수 있습니다.

덕분에 부서 간 논의가 훨씬 원활해졌습니다. “무엇이 문제이며 어떻게 개선해야 할지”에 대해 모두가 공통된 인식을 가질 수 있다는 점이 팀 운영에 있어 매우 큰 장점이라고 생각합니다.

Yamaguchi：개인적으로 추천하고 싶은 기능은 KPT 회고 기능과 서베이 기능입니다. 예전에는 회고 자료 준비에 시간이 많이 들었지만, Findy Team+는 데이터를 자동으로 불러와 주기 때문에 즉시 본질적인 논의에 집중할 수 있어 정말 좋습니다. 특히 서베이 기능을 통해서는 멤버의 심리적 안정감이나 팀 과제를 즉시 파악할 수 있어 ‘정량 데이터 + 정성 피드백’의 조합으로 보다 깊이 있는 회고가 가능해집니다. 과제가 눈에 보이면 자연스럽게 개선하고 싶어진다는 점도 느끼고 있습니다. Findy Team+는 “같이 더 나은 팀을 만들자!”는 분위기를 자연스럽게 만들어주는 도구라고 생각합니다.

“진짜 가치 있는 것을 빠르게, 그리고 높은 품질로.” 유저 퍼스트를 관철하는 개발 조직의 문화

─ 귀사의 개발 조직의 매력은 무엇인가요?

Iwamoto：저희가 가장 중요하게 생각하는 것은 ‘엔드 유저 퍼스트’와 ‘본질적이고 장기적인 사고방식’입니다.

단순히 “빨리 만든다”는 것이 아니라, “사용자에게 진짜 가치 있는 것을 빠르게, 그리고 높은 품질로 전달하는 것”을 중시하고 있습니다. 그렇기 때문에 엔지니어도 적극적으로 사용자 인터뷰에 참여하고, 사업 KPI를 의식하면서 개발에 임하고 있습니다.

또 하나의 강점은 솔직하게 의견을 나눌 수 있는 문화입니다.

• “이건 뭔가 아닌 것 같은데요?”라고 생각하면 누구나 자유롭게 말할 수 있다,

• 지적을 받았을 때도 “그러네, 고마워!”라고 긍정적으로 받아들일 수 있다,

이런 분위기는 다양한 배경을 가진 멤버들이 서로를 존중하고 있기 때문에 가능한 일이라 생각합니다. 먼저 말 꺼내는 걸 주저하지 않고 솔직하게 의견을 주고받는 것, 그것이 좋은 제품을 만드는 데 반드시 필요한 문화라고 믿고 있습니다.

Yamaguchi：또 하나의 매력은 “성장하고 싶은 사람에게 아낌없이 기회를 주는 환경”입니다. 신입이어도 “이거 해보고 싶어요!”라고 말하면 바로 맡길 수 있습니다. 물론 책임도 따르지만 주변에서 정말 진심으로 서포트해주기 때문에 안심하고 도전할 수 있습니다. 실제로 입사 2년 차 멤버가 대형 프로젝트를 리드하는 일도 드물지 않습니다.

“엔지니어로서도, 인간으로서도 성장하고 싶다!” 그런 마음을 가진 분이라면 저희 팀은 정말 최고의 환경이라고 자신 있게 말씀드릴 수 있습니다!

“만드는 것”으로 끝내지 않는다. 사용자 지향성과 성장 의지를 가진 동료를 환영합니다

Iwamoto：앞으로 함께 일하고 싶은 분은 “사용자에게 가치를 전달하기 위해 스스로 움직일 수 있는 사람”입니다. 저희는 단순히 “지시받은 것을 만드는 엔지니어”를 찾는 것이 아니라, “왜 만들고 있는지”, “어떻게 하면 더 나아질 수 있을지”를 함께 고민할 수 있는 사람을 환영합니다. 특히 사용자 관점을 갖고 있고 사업이나 비즈니스에 대한 관심이 있는 분이라면, 저희와 함께 재미있게 일하실 수 있을 것입니다.

Yamaguchi：그리고 “성장을 즐길 수 있는 사람”도요. 원캐리어에서는 매일 열리는 스터디 모임이나 랜덤 페어 프로그래밍 등을 통해 기술력과 팀워크를 다듬을 수 있는 기회가 많습니다. 물론 힘든 일도 있지만 그 안에서 재미를 느낄 수 있는 분이라면 자연스럽게 조직에 녹아들 수 있다고 생각합니다.

그리고 무엇보다 중요한 건 “자신의 일이 누군가에게 도움이 되고 있다”는 걸 기쁘게 느낄 수 있는지입니다. 그런 마음을 가진 분들과 함께, 지금보다 더 좋은 조직을 함께 만들어 나가고 싶습니다!