50년 된 책이 다시 소환된 이유
프레드 브룩스(Fred Brooks)의 『맨먼스 미신(The Mythical Man-Month)』은 1975년에 나온 책이에요. IBM에서 OS/360이라는 거대한 운영체제 프로젝트를 이끌며 겪은 시행착오를 정리했는데, 반세기가 지난 지금도 소프트웨어 공학 필독서로 꼽히거든요. 최근 이 고전을 AI 시대의 눈으로 다시 읽어보자는 글이 올라왔는데, 타이밍이 절묘해요. 요즘 우리는 코딩 에이전트를 여러 개 띄워놓고 일을 나눠 맡기는 걸 진지하게 고민하잖아요. 이건 브룩스가 50년 전에 경고한 상황, 즉 ‘사람을 더 넣으면 빨라지겠지?’와 구조가 똑같아요.
브룩스의 법칙, 이게 뭐냐면
책의 핵심은 한 문장으로 유명해요. “늦어진 소프트웨어 프로젝트에 인력을 추가하면 더 늦어진다.”
‘맨먼스(man-month)’는 한 사람이 한 달 동안 하는 작업량을 뜻하는 단위예요. 이 단위에는 사람과 시간을 맞바꿀 수 있다는 가정이 깔려 있어요. 10맨먼스짜리 일이면 10명이 1달, 혹은 1명이 10달이면 끝난다는 식이죠. 브룩스는 이게 미신이라고 했어요. 아이를 낳는 데는 9개월이 걸리고, 산모 9명을 투입한다고 1개월로 줄지 않는다는 유명한 비유도 여기서 나왔어요.
이유는 크게 두 가지예요. 첫째는 소통 비용이에요. n명이 서로 소통하는 경로는 n(n-1)/2개로 늘어나요. 5명이면 10개, 10명이면 45개, 20명이면 190개예요. 사람은 2배가 됐는데 조율할 관계는 4배 넘게 늘어나는 거죠. 둘째는 온보딩 비용이에요. 새로 온 사람이 맥락을 파악하려면 기존 멤버의 시간을 빼앗을 수밖에 없거든요.
AI 에이전트는 ‘사람’일까?
AI 에이전트는 온보딩에 몇 주씩 걸리지 않아요. 저장소를 읽고 몇 분 만에 일을 시작하죠. 그럼 브룩스의 법칙에서 자유로울까요?
절반만 그래요. 온보딩 비용은 확실히 줄었지만, 소통 비용은 모양만 바뀌어 남아 있어요. 에이전트 여러 개가 같은 코드베이스를 병렬로 건드리면 머지 충돌이 나고, 각자 비슷한 유틸 함수를 따로 만들고, 서로의 가정을 모른 채 인터페이스를 바꿔버려요. 결국 이걸 조율하고 리뷰하는 건 사람이에요. 에이전트 10개를 띄우면 리뷰할 PR도 10개가 되는데, 사람의 리뷰 속도는 그대로잖아요. 병목이 ‘코드 작성’에서 ‘검토와 통합’으로 옮겨갈 뿐이에요.
데이터도 비슷한 얘기를 해요. 2025년 연구 기관 METR이 숙련된 오픈소스 개발자들을 대상으로 실험했더니, AI 도구를 쓴 쪽이 오히려 작업 시간이 약 19% 더 걸렸어요. 재미있는 건 참가자들 스스로는 20% 정도 빨라졌다고 느꼈다는 점이에요. 2025년 초 도구 기준이라 지금은 다를 수 있지만, 체감 생산성과 실제 생산성이 어긋날 수 있다는 교훈은 여전히 유효해요.
코딩은 전체 일정의 1/6이었다
책에서 덜 알려졌지만 지금 꼭 다시 볼 대목이 있어요. 브룩스는 경험적으로 일정을 이렇게 나눴어요. 계획 1/3, 코딩 1/6, 구성요소 테스트 1/4, 시스템 테스트 1/4.
코딩이 고작 1/6이에요. 1975년 기준 비율이긴 하지만, AI가 코딩 시간을 0으로 만들어도 전체 일정은 최대 17% 정도만 줄어든다는 계산이 나와요. 병렬 컴퓨팅의 암달의 법칙, 그러니까 ‘전체 속도는 빨라지지 않는 부분이 결정한다’는 원리와 똑같죠.
브룩스가 1986년에 쓴 에세이 「은탄환은 없다(No Silver Bullet)」도 같은 맥락이에요. 그는 소프트웨어의 복잡성을 본질적 복잡성(문제 자체가 어려워서 생기는 것)과 우연적 복잡성(도구나 언어 때문에 생기는 것)으로 나눴어요. AI는 보일러플레이트 작성, 문법 찾기, API 사용법 검색 같은 우연적 복잡성을 크게 줄여줘요. 하지만 ‘이 서비스가 정확히 무엇을 해야 하는가’라는 본질적 복잡성은 여전히 우리 몫이에요.
오히려 지금 더 맞아떨어지는 ‘외과 수술팀’
반대로 AI 시대에 더 빛나는 아이디어도 있어요. 브룩스는 할런 밀스(Harlan Mills)의 ‘외과 수술팀’ 모델을 소개했는데요, 실력 있는 집도의 한 명이 핵심 설계와 코드를 책임지고 나머지(부집도의, 도구 담당, 테스터, 언어 전문가 등)가 그를 지원하는 구조예요. 목표는 개념적 무결성, 즉 시스템 전체가 한 사람의 머릿속에서 나온 것처럼 일관되게 설계되는 것이었어요.
이건 ‘개발자 1명 + AI 에이전트 여러 개’와 거의 같은 그림이에요. 테스트 작성, 문서 정리, 리팩터링, 라이브러리 조사는 에이전트가 맡고 사람은 설계 결정과 최종 판단에 집중하는 거죠. 사람으로 꾸리기엔 비쌌던 모델을 AI가 싸게 만들어준 셈이에요. ‘하나는 버릴 각오로 만들어라(Plan to throw one away)’는 조언도 프로토타입 비용이 거의 0이 된 지금 훨씬 실천하기 쉬워졌고요.
한국 개발자에게 주는 시사점
한국 SI 업계는 지금도 M/M(맨먼스) 기준으로 견적을 내고 계약하는 경우가 많아요. 기능점수(FP) 방식도 있지만 현장에선 ‘몇 명이 몇 개월 투입되느냐’가 여전히 기준이죠. 한 사람이 AI로 낼 수 있는 결과물이 크게 달라지는 상황에서 이 방식이 계속 유효할지는 진지하게 고민해볼 문제예요.
실무에선 이렇게 정리해볼 수 있어요.
- 에이전트를 병렬로 돌릴 땐 작업을 독립적으로 쪼개세요. 같은 파일을 건드리지 않게 경계를 나누는 게 사람 팀보다 더 중요해요.
- 리뷰 역량이 새로운 핵심 역량이에요. 코드를 빨리 쓰는 능력보다 남(혹은 AI)이 쓴 코드를 빠르고 정확하게 판단하는 능력이 더 중요해지고 있어요.
- 설계 문서와 컨벤션에 투자하세요. 에이전트에게 개념적 무결성을 전달하는 가장 확실한 방법은 잘 쓴 문서예요.
마무리
AI는 맨먼스를 싸게 만들었지만, 소통과 개념적 무결성의 비용까지 없애주진 않았어요. 대상이 사람에서 AI로 바뀌었을 뿐, 50년 전 브룩스의 통찰은 여전히 살아 있어요.
여러분의 팀은 어떤가요? AI 도구를 도입한 뒤 실제 출시 일정이 줄었나요, 아니면 병목이 리뷰나 QA로 옮겨가기만 했나요?
🔗 출처: Hacker News