DORA 지표란 무엇인가? 개발자가 알아야 할 네 가지 핵심
요약
DORA 지표란 무엇인가? 소프트웨어 배포 성능의 네 가지 핵심 측정입니다. 배포 빈도, 변경 리드 타임, 실패율, 복구 시간으로 팀의 배포 능력을 진단하고 개선합니다.
DORA 지표란 무엇인가? 소프트웨어 배포 성능을 수치화하는 네 가지 측정입니다: 배포 빈도(Deployment Frequency), 변경 리드 타임(Lead Time for Changes), 변경 실패율(Change Failure Rate), 서비스 복구 시간(Time to Restore Service). Nicole Forsgren, Jez Humble, Gene Kim이 개발했고 수만 개 팀에서 검증됐으며, 2018년 구글이 인수했습니다.
DORA 지표의 출발점과 연구가 중요한 이유
DORA 프로그램은 2014년 한 가지 질문에서 시작했습니다: 성과가 뛰어난 소프트웨어팀과 평범한팀은 무엇이 다를까? 연구팀은 매년 수만 명의 개발자를 대상으로 조사를 실시해서, 소프트웨어 배포 결과를 좌우하는 관행을 찾아냈습니다.
연구에서 가장 충격적이었던 발견은 직관에 반했습니다. 성과가 뛰어난팀은 속도와 안정성 중 하나를 포기하지 않았습니다. 더 자주 배포했는데도 버그가 적었습니다. 이는 배포 사이클을 늘리는 이유로 흔히 주장하는 설명을 깼습니다. "덜 배포하면 덜 깨진다"는 논리였죠.
데이터는 반대를 말했습니다. 자주 배포하는팀은 더 나은 피드백 루프를 만들었고, 문제를 더 빨리 잡았고, 뭔가 잘못되면 더 빨리 복구했습니다. 속도와 안정성은 대립하지 않았습니다. 연관성이 있었습니다.
구글은 2018년 DORA 프로그램을 인수했습니다. 팀은 이제 매년 DevOps 상태 보고서를 발표하고 2025년에 다섯 번째 지표(리워크 비율)를 추가했으며, 연구를 dora.dev에서 공개 이니셔티브로 운영하고 있습니다.
네 가지 지표와 각각이 실제로 추적하는 것
2025년 모델은 리워크 비율을 다섯 번째 지표로 추가하면서 업데이트됐지만, 원래 네 가지가 대부분의 도구와 팀 논의의 기준이 됩니다.
배포 빈도(Deployment Frequency)
팀이 프로덕션에 얼마나 자주 푸시하는가. 그게 정의의 전부입니다.
성과가 뛰어난팀은 온디맨드로 배포합니다: 뭔가 준비되면 하루에 여러 번씩. 성과가 낮은팀은 한 달에 한 번 또는 더 적게, 때론 몇 개월에 한 번 배포합니다. 개인 개발자라면 일관된 주간 배포 주기는 이 하나의 지표만 봐도 성과가 뛰어난 범주에 들어갑니다.
배포 빈도는 파이프라인에 대한 신뢰도를 보여주는 지표입니다. 자주 배포하지 않는팀은 보통 취약한 인프라, 무거운 수동 테스트 게이트, 배포를 느리게 만드는 조직의 승인 단계를 갖고 있습니다. 하루에 여러 번 배포하는팀은 그런 병목들을 대부분 자동화했습니다. 빈도는 결과지, 원인이 아닙니다.
변경 리드 타임(Lead Time for Changes)
커밋이 버전 관리에 들어온 순간부터 같은 변경이 프로덕션에 올라가는 순간까지의 시간입니다.
이 시간의 대부분은 코딩이 아닙니다. 기다리는 것입니다: PR 큐가 정리될 때까지, CI/CD 파이프라인이 끝날 때까지, 배포 슬롯이 나올 때까지, 배포를 실행할 권한 있는 사람을 기다리는 것. 리드 타임이 몇 시간이면 워크플로가 팽팽하고 대부분 자동화됐다는 뜻입니다. 리드 타임이 주 단위면 그 핸드오프 포인트 중 하나 이상에서 무언가 구조적으로 마찰을 일으킵니다.
개인 개발자라면 리드 타임은 커밋을 푸시하는 것부터 사용자가 결과를 보는 것까지의 모든 것입니다. 때론 배포 파이프라인이 12분 걸리고, 때론 변경이 배포할 만큼 안정적인지에 대한 내적 주저함입니다.
변경 실패율(Change Failure Rate)
배포된 변경 중 프로덕션에서 장애나 롤백이 필요한 비율입니다.
낮은 실패율은 당신의팀이 변경을 꼼꼼히 검토하고 있다는 뜻일 수도, 단순히 배포가 드물어서 문제가 적대로 드러날 기회가 적다는 뜻일 수도 있습니다. 배포가 자주 일어나는팀에서 실패율이 낮다면? 그건 진짜 신호입니다.
엘리트팀의 변경 실패율은 대체로 15% 미만입니다. 대규모 조직의 평균은 15-45%입니다. 성과가 낮은곳은 40% 초과입니다.
서비스 복구 시간(Time to Restore Service)
무언가 프로덕션에서 고장 났을 때, 다시 정상 작동할 때까지 걸리는 시간입니다.
복구 시간은 인프라와 관찰성(observability)을 반영합니다. 무슨 일이 일어났는지 빠르게 파악할 수 있으면 복구도 빠릅니다. 모니터링이 있으면 없는 것과 하늘과 땅입니다.
엘리트팀은 1시간 이내에 복구합니다. 높은 성과팀은 1-6시간. 중간 성과팀은 6-24시간. 낮은 성과팀은 24시간 이상.
DORA를 계측하기 시작할 때 실제로 일어나는 일
처음엔 DORA를 측정하는 게 어떻게 되나 싶을 수 있습니다. 자동화된 배포 파이프라인이 없으면? 수동 테스트가 대부분이면? Slack 통지로 배포 기록하는 게 진짜인가요?
네, 진짜입니다. 정확하지 않아도 됩니다. 시작점이 중요합니다.
배포 빈도는 깃 로그, CI/CD 로그, 또는 Slack 기록에서 셀 수 있습니다. 리드 타임은 첫 커밋과 배포 사이 시간을 계산하면 됩니다. 실패율은 "이번 달에 뭐가 터졌나"를 세면 됩니다. 복구 시간은 "경고에서 고정까지 몇 시간"입니다.
작은 수동 계산이라도, 한 달을 재는 것도 추세를 잡을 수 있습니다. 측정이 일어나면 개선이 움직입니다.
DORA가 답하지 않는 것들
DORA는 강력한 틀입니다. 하지만 소프트웨어 배포의 모든 측면을 포착하진 않습니다.
코드 품질, 보안 태세, 사용자 만족도는 DORA 지표에 직접 나타나지 않습니다. 자주 배포하고도 버그투성이일 수 있습니다. 빨리 복구하고도 같은 버그가 반복될 수 있습니다.
2025년에 DORA에 추가된 리워크 비율(Rework Rate)이 이를 약간 보완합니다. 하지만 근본적으로 DORA는 "얼마나 자주, 얼마나 빨리"를 측정합니다. "얼마나 잘"은 다른 도구와 문화 측정이 필요합니다.
개인 개발자나 스타트업은 DORA를 배포 속도와 안정성 이상으로 해석하지 않는 게 좋습니다. 그것만으로도 충분한 신호입니다.
시작하기
DORA 지표를 추적하려면:
지난 한 달 배포를 센다. 주당 또는 월당 몇 번?
최근 변경부터 배포까지 걸린 시간을 본다. 몇 시간? 며칠?
어떤 배포가 문제를 일으켰는지, 또는 버그였는지를 본다.
최근에 뭔가 고장 나면 얼마나 빨리 고쳤나 본다.
여기서 멈춰도 됩니다. 또는 이 네 가지를 매달 추적해서 추세를 본다. 선택입니다.
팀이 작으면 DORA는 증거입니다. 팀이 크면 DORA는 경보기입니다. 어느 쪽이든 시작하는 게 중요합니다.