코드에 더 많은 에이전트를 투입한다고 해서 속도가 빨라지지 않는 이유

현재 모든 이들이 자신의 AI 코딩 설정을 확장(scale up)하려고 노력하고 있습니다. 그 논리는 간단합니다. 만약 하나의 코딩 에이전트(coding agent)가 당신을 더 빠르게 만든다면, 왜 4개나 8개를 병렬로 실행하지 않겠느냐는 것입니다.

사람들이 저지르는 실수는 에이전트의 수를 주요 최적화 지표(optimization metric)로 취급하는 것입니다. 계획 없이 다수의 동시 에이전트(concurrent agents)를 가동하면, 기능 구현(feature delivery) 속도가 빨라지는 것이 아니라, 단지 영향 범위(blast radius)만 넓히고 컨텍스트 스위칭(context switching)의 늪에 빠지게 될 뿐입니다.

멀티 에이전트(Multi-agent)의 속도는 단순한 동시성(concurrency)에서 오는 것이 아닙니다. 그것은 명시적인 산출물(explicit artifacts), 엄격한 경계(strict boundaries), 그리고 핸드오프(handoff, 인수인계)를 채팅창 밖으로 옮기는 것에서 나옵니다.

핸드오프는 파일 내에 존재해야 합니다

만약 당신의 에이전트들이 서로의 채팅 메모리를 읽음으로써 협업하고 있다면, 당신의 시스템은 취약합니다.

실제로 4~8개의 병렬 에이전트를 성공적으로 운영하는 운영자들은 암묵적인 컨텍스트(implicit context)에 의존하지 않습니다. 그들은 명시적인 마크다운(markdown) 명세서, AGENTS.md 지침, 그리고 마일스톤 커밋(milestone commits)을 사용합니다. 워크플로우는 간단합니다. 플래너 에이전트(planner agent)나 사람이 파일에 명세(specification)를 작성하면, 워커 에이전트(worker agent)가 새로운 세션에서 해당 파일을 읽는 방식입니다.

구현 계획이 파일에 저장되어 있을 때, 새로운 워커 세션은 현저히 더 나은 성능을 발휘합니다. 의도(intent)를 보존할 수 있으며, 에이전트가 관련 없는 리팩터링(refactors)으로 벗어나는 것을 방지할 수 있습니다.

격리(Isolation)는 선택 사항이 아닙니다

병렬 에이전트에는 격리된 실행 환경(isolated execution environments)이 필요합니다. Open SWE와 같은 프레임워크들이 이를 강력하게 추진하는 데에는 이유가 있습니다.

만약 4개의 에이전트가 동일한 워크트리(worktree)에 대해 완전한 읽기/쓰기 권한을 가진다면, 그들은 서로의 작업을 방해하게 될 것입니다. 샌드박스(sandboxes), 별도의 브랜치(branches), 또는 완전히 새로운 환경이 필요합니다. 도구를 큐레이션하고 권한 경계(permission boundaries)를 강제하는 것이 에이전트가 얼마나 많은 도구에 접근할 수 있는지보다 훨씬 더 중요합니다.

검증(Verification)은 그 자체로 하나의 단계입니다

병렬 에이전트 워크플로우에서 흥미로운 부분은 코드가 작성된 이후에 일어나는 일입니다.

검증 (Verification)을 사후 고려 사항으로 취급해서는 안 됩니다. 검증은 파이프라인 내에서 그 자체로 명시적인 단계를 가질 가치가 있습니다. Google AI Studio 문서에서는 출력이 표류(drift)하는 것을 방지하기 위해 체크포인트 (checkpoints)와 구조화된 중단 (structured stops)을 사용할 것을 강조합니다. 독립적인 운영자들도 동일한 방식을 취하고 있습니다. 즉, 작업자 (worker) 역할과 검증 (verification) 역할을 분리하는 것입니다.

에이전트가 작업을 완료하면 작업이 끝났음을 알릴 방법이 필요하며, 사용자는 그 결과물을 검토할 방법이 필요합니다. 이것이 바로 실행 중 메시징 (mid-run messaging)과 반응형 채널 (reactive channels)이 중요해지고 있는 이유입니다. 흐름을 깨뜨리지 않으면서 세션 (session)에 이벤트를 밀어 넣고(push) 상태를 끌어오는(pull) 방식이 필요합니다.

마치며

에이전트를 더 많이 추가하면 검토 비용 (review cost)이 빠르게 증가합니다. 조정의 한계 (coordination ceiling)는 컴퓨팅 자원 (compute)이 고갈되기 훨씬 전에 먼저 찾아옵니다.

거대한 프롬프트 (prompts)를 통해 복잡한 내부 에이전트 로직을 오케스트레이션 (orchestrate)하려고 하지 마세요. 플래너 (planner) 작업과 구현 (implementation) 작업을 분리하십시오. 에이전트가 명시적인 사양 (specs)을 읽고 쓰도록 강제하십시오. 만약 핸드오프 (handoff)가 실체적이지 않다면, 당신은 실제로 병렬 에이전트를 실행하고 있는 것이 아니라 그저 혼돈을 관리하고 있는 것뿐입니다.

출처 노트

• Vibe-coding in Google AI Studio: my tips to prompt better and create amazing apps
• Open SWE
• How I run 4-8 parallel coding agents with tmux and Markdown specs
• Push events into a running session with channels