64개의 에이전트를 동시에 돌렸습니다. 그런데 11일 만에 완료된 이유는 에이전트가 많아서가 아니었습니다.

Bun이 최근 프레임워크 코어를 Zig에서 Rust로 전면 이식한 프로젝트를 공개했습니다. 규모가 상당합니다. 에이전트 64개를 동시에 투입해 11일 만에 전체 코드베이스 재작성을 완료했습니다. GeekNews에서 화제가 됐던 케이스입니다.

이 숫자들을 보면 흔히 이렇게 읽습니다. “에이전트를 많이 쓰면 빠르다.” 하지만 이 프로젝트의 핵심은 에이전트 숫자가 아닙니다.

600줄짜리 문서가 진짜 비결이었다

Bun 이식 프로젝트의 실제 인프라는 PORTING.md라는 단일 명세서입니다. 600줄짜리 문서 하나가 64개 에이전트의 공통 기준이었습니다.

각 에이전트는 이 문서를 좌표계로 삼아 판단했습니다. Zig 코드의 어떤 패턴이 Rust에서는 어떻게 번역되는지, 어떤 케이스가 수용 가능하고 어떤 케이스에서 멈춰야 하는지가 문서 안에 있었습니다. 거기에 적대적 리뷰(adversarial review) 프로세스를 얹었습니다. 에이전트들은 서로의 결과를 의심하며 교차 검증했습니다.

MCP 생태계에서도 같은 방향의 신호가 누적되고 있습니다. 공유 컨텍스트 레이어를 두자 토큰 사용량이 98% 줄었다는 사례가 나왔고, Ghidra는 MCP 서버로 110개 도구를 외부에 공개했습니다. 에이전트들이 공유할 수 있는 툴 레이어와 기준 레이어, 두 가지가 동시에 성숙하고 있습니다.

병렬 에이전트가 실패하는 진짜 이유

멀티 에이전트 프로젝트가 무너지는 패턴은 대부분 같습니다. 에이전트가 너무 적어서 실패하는 경우는 드뭅니다. 에이전트들이 각자 다른 방향으로 수렴하면서 드리프트가 누적됩니다.

10개의 에이전트가 10개의 방향으로 흩어지면, 나중에 이를 합치는 비용이 처음부터 직렬로 만드는 비용보다 커집니다. 속도를 위해 병렬을 선택했는데 후반 통합에서 병목이 생기는 역설입니다.

PORTING.md가 해결한 건 이 문제입니다. 에이전트들이 판단 기준을 공유할 때만 규모가 힘이 됩니다. 기준이 없으면 규모는 소음입니다.

이것은 인간 팀에도 동일하게 적용됩니다. 10명을 투입했는데 설계 문서가 없으면 코드 리뷰에서 다 다른 기준으로 충돌합니다. 에이전트는 이 문제를 더 빠르게, 더 큰 규모로 드러냅니다.

PM이 써야 할 것은 기능 명세가 아니다

이 케이스가 AI PM에게 던지는 질문은 하나입니다. 당신의 팀에서 멀티 에이전트를 운영할 때, PORTING.md에 해당하는 문서가 있습니까?

기능 명세서가 아닙니다. 에이전트들이 동일한 판단을 내릴 수 있는 기준 문서입니다.

  • 어떤 케이스에서 에이전트가 진행하고, 어떤 케이스에서 멈추는가
  • 출력물의 어떤 특성이 수용 가능하고 어떤 특성이 거부 대상인가
  • 에이전트 간 충돌이 발생했을 때 누구의 판단을 우선하는가

이 기준들을 한 문서에 담는 작업이 AI 시대 PM의 새 1차 산출물입니다. PRD나 스펙 문서를 잘 쓰는 것과는 다릅니다. 에이전트가 읽고 수렴할 수 있는 기준 문서를 만드는 역량입니다.

Bun의 PORTING.md는 600줄이었습니다. 처음부터 600줄을 쓸 필요는 없습니다. 하지만 에이전트를 병렬로 돌리기 전에 단 한 장이라도 공통 기준 문서가 있어야 합니다. 그게 없으면 64개든 640개든 마지막엔 사람이 정리해야 합니다.

에이전트를 많이 쓰는 것과 잘 쓰는 것은 다릅니다. 잘 쓰는 팀은 명세서를 먼저 씁니다.

당신의 멀티 에이전트 설계에 드리프트를 잡을 기준 문서가 있습니까?