DORA 지표란 무엇인가요?

Google의 DevOps 연구 및 평가(DevOps Research and Assessment, DORA)팀이 개발한 DORA 지표는 소프트웨어 제공 및 DevOps 성숙도에 대한 업계 표준 벤치마크를 제공합니다.

DORA 지표는 기본적으로 다음 두 가지 측면에 중점을 둡니다.

1. 처리량: DevOps 팀이 소프트웨어를 얼마나 빠르게 제공할 수 있는지
   
   
2. 안정성: DevOps 팀이 소프트웨어를 얼마나 안정적이고 안전하게 제공할 수 있는지

처리량 중심 지표는 코드 변경 사항이 소프트웨어 개발 라이프사이클(아이디어 구상부터 프로덕션까지)을 얼마나 빠르게 통과하는지 보여주는 반면, 안정성 중심 지표는 배포가 얼마나 자주 실패하는지와 팀이 얼마나 빠르게 복구하는지를 보여줍니다. 두 지표를 함께 활용하면 비즈니스 리더와 DevOps 팀은 DevOps 성과에 관한 증거 기반의 재현 가능한 인사이트를 얻을 수 있습니다. 기업은 ‘작성한 코드 줄 수’나 ‘근무 시간’과 같은 주관적인 성과 측정 방법이나 허영 지표에 의존할 필요가 없습니다.

DORA 지표를 추적하면 DevOps 팀은 업계에서 인정하는 성과 등급(낮음, 보통, 높음, 엘리트)과 비교하여 자신의 수준을 파악하고, 전사 목표와 일치하는지 확인할 수 있습니다. 또한 기업은 지속적 통합/지속적 제공(CI/CD) 파이프라인, 소프트웨어 테스트 및 인시던트 관리에서 병목 현상을 객관적으로 식별할 수 있습니다.  

DORA 지표를 사용하면 조직 리더는 비즈니스 이해관계자에게 엔지니어링 부서의 상태를 더 쉽게 전달하고, DevOps 사례를 최적화하는 데 도움이 되는 고급 자동화, 관측 가능성 및 사이트 신뢰성 엔지니어링(SRE) 툴에 대한 투자를 정당화할 수 있습니다.

DevOps에서 DORA는 소프트웨어 개발 팀을 위한 조직 성과 지표를 널리 알린 DevOps 연구 및 평가(DevOps Research and Assessment) 팀을 의미합니다.

현재 Google Cloud의 일부인 DORA는 소프트웨어 제공 프로세스가 비즈니스 성과에 미치는 영향을 연구한 독립적인 연구 프로젝트로 시작했습니다. DORA 팀은 한 가지 핵심 질문에 답하고자 했습니다. 고성과 소프트웨어 팀은 저성과 팀과 무엇이 다를까요?

이들은 수천 개 팀의 설문 조사 및 텔레메트리 데이터를 수집하여 소프트웨어 제공 및 운영과 관련된 소수의 지표가 전반적인 성과를 강력하게 예측한다는 사실을 발견했습니다. 구체적으로 이러한 지표는 배포 빈도, 변경 리드 타임, 변경 실패율 및 실패한 배포 복구 시간입니다. 또한 그 결과는 릴리스 속도와 소프트웨어 안정성이 함께 달성될 수 있음을 입증했습니다. 따라서 팀은 둘 중 하나를 우선시할 필요가 없습니다.

결국 이 네 가지 지표는 소프트웨어 제공 성과를 위한 업계 표준 벤치마크를 제공하는 표준 DORA 지표가 되었습니다. 2024년에 DORA 연구팀은 프레임워크에 다섯 번째 지표인 배포 재작업률을 추가했습니다.  

5가지 DORA 지표는 ‘처리량’과 ‘안정성’이라는 두 가지 상위 범주로 분류할 수 있습니다.

처리량 지표에는 배포 빈도, 변경 리드 타임 및 실패한 배포 복구 시간이 포함되며, 이를 종합하면 애플리케이션이 얼마나 많은 변경 사항을 처리할 수 있는지와 변경 사항이 프로덕션으로 얼마나 빠르게 전달되는지를 알 수 있습니다.

안정성 지표에는 변경 실패율과 배포 재작업률이 포함되며, 실패를 유발하는 배포의 비율과 계획되지 않았거나 프로덕션 인시던트에 의해 실행된 배포의 비중을 측정합니다.

배포 빈도는 팀이 일정 기간(일별, 주별, 월별) 동안 코드가 프로덕션에 성공적으로 배포된 빈도를 측정합니다.

배포 빈도는 소프트웨어 팀이 제공 프로세스에서 얼마나 민첩하고 자신감을 가지고 있는지를 보여주는 가장 가시적인 신호 중 하나입니다. 팀이 하루에 여러 번 코드를 프로덕션에 배포한다면, 일반적으로 자동화된 빌드, 테스트 및 배포 프로세스가 원활하게 실행되고 있으며 효과적인 관측 가능성 메커니즘이 마련되어 있음을 의미합니다. 이러한 조건을 통해 개발 팀은 시스템 중단에 대한 우려 없이 소프트웨어를 릴리스할 수 있습니다.

반대로 한 달에 한 번만 배포하거나 그보다 더 낮은 빈도로 배포하는 팀은 장기간 유지되는 코드 브랜치, 수동 테스트, 복잡한 승인 프로토콜 및 대규모 릴리스 일자에 의존하는 경우가 많습니다. 이러한 요인은 모두 사용자 피드백 주기를 늦추고 결함 수정 비용을 증가시킵니다.

특히 높은 배포 빈도가 잦은 서비스 중단이나 롤백을 수반한다면, 이는 건전성의 신호가 아닙니다. 고성과 팀은 높은 배포 빈도와 견고한 품질 보증 사례(다단계 자동화 테스트, 단계적 배포, 기능 플래그 및 실시간 모니터링 사례)를 결합하여 팀이 사용자에 대한 위험을 최소화하면서 자주 배포할 수 있도록 지원합니다.

조직 리더의 관점에서 시간에 따른 배포 빈도를 추적하면 소프트웨어 제공 파이프라인의 병목 현상을 파악할 수 있습니다. 예를 들어 새 승인 위원회를 도입한 후 배포 빈도가 감소한다면, 해당 프로세스가 지나치게 엄격하다는 의미일 수 있습니다. 반대로 배포 빈도가 꾸준히 증가하고 신뢰성 지표도 함께 개선된다면, CI/CD 파이프라인 및 DevOps 사례에 대한 투자가 성과를 거두고 있다는 강력한 지표입니다.

변경 리드 타임은 버전 제어 시스템의 기본 코드 브랜치에 코드 변경 사항이 커밋된 후, 해당 변경 사항이 배포되어 실제 프로덕션 환경에서 성공적으로 실행되기까지 걸리는 시간을 측정합니다.

이 엔드투엔드 기간에는 빌드 시간, 테스트 실행, 코드 검토, 승인, 파이프라인 단계 및 실제 배포를 비롯한 모든 과정이 포함됩니다. 이를 통해 시스템이 의사 결정을 최종 사용자를 위한 실질적인 변경으로 얼마나 빠르게 전환할 수 있는지 알 수 있습니다.

리드 타임이 짧으면(1시간 미만) 조직은 인시던트에 거의 실시간으로 대응할 수 있습니다. 예를 들어 보안 팀이 취약점을 표시하면 엔지니어링 팀은 수정 사항을 구현하고, 자동화된 검사를 통해 검증한 후, 매우 짧은 시간 내에 프로덕션에 적용할 수 있습니다. 이러한 신속한 피드백 루프는 팀이 변경 사항의 영향을 빠르게 측정하고 그에 따라 조정할 수 있으므로 개발 업무를 비즈니스 성과와 직접 연결합니다.

변경 리드 타임을 줄이려면 거의 항상 DevOps 팀이 제공 파이프라인을 자동화하고 간소화해야 합니다. 일반적으로 이 프로세스에는 모든 커밋을 신속하게 빌드하고 테스트할 수 있도록 지속적 통합(CI) 툴에 투자하고, 승인이 개발 워크플로에 통합되도록 승인 프로세스를 간소화하는 작업이 포함됩니다.

실패한 배포 복구 시간은 평균 복구 시간(MTTR) 또는 평균 서비스 복구 시간이라고도 하며, 배포 관련 장애 후 서비스를 정상 상태로 복구하는 데 걸리는 시간을 평가합니다.

서비스를 복구하기 위해 개발자는 문제가 있는 변경 사항을 롤백하거나, 핫픽스(일반 릴리스 주기 외에 릴리스되는 작고 긴급한 코드 변경 사항)를 배포하거나, 사용자가 시스템을 다시 정상적으로 사용할 수 있도록 문제의 영향을 완화해야 할 수 있습니다.

복구 시간이 짧으면(수 분 수준) 일반적으로 여러 DevOps 구성 요소가 원활하게 함께 작동하고 있음을 의미합니다.

관측 가능성이 뛰어납니다. 지표, 로그 및 추적 데이터와 같은 실시간 텔레메트리 데이터가 대시보드에 완전히 통합되어 중앙에서 관리됩니다. 인시던트는 사용자의 신고를 기다리지 않고 신속하게(흔히 자동으로) 감지됩니다.

알림은 적절하게 조정되므로 엔지니어는 즉시 알림을 받지만 과도한 노이즈에 압도되지 않습니다.

DevOps 팀은 런북(기술 작업 수행을 위한 단계별 전술 가이드), 플레이북(팀이 특정 상황에 대응하는 방법을 설명하는 상위 수준의 전략 가이드) 및 문서화된 롤백 절차를 활용합니다. 이러한 프레임워크는 서비스 중단 상황에서 무엇을 해야 할지 추측할 필요가 없게 합니다.

복구 시간이 길면(수 시간 또는 수 일) 운영 사례가 미흡하다는 의미인 경우가 많습니다. 감지 체계가 부실하여 고객이 보고할 때까지 프로덕션 장애가 지속될 수 있습니다. 데이터 수집이 분산되어 있거나 오류 메시지가 명확하지 않거나, 장애 모드에서 시스템이 어떻게 작동하는지에 대한 팀의 공통된 이해가 부족하기 때문에 진단 과정도 느립니다. 이러한 환경에서는 각 인시던트가 명확한 해결 프로토콜을 갖춘 단순한 문제 해결 작업이 아니라, 높은 스트레스와 위험을 수반하는 이벤트가 됩니다.

다른 DORA 지표와 함께 활용하면 실패한 배포 복구 시간이 짧을수록 배포가 가끔 실패하더라도 장애를 억제하고 대응 시간을 짧게 유지하는 데 도움이 됩니다.

변경 실패율(CFR)은 프로덕션 환경에서 배포가 얼마나 자주 실패하는지를 DevOps 팀에 알려 주는 ‘제공 품질’ 지표입니다. 다음에 계획된 릴리스까지 문제 해결을 기다리는 대신 팀이 즉시 개입해야 하는 모든 문제 발생 프로덕션 배포는 ‘실패한’ 배포로 간주됩니다.

시간 경과에 따라 CFR을 추적하면 팀은 변경 사항을 얼마나 안정적으로 제공하고 있는지 파악할 수 있으며, 속도를 우선시하는 처리량 지표(배포 빈도, 변경 리드 타임)에 대한 균형 지표 역할을 합니다.

CFR은 일반적으로 백분율로 표시하며, 동일한 기간의 전체 배포 수로 실패한 배포 수를 나눈 다음 100을 곱하여 계산합니다.

변경 실패율이 낮다는 것은 팀이 일반적으로 프로덕션에서 예상대로 작동하는 변경 사항을 제공하고 있음을 의미합니다. CFR이 낮고 안정적으로 유지되면 팀은 사용자 경험을 저해하지 않으면서 배포 빈도를 높이고 변경 리드 타임을 단축할 수 있습니다.

그러나 변경 실패율이 높다면 너무 많은 변경 사항이 시스템을 불안정하게 만들고 있다는 의미입니다. 원인으로는 불완전하거나 불안정한 테스트, 프로덕션 환경과 다른 스테이징 및 테스트 환경, 지나치게 크기가 큰 배포 또는 느린 모니터링 및 알림 등이 있습니다. CFR이 높다면, 조직은 더 작고 점진적인 변경 사항과 더 안전한 배포 사례(예: 전체 릴리스 전에 소규모 사용자 그룹에게 새 애플리케이션 또는 기능을 배포하는 카나리 릴리스)를 우선시하여 프로덕션 인시던트로 이어지는 변경 사항을 줄여야 한다는 신호입니다.

배포 재작업률은 팀의 배포 중 재작업이 차지하는 비율을 측정하는 안정성 지표입니다. ‘재작업’은 프로덕션 환경에서 사용자에게 영향을 미치는 버그 또는 인시던트로 인해 실행되며, 원래 계획된 릴리스 트레인에 포함되지 않은 모든 배포를 의미합니다.

배포 재작업률은 대응 작업을 가시화하여 기존의 4가지 DORA 지표를 보완합니다. 이를 통해 팀의 개발 노력 중 제품을 발전시키는 대신 과거의 실수를 바로잡는 데 쓰이는 비중을 파악할 수 있습니다.

일반적으로 재작업률이 낮으면 DevOps 팀이 대부분의 문제를 최종 사용자에게 도달하기 전에 포착하고, 대부분의 시간을 가치 창출 업무(계획된 최적화 및 리팩터링)에 사용하고 있음을 의미합니다. 재작업률이 높다면 팀이 긴급 대응 업무에 너무 많은 시간을 쓰고 있다는 의미입니다.

재작업률은 다른 핵심 지표와 함께 사용할 때 특히 유용합니다. 예를 들어 팀의 배포 빈도가 높고 재작업률이 낮다면, 품질을 희생하지 않으면서 새로운 소프트웨어 버전을 빠르게 제공하고 있다는 신호입니다. 반면 배포 빈도와 재작업률이 모두 높다면 많은 코드를 제공하는 동시에 이를 수정하는 데에도 많은 시간을 쓰고 있음을 시사합니다.

중요한 점은 재작업률이 0이 아닌 것은 정상적이며(대개는 바람직하기도 합니다), 최상의 개발 팀도 실수할 수 있고 잘 구축된 소프트웨어 애플리케이션도 시간이 지남에 따라 개선 및 기능 업데이트가 필요하다는 것입니다. 목표는 재작업률을 0%로 만드는 것이 아니라, 전체 배포에서 재작업이 차지하는 비율을 작고 예측 가능한 수준으로 유지하는 것입니다.

각 DORA 지표에서 팀은 엘리트, 높음, 보통 또는 낮음의 4가지 성과 등급 중 하나로 분류되며, 각 등급은 해당 지표에 대해 설정된 기준값을 기반으로 합니다. 기준값은 다음과 같습니다.

배포 재작업률은 비교적 새로운 지표이므로 아직 설정된 기준값이나 성과 등급이 없습니다. 그러나 많은 기업과 DevOps 팀은 자체 재작업 기준선을 추적하고, 시간이 지남에 따라 이를 낮추는 것을 목표로 합니다. 재작업률 데이터를 변경 실패율 및 기타 신뢰성 지표와 함께 활용하면 팀은 하나의 수치만을 기준으로 과도하게 조정하지 않으면서 배포 재작업률을 개선할 수 있습니다. 

DORA 지표는 애플리케이션 개발 및 운영 기능 전반에서 여러 분야로 구성된 팀 간의 지속적인 협업을 우선시하는, 소프트웨어 개발에 대한 광범위한 DevOps 접근 방식을 지원합니다. DevOps 환경의 성공은 그 환경을 구성하는 팀의 역량에 달려 있습니다.

DORA 지표를 통해 기업은 광범위한 가치 흐름 및 비즈니스 성과와 밀접하게 연계된 기준에 따라 팀 성과를 정량화할 수 있습니다. 예를 들어 고성과 팀과 엘리트 성과 팀은 수익성, 시장 출시 기간 및 고객 만족도 목표를 달성할 가능성이 더 높습니다.

DevOps 문화는 자유로운 의사소통과 소프트웨어 제공 이해관계자 간의 공동 책임에 대한 의지가 특징입니다. 이들은 모두 고품질 소프트웨어를 구축하고 제품 혁신을 가속화하기 위해 협력합니다. 따라서 많은 조직은 DORA 지표를 사용하여 지속적인 개선 피드백 루프를 구축합니다. 지표는 각 팀의 성과를 측정합니다. 팀은 측정 결과를 바탕으로 개선 기회를 논의하고, 새로운 접근 방식을 실험한 후, 성과를 다시 측정하여 어떤 변경 사항이 실제로 제공 사례를 개선하는지 확인할 수 있습니다.

중요한 점은 DORA 지표가 처벌 목적이 아닌 진단 목적의 지표라는 것입니다. 이는 개별 개발자의 업무에 초점을 맞추는 대신 개발 프로세스의 체계적인 패턴을 파악하는 데 도움이 됩니다.