# DORA 지표란? 소프트웨어 배포 성능 측정의 5가지 지표

URL: https://upstreamapi.com/ko/journal/dora-metrics-guide
Type: blog
Locale: ko
Published: 2026-10-03
Updated: 2026-10-03

---

> DORA 지표는 소프트웨어 배포의 5가지 측정값입니다. 처리량과 안정성을 함께 읽어야 하며, 제대로 사용하면 병목을 찾을 수 있습니다.

## DORA 지표란?

DORA 지표는 소프트웨어 배포의 다섯 가지 측정값입니다. 변경 리드 타임, 배포 빈도, 장애 복구 시간, 변경 실패율, 배포 재작업율입니다. 처음 세 개는 처리량을 설명하고, 마지막 두 개는 불안정성을 설명합니다. 함께 보면 변경이 프로덕션에 도달하는 속도와 그 변경들이 얼마나 자주 문제를 일으키는지 알 수 있습니다. 제대로 사용하면 병목을 가리킵니다. 잘못 사용하면 팀이 게임화하기를 배우는 보고카드가 됩니다.

## 숫자가 어디서 나왔는가, 그리고 왜 이 용어가 정착했는가

분기 검토에 앉은 플랫폼 리드가 있습니다. CTO가 한 가지 질문을 합니다. 지난해보다 더 빨리 배포하고 있는가, 그리고 덜 깨고 있는가? 공통된 용어가 없으면 답변은 일화들의 더미가 됩니다. DORA 지표는 이 일화들을 여러분이 이미 운영 중인 시스템에서 뽑을 수 있는 네 개 또는 다섯 개의 숫자로 바꾸기 위해 존재합니다.

이름은 DevOps Research and Assessment에서 나왔습니다. 이것은 엔지니어링 팀을 조사하고 그들의 배포 관행과 조직 성과를 연관지으려고 수년간 노력한 연구 프로그램입니다. 이제 Google Cloud의 일부이며, 발견 사항은 매해 [DORA 연구 프로그램](https://dora.dev/research/)에서 발행됩니다. '액셀러레이트'라는 책이 원래의 네 가지 지표를 대중화했습니다. 이후 프레임워크가 개정되었고, 이 개정은 대부분의 블로그 포스트가 인정하는 것보다 훨씬 더 중요합니다.

자주 잘못 이해되는 부분이 있습니다. 지표는 리더보드로 만들어지지 않았습니다. 통계적 발견에서 나왔습니다. 속도에서 잘 나온 팀들도 안정성에서 잘 나왔습니다. 속도와 안전은 트레이드오프가 아니었고, 함께 움직였습니다. 이것은 많은 팀 간의 상관관계에 대한 주장이지, 여러분의 팀에 대한 목표가 아닙니다.

## 다섯 가지 지표, 온콜 엔지니어가 정의하는 방식으로

현재의 [공식 DORA 지표 가이드](https://dora.dev/guides/dora-metrics/)의 정의는 두 그룹으로 나뉩니다. 특정 서비스를 염두에 두고 읽으세요. 모든 정의는 여러분이 이를 "회사 전체"에 적용하면 제대로 작동하지 않기 때문입니다.

**변경 리드 타임.** 커밋에서 그 커밋이 프로덕션에서 실행될 때까지의 시간입니다. 티켓이 열린 시점에서가 아니고, 풀 리퀘스트가 승인된 시점에서가 아닙니다. 커밋에서 프로드까지입니다. 파이프라인이 40분이 걸리고 릴리스 트레인이 목요일에 떠난다면, 리드 타임은 목요일에 의해 지배됩니다.

**배포 빈도.** 프로덕션에 얼마나 자주 배포하는가입니다. 기간 동안의 배포를 세거나 배포 사이의 간격을 측정할 수 있습니다. 하루에 11번 배포하는 서비스와 한 달에 한 번 배포하는 서비스는 다른 동물이며, 평균화하면 둘 다 숨깁니다.

**장애 복구 시간.** 배포로 인해 개입이 필요한 문제가 발생했을 때 복구하는 데 걸리는 시간입니다. 이것은 예전에 평균 복구 시간이라고 불렸으며, 이름 변경은 의도적입니다. 여러분 자신의 변경으로 인한 사건만 카운트되며, 화요일의 클라우드 제공자 장애는 아닙니다.

**변경 실패율.** 이후에 즉시 개입이 필요한 배포의 비율입니다. 롤백, 핫픽스, 빠른 속도로 푸시된 포워드 픽스입니다. 10가지 배포, 2개가 복구되었다면, 변경 실패율은 20%입니다.

**배포 재작업율.** 계획되지 않은 배포의 비율입니다. 로드맵 작업이 아닌 프로덕션 사건에 의해 트리거됩니다. 이것은 최신 추가 사항이며, 변경 실패율이 놓치는 것을 포착합니다. 롤백하지 않지만 주의 절반을 긴급 패치 배포에 쓰는 팀입니다.

![정시 개념을 나타내는 서버 랙 패널 위의 스톱워치](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/02c796-i1.webp)

## 처리량 대 불안정성: 왜 한 지표만으로는 절대 읽으면 안 되는가

처음 세 가지 지표는 처리량입니다. 마지막 두 가지는 불안정성입니다. 이 그룹화가 핵심입니다.

처리량만 보면, 하루에 40번 배포하고 조용히 25%를 복구하는 팀을 축하하게 됩니다. 불안정성만 보면, 한 달에 한 번 배포하고 완벽한 기록을 가진 팀을 보상하게 되는데, 이는 아무도 뭔가를 변경하지 않기 때문입니다. 모든 단일 지표에는 시스템을 악화시키는 것을 개선하는 저렴한 방법이 있습니다.

배포 빈도는 배포를 다섯 개의 빈 배포로 나눌 때 올라갑니다. 변경 실패율은 핫픽스를 장애로 카운트하지 않을 때 내려갑니다. 리드 타임은 시계 시작을 재정의할 때 줄어듭니다. 이것은 Goodhart의 법칙이 항상 하는 것입니다. 측정이 목표가 되면, 좋은 측정이 되는 것을 멈춘니다. 공식 가이드가 경고 중 첫 번째로 이것을 나열하며, 이것은 가장 심하게 물려드는 것입니다.

따라서 작동하는 규칙은 쌍입니다. 리드 타임을 변경 실패율 옆에 읽으세요. 배포 빈도를 재작업율 옆에 읽으세요. 한 방향의 움직임이 다른 쪽에서 일치하는 이야기 없이는 더 자세히 살펴봐야 한다는 신호이며, 발표할 승리가 아닙니다.

벤더 자료에 벤치마크가 유포되고 있으며, 이것은 덫입니다. 최근 DORA 보고서의 보도된 패턴은 모양에서 일관됩니다. 가장 강력한 팀 클러스터는 온디맨드 배포, 리드 타임이 1일 미만, 장애 배포에서 1시간 이내에 복구합니다. 가장 느린 클러스터는 양쪽 모두에서 주에서 개월 범위에 있습니다.

이 숫자들은 한 가지에 유용합니다. 여러분의 직관을 보정하는 것입니다. 그들은 목표로서 형편합니다. 필수 감사 게이트가 있는 결제 서비스는 마케팅 사이트와 일치하지 않으며, 일치하려고 해서도 안 됩니다. 공식 지침은 비슷한 애플리케이션 또는 서비스만 비교해야 하며, 팀 간 경쟁보다는 자신의 기준에 대한 개선을 목표로 해야 한다는 것을 명시합니다.

자신의 중앙값으로 시작하세요. 목표를 설정하기 전에 한 달 동안 측정하세요. 첫 번째 숫자는 거의 항상 창피하고, 그것은 괜찮습니다. 여러분을 창피하게 하는 기준은 여러분이 실제로 신뢰할 수 있는 기준입니다.

## 데이터 플랫폼을 구축하지 않으면서도 이들을 계기화하는 방법

대부분의 팀이 이것을 과도하게 만듭니다. 웨어하우스 프로젝트가 필요하지 않습니다. 네 개의 타임스탬프와 하나의 플래그가 필요합니다.

타임스탬프: 메인 브랜치에 병합된 커밋, 빌드 완료, 프로덕션 배포 시작, 배포 완료. 플래그: 배포가 나중에 복구, 핫픽스, 또는 정의된 창 내에서 계획되지 않은 배포가 뒤따르는지 여부입니다.

다음은 TypeScript의 최소 스케치입니다. 배포 레코드 목록을 취하고 중요한 숫자를 반환합니다.

`type Deploy = {
  service: string;
  committedAt: Date;
  deployedAt: Date;
  failed: boolean;       // 복구됨, 핫픽스됨, 또는 수동 개입
  unplanned: boolean;    // 사건에 의해 트리거됨, 로드맵 작업이 아님
  recoveredAt?: Date;    // failed가 true일 때 설정됨
};

const median = (xs: number[]) => {
  const s = [...xs].sort((a, b) => a - b);
  return s.length ? s[Math.floor(s.length / 2)] : 0;
};

export function doraSummary(deploys: Deploy[], days: number) {
  const leadHours = deploys.map(
    d => (d.deployedAt.getTime() - d.committedAt.getTime()) / 36e5,
  );
  const failures = deploys.filter(d => d.failed);
  const recoveryMins = failures
    .filter(d => d.recoveredAt)
    .map(d => (d.recoveredAt!.getTime() - d.deployedAt.getTime()) / 6e4);

  return {
    leadTimeHoursP50: median(leadHours),
    deploysPerDay: deploys.length / days,
    changeFailRate: failures.length / Math.max(deploys.length, 1),
    recoveryMinutesP50: median(recoveryMins),
    reworkRate: deploys.filter(d => d.unplanned).length / Math.max(deploys.length, 1),
  };
}`그 스니펫의 두 결정이 무게를 운반합니다. 첫째, 평균이 아닌 중앙값을 사용합니다. 3일 복구를 포함한 나쁜 주 하나가 평균을 망치고 일반적인 화요일에 대해 아무것도 말하지 않습니다. 둘째, 서비스당 모든 것을 계산합니다. 아래의 서비스를 본 후에만 팀 또는 부서에 집계합니다.

어려운 부분은 코드가 아닙니다. 어려운 부분은 `failed` 플래그입니다. 누군가는 장애로 카운트되는 것을 결정하고 쓰고 매번 같은 방식으로 적용해야 합니다. 사건 추적기가 사건을 그들을 야기한 배포에 연결하면, 여러분은 거의 무료로 이것을 얻습니다. 그렇지 않으면, 거기서 시작하세요.

![장애 배포를 나타내는 산업용 차단기 패널, 빨간 레버가 당겨짐](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/f8caad-i2.webp)

도구화 질문은 데이터 질문 이후에 나옵니다. 여러분은 대부분의 원시 데이터를 이미 소유하고 있습니다. 여러분의 Git 호스트는 커밋 시간을 가집니다. 여러분의 CI는 빌드 및 배포 이벤트를 가집니다. 여러분의 사건 도구는 장애를 가집니다. 작업은 공유 배포 식별자에서 이들을 조인하는 것입니다.

관찰성 플랫폼은 배포 마커를 오류율 및 지연 위에 오버레이하는 자연스러운 장소이므로, 어떤 배포가 어떤 스파이크보다 앞섰는지 볼 수 있습니다.

스택을 열려 있고 자체 호스팅으로 유지하려면, 배포 이벤트의 자신의 데이터베이스 위의 대시보드 계층이 동일한 작업을 더 낮은 비용으로 수행하며, 더 많은 배관 작업을 합니다.

또한 여러분의 저장소와 배포 이력을 읽고 위험을 표면화하는 도구 범주가 있습니다. 코드 변동과 과거 결함이 클러스터되는 핫스팟 등을 읽습니다. 네 개의 타임스탬프를 대체하지 않지만, 한 서비스가 이웃과 다를 때 높은 변경 실패율을 가지는 이유를 설명합니다.

여기서 구매에 주의하세요. 숫자를 표시하는 대시보드는 이들에 대해 행동하는 팀과 같지 않습니다. 아무도 복구 시간 차트를 소유하지 않으면, 더 나은 차트를 구매하는 것도 아무것도 변경하지 않습니다.

## 각 숫자를 실제로 움직이는 레버

지표는 진단입니다. 치료는 다른 곳에 있으며, 각각에 대해 다릅니다.

리드 타임의 경우, 작업이 아니라 대기를 봅니다. 최근의 12가지 변경을 당겨 각각이 유휴 상태인 곳을 표시합니다. 검토 대기 중, 빌드 슬롯 대기 중, 릴리스 창 대기 중입니다. 대부분의 팀에서 유휴 시간이 코딩 시간을 여러 번 능가합니다. 더 작은 풀 리퀘스트와 검토 서비스 수준 기대가 모든 파이프라인 튜닝을 이깁니다.

배포 빈도의 경우, 레버는 배치 크기입니다. 더 작은 변경은 검토하기 쉽고, 추론하기 쉽고, 복구하기 쉽습니다. 트렁크 기반 개발과 기능 플래그는 미완성 작업을 안전하게 병합하도록 하며, 배포와 릴리스의 분리가 가능합니다.

변경 실패율의 경우, 레버는 전체 함대가 되기 전에 볼 수 있는 폭발 반경입니다. 트래픽의 1%를 노출하는 롤아웃, SLO에 대한 오류율을 보고, 위반 시 정지하면 그렇지 않으면 사건이 될 것을 논경 사건으로 변합니다. 이것이 장애 배포와 팀 밖의 아무도 주목하지 않은 장애 변경 사이의 간격입니다.

복구 시간의 경우, 레버는 롤백입니다. 가장 빠른 수정이 롤백이라면, 복구 시간은 문제를 감지하는 것과 버튼을 누르는 것이 얼마나 빠른지입니다. 임계값 위반 시 자동 복구를 자동화하면 처음 10분 동안 인간을 빼냅니다. 3시 방향에 이것은 모든 런북보다 더 중요합니다.

재작업율의 경우, 레버는 상류입니다. 높은 숫자는 사건이 배포를 생성한다는 뜻입니다. 어떤 서비스가 긴급 패치를 생성하는지 봅니다. 그리고 한 번에 하나씩 사후분석을 읽는 것이 아닌 전체 집합으로 읽으세요.

## AI가 더 많은 코드를 작성할 때 무엇이 바뀌는가

최근 DORA 연구는 코딩 보조자를 판매하는 누구에게나 불편한 것을 가리킵니다. 보조자는 저수준 작업을 속도를 높이며, 그러나 이득이 리드 타임이나 변경 실패율을 명확하게 수행하지 않습니다. 더 많은 코드가 한 시간에 작성되는 것은 더 많은 가치가 한 주에 배포되는 것과 같지 않습니다.

만약 뭔가라면, 생성된 변경의 더 큰 볼륨이 검토와 여러분의 배포 파이프라인에 압력을 밉니다. 더 큰 배치는 안정성을 해치고, 검토 용량은 입력 속도로 확장되지 않습니다. 팀이 보조자를 채택한 후 몇 달 동안 변경 실패율과 재작업율을 면밀히 감시합니다. 리드 타임이 떨어지지만 재작업이 오르면, 여러분은 더 빨라지지 않았습니다. 여러분은 비용을 옮겼습니다.

![팀 사후분석을 위해 손으로 그린 추세 차트가 있는 노트북](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/30e093-i3.webp)

## 사후분석에서 팀을 깨지 않으면서도 사용하는 방법

실제로 작동하는 것이 있습니다. 지난 분기의 추세선을 화면에 놓고 한 가지 질문을 합니다. 여기서 뭐가 바뀌었고, 왜? 누구를 묻지 마세요. 목표는 사람에 대한 판정이 아니라 시스템에 대한 가설입니다.

세 가지 습관이 숫자를 정직하게 유지합니다.

첫째, 절대 개인 성과 검토에 넣지 마세요. 지표가 이름에 부착되는 순간, 사람들은 지표를 최적화하고, 여러분의 데이터는 현실을 설명하는 것을 멈춘니다.

둘째, 모든 숫자를 이야기와 짝을 합니다. 복구 시간의 스파이크는 이름과 사후분석이 있는 하나의 사건입니다. 차트를 읽기 전에 사후분석을 읽으세요.

셋째, 한 번에 한 가지를 바꿉니다. 기능 플래그를 채택하고, 풀 리퀘스트를 축소하고, 같은 달에 롤백을 자동화하면, 어떤 것이 바늘을 움직였는지 절대 배우지 않을 것입니다.

여러분의 조직을 티어로 정렬하고 트로피를 나눠주는 성숙도 모델 슬라이드를 건너뜁니다. 더 가치 있는 대신. 서비스당 한 페이지, 월간 업데이트, 다섯 숫자 나열, 이전 달의 값, 그리고 무엇이 바뀌었는지에 대한 한 문장입니다.

한 서비스에서 깨끗한 90일의 데이터가 있고, 배포 빈도가 평평하게 유지되는 동안 변경 실패율이 서서히 올라가는 것을 보았다고 가정합시다. 어디를 먼저 봅시까. 변경의 크기, 검토의 질, 또는 여전히 작은 동안 롤아웃에 할 수 있는 가시성? 여러분의 답변은 벤치마크보다 여러분의 배포 시스템에 대해 더 많이 말합니다.

## FAQ

### DORA 지표란 무엇입니까?

DORA 지표는 소프트웨어 배포 성능을 측정하는 5가지 메트릭입니다. 변경 리드 타임, 배포 빈도, 장애 복구 시간, 변경 실패율, 배포 재작업율로 구성되어 있습니다.

### 처리량과 불안정성을 함께 읽어야 하는 이유는 무엇입니까?

처리량과 불안정성을 분리하면 하나를 개선할 때 다른 하나가 악화될 수 있습니다. 예를 들어 배포 빈도만 높이면서 변경 실패율은 무시할 수 있습니다. 함께 읽으면 팀의 배포 시스템을 전체적으로 이해할 수 있습니다.

### DORA 지표를 계기화하기 위해 데이터 플랫폼이 필요합니까?

아닙니다. 4개의 타임스탬프(커밋, 빌드 완료, 배포 시작, 배포 완료)와 1개의 플래그(장애 여부)만 있으면 됩니다. 이미 Git, CI, 사건 추적 시스템에서 이 데이터를 얻을 수 있습니다.

### 벤치마크 목표를 설정해야 합니까?

벤치마크는 가능성을 보정하는 데 유용하지만 목표로 사용해서는 안 됩니다. 대신 자신의 기준선을 설정하고 월별 개선을 추적하세요. 비슷한 서비스끼리만 비교하세요.

### AI 코딩 보조자가 DORA 지표에 미치는 영향은 무엇입니까?

AI 보조자는 저수준 작업 속도를 높이지만 리드 타임이나 변경 실패율을 명확하게 개선하지 않습니다. 오히려 더 많은 코드가 검토와 배포 파이프라인에 압력을 가할 수 있습니다.

### 사후분석에서 DORA 지표를 어떻게 사용합니까?

지난 분기의 추세선을 화면에 표시하고 "무엇이 바뀌었고 왜?"라고 묻습니다. 절대 개인을 지적하지 말고, 숫자와 함께 이야기를 읽고, 한 번에 한 가지씩만 변경하세요.

### 변경 리드 타임이 높으면 어떻게 해야 합니까?

코딩 시간이 아닌 대기 시간을 살펴보세요. 리뷰 대기, 빌드 슬롯 대기, 릴리스 윈도우 대기 등을 확인하세요. 더 작은 풀 리퀘스트와 리뷰 SLO가 파이프라인 튜닝보다 더 효과적입니다.