생산성은 무엇으로 측정해야 하는가?
코드량의 신화
『The Mythical Man-Month』 9장과 11장은 개발자의 생산성을 측정하는 문제를 다룹니다. 브룩스는 당시 흔히 사용되던 생산성 지표인 '코드 줄 수(lines of code)'에 대한 문제의식을 드러냅니다.
"생산성은 코드 양이 아니라, 코드가 만들어내는 가치로 측정해야 한다."
지금도 이 말은 너무나 당연하게 들리지만, 실무에서는 여전히 코드 양에 대한 환상이 존재합니다.
GitHub 커밋 수, 줄 수, 코드 리뷰 양 같은 수치가 여전히 개인 기여도를 판단하는 지표로 쓰이기도 하니까요.
그렇다면 왜 이 '코드량의 신화'는 여전히 반복되고 있을까요?
1970년대의 생산성 논쟁
브룩스는 여러 연구 데이터를 인용해 당시 개발자의 연간 생산량이 대략 600~5,000 프로그램 단어(program words) 수준이라고 설명합니다. 이 단위는 어셈블리어 또는 저수준 언어의 명령어 단위로 이해할 수 있습니다.
그는 중요한 관찰을 공유합니다.
고급 언어를 쓰면 생산성이 5배 이상 증가
컴파일러, 운영체제 개발자는 일반 애플리케이션 개발자보다 생산성이 3~9배 낮음
생산성은 줄 수가 아니라 사고의 단위로 평가해야 함
이런 논의는 오늘날까지 이어지고 있습니다.
브룩스는 언어, 도구, 업무의 성격에 따라 생산성은 크게 달라지며,
단순 비교는 무의미하다는 점을 강조합니다.
오늘날의 코드 생산성은 더 높아졌을까?
2020년대의 개발자는 하루 수천 줄의 코드를 작성할 수 있습니다.
고급 언어, 자동완성, AI 코딩 도구 덕분입니다.
대표적인 예시로는
Kubernetes: 평균 기여자 월간 1,300줄 코드 변경
Sourcegraph: 730줄
Amazon(내부 사례): 연간 75만 줄 (약 월 5,600줄)
단순 수치만 보면 생산성이 수십 배 증가한 것처럼 보이지만, 이것은 도구의 발전, 프레임워크의 재사용, 코드 생성 자동화에 따른 결과입니다. 핵심은 줄 수가 아닌 맥락입니다.
코드량은 생산성의 착시일 뿐이다
단순히 많은 코드를 작성했다고 해서 좋은 개발자는 아닙니다. 오히려 다음과 같은 경우가 많습니다.
불필요한 abstraction, 지나친 generic 설계
코드 중복, 모듈 분리가 미흡한 상태에서의 과도한 구현
리팩토링 필요성을 무시한 누적된 기술부채
결과적으로 줄 수가 많다는 건 오히려 설계가 미숙하거나,
문제 정의가 명확하지 않았음을 뜻할 수도 있습니다.
브룩스는 다음과 같이 정리합니다.
“코드량은 조직의 생산성을 판단하는 데 거의 도움이 되지 않는다.”
진짜 생산성을 어떻게 볼 것인가?
최근에는 'DevEx(Developer Experience)', 'DORA Metrics', 'SPACE Framework' 같은 생산성 프레임워크가 등장하며, 코드량 중심의 평가를 탈피하려는 움직임이 나타나고 있습니다. 이들은 다음과 같은 요소들을 고려합니다.
개발자의 심리적 만족도
배포 주기, 변경 성공률, 사고 대응 속도
작업 완료까지 걸리는 시간 (lead time)
협업 효율성과 커뮤니케이션 품질
이러한 정성적/정량적 지표를 함께 활용해 생산성을 보다 입체적으로 측정하려는 시도입니다.
중요한 것은, 더 나은 제품과 팀 성과로 연결되는 생산성을 고민해야 한다는 점입니다.
생산성은 줄이는 데 있다
재미있는 아이러니가 하나 있습니다.
정말 뛰어난 개발자는 코드를 덜 쓰고도 같은 결과를 만드는 사람입니다.
이미 존재하는 라이브러리를 적절히 사용한다
문제를 단순화하거나, 문제 정의 자체를 바꾼다
협업을 통해 문제 해결 속도를 높인다
결국 생산성은 다음과 같이 재정의될 수 있습니다:
“적은 코드로, 빠르게, 신뢰성 있게 문제를 해결하는 능력”
브룩스가 말한 "사고의 단위"라는 표현은, 지금 시대의 개발자에게도 여전히 유효한 기준입니다.
개발자의 생산성은 더 이상 코드 줄 수로 판단할 수 없습니다.
지금은 다양한 툴, 자동화, 협업 도구 덕분에 같은 문제를 더 빠르고 적은 코드로 해결할 수 있는 시대입니다.
그러므로 우리는 코드량이 아니라, 문제 해결력, 설계력, 협업력, 품질에 대한 감각을 중심으로 생산성을 바라보아야 합니다.
코드 줄 수의 신화는 이제 끝내야 할 때입니다. 진짜 중요한 질문은 이것입니다.
"이 코드는 진짜 필요한가?"
→ 7편: 툴링의 진화와 공유 문화의 재편
