소프트웨어 개발 조직에서 '생산성'이라는 말을 자주 사용합니다.
하지만 개발 생산성이 정확히 무엇을 의미하는지 설명하려고 하면 생각보다 간단하지 않습니다.
코드를 많이 작성하는 것이 생산성일까요? 기능을 빠르게 출시하는 것이 생산성일까요? 장애 없이 안정적으로 서비스를 운영하는 것일까요? 아니면 개발자가 업무에 집중하고 원활하게 협업할 수 있는 환경까지 포함해야 할까요?
개발 생산성을 단순한 작업량만으로 설명하기 어려운 이유입니다.
이러한 개발 조직의 성과와 생산성을 보다 체계적으로 이해하기 위해 활용되는 대표적인 접근법이 DORA와 SPACE 프레임워크입니다.
이번 글에서는 두 프레임워크의 우열이나 차이를 비교하기보다, DORA와 SPACE가 각각 무엇이며 개발 조직을 어떤 관점에서 바라보는지 기본 개념부터 살펴보겠습니다.
DORA와 SPACE란 무엇인가요?
먼저 핵심만 정리하면 다음과 같습니다.
DORA는 소프트웨어가 사용자에게 전달되는 과정의 성과를 측정하는 데 활용되는 지표 체계이며, SPACE는 개발자 생산성을 다섯 가지 차원에서 이해하기 위한 프레임워크입니다.
DORA에서는 배포와 변경, 실패 및 복구와 관련된 데이터를 통해 소프트웨어 전달 시스템의 상태를 살펴봅니다.
SPACE에서는 만족도와 웰빙, 성과, 활동, 커뮤니케이션과 협업, 효율성과 흐름이라는 다섯 가지 차원을 통해 개발 생산성을 보다 입체적으로 이해합니다.
두 접근법을 이해하면 개발 생산성을 단순히 '개발자가 얼마나 많이 일했는가'가 아니라, 개발 조직이 어떤 방식으로 가치를 만들어내고 있는가라는 관점에서 바라볼 수 있습니다.
DORA란 무엇인가요?
DORA는 DevOps Research and Assessment의 약자입니다.
DORA 연구는 소프트웨어를 빠르고 안정적으로 전달하는 조직에는 어떤 특징이 있는지를 장기간 연구하면서 발전해 왔습니다.
DORA의 핵심적인 특징은 개발자 개인의 업무량을 측정하는 것이 아니라, 하나의 애플리케이션이나 서비스가 변경 사항을 얼마나 빠르고 안정적으로 사용자에게 전달하는지 관찰한다는 것입니다.
예를 들어 개발 자체는 빠르게 이루어지고 있지만 실제 서비스에 반영되기까지 오랜 시간이 필요하다면 전달 과정 어딘가에 병목이 있을 가능성이 있습니다.
반대로 매우 자주 배포하고 있지만 배포 이후 문제가 반복적으로 발생한다면 전달 속도뿐 아니라 안정성 역시 함께 살펴봐야 합니다.
DORA는 이런 상태를 데이터로 파악할 수 있도록 소프트웨어 전달 성과(Software Delivery Performance)를 측정합니다. 현재 DORA는 이를 Throughput과 Instability라는 두 영역의 다섯 가지 지표로 설명하고 있습니다.
현재 DORA의 5가지 지표는 무엇인가요?
1. Change Lead Time — 변경 리드 타임
코드 변경이 버전 관리 시스템에 커밋된 이후 실제 프로덕션 환경에 배포되기까지 걸리는 시간입니다.
변경 사항이 실제 사용자에게 전달되기까지 얼마나 빠르게 흐르고 있는지를 이해하는 데 활용됩니다.
2. Deployment Frequency — 배포 빈도
일정 기간 동안 프로덕션 환경에 얼마나 자주 변경 사항을 배포하는지를 나타냅니다.
개발된 변경 사항을 실제 사용자에게 얼마나 지속적으로 전달하고 있는지 확인할 수 있습니다.
3. Failed Deployment Recovery Time — 실패한 배포 복구 시간
배포로 인해 문제가 발생했을 때 정상적인 서비스 상태로 회복하기까지 걸리는 시간을 의미합니다.
과거에는 MTTR(Mean Time to Recovery)이 널리 사용되었지만, 현재 DORA는 소프트웨어 변경으로 인해 발생한 문제의 복구에 보다 명확하게 초점을 맞추고 있습니다.
4. Change Fail Rate — 변경 실패율
프로덕션에 이루어진 배포 중 즉각적인 수정이나 롤백 등의 조치가 필요한 문제를 일으킨 비율을 나타냅니다.
배포 속도만이 아니라 변경 사항이 얼마나 안정적으로 전달되고 있는지를 살펴보기 위한 지표입니다.
5. Deployment Rework Rate — 배포 재작업률
프로덕션에서 발생한 문제를 해결하기 위해 이루어진 계획되지 않은 배포의 비율입니다.
DORA는 2024년 이 지표를 추가하면서 기존의 Four Keys에서 현재의 5개 지표 체계로 발전했습니다.
DORA는 왜 Throughput과 Instability를 함께 볼까요?
DORA의 다섯 가지 지표는 크게 두 영역으로 나뉩니다.
Throughput은 변경 사항이 소프트웨어 전달 시스템을 얼마나 원활하게 통과하는지를 보여줍니다.
여기에는 변경 리드 타임, 배포 빈도, 실패한 배포의 복구 시간이 포함됩니다.
반면 Instability는 배포 과정에서 얼마나 많은 문제가 발생하고 있는지를 살펴봅니다.
여기에는 변경 실패율과 배포 재작업률이 포함됩니다.
이렇게 나누는 이유는 개발 성과를 단순히 '더 빠르게 배포하는 것'으로 정의하지 않기 위해서입니다.
빠르게 변경 사항을 전달하면서도 문제가 반복적으로 발생한다면 좋은 소프트웨어 전달 시스템이라고 보기 어렵습니다.
따라서 DORA에서는 변경을 전달하는 능력과 그 과정에서 발생하는 불안정성을 함께 살펴봅니다.
SPACE 프레임워크란 무엇인가요?
DORA가 소프트웨어 전달 시스템을 이해하는 방법을 제시한다면, 개발 생산성 자체를 보다 넓게 이해하려는 연구도 있습니다.
대표적인 것이 SPACE 프레임워크입니다.
SPACE는 GitHub와 Microsoft 등의 연구자들이 참여해 제안한 개발자 생산성 프레임워크입니다.
이 프레임워크의 중요한 출발점은 다음과 같습니다.
개발자 생산성은 하나의 지표나 활동량만으로 설명할 수 없다.
개발자의 업무에는 코드 작성만 존재하지 않습니다.
설계하고, 문제를 해결하고, 코드를 검토하고, 다른 개발자와 지식을 공유하며, 여러 팀과 협업합니다.
따라서 코드 라인 수나 커밋 수처럼 측정하기 쉬운 하나의 숫자만으로 개발자의 생산성을 정의하면 실제 개발 업무의 상당 부분을 놓칠 수 있습니다.
SPACE는 이러한 개발 생산성을 다섯 가지 차원으로 바라봅니다.
SPACE의 5가지 영역은 무엇인가요?
SPACE라는 이름은 다음 다섯 영역의 앞 글자에서 만들어졌습니다.
S — Satisfaction and Well-being
개발자가 자신의 업무와 조직, 업무 환경에 대해 어떻게 느끼고 있는지를 살펴보는 영역입니다.
업무 만족도, 몰입도, 번아웃과 같은 요소가 포함될 수 있습니다.
중요한 것은 개발자가 단기적으로 많은 일을 수행하고 있는지만 보는 것이 아니라 지속적으로 좋은 성과를 만들어낼 수 있는 환경에 있는지도 함께 살펴보는 것입니다.
P — Performance
개발 활동을 통해 만들어진 결과와 가치를 바라보는 영역입니다.
단순히 얼마나 많은 코드를 작성하거나 기능을 출시했는지가 아니라, 개발 결과물이 품질이나 사용자 경험, 비즈니스 성과 등에 어떤 영향을 만들어냈는지를 살펴봅니다.
즉, “얼마나 많이 만들었는가?”보다 “무엇을 만들어냈는가?”에 더 가까운 관점입니다.
A — Activity
개발 과정에서 발생하는 다양한 활동을 의미합니다.
예를 들면 코드 작성, 커밋, 코드 리뷰, 테스트, 배포 등이 있습니다.
Activity 데이터는 실제 개발 과정에서 어떤 일이 이루어지고 있는지 이해하는 데 도움이 될 수 있습니다.
하지만 SPACE에서 Activity는 생산성 그 자체가 아니라 생산성을 이해하기 위한 하나의 신호입니다.
PR 수가 두 배가 되었다고 해서 개발 생산성이 두 배가 되었다고 판단할 수 없는 이유입니다.
C — Communication and Collaboration
소프트웨어 개발은 여러 사람이 함께 수행하는 작업입니다.
코드 리뷰, 설계 논의, 지식 공유, 팀 간 의사결정 등 다양한 협업이 이루어집니다.
따라서 SPACE에서는 개발자가 얼마나 효과적으로 정보를 공유하고 함께 문제를 해결하고 있는지도 생산성을 이해하는 중요한 영역으로 봅니다.
E — Efficiency and Flow
개발자가 업무를 수행하는 과정에서 얼마나 원활하게 작업이 진행되고 있는지를 살펴봅니다.
예를 들어 다음과 같은 상황은 개발 흐름을 방해할 수 있습니다.
잦은 업무 전환, 긴 리뷰 대기 시간, 반복적인 승인 절차, 불필요한 회의, 부족한 개발 도구 등이 대표적입니다.
Efficiency and Flow는 단순히 업무를 더 빨리 처리하는 것이 아니라, 개발자가 중요한 업무에 집중하고 작업을 지속적으로 진행할 수 있는 환경인가를 바라봅니다.
SPACE에서 가장 중요한 개념은 무엇인가요?
SPACE를 처음 접하면 다섯 가지 항목을 새로운 KPI 목록처럼 이해하기 쉽습니다.
하지만 SPACE의 핵심은 S·P·A·C·E 다섯 개의 숫자를 만들어 관리하는 것이 아닙니다.
오히려 반대에 가깝습니다.
개발자 생산성을 단일한 숫자로 단순화하지 말고 여러 차원의 신호를 함께 살펴봐야 한다는 것이 SPACE의 중요한 메시지입니다.
예를 들어 Activity만 본다면 커밋이 많고 PR을 많이 생성하는 개발자가 생산성이 높은 것처럼 보일 수 있습니다.
하지만 Performance까지 살펴보면 그 활동이 실제 좋은 결과로 이어졌는지 확인해야 합니다.
Efficiency and Flow를 함께 본다면 그러한 성과를 만드는 과정에서 지나치게 많은 방해나 대기가 발생하고 있지는 않은지도 살펴볼 수 있습니다.
Satisfaction and Well-being까지 고려한다면 현재의 성과가 지속 가능한 방식으로 만들어지고 있는지도 질문할 수 있습니다.
즉 SPACE는, “개발 생산성을 어떤 하나의 숫자로 측정할 것인가?” 보다
“개발 생산성을 이해하기 위해 어떤 여러 신호를 함께 봐야 하는가?”
라는 질문을 던지는 프레임워크에 가깝습니다.
DORA와 SPACE를 이해하면 개발 생산성을 보는 관점이 어떻게 달라질까요?
DORA와 SPACE를 처음 배우는 데 의미가 있는 이유는 단순히 새로운 지표의 이름을 알게 되기 때문이 아닙니다.
두 접근법은 공통적으로 개발 생산성을 단순한 개발자의 작업량과 동일시해서는 안 된다는 관점을 이해하는 데 도움을 줍니다.
개발 조직의 성과를 이해하려면, 소프트웨어가 실제 사용자에게 어떤 방식으로 전달되고 있는지, 그 과정에서 얼마나 안정적인지를 살펴봐야 합니다.
동시에 개발자가 어떤 환경에서 일하고 있으며, 어떤 결과를 만들고 있고, 어떻게 협업하고 있는지도 생산성을 이해하는 중요한 정보가 될 수 있습니다.
그래서 개발 생산성 측정은 결국 숫자를 많이 모으는 문제라기보다 어떤 현상을 이해하기 위해 어떤 신호를 볼 것인지 결정하는 문제에 가깝습니다.
실제로 DORA 역시 측정 프레임워크를 조직 변화의 수단으로 활용하고, 조직이 달성하려는 목표에 따라 적절한 측정 방식을 선택할 것을 강조하고 있습니다.
DORA와 SPACE에 대해 자주 묻는 질문
Q. 현재 DORA 지표는 몇 개인가요?
현재 DORA의 Software Delivery Performance Metrics는 5개입니다. Change Lead Time, Deployment Frequency, Failed Deployment Recovery Time, Change Fail Rate, Deployment Rework Rate로 구성됩니다. 2024년 Deployment Rework Rate가 추가되면서 기존 Four Keys에서 5개 지표 체계로 확장되었습니다.
Q. SPACE의 다섯 영역을 모두 KPI로 관리해야 하나요?
SPACE의 핵심은 다섯 가지 항목을 각각 하나의 KPI로 만드는 것이 아닙니다. 개발 생산성을 하나의 지표로 정의하지 않고 여러 차원의 신호를 활용해 이해하는 데 목적이 있습니다.
Q. 커밋이나 PR 수는 개발 생산성 지표인가요?
커밋이나 PR 수는 개발 활동을 보여주는 데이터로 활용할 수 있지만, 그것만으로 개발 생산성을 판단하기는 어렵습니다. 어떤 결과가 만들어졌는지, 협업과 업무 흐름은 어떠한지 등 다른 정보와 함께 해석할 필요가 있습니다.
DORA와 SPACE는 '생산성의 숫자'보다 '생산성을 보는 관점'을 제공합니다
DORA와 SPACE를 처음 접하면 다양한 지표와 용어가 먼저 눈에 들어옵니다. 하지만 두 프레임워크를 이해할 때 더 중요한 것은 각각의 숫자를 외우는 것이 아닙니다.
-
DORA는 소프트웨어 전달 시스템을 어떤 데이터로 관찰할 수 있는지 보여줍니다.
-
SPACE는 개발자 생산성을 하나의 지표로 단순화하지 않고 어떤 차원에서 바라봐야 하는지 보여줍니다.
따라서 두 프레임워크를 이해하는 것은 개발 조직의 생산성을 평가하기 위한 점수표를 만드는 것보다, 현재 개발 조직에서 일어나고 있는 일을 더 정확하게 이해하기 위한 관점을 배우는 과정에 가깝습니다.
그렇다면 다음 질문이 생깁니다.
DORA와 SPACE는 정확히 무엇이 다르고, 실제 개발 조직에서는 어떤 관점과 지표를 선택해야 할까요?
다음 글 「 DORA 지표와 SPACE 프레임워크의 차이: 개발 생산성을 어떻게 측정해야 할까? 」에서는 DORA와 SPACE의 차이, 각각의 장점과 한계, 어떤 상황에서 활용하면 좋은지, 그리고 두 접근법을 함께 활용하는 방법까지 구체적으로 살펴보겠습니다.