GeekNews에 이번 주 흥미로운 사례가 올라왔습니다.

Bun으로 작성된 코드베이스를 Zig→Rust로 재작성한 팀의 이야기입니다. 64개의 에이전트를 병렬로 운용해 11일 만에 완료했다고 했습니다. 그런데 이 팀이 코드 한 줄을 건드리기 전에 한 일이 있었습니다.

600줄짜리 PORTING.md를 먼저 썼습니다.

병렬 에이전트를 설계할 때 가장 먼저 드는 질문은 대부분 이겁니다.

“몇 개를 돌려야 하죠?”

틀린 질문입니다. 에이전트 병렬화는 수량 결정이 아니라 명세 설계입니다.

64개의 에이전트가 Zig 코드를 Rust로 변환하는 동안, 이들을 하나의 방향으로 묶어둔 것은 모델 성능이 아니었습니다. 600줄짜리 마이그레이션 명세서였습니다. 어떤 패턴은 어떻게 바꾸고, 어디서 멈추고, 어떤 예외는 플래그를 달아야 하는지를 문서로 선언했기 때문에, 64개가 서로 다른 방향으로 표류하지 않았습니다.

에이전트 수가 늘수록 ‘드리프트’가 커집니다. 드리프트란 각 에이전트가 같은 목표를 향하는 것처럼 보이지만 실제로는 조금씩 다른 해석으로 움직이는 현상입니다. 1개일 때는 미미합니다. 10개가 되면 표면에 드러납니다. 64개가 되면 재앙이 됩니다.

이 팀이 드리프트를 막은 두 번째 장치가 ‘적대적 리뷰’였습니다. 한 에이전트의 출력이 다음 에이전트의 입력이 되는 파이프라인 구조가 아니라, 별도 에이전트가 이전 에이전트의 결과를 정면으로 반박하도록 설계했습니다. 11일이 걸린 이유는 에이전트를 배포한 게 아니라 검증 루프를 설계했기 때문입니다.

병렬 에이전트 시스템에서 진짜 병목은 처리 속도가 아닙니다. 드리프트 감지와 수렴입니다.

이 사례를 보면서 최근 MCP 생태계의 움직임이 겹쳐 보였습니다.

Ghidra MCP는 리버스 엔지니어링 도구 110개를 하나의 인터페이스로 묶었습니다. mksg.lu의 context-mode MCP는 에이전트 컨텍스트를 98% 줄이는 서버를 오픈소스로 공개했습니다. Safari MCP, WhatsApp MCP, 금융 데이터 MCP까지 배선층이 급속도로 표준화되고 있습니다.

도구 추가처럼 보이지만 저는 다르게 읽습니다.

MCP 배선층이 성숙할수록 병렬 에이전트 설계에서 인프라가 해결해주는 문제가 늘어납니다. 도구 호출 방식의 차이에서 오는 드리프트, 컨텍스트 크기에서 오는 비용 폭발, 권한 관리의 일관성 문제. 이 레이어가 표준화되면 남는 문제는 단 하나입니다.

“각 에이전트에게 무엇을 지시했는가.”

인프라가 해결해주는 것이 많아질수록 명세의 중요성은 역설적으로 커집니다. 공통 배선이 깔리고 나면, 시스템 품질을 가르는 것은 결국 각 에이전트의 역할 선언이기 때문입니다.

100 Agents를 설계하면서 같은 교훈을 반복해서 확인했습니다.

에이전트를 추가할 때마다 성능이 좋아진 것이 아니라, 각 에이전트의 역할 경계를 명확히 쓸 수 있을 때 시스템이 안정됐습니다. 어떤 에이전트가 어디서 멈추고, 어떤 출력이 다음 에이전트로 넘어가는지를 한 줄로 설명할 수 없으면 병렬로 돌릴 준비가 안 된 것입니다.

저는 이것을 ‘PORTING.md 원칙’이라고 부르고 싶습니다.

멀티에이전트 시스템을 시작하기 전에, 각 에이전트에게 무엇을 시킬지를 문서로 선언해야 합니다. 경계, 입출력 계약, 드리프트를 감지할 기준, 적대적 검증 지점. 이 명세가 먼저 있어야 에이전트 수를 논할 수 있습니다.

600줄짜리 PORTING.md를 먼저 쓴 팀은 하나를 알고 있었습니다.

에이전트에게 일을 시키기 전에, 사람이 먼저 그 일을 충분히 이해해야 한다는 것을.

당신의 멀티에이전트 시스템에는 PORTING.md가 있습니까? 각 에이전트가 무엇을 해야 하는지, 어디서 멈춰야 하는지, 어떤 출력이 다음으로 넘어가는지를 선언한 명세가 있습니까?

에이전트 수가 아니라 그 명세의 밀도가 시스템의 품질을 결정합니다.