개발 생산성을 측정할수록 팀이 느려지는 이유

결론부터 말씀드리겠습니다. 개발 생산성은 측정할 수 없는 게 아닙니다. 문제는 대부분의 조직이 잘못된 층위를 잰다는 데 있습니다. 코드 줄 수, 커밋 수, 스프린트 벨로시티처럼 “얼마나 많이 만들었나”를 재는 순간, 팀은 가치를 만드는 대신 그 숫자를 연기하기 시작합니다. 지표는 올라가는데 실제 제품이 나아가는 속도는 느려집니다. 이 글은 왜 그런 일이 벌어지는지, 그리고 무엇을 대신 측정해야 하는지에 대한 이야기입니다.

코드 줄 수는 왜 생산성이 아닌가

코드 라인 수(LOC), 커밋 수, PR 수, 벨로시티. 이 지표들의 공통점은 모두 산출물의 양을 잰다는 것입니다. 그리고 소프트웨어에서 산출물의 양은 가치와 자주 반대로 움직입니다.

유명한 일화가 있습니다. 애플에서 QuickDraw를 만든 빌 앳킨슨(Bill Atkinson)은 주간 코드 라인 수를 적으라는 관리 양식을 받았습니다. 그는 그 주에 그래픽 루틴을 리팩터링해 2,000줄을 지우고 성능을 더 끌어올린 참이었습니다. 양식에는 “-2000”이라고 적었습니다. (그 뒤로 그 양식은 사라졌다고 합니다.) 더 적은 코드로 더 나은 결과를 낸 주가, 라인 수로는 마이너스 생산성이 되는 것입니다.

프레드 브룩스(Fred Brooks)는 이미 1975년 『맨먼스 미신』에서 소프트웨어 생산성이 인원수에 비례하지 않는다고 못 박았습니다. 사람을 두 배로 넣어도 결과물이 두 배가 되지 않고, 늦은 프로젝트에 사람을 더하면 더 늦어진다는 것이죠. 생산성이 이렇게 비선형적인데, 우리는 여전히 선형적으로 셀 수 있는 것들만 세고 있습니다. 코딩 속도 자체가 생산성이 아니라는 사실은 시니어 개발자가 코드를 짜기 전에 더 많은 시간을 쓰는 이유와도 정확히 통합니다.

2023년 매킨지가 「그렇다, 개발자 생산성은 측정할 수 있다」라는 글을 내놓자 업계가 들끓었습니다. 켄트 벡(Kent Beck)과 게르겔리 오로시(Gergely Orosz)는 두 편에 걸친 반박문에서 핵심을 짚었습니다. 매킨지의 지표는 노력과 산출물만 잴 뿐, 그 뒤에 오는 성과와 영향을 보지 못한다는 것입니다. 두 사람의 비유는 명료합니다. 세일즈 팀을 “보낸 이메일 수”로 평가하지 않습니다. 성사된 거래로 평가합니다. 그런데 왜 개발자는 “짠 코드의 양”으로 평가하려 하는가.

측정이 목표가 되는 순간

여기서 더 깊은 문제가 있습니다. 잘못된 지표는 단지 부정확한 데서 그치지 않습니다. 팀의 행동을 적극적으로 망가뜨립니다.

영국 경제학자 찰스 굿하트(Charles Goodhart)의 이름을 딴 굿하트의 법칙은 이렇게 요약됩니다. 측정 지표가 목표가 되는 순간, 그것은 더 이상 좋은 지표가 아니다. 사회심리학자 도널드 캠벨(Donald Campbell)은 1976년에 더 날카롭게 표현했습니다. 정량 지표가 의사결정에 많이 쓰일수록, 그 지표는 부패 압력을 받고 원래 측정하려던 과정 자체를 왜곡한다는 것입니다. 벨로시티를 성과로 걸면 스토리 포인트가 부풀고, PR 수를 걸면 PR이 잘게 쪼개집니다. 숫자는 오르지만 그것이 가리키던 실체는 사라집니다.

켄트 벡은 페이스북 시절의 경험을 이렇게 회고합니다. 개발자 설문 점수는 처음엔 유용했습니다. 그런데 그 점수가 인사평가에 연결되고 관리 계층을 타고 위로 올라가자, 디렉터가 매니저를 압박하고 매니저가 다시 개인과 점수를 “협상”하기 시작했습니다. 측정이 목표가 되는 순간, 지표는 현실을 비추는 거울이 아니라 연기해야 할 대본이 됩니다.

저도 같은 실수를 지켜본 적이 있습니다. 예전에 실시간 운영 모니터링 대시보드를 만든 적이 있는데, 원래 목적은 시스템 상태를 “보이게” 하는 것이었습니다. 그런데 경영진이 그 화면에서 배포 건수 하나에 시선을 고정하자, 팀은 그 숫자를 올리는 방향으로 움직이기 시작했습니다. 배포 빈도는 분명히 올라갔습니다. 대신 롤백과 심야 핫픽스가 같이 늘었습니다. (숫자를 목표로 준 대가였습니다.) 대시보드는 죄가 없었습니다. 하나의 숫자를 목표로 삼은 것이 문제였죠.

흔히 피터 드러커(Peter Drucker)의 말로 인용되는 “측정할 수 없으면 관리할 수 없다”는 문장은 정작 그의 저작에서 확인되지 않습니다. 오히려 통계학자 에드워즈 데밍(W. Edwards Deming)은 정반대로 말했습니다. 경영에 가장 중요한 숫자들은 대개 알 수 없으며, 눈에 보이는 숫자만 믿고 회사를 운영하는 것은 값비싼 착각이라고요.

AI가 만든 착시: 개인은 빨라지고 팀은 느려진다

이미 코드의 절반가량을 AI가 쓰는 2026년 현재, 이 오래된 함정에 새 변수가 하나 더해졌습니다. AI 코딩 도구입니다.

DORA의 2024년 State of DevOps 보고서는 흥미로운 역설을 보고합니다. AI 도입은 개인의 생산성과 몰입, 직무 만족도를 분명히 끌어올립니다. 그런데 같은 조직의 배포 안정성과 처리량은 오히려 떨어졌습니다. 구체적으로, AI 채택도가 25% 증가할 때 배포 처리량은 약 1.5%, 배포 안정성은 약 7.2% 감소하는 것으로 추정됐습니다. 원인으로 지목된 것은 AI가 만들어낸 크고 검토하기 어려운 변경 덩어리, 그리고 작은 배치와 견고한 테스트라는 기본기의 붕괴였습니다.

이 대목이 측정의 문제와 정확히 맞물립니다. AI 효과를 개인 산출물 지표로만 재면 — 이를테면 완료한 태스크 21% 증가, 병합된 PR 98% 증가 같은 화려한 숫자로만 보면 — “AI가 생산성을 두 배로 올렸다”는 결론이 나옵니다. 하지만 팀의 전달 지표로 보면 정반대의 그림이 나올 수 있습니다. 개인은 빨라졌는데 팀은 느려진 것입니다. AI가 짠 코드를 누가, 어떻게 검증하느냐의 문제가 여기서 다시 발목을 잡습니다.

그래서 무엇을 측정하는가

그렇다면 측정을 포기해야 할까요. 아닙니다. 초점을 옮기면 됩니다. 켄트 벡과 오로시가 제시한 사고 틀이 좋은 지도입니다.

flowchart LR
  E["노력<br/>계획·코딩"] --> O["산출물<br/>커밋·PR·기능"]
  O --> Oc["성과<br/>사용자 행동 변화"]
  Oc --> Im["영향<br/>매출·유지·신뢰"]
  class E muted
  class O muted
  class Oc accent
  class Im accent

대부분의 조직은 왼쪽 두 칸, 즉 노력과 산출물을 잽니다. 세기 쉽기 때문입니다. 하지만 가치는 오른쪽 두 칸, 성과와 영향에서 만들어집니다. 사용자가 실제로 다르게 행동했는가, 그래서 매출과 유지와 신뢰로 돌아왔는가. 측정의 초점을 왼쪽에서 오른쪽으로 옮기는 것이 출발점입니다.

이 원리를 실제 지표로 구현한 세 가지 틀이 업계 표준으로 자리 잡았습니다.

DORA의 핵심은 처리량 두 지표와 안정성 두 지표를 반드시 쌍으로 본다는 데 있습니다. 배포를 빨리 하면서 실패율이 함께 치솟으면 그건 개선이 아니니까요. 니콜 포스그렌(Nicole Forsgren)이 주도한 SPACE는 한 걸음 더 나아가, 생산성은 단일 지표로 잴 수 없으며 활동량만 봐서는 안 된다고 못 박습니다. 만족도 같은 정성 지표가 오히려 성과와 잔류율을 예측한다는 것이죠. 2024년 나온 DX Core 4는 이 셋을 통합해 “무엇을 측정할 것인가”에 처방을 내린 최신 틀입니다.

측정을 다시 설계하는 법

프레임워크의 이름을 외우는 것보다, 다음 네 가지 원칙이 실무에서 더 중요합니다.

첫째, 개인이 아니라 팀을 측정합니다. 개인 랭킹이나 해고 근거로 지표를 쓰는 순간 캠벨의 법칙이 어김없이 발동합니다. CTO가 생산성 측정을 원하는 흔한 이유 하나가 “누구를 자를지” 가리는 것이라는 벡의 지적은 뼈아픕니다. 지표의 목적을 “누가 못하는가”가 아니라 “무엇이 팀을 느리게 하는가”로 돌려야 합니다.

둘째, 항상 쌍으로 묶습니다. 속도 지표 옆에는 반드시 품질·안정성 지표를 둡니다. 배포 빈도 옆에 변경 실패율을, 리드타임 옆에 복구 시간을. 한쪽만 걸면 팀은 다른 쪽을 희생해서 그 숫자를 만듭니다.

셋째, 정량과 정성을 함께 봅니다. 숫자는 질문의 시작이지 답이 아닙니다. 리드타임이 늘었다면 그건 “왜”를 물어야 할 신호이지, 누군가를 탓할 결론이 아닙니다. SPACE의 만족도 설문이 대시보드의 숫자가 놓치는 맥락을 채워줍니다.

넷째, 감시가 아니라 마찰 제거를 위해 잽니다. 좋은 측정은 팀을 내려다보는 렌즈가 아니라, 어디서 막히는지를 비추는 손전등입니다. 빌드가 20분씩 걸리는지, 리뷰가 이틀씩 밀리는지, 배포가 무서워 다들 미루는지. 이런 마찰을 찾아 없애는 데 지표를 쓰면, 생산성은 쥐어짜지 않아도 따라 올라옵니다.

결론

결국 개발 생산성은 숫자의 문제가 아니라 방향의 문제입니다. 무엇을 세느냐가 팀이 무엇을 향해 일하는지를 결정합니다. 코드 줄 수를 세면 팀은 코드를 늘리고, 배포 건수를 세면 배포를 늘립니다. 성과와 영향을 물으면, 그제야 팀은 사용자를 향합니다.

측정을 두려워할 필요는 없습니다. 다만 측정이 목표가 되는 순간을 경계해야 합니다. 지표는 팀을 심판하는 성적표가 아니라, 함께 길을 찾는 나침반이어야 합니다. 여러분의 대시보드에 걸린 숫자가 지금 어느 쪽을 가리키고 있는지, 한번 들여다보시기 바랍니다. (혹시 그 숫자가 어느새 목표가 되어 있진 않은지도요.)

참고 자료

• Nicole Forsgren, Jez Humble, Gene Kim, 『Accelerate』 (2018) / DORA (dora.dev)
• Nicole Forsgren 외, “The SPACE of Developer Productivity”, ACM Queue (2021)
• DORA, Accelerate State of DevOps Report (2024)
• McKinsey, “Yes, you can measure software developer productivity” (2023)
• Kent Beck & Gergely Orosz, “Measuring developer productivity? A response to McKinsey”, The Pragmatic Engineer (2023)
• Abi Noda & Laura Tacho, “Introducing the DX Core 4”, DX (2024)
• Donald T. Campbell, “Assessing the Impact of Planned Social Change” (1976)
• Fred Brooks, 『The Mythical Man-Month』 (1975)