샘 데이비도프(Sam Davidoff)는 회사 해커톤과 오픈소스 프로젝트에서 여러 AI 에이전트를 함께 활용한 경험을 전한다. 조율자 에이전트를 두면 개발자가 기다리는 시간을 줄일 수 있지만, 토큰 사용량이 늘고 작업 내용을 파악하기 어려워질 수 있다고 관찰했다.

데이비도프와 동료들은 다른 에이전트를 관리하는 조율자 에이전트를 중심에 두는 방식을 자연스럽게 채택했다. 조율자는 채팅 서버와 작업 채널, 규칙을 설정하고 다른 에이전트가 작업을 이어가도록 했다. 조율자에게 직접 작업을 맡기지 않고 조정과 대화만 담당하게 하면, 긴 작업이 진행되는 동안에도 개발자와 소통할 수 있었다.

에이전트가 늘면 토큰 사용량도 증가했다. 특히 MCP 도구를 호출할 때마다 대화의 한 차례가 추가되면서 맥락을 다시 전송해야 한다는 점이 두드러졌다. 캐시가 비용을 줄일 수는 있지만 문제를 없애지는 못한다고 데이비도프는 설명했다. MCP에는 푸시 기능이 없어 에이전트들이 채팅 서버를 짧은 간격으로 반복 확인했고, 새 소식이 없어도 토큰을 소모했다.

에이전트들은 이 문제를 해결하려고 채팅 변경을 확인하는 백그라운드 스크립트를 활용했다. 새 알림이 있을 때만 에이전트에 확인을 요청해 불필요한 호출을 줄이는 방식이다. 또 tmux 세션 안에서 다른 에이전트를 시작·중지하거나, 세션에 텍스트를 입력해 대기 중인 에이전트를 깨우는 방법도 찾아냈다. 데이비도프는 이런 방식이 모두 안전한지는 확신하지 못한다며 주의를 당부했다.

그의 관찰에 따르면 에이전트들은 복잡한 사전 규칙이나 역할을 많이 정해주지 않아도 의사소통 방법을 찾아냈다. 따라서 데이비도프는 에이전트가 스스로 어떻게 행동하는지 먼저 살펴본 뒤, 정해진 도구와 제약을 추가하는 편이 낫다고 제안했다. 다만 에이전트가 늘면서 사람이 어떤 작업이 진행 중인지 놓치는 혼란도 생겼고, 관심받지 않는 문제에 시간을 들여 정교한 해결책을 만드는 경우도 있었다. 개발자들이 계획 세부 사항을 덜 파악하게 될 수 있다는 점도 우려했다.

해커톤에서는 다른 에이전트와 끝없이 대화하거나 서로의 코드를 검토하는 문제를 거의 보지 못했다. 에이전트들이 개성을 드러내지도 않았으며, 경험은 일화적이어서 다른 환경에도 그대로 적용된다고 단정할 수는 없다. 데이비도프와 동료들은 전반적으로 경험을 긍정적으로 평가했으며, 개발팀이 조율형 에이전트 없이 일하기 어려울 것이라고 봤다.

데이비도프가 만든 채팅 MCP 서버는 오픈소스로 공개됐다: kashkeshet. 팀은 주로 Claude Code에서 Opus 5.5 에이전트를, Codex에서 Sol 6.1 에이전트를 사용했다. Muse Code, Antigravity, OpenCode도 이 방식으로 시험했다.