맥나마라 오류(McNamara Fallacy)는 측정 가능한 수치나 정량적 데이터에만 의존해 의사결정을 내리는 것이 잘못된 접근이라는 인식을 말한다.

로버트 맥나마라는 1960년대 대부분 기간 동안 미국 국방장관을 지내며 베트남전 초기를 이끌었다. 이전에는 산업계에서 경력을 쌓았으며, 특히 포드자동차에서 포드 가문 출신이 아닌 최초의 사장으로 이름을 알렸다. 당시 맥나마라는 통계 기법을 경영에 도입한 혁신적인 리더십으로 주목받았다.

맥나마라는 측정할 수 없는 것은 의사결정 과정에서 고려할 필요가 없다는 입장을 취했다. 측정 가능한 모든 데이터가 유용하다고 보았으며, 정량 지표만으로 최선의 행동 방향을 판단하려 했다. 국방장관 재임 시절에도 이런 통계 중심적 사고방식을 전쟁 운영에 적용했고, 그 결과 적군의 사망자 수를 군사적 성과의 기준으로 삼는 방식처럼 왜곡된 지표 활용이 나타났다. 이것이 ‘맥나마라 오류’라는 표현이 생긴 배경이 됐다.

오늘날 소프트웨어 업계 역시 맥나마라 오류의 희생양이 될 위험에 처해 있다. 정량 지표는 분명 유용하다. 하지만 영향을 미치는 것이 분명한 정성적 요소를 무시하면 결국 중요하지 않은 것에 집착하는 상황으로 이어질 수 있다. 그리고 이는 실패로 직결될 수 있다.

숫자는 쉽다

우선, 소프트웨어 개발 과정을 측정하는 일은 점점 더 쉬워지고 있다. 깃(Git)이 사실상 표준 버전 관리 시스템으로 자리잡았고, 리니어B(LinearB), 젤리피시(JellyFish), 플랜덱(Plandek)과 같은 도구가 소프트웨어 리포지토리 내부 활동을 깊이 있게 분석하는 기능을 제공하면서, 팀이 무엇을 하고 있는지 보여주는 다양한 정량 지표를 쉽게 수집할 수 있게 됐다.

한때는 업계가 ‘하루에 작성한 코드 라인 수’처럼 터무니없이 단순한 수치를 진지한 성과 지표로 받아들였다는 사실은 지금 생각하면 우스꽝스럽게 느껴진다. 하지만 오늘날의 도구는 과거에는 관측조차 어려웠던 개발 활동의 흐름을 관리자가 직접 들여다볼 수 있게 해준다. 배포 빈도, 풀 리퀘스트 리뷰 소요 시간, 사이클 타임과 같은 기본적인 팀 단위 지표를 손쉽게 수집할 수 있고, 이를 통해 병목 구간을 파악하거나 의사결정에 참고할 수 있는 기반도 마련됐다.

이제 업계는 정량 지표는 손쉽게 확보할 수 있지만, ‘소프트’한 요소는 측정하기 어려운 시점에 와 있다. 물론 지금 활용할 수 있는 세밀한 지표가 유용하고 가치 있다는 점은 분명하다. 하지만 측정하기 어려운 요소를 고민하지 않고 측정이 쉬운 수치에만 의존하려는 유혹에 넘어가기 쉽다. 로버트 맥나마라가 바로 그 함정에 빠졌고, 현재의 소프트웨어 업계 역시 같은 실수를 반복하고 있다.

측정할 수 없는 요소를 놓치면 소프트웨어 개발을 성공으로 이끄는 본질 역시 잃게 된다. 컴퓨터 과학이나 소프트웨어 공학에만 집중하다 보면, 성공적인 프로젝트의 성패를 가르는 ‘사람 중심의 요소’를 간과하기 쉽다. 코드는 결국 사람이 쓰는 것이며, 그 과정에서 발생하는 인간적 요인이야말로 개발의 성패를 결정짓는 핵심이다.

소프트웨어 개발은 팀 스포츠에 가깝다. 물론 팀 안에서 개인이 빛날 수는 있어도 가장 중요한 것은 팀 전체의 성과다. 스포츠 팬들은 통계를 즐겨 보지만, 챔피언을 결정짓는 것은 수치가 아니다. 1위와 2위의 차이를 만드는 것은 숫자로 환산할 수 없는 무형의 요소다.

무형의 요소는 측정하기 어렵다

아무리 노력해도 ‘좋은 코드를 작성한다’는 것을 측정할 방법은 아직 없다. 좋은 코드와 나쁜 코드를 구분하는 능력은 오랜 경험을 통해서만 길러지며, 이를 객관적으로 수치화하는 방법은 존재하지 않는다. 언젠가 AI가 그 해답을 찾을 수도 있겠지만, 현재로선 어렵다. 누군가는 AI가 ‘좋은 코드’를 작성할 수 있다고 주장하겠지만, 그 코드가 좋은지를 판별하는 능력만큼은 여전히 인간만의 영역이다.

마찬가지로 ‘협업을 잘한다’는 것을 어떻게 측정할 수 있을까? ‘팀의 사기’는 또 어떨까? 이런 요소는 지금도, 앞으로도 수치화하기 어려울 것이다. 하지만 분명 중요한 가치이며, 직접 눈으로 보고 느끼는 능력이야말로 성공의 열쇠다. 소프트웨어 개발 관리자는 이런 무형의 요소를 인식하고 북돋는 역량을 반드시 갖춰야 한다.

결국 지표에 과도하게 집착하면 팀 사기를 해칠 수 있다. 스프레드시트 속 숫자로만 취급받고 싶어 하는 사람은 아무도 없다.

오늘날 사용할 수 있는 훌륭한 측정 도구를 적극 활용하길 권한다. 하지만 DORA(DevOps Research and Assessment) 지표처럼 다양한 정량 데이터를 검토할 때도, 숫자가 말해주지 않는 부분을 함께 고려해야 한다. 정량 지표는 분명 중요하지만, 때로는 직관이 주는 신호나 경험에서 오는 감각이 더 큰 가치를 발휘한다.

측정할 수 있는 것은 최대한 측정하되, 어떤 통계 도구로도 들을 수 없는 작고 조용한 목소리에도 귀를 기울여 보라.
dl-itworldkorea@foundryco.com