이전에 AI를 위한 Web 앱 프레임워크를 만들었다는 글을 쓴 적이 있습니다.

이 FW(Framework)를 개발한 배경에는, 현재의 업무 환경으로 이직하자마자 직면했던 '극도로 타이트한 스케줄의 업무 시스템 개발'이라는 과제가 있었습니다.

기존의 접근 방식으로는 요구사항을 충족하면서 납기를 맞추는 것이 불가능했기 때문에, 이전부터 구상해 왔던 AI 주도 개발(AI-driven development) 기법으로 완전히 전환하는 과정에서 탄생한 것이 Lattice입니다.

그리고 버전을 거듭하며 업데이트를 진행해 왔고, 현재도 실무 프로덕트 개발에서 매우 적극적으로 활용하고 있습니다.

여기까지 읽으셨다면 엔지니어 분들이라면 아마 높은 확률로 이런 의문이 드실 겁니다.

'어? 그거 완전 개인의 역량에만 의존하는(属人化, Silo/Individual dependency) 것 아닌가요?'

맞습니다. 버스 계수(Bus Factor, 몇 명이 사라지면 프로젝트가 중단되는가)는 1이며, 코드를 봐줄 동료도 없으니까요.

그러던 중, 기분 전환 삼아 무심코 『맨먼스 미신 (The Mythical Man-Month)』을 다시 읽고 있었는데, 그 거장 Brooks가 50년 전에 "설계하는 머리는 하나로 하라"라고 썼다는... 이야기입니다.

먼저 전제로, 브룩스의 법칙(Brooks's Law).

지연되고 있는 소프트웨어 프로젝트에 인원을 추가하는 것은 그 프로젝트를 더욱 지연시킨다.

너무나 유명한 문장이지만, 중요한 것은 그 이유입니다. Brooks는 세 가지를 꼽았습니다.

• 새로운 사람이 전력이 되기까지의 교육 기간
• 분할할 수 없는 태스크(Task)의 존재
• 커뮤니케이션 패스(Communication Path)의 폭발

특히 3번. 패스의 수는 인원을 n이라고 할 때 n(n-1)/2로 증가합니다. 3명이면 3개. 10명이면 45개. 50명이면 1,225개. 사람은 선형적으로만 늘어나는데, 연결 고리는 제곱으로 늘어나는 셈입니다.

아주 거칠게 말하자면, 사람을 추가했을 때 늘어나는 것은 손이 아니라 회의...라는 것이죠.

나무에 그네를 달아달라는 단순한 의뢰가 관계자들의 손을 거칠 때마다 왜곡되어 간다는... 이 유명한 풍자화.

등장인물이 모두 제각각인 회사와 부서의 사람들. 영업이 들은 이야기가 리더에게 전달되고, 애널리스트가 설계하며, 하청업체의 프로그래머가 코드를 작성한다. 패스가 하나 통과될 때마다 정보가 누락됩니다.

이것은 n(n-1)/2가 시각화된 그림입니다. 특히 일본 IT 업계의 다중 하청 구조는 이 n을 구조적으로 계속 늘려가는 최악의 메커니즘이 되어 있습니다.

그리고 이 그림에서 개인적으로 가장 뼈아프게 다가오는 것이 6번째 칸입니다. '프로젝트 서류' 칸이 밑동으로 되어 있어 아무것도 남아 있지 않습니다. 이 글은 이후 계속해서 문서(Document) 이야기를 하겠지만, n이 불어난 현장에서 가장 먼저 증발하는 것이 무엇인지는 이 한 컷이 전부 말해주고 있습니다.

여기서부터가 본론입니다.

브룩스의 법칙만 독자적으로 회자되기 쉽지만, 『맨먼스 미신』 제3장에는 제대로 된 처방전이 적혀 있습니다. '외과 수술 팀'이라는 장입니다. 원안은 Harlan Mills가 1971년에 제안한 chief programmer team(주임 프로그래머 팀)입니다.

이 Mills의 안을 소개하는 Brooks의 필력이 가차 없어서 좋아하는데, 이렇게 대비시킵니다. 돼지 해체 팀이 되지 말고, 외과 수술 팀이 되어라라고 말이죠.

해체 팀은 전원이 고기를 자릅니다. 인원수만큼 손이 늘어납니다. 반면 외과 수술 팀에서 자르는 것은 집도의 단 한 명뿐입니다. 나머지는 모두 그 한 명이 자르는 것에 집중할 수 있도록 지원합니다.

집도의의 업무는 철저합니다. 사양(Specification)을 정의하고, 설계하고, 코드를 작성하고, 테스트하고, 문서까지 직접 작성합니다. 그리고 주변의 9명은 다음과 같습니다.

부조종사 (copilot): 설계를 함께 고민하고 평가한다. 손은 움직이지만 결정은 집도의가 한다. 또한 코드를 구석구석 파악하고 있으며, Brooks의 표현을 빌리자면 "집도의에 대한 재난 보험 (insurance against disaster)"
언어 변호사 (language lawyer): 사용 언어의 세부 사항에 비정상적으로 해박한 사람. "그렇게 작성하면 이렇게 동작한다"를 즉답함
도구 관리자 (toolsmith): 집도의 전용 툴이나 스크립트를 준비함
그 외 관리자, 편집자, 비서 2명(관리자 포함 및 편집자 포함), 프로그램 사무원, 테스터

왜 이렇게까지 하는 걸까요?

Brooks의 답은 개념적 완전성(conceptual integrity)입니다. 설계하는 머리가 늘어날수록 시스템은 일관성을 잃고 누더기가 됩니다. 그래서 10명이 있더라도 설계하는 머리는 하나로 유지합니다. 늘려도 되는 것은 지원 역할뿐이라는 뜻입니다.

요컨대 Brooks는 "혼자서 설계하라. 나머지 전원은 그를 지원하라"라고 말하고 있었던 것입니다.

그렇다면 왜 외과 수술 팀은 표준이 되지 못할까요?

답은 간단합니다. 단순하게 돈 문제입니다. 위의 방식은 지원 역할을 9명이나 고용해야만 성립하기 때문입니다.

집도의 1명을 위해 언어 변호사(Language Lawyer)와 도구 관리자(Toolman), 사무원을 전담으로 둘 수 있는 회사가 세상에 얼마나 있을까요? 적어도 중소기업에는 무리입니다. 그래서 현실의 현장은 더 저렴한 해체 팀으로 흘러갔습니다. 모두가 똑같이 살을 베어내는, 인월(Man-month) 단위로 계산되는 팀으로 말이죠.

하~지마안!!

현재 Claude 등의 AI는 이 9명이 담당했던 역할을 '거의' 전부 한꺼번에 대신해 줍니다. 설계의 브레인스토밍 상대(Co-pilot)가 되어주고, 언어 사양의 세부 사항을 즉답하며(언어 변호사), 일회용 스크립트를 작성하고(도구 관리자), 테스트를 돌리고, 회의록까지 남깁니다.

이 '거의'라는 부분이 나중에 큰 차이를 만드므로, 머릿속 한구석에 잘 담아두시기 바랍니다.

당연하게도, 집도의의 의자에는 제가 앉습니다. 설계 판단과 품질 관리는 넘겨주지 않습니다.

50년 전의 처방전이 드디어 1명이 실행할 수 있는 비용까지 떨어진 것. 1인 + AI라는 것은 바로 그런 체제라고 생각합니다.

여기서 서두의 비판으로 돌아가겠습니다.

애초에 속인화(Personification)란 무엇인가? 인원수의 문제가 아닙니다. 그 사람의 머릿속에만 존재하는 상태를 말합니다.

그렇다면 5인 팀이라도 설계 판단의 이유가 누구의 머릿속에도 없고 구전으로만 남아 있다면, 그것은 속인화되어 있는 것입니다. 오히려 5인분만큼 속인화되어 있는 것이죠. 인원수는 속인화를 방지하는 변수가 아닙니다.

그리고 1인 + AI에는 결정적인 성질이 있습니다.

인간 동료에게는 "그 건 말이야, 평소 느낌대로"라고 하면 통합니다. AI에게는 통하지 않습니다. 세션이 바뀌면 기억은 제로로 돌아갑니다(이것은 시스템적으로 방지할 수 있습니다만).

어쨌든 전제도, 제약도, 결정 이유도 적혀 있지 않으면 제대로 움직이지 않습니다.

즉, AI와 팀을 이루어 개발하면 문서(Document)가 부산물로서 남게 됩니다. 쓰지 않으면 일이 진행되지 않기 때문에 쓰는 것입니다. 의지력이 아니라 환경이 그렇게 만드는 것입니다.

다만 인력 개발과 결정적으로 다른 점은, 그 환경을 유지하는 동기 자체가 AI 측으로부터 공급된다는 점입니다. 이유는 후술하겠습니다.

실례로서, 어떤 사내 업무 시스템을 1인 + AI로 개발하고 있는 리포지토리(Repository) 구성의 일부분입니다.

docs/
├── CHANGELOG.md ← 구현 이력 (왜 그렇게 만들었는가)
└── BACKLOG.md ← 의도적으로 미뤄둔 TODO
...

예를 들어 CHANGELOG.md에는 다음과 같은 섹션이 있습니다.

이것이 일반적인 팀 개발에서 남을까요? "왜 select인가"는 대개 작성한 본인의 머릿속에만 있습니다. 반년 뒤의 자신의 머릿속에도 남아 있지 않습니다. 그리고 다른 누군가(혹은 자기 자신)가 "왜 이런 곳에 select를 썼지?"라며 <input type="time">으로 "개선"했다가, 스마트폰에서 레이아웃이 깨지고...

CHANGELOG.md에는 실패의 경위까지 자동으로 남기는 구조로 만들었습니다. 예를 들어, 일정표의 바(Bar)에서 내용이 삐져나왔을 때 무엇을 순서대로 시도했는지 말입니다.

• 단순히 행 높이를 높인다 → 화면이 약 3배로 늘어나 가독성을 잃으므로 기각
• 짧은 바는 시간 행을 접어서 내용을 한 줄로 보여준다 (컨테이너 쿼리, Container Query) → 30분 일정은 해결
• 행 높이는 미세하게만 높인다 (46→50px) → 어디까지나 보조적 수단
• 그래도 15분 일정은 한 줄 높이를 채우지 못해 여전히 타이트함
• 나머지는 "최소 높이 보장"이 필요하지만, 바의 겹침 현상에 부작용이 생기므로 BACKLOG.md로 분리

효과가 없었던 안들이 이유와 함께 순서대로 남아 있기 때문에, 반년 뒤의 누군가가 "행 높이를 높이면 되지 않을까?"라고 생각하더라도, AI가 "그건 안 됩니다"라고 알려줍니다.

사라진 것은 어디까지나 "인간끼리의 합의를 취하기 위한 조정 문서"입니다. 승인을 받기 위한 사양서, 인식을 맞추기 위한 회의록, 인수인계를 위한 절차서.

이것들은 n(n-1)/2의 산물이므로, n이 1이 되면 필요 없어집니다.

남은 것은 "AI에게 문맥을 전달하기 위한 컨텍스트 문서(Context Document)". 이것은 n과는 무관하게 필요하며, 오히려 AI 주도 개발(AI-driven development)에서야말로 필수적입니다.

즉, 문서가 사라진 것이 아니라, 독자가 인간에서 AI로 바뀌었을 뿐입니다.

그리고 아이러니하게도, 후자 쪽이 인수인계에 더 유용합니다.

인간용 사양서는 "합의한 순간"의 스냅샷이므로, 작성을 마친 순간부터 부패하기 시작합니다. 업데이트하지 않아도 아무도 곤란해하지 않습니다. 곤란해지는 것은 반년 뒤의 타인뿐입니다.

一方でAI向けのコンテキストは、腐らせると別のセッションでAIが誤動作して自分が損をする。だから私のような怠惰な者は、そこが陳腐化しないよう自動化する動機がその場で発生します。

また、実装計画用のマークダウンファイルをAIに整理させれば、「最新の」仕様書をお好みの形ですぐ出ます。逆は無理です。

ただし、この体制で解けていない問題もあります。

一番キツいのは、バス係数が1のままだという点。ここは本当にどうにもなりません。知識の属人化は外に出せても、稼働の属人化は残ります。

1人が倒れたらプロジェクトはそこで止まってしまう。ドキュメントがあるから引き継げるだけであって、止まらないわけではありません。この2つはまったく別の話で、そこに関しては返す言葉がありません。

そして面白いことに、この穴の位置は50年前の設計図に予告されていました。

さきほど頭の隅に置いてもらった「ほぼ」です。ブルックスの副操縦士には機能が2つありました。設計の壁打ち相手と、執刀医に対する災害保険。AIが肩代わりしたのは前者だけで、後者は落ちています。AIは私が倒れても代わりに執刀してはくれません。

つまり1人＋AIとは、外科手術チームから副操縦士の保険機能だけを抜いた体制のことです。この穴はたまたま空いたわけではなく、9人をAIに置き換えた時点で構造的に確定していた、というわけですね。

また、ドキュメントが残ることと、それが正しいことも別の話です。

AIは自信満々に間違った記録も書きます。定期的に実装と突き合わして整理する仕組みを作っておかないと、嘘が公式記録として固定されてしまいます。（逆に言えば仕組みで防げる部分でもある）

そしてブルックス自身が釘を刺しています。彼は1986年の「銀の弾などない」で、ソフトウェアの複雑性を本質的なもの（essential）と偶有的なもの（accidental）に分けました。

道具が潰せるのは偶有的なほうだけ、というのが結論です。

AIが潰しているのも、まさに偶有的複雑性のほうです。タイピング、ボイラープレート、APIの調べもの、環境構築。

ブランコ風刺画の1コマ目、顧客が自分の欲しいものを言語化できない問題は、AIでは解けません。そこは今も人間の仕事として残っていますし、今後シニアエンジニアの価値が上がる部分だとも思います。

射程も断っておきます。ここまでの話は中小企業向けの業務システム規模での実感ですので、OSや大規模基盤のように大人数が必然の領域には当てはまりません。※ブルックスが OS/360 を作りながら考えたのはそっち側ですし、外科手術チームも「大きな仕事を分割した、その1区画」の話でした。

属人化かどうかを決めるのは、人数ではありません。頭の中にあるものが、外に出ているかどうかです。

その物差しで見ると、ドキュメントの無い5人チームは、1人＋AIより属人化しています。しかも5人ぶん、誰もそれに気づかないまま。

ブルックスは50年前に「設計する頭は1つに、残りは支援に回せ」と書きました。当時それを実行するには、9人分の人件費が必要だった。AIは、その支援役をようやく現実的な値段で連れてきてくれたわけです。ありがたやー。

1人＋AIは属人化する体制ではなくて、属人化を強制的に外に吐き出させる装置だと思っています。用意しないとAIが意図通りに動いてくれないので、用意するしかない。

ただし、外に出せたのは知識の属人化だけです。稼働の属人化＝バス係数1は、副操縦士の保険機能を落とした穴として、そのまま残っています。この記事が主張しているのは前者だけで、後者について私はまだ何も解いていません。

私みたいな怠惰な人間には、これくらい強制力があるほうがちょうどいいのかもしれません。

参考

• Frederick P. Brooks, Jr. 『人月の神話』（The Mythical Man-Month, 1975 / 20周年記念増訂版 1995）第3章「外科手術チーム」、第4章「貴族政治、民主政治、そしてシステムデザイン」
• Frederick P. Brooks, Jr. "No Silver Bullet — Essence and Accident in Software Engineering" (1986)
• Harlan D. Mills, "Chief Programmer Teams: Principles and Procedures," IBM Federal Systems Division Report FSC 71-5108 (1971)

AI가 알아서 써주는 것은 아닙니다. 허술한 프롬프트(Prompt)를 입력해도 AI는 나름대로 작동하며, 문서(Document)를 단 한 줄도 남기지 않고 AI 주도 개발(AI-driven development)을 하는 사람도 얼마든지 있습니다. 강제성이 작용하는 것은 어디까지나 "그러한 환경(시스템)을 마련한다면"이라는 전제하의 이야기입니다. ↩