개발자 생산성은 IT 업계에서 언제나 뜨거운 화두입니다. 이는 소프트웨어 개발 프로젝트의 성공과 기업의 비즈니스 발전에 영향을 미치고요. 개발자의 자기 계발과 직무 만족도 향상과도 밀접한 관련이 있죠. 조직과 개인 모두 개발자 생산성을 높이는 데 이견은 없습니다. 그러나 ‘이를 어떻게 측정하고, 무엇을 기준으로 생산성을 판단할지’를 두고 치열한 갑론을박이 펼쳐지기도 하죠.
이 글은 개발자 생산성의 중요성과 측정 필요성을 짚고요. DORA 지표, SPACE 프레임워크 등 전통적인 개발자 생산성 지표와 맥킨지의 기회 지향 지표, Linkedin, Uber, Spotify 등 17개 유명 기술 기업의 개발자 생산성 지표를 살펴보고자 합니다. 아울러 개발자 생산성을 측정할 때 고려 사항을 알아보고요. 인포그랩이 Value Stream Mapping 방식으로 내부 프로젝트인 ‘전문가 실험실’의 개발 활동을 분석, 개발 생산성을 향상한 사례를 공유하겠습니다.
개발자 생산성은 뭐고, 왜 중요할까?
개발자 생산성(Developer Productivity)은 ‘특정 기간 안에 양질의 코드를 생산하고, 관련 작업을 완료하는 소프트웨어 개발팀의 역량을 측정하는 척도’입니다. 이는 소프트웨어 개발자의 개별 성과뿐만 아니라 전체 팀의 효율성, 협업, 체계성을 뜻하기도 하죠. 아울러 개발자 생산성은 ‘기업의 비즈니스 성과와 직접 관련된 코드를 능숙하게 생산하고 제공하는 개발팀 능력을 측정한 것’이기도 하고요. 또 ‘개발팀이 효율적으로 개발한, 품질이 좋고 안정적인 소프트웨어 양’을 뜻하기도 합니다.
개발자 생산성의 중요성
개발자 생산성은 소프트웨어 개발 프로젝트의 성공과 개발팀의 성과에 중요한 역할을 하죠. 개발자 생산성이 높아지면 개발 속도가 빨라지는 건 물론이고요. 문제를 해결하고, 기업의 비즈니스를 발전시킬 수 있습니다. 미국 엔지니어링 분석 플랫폼 기업 Hatica는 개발자 생산성이 중요한 이유를 다음과 같이 설명했는데요.
-
시간·비용 효율화
개발자 생산성을 향상하면 소프트웨어 제품을 개발하고 제공하는 시간을 줄일 수 있죠. 이로써 프로젝트를 더 빨리 완료하고, 제품의 시장 출시 기간도 단축할 수 있습니다. 그 결과, 조직은 비용도 절감할 수 있고요.
-
코드·제품 품질, 안정성 확보
개발자가 생산성을 높이면 버그가 덜 발생하고, 깔끔하며, 잘 테스트 된 코드를 작성하는 데 시간을 더 투자할 수 있습니다. 그 결과, 품질이 더 높고 안정적인 제품을 만들 수 있고요. 이로써 디버깅과 유지 관리에 들어가는 자원도 줄일 수 있죠.
-
자기 계발, 비즈니스 성과 창출
개발자가 생산성을 개선하면 새로운 기술을 탐색하고, 새로운 스킬을 배우며, 혁신할 시간을 얻을 수 있습니다. 특히 창의적으로 실험하고 생각할 여유가 있으면 혁신적인 솔루션을 개발하고, 작업 프로세스를 지속적으로 향상할 수 있죠. 이는 더 나은 제품을 만들고, 시장에서 우위를 확보하는 데 도움이 되고요.
-
팀 협업·직무 만족도 향상
개발자 생산성을 높이면 워크플로를 간소화하고, 병목 현상을 줄일 수 있고요. 팀 안에서 소통과 협업도 강화할 수 있습니다. 그 결과, 긍정적인 작업 환경을 조성하며, 직무 만족도를 높일 수 있고요. 이는 궁극적으로 조직이 더 나은 성과를 이루는 데 기여할 수 있죠.
개발자 생산성 측정의 필요성
개발자 생산성을 측정하면 위와 같은 효과를 달성하는 데 도움이 됩니다. 아울러 이는 조직의 목표를 성취하고, 향후 작업을 잘 계획하는 데 기여하죠. 미국 생산성 플랫폼 기업 Clickup과 Hatica는 개발자 생산성을 측정해야 할 이유를 다음과 같이 분석합니다.
-
적절한 자원 할당
개발자 생산성을 측정하면 자원이 더 필요하거나, 더 적어도 되는 영역을 쉽게 확인할 수 있습니다. 개발자 생산성에 따라 프로젝트를 완료하는 데 더 많은 사람을 투입하거나, 프로젝트 일정을 조정하거나, 팀 업무 수행을 돕는 도구에 더 투자해야 할 수 있는데요. 개발자 생산성을 측정하면 이러한 계획을 실효성 있게 세우는 데 도움이 되고요. 이는 워크플로를 더 효율화하는 데 이바지할 수 있습니다.
-
현실적인 목표와 일정 설정
개발팀 생산성을 지표로 파악하면 현실적인 목표와 마감일을 설정하고, 역량에 맞춰 일정을 짤 수 있습니다. 현실적인 목표 설정은 고객 만족뿐만 아니라 팀의 웰빙에도 중요한데요. 작업량이 최적의 수준일 때 팀원은 집중력을 유지하고, 창의력을 발휘하며, 일과 삶의 균형을 이룰 수 있죠. 그러나 마감일이 촉박하고, 회의가 무수히 많으면 업무 만족도는 급락하고, 팀원은 번아웃에 빠질 수 있습니다. 개발자 생산성을 측정해 현실적인 목표와 일정을 수립하면 이러한 부작용을 막는 데 도움이 될 수 있고요.
-
프로젝트 진행 상황 추적, 마감일 준수
개발자 생산성을 측정하면 프로젝트의 진행 상황을 추적하고, 프로젝트를 일정에 맞춰 진행하는 데 도움이 되죠. 특히 개발자 생산성 지표를 명확하게 마련하면, 팀은 잠재적 지연이나 이슈를 조기에 확인할 수 있고요. 이를 해결하는 조치도 신속히 취할 수 있습니다. 그 결과, 더 나은 프로젝트 계획을 세우고, 팀이 마감일을 일관되게 지키도록 이끌 수 있고요.
개발자 생산성 지표 사례
IT 업계에는 개발자 생산성을 측정하는 다양한 지표가 있습니다. 그중 DORA 지표와 SPACE 프레임워크가 대표적이죠. 글로벌 컨설팅 기업 맥킨지는 두 지표를 ‘기회 지향 지표’로 보완, 제시하기도 했습니다. 아울러 Linkedin, Uber, Spotify, Stripe 등 유명 기술 기업은 자체적으로 여러 지표를 측정해 개발자 생산성을 파악하는데요. 지금부터 DORA 지표, SPACE 프레임워크, 기회 지향 지표를 각각 살펴보고요. 17개 유명 기술 기업이 활용하는 개발자 생산성 지표도 알아보겠습니다.
DORA 지표
DORA(DevOps Research and Assessment) 지표는 개발자 생산성 지표의 표준으로 널리 알려졌습니다. 이는 DORA 지표를 만든 구글 팀에서 이름을 따왔죠. DORA 지표는 팀 속도와 안정성 측면에서 다음 네 가지를 각각 측정합니다.
- 팀 속도
- 배포 빈도: 선택한 기간 내 소프트웨어 배포 횟수
- 변경 리드 타임: 코드 변경 요청을 받아 프로덕션에 배포하기까지 걸리는 시간
- 안정성
- 변경 실패율: 다운타임, 사용자에게 미치는 부정적 영향, 오류와 같이 프로덕션 장애를 일으키는 변경 사항 비율
- 서비스 복구 시간: 프로덕션 장애 이후 서비스를 복구하는 데 걸리는 시간
SPACE 프레임워크
SPACE 프레임워크는 관리자에게 개발자 생산성의 전체적인 관점을 제공하기 위해 GitHub, Victoria 대학교, Microsoft Research 연구원들이 설계했는데요. 이는 만족도와 웰빙(Satisfaction and well-being), 성과(Performance), 활동(Activity), 소통과 협업(Communication과 Collaboration), 효율성과 흐름(Efficiency and flow) 측면에서 아래와 같이 생산성을 측정합니다.
- 만족도와 웰빙
- 업무, 팀, 기업 문화와 관련된 개인과 팀의 성취감
- 직원 만족도와 번아웃으로 측정
- 성과
- 비즈니스, 개발자별 업무 성과
- 프로젝트 품질, 안정성, 유지관리 가능성, 서비스 상태로 측정
- 활동
- 개발자가 주어진 하루 동안 수행한 작업 수
- Pull Requests, 커밋, 배포 빈도로 측정
- 소통과 협업
- 프로젝트 피드백과 아이디어 수
- 내부 인터뷰와 온보딩 검토를 통해 측정
- 효율성과 흐름
- 개발자 또는 팀이 중단 없이 프로젝트를 진행할 수 있는 능력
- 프로젝트 간 핸드오프 횟수와 시간을 통해 측정
기회 지향 지표
기회 지향 지표는 맥킨지가 DORA 지표와 SPACE 프레임워크를 보완한 건데요. 내부 루프와 외부 루프에 걸린 시간, 개발자 속도 지수 벤치마킹, 개발자 기여도 분석, 인재 관리 측면에서 다음과 같이 생산성을 판단합니다.
- 내부 루프와 외부 루프에 걸린 시간
- 내부 루프: 코딩, 빌드, 단위 테스트 등 소프트웨어 제품 개발과 직접 관련된 활동
- 외부 루프: 통합, 테스트, 릴리즈, 배치처럼 코드의 프로덕션 환경 이전과 관련된 활동
- 개발자가 내부 루프에 더 많은 시간을 할애할수록 생산성 향상
- 개발자 속도 지수 벤치마킹
- 사내 관행을 다른 기업 관행과 비교해 개선할 영역 파악
- 개발자 기여도 분석
- 팀이 백로그에 어떻게 기여하는지 평가
- 백로그 관리를 측정하는 Jira 같은 도구로 성과 향상을 방해하는 부정적 흐름 파악
- 인재 관리
- 업계 표준 역량 맵을 사용해 조직의 기존 지식, 기술, 능력을 가시화하는 점수 만듦
- 이로써 격차와 약점 파악
유명 기술 기업의 개발자 생산성 지표
미국 엔지니어링 인텔리전스 플랫폼 기업인 DX는 Linkedin, Uber, Spotify 등 17개 유명 기술 기업의 개발자 생산성 부서 리더들을 인터뷰했는데요. 각 사 리더가 공유한 기업별/부서별 개발자 생산성 지표는 아래와 같습니다.
| 기업 | 부서명 | 측정 지표 |
|---|---|---|
| Amplitude | Platform Engineering | 전달 용이성, 엔지니어 참여도, 서비스당 배포 수, 변경 실패율 |
| Atlassian | Developer Experience | 개발자 만족도, 커밋~배포 시간, Pull Request(PR) 사이클 타임, 셀프 문서화·의존성 유지 관리 |
| Chime | Engineering Operations | 개발자 고객 만족도, 체감 전달 속도, 전달 용이성, 감정, 16개 이상의 DevEx 요소의 정량 지표 |
| Doordash | Developer Platform | 개발자 만족도, 채택률, 서비스/앱 안정성 |
| Etsy | Enablement | 실험 속도, 가용성, 성능, 개발자 감정 |
| GoodRX | Engineering Solutions | 참여도, 주간 시간 손실, 집중 시간, 전달 용이성, 속도, 안정성, 표준 채택률 |
| Engineering Productivity | 속도, 용이성, 품질 *각 차원의 구체적 지표는 다양함 | |
| Intercom | Developer Experience | 전달 용이성, 체감 생산성, 엔지니어 참여도 |
| Lattice | Developer Experience | 체감 배포 용이성, Cl 파이프라인 실패율, Cl 파이프라인 P50 빌드 시간, 배포 수, 변경 실패율 |
| Productivity &Happiness | 개발자 빌드 시간, 코드 리뷰어 응답 시간, 커밋 후 CI 속도, CI 결정성(테스트군 결과가 유효할 가능성), 배포 성공률, 개발자 순 사용자 만족도 | |
| Microsoft | Engineering Thrive | SPACE 지표 *각 차원의 구체적 지표는 다양함 |
| Notion | Developer Infrastructure | 마찰 인식에 초점을 둔 개발자 설문조사 |
| Peloton | Tech Enablement | 개발자 만족도 점수, 첫 번째와 열 번째 PR까지 시간, 리드 타임, 배포 빈도, 250줄 미만 PR 비율, 라인 커버리지, 변경 실패율, 서비스 복구 시간 |
| Postman | Platform Engineering | 전달 용이성, 체감 생산성, 주간 시간 손실, 엔지니어 참여도, 사이클 타임, 만족도 |
| Spotify | Developer Experience | 자체 보고된 생산성, Golden Standards 채택률, 배포 빈도, 주간 활성 개발자당 주간 배포 수 |
| Stripe | Developer Tools | 충분한 집중 시간을 가진 평균 일수, 브랜치 생성~master merge 시간, 감정, 개발자당 주간 PR 수 |
| Uber | Developer Platform | 엔지니어당 주간 Diff/PR 수, 엔지니어당 주간 코드 리뷰 수, 엔지니어당 생성된 주간 설계 문서 수, 엔지니어당 주간 평균 집중 시간 |
개발자 생산성 측정 시 고려 사항
개발자 생산성을 측정해 개발 업무와 프로젝트, 비즈니스를 발전시키려면 관련 지표를 올바르게 측정하고 활용할 줄 알아야 하는데요. 미국 엔지니어링 인텔리전스 플랫폼 기업 DX와 옵저버빌리티 기업 Chronosphere의 Senior Developer Advocate인 Paige Cruz, 테크 저널리스트 Bill Doerrfeld는 개발자 생산성을 측정할 때 다음 사항을 고려할 것을 제언합니다.
소프트웨어 개발 특수성 이해
소프트웨어 개발은 쉽게 정량화할 수 없는 협업, 창의성, 기술력을 포함하는 일임을 이해해야 합니다. 이러한 특성을 반영한, 정교하고 질적인 지표를 함께 사용해야 개발자 생산성을 정확히 측정하고 제대로 파악할 수 있고요. 그렇기에 개발자 생산성을 측정하는 건 어렵고 복잡할 수밖에 없죠.
팀 운영 방식 반영
성과 지표를 개인 성과에만 초점을 맞추기보다 팀 운영 방식도 반영해야 합니다. 기술 개발은 협업 프로세스에 가까운데요. 개발 프로젝트는 팀워크와 관련됐고, 팀원들의 노력이 얽혀 있기도 하죠. 또 성과 지표에서 개인 기여에만 초점을 맞추면 팀 협업의 시너지 효과를 간과할 우려도 있고요.
코딩 외 업무 고려
개발자는 코드만 작성하지 않습니다. 코드도 리뷰하고, 문서도 쓰며, 회의에도 참석해야 하죠. 이러한 업무도 개발 프로세스에 필수적인데요. 개발자 생산성을 측정할 때 이를 고려하는 기업도 있지만 그렇지 않은 곳도 많죠. 코드와 같은 가시적인 결과물에 초점을 맞추는 게 일반적이고요. 코딩 외 업무가 프로젝트 성공에 미치는 영향과 중요성을 고려해 이러한 업무의 생산성을 추적하는 방안도 모색해야 합니다.
양과 질 균형 유지
작업의 양과 질을 모두 측정하는 개발자 생산성 지표를 사용하는 것도 중요합니다. 코드나 기능을 더 많이 만들어도 항상 더 나은 결과로 이어 지지 않을 수 있는데요. 양에만 초점을 두면 코드 품질, 유지보수성, 성능을 소홀히 할 가능성도 있죠. 작업의 양과 질을 함께 측정하는 전체 지표를 사용하면, 개발자 생산성이 높아지면서 소프트웨어의 전체 품질이 향상되거나, 떨어지지 않도록 이끌 수 있고요.
적절한 지표 활용
근무 시간과 같은 투입량이나 노력으로 개발자 생산성을 측정하면 잘못된 행동을 조장할 수 있습니다. 특히 기업 문화가 컴퓨터 화면 앞에서 보낸 시간에 가치를 두고 보상하면, 개발자는 여기에 공을 더 많이 들일 수 있죠. 그러나 이는 작업의 품질을 보장하지 않고요. 가장 일찍 출근해서 가장 늦게 퇴근하는 경쟁으로 변질될 수 있습니다.
지표 맥락 고려
코드 줄이나 커밋 수로 개발자 생산성을 측정하는 것도 유의해야 합니다. 개발자는 코드 줄을 매우 빠르게 대량 작성할 수 있고요. 이를 측정하는 건 쉽다고 하죠. 아울러 코드 줄이나 커밋 수는 문제를 해결할 때 개발자의 지적 노력과 창의성을 온전히 반영하지 않을 수 있고요. 모든 성과 지표는 맥락을 고려해 해석해야 합니다.
지표 맹신 경계
지표를 너무 믿지 않도록 유의해야 합니다. 지표는 단면만 보여주기 쉬운데요. 이는 데이터 포인트일 뿐이며, 실제 상황을 항상 보여주기는 어렵습니다. 아울러 정성 답변은 말하는 걸 꺼리다 보니 왜곡될 수도 있고요.
인포그랩 개발 생산성 분석·개선 사례
인포그랩은 내부 프로젝트인 ‘전문가 실험실’ 개발 활동을 진행하며, 개발 생산성을 정확히 측정하고 이를 향상하고자 노력하는데요. 특히 Value Stream Mapping 방식으로 개발 활동을 평가해 개발 생산성 측정·개선 과정에서 인사이트를 얻고, 효과도 봤습니다. Value Stream Mapping 방식은 소프트웨어 개발에서 가치 흐름을 시각화하고 병목을 확인해 목표를 달성하는데요. 인포그랩은 이러한 방식으로 특정 스프린트의 개발 활동을 분석해 구체적인 가치 흐름을 평가하고요. 개선점을 발견했죠.
인포그랩이 Value Stream Mapping 방식으로 개발 활동을 분석하면서 도출한 개선점은 다음과 같은데요. ▲우선순위 조율, 요구사항 싱크 등 오류 발생, 프로젝트 계획 부족으로 예상과 다른 결과물 나옴 ▲자동화 파이프라인 속도 포함해 현황을 잘 파악 못함 ▲빠른 개발로 기술 부채 발생, 애플리케이션 오류 추적에 시간 소요 ▲개발 생산성 분석에 가시화 필요 등이 그 내용입니다.
이에 인포그랩은 ▲스프린트 협업 방식 개선 ▲CI/CD 파이프라인 측정으로 병목 해결 ▲오류 추적 환경을 GitLab으로 일원화 ▲가치 흐름 관리 위한 분석 환경 개선 등 조치를 취했는데요. 그 결과, 싱크 맞추는 시간과 리드 타임을 줄였고요. 예상치 못한 오류를 빠르게 수정하는 효과를 거뒀죠. 인포그랩은 이러한 경험을 확장하며, Value Stream Management 역량을 강화하고 있는데요. 앞으로도 인포그랩에 의미 있는 개발 생산성 지표를 찾아 가시화하려 합니다. 더 자세한 내용이 궁금하신 분은 인포그랩에 언제든지 문의해 주십시오.
맺음말
지금까지 개발자 생산성의 중요성과 측정 필요성을 살펴보고요. DORA 지표, SPACE 프레임워크 등 전통적인 개발자 생산성 지표와 맥킨지의 기회 지향 지표, Linkedin, Uber, Spotify 등 17개 유명 기술 기업의 개발자 생산성 지표를 알아봤습니다. 아울러 개발자 생산성을 측정할 때 고려 사항을 짚고요. 인포그랩이 Value Stream Mapping 방식으로 내부 프로젝트인 ‘전문가 실험실’의 개발 활동을 분석, 개발 생산성을 향상한 사례를 살펴봤는데요. 이 글의 요점은 다음과 같습니다.
- 개발자 생산성이 높아지면 시간·비용을 효율화하고, 코드·제품의 품질과 안정성을 확보하는 데 도움이 됩니다. 이는 개발자의 자기 계발과 비즈니스 성과 창출에도 기여하고요. 팀 협업과 직무 만족도도 향상할 수 있죠.
- 개발자 생산성 측정은 적절한 자원을 할당하고, 현실적인 목표와 일정을 설정하며, 프로젝트 진행 상황을 추적하고, 마감일을 지키는 데 필요합니다.
- DORA 지표는 개발자 생산성 지표로 배포 빈도, 변경 리드 타임, 변경 실패율, 서비스 복구 시간을 측정합니다.
- SPACE 프레임워크는 만족도와 웰빙, 성과, 활동, 소통과 협업, 효율성과 흐름 측면에서 개발자 생산성을 측정합니다.
- 맥킨지의 기회 지향 지표는 내부 루프와 외부 루프에 걸린 시간, 개발자 속도 지수 벤치마킹, 개발자 기여도 분석, 인재 관리 측면에서 개발자 생산성을 판단합니다.
- 개발자 생산성을 측정할 때는 소프트웨어 개발 특수성, 팀 운영 방식, 코딩 외 업무, 작업의 양과 질, 지표의 적절성과 맥락을 고려해야 합니다.
- 인포그랩은 내부 프로젝트인 ‘전문가 실험실’ 개발 활동을 진행하며, Value Stream Mapping 방식으로 개발 활동을 평가해 인사이트를 얻고, 개발 생산성도 개선했습니다.
참고 자료
- How to measure and strengthen developer productivity
- What is Developer Productivity and How to Improve it?
- Measuring Developer Productivity: Improvement Tips for Software Development Teams
- 소프트웨어 개발자의 생산성을 측정하는 방법
- How to measure and maximize developer productivity
- Developer productivity metrics at top tech companies
- A Guide to Measuring Developer Productivity
- Should You Measure Developer Productivity?
- GitLab 쉽게 배우는 노하우 대방출(Feat. GitLab 밋업)
- GitLab Value Streams 대시보드의 DORA Performers 점수
DevOps와 GitLab을 효과적으로 도입하는 방법, 지금 인포그랩에 문의하세요.