본문으로 건너뛰기

DORA 메트릭

"우리 팀의 DevOps 역량은 어느 정도일까?" 이 질문에 객관적으로 답하기란 쉽지 않습니다. DORA 메트릭은 이런 고민을 해결해 줍니다. 전 세계 수천 개 팀의 데이터를 기반으로 만들어진 기준이라 객관적인 비교가 가능합니다.

DORA란?

DORA(DevOps Research and Assessment)는 Google Cloud의 DevOps 연구팀입니다. 이 팀은 매년 전 세계 수천 개의 IT 조직을 분석하여 "State of DevOps Report"를 발표합니다. DORA 메트릭은 이 연구의 핵심 결과물입니다.

DORA 메트릭 개요​

DORA 메트릭은 4가지 핵심 지표로 구성됩니다. 각 지표가 왜 중요한지 함께 알아보겠습니다.

  • 배포 빈도 (DF, Deployment Frequency): 프로덕션에 코드를 배포하는 횟수입니다. 자주 배포할수록 사용자에게 가치를 빠르게 전달할 수 있습니다.
  • 변경 리드 타임 (LT, Lead Time for Changes): 파이프라인의 source/build 시작 시각부터 deploy 완료 시각까지 걸리는 시간입니다. 짧을수록 시장 변화에 빠르게 대응할 수 있습니다.
  • 변경 실패율 (CFR, Change Failure Rate): 전체 deploy 단계 중 status=failed로 종료된 비율입니다. 낮을수록 품질이 좋고 안정적입니다.
  • 서비스 복구 시간 (MTTR, Mean Time to Restore): 장애 발생부터 복구까지의 시간입니다. 짧을수록 사용자 영향을 최소화할 수 있습니다.
왜 이 4가지일까요?

이 4가지 지표는 서로 균형을 이룹니다. 예를 들어, 배포 빈도만 높이려고 하면 실패율이 올라갈 수 있습니다. DORA 메트릭은 속도와 안정성을 모두 측정하여 진정한 DevOps 역량을 보여줍니다.

성능 등급 기준​

KIOPS는 실제 코드 기준으로 다음 임계값을 사용해 각 메트릭과 종합 등급(overallGrade)을 산출합니다. 단일 지표가 아래 어느 구간에 속하느냐로 등급이 결정되고, 모든 지표를 종합해 overallGrade가 정해집니다.

Elite (엘리트) 등급​

가장 높은 성능 등급으로, 세계적인 DevOps 조직이 달성하는 수준입니다.

  • DF: 1/일 이상 (하루 1회 이상)
  • LT: 1시간 이하
  • MTTR: 1시간 이하
  • CFR: 15% 미만

High (고성능) 등급​

대부분의 성숙한 DevOps 팀이 달성하는 수준입니다.

  • DF: 0.14/일 이상 (대략 주 1회)
  • LT: 1일 이하
  • MTTR: 1일 이하
  • CFR: 30% 미만

Medium (중간) 등급​

DevOps 여정을 시작한 팀이 일반적으로 해당하는 수준입니다.

  • DF: 0.033/일 이상 (대략 월 1회)
  • LT: 1주 이하
  • MTTR: 1일 이하
  • CFR: 45% 미만

Low (저성능) 등급​

위 어느 구간에도 들지 못하는 경우, 또는 CFR이 45% 이상인 경우입니다.

Low 등급이라면

Low 등급이라고 해서 좌절할 필요는 없습니다. 자동화와 프로세스 개선에 집중하면 빠르게 Medium, High 등급으로 올라갈 수 있습니다.

overallGrade 와 healthScore​

  • overallGrade: 4개 지표의 등급을 종합하여 Elite/High/Medium/Low 중 하나로 산출되는 종합 등급입니다.
  • healthScore (0~100): 4개 지표의 등급을 0~100 점수로 환산해 합산한 건강 점수입니다. 점수가 높을수록 우수합니다.

두 값은 모두 백엔드에서 계산되어 API로 제공되며, **[보안 분석]**의 [품질] 탭에 표시됩니다.

DORA 메트릭 확인하기​

KIOPS에서 DORA 메트릭은 [보안 분석] 페이지의 [품질] 탭에서 확인합니다.

진입 경로​

  1. [보안 분석] 페이지(/security)로 이동합니다.
  2. [품질] 탭(/security?area=quality)을 엽니다.
  3. 품질 탭에서 DORA 메트릭 4가지 지표와 등급, healthScore를 확인합니다.
대시보드 메인에 메트릭 패널은 없습니다

이전 가이드에서 안내했던 "대시보드 우측 상단 DORA 메트릭 패널"이나 "서비스 상세의 품질 관리 탭"은 더 이상 존재하지 않습니다. DORA 메트릭은 항상 **[보안 분석]**의 [품질] 탭에서 확인합니다.

서비스별 vs 시스템 전체 메트릭​

KIOPS는 DORA 메트릭을 두 가지 범위로 산출합니다.

  • 서비스별 (scope_type = service): 특정 서비스의 파이프라인만 집계합니다. [품질] 탭에 표시되는 값이 이에 해당합니다.
  • 시스템 전체 (scope_type = system): 시스템 전체 파이프라인을 집계한 값입니다. 조직 전체 DevOps 성과를 파악할 때 활용합니다.

두 범위의 값은 별도로 저장되므로, 특정 서비스의 등급이 낮다고 해서 시스템 전체 등급이 동일하게 낮은 것은 아닙니다.

일별 스냅샷 및 히스토리​

DORA 메트릭은 일별 스냅샷으로 저장되어 시간 흐름에 따른 변화를 조회할 수 있습니다.

  • 일별 스냅샷은 백엔드에 영속 저장됩니다.
  • 히스토리 조회 API를 통해 특정 기간의 DF/LT/CFR/MTTR 변화를 가져올 수 있습니다.
  • 시계열 시각화 UI 노출 위치는 환경에 따라 다를 수 있으므로, [품질] 탭의 안내를 따라주세요.

각 메트릭 상세​

각 메트릭이 무엇을 측정하고, 어떻게 개선할 수 있는지 자세히 알아보겠습니다.

배포 빈도 (DF, Deployment Frequency)​

성공한 deploy 단계의 일별/주별/월별 빈도를 측정합니다.

왜 배포 빈도가 중요한가요?

자주 배포할수록 사용자에게 새로운 기능과 버그 수정을 빠르게 전달할 수 있습니다. 작은 단위로 자주 배포하면 문제가 생겼을 때 원인을 찾기도 쉽습니다.

개선 방법:

  1. CI/CD 파이프라인 자동화

    • KIOPS의 Auto CI 기능을 활성화하면 코드 푸시 시 자동으로 빌드가 실행됩니다.

  2. 작은 단위로 자주 배포하는 문화 만들기

    • 대규모 기능을 작은 PR로 분리하세요.

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

KIOPS는 리드 타임을 파이프라인의 source/build 시작 시각부터 deploy 단계의 completed_at까지로 계산합니다.

주의: Git 커밋 시각을 사용하지 않습니다

일반적인 DORA 정의는 "커밋부터 배포까지"이지만, KIOPS는 파이프라인 시작 시각을 기준으로 합니다. 따라서 Git 커밋과 파이프라인 트리거 사이의 지연 시간은 LT 산정에 포함되지 않습니다.

개선 방법:

  1. 빌드 시간 최적화

    • Docker 레이어 캐싱을 활용하세요.
    • 불필요한 의존성을 제거하세요.

  2. 테스트 병렬 실행

    • 테스트를 병렬로 실행하면 CI 시간을 크게 단축할 수 있습니다.

  3. 승인 프로세스 간소화

    • 불필요한 배포 승인 단계가 있다면 제거를 고려하세요.

변경 실패율 (CFR, Change Failure Rate)​

KIOPS는 변경 실패율을 deploy 단계 중 status=failed로 종료된 비율로 계산합니다. 별도의 "롤백/핫픽스" 표식이 아니라 deploy 단계의 종료 상태가 기준입니다.

왜 실패율이 중요한가요?

실패율이 높으면 사용자 경험이 나빠지고, 팀의 시간도 낭비됩니다. 실패율을 낮추면 팀이 새로운 기능 개발에 더 집중할 수 있습니다.

개선 방법:

  1. 테스트 커버리지 80% 이상 유지

    • 자동화된 테스트가 많을수록 버그를 배포 전에 발견합니다.

  2. 철저한 코드 리뷰

    • 리뷰어 승인 없이는 머지할 수 없도록 설정하세요.

  3. 스테이징 환경에서 충분히 검증

    • 프로덕션 배포 전에 스테이징에서 최소 1일 이상 테스트하세요.

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

서비스에 장애가 발생한 시점부터 정상 복구까지 걸린 시간입니다.

왜 복구 시간이 중요한가요?

장애는 언제든 발생할 수 있습니다. 중요한 것은 얼마나 빨리 복구하느냐입니다. 복구 시간이 길면 사용자 이탈과 매출 손실로 이어집니다.

개선 방법:

  1. 모니터링과 알림 강화

    • 장애를 빠르게 감지할수록 빠르게 대응할 수 있습니다.

  2. 롤백 절차 자동화

    • 버튼 한 번으로 이전 버전으로 돌아갈 수 있게 준비하세요.

  3. 인시던트 대응 프로세스 문서화

    • 누가 무엇을 해야 하는지 미리 정해두면 혼란을 줄일 수 있습니다.

트렌드 분석​

숫자 하나만 보는 것보다 시간에 따른 변화를 보는 것이 더 중요합니다. 일별 스냅샷이 누적되면 개선 추이를 분석할 수 있습니다.

히스토리 조회​

KIOPS는 DORA 메트릭의 일별 스냅샷을 백엔드에 저장합니다. 히스토리 조회 API를 활용하면 일별/주별/월별 추세 데이터를 가져와 외부 분석 도구나 자체 대시보드에서 활용할 수 있습니다.

트렌드 분석 팁

주간 회의에서 DORA 메트릭 추세를 함께 리뷰하세요. "지난주보다 나아졌다/나빠졌다"를 확인하면 개선 방향을 잡기 쉽습니다.

벤치마크 비교​

KIOPS는 Google Cloud의 State of DevOps Report 연구 결과를 참고한 임계값을 기준으로 등급을 표시합니다. 이를 통해 전 세계 IT 조직과의 비교 관점에서 우리 팀의 위치를 가늠할 수 있습니다.

실제 사용 시나리오​

실제로 어떻게 DORA 메트릭을 개선할 수 있는지 구체적인 시나리오를 살펴보겠습니다.

시나리오 1: 배포 빈도 Low에서 Medium 등급으로​

상황

월 2~3회 배포하고 있어 Low 등급입니다. "배포가 무섭다", "배포는 큰일"이라는 인식이 팀에 있습니다.

개선 계획:

  • 1단계 - KIOPS Auto CI 활성화: 코드 푸시 시 자동 빌드가 실행되어 수동 작업이 제거됩니다.
  • 2단계 - 대규모 기능을 작은 PR로 분리: 작은 단위로 자주 머지가 가능해집니다.
  • 3단계 - 코드 리뷰 24시간 이내 완료: 병목 구간이 해소됩니다.
  • 4단계 - 수동 승인 단계 최소화: 배포 장벽이 낮아집니다.

결과: 주 1회 이상 배포가 가능해져 DF 0.14/일 이상으로 Medium → High 등급에 근접합니다.

시나리오 2: 변경 실패율 30%에서 15% 미만으로​

상황

deploy 단계 실패율이 30%로 High 임계값(30%)에 걸쳐 있습니다. 배포할 때마다 긴장됩니다.

개선 계획:

  • 1단계 - 테스트 커버리지 50%에서 80%로: 버그를 배포 전에 발견할 수 있습니다.
  • 2단계 - SAST/SCA 스캔 필수 적용: 보안 취약점과 버그를 사전에 차단합니다.
  • 3단계 - 스테이징에서 최소 1일 검증: 프로덕션 문제를 사전에 발견할 수 있습니다.

결과: CFR이 15% 미만으로 떨어져 Elite 등급에 근접합니다.

작은 것부터 시작하세요

모든 것을 한 번에 바꾸려고 하지 마세요. 2주 스프린트마다 하나씩 개선해 보세요.

베스트 프랙티스​

DORA 메트릭을 개선하기 위한 베스트 프랙티스를 팀 문화, 기술, 프로세스 세 가지 관점에서 정리했습니다.

팀 문화 측면​

  • 작은 단위로 자주 배포하는 문화를 만드세요.
  • 실패를 학습 기회로 활용하세요. Post-mortem(사후 분석)을 통해 재발을 방지하세요.
  • 배포 자동화에 지속적으로 투자하세요.

기술적 측면​

  • CI/CD 파이프라인 최적화로 빌드/배포 시간 단축
  • 자동화된 테스트로 회귀 버그 사전 발견
  • 모니터링과 알림 강화로 문제 빠르게 인지
  • 롤백 절차 자동화로 장애 복구 시간 단축

프로세스 측면​

  • 불필요한 배포 승인 단계 간소화
  • 인시던트 대응 프로세스 문서화
  • 주간 또는 월간 DORA 메트릭 정기 리뷰
DORA 메트릭 리뷰 미팅

주간 팀 미팅에서 5분만 할애하여 DORA 메트릭을 함께 확인하세요.

관련 가이드​