딜리버리 성과·5 분

응답 23,000건을 견뎌낸 네 개의 지표

속도와 안정성은 맞바꾸는 관계가 아닙니다. 지난 20년간 소프트웨어 딜리버리에 관해 나온 이야기 중 가장 쓸모 있는 발견입니다.

출처

Accelerate: The Science of Lean Software and DevOps

Nicole Forsgren, Jez Humble & Gene Kim · IT Revolution · 2018

이 자료의 저자는 AslanWay가 아닙니다. 아래 요약은 원문 내용을 정리한 것이고, 이어지는 해설은 저희 의견이며 저자의 동의를 받은 것이 아닙니다.

이 자료의 주장

『Accelerate』는 2,000개 이상 조직에서 모은 23,000건 넘는 설문 응답을 바탕으로 한 다년간의 연구를 정리한 책입니다. 기여한 지점은 명확합니다. 그동안 일화로 굴러가던 분야에 통계적 방법을 들여왔다는 것.

책이 추려낸 네 지표는 배포 빈도, 변경 리드타임, 변경 실패율, 서비스 복구 시간입니다. 앞의 둘은 속도, 뒤의 둘은 안정성을 봅니다.

연구 결과 속도 지표와 안정성 지표는 같은 방향으로 움직였습니다. 자주 배포하는 팀이 덜 실패하고 더 빨리 복구합니다. '안전하려면 속도를 늦춰야 한다'는 통념은 데이터로 뒷받침되지 않았습니다.

작동 원리는 작은 배치입니다. 변경이 작으면 리뷰도, 테스트도, 장애 원인 추적도, 되돌리기도 쉽습니다. 변경 승인 위원회나 긴 릴리스 열차는 배치를 키우고, 그만큼 릴리스 하나하나를 위험하게 만듭니다.

책은 이 지표들을 수익성·점유율·생산성 같은 조직 성과와도 연결합니다. 덕분에 엔지니어링 조직 안에서만이 아니라 이사회 대화에서도 쓸 수 있는 언어가 되었습니다.

네 개를 다 보든지, 아니면 아예 보지 마십시오. 배포 빈도만 보면 쓰레기를 빨리 내보내게 되고, 변경 실패율만 보면 아무것도 안 내보내는 게 최적해가 됩니다.
더 안전해지고 싶다면 승인 게이트를 늘릴 게 아니라 배치를 줄이고 자동화 테스트를 손봐야 합니다. 게이트는 배치를 키우고, 애초에 문제를 만든 게 그 크기입니다.
다만 DORA의 2025년 보고서는 엘리트·상·중·하 등급 구분에서 팀 유형 분류로 방향을 바꿨습니다. 네 지표는 남과 비교하는 순위표가 아니라 우리 팀의 추세선으로 쓰는 편이 맞습니다.