우리 팀은 왜 배포가 이렇게 느릴까? 딜리버리 비효율의 진짜 원인

"코드는 다 짰는데 왜 배포까지 2주가 걸리지?"

개발하다 보면 이런 답답함 겪어보셨을 거예요. 기능 자체는 하루 이틀이면 다 만들었는데, 정작 그게 실제 사용자에게 배포되기까지는 며칠, 심하면 몇 주가 걸리는 상황이요. ACM에 실린 이 연구는 바로 그 지점, "소프트웨어를 만들어 전달하는 과정(software delivery)이 왜 이렇게 비효율적인가"를 파고들어요.

핵심 통찰은 이거예요. 개발이 느린 진짜 원인은 대부분 "코딩 속도"가 아니라 "코딩하지 않고 기다리는 시간"에 있다는 거죠. 그래서 개발자를 더 쥐어짠다고 빨라지지 않는다는 게 이 연구가 던지는 메시지예요.

비효율은 대부분 "대기 시간"에서 나와요

일이 흘러가는 과정을 쭉 늘어놓고 보면, 실제로 손을 움직여 작업하는 시간보다 뭔가를 기다리는 시간이 훨씬 길다는 걸 발견하게 돼요. 이걸 "흐름 효율(flow efficiency)"이라고 하는데, 전체 소요 시간 중 실제 작업 시간의 비율이에요. 많은 팀이 이 수치가 놀랄 만큼 낮아요. 15%도 안 되는 경우가 흔하죠. 나머지 85%는 다 기다리는 시간이라는 거예요.

그럼 뭘 기다리느냐. 대표적인 게 이런 것들이에요. 코드 리뷰가 며칠씩 밀려서 기다리고, 테스트 환경이 없거나 불안정해서 기다리고, 다른 팀에 요청한 게 처리되길 기다리고(핸드오프), 요구사항이 애매해서 물어보고 답을 기다려요. 여기에 여러 일을 동시에 하느라 생기는 "컨텍스트 스위칭(맥락 전환)" 비용도 커요. 사람이 이 일 저 일 왔다 갔다 하면 매번 머릿속을 다시 세팅해야 하니까 실질 생산성이 뚝 떨어지거든요.

또 하나 무시 못 할 게 "기술 부채(technical debt)"예요. 급하게 대충 짜놓은 코드가 쌓이면, 나중엔 작은 변경 하나에도 여기저기 부서질까 봐 조심스러워지고, 결국 모든 작업이 느려져요. 이자가 붙는 빚처럼 시간이 갈수록 더 발목을 잡죠.

이걸 어떻게 측정하고 개선하나

이 분야에서 유명한 게 "DORA 지표"예요. 구글이 주도한 연구에서 나온 네 가지 핵심 지표인데요. 배포 빈도(얼마나 자주 배포하나), 변경 리드 타임(코드 커밋부터 배포까지 걸리는 시간), 변경 실패율(배포 후 문제가 생기는 비율), 복구 시간(장애가 나면 얼마나 빨리 복구하나)이에요. 잘하는 팀일수록 자주, 빠르게, 안정적으로 배포한다는 게 데이터로 증명됐죠.

개선 방법으로는 한 번에 진행하는 작업 수를 제한하기(WIP 제한), 큰 덩어리 대신 작게 자주 배포하기, 리뷰와 테스트를 자동화해 대기 시간을 줄이기, 그리고 "가치 흐름 지도(value stream mapping)"로 일이 막히는 병목 지점을 눈으로 확인하기 등이 있어요. SPACE 프레임워크처럼 생산성을 속도뿐 아니라 만족도, 협업 같은 여러 각도로 함께 보려는 시도도 있고요.

한국 개발자에게

한국 개발 조직에서도 정말 공감될 이야기일 거예요. 우리는 종종 "개발자가 코딩을 더 빨리 하면 되지"라고 생각하기 쉬운데, 이 연구는 그게 핵심이 아니라고 말해요. 리뷰가 왜 밀리는지, 배포 파이프라인 어디서 막히는지, 팀 간 요청이 왜 늦어지는지 같은 "과정의 병목"을 찾아 없애는 게 훨씬 효과가 크다는 거죠.

당장 해볼 수 있는 건, 우리 팀의 리드 타임을 한번 측정해보는 거예요. "이 기능, 아이디어부터 배포까지 며칠 걸렸지?"를 기록해보면 어디서 시간이 새는지 보이거든요. 측정하지 않으면 개선할 수도 없으니까요. 감으로 "우리 느린 것 같아"가 아니라 숫자로 보는 게 시작이에요.

결국 빠른 팀은 손이 빠른 게 아니라 기다리는 시간이 짧은 팀이에요. 여러분 팀에서 가장 오래 "기다리게" 만드는 병목은 어디인가요?