멀티 에이전트 오케스트레이션을 실제로 사용하시나요, 아니면 단일 에이전트로 충분한가요?

멀티 에이전트 워크플로우를 몇 번 구축해 봤지만 매번 후회했습니다. 토큰 대부분이 코드를 수정하는 데 쓰이는 게 아니라, 플래너가 작업자에게 지시하고 작업자가 보고하고 인수인계 내용을 다시 설명하는 등의 워크플로우를 돌리는 데 소모되었습니다. 에이전트들은 서로의 기초 작업을 계속 다시 수행했는데, 각 에이전트가 뭔가를 건드리기 전에 코드베이스를 다시 파악해야 했기 때문입니다.

제 첫 대형 프로젝트는 Cursor에서 에이전트 간 인수인계 체인으로 구축했는데, Claude Code로 처음부터 다시 만들 때 그 체인 전체를 가장 먼저 잘라냈습니다. 절약한 것보다 유지 관리 비용이 더 많이 들었고, Cursor 요금은 월 300달러를 넘겼거든요.

지금 저에게 효과적인 방식은 계층 구조 대신 병렬 스트림입니다. 여러 개의 평범한 단일 에이전트를 각각 별도의 git 워크트리와 브랜치에서 작업하게 하고, 모두 동일한 소규모의 잘 정의된 도구(테스트 실행, 통과 시 병합)를 사용하게 합니다. 플래너는 없습니다. 작업 분할은 제가 직접 하는데, 1분이면 끝나고 제가 어떤 부분이 정말 독립적인지 알기 때문에 제가 해본 어떤 플래너보다 낫습니다.

작업들이 파일을 공유하지 않으면 병합 충돌은 거의 사라집니다. 두 작업이 파일을 공유해야 할 때는 순차적으로 실행합니다.

그래서 결론은, 멀티 에이전트를 계속 켜두지 않습니다. 병렬 단일 에이전트 방식은 하루 종일 사용합니다.

멀티 에이전트 오케스트레이션을 위해 어떤 소프트웨어를 사용하시나요? 아니면 사람들이 주로 뭘 쓰나요?

직접 실험해보고 싶은데 소프트웨어 개발 배경이 없어서요.

실제로 단일 에이전트보다 작업을 더 빠르고 좋게 끝냈나요?

더 빠르지는 않지만, 더 많은 자율성을 통해 더 나은 품질을 얻었다고 표현하고 싶네요. 작업 자체가 처음부터 고도로 병렬화 가능한 게 아니라면 일반적으로 더 느리다고 봅니다. 이유는 에이전트 팀이 스스로 작업을 검토하기 때문입니다. 저는 스크린샷을 사용하여 버튼 배치, 간격, 레이아웃 등을 비판하는 '최종 사용자 옹호자(End-User Advocate)' 에이전트를 두고 있습니다.

이제 세부 사항에 덜 관여해도 된다는 자신감이 생겼습니다.

또한, 여러 에이전트 프로필을 구성하여 Anthropic, OpenAI, DeepSeek 등 여러 제공업체에 비용을 분산하고 있습니다.

이 설정에서 리드 에이전트가 작업을 시작할 때 특정 작업에 맞춰 프롬프트를 작성하는 방식이 효과적입니다. 제 지침(아래 gist 링크)을 따르면 리드 에이전트가 작업에 맞는 올바른 에이전트를 선택하고 매우 상세한 지침을 제공합니다. Opus 5.5나 Sol 6.1로 구동되는 DeepSeek, Luna, Haiku 조합은 훨씬 낮은 비용으로 정말 탄탄한 결과물을 만들어냅니다.

어디서 문제가 발생했나요? 병합 충돌, 에이전트 간 간섭, 플래너의 잘못된 작업 분할 등?

단일 조정 리드 에이전트가 있다면 문제가 발생하지 않습니다.

Claude 관련 팁: 현재 모델들은 모두 100만 컨텍스트 윈도우에 짧은 TTL을 가지고 있으니 /autocompact 300000을 사용하세요. 이런 팀 구성에서는 에이전트가 캐시 TTL을 넘어가면 비용이 빠르게 상승합니다. 압축 임계값을 낮추면 리드 에이전트가 나중에 TTL 이후에 서브 에이전트에게 다시 작업을 요청할 때, 80만 토큰을 한계치 근처로 보내는 것보다 훨씬 저렴합니다.

300,000 제한은 Codex가 OpenAI에서 하는 방식과 비슷하며, 왜 Claude보다 Codex로 더 많은 일을 할 수 있다고 느끼는지에 대한 이유이기도 합니다(더 나은 자동 압축). 작업 부하가 100만 토큰의 이점을 누린다는 확신이 있을 때만 전체 제한을 유지하세요(저는 모든 모델을 300k로 낮췄습니다. 네, 각 모델마다 설정해야 합니다).

좋은 무료 도구가 있나요, 아니면 전부 유료 플랜인가요?

Paseo(https://paseo.sh, Apache 2.0; 제휴 아님) + GitHub Codespaces를 추천합니다. 멀티 에이전트 확장에는 팀과 호스트라는 두 가지 측면이 있습니다. 로컬 호스트에서 팀을 실행하는 것부터 시작하세요. 그런 다음 SSH를 통해 가지고 있는 다른 물리적 머신이나 Codespaces로 확장하세요. Codespaces는 매달 160 코어 시간의 크레딧을 제공합니다. Paseo가 미리 구성된 이미지를 설정하고 작업을 분산할 수 있습니다(또는 장기 실행 Codespace를 설정하고 수동으로 구성할 수도 있습니다). 두 번째 호스트를 완전히 활용하게 된다면 더 쉽게 추가하고 다른 서버리스 인프라로 이동하는 것을 고려할 수 있습니다.

제가 계속 겪는 실패는 플래너가 작업을 잘못 분할하는 게 아니라, 두 작업자가 같은 가변적인 대상을 소유하고 있다고 믿는 것입니다. 레포, 브라우저 프로필, 스테이징 데이터베이스, Slack 스레드 같은 것들이요. 플래너는 작업을 순수 함수인 것처럼 추론하지만, 결국 둘 다 같은 파일을 작성하게 되고 어떤 재프롬프팅으로도 해결되지 않는 충돌이 발생합니다.

멀티 에이전트가 가치 있게 느껴졌던 점은 분할 방식을 작업 중심이 아니라 리소스 중심으로 바꾼 것입니다: 레포당 작성자 한 명, 브라우저 프로필당 에이전트 한 명, 외부 계정당 소유자 한 명. 이렇게 하면 작업이 진정으로 독립적인 곳(읽기, 조사, 초안 작성)에서 병렬 처리가 일어나고 쓰기 작업은 직렬화됩니다. 속도 향상은 실재하지만, 그것은 에이전트가 많아서가 아니라 독립적인 절반의 작업에서 오는 것입니다.

아무도 예산에 넣지 않는 비용: 모든 작업자는 컨텍스트의 자체 복사본이 필요하므로, 에이전트 3명은 브리핑 내용을 이해하기 위해 대략 3배의 토큰을 태웁니다. 작업이 병렬 읽기로 깔끔하게 분할되지 않는다면, 좋은 계획을 가진 에이전트 하나가 더 저렴하고 낫습니다.

저는 속도를 높일 이유가 없어서 그냥 에이전트 하나만 씁니다.