[Daily morning study] DORA Metrics와 DevOps 성과 측정
#daily morning study
DORA Metrics란
DORA(DevOps Research and Assessment)는 Google이 인수한 연구 조직으로, 수천 개 팀을 대상으로 한 연구를 통해 소프트웨어 개발팀의 성과를 측정하는 4가지 핵심 지표를 정의했다. 이 지표들은 단순한 속도 측정을 넘어서 속도와 안정성의 균형을 평가한다.
4가지 핵심 지표
1. Deployment Frequency (배포 빈도)
얼마나 자주 프로덕션에 배포하는가를 측정한다.
| 성과 등급 | 배포 빈도 |
|---|---|
| Elite | 하루에 여러 번 |
| High | 하루 1회 ~ 주 1회 |
| Medium | 주 1회 ~ 월 1회 |
| Low | 월 1회 미만 |
배포 빈도가 높다는 것은 작은 변경을 자주 릴리즈한다는 뜻이다. 배치 크기가 작을수록 리스크가 줄고 문제 발생 시 원인 파악이 쉽다.
2. Lead Time for Changes (변경 리드 타임)
코드 커밋이 프로덕션에 반영되기까지 걸리는 시간이다.
Lead Time = 코드 커밋 시간 → 프로덕션 배포 시간
| 성과 등급 | 리드 타임 |
|---|---|
| Elite | 1시간 미만 |
| High | 하루 ~ 1주일 |
| Medium | 1주일 ~ 1개월 |
| Low | 1개월 초과 |
리드 타임이 짧을수록 피드백 루프가 빨라지고, 사용자 요구사항에 빠르게 대응할 수 있다.
3. Mean Time to Recovery, MTTR (평균 복구 시간)
장애가 발생했을 때 서비스를 복구하는 데 걸리는 평균 시간이다.
MTTR = 장애 감지 시간 + 진단 시간 + 수정/롤백 시간 + 검증 시간
| 성과 등급 | MTTR |
|---|---|
| Elite | 1시간 미만 |
| High | 하루 미만 |
| Medium | 하루 ~ 1주일 |
| Low | 1주일 초과 |
MTTR은 모니터링, 알림 체계, 롤백 자동화 수준을 반영한다.
4. Change Failure Rate (변경 실패율)
배포한 변경 사항 중 프로덕션 장애를 유발한 비율이다.
Change Failure Rate = 실패한 배포 수 / 전체 배포 수 × 100%
| 성과 등급 | 변경 실패율 |
|---|---|
| Elite | 0% ~ 15% |
| High | 0% ~ 15% |
| Medium | 16% ~ 45% |
| Low | 46% 이상 |
속도 vs 안정성 트레이드오프
직관적으로는 “빠르게 배포하면 더 많이 망가진다”고 생각하기 쉽다. 하지만 DORA 연구 결과는 반대였다.
Elite 팀은 배포 빈도가 높으면서도 변경 실패율이 낮고 MTTR도 짧다.
이것이 가능한 이유:
- 작은 배치 크기 → 변경 범위가 명확 → 디버깅 용이
- 자동화된 테스트 → 릴리즈 전 문제 감지
- 자동 롤백 → 빠른 복구
- 지속적인 배포 파이프라인 → 사람의 실수 감소
DORA Metrics 수집 방법
배포 빈도 측정
CI/CD 파이프라인 로그를 활용한다.
# GitHub Actions 예시 - 배포 완료 이벤트 기록
- name: Record deployment
run: |
curl -X POST https://metrics-api/deployments \
-d '{"timestamp": "'$(date -u +%Y-%m-%dT%H:%M:%SZ)'", "env": "production", "status": "success"}'
리드 타임 측정
# 커밋 시간과 배포 시간 차이 계산
def calculate_lead_time(commit_sha, deployment_time):
commit_time = get_commit_timestamp(commit_sha)
lead_time = deployment_time - commit_time
return lead_time.total_seconds() / 3600 # 시간 단위
MTTR 측정
장애 티켓의 created_at과 resolved_at 차이를 계산한다.
def calculate_mttr(incidents):
total_recovery_time = sum(
(i['resolved_at'] - i['created_at']).total_seconds()
for i in incidents
)
return total_recovery_time / len(incidents) / 3600
관련 도구
| 도구 | 역할 |
|---|---|
| Four Keys (Google) | DORA 지표 자동 수집 오픈소스 |
| LinearB | 개발 지표 대시보드 |
| Sleuth | DORA 지표 추적 SaaS |
| Datadog DORA | Datadog 내 DORA 지표 통합 |
| GitHub Insights | PR 사이클 타임 등 개발 지표 |
Four Keys 프로젝트
Google이 오픈소스로 공개한 DORA 지표 수집 파이프라인이다.
GitHub/GitLab Webhook
↓
Cloud Pub/Sub
↓
Cloud Functions
↓
BigQuery (데이터 저장)
↓
Looker Studio 대시보드
이벤트 기반으로 커밋, 배포, 인시던트 데이터를 수집하고 BigQuery에 저장한 뒤 대시보드로 시각화한다.
DORA 지표 개선 전략
Deployment Frequency 높이기
- 기능 플래그(Feature Flag)로 코드와 릴리즈를 분리
- 작은 PR 단위로 작업 분리
- CI 파이프라인 속도 개선 (캐싱, 병렬 테스트)
Lead Time 줄이기
- 코드 리뷰 프로세스 개선 (Draft PR 활용, 리뷰어 자동 지정)
- 자동화된 테스트 커버리지 확대
- 머지 큐(Merge Queue) 도입으로 대기 시간 감소
MTTR 줄이기
- 체계적인 모니터링과 알림 (알림 피로 방지를 위한 임계값 조정)
- Runbook 자동화
- 카나리 배포 / 블루-그린 배포로 빠른 롤백 체계 구축
- 포스트모템 문화로 재발 방지
Change Failure Rate 줄이기
- 테스트 자동화 (단위, 통합, E2E 테스트)
- 스테이징 환경 완성도 향상
- 점진적 배포 (카나리 / 트래픽 가중치 조절)
5번째 지표: Reliability
2021년 DORA 연구에서 Reliability(신뢰성)가 5번째 지표로 추가됐다. SLO(Service Level Objective) 달성 여부로 측정하며, 엘리트 팀은 SLO를 항상 충족하거나 초과 달성한다.
Availability SLO: 99.9% (월 최대 다운타임 43분)
Latency SLO: p99 응답 시간 < 500ms
Error Rate SLO: 0.1% 미만
핵심 정리
- DORA 4가지 지표: Deployment Frequency, Lead Time, MTTR, Change Failure Rate
- 고성과 팀은 속도와 안정성이 동시에 높다 — 트레이드오프가 아니다
- 지표 개선의 핵심은 자동화, 작은 배치 크기, 빠른 피드백 루프
- 지표 자체가 목표가 되지 않도록 주의해야 한다 (Goodhart’s Law)
