• 목록
• 답변
• 글쓰기

출처 : https://medium.com/proofer-blog/dora-metrics-1-dora-devops-research-and-assessment-%ED%8C%80%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC-ea75c90a29d1

개발자의 생산성을 측정 하려는 시도는 과거부터 이어져 온 바람이자 지금도 꾸준히 연구되고 있는 주제입니다.

그 중에서도 Google Cloud 에서 이를 연구하는 DevOps Research and Assessment 팀이 있습니다. 각 대문자만 따서 “DORA” 팀입니다.

Team DORA(DevOps Research and Assessment)

DORA 팀은 2014년부터 2020년까지 6년 동안 31,000명 이상의 조직 내 전문가를 대상하여 Nicole Forsgren 박사, Jez Humble 및 Gene Kim을 필두로 꾸준히 활동했던 연구팀으로, 

DevOps 기술의 발전을 위한 연구와 소프트웨어 개발 맥락에서 ‘고성능’이 무엇인지를 이해하고 이러한 ‘고성능’을 예측하는 요인에 대한 연구를 수행하기 위해 설립되었습니다. 

이들의 연구 결과는 곧 기술 조직을 평가하고 벤치마킹하기 위한 다양한 데이터 기반 솔루션(Flow, Codacy, waydev …)들의 기초가 됩니다.

2018년에는 DORA가 Google에 인수되었습니다. Google Cloud의 일부가 된 DORA는 이제 데이터 기반 의사결정을 통해 개발자와 경영진 모두 즐거운 경험을 줄 수 있는 방법들을 계속해서 만들어가고 있습니다.

DORA 팀은 연구성과가 담긴 Report 를 매년 각기 다른 테마로 지속하여 발행해왔습니다.

이 아티클에서는 2014년부터 2019년까지 Nicole Forsgren 박사가 이끌었던 DORA 팀의 연간 보고서의 내용을 시간순으로 따라가며 도라 메트릭(DORA Metrics)이 탄생하게 된 배경을 살펴보겠습니다.

State of DevOps Report (2014)

2014년부터 2017년 까지는 puppet 과 협업하여 Puppet Lab 산하에서 매년 State of DevOps Report 를 발행해왔습니다.

다음은 2014년에 이루어진 보고 내용입니다.

DORA 팀은 개발의 성능을 어떻게 측정해야 하는가에 대한 연구를 시작하며 DORA Metrics 의 전신인 Four key metrics 를 제시하였습니다.

사례기반 IT 성능지표 4가지

(Practices Correlated with IT Performance Metrics):

생산성 지표(Throughput Metrics)

배포 빈도(Deployment Frequency)

변경에 걸리는 시간(Lead Time for Changes)

안정성 지표(Stability Metrics)

평균 오류 복구 시간(Mean Time to Recover)

변경 시 실패율(Change Fail Rate)

당시 이 지표들을 달성하기 위해 제시된 방법들은 다음과 같았다고 합니다.

지속적 제공(Continuous Delivery)

소프트웨어가 항상 릴리스 가능한 상태가 되도록 보장하여 언제나 배포 가능하도록 만듭니다.

버전 컨트롤(Version Control)

테스트 및 문제 해결을 위해 소프트웨어 환경을 어디서든 쉽게 재현할 수 있게 만들면 효율적으로 일할 수 있습니다.

테스트 자동화(Automated testing)

안정적이고 커버리지가 높은 테스트 자동화 환경을 구현 해 놓는다면, 시간이 오래걸리는 긴 회귀 테스트 주기 없이 빠르게 배포할 수 있다는 확신을 얻을 수 있습니다.

모니터링 시스템과 애플리케이션 상태 (Monitoring system and application health)

로깅 및 모니터링 시스템을 도입하면 다발적으로 발생하여 검출해내기 힘든 오류를 쉽게 감지하고 오류의 원인이 되는 이벤트를 식별할 수 있습니다. 

또한 임계값 및 변화율 경고를 기반으로 시스템 상태를 사전에 모니터링 해놓는 다면 문제를 사전에 감지하고 대응, 완화할 수 있습니다.

연구는 조사 대상 조직들을 이 metrics 을 기준하여 높은 성과조직/중간 성과조직/ 낮은 성과조직 으로 분류하고 여러가지 

DevOps Transformation 수단들을 도입했을 때 이전 년도와 당해년도 지표의 변화 양상을 분석하여 지표의 타당성을 검증하는 방식입니다.

필자의 의견:

SPRi(소프트웨어 정책연구소)에서 발행한 2014년 한국 SW개발자 현황에 따르면 

이 당시 대한민국에서는 개발자와 SW에 대한 낮은 인식이 가장 중요한 문제점이라고 하였고, SI와 개발자의 수명, 삶의 질을 문제점으로 꼽았습니다. 

제가 2014년에 근무하던 기억에는 기술적인 발전은 둘째치고 근무환경 자체도 화이트 칼라 치고 그다지 좋지 않았고 개발자가 받던 취급은 

‘등대지기’, ‘끝은 치킨집’ 등 열심히 일해도 대우를 받지 못하는 시대가 있었습니다. 

2014년에 제시 되었다는 것을 생각한다면 기술적으로 매우 진일보한 시도라고 생각합니다. 

하물며 아직도 2014년에 제시된 방법들 조차 도입하지 못한 곳이 많이 남아있으니 상대적으로 엄청나게 앞서있다고 볼 수 있겠습니다.

State of DevOps Report (2015)

DORA 팀은 이 Four key metrics 를 토대로 무수한 설문조사와 사례분석에 들어갔고 

2015 년에는 이 metrics 기반의 개선방향을 제시한 회사들이 어떻게 변화 했는지에 대해 추적하여 측정한 결과 

200배 더 짧은 리드 타임으로 30배 더 자주 배포하며 오류가 60배 더 적고 복구 속도가 168배 더 빠르다고 보고하며 제시된 metrics 가 유효함을 증명했습니다.

짧아진 리드타임과 자주 배포할 수 있게 된 팀은 lean management 를 도입할 수 있는 최적의 조건이 되었고 이로써 얻을 수 있는 시너지에 대한 내용도 서술되었습니다.

필자의 의견:

높은 성과를 내는 IT조직은 강한 긍정적인 태도를 가지고 있고 결국 이들이 서비스를 제공하는 기업의 전반적인 성과에 영향을 미친다고 합니다. 

그러고 보면 개발자들은 업무 만족도가 삶의 만족도와 일치된 경우가 많아 충분히 나올 수 있는 결과라고 봅니다. 

또한 자동화를 통해 업무의 속도와 안정성을 향상시키고 프로세스를 명확하게 이해하여 진행하도록 한다면 번아웃을 예방할 수 있다는 결과는 개인적으로 매우 흥미로운 주제입니다.

State of DevOps Report (2016)

2016 년에는 측정에서 그치지 않고 이 metrics 이 높아졌을 때에 정확히 어떤 이점들을 가지게 되는지에 대한 내용을 보고합니다.

높은 성과를 내는 조직은 생산성 측면에서 성과가 낮은 조직보다 metrics 상 더 나은 지표를 보이고 있습니다. 

높은 성과조직이 낮은 성과조직보다 200배 더 자주 배포합니다. 높은 성과조직이 각 변경업무에 걸리는 시간이 더 짧으며, 

오류 발생 시 복구 시간은 24배 빨라지고 변경 실패율은 3배 낮아져 성과가 낮은 보다 계속해서 훨씬 뛰어난 성능을 발휘합니다.

직원 NPS(eNPS)로 측정할 때 성과가 높은 조직은 직원 충성도가 더 높았습니다. 

성과가 높은 조직의 직원들은 자신의 조직을 일하기 좋은 곳으로 지인에게 추천할 확률이 2.2배 더 높았고, 훌륭한 업무 환경으로 자신의 팀을 지인에게 추천할 확률이 1.8배 더 높았습니다.

metrics 로 측정된 성과가 높은 조직들은 계획되지 않은 작업과 재작업에 소요되는 시간을 22% 줄였습니다. 

결과적으로 새로운 기능이나 코드 리팩토링과 같은 새로운 작업에 29% 더 많은 시간을 할애할 수 있었고 비용 또한 줄일 수 있었습니다.

재작업에 드는 비용(Cost of excess rework) = 개발자 인원 수(Technical staff size) × 평균연봉(Average salary) × 복지혜택(Benefits multiplier) × 재작업에 소요되는 시간(Percentage of technical staff time spent on excess rework)

그 이외에도, 조직 성과를 향상시킬 수 있었습니다. 

짧은 제품 개발 주기는 제품과 기능을 작은 배치로 분해하는 제품 팀의 능력 아이디어에서 생산까지 작업 흐름에 대한 가시성을 제공했고 고객 피드백을 빠르게 수집하여 반복하고 개선할 수 있게 되었습니다.

높은 성과를 내는 조직은 낮은 성과를 내는 조직보다 보안이슈를 해결하는 데 50% 더 적은 시간을 소비합니다. 

정보 보안 목표를 개발업무에 녹이면서 팀은 더 높은 수준의 보안을 달성하고 보다 안전한 시스템을 구축할 수 있습니다.

뿐만 아니라 상당한 비용 절감 효과를 얻을 수 있습니다. 

모든 리더는 기술 혁신에 투자하면 실질적으로 어떤 수익을 기대할 수 있는지 알고 싶어합니다. 

2016년의 보고에는 주요 지표와 업계 벤치마크를 사용하여 잠재적인 비용 절감을 정량화하는 데 도움이 되는 공식이 제시되었습니다. 

또한 절감된 비용을 기술에 재 투자하기 위한 제안도 제공합니다.

2016년 보고는 단순히 DevOps 성과측정 지표로써의 가설로 제시 되었던 metrics 가 비즈니스적인 성과 및 의사결정에 상관관계가 있다는 것에 의의를 주었고 

그럼으로써 DevOps 의 변화가 Google, Netflix, Amazon 과 같은 유니콘 기업에만 필요한 것이 아닌 개발조직이 있는 모든 기업에 해당된다는 이야기를 하고 있습니다.

필자의 의견:

2년동안 쌓인 데이터를 토대로 이 이론이 동작함을 증명했고, 이 지표가 단순히 성과를 측정하는데에 끝나지 않고 지표가 높은 조직들의 공통점을 분석하여 

DevOps의 성과가 높은 조직들이 곧 구성원들의 만족도도 높고 재무적인 이점도 챙길 수 있다는 연관관계를 제시합니다. 

물론 이 연관관계가 그다지 튼튼하진 않아 보이지만 2024년인 지금 빅테크기업들의 개발자들이 상대적으로 논테크기업들의 개발자에 비해 행복하게 일할 수 있는 것과 비슷한 관측이 아니었을까 생각이 듭니다.

State of DevOps Report (2017)

2017 년 보고 에서는 Four key metrics 를 통한 지표측정 이외에도 2016 년 제시된 이익과 비용 측정을 넘어서 

더 넓은 조직 목표, 즉 목표를 달성하는 능력에 관해서도 이야기합니다. 이는 여전히 DevOps가 비영리 조직이나 정부 조직보다 영리 기업에 더 중요하다는 인식이 있고 이를 타파하기 위함 이었습니다.

IT 매니저의 적절한 리더십 아래 테스트와 배포의 자동화, 지속적인 통합시스템 구축, VCS 트렁크 기반의 개발, 

보안코딩과 느슨하게 결합된 설계, 결정적으로 개발자들에게 적절한 권한을 부여하여 개발자의 지적 호기심을 자극합니다.

이렇게 효율적이게 개선된 시스템의 서포팅 아래 지속적 전달기반을 완성하여 배포에 대한 부담을 줄일 수 있게되고, 

이제 시스템적으로 린 방법론을 적용할 수 있는 환경이 되었으니 팀의 개발경험은 개선되고 아주 작은 배포단위로 배포할 수 있는 점을 활용해 

고객 피드백 사이클을 빠르고 자주 돌려 조직의 목표와 성과도 이룰 수 있다는 도식입니다.

측정으로 돌아와서, 초기 높은 성과를 내던 조직은 계속해서 더 빠른 생산성과 더 나은 안정성을 달성하고 있으며 

낮은 성과를 내던 조직에서 2016년에 비해 배포 빈도와 변경 리드 타임이 향상되었다고 보고함에 따라 생산성 측정에서 높은 성과조직과 낮은 성과 조직 간의 격차가 좁아졌습니다.

그러나 성과가 낮은 조직은 오류 복구 시간이 느리고 실패율이 더 높다고 보고되었습니다. 

원인으로는 단순하게 metrics 의 지표만 올리려는 생각에 더 빠르고 더 자주 배포해야 한다는 압박으로 인해 오히려 개발환경의 품질 획득에 충분한 관심을 기울이지 못하게 되는 현상이 관측 되었다고 합니다.

따라서 2017년의 보고서는 단순하게 metrics 를 수동으로 올리는 것에 집중할 것이 아니라 테스트&배포 자동화, 

보안코딩에 대한 인식, 확장성이 고려된 설계, 지속적인 통합과 트렁크 기반의 통합방법론 등 실질적인 방법들을 통해 먼저 자동화를 시켜야 할 필요가 있음을 강조하고 있습니다.

필자의 의견:

인터넷 밈중에 이런것이 있습니다. “가정이 무너지고…사회가무너지고…가정이 황폐화되고 이러한 현실 속에서…”

환경변화의 연쇄효과에 대한 밈인데, 조직도 마찬가지인 것 같습니다. 

개발자가 일하기 편하고 즐거운 환경을 만들면 개발자가 만드는 서비스 퀄리티가 올라가고, 서비스 퀄리티가 올라가면 고객이 만족하고, 

고객이 만족하면 비즈니스가 성공하죠. DORA 팀은 계속해서 이 점을 강조하고 있습니다.

DORA, Google Cloud에 합류

DORA Joins Google Cloud

DevOps Research and Assessment (DORA) is a long running research program that seeks to understand the capabilities that…

dora.dev

We are super excited to announce that DevOps Research and Assessment (DORA) has been acquired by Google. As part of Google Cloud, DORA will continue to create delightful experiences for developers and operators through data-driven insights that deliver value using DevOps in the cloud.

2018년 12월 20일 당해 보고서 발행에 앞서 DORA 팀은 Google 에 인수 되었다는 소식으로 시작합니다.

DORA 팀은 앞으로 DevOps 의 흐름에 cloud 가 빠질 수 없겠다는 것을 인지하고 있었고 Google 은 Google Cloud 를 서비스 하면서 

많고 다양한 회사들이 in-house 환경에서 cloud 로 이동하는 것의 부스팅을 DORA 팀이 함께해주는 것을 기대하여 상호간에 뜻을 맞추게 되었습니다.

당시 Google의 엔지니어링 담당 부사장이었던 Melody Meckfessel 는 “우리는 항상 최고의 개발자 및 운영자 경험을 제공하고 이를 실현하기 위한 도구 및 워크플로에 투자하여 

전 세계 팀이 광범위하게 액세스할 수 있도록 하는 데 중점을 두었습니다.”

“DORA가 Google Cloud 제품군에 합류하여 개발자와 운영자가 생산성과 근무 만족도를 파악하기 위한 데이터 기반 접근 방식을 강화하는 데 도움을 줄 수 있게 되어 기쁩니다.” 라고 말합니다.

Accelerate: State of DevOps(2018)

2018년 보고에서는 지금까지 측정해왔던 기준인 높은 성과조직/중간 성과조직/낮은 성과조직에서 특별히 유난히 높은 수치를 보이고 있는 

조직들을 엘리트 성과조직으로 새로 배정하여 측정하기 시작했다고 합니다.

Google 조직 스스로 우리는 엘리트라고 불러줘 라고 하지 않았을까 하는 재미난 의심을 해봅니다