왜 대부분의 개발 조직은 팀의 경제적 성과를 모르고 있을까

개발팀의 생산성, 정말 측정하고 있나요?

개발자라면 한 번쯤 이런 경험이 있을 거예요. 스프린트 회고에서 "이번 스프린트에 몇 개의 스토리 포인트를 완료했다"는 보고를 하지만, 정작 그 작업이 회사의 매출이나 비용 절감에 얼마나 기여했는지는 아무도 모르는 상황이요. Viktor Cessan이 쓴 글 "The Economics of Software Teams"는 바로 이 문제를 정면으로 다루고 있어요. 대부분의 엔지니어링 조직이 자기 팀의 경제적 성과에 대해 사실상 "눈을 감고 비행하고 있다"는 거예요.

이건 특히 요즘 같은 시기에 중요한 이야기인데요, 글로벌 테크 기업들이 대규모 구조조정을 하면서 "개발 조직의 가치를 어떻게 증명할 것인가"가 업계 전체의 화두가 되었거든요.

문제의 핵심: 비용은 알지만 가치는 모른다

글의 핵심 주장은 이래요. 소프트웨어 팀의 비용(인건비, 인프라 비용, 도구 비용 등)은 CFO가 정확하게 알고 있지만, 그 팀이 만들어내는 가치는 거의 아무도 제대로 측정하지 않는다는 거예요.

왜 이런 일이 벌어질까요? 제조업에서는 공장 라인 하나의 산출량과 비용을 정확하게 계산할 수 있잖아요. 자동차 한 대 만드는 데 얼마가 들고, 팔면 얼마를 벌고. 하지만 소프트웨어 개발은 다르거든요. 개발자 A가 이번 주에 작성한 코드가 매출에 기여하는 건 3개월 뒤일 수도 있고, 혹은 다른 팀의 작업과 합쳐져야 비로소 가치가 생기기도 해요. 이런 인과관계의 복잡성 때문에 대부분의 조직이 측정 자체를 포기하는 거예요.

글에서 지적하는 또 하나의 문제는 "대리 지표(proxy metrics)에 대한 과도한 의존"이에요. 배포 횟수, PR 머지 속도, 코드 커버리지 같은 지표들이 널리 쓰이지만, 이것들은 "개발팀이 바쁜가"를 측정할 뿐 "개발팀이 가치를 만들고 있는가"를 측정하지는 못한다는 거죠.

DORA 메트릭과 그 한계

여기서 많은 분들이 떠올릴 만한 게 DORA 메트릭이에요. 이게 뭐냐면, 구글 클라우드 팀이 연구해서 만든 소프트웨어 딜리버리 성과 측정 프레임워크인데요, 배포 빈도(Deployment Frequency), 변경 리드 타임(Lead Time for Changes), 변경 실패율(Change Failure Rate), 서비스 복구 시간(Time to Restore Service) 이 네 가지 지표를 핵심으로 봐요.

DORA 메트릭은 분명 유용하지만, 이 글의 관점에서 보면 여전히 "개발 프로세스의 효율성"을 측정하는 것이지 "비즈니스 가치"를 측정하는 건 아니거든요. 배포를 하루에 10번 한다고 해서 매출이 늘어나는 건 아니니까요. 완전히 잘못된 기능을 아주 빠르게 배포하고 있을 수도 있는 거예요.

이 글이 제안하는 접근법은 좀 더 근본적이에요. 각 팀이 만드는 "제품 단위"에 경제적 가치를 매기고, 그 가치 대비 투입 비용의 비율을 추적하자는 거예요. 물론 이게 쉽지 않다는 건 저자도 인정하지만, 적어도 그 방향으로 노력해야 한다는 거죠.

업계에서는 어떤 시도들이 있을까

사실 이 문제에 대한 업계의 관심은 점점 커지고 있어요. 마틴 파울러가 오래전에 말한 "소프트웨어 개발의 생산성은 측정할 수 없다"는 명언이 있는데, 최근에는 이에 도전하는 시도들이 많아졌어요. McKinsey가 2023년에 발표한 개발자 생산성 보고서가 업계에서 큰 논쟁을 일으킨 것도 같은 맥락이에요. 켄트 벡을 비롯한 많은 엔지니어링 리더들이 "그런 식으로 측정하면 안 된다"고 반박했거든요.

Space 프레임워크(Satisfaction, Performance, Activity, Communication, Efficiency)나, LinearB·Jellyfish 같은 엔지니어링 인텔리전스 플랫폼들도 이 영역에서 경쟁하고 있고요. 한국에서도 플랫폼 엔지니어링이 화두가 되면서 "개발 생산성을 어떻게 측정할 것인가"에 대한 관심이 높아진 상황이에요.

한국 개발 조직에 주는 시사점

한국 IT 업계에서 이 글이 특히 와닿을 수 있는 이유가 있어요. 한국 기업들은 전통적으로 "투입 대비 산출"을 중시하는 문화가 강한데, 개발 조직의 산출을 제대로 정의하지 못한 채 야근 시간이나 커밋 수 같은 표면적 지표로 평가하는 경우가 많거든요.

만약 여러분이 테크 리드나 엔지니어링 매니저 역할을 하고 있다면, 이 글을 계기로 "우리 팀이 만드는 가치를 어떻게 경영진에게 설명할 수 있을까"를 한 번 생각해보면 좋겠어요. 코드를 얼마나 빨리 짜느냐보다, 그 코드가 비즈니스에 어떤 영향을 주느냐를 설명할 수 있는 개발자가 앞으로 더 높은 가치를 인정받을 거예요.

IC(Individual Contributor) 개발자라도 자기 작업의 비즈니스 임팩트를 인식하고 커뮤니케이션하는 연습은 커리어에 큰 도움이 돼요. 성과 리뷰에서 "뭘 했다"가 아니라 "그래서 어떤 결과가 나왔다"를 말할 수 있으면 전혀 다른 평가를 받게 되거든요.