DORA 지표

배포 성과를 재는 네 가지 지표. 속도 둘과 안정성 둘로 짝을 이루는 것이 핵심이다.

왜 반드시 넷을 같이 보나

속도만 보면 검증을 걷어 내면 된다 — 배포 빈도는 오르고 실패율은 폭발한다. 안정성만 보면 배포를 안 하면 된다 — 실패율은 0 이고 리드 타임은 무한이다.

한쪽을 올리려고 다른 쪽을 희생하는 것을 서로 막는 구조다. 지표 하나를 목표로 삼는 순간 그 지표는 지표이기를 그만둔다는 문제를, 짝을 지어 푼다.

자주 배포하는 쪽이 더 안정적이다

직관에 반하지만 조사 결과는 일관된다. 이유는 배포 단위의 크기다.

2주치를 한 번에   →  변경 200개 중 무엇이 원인인지 모른다
                     되돌리면 정상 변경까지 함께 되돌아간다
하루에 여러 번    →  변경 2개. 원인이 자명하고 되돌림이 싸다

자주 배포하는 것이 원인이자 결과다 — 배포가 싸고 안전해야 자주 하게 되고, 자주 하면 한 번의 크기가 작아져 더 안전해진다.

무엇을 개선해야 하는지 가리킨다

• 리드 타임이 길다 → 대기 시간을 찾는다. 리뷰 대기·수동 승인·느린 테스트
• 실패율이 높다 → 검증이 얇거나 배포 단위가 크다
• 복구가 느리다 → 롤백 절차·관측성 문제. 무엇이 깨졌는지 아는 데 오래 걸리는 것인지, 고치는 데 오래 걸리는 것인지 나눠 본다

MTTR 을 줄이는 가장 확실한 방법이 되돌리기를 쉽게 만드는 것이라는 점이 중요하다. 원인을 규명한 뒤 고치는 것보다 일단 되돌리는 편이 훨씬 빠르다.

어떻게 재나

배포 빈도      배포 파이프라인의 성공 실행 횟수
리드 타임      커밋 시각 → 그 커밋이 포함된 배포 시각
변경 실패율    롤백·핫픽스를 부른 배포 / 전체 배포
복구 시간      장애 시작 → 정상 복귀 (사고 기록에서)

앞의 둘은 파이프라인 로그에서 자동으로 나온다. 뒤의 둘은 "무엇을 장애로 볼 것인가" 를 팀이 정의해야 해서 수작업이 섞인다. 그래서 실무에서는 앞의 둘부터 재기 시작하는 경우가 많다.

주의할 점은 리드 타임의 시작점이다. 커밋 시각으로 재면 리뷰 대기가 포함되고, 병합 시각으로 재면 빠져 버린다. 개선하고 싶은 것이 대기 시간이라면 커밋 시각으로 재야 그 대기가 보인다.

이 지표들은 결과이지 목표가 아니다

네 지표를 직접 올리려 하면 왜곡되기 쉽다. 실제로 손대야 하는 것은 그 지표를 만들어 내는 관행이다 — 작은 배치, 자동화된 검증, 되돌리기 쉬운 구조, 짧은 브랜치. 지표는 그것들이 잘 되고 있는지 알려 주는 계기판이다.

조심할 것

지표를 팀 평가에 쓰면 즉시 왜곡된다. 배포를 잘게 쪼개 횟수를 늘리거나, 장애를 장애로 기록하지 않게 된다. 개선의 나침반으로 쓰고 성과급의 근거로 쓰지 않는다.

면접 함정

• ❌ "배포 빈도가 높으면 좋은 팀" → 실패율·복구 시간과 같이 봐야 의미가 있다.
• ❌ "자주 배포하면 위험하다" → 배포 단위가 작아져 오히려 안전해진다.
• ❌ "MTTR 은 원인 분석 속도" → 회복까지의 시간이다. 롤백이 가장 빠른 회복 수단인 경우가 많다.