“개발자 거부감 없이 성과 측정하기” 도라(DORA) 메트릭이 인기 있는 이유

오래전부터 소프트웨어 엔지니어링 팀은 개발자에게 감시당하고 있다는 느낌을 주지 않으면서 개선에 실질적인 도움이 되는 하드 메트릭(hard metrics)으로 개발 효율성을 측정할 방법을 모색해왔다. 그 노력이 이제 결실을 보고 있다. 개발자라면 누구나 업계에 만연한, 작성한 코드 라인 수, 병합된 풀 요청 수와 같은 모호한 메트릭을 기반으로 한 성과 측정 방식의 고충 또는 잠재적 어려움을 잘 알 것이다. 또한 엔지니어링 관리자라면 누구나 이와 같은 방식이 팀에 불러일으킬 수 있는 반발과 불신에 대해서도 잘 안다. 
 

그러나 이사회, 엔지니어링 리더는 물론 개발자 역시, 프로세스가 잘 움직이고 있는지, 팀이 효율적인지, 그리고 어떻게 더 개선할 수 있을지 알고 싶어한다. 결국 진행 중인 작업의 성과를 어떤 방식으로든 측정할 방법은 필요하다. 이를 위해 다양한 메트릭과 프레임워크, 모범 사례가 등장했고 필연적으로 각 방식 간의 우열도 드러났다. 핵심은 개발자가 이미 매일 다루는 툴과 시스템으로 작업 성과를 측정하는 것인데, 도라(DORA, DevOps Research and Assessment) 메트릭을 사용하면 바로 이것이 가능하다. 도라가 업계 표준으로 부상하고 있는 이유도 여기에 있다. 

일단 DORA 외의 다른 메트릭 유형부터 알아보자. 
 

분주함 메트릭 

분주함(Busyness) 메트릭은 개발자의 흐름 시간(flow time)을 측정하는 것이다. 하루에 두세 번 흐름이 끊긴다면 일을 제대로 해내기가 거의 불가능한 것으로 본다. 개발자의 시간을 보호하기 위해 노력하는 과정에서 HR 시스템과 캘린더에 연결되는 '엔지니어링 효율성 툴'이라는 하나의 범주가 만들어졌다. 이런 툴은 개발자의 컨텍스트 전환, 회의, 그리고 시간을 잡아먹는 프로세스가 너무 많은지를 살펴본다.

궁극적으로 이러한 메트릭은 코딩의 인간적 측면을 살펴봄으로써 번아웃을 방지하고자 한다. 분명 중요한 부분이지만 문제는 행동으로 옮기기에 썩 적합하지는 않다는 것이다. 개발자들이 너무 많은 회의에 참석하고 있다는 것을 안다 해도, 필요한 회의를 하면서 흐름의 효율성도 높은 환경을 어떻게 구성할 수 있을까? 분주함 메트릭에는 가이드가 될 가능한 개선 방안이 빠져 있다. 
 

스페이스 프레임워크 

스페이스(SPACE) 프레임워크는 DORA(DevOps Research Assessment)의 설립자 중 한 명인 니콜 포스그렌이 개발자 생산성을 파악하기 위해 개발했다. 하드 메트릭 대신 개발자의 심리적 상태와 신체적 웰빙에 초점을 둔다. 이런 메트릭은 개발자가 일에 대해 전반적으로 느끼는 즐거움과 팀의 엔지니어링 성과에 있어 중요하다.

구체적으로 스페이스 프레임워크는 개발자 생산성의 다음과 같은 5가지 측면을 측정한다. 앞 글자를 따면 스페이스(SPACE)가 된다.
 

• 만족도(Satisfaction) : 일, 툴, 팀, 문화에 대한 만족도, 웰빙 
• 성과(Performance) : 시스템 또는 프로세스의 성과 
• 활동(Activity) : 수행할 활동의 양을 결과물과 작업 측면에서 측정 
• 소통 및 협업(Communication and collaboration) : 소프트웨어 개발팀 전반의 협업 프로세스 및 지원 
• 효율성 및 흐름(Efficiency and flow) : 소프트웨어 개발자가 작업을 진행할 수 있는 수준 

분주함 메트릭과 마찬가지로 스페이스 프레임워크도 포착하는 정보 자체는 유효하지만 이를 기반으로 뭔가 조처를 하기는 어렵다. 현재 수행 중인 작업에서 측정하기 어려운 모범 사례라고 생각하면 된다. 간결함과 목표 지향적 결과가 빠져 있다. 
 

전통적인 메트릭 

지금까지 살펴본 메트릭은 작성한 코드 라인 수, 병합된 풀 요청 수, 코딩에 소요한 시간 등 개발자의 실질적인 노력을 포착하지 못하는 하드 메트릭이다. 최소한의 지시로 작업을 완료한 개발자가 리더가 되는 펀치 카드 프로그래밍 시절에 만들어졌다. 

그러나 개발자는 이런 지표가 실질적으로 중요한 성과를 측정하지 못한다는 것을 알고 있다. 애플리케이션에서 가장 중요한 코드 5라인을 너무 복잡해서 작성하는 데 꼬박 2주가 걸릴 수도 있다. 반대로 500만 라인의 코드를 작성하더라도 그 가치는 미미할 수 있다. 병합된 풀 요청의 수를 측정하는 것도 마찬가지다. 전체적인 배치 크기에 대해 알려주는 부분은 있지만 팀이 개선하도록 돕는 데는 거의 쓸모가 없다. 

따라서 이와 같은 측정값으로 개발자의 성과를 판단한다면 개발자는 회사가 자신 또는 자신의 일을 이해하지 못한다고 생각하기 쉽다. 게다가 측정이 개인 단위로 이뤄질 경우 조직에 독이 된다. 개발자는 감시당하고 평가된다는 느낌을 받고 반감을 갖게 된다.
 

가치 흐름 메트릭 

가치 흐름(value stream) 메트릭의 목적은 엔지니어링 투자의 분포, 즉 투자가 어디로 가는지를 파악하는 데 있다. 이는 특히 조직이 정부로부터 연구개발에 대해 세제 혜택을 받기 때문에 연구개발과 버그 수정, 운영 등에 투입된 작업을 분류해야 하는 경우 유용하다. 이런 메트릭은 팀의 개선을 도울 방법을 알아내는 것보다는 팀이 어디에 투자하고 있는지를 파악하는 데 중점을 둔다. 
 

도라 메트릭 

앞서 언급한 다양한 메트릭이 모두 쓸모없는 것은 아니다. 그런데 많은 팀과 조직이 도라 메트릭을 대신 도입하는 이유는 무엇일까? 도라의 개념과 이것이 중요한 이유는 다음 6가지로 정리할 수 있다.
 

1. 연구로 뒷받침된다. 다양한 연구결과를 보면 긍정적인 도라 메트릭과 긍정적인 조직 성과 간에 통계적으로 유의미한 상관 관계가 있음을 보여준다. 도라 메트릭은 육감이 아니다. 
2. 도라 메트릭은 우리가 오랜 시간 적용해 온 데브옵스 관행을 간결하게 구체화하며 지속적인 개선과 학습 측면에서 팀이 얼마나 잘 하고 있는가를 보여준다. 예를 들어 우리는 그동안 관행을 통해 배치 크기를 줄이면 더 빠르게 작업을 완수할 수 있고 더 효과적임을 알아냈다. 도라는 이를 배포 빈도, 변화 리드 시간, 변화 실패율, 평균 복구 시간 등 여러 메트릭 범주로 분류하고 각각이 어떻게 상호 관련되는지를 보여줬다. 실무자 관점에서 보면 도라 메트릭은 개발자가 항상 해왔던 일들에 이름을 붙여준 것이다. 
3. 도라 메트릭은 단순함을 유지한다. 기업은 엔지니어링 관점에서 무엇을 측정할지 결정할 때 교착 상태에 빠지는 경우가 많다. 도라를 사용하면 업계 벤치마크로 잘 정의된 메트릭으로 시작할 수 있고 축적된 집단의 지혜를 활용할 수 있다. 
4. 도라 메트릭은 팀 메트릭이므로 개인별 메트릭에서 개발자가 느끼는 부담과 우려에서 벗어난다. 도라 메트릭도 여전히 개인 성과 측정에 사용할 수 있지만, 기본적으로 소프트웨어 개발을 팀 스포츠로 본다. 도라와 데브옵스 현황 보고서를 읽어보면 알겠지만 모두 팀에 관한 내용이다. 
5. 도라 메트릭은 복잡한 활동을 간단한 하드 측정값으로 추출한다. 소스 제어, 소스 리뷰 시스템, 이슈 트캐커, 사고 관리 공급자 및 메트릭 툴의 데이터를 가져와서 이를 4개의 주요 측정값으로 변환할 수 있다. 따라서 모든 팀이 같지는 않겠지만 한 팀의 도라 메트릭을 다른 팀과 비교할 수 있다. 도라 연구를 통해 팀은 앞서 언급한 4개의 주요 메트릭에 대한 수행 실적을 기반으로 스스로를 낮음, 중간, 높음 성과 범주에 넣을 수 있다. 이를 통해 다른 팀과 비교한 성과 수준도 산출할 수 있다.
6. 도라 메트릭은 개발자 프로세스와 그 프로세스가 사용자에 얼마나 잘 이행되는지를 포함하여 넓은 범위를 포괄한다. 도라 메트릭은 개발자가 코딩을 시작하는 시점부터 팀이 프로덕션에 결과물을 제공하는 시점까지의 프로세스를 살펴본다. 이 메트릭은 누구도 “되든 말든 무조건 빠른” 접근 방식을 택하기를 원하지 않는다는 것을 인정한다. 도라 메트릭은 “빠르되 책임감 있는”, 더 건전한 접근 방식을 장려한다. 

도라 메트릭을 포함해 어떤 메트릭도 최고의 엔지니어링 팀이 되는 만능 열쇠가 아니다. 그러나 도라 메트릭은 소프트웨어 업계가 소프트웨어 제공 및 운영 성과에 대해 개발자가 거부감을 느끼지 않는 방식으로, 어쩌면 좋아할 수도 있는 방식으로 과학적인 측정 시스템을 구축하는 데 일익을 담당한다.
editor@itworld.co.kr