에이전트를 하나 쓰는 것과 여럿을 함께 쓰는 것은 복잡도의 차이가 아니다. 설계 철학 자체가 달라진다. 단일 에이전트 워크플로우에서는 '이 에이전트가 무엇을 잘 하는가'를 묻지만, 멀티 에이전트 환경에서는 '에이전트들이 어떻게 협력하고, 어디서 어떻게 실패하는가'를 먼저 물어야 한다. 최근 등장한 세 가지 접근—Chorus의 크로스 에이전트 위임, Qualixar OS의 오케스트레이션 런타임, 그리고 프로덕션 에러 핸들링 패턴—은 각각 다른 각도에서 같은 질문을 던진다.
모델 불일치를 버그가 아니라 신호로 쓰기
Chorus는 Claude Code, OpenCode, Gemini CLI, Codex를 4×3 메시로 연결하는 오픈소스 플러그인 컬렉션이다. 핵심 아이디어는 단순하다. 지금 쓰고 있는 CLI에서 다른 에이전트에게 직접 태스크를 위임하는 것. claude 에서 /gemini:review를 실행하거나 /codex:run으로 회귀 테스트를 요청하는 식이다.
흥미로운 지점은 이걸 '협업'이 아니라 '모델 불일치를 도구로 쓴다'고 정의한다는 것이다. 세 에이전트에게 같은 diff를 독립적으로 리뷰시키면 각자 다른 실패 모드를 드러낸다. 한 에이전트는 아키텍처에 과도하게 집착하고, 다른 하나는 테스트 커버리지 구멍을 잡아내고, 또 다른 하나는 더 단순한 구현을 제안한다. 셋 중 하나는 틀릴 수 있다. 그것도 괜찮다. 여러 독립적인 패스를 통해 단일 에이전트의 블라인드 스팟을 드러내는 것이 목표이기 때문이다. Chorus의 설계 철학이 '새로운 AI IDE가 되지 않겠다'고 명시한 것도 중요하다. 기존 인터페이스를 바꾸지 않고 에이전트 간 격벽만 제거하는 글루(glue) 레이어로 스스로를 정의한다.
태스크를 주면 팀을 설계해주는 런타임
Qualixar OS는 한 레이어 위에서 작동한다. 자연어로 태스크를 입력하면 Forge AI가 에이전트 팀 구성, 토폴로지 선택, 실행, 평가까지 자동으로 처리한다. 25개의 MCP 툴로 노출되어 있어 Claude Code에서 직접 호출할 수 있다.
여기서 주목할 개념은 '토폴로지'다. Qualixar OS는 13가지 실행 토폴로지를 지원한다. 순서가 중요한 파이프라인엔 sequential, 독립적인 분석을 병렬로 돌릴 땐 parallel, 두 에이전트가 서로 논쟁하고 판사 에이전트가 결론을 내리는 debate, 복잡한 태스크를 하위 태스크로 분해하는 hierarchical. 인증 모듈 보안 리뷰를 요청하면 Forge가 자동으로 Security Analyst, Code Quality Reviewer, Test Coverage Auditor 세 역할을 설계하고 debate 토폴로지를 선택하는 식이다. 개발자가 토폴로지에 동의하지 않으면 명시적으로 오버라이드할 수 있다.
적대적 판사 파이프라인도 눈에 띈다. 실행이 끝나면 judge 에이전트가 정확성, 완결성, 명확성 기준으로 결과를 평가하고, 기준을 통과하지 못하면 자동으로 팀을 재설계해 재실행한다. 최대 5라운드, 예산 3배 캡이 안전장치다. '에이전트가 좋은 답을 냈는가'를 또 다른 에이전트가 검증하는 구조 자체가 멀티 에이전트 설계의 핵심 패턴이다.
에이전트가 늘어나면 실패도 늘어난다—그래서 에러 핸들링이 아키텍처다
멀티 에이전트 환경에서 가장 과소평가되는 것이 에러 핸들링이다. 에이전트를 하나 추가할 때마다 실패 지점이 하나씩 더 생긴다. 레이트 리밋, 타임아웃, 말형성 응답, 컨텍스트 오버플로우—프로덕션에서 이것들이 동시에 발생하면 단일 에이전트 장애가 아니라 연쇄 장애가 된다.
실무에서 효과가 검증된 패턴은 네 겹의 레이어로 정리된다. 첫째, 에러 분류. 재시도가 의미 있는 일시적 에러(429, 타임아웃, 네트워크 블립)와 재시도해도 소용없는 영구적 에러(잘못된 API 키, 컨텍스트 초과)를 먼저 분리한다. 이 분류가 나머지 모든 전략의 전제다. 둘째, 지터를 포함한 지수 백오프. 즉시 재시도와 무한 재시도는 레이트 리밋을 밴으로 바꾼다. 재시도 횟수는 3회로 캡핑하는 것이 실용적이다. 셋째, 서킷 브레이커. LLM 프로바이더 전체가 장애 상태일 때 요청이 쌓이는 것을 막는다. 서킷이 열리면 캐시 응답이나 단순 로직으로 폴백한다. 서킷 상태 전환은 장애의 조기 신호로도 활용된다. 넷째, 폴백 체인. claude-sonnet → gpt-4o-mini → cached_response 순서로 내려가면서 전체 장애를 막는다. 사용자는 성능이 낮아지더라도 응답을 받을 수 있다.
설계 판단: 언제 무엇을 선택할 것인가
세 접근을 놓고 보면 멀티 에이전트 도입의 스펙트럼이 보인다. Chorus는 기존 워크플로우를 바꾸지 않으면서 에이전트 간 격벽을 제거하려는 팀에 맞다. 도구 전환 비용은 낮지만, 에이전트 간 조율은 여전히 개발자 손에 달려 있다. Qualixar OS는 태스크 정의만 하면 팀 설계와 품질 평가까지 위임하고 싶을 때 유효하다. 대신 오케스트레이션 레이어 자체에 대한 신뢰와 비용 가시성 관리가 선행되어야 한다.
에러 핸들링 패턴은 어떤 조합을 선택하든 공통으로 깔아야 하는 기반이다. 에이전트가 많아질수록 '행복 경로'만 보여주는 데모와 프로덕션 사이의 거리는 기하급수적으로 벌어진다. 서킷 브레이커와 폴백 체인은 새로운 개념이 아니다. 분산 시스템에서 수십 년간 검증된 패턴이다. 다만 AI 에이전트에 적용할 때는 실패가 확률적이고, 응답이 비결정적이며, 재시도마다 비용이 누적된다는 점이 다르다.
지금 당장 적용할 수 있는 출발점
멀티 에이전트를 처음 도입한다면 순서가 있다. 먼저 에러 분류 레이어를 만든다. 어떤 실패가 일시적이고 어떤 실패가 영구적인지 코드로 정의하는 것이 전부다. 다음으로 Chorus처럼 낮은 비용으로 멀티 에이전트 리뷰를 실험한다. 리스크가 높은 변경 사항에 두 번째 에이전트의 의견을 구하는 것만으로도 블라인드 스팟을 줄일 수 있다. 오케스트레이션 자동화는 단일 에이전트의 한계가 명확히 보일 때 도입한다. 복잡도를 먼저 이해하지 않은 채 레이어를 추가하면 디버깅할 수 없는 시스템이 된다.
멀티 에이전트는 더 많은 에이전트를 추가하는 전략이 아니다. 각 에이전트가 어디서 실패하는지 이해하고, 그 실패를 시스템 수준에서 흡수하는 설계를 먼저 갖추는 전략이다. 에이전트를 늘리기 전에 무너질 곳을 먼저 설계하는 것—그게 멀티 에이전트 워크플로우의 실제 진입 조건이다.