릴리스 데이터로 계산하고 서비스별로 나눠 보는 DORA 메트릭

대부분의 엔지니어링 팀은 무엇을 배포했는지는 말할 수 있습니다. 하지만 얼마나 빨리 배포했는지, 얼마나 자주 장애가 났는지, 장애가 났을 때 복구에 얼마나 걸렸는지 말할 수 있는 팀은 거의 없습니다. 배포 횟수는 있습니다. 품질 신호가 없을 뿐입니다.

이 사각지대가 생기는 이유는 딜리버리 성과와 아키텍처 문서가 늘 서로 다른 세계에 있었기 때문입니다. CI/CD 도구는 파이프라인을 압니다. 아키텍처 도구는 시스템을 압니다. 둘 다 정말 중요한 질문, 즉 "우리 팀은 소프트웨어를 더 잘 딜리버리하고 있는가?"에 답할 만큼은 알지 못합니다.

DORA 메트릭은 그 간극을 메웁니다 — 그리고 Archyl은 이제 릴리스 데이터에서 이를 자동으로 계산합니다. 이 글은 그 동작 방식을 다룹니다. 애초에 딜리버리 메트릭이 왜 아키텍처 옆에 있어야 하는지는 아키텍처 팀을 위한 DORA 메트릭을 참고하세요.

중요한 네 가지 메트릭

2018년, DORA 팀(DevOps Research and Assessment, 현재 Google Cloud 소속)은 네 가지 특정 메트릭이 다른 무엇보다도 소프트웨어 딜리버리 성과를 잘 예측한다는 연구를 발표했습니다. 이후 이 메트릭들은 엔지니어링 효과를 측정하는 업계 표준이 되었습니다:

배포 빈도(Deployment Frequency) — 팀이 프로덕션에 얼마나 자주 배포하는가. 엘리트 팀은 필요할 때마다, 하루에도 여러 번 배포합니다. 성과가 낮은 팀은 한 달에 한 번에서 여섯 달에 한 번 사이로 배포합니다.

변경 리드 타임(Lead Time for Changes) — 코드 커밋부터 프로덕션 배포까지 얼마나 걸리는가. 엘리트 팀은 이를 시간 단위로 잽니다. 성과가 낮은 팀은 월 단위입니다.

변경 실패율(Change Failure Rate) — 배포 중 몇 퍼센트가 프로덕션 장애를 일으키는가(핫픽스, 롤백, 패치가 필요한 경우). 엘리트 팀은 5% 미만을 유지합니다. 성과가 낮은 팀은 46%를 넘습니다.

평균 복구 시간(MTTR) — 프로덕션 장애가 발생하면 복구하는 데 얼마나 걸리는가. 엘리트 팀은 한 시간 안에 서비스를 복구합니다. 성과가 낮은 팀은 일주일에서 한 달이 걸립니다.

DORA의 힘은 어느 한 메트릭이 아니라 네 가지를 함께 보는 데 있습니다. 하루에 열 번 배포하지만 절반은 프로덕션을 망가뜨리는 팀은 잘하고 있는 것이 아닙니다. 장애는 없지만 분기에 한 번 배포하는 팀은 지나치게 몸을 사리고 있습니다. 네 가지 메트릭은 속도와 안정성을 모두 보상하는 균형 잡힌 스코어카드를 만듭니다.

Archyl의 DORA: 릴리스 데이터 위에 구축

DORA 메트릭에 대해 한 가지 짚어 둘 점이 있습니다. 릴리스를 추적하고 있다면 원시 데이터는 이미 존재한다는 것입니다. 모든 릴리스에는 타임스탬프, 상태, 환경이 있습니다. 네 가지 메트릭을 모두 자동으로 계산하기에 충분합니다.

GitHub Actions, 웹훅, REST API 중 무엇을 통해서든 Archyl의 릴리스 관리를 사용해 왔다면, 데이터는 이미 있습니다. 우리는 계산만 하면 되었습니다.

배포 빈도는 주어진 기간 동안 프로덕션에 성공한 배포 횟수로 계산합니다. 최근 30일 동안 프로덕션에 45개의 릴리스를 배포했다면, 배포 빈도는 하루 1.5회입니다.

변경 리드 타임은 릴리스가 생성된 시점(가능하면 커밋 타임스탬프)부터 프로덕션 배포에 성공하기까지의 시간입니다. Archyl은 해당 기간의 모든 릴리스에 대한 중앙값을 계산합니다.

변경 실패율은 상태가 Failed 또는 Rolled Back인 릴리스가 전체 배포에서 차지하는 비율입니다. 40번 배포했고 그중 3번이 롤백되었다면 CFR은 7.5%입니다.

평균 복구 시간은 실패한 배포부터 같은 환경에 대한 다음 성공 배포까지의 시간을 측정합니다. 팀이 인시던트에서 얼마나 빨리 회복하는지를 포착합니다.

네 가지 메트릭은 모두 자동으로 계산됩니다. 설정도, 수동 입력도 필요 없습니다. 릴리스가 Archyl로 들어오고 있다면 DORA 메트릭은 이미 그곳에 있습니다.

DORA 스코어카드

각 메트릭은 DORA 연구에서 확립된 벤치마크를 기준으로 네 가지 성과 수준 중 하나로 분류됩니다:

  • Elite — 최상위 성과. 전 세계 엔지니어링 팀 중 최상위권에 속합니다.
  • High — 높은 성과. 대부분의 팀보다 앞서 있지만 개선의 여지가 있습니다.
  • Medium — 평균적인 성과. 개선할 영역이 분명히 있습니다.
  • Low — 평균 이하. 이 메트릭들은 딜리버리 파이프라인의 어느 부분에 관심이 필요한지 보여 줍니다.

스코어카드는 한눈에 보는 뷰를 제공합니다. 카드 네 장, 메트릭 네 개, 수준 네 가지. 각 카드에는 현재 값, 색상으로 표시된 성과 수준, 그리고 그 수준이 무엇을 의미하는지에 대한 짧은 설명이 표시됩니다. DORA 벤치마크를 외울 필요가 없습니다 — 스코어카드가 숫자를 해석해 줍니다.

전체 성과 수준은 네 가지 메트릭의 조합으로 계산됩니다. 메트릭 세 개가 Elite이고 하나가 High라면, 전체적으로 Elite 수준의 성과입니다.

추세 차트: 위치보다 방향이 중요하다

DORA 메트릭의 스냅샷은 지금 어디에 있는지 알려 줍니다. 추세는 어디로 가고 있는지 알려 줍니다. DORA 대시보드에는 각 메트릭을 시간에 따라 그린 추세 차트가 있어서, 상황이 나아지고 있는지, 안정적인지, 나빠지고 있는지 볼 수 있습니다.

기간(7일, 30일, 90일 또는 사용자 지정 범위)을 선택하면 추세 차트가 궤적을 보여 줍니다. 배포 빈도는 꾸준히 오르고 있을 수 있습니다. 리드 타임은 대규모 리팩터링 이후 급증했다가 지금은 회복 중일 수 있습니다. 변경 실패율은 건강한 수준에서 평탄할 수 있습니다.

추세는 메트릭을 성과 평가 도구에서 지속적 개선 도구로 바꿉니다. DORA를 분기에 한 번 확인하고 보고서에 넣어 두는 것이 아닙니다. 매주 추세를 보고, 리드 타임이 조금씩 늘어나는 것을 알아차리고, 문제가 되기 전에 조사하는 것입니다.

아키텍처 단위로 범위 지정

Archyl은 여러분의 C4 모델을 알고 있으므로, DORA 메트릭이 프로젝트 전체 집계에 머물지 않습니다. 특정 시스템이나 컨테이너로 메트릭의 범위를 좁힐 수 있습니다.

Payment Gateway만의 배포 빈도를 알고 싶으신가요? 그 시스템으로 필터링하세요. Notification Service의 변경 실패율이 Account API보다 높은지 궁금하신가요? 나란히 비교하세요.

바로 이 지점에서 아키텍처를 인식하는 메트릭이 진정으로 유용해집니다. 프로젝트 전체 MTTR이 두 시간이라면 훌륭해 보일 수 있습니다 — API Gateway는 15분 만에 복구되고 Billing Service는 18시간이 걸린다는 것을 알기 전까지는요. 범위를 좁힌 메트릭은 평균이 가리는 이상치를 드러냅니다.

조직 전체 DORA 개요

여러 프로젝트를 관리하는 엔지니어링 리더를 위해, 조직 수준 DORA 개요는 워크스페이스의 모든 프로젝트를 한눈에 조망하게 해 줍니다.

개요에는 전체 성과 수준을 보여 주는 요약 바와 프로젝트 카드 그리드가 표시되며, 각 카드는 네 가지 DORA 메트릭과 각각의 수준을 보여 줍니다. 어떤 프로젝트가 Elite 수준이고 어떤 프로젝트가 어려움을 겪고 있는지 즉시 알 수 있습니다.

이것은 팀끼리 순위를 매기려는 것이 아닙니다. 어디에 투자할지 파악하려는 것입니다. 다른 프로젝트는 안정적인데 한 프로젝트의 리드 타임만 오르고 있다면, 조사해 볼 가치가 있는 신호입니다. 변경 실패율이 전반적으로 높다면, 문제는 구조적인 것 — 공유 인프라, 테스트 공백, 배포 도구 — 일 수 있습니다.

조직 뷰는 프로젝트 뷰와 같은 기간 선택기를 사용하므로, 프로젝트 간 비교 시 기간을 맞출 수 있습니다.

피드백 루프

DORA 메트릭은 피드백 루프의 일부로 쓸 때 가장 효과적입니다. 팀들이 효과적으로 활용하는 방식은 다음과 같습니다:

  1. 릴리스 추적 설정 — GitHub Actions, 웹훅 또는 REST API로 CI/CD 파이프라인을 Archyl에 연결합니다. 릴리스가 자동으로 들어오기 시작합니다.

  2. 기준선 설정 — 몇 주 분량의 데이터가 쌓이면 DORA 스코어카드를 확인합니다. 이것이 오늘의 현재 위치입니다. 평가하지 말고 기록만 하세요.

  3. 추세 관찰 — 매주 확인합니다. 메트릭이 올바른 방향으로 움직이고 있나요? 안정적이라면 괜찮습니다. 나빠지고 있다면 신호입니다.

  4. 이상 징후 조사 — 메트릭이 변하면 개별 시스템으로 범위를 좁힙니다. 프로젝트 전체의 변화는 한두 개의 서비스 때문인 경우가 많습니다.

  5. 반복 개선 — 딜리버리 프로세스를 바꾸고 메트릭이 어떻게 반응하는지 지켜봅니다. 코드 리뷰가 빨라지면 리드 타임이 줄어듭니다. 테스트 커버리지가 좋아지면 변경 실패율이 낮아집니다. 피처 플래그는 MTTR을 줄입니다.

DORA 연구의 핵심 통찰은 이 메트릭들이 목표가 아니라 결과라는 것입니다. 배포를 더 많이 해서 배포 빈도가 개선되는 것이 아닙니다 — 배포를 느리거나 위험하게 만드는 마찰을 제거해서 개선되는 것입니다. 메트릭은 프로세스 개선이 실제로 효과가 있는지 알려 줍니다.

점들을 연결하기

DORA 메트릭은 의도만이 아니라 현실을 반영하는 아키텍처 문서라는 Archyl의 접근 방식에 더해진 최신 조각입니다.

C4 다이어그램은 구조를 보여 줍니다. API 계약은 인터페이스를 보여 줍니다. ADR은 결정을 보여 줍니다. 릴리스 관리는 무엇이 배포되었는지 보여 줍니다. 그리고 이제 DORA 메트릭은 딜리버리 체계가 얼마나 잘 돌아가고 있는지 보여 줍니다.

각 레이어는 앞의 레이어에 컨텍스트를 더합니다. 다이어그램 위의 시스템은 더 이상 화살표가 달린 상자가 아닙니다. 정의된 API, 설계 뒤에 있는 문서화된 결정, 배포 이력, 그리고 측정 가능한 딜리버리 성과를 가진 서비스입니다. 그것이 다이어그램과 살아 있는 아키텍처 플랫폼의 차이입니다.

시작하기

이미 Archyl에서 릴리스를 추적하고 있다면 DORA 메트릭을 지금 바로 사용할 수 있습니다. 프로젝트의 Releases 페이지로 이동해 Metrics 탭으로 전환하세요. 스코어카드와 추세 차트가 이미 채워져 있습니다.

아직 릴리스 추적을 설정하지 않았다면 거기서 시작하세요. 릴리스 관리 가이드를 따라 CI/CD 파이프라인을 연결하고, 몇 주 분량의 배포 데이터가 쌓이면 Metrics 탭으로 돌아오세요.

조직 수준의 인사이트를 보려면 특정 프로젝트를 선택하지 않은 채 Releases 페이지를 열고 Metrics 탭으로 전환하세요. 개요에 워크스페이스의 모든 프로젝트와 각각의 DORA 점수가 표시됩니다.

아키텍처는 무엇이 존재하는지 압니다. 릴리스는 무엇이 배포되었는지 압니다. 이제 메트릭은 얼마나 잘 딜리버리하고 있는지 압니다.

릴리스 관리에서 배포 추적에 대해 더 알아보거나, Architecture Change Requests가 C4 모델에 구조화된 리뷰 워크플로우를 어떻게 가져오는지 살펴보세요.