제품 출시 속도가 떨어지는 이유 진단하기(Diagnose why your product's shipping velocity is declining)
팀 규모는 5명에서 15명으로 늘었는데 분기당 출시 기능 수는 오히려 줄고 있을 때 쓰는 프롬프트입니다. 스탠드업은 형식적이고, PR은 며칠씩 리뷰에 묶이며, 스프린트 약속은 계속 어긋나는 상황에서 진짜 병목이 프로세스인지, 아키텍처인지, 사람인지 구조적으로 진단합니다.
엔지니어를 더 뽑았는데 왜 출시는 더 느려졌을까?
소프트웨어 개발에서 가장 역설적인 패턴 중 하나입니다. 팀이 두 배가 되는데 velocity는 오히려 떨어집니다. 그것도 조금이 아니라 극적으로 떨어지는 경우가 많습니다. DORA(DevOps Research and Assessment) 프로그램의 널리 인용되는 연구에 따르면 elite engineering 조직은 low performer보다 973배 더 자주 배포합니다. 그 차이는 재능이나 기술보다, 일이 시스템 안에서 어떻게 흐르느냐에서 나옵니다.
Brooks의 법칙은 여전히 유효하다
Fred Brooks는 1975년에 늦어진 소프트웨어 프로젝트에 사람을 더 투입하면 더 늦어진다고 말했습니다. 원칙은 바뀌지 않았고, 메커니즘만 진화했습니다. 현대의 제품팀에서는 velocity 저하가 다음처럼 드러납니다. 리뷰 대기열이 PR 자체보다 길어지고, 팀원이 늘 때마다 회의가 증식하고, 코드베이스의 소유권 경계가 불분명해 아키텍트가 인간 라우터가 됩니다.
Ramp의 VP of Product인 Geoff Charles는 팀이 커져도 속도를 유지하기 위한 접근을 설명하며, 엔지니어링 품질을 일급 우선순위로 다루고, 작은 자율 팀에 권한을 주며, coordination overhead를 가차 없이 제거해야 한다고 말했습니다. 가장 빠르게 ship하는 회사는 엔지니어 수가 가장 많은 회사가 아니라, 의도와 배포 사이의 friction이 가장 적은 회사입니다.
이 Velocity Diagnosis 프롬프트의 작동 방식
이 프롬프트는 velocity 저하를 사기 저하 문제가 아니라 진단 문제로 다룹니다. 먼저 10가지 대표적인 velocity killer를 심각도로 점수화하는 symptom inventory를 진행합니다. 그런 다음 증상을 process bloat, architecture friction, coordination overhead, scope creep, skill gap이라는 다섯 범주로 묶어 root cause를 파악합니다. 확인된 각 root cause마다 owner, timeline, success metric이 붙은 구체적 intervention을 설계하고, 이를 quick win(이번 주), medium-term fix(이번 달), structural change(이번 분기)로 나눕니다.
Step 5의 time allocation breakdown은 종종 가장 충격적인 결과를 줍니다. 엔지니어링 시간의 35%가 회의와 support에 쓰이고 있다는 사실을 팀이 발견하는 순간, velocity 회복 경로는 코드 한 줄도 바꾸기 전에 이미 보이기 시작합니다.
언제 사용할까
- headcount는 안정적이거나 늘고 있는데 sprint velocity가 3개 이상 연속으로 떨어졌을 때
- 팀이 코딩보다 회의와 리뷰에 더 많은 시간을 쓰는 것 같을 때
- 팀은 커졌는데 deploy frequency는 오히려 감소했을 때
- 신규 엔지니어가 기대보다 훨씬 늦게 생산성을 내기 시작할 때
- 엔지니어링 리더십은 "사람이 더 필요하다"고 말하지만, 사람을 늘려도 도움이 되지 않았을 때
흔한 함정
개인이 아니라 시스템을 봐야 한다. velocity 저하는 거의 항상 사람 문제가 아니라 시스템 문제입니다. 모든 신규 채용이 3개월 뒤에도 느려진다면, 문제는 채용된 사람보다 환경에 있습니다.
진단 없이 조직 개편부터 하는 것. 팀 재조정은 가장 파괴적인 intervention이며 마지막 수단이어야 합니다. 사람을 옮기지 않아도 되는 프로세스와 도구 개선부터 시작하세요.
산출량을 결과보다 더 중시하는 것. sprint당 완료 story points는 방향성을 보는 데는 쓸 수 있지만 성과 지표로는 형편없습니다. deploy frequency와 cycle time에 집중하세요. 고객에게 가치가 얼마나 빨리 도달하는지를 측정하는 지표이기 때문입니다.
참고 자료
- DORA State of DevOps Report — Industry benchmarks for engineering velocity and deployment performance
- Ramp Engineering Blog: How Ramp Ships Fast — Ramp's engineering blog covering velocity and scaling practices
- An Elegant Puzzle — Will Larson on systems thinking for engineering organizations
Sources
- DORA State of DevOps Report — DORA
- Ramp Engineering Blog — Ramp
- An Elegant Puzzle — Will Larson
Prompt details
Ready to try the prompt?
Open the live prompt detail page for the full workflow.