DORA Metrics 에 관한 더 자세한 분석과 활용방법
이번 아티클에서는 도라 메트릭(DORA Metrics) 자체에 집중하여 자세하게 분석해보고 충분히 숙지하여 활용하는 방법에 대해 다루겠습니다.
분석
도라 메트릭이 가지는 의미는 조직이 보유하고 수행하는 능력(capabilities) 을 토대로 성능(performance)을 측정하고 최종적으로 성과(outcomes)로 변환하는 것에 있습니다.
소프트웨어 제공성능(Software delivery performance)
소프트웨어 제공성능은 아래 다섯가지 지표로 측정합니다.
변경 리드 타임(Lead time for changes, LTC): 리모트 저장소에 commit 한 코드가 프로덕션 환경으로 성공적으로 배포되어 실행되는데까지의 시간입니다.
배포 빈도(Deployment frequency, DF): 코드를 프로덕션 환경에 배포하는 빈도입니다.
변경 실패율(Change failure rate, CFR): 프로덕션에 배포된 변경사항 중 서비스 저하(예: 서비스 장애 또는 서비스 중단 발생)를 초래하고 이후 수정(예: 핫픽스, 롤백, 나중에 고칠 버그, 패치)이 필요해진 비율입니다.
실패한 배포 복원 시간(Failed deployment recovery time, FDRT): 사용자에게 영향을 미치는 서비스 사고 또는 결함(예: 처리되지 않은 예외로 발생한 중단, 서비스 장애)이 발생한 경우 서비스를 복원하는 데 걸리는 시간입니다.
안정성(Reliability): 가용성, 대기 시간, 성능 및 확장성을 포함하는 보다 광범위한 소프트웨어 시스템이 정상 동작할 것이라고 신뢰할 수 있는지에 대한 지표입니다.
활용: 측정
각 지표들을 어떻게 측정할 수 있을지에 대한 계산식과 사용하면 좋을 도구들에 대해 아래에 나열하였습니다.
변경 리드 타임(Lead time for changes, LTC):
{변경 리드 타임} 의 평균
변경 리드 타임 = {변경 배포 시간}-{변경 시작 시간}
개발자로부터 변경이 시작된 시간으로부터 완료하여 코드를 배포 브랜치에 병합한 시점까지의 시간을 측정합니다. 시작과 배포 사이에는 조직마다 다른 여러 단계가 있으므로 사용하려는 조직 내에서 진행되는 프로세스를 먼저 분석하여 각각의 단계를 정의해야 합니다. 이 시간은 개발 업무에 사용되는 도구들을 사용하면 타임스탬프를 추적하고 리드 타임을 계산할 수 있습니다.
예를들어 JIRA 의 경우 … Task 가 Todo 에서 In Progress 로 넘어갔을 때를 시작으로 하고, Done 상태가 되었을 때를 완료로 합니다. 시작에서부터 완료까지 걸린 시간을 측정합니다. Git 의 경우 … (1) 첫 코드 커밋이 이루어진 시점과 (2) 해당 변경 사항이 배포된 시점의 타임스탬프를 각각 기록하고, (1) 과 (2) 의 차이를 계산합니다.
Git 을 통하여 제대로된 데이터를 측정하기 위해서는 반드시 개발자들이 코드를 커밋할 때에 Atomic commit 을 적용해야 합니다.
측정 단위는 프로덕션 배포가 진행될 브랜치로의 Pull Request, 또는 프로젝트 매니징 솔루션에서의 이슈 단위가 될 수 있습니다.
단순히 변경 리드 타임만 줄이는 것 자체를 목표하여 오히려 품질이 저하되지 않도록 주의해야합니다. 변경 리드 타임을 극도로 낮췄을 때 팀이 마치 효율적인 것 처럼 보일수도 있지만, 지속할 수 없는 속도로 움직여 이로 인해 개발자들의 번아웃을 초래하거나 긴 호흡을 가져야 하는 일까지 짧게 가져가 품질을 저하시키고 있다면 사용자 경험이 희생당할 수 있습니다.
배포 빈도(Deployment frequency, DF):
({마지막배포시간}-{첫번째배포시간}) / {총 배포 횟수}
측정하기로 한 특정 기간 동안의 배포 빈도를 계산합니다.
예를들어 버전 제어 시스템의 경우 … Git 과 같은 버전 제어 시스템을 사용하여 전체 커밋 및 릴리즈 횟수를 추적합니다. 또는 지속적인 통합(Continuous Integration)의 경우 … Jenkins, GitLab CI와 같은 CI 도구를 통해서 프로세스를 자동화하고 배포 빈도 지표를 추출할 수 있습니다.
배포 빈도를 제대로 측정하기 위해서는 먼저 “무엇이 배포인가” 를 정의해야 합니다. 그렇지 않다면 도입 의도와 다르게 지나치게 많게 측정되거나 개발자가 쉽게 어뷰징할 수 있는 지표가 되어 측정에 어려움을 줄 수 있습니다.
이 지표를 매번 측정하기에 조직을 구성하는 개발자와 팀이 너무 많은 경우에는 배포로 인한 리스크 관리와 표준화된 배포 방식을 가지기 어려워 균일하게 측정하지 못할 수도 있습니다. 그렇다면 배포를 위한 릴리즈 트레인을 조직에 구축하고 매월 또는 매주정기적으로 배포하는 것을 제안합니다. 이 방식을 사용하면 구성원에게 부담을 주지 않으면서 더 자주 배포할 수 있습니다.
변경 실패율(Change failure rate, CFR):
{실패한 배포 횟수} / {총 배포 횟수}
배포한 변경사항이 정상동작하지 않는 원인이 되었다면 실패로 간주하여 실패 횟수로 측정하고, 특정 기간 동안의 실패한 배포 횟수를 총 배포 횟수로 나누어 사용합니다.
총 실패 횟수를 사용하지 않는 이유는 변경 실패에 대한 지표가 배포 빈도 지표와 경쟁하지 않도록 하기 위함 입니다. 단순하게 비교했을 때 많이 배포하지 않는 팀이 더 적게 실패할 수도 있지만, 그렇다고 해서 배포를 적게한 팀이 더 적은 실패를 만드는 능력이 있다는 뜻은 아닙니다. 배포를 했을 때에 실패할 확률을 계산함으로써 “일부러 배포를 하지 않는 방향”으로 실패 횟수를 줄이는 것을 방지합니다.
버전 제어 시스템, CI 도구, Prometheus, Grafana 와 같은 모니터링 솔루션은 배포가 실패 했는지에 대한 데이터를 제공할 수 있습니다.
실패한 배포 복원 시간(Failed deployment recovery time, FDRT):
{실패한 배포 복원 시간}의 평균
실패한 배포 복원 시간 = {복원버전 배포 시간}-{사고가 발생한 시간}
이 지표를 계산하려면 사고가 발생한 시점부터 서비스가 완전히 복원된 시점까지의 시간을 기록합니다.
이 지표는 다음과 같은 요소들에 영향을 받습니다.
- 설계
- 문서화
- 모니터링 가시성
- 배포 파이프라인 성능
블록 Exception 핸들링 범위를 적절하게 조정하는 등의 방법으로 오류가 발생하더라도 최대한 작은 영향만 끼치도록 설계해야하고, 코드를 작성한 사람이 자리에 없더라도 충분히 다른 개발자도 복원할 수 있도록 문서화가 잘 되어있어야 하며 사고가 발생했다는 것을 알고 어느 인프라의 코드라인이 문제인지 빠르게 파악하기 위한 모니터링 가시성도 중요합니다. 마지막으로는 배포 파이프라인 성능이 좋을수록 오류를 해결한 버전을 배포하는데에 시간이 덜 들어갈 것입니다.
Datadog, PagerDuty 또는 Sentry 와 같은 모니터링 및 사고 관리 플랫폼은 사고 해결 시간에 대한 타임스탬프와 데이터를 제공할 수 있습니다.
안정성(Reliability):
애플리케이션의 전반적인 가동 시간과 성능을 추적하여 서비스의 안정성을 측정합니다. 또한 모니터링 도구, 로그 분석, 사용자 피드백을 활용하여 시스템의 안정성을 측정합니다.
기본적으로 안정성은 정확히 수치화해서 측정할 수는 없습니다. 가용성, 대기 시간, 성능 및 확장성을 포함하여 성능을 평가하는 데 사용되는 여러 측정항목으로 구성되기 때문입니다. 예를들어 평균 실패 간격(Mean Time Between Failures, MTBF)/평균 복원 시간(Mean Time To Recovery, MTTR)/평균 인지 시간(Mean Time To Acknowledge, MTTA) 등 안정성에 영향을 주는 지표를 계산하고 참고하여 정량화합니다.
MTBF = {총 운영된 시간}/{총 장애횟수}
MTTR={총 장애시간}/{총 장애 횟수}
MTTA={장애발생으로부터 작업시작까지 걸리는 시간의 합}/{총 실패 횟수}
활용: 성과개선
도라 메트릭을 개발자 개인과 조직의 성과 개선을 위해 사용하기에 앞서서 측정의 자동화가 필요합니다. 도입 초기의 수치를 측정하고 성과를 개선할 수 있는 작업들을 진행하며 어떤 방향으로 개선을 해야 할지, 지금 가고 있는 방향이 맞는지에 대해 판단하기 위해 연속적으로 지표 변화를 관찰해야 합니다.
이를 매번 수동으로 히스토리로부터 수치를 추출하고, 계산하고, 정리하는 과정을 반복해야 한다면 개선의 의도와 다르게 이것은 고통스러운 일이 될 것입니다. 이를 위해 지금은 Gitlab 에서 제공하는 DORA Metrics Analytics 나 생산성 SaaS 인 waydev 와 같은 도구들을 사용할 수 있습니다. 하지만 측정된 수치에서 인사이트를 도출하는 것은 여전히 사용자의 몫임을 기억해야 합니다.
또한 규제가 심한 산업의 환경(예: 금융산업)을 개선작업을 하지 않기 위한 핑계로 활용하지 않도록 주의해야합니다. 예를들어 배포 프로세스의 규제는 표준화된 배포 방식과 릴리즈 트레인 등의 방법으로, 개발환경에 대한 규제는 인트라넷 패키지 매니징 서버 구축 등의 방법으로 해결할 수 있을 것입니다.
개선을 위해 무엇을 해야할 지는 The Accelerate State of DevOps Report 2023 에서 더 자세하게 확인해볼 수 있습니다.
활용: 성과평가
도라 메트릭을 도입 해보려는 조직에서 자주 하는 실수는 이 지표들을 통해 측정된 수치의 등락을 숫자 그대로 반영하려는 시도입니다. 측정된 값이 평가의 근거가 될 수는 있어도 값이 곧바로 평가 점수가 되어서는 안됩니다.
도라 메트릭은 기본적으로 평가 도구가 아닌 측정 도구입니다. 도라 메트릭은 안정성과 처리량에 대한 정도를 정량적으로 제공하고 개선할 수 있는 방향을 알려주는 일종의 나침반 역할을 할 수 있습니다.
조직이 개인과 조직의 성과를 측정 하기로 결정하고 도라 메트릭으로 측정을 시작했다면 조직은 계산된 수치가 나타내는 맥락보다 수치의 숫자 자체에 과도하게 반응할 수 있습니다. 이로 인해 단순하게 수치를 높이기 위한 단면적인 작업들이 진행되고 수치와 비즈니스 결과가 분리될 수 있습니다(a.k.a 굿하트의 법칙).
굿하트의 법칙 [Goodhart’s law]
지표의 통계적 규칙성이 그것을 정책목표로 삼고 규제하기 시작하는 순간 사라진다는 이론
만약 평가를 위해 도라 메트릭을 활용한다면 먼저 조직에서 배포 및 사고에 대한 패턴을 파악하여 어떤 기준을 더 높게 볼 것인지 등 기준을 정의해야 합니다. 모든 지표를 동일한 가중치로 추적하는 대신 비즈니스 가치를 높일 가능성이 가장 높은 지표에 먼저 집중해야합니다.
또한 개선을 위한 상황과 동일하게 측정의 자동화가 필요합니다. 평가 주기에 다다랐을 때 에서야 밀린 지표들을 측정하는 것은 상태를 진단하여 문제가 있는 부분을 발견하고, 발견한 문제의 해결책을 제시하고 실행하거나 문제가 된 부분을 개선하고, 평가를 받은 대상의 더 나은 미래를 대비하기 위한 평가의 의도에 반합니다. 연속적이고 자동화된 측정으로써 평가의 대상의 처음 상태에서 지금까지 어떤 식으로 일해오고 성장해왔는지를 알 수 있어 늘 ‘나아지려고 하는 성질’ 을 가지고 있는지를 확인해볼 수 있습니다.
뿐만 아니라 수동으로 측정을 수행할 때에 조직의 규모에 따라서도 문제가 발생할 수 있습니다. 예를들어 최소 5명이상의 개발자를 가진 조직이라면, 각각의 수치를 평가 주기에 와서야 추출하고 정리하는데에 명당 6시간이 든다고 가정 했을 때에 총 30시간을 들여야 비로소 평가를 위한 아주 기본적인 지표를 얻을 수 있다는 규모의 비효율에 맞닥뜨릴 수 있습니다.
마지막으로 도라 메트릭은 10년의 세월로 입증되었고 실제로 동작해온 좋은 지표이지만 이 지표를 측정하며 개선된 많은 조직들은 절대로 여기에만 매몰 되지는 않았었으므로 도라 메트릭만을 조직의 평가 기준으로 삼지 말라는 말씀을 드리고 싶습니다.
그럼에도 도라 메트릭은 팀의 진행 상황을 보여주는 훌륭한 방법이며 이러한 지표는 개발자, 비즈니스 담당자 및 최종 사용자를 하나로 모으는 개발 및 릴리스 프로세스의 속도, 민첩성 및 탄력성의 지속적인 개선이라는 이점을 제공합니다. 지표의 추세를 관찰하고 추적하면 개인의 성과를 개선하고 팀워크를 활성화하고 비즈니스를 성공시켜 고객에게 더 많은 가치를 제공하는 올바른 결정을 내릴 수 있을 것입니다.
최신 도라 메트릭을 분석해보고 이를 성과 개선을 위해, 그리고 성과의 평가를 위해 올바르게 사용해보는 방향을 확인해보았습니다.
DORA 팀은 도라 메트릭을 적용해보기 전 간단하게 자신의 조직의 레벨을 진단할 수 있는 폼을 준비해뒀으니 재미로라도 한번 해보시는 것을 추천드립니다.
프루퍼(Proofer)
프루퍼(Proofer) 팀은 지금 도라 메트릭(DORA Metrics) 이외에도 성과측정을 위해 연구된 SPACE Framework, DevEx Framework 등 실제로 개선에 도움이 되는것이 증명된 프레임워크들을 기반하여 자동으로 지표들을 측정하고, 측정에 대한 분석을 통해 성과로 변환, 개발자의 성과에 대한 인사이트와 비즈니스 담당자들을 위한 비즈니스 인사이트와 재무적인 인사이트 등을 제공해주는 서비스를 개발하고 있습니다.
다음 아티클 주제로는 SPACE Framework 에 대해 작성해보려 합니다.
DORA Metrics 에 관한 더 자세한 분석과 활용방법 was originally published in 프루퍼 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.