기술 위키에 문서 네 편을 더 써야 했다. MCP, 멀티 에이전트, LLM 판정, 실시간 렌더링. 문제는 넷이 전부 다른 프로젝트의 코드에 근거해야 한다는 거였다. MCP는 그어봄 서버를, 멀티 에이전트는 .claude/agents 정의를, LLM 판정은 saegim-eval 채점기를, 실시간 렌더링은 noon의 SpriteKit 코드를 읽어야 나온다.
한 편씩 쓰면 이렇게 된다. 그어봄을 파느라 컨텍스트를 잔뜩 채우고, 다음 문서를 쓸 즈음엔 그 코드가 머릿속에서 밀려나 있다. 넷을 순서대로 하면 앞에서 읽은 걸 뒤에서 잊는다. 그래서 넷을 동시에 시켰다.
넷을 한 번에 풀었다
서브에이전트 넷을 병렬로 띄웠다. 각자 프로젝트 하나씩 맡아 실제 코드를 조사하고, 위키 포맷과 정직성 규칙에 맞춰 자기 문서 초안까지 쓴다. 나는 오케스트레이터로 남아 넷의 결과를 받아 검증하고 엮는 자리에 섰다.
여기엔 결이 하나 있다. 지금 쓰는 이 글감이 된 문서 중 하나가 하필 "멀티 에이전트"다. 멀티 에이전트 오케스트레이션을 설명하는 문서가, 멀티 에이전트 오케스트레이션으로 쓰였다. 그 문서를 맡은 에이전트는 자기가 지금 병렬 팬아웃의 한 갈래로 돌고 있다는 걸 그대로 본문에 적었다.
병렬의 진짜 값은 속도가 아니었다
넷을 동시에 굴리면 빠르다. 그건 예상한 이득이다. 그런데 안 예상한 게 더 컸다. 각 에이전트가 한 코드베이스에 깊이 박히니, 내가 대충 알고 넘긴 걸 코드를 읽고 바로잡았다.
넷이 각자 잡아낸 것
셋 다 내가 프롬프트로 준 방향이 틀렸거나 흐렸던 지점이다. 한 대화에서 넷을 급히 훑었다면 내 표현을 그대로 받아 적었을 것이다. 각자 한 프로젝트만 붙잡고 코드를 실제로 연 에이전트라서, "당신이 준 전제가 코드와 다르다"고 말해줬다. 병렬은 시간을 줄인 게 아니라, 네 개의 독립된 눈을 코드에 붙여준 거였다.
그래서 내 일은 검증이었다
넷이 초안을 던졌다고 끝이 아니다. 오히려 그때부터가 내 일이었다. 네 편을 전부 처음부터 끝까지 읽었다. 도구 태그가 샜는지, 컴포넌트 문법이 맞는지, 이모지가 끼었는지, 상호 링크가 실제로 연결되는지. 실시간 렌더링 문서에선 표정 묘사에 박힌 특수 기호 하나를 빼고, 멀티 에이전트 문서에선 "이번에 병렬로 쓴 네 편"의 목록이 실제와 안 맞아 고쳤다.
순차로 한 대화
- 앞 코드가 뒤에서 밀려남
- 내 표현을 그대로 받아 적음
- 검증이 조사에 묻힘
병렬 넷 + 검증
- 각자 한 코드베이스에 집중
- 전제 오류·날조를 코드로 반박
- 정독 검증이 오케스트레이터의 일
핵심은 이거다. 위임은 공짜가 아니다. 넷을 띄운 만큼 넷을 검증해야 하고, 그 검증을 건너뛰면 병렬로 빨리 틀리는 것뿐이다. 각 에이전트에 "실제 코드에 있는 것만 써라, 근거 파일을 대라, 확인 못 하면 빼라"를 못 박아둔 게, 속도보다 결과를 지킨 진짜 장치였다. 넷이 하나같이 "넣고 싶었지만 코드에서 확인 못 해 뺐다"를 보고서에 남긴 게 그 증거다.
남은 것
이 위키는 원래 하네스·RAG 두 편뿐이었다. 거기에 네 편이 붙어 여섯이 됐고, 그 넷은 한 명이 순서대로 쓴 게 아니라 넷이 동시에, 각자의 코드 위에서 썼다. 오케스트레이션을 자랑하려고 병렬로 한 게 아니라, 네 개의 근거가 서로 다른 곳에 있어서 그게 맞는 구조였을 뿐이다.
배운 건 두 줄로 남는다. 병렬의 값은 속도이기 전에 독립된 시선이다 — 각자 한 코드베이스에 깊이 들어가면, 오케스트레이터가 대충 안 걸 잡아준다. 그리고 그 시선을 믿을 수 있는 건 팬아웃이 아니라 가드레일 덕이다. 넷을 띄우는 것보다, 넷에게 "지어내지 마라"를 박고 넷을 다 읽는 게 어려웠다.