[번역] DORA 지표(DORA Metrics)를 계산하는 방법

2023년 11월

원문 — How to Calculate DORA Metrics

https://dorametrics.org/how-to-calculate-dora-metrics/

데이터, 특히 조직에 대한 데이터보다 조직에 더 가치 있는 것은 없습니다. 성과를 측정하지 않으면 개선 방법이나 리소스 분배에 대해 합리적인 결정을 내리기가 힘들 수 있습니다. 이 때 개발 팀의 운영 방식을 명확하게 파악하면 가치 흐름을 극대화하고 최종 사용자에게 최상의 제품을 제공할 수 있습니다.

수년간의 연구 끝에 Google의 DORA(DevOps Research and Assessment) 팀은 팀의 생산성을 평가하기 위한 4가지 주요 항목을 알아냈습니다.

• 변경 리드 타임
• 배포 빈도
• 평균 복구 시간
• 변경 실패율

DORA 지표는 소프트웨어 개발 팀의 생산성을 측정하는 표준이 되었으며 팀의 성장에 대한 중요한 통찰력을 제공합니다. 이러한 지표는 현대화를 원하는 조직과 경쟁업체에 비해 우위를 확보하려는 조직에 필수적입니다. 아래에서는 각 항목에 대해 자세히 알아보고 이러한 측정 항목이 소프트웨어 개발 팀에 대해 무엇을 알려줄 수 있는지 알아봅니다.

변경 리드 타임

변경 리드 타임(LTC — Lead Time for Changes)은 커밋과 프로덕션 배포 사이에 걸리는 시간을 의미합니다. 변경 리드 타임은 팀이 얼마나 민첩한 지 나타냅니다. 변경 사항을 구현하는 데 걸리는 시간뿐만 아니라 끊임없이 변화하는 사용자 요구 사항에 팀이 얼마나 빨리 대응할 수 있는 지를 보여줍니다. DORA 팀은 Accelerate State of DevOps 2021 보고서에서 아래와 같은 벤치마크를 찾을 수 있었습니다.

• 엘리트 팀: <1시간
• 고성과 팀: 1일~1주
• 중간성과 팀: 1개월~6개월
• 저성과 팀: 6개월 이상

변경 리드 타임은 열악한 DevOps의 징후를 밝힐 수 있습니다. 팀이 코드를 프로덕션에 릴리스하는 데 몇 주 또는 몇 달이 걸린다면 비효율적인 프로세스로 운영되고 있다고 볼 수 있습니다. CI/CD(Continuous Integration / Continuous Deployment)를 통해 변경 리드 타임을 최소화할 수 있습니다. 테스터와 개발자가 긴밀하게 협력하여 모든 사람이 소프트웨어를 포괄적으로 이해할 수 있도록 하십시오. 또한 더 많은 시간을 절약하고 CI/CD 파이프라인을 개선하려면 자동화된 테스트 구축을 고려해야 합니다.

변경 시작과 배포 사이에는 여러 단계가 있으므로 프로세스의 각 단계를 정의하고 각 단계에 소요되는 시간을 추적하는 것이 좋습니다. 팀이 어떻게 기능하고 있는지 그리고 단계 별로 어느정도 시간이 소요되는지 철저하게 파악해 시간을 절약할 수 있는 부분에 대해 정확히 짚으세요.

더 빠른 변경을 추구하면서 소프트웨어 제공 품질이 저하되지 않도록 주의하세요. 변경 리드 타임이 낮다는 것은 팀이 효율적이라는 것을 의미할 수 있지만, 구현 중인 변경 사항을 지원할 수 없거나 지속 불가능한 속도로 움직이고 있다면 사용자 경험이 희생될 위험이 있습니다. 팀의 변경 리드 타임을 다른 팀 또는 조직의 변경 리드 타임과 정확히 비교하기보다는 시간이 지남에 따라 변경 리드 타임을 절대적으로 평가하고 이를 성장(또는 정체)의 지표로 간주해야 합니다.

배포 빈도

배포 빈도(DF — Deployment Frequency)는 변경 사항을 제공하는 빈도, 소프트웨어 제공의 일관성을 나타냅니다. 이 지표는 팀이 지속적으로 배포하고 있는지 여부를 판단할 때 특히 유용합니다. DORA 팀에 따르면 배포 빈도에 대한 벤치마크는 다음과 같습니다.

• 엘리트 팀: 하루에 여러 번
• 고성과 팀: 주 1회 ~ 월 1회
• 중간성과 팀: 한 달에 한 번 ~ 6개월에 한 번
• 저성과 팀: 6개월에 1회 미만

만약 배포 빈도가 낮으면 개발 프로세스의 병목 현상이 나타나거나 프로젝트가 너무 복잡하다는 것을 의미할 수 있습니다. 배포 빈도를 향상시키는 가장 좋은 방법은 변경사항을 작게 유지하는 것입니다. 배포를 자주하는 것은 서비스를 지속적으로 개선하고 있음을 의미하며, 자주 배포를 하는 경우 코드에 문제가 있는 경우라도 해결하기 쉬워집니다.

팀 규모가 크다면 이는 실현 가능한 옵션이 아닐 수도 있습니다. 대신, 릴리즈 트레인을 구축하고 정기적으로 배포하는 것을 고려할 수 있습니다. 이 접근 방식을 사용하면 팀 구성원에게 부담을 주지 않으면서 더 자주 배포할 수 있습니다.

평균 복구 시간

평균 복구 시간(MTTR — Mean Time to Recovery)은 장애 상황과 같은 서비스 중단이 발생할 때 팀이 서비스를 복원하는 데 걸리는 평균 시간입니다. 이 지표는 소프트웨어의 안정성은 물론 문제에 직면한 팀의 민첩성을 보여줍니다. State of DevOps 보고서에서 확인된 벤치마크는 다음과 같습니다.

• 엘리트 팀: <1시간
• 고성과 팀: <1일
• 중간성과 팀: 1일~1주
• 저성과 팀: 6개월 이상

서비스 저하가 유저 가치 흐름에 미치는 영향을 최소화하려면 가동 중지 시간이 최대한 적어야 합니다. 팀이 서비스를 복원하는 데 하루 이상 걸리는 경우, 큰 중단을 일으키지 않고 변경 사항을 신속하게 비활성화할 수 있도록 피쳐 플래그를 활용하면 좋습니다. 더 작게 쪼개어 배포한다면 문제를 발견하고 해결하는 것도 더 쉬워집니다.

평균 발견 시간(MTTD — Mean Time to Discover)은 평균 복구 시간과 다르지만, 팀이 문제를 감지하는 데 걸리는 시간으로 평균 복구 시간에 영향을 미칩니다. 즉, 팀이 문제를 더 빨리 발견할수록 서비스를 더 빨리 복원할 수 있습니다.

변경 리드 타임에서 이야기했던것처럼 품질을 희생하면서까지 빠르게 변경을 반영하고 싶지는 않으실겁니다. 빠르게 해결하는 것도 중요하지만 제공하려는 변경 사항이 지속가능하고 단단한지 확인하세요. 이를 통해 시간이 지남에 따라 평균 복구 시간을 추적하여 팀이 어떻게 발전하고 있는지 확인하고 꾸준하고 안정적인 성장을 목표로 삼아야 합니다.

변경 실패율

변경 실패율(CFR — Change Failure Rate)은 가동 중지 시간, 서비스 저하 또는 롤백을 초래하는 릴리즈의 비율로, 팀이 변경 사항을 구현하는 데 얼마나 효율적인지 알 수 있습니다. 보시다시피 변경 실패율의 성능 벤치마크 간에는 큰 차이가 없습니다.

• 엘리트 팀: 0-15%
• 고성과, 중간, 저성과 팀: 16-30%

변경 실패율은 발생한 총 실패 횟수로 인해 팀이 오해를 받는 것을 방지할 수 있기 때문에 특히 중요한 지표입니다. 많이 배포하지 않는 팀은 실패 횟수가 더 적지만, 그렇다고 해서 배포를 적게한 팀이 더 성공적이라는 의미는 아닙니다. CI/CD 방식을 따르는 팀은 더 많은 배포로 인해 실패 횟수가 더 높을 수 있지만 변경 실패율이 낮다면 배포 속도와 전반적인 성공률로 인해 이러한 팀이 우위를 점하게 됩니다.

이 비율은 가치 흐름에 중요한 영향을 미칠 수도 있습니다. 즉, 새로운 프로젝트를 개발하는데 시간을 쓰지 못하고 그 대신 문제를 해결하는 데 사용한 시간을 나타낼 수 있습니다. 성과가 높은 팀, 중간 팀, 낮은 팀이 모두 동일한 범위에 속하므로 다른 조직과 비교하기보다는 팀과 비즈니스를 기반으로 목표를 설정하는 것이 가장 좋습니다.

함께 모아서

모든 데이터와 마찬가지로 DORA 지표에는 맥락이 필요하며 이러한 네 가지 지표를 모두 함께 고려해야 합니다. 변경 리드 타임 및 배포 빈도는 팀의 속도와 끊임없이 변화하는 사용자 요구 사항에 얼마나 신속하게 대응하는지에 대한 통찰력을 제공합니다. 반면 평균 복구 시간 및 변경 실패율은 서비스의 안정성과 서비스 중단 또는 오류에 대한 팀의 대응 정도를 나타냅니다.

네 가지 주요 지표를 모두 비교하면 조직이 속도와 안정성의 균형을 얼마나 잘 유지하고 있는지 평가할 수 있습니다 . 변경 리드 타임이 1주일 이내이고 일주일에 한 번 이상 배포하지만 변경 실패율이 높은 경우 팀은 준비가 되기 전에 서둘러 변경 사항을 적용하거나 예정된 요구사항을 모두 유저에게 전달하지 못할 수 있습니다. 반면에 한 달에 한 번 배포하고 평균 복구 시간이 짧고 변경 실패율이 낮다면 이 팀은 제품 개선보다 코드 수정에 더 많은 시간을 할애할 수 있습니다.

DORA 지표는 팀 성과에 대한 높은 수준의 시야를 제공하므로 현대화를 시도하는 조직에 특히 유용할 수 있습니다. DORA 지표는 개선할 부분과 방법을 정확히 식별하는 데 도움이 됩니다. 시간이 지남에 따라 팀이 어떻게 성장했는지, 어떤 영역이 더 다루기 어려웠는지 확인할 수 있습니다.

엘리트 범주에 속하는 팀은 DORA 지표를 활용하여 서비스를 지속적으로 개선하고 경쟁사보다 우위를 확보할 수 있습니다. State of DevOps 보고서에 따르면 엘리트 팀은 빠르게 성장하고 있으므로 (2018년 7%에서 2021년 26%로) DORA 지표는 이 그룹에 귀중한 통찰력을 제공할 수 있습니다.

데이터는 지금까지의 현상만 조명합니다. DORA 지표를 최대한 활용하려면 조직과 팀을 알아야 하며 해당 지식을 모두 활용하여 팀의 목표와 리소스 투자 방법을 안내해야 합니다.

이 게시물은 Cortex 블로그에서 다시 게시되었습니다.