Mythical Man-Month가 다시 주목받는 이유
1975년, IBM의 프로젝트 매니저였던 프레더릭 브룩스는 한 권의 책을 펴냅니다.
출간 이후 반세기가 흐른 지금까지도 소프트웨어 업계에서 회자되는, 거의 신화 같은 존재입니다.
그런데, 왜 우리는 여전히 이 오래된 책을 읽고 있는 걸까요?
프로그래머의 입장에서 이 질문은 꽤 흥미롭습니다.
기술은 빠르게 진화하고, 도구는 매년 바뀌며, 개발 패러다임도 지속적으로 진화하는데,
50년 된 책이 여전히 '유효한 통찰'로 남아 있다는 건 뭔가 이상하기도 합니다.
그 이유를 하나씩 짚어보겠습니다.
왜 "맨먼스"는 허구인가
이 책의 제목은 이른바 "맨먼스(man-month)"라는 단위를 정면으로 비판하는 데서 시작됩니다.
브룩스는 이렇게 말합니다.
비용은 사람 수와 시간의 곱으로 측정할 수 있다. 하지만 진행(progress)은 그렇지 않다.
따라서 '맨먼스'는 위험하고 기만적인 단위다.
이는 결국, 개발 조직에서 흔히 벌어지는 오해를 지적하는 문장입니다.
개발이 늦어지면 사람을 더 투입해서 해결하려는 시도가 대표적입니다.
하지만 소프트웨어는 그렇게 동작하지 않습니다.
오히려 상황은 더 악화되곤 하죠.
이유는 간단합니다.
사람을 늘리면 그만큼 커뮤니케이션 비용이 폭증하고,
신규 인력의 온보딩에 시간이 걸리며,
이미 복잡해진 구조에 더 많은 변수와 오류가 유입되기 때문입니다.
저 역시 예외는 아니었습니다.
스타트업에서 일하면서 여러 번 이 문제를 겪었습니다.
어떤 프로젝트가 예상보다 지연되면,
매번 "한 명 더 뽑으면 어떨까요?"라는 제안이 자연스럽게 나왔습니다.
때로는 저도 그 말에 동의했습니다.
하지만 나중에 돌아보면, 대부분의 경우 정확한 문제 정의 없이 인력을 투입한 것이 사태를 더 꼬이게 만든 상황이었습니다.
브룩스의 말처럼, 문제는 인력 부족이 아니라 복잡성에 대한 설계와 이해 부족이었습니다.
"Brooks's Law"는 여전히 유효하다
『The Mythical Man-Month』에서 가장 유명한 개념은 아마도 이 문장일 것입니다:
늦어진 소프트웨어 프로젝트에 인력을 더 투입하면 더 늦어진다.
이른바 "브룩스의 법칙"입니다.
너무나 간단하지만, 현실에서 자주 무시되는 진실이기도 하죠.
이유는 무엇일까요?
아마도, 조직에서는 지연이 발생했을 때 무언가 '가시적인 조치'를 취해야 한다는 압박을 받기 때문일 겁니다. 그리고 그 가시적인 조치 중 가장 쉬운 것이 인력을 늘리는 것입니다.
하지만 실무에서는, 특히 초기 설계가 제대로 되지 않았거나,
요구사항이 자주 바뀌는 상황에서는 사람을 더 늘린다고 해결되지 않습니다.
오히려 그런 상황일수록 핵심 개발자가 조율자 역할을 하면서 복잡도를 낮추는 데 집중해야 합니다.
제 경험상, 정말 효율적인 프로젝트는 '적은 수의 잘 맞는 팀원'으로도 충분히 빠르게 진척됩니다.
문제는 대부분 복잡한 시스템에 적절한 인터페이스가 없고,
팀 간 역할과 기대치가 모호할 때 발생합니다. 브룩스는 이미 50년 전에 이 사실을 통찰했고, 우리는 여전히 그 교훈을 되풀이하고 있습니다.
왜 2025년에 다시 읽는가
『Mythical Man-Month』는 단지 역사적인 참고서가 아닙니다.
지금 읽어도 유효한 문장들이 가득합니다.
특히 아래의 두 가지 이유 때문에 다시 읽어볼 가치가 있다고 생각합니다.
기술이 아니라 "사람"을 다루는 책이기 때문입니다. 이 책은 코딩 기술이나 아키텍처 기법을 설명하는 책이 아닙니다. 소프트웨어를 개발하는 "사람들"에 대한 이야기, 그리고 그들이 모여서 일하는 방식에 대한 통찰입니다. 50년이 지나도 여전히 우리가 겪고 있는 문제(커뮤니케이션, 일정 관리, 역할 분배, 생산성)에 대해 다루고 있기 때문에 지금도 의미가 있습니다.
너무 많은 것이 바뀐 시대에, 무엇이 바뀌지 않았는지를 알게 해 주기 때문입니다. 우리는 클라우드, CI/CD, LLM, 자동화 도구 등 수많은 기술의 진보를 이루었지만, 여전히 프로젝트는 지연되고, 문서화는 부족하며, 커뮤니케이션 문제는 반복됩니다. 기술은 변했지만, 사람과 구조의 문제는 크게 다르지 않습니다.
박물관이 아니라, 거울이다
『The Mythical Man-Month』는 박물관 속 골동품이 아닙니다.
오히려 우리에게 지금도 유효한 질문을 던지는 거울에 가깝습니다.
우리는 왜 여전히 추정에 실패하는가?
왜 팀 규모를 늘려도 일정은 더 늦어지는가?
왜 커뮤니케이션 문제는 계속해서 반복되는가?
이 시리즈를 통해, 단순히 과거를 회상하는 데 그치지 않고, 오늘날의 실무와 연결 지어 생각해보려 합니다.
다음 편에서는, 개발이라는 행위 자체에 내재한 '기쁨과 고통'이라는 양면성에 대해 이야기해 보겠습니다.
→ 2편: “개발은 왜 여전히 고통스러운가?” — Joys and Woes, 50년 후
