소프트웨어 개발 조직에서 성과를 정량적으로 측정하는 것은 오래된 숙제다. 개발 프로세스가 개선되고 있다는 느낌은 있지만, 이를 명확한 숫자로 증명하기란 쉽지 않다. “어떤 팀이 정말 잘하고 있는가?”, “개선 노력이 실제로 효과가 있는가?“라는 질문에 객관적으로 답하기 위해서는 신뢰할 수 있는 측정 방법이 필요하다.

DORA 메트릭스는 이러한 문제에 대한 과학적 접근이다. 측정과 기록, 관리가 필요한 일이라 실무에 적용하기는 쉽지 않다는 평가가 많지만, DevOps 성과를 바라보는 관점을 이해하는 것만으로도 의미가 있다. 이 글에서는 DORA 메트릭스에 대해 깊이 있게 살펴본다.

DORA의 시작과 발전

DORA(DevOps Research and Assessment)의 역사는 2013년으로 거슬러 올라간다. 당시부터 State of DevOps Report라는 이름으로 산업 전반의 DevOps 현황을 조사하기 시작했고, 2015년 말 Nicole Forsgren 박사, Jez Humble, Gene Kim이 함께 DORA LLC를 정식으로 설립했다. 이후 2018년에 Google Cloud가 이 조직을 인수하면서 더욱 체계적인 연구가 가능해졌다.

이들의 연구는 단순한 업계 조사를 넘어서는 것이었다. 매년 수만 명의 기술 전문가를 대상으로 설문조사를 진행하며, 고성과 조직과 저성과 조직을 구분하는 요인을 통계적으로 분석했다. 이 10년 이상의 연구 결과는 2018년 “Accelerate: The Science of Lean Software and DevOps"라는 책으로 출간되었는데, 여기서 처음으로 4가지 핵심 지표가 제시되었다. 이후 2021년에 신뢰성(Reliability)이, 2024년에는 재작업률(Rework Rate)이 추가되면서 현재는 6가지 메트릭으로 확장되었다.

네 가지 핵심 지표

DORA가 제시한 핵심 지표는 크게 두 가지 측면을 본다. 속도와 안정성이다. 배포 빈도와 변경 리드 타임은 속도를, 변경 실패율과 서비스 복구 시간은 안정성을 측정한다.

배포 빈도 (Deployment Frequency)

배포 빈도는 말 그대로 얼마나 자주 프로덕션 환경에 코드를 배포하는가를 측정한다. CI/CD 파이프라인 로그나 배포 도구의 메트릭, Git 태그 등을 활용해서 측정할 수 있다.

2024년 기준으로 엘리트 팀은 하루에 여러 번 배포한다. 온디맨드로 원할 때마다 배포할 수 있는 수준이다. 고성과 팀은 하루에 한 번에서 주 1회 정도, 중간 수준 팀은 주 1회에서 월 1회, 저성과 팀은 월 1회 이하로 배포한다.

이 지표가 중요한 이유는 배포 빈도가 높다는 것이 단순히 “자주 배포한다"는 의미를 넘어서기 때문이다. 작은 배치 크기로 자주 배포한다는 것은 각 배포마다 변경사항이 적다는 뜻이고, 이는 곧 리스크가 낮다는 의미다. 문제가 발생했을 때 원인을 파악하기도 쉽고, 사용자 피드백을 빠르게 받아 제품을 개선할 수 있다.

다만 주의할 점이 있다. 배포 빈도만 높이는 것이 목표가 되어서는 안 된다. 의미 없는 변경을 자주 배포하거나, 품질을 희생하면서까지 빈도를 높이는 것은 본말이 전도된 것이다.

변경 리드 타임 (Lead Time for Changes)

변경 리드 타임은 코드를 커밋한 시점부터 그 코드가 프로덕션 환경에서 실행되기까지 걸리는 시간을 말한다. Git 커밋 시간과 배포 완료 시간의 차이를 계산하면 되는데, 조직에 따라서는 Pull Request 머지 시간부터 측정하기도 한다.

엘리트 팀은 1시간 미만이다. 코드를 커밋하면 한 시간 안에 프로덕션에 올라간다는 얘기다. 고성과 팀은 1일에서 1주, 중간 팀은 1주에서 1개월, 저성과 팀은 1개월에서 6개월이 걸린다.

리드 타임이 짧다는 것은 아이디어부터 실제 가치 제공까지의 시간이 단축된다는 의미다. 시장 변화에 빠르게 대응하고 경쟁 우위를 확보하는 데 있어 핵심적인 요소다. 또한 짧은 리드 타임은 자동화된 테스트, 효율적인 코드 리뷰 프로세스, 간소화된 배포 파이프라인의 결과물이기도 하다.

여기서 흔한 오해가 하나 있다. 리드 타임을 줄이기 위해 코드 리뷰를 건너뛰거나 테스트를 생략하면 안 된다는 것이다. 오히려 자동화와 병렬화를 통해 품질을 유지하면서 시간을 단축해야 한다.

변경 실패율 (Change Failure Rate)

변경 실패율은 프로덕션 배포 중 장애를 일으키거나 롤백, 핫픽스가 필요한 배포의 비율을 나타낸다. 실패한 배포 수를 전체 배포 수로 나눈 값이다. 여기서 “실패"는 서비스 중단, 서비스 품질 저하, 긴급 롤백, 핫픽스 배포 등을 포함한다.

2024년 DORA 리포트에서 벤치마크가 크게 업데이트되었는데, 엘리트 팀은 5%, 고성과 팀은 10%, 중간 팀은 15%, 저성과 팀은 64%로 나타났다. 과거에는 엘리트가 0-15%, 나머지가 모두 16-30%였던 것에 비해 훨씬 세분화되고 정확해졌다.

빠른 배포만큼 중요한 것이 안정성이다. 변경 실패율은 조직의 테스트 커버리지, 모니터링 능력, 릴리스 프로세스의 성숙도를 고스란히 반영한다. 낮은 실패율은 자동화된 테스트, 카나리 배포, 기능 플래그 같은 안전 장치가 제대로 작동하고 있다는 증거다.

이를 개선하려면 자동화된 테스트 커버리지를 확대하고, 스테이징 환경에서 프로덕션과 유사한 조건으로 테스트하며, Blue-Green이나 Canary 같은 점진적 배포 전략을 도입하는 것이 필요하다.

서비스 복구 시간 (Mean Time to Recovery, MTTR)

서비스 복구 시간은 장애가 발생한 후 서비스를 정상화하는 데 걸리는 평균 시간이다. 인시던트 관리 시스템의 타임스탬프를 활용해서 측정하는데, 평균값을 계산할 때는 극단값의 영향을 배제하기 위해 중앙값(median)도 함께 고려하는 것이 좋다.

엘리트 팀은 1시간 미만에 복구하고, 고성과 팀은 1일 미만, 중간 팀은 1일에서 1주, 저성과 팀은 1주에서 1개월 이상이 걸린다.

장애는 불가피하다. 아무리 잘 만든 시스템이라도 언젠가는 문제가 생긴다. 중요한 것은 얼마나 빨리 복구하느냐다. 빠른 복구 시간은 효과적인 모니터링, 명확한 롤백 전략, 잘 훈련된 인시던트 대응 프로세스의 결과물이다.

이를 위해서는 실시간 모니터링 및 알림 시스템을 구축하고, 자동화된 롤백 메커니즘을 갖춰야 한다. 인시던트 대응 플레이북을 작성하고 정기적으로 훈련하는 것도 중요하다. 사후 분석 문화를 확립하고, Feature Flag를 통해 문제가 있는 기능을 빠르게 비활성화할 수 있어야 한다.

확장된 지표들

신뢰성 (Reliability)

2021년에 추가된 다섯 번째 메트릭은 신뢰성이다. 서비스가 사용자 요구를 얼마나 충족하는지를 가용성과 성능으로 측정한다. 가동 시간을 전체 시간으로 나눈 값(예: 99.9%, 99.99%)이나, SLI(Service Level Indicators)와 SLO(Service Level Objectives)를 기반으로 측정한다.

빠르고 자주 배포하는 것도 중요하지만, 서비스가 안정적이지 않으면 의미가 없다. 흥미로운 점은 DORA 연구에 따르면 엘리트 팀은 속도와 안정성 모두에서 뛰어나다는 것이다. 이는 품질과 속도가 트레이드오프 관계가 아니라는 것을 증명한다.

재작업률 (Rework Rate)

2024년에 추가된 가장 새로운 메트릭이다. 배포된 변경사항 중 다시 수정이 필요한 작업의 비율을 나타낸다. 배포 후 일정 기간(예: 2주) 내에 동일한 코드 영역을 다시 수정한 비율로 측정하며, 버그 픽스, 설계 변경, 기능 수정 등을 모두 포함한다.

Change Failure Rate가 심각한 장애만을 측정하는 반면, Rework Rate는 더 넓은 범위의 품질 문제를 포착한다. 높은 재작업률은 불충분한 요구사항 분석, 기술 부채, 코드 품질 문제를 나타낸다. 아직 명확한 성과 수준별 벤치마크는 수립되지 않았지만, 점차 데이터가 축적되면서 표준이 만들어질 것으로 보인다.

성과 수준의 실제 모습

엘리트 팀(전체의 약 19%)은 하루에 여러 번 배포하고, 1시간 미만의 리드 타임에, 5%의 변경 실패율, 1시간 미만의 복구 시간을 보인다. 이들은 고도로 자동화된 CI/CD 파이프라인과 포괄적인 자동화 테스트를 갖추고 있다. 마이크로서비스 아키텍처와 느슨한 결합, 강력한 모니터링과 관찰성, 그리고 심리적 안정감이 높은 팀 문화가 특징이다.

고성과 팀(19%)은 하루 1회에서 주 1회 배포하고, 1일에서 1주의 리드 타임, 10%의 변경 실패율, 1일 미만의 복구 시간을 보인다. 잘 정의된 배포 프로세스와 자동화된 빌드 및 테스트, 효과적인 협업 문화를 갖추고 있다.

중간 수준 팀(22%)은 주 1회에서 월 1회 배포하며, 1주에서 1개월의 리드 타임, 15%의 변경 실패율, 1일에서 1주의 복구 시간을 보인다. 부분적 자동화가 이뤄져 있지만 수동 프로세스가 병목 지점으로 작용하고 있어 개선의 여지가 크다.

저성과 팀(25%)은 월 1회 이하로 배포하고, 1개월에서 6개월의 리드 타임, 64%의 변경 실패율, 1주에서 1개월 이상의 복구 시간이 걸린다. 수동 프로세스 위주로 운영되고, 긴 릴리스 사이클을 가지며, 레거시 시스템에 대한 의존도가 높다. 문서화와 표준화도 부족한 편이다.

DORA가 발견한 것들

DORA 연구에서 가장 흥미로운 발견은 속도와 안정성이 트레이드오프 관계가 아니라는 점이다. 전통적으로는 “빠르게 배포하려면 안정성을 포기해야 하고, 안정적이려면 느려질 수밖에 없다"고 생각했다. 하지만 실제 데이터는 정반대를 보여준다. 고성과 팀은 속도와 안정성 모두에서 뛰어나다. 자주 배포하는 팀이 오히려 더 안정적이고, 빠르게 복구한다.

이는 작은 배치 크기 덕분이다. 각 배포의 변경 사항이 적으면 리스크가 낮아진다. 또한 반복을 통해 학습하면서 프로세스가 개선되고, 자동화를 통해 휴먼 에러가 감소한다.

더 놀라운 것은 이러한 소프트웨어 전달 성과가 비즈니스 성과와도 직접적으로 연관되어 있다는 점이다. DORA 연구에 따르면 높은 소프트웨어 전달 성과를 보이는 조직은 수익성 증가 가능성이 2배, 시장 점유율 증가 가능성이 2배, 생산성 증가 가능성이 2배 높다. 직원 추천 지수(NPS)도 개선된다.

또한 기술적 실천만으로는 충분하지 않다는 것도 명확해졌다. DORA 연구는 문화와 기술의 상호작용을 강조한다. 심리적 안정감이 있어 실수를 인정하고 배울 수 있는 환경, 정보의 흐름과 협업, 혁신을 중시하는 웨스트럼 조직 문화, 실패로부터 배우는 사후 분석 문화, 팀이 의사결정 권한을 가지는 권한 위임 등이 함께 작용해야 한다.

측정의 실제

DORA 메트릭스를 수동으로 측정하는 것은 지속 가능하지 않다. 자동화가 필수다. 배포 빈도와 리드 타임은 Git 커밋 및 태그 정보, CI/CD 파이프라인 메타데이터(Jenkins, GitLab CI, GitHub Actions, CircleCI 등), 배포 도구 로그(Kubernetes, ArgoCD, Spinnaker), 클라우드 제공자 로그(AWS CodeDeploy, Azure DevOps) 등을 활용해서 측정할 수 있다.

변경 실패율은 인시던트 관리 시스템(PagerDuty, Opsgenie, Jira Service Management), 모니터링 및 로깅 시스템(Prometheus, Grafana, Datadog, New Relic), 롤백 이벤트 추적 등을 통해 파악한다. 복구 시간은 인시던트 타임라인, 알림 시스템 로그, SLA/SLO 대시보드를 통해 측정한다.

시중에는 Sleuth, LinearB, Haystack 같은 DORA 메트릭스 전문 플랫폼도 있고, Datadog 같은 통합 모니터링 도구도 있다. Grafana와 Prometheus로 자체 구축할 수도 있고, Port나 Backstage 같은 Internal Developer Portal을 통해 메트릭스를 통합할 수도 있다.

흔한 안티패턴들

DORA 메트릭스를 도입하는 조직들이 자주 빠지는 함정들이 있다. 첫 번째는 메트릭스를 개인 평가에 사용하는 것이다. 이렇게 되면 게임화가 발생한다. 의미 없는 커밋을 자주 해서 배포 빈도를 높이거나, 큰 변경사항을 억지로 작게 쪼개서 리드 타임을 조작하거나, 실패를 보고하지 않아 변경 실패율이 왜곡되는 현상이 나타난다. DORA 연구자들은 이 메트릭스가 팀 및 시스템 수준의 개선 영역을 파악하는 도구여야 한다고 강조한다. 개인이 아니라 프로세스를 개선하는 데 초점을 맞춰야 한다는 것이다.

두 번째 안티패턴은 단일 메트릭에만 집중하는 것이다. 배포 빈도만 높이려고 하면 품질이 떨어질 수 있다. DORA가 4가지 핵심 메트릭스를 제시한 이유는 균형 때문이다. 속도(배포 빈도, 리드 타임)와 안정성(변경 실패율, 복구 시간)이 함께 개선되어야 한다. 조직의 성숙도에 따라 신뢰성과 재작업률도 추가로 측정할 수 있다.

세 번째는 맥락 없이 벤치마크만 추구하는 것이다. “우리도 하루에 여러 번 배포해야 해!“라는 목표만 세우고 현재 상태와 제약사항을 무시하는 경우다. 업계 사례를 보면 현재 상태를 측정하는 것부터 시작해서 기준선을 설정하고, 점진적 개선 목표를 세우는 것이 효과적이다. 조직의 맥락, 즉 레거시 시스템이나 규제 요구사항 같은 것들을 고려하면서 개선을 막는 병목 지점을 파악하고 제거하는 접근이 필요하다.

네 번째는 도구만으로 해결하려는 시도다. “이 도구를 도입하면 메트릭스가 개선될 것이다"라는 생각은 실패로 이어지는 경우가 많다. 도구는 수단일 뿐이다. DORA 연구가 지속적으로 강조하는 것은 문화, 프로세스, 사람이 먼저 변해야 한다는 점이다. 자동화를 도입하기 전에 프로세스를 먼저 최적화하는 것이 선행되어야 한다.

개선 로드맵

DORA 메트릭스를 도입하는 조직들은 일반적으로 단계적 접근을 취한다. 첫 단계는 측정을 시작하는 것이다. 수동으로라도 현재 상태를 파악하고 기준선을 설정한 다음, 측정 자동화 계획을 수립하는 단계다.

다음으로 병목 지점을 파악하는 단계가 온다. 리드 타임이 긴 이유를 분석한다. 수동 테스트 때문인가, 느린 빌드 때문인가, 승인 프로세스 때문인가? 배포 빈도가 낮은 이유는 무엇인가? 실패가 자주 발생하는 영역은 어디인가?

그런 다음 자동화와 프로세스 개선 단계로 진입한다. CI/CD 파이프라인을 구축하거나 개선하고, 자동화 테스트를 확대하며, 코드 리뷰 프로세스를 효율화하고, 배포를 자동화하는 단계다.

하지만 DORA 연구는 기술적 개선만으로는 부족하다는 것을 보여준다. 문화 개선이 필요하다. 심리적 안정감을 조성하고, 비난하지 않는 사후 분석 문화를 도입하며, 지속적 학습과 개선 문화를 만들고, 팀 권한을 강화하는 것이 함께 이뤄져야 한다.

마지막은 지속적 모니터링과 최적화 단계다. 대시보드를 통해 실시간으로 모니터링하고, 정기적으로 회고하며 개선하고, 새로운 병목 지점을 식별하고 제거하는 과정을 반복하는 것이다.

서버리스 환경에서의 적용

서버리스 아키텍처는 DORA 메트릭스 개선에 유리한 특성을 가지고 있다. 인프라 관리 부담이 감소하면서 배포 속도가 향상되고, 함수 단위 배포로 변경 범위가 최소화되며, 자동 스케일링이 복구 시간 단축에 기여하고, 이벤트 기반 아키텍처와 느슨한 결합 덕분에 변경 실패율이 낮아진다.

물론 도전 과제도 있다. 분산 시스템의 추적이 어렵고, 콜드 스타트로 인한 성능 일관성 이슈가 있으며, 여러 서비스 간 의존성 관리가 복잡하다. 하지만 AWS X-Ray나 CloudWatch Logs Insights를 활용하고, Lambda 버전과 별칭을 활용한 배포 추적, EventBridge와 Step Functions의 실행 로그 분석, Port나 Backstage 같은 Internal Developer Portal을 통한 통합 뷰 등으로 이러한 문제들을 해결할 수 있다.

결론

DORA 메트릭스는 단순한 숫자가 아니다. 조직의 소프트웨어 전달 능력을 나타내는 건강 지표다. 10년 이상의 실증 연구가 보여주는 것은 명확하다. 측정 가능한 지표를 통해 개선 방향을 찾을 수 있고, 속도와 안정성이라는 두 마리 토끼를 모두 잡을 수 있다는 것이다.

DORA 연구가 강조하는 핵심은 균형이다. 속도만 추구하면 안정성이 무너지고, 안정성만 추구하면 경쟁력을 잃는다는 전통적 믿음은 틀렸다. 실제 데이터는 정반대를 보여준다. 고성과 조직은 두 가지 모두에서 뛰어나며, 이는 기술적 실천과 조직 문화가 함께 작용한 결과다.

중요한 것은 벤치마크 그 자체가 아니라 지속적인 개선이다. 엘리트 팀의 수치를 목표로 삼는 것도 좋지만, 조직의 맥락과 현실을 무시해서는 안 된다. 자신의 과거와 비교하며 점진적으로 나아가는 것이 실질적인 접근이다. DORA 메트릭스는 그 여정을 안내하는 나침반 역할을 한다.

References