멀티 에이전트 오케스트레이션 완전 정리: 지속형 팀원·요청 응답 규약·작업 보드·깃 워크트리

핵심 메시지

• 터미널 여러 개를 같은 저장소에 붙여 놓는 방식은 파일 충돌, 경쟁 상태, 중복 작업, 통신 교착이라는 네 가지 실패로 이어진다. 모델 성능이 아니라 조율 구조가 차이를 만든다.
• 하위 에이전트를 일회용 작업자가 아니라 이름과 메일함을 가진 지속형 팀원으로 다루면, 리드 에이전트의 맥락이 세부 실행으로 오염되지 않고 팀원의 상태도 맥락 압축에서 살아남는다.
• 모든 메시지를 ID·유형·본문·상관 ID 네 필드로 구조화하면 스무 개의 메시지가 뒤섞여도 어떤 요청에 대한 답인지 추적된다. HTTP와 gRPC가 쓰는 것과 같은 요청-응답 패턴이다.
• 리드가 작업을 배정하는 대신 에이전트가 공유 작업 보드를 훑고 스스로 선점하게 하면 병목이 사라진다. 선점은 원자적 쓰기라 두 에이전트가 동시에 집으면 하나만 성공한다.
• 작업마다 별도의 깃 워크트리를 주면 실행 중 충돌이 병합 시점으로 옮겨간다. 다만 노트북 환경에서는 동시 5~7개가 생산성의 상한이라는 것이 발표자의 실측이다.

쉽게 이해하기

코딩 에이전트를 여러 개 동시에 돌리는 시도는 흔해졌지만, 대부분은 터미널 다섯 개를 열어 같은 저장소를 가리키게 하는 데서 시작한다. 영상은 그 방식이 예측 가능한 방식으로 무너진다고 지적한다. 한 에이전트가 방금 끝낸 파일을 다른 에이전트가 덮어쓰고, 커밋되지 않은 변경 위에서 테스트가 돌고, 두 에이전트가 같은 작업을 서로 모른 채 붙잡는다. 발표자는 이 네 가지 실패가 모두 해결 가능하며, 각각에 대응하는 장치가 하나씩 있다고 설명한다.

첫 번째 장치는 팀원 개념이다. 하위 에이전트를 호출하면 실행하고 사라지는 일회용 작업자로 보면 단발성 작업에는 문제가 없지만, 시간을 두고 협업해야 하는 순간 무너진다. 대신 각 에이전트에 안정적인 이름과 순서대로 처리되는 메일함을 주고, 리드 에이전트가 직접 하위 작업을 실행하는 대신 해당 메일함에 메시지를 보내게 한다. 이렇게 하면 리드의 맥락이 실행 세부로 채워지지 않고, 리드가 맥락을 압축하더라도 팀원들은 자기 상태를 잃지 않는다.

두 번째는 공통 통신 규약이다. 규약이 없으면 에이전트끼리 '최신 버전으로 했다', '어느 최신 버전이냐'를 주고받다 서로를 기다리며 멈춘다. 영상이 제시하는 해법은 모든 메시지를 고유 ID, 요청인지 응답인지를 나타내는 유형, 실제 내용, 그리고 응답일 경우 어떤 요청에 대한 답인지 가리키는 상관 ID로 구성하는 것이다. 단순해 보이지만 이 규약 위에 스트리밍이나 재시도, 타임아웃 같은 동작을 얹을 수 있다는 점이 핵심이다.

세 번째는 작업 배정 방식의 전환이다. 팀원과 규약이 갖춰져도 모든 작업이 리드 한 명을 거치면 그 자체가 병목이 된다. 대신 대기 상태의 에이전트가 몇 초마다 공유 작업 보드를 훑고, 자기 역량에 맞는 열린 작업을 발견하면 원자적 쓰기로 선점하게 한다. 동시에 두 에이전트가 같은 작업을 집으면 한쪽만 성공하고 다른 쪽은 파일을 다시 읽어 다음 작업으로 넘어간다. 리드는 작업을 배정하는 사람이 아니라 작업을 쪼개 보드에 적는 사람이 된다.

마지막은 디렉터리 격리다. 다섯 에이전트가 같은 작업 디렉터리에 쓰면 깃 잠금 경합과 덮어쓰기가 계속 생기므로, 작업마다 자기 브랜치를 가리키는 별도 워크트리를 준다. 저장소 이력은 공유하되 작업 디렉터리는 나누는 방식이며, 작업 ID와 워크트리 경로에 같은 식별자를 써서 에이전트가 자기 위치를 항상 알게 한다. 충돌은 사라지는 것이 아니라 표준 깃 도구가 감지할 수 있는 병합 시점으로 옮겨간다.

주요 인사이트

• 멀티 에이전트의 성패를 가르는 것은 모델이 아니라 조율 계층의 설계다. 같은 모델을 쓰더라도 팀원·규약·보드·워크트리가 있느냐 없느냐에 따라 결과가 갈린다는 것이 영상의 일관된 주장이다.
• 지속형 정체성과 지속형 지식은 다른 문제다. 이름과 메일함이 있어도 세션이 바뀌면 팀원은 백지에서 시작하므로, 무엇을 했고 무엇이 남았는지를 담은 인수인계 산출물을 작업마다 만들어 둬야 다음 에이전트가 헤매지 않는다.
• 병렬화는 비용을 그대로 곱한다. 각각 20만 토큰을 쓰는 에이전트 다섯이 동시에 돌면 API 사용 한도에 빠르게 닿기 때문에, 확장 전에 예산부터 정하라는 조언이 붙는다.
• 워크트리 격리는 실행 중 쓰기 충돌만 막아 준다. 다섯 개의 분기가 공용 유틸리티를 각자 고쳤다면 병합 검토 부담은 그대로 남으며, 워크트리마다 작업 디렉터리를 복제하므로 디스크도 함께 소모된다.
• 요청-응답에 상관 ID를 붙이는 방식은 새로운 발명이 아니라 웹과 분산 시스템이 오래 써 온 패턴이다. 에이전트 조율 문제의 상당 부분이 이미 검증된 분산 시스템 설계로 환원된다는 점이 시사적이다.

자주 묻는 질문

관련 AI 소식