배포를 추적하고 있습니다. 하지만 팀이 더 빨라지고 있는지 알고 계신가요? Archyl은 이제 DORA 메트릭 — Deployment Frequency, Lead Time, Change Failure Rate, Mean Time to Restore — 을 릴리스 이력에서 직접, 프로젝트 및 조직 수준에서 계산합니다.

DORA 메트릭: 아키텍처 전반의 엔지니어링 성과 측정

대부분의 엔지니어링 팀은 무엇을 출시했는지 말할 수 있습니다. 하지만 얼마나 빠르게 출시했는지, 얼마나 자주 장애가 발생했는지, 장애 발생 시 복구에 얼마나 걸렸는지를 말할 수 있는 팀은 극소수입니다. 배포 횟수는 있습니다. 품질 신호는 없습니다.

이 사각지대는 딜리버리 성과와 아키텍처 문서가 항상 별개의 세계에 존재했기 때문입니다. CI/CD 도구는 파이프라인을 알고, 아키텍처 도구는 시스템을 압니다. 하지만 정말 중요한 질문에 답하기에는 둘 다 충분하지 않습니다: 팀이 소프트웨어 딜리버리를 개선하고 있는가?

DORA 메트릭이 그 격차를 해소합니다 — 그리고 Archyl은 이제 릴리스 데이터에서 자동으로 이를 계산합니다.

중요한 네 가지 메트릭

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

Deployment Frequency — 팀이 얼마나 자주 프로덕션에 배포하는지. Elite 팀은 하루에 여러 번 온디맨드로 배포합니다. Low 팀은 한 달에 한 번에서 6개월에 한 번 사이로 배포합니다.

Lead Time for Changes — 코드 커밋에서 프로덕션 배포까지 걸리는 시간. Elite 팀은 이것을 시간 단위로 측정합니다. Low 팀은 월 단위로 측정합니다.

Change Failure Rate — 배포의 몇 퍼센트가 프로덕션에서 장애를 일으키는지(핫픽스, 롤백 또는 패치가 필요한). Elite 팀은 5% 미만을 유지합니다. Low 팀은 46%를 초과합니다.

Mean Time to Restore (MTTR) — 프로덕션 장애가 발생했을 때 복구까지 얼마나 걸리는지. Elite 팀은 1시간 이내에 서비스를 복구합니다. Low 팀은 1주일에서 1개월 사이가 걸립니다.

DORA를 강력하게 만드는 것은 단일 메트릭이 아닙니다 — 네 가지의 조합입니다. 하루에 10번 배포하지만 프로덕션을 절반의 시간 동안 깨뜨리는 팀은 잘하고 있는 것이 아닙니다. 장애가 없지만 분기에 한 번만 배포하는 팀은 너무 안전하게 플레이하고 있습니다. 네 가지 메트릭은 속도와 안정성 모두를 보상하는 균형 잡힌 스코어카드를 만듭니다.

Archyl의 DORA: 릴리스 데이터를 기반으로 구축

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

Archyl의 릴리스 관리를 사용하고 있다면 — GitHub Actions, Webhook 또는 REST API를 통해서든 — 이미 데이터가 있습니다. 계산만 하면 됐습니다.

Deployment Frequency는 주어진 시간 윈도우 동안의 성공적인 프로덕션 배포 수에서 계산됩니다. 지난 30일 동안 프로덕션에 45개의 릴리스를 출시했다면, 배포 빈도는 하루 1.5입니다.

Lead Time for Changes는 릴리스 생성(또는 사용 가능한 경우 커밋 타임스탬프)과 프로덕션으로의 성공적인 배포 사이의 시간입니다. Archyl은 해당 기간의 모든 릴리스에 대한 중앙값을 계산합니다.

Change Failure Rate는 Failed 또는 Rolled Back 상태의 릴리스를 총 배포에 대한 비율로 봅니다. 40번 배포하고 3번이 롤백되었다면, CFR은 7.5%입니다.

Mean Time to Restore는 실패한 배포와 동일 환경에서의 다음 성공적인 배포 사이의 시간을 측정합니다. 이는 팀이 인시던트에서 얼마나 빨리 복구하는지를 포착합니다.

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

DORA 스코어카드

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

Elite — 최상위 성과. 글로벌 엔지니어링 팀 중 최상위 브라켓에 있습니다.
High — 강력한 성과. 대부분의 팀보다 앞서 있지만 개선의 여지가 있습니다.
Medium — 평균 성과. 명확한 개선 영역이 있습니다.
Low — 평균 이하. 이 메트릭은 딜리버리 파이프라인에서 주의가 필요한 곳을 강조합니다.

스코어카드는 한눈에 보이는 뷰를 제공합니다: 네 장의 카드, 네 가지 메트릭, 네 가지 레벨. 각 카드는 현재 값, 색상 인디케이터가 있는 성과 레벨, 그리고 해당 레벨이 의미하는 바에 대한 간략한 설명을 표시합니다. DORA 벤치마크를 외울 필요가 없습니다 — 스코어카드가 숫자를 해석해 줍니다.

전체 성과 레벨은 네 가지 메트릭 모두의 조합에서 계산됩니다. 세 가지 메트릭이 Elite이고 하나가 High라면, 전체적으로 Elite 레벨로 수행하고 있는 것입니다.

트렌드 차트: 위치보다 방향이 중요

DORA 메트릭의 단일 스냅샷은 현재 위치를 알려줍니다. 트렌드는 향하는 곳을 알려줍니다. DORA 대시보드에는 각 메트릭을 시간에 따라 플롯하는 트렌드 차트가 포함되어 있어, 상황이 개선되고 있는지, 안정적인지, 악화되고 있는지 확인할 수 있습니다.

기간을 선택하세요 — 7일, 30일, 90일 또는 사용자 정의 범위 — 트렌드 차트가 궤적을 보여줍니다. 배포 빈도가 꾸준히 올라가고 있을 수 있습니다. 리드 타임이 대규모 리팩토링 후 스파이크를 겪었지만 회복 중일 수 있습니다. Change Failure Rate가 건강한 수준에서 안정적일 수 있습니다.

트렌드는 메트릭을 성과 리뷰 도구에서 지속적 개선 도구로 바꾸는 것입니다. DORA를 분기에 한 번 확인하고 보고서에 정리하지 않습니다. 매주 트렌드를 관찰하고, 리드 타임이 올라가는 것을 알아차리고, 문제가 되기 전에 조사합니다.

아키텍처에 맞춤

Archyl은 C4 모델을 알고 있기 때문에, DORA 메트릭은 프로젝트 전체 집계에 제한되지 않습니다. 특정 시스템이나 컨테이너에 메트릭을 스코프할 수 있습니다.

Payment Gateway만의 배포 빈도를 알고 싶으세요? 해당 시스템으로 필터링하세요. Notification Service가 Account API보다 Change Failure Rate가 높은지 궁금하세요? 나란히 비교하세요.

여기서 아키텍처를 인식하는 메트릭이 진정으로 유용해집니다. 프로젝트 전체 MTTR이 2시간이면 훌륭하게 들릴 수 있습니다 — API Gateway가 15분 만에 복구되고 Billing Service가 18시간 걸린다는 것을 깨달을 때까지. 스코프된 메트릭은 평균이 숨기는 이상치를 드러냅니다.

조직 전체 DORA 개요

여러 프로젝트를 관리하는 엔지니어링 리더를 위해, 조직 수준 DORA 개요는 워크스페이스의 모든 프로젝트에 대한 조감도를 제공합니다.

개요는 집계된 성과 레벨이 있는 요약 바와 프로젝트 카드 그리드를 보여줍니다 — 각각 네 가지 DORA 메트릭과 개별 레벨을 표시합니다. 어떤 프로젝트가 Elite 레벨에서 수행하고 있고 어떤 프로젝트가 어려움을 겪고 있는지 즉시 파악할 수 있습니다.

이것은 팀을 서로 순위 매기는 것이 아닙니다. 어디에 투자할지 식별하는 것입니다. 한 프로젝트의 리드 타임이 올라가는 반면 다른 프로젝트는 안정적이라면, 조사할 가치가 있는 신호입니다. Change Failure Rate가 전반적으로 높다면, 문제는 시스템적일 수 있습니다 — 공유 인프라, 테스트 갭 또는 배포 도구.

조직 뷰는 프로젝트 뷰와 동일한 기간 선택기를 사용하므로, 프로젝트 간 비교 시 시간 프레임을 정렬할 수 있습니다.

피드백 루프

DORA 메트릭은 피드백 루프의 일부로 가장 잘 작동합니다. 팀이 효과적으로 사용하는 방법은 다음과 같습니다:

릴리스 추적 설정 — GitHub Actions, Webhook 또는 REST API를 사용하여 CI/CD 파이프라인을 Archyl에 연결합니다. 릴리스가 자동으로 흘러들어오기 시작합니다.
기준선 확립 — 몇 주간의 데이터 후, DORA 스코어카드를 확인합니다. 이것이 현재 위치입니다. 판단하지 마세요 — 기록하세요.
트렌드 관찰 — 매주 확인합니다. 메트릭이 올바른 방향으로 움직이고 있나요? 안정은 괜찮습니다. 악화는 신호입니다.
이상 조사 — 메트릭이 변동하면, 개별 시스템으로 스코프합니다. 프로젝트 전체 변화는 종종 하나 또는 두 개의 서비스에 의해 주도됩니다.
반복 — 딜리버리 프로세스를 변경하고 메트릭의 반응을 관찰합니다. 더 빠른 코드 리뷰는 리드 타임을 줄입니다. 더 나은 테스트 커버리지는 Change Failure Rate를 줄입니다. 피처 플래그는 MTTR을 줄입니다.

DORA 연구의 핵심 인사이트는 이 메트릭이 결과이지 목표가 아니라는 것입니다. 배포 빈도를 더 많이 배포해서 개선하는 것이 아니라, 배포를 느리거나 위험하게 만드는 마찰을 제거함으로써 개선합니다. 메트릭은 프로세스 개선이 실제로 작동하는지 알려줍니다.

점 연결하기

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

C4 다이어그램은 구조를 보여줍니다. API 계약은 인터페이스를 보여줍니다. ADR은 결정을 보여줍니다. 릴리스 관리는 무엇이 출시되었는지 보여줍니다. 그리고 이제 DORA 메트릭은 딜리버리 머신이 얼마나 잘 작동하는지 보여줍니다.

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

시작하기

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

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

조직 수준 인사이트를 위해, 특정 프로젝트를 선택하지 않고 릴리스 페이지를 열고 메트릭 탭으로 전환하세요. 개요에 워크스페이스의 모든 프로젝트와 개별 DORA 점수가 표시됩니다.

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

릴리스 관리에서 배포 추적에 대해 자세히 알아보거나, 아키텍처 변경 요청이 C4 모델에 구조화된 리뷰 워크플로를 어떻게 가져오는지 탐색하세요.

DORA 메트릭: 아키텍처 전반의 엔지니어링 성과 측정 - Archyl Blog