AI 에이전트 얘기 가 나오면 요즘 꼭 따라붙는 말 이 멀티 에이전트(multi-agent) 다. 한 줄 로 정의 하면:

에이전트 하나 가 모든 걸 하는 게 아니라, 여러 에이전트 가 역할 을 나눠 협업 하는 구조. 오케스트레이터(지휘자) 가 일 을 쪼개 서브에이전트 들 에게 나눠주고, 결과 를 모아 판단 한다.

그런데 “여러 개 면 무조건 좋다” 는 아니다. 왜 나누는지, 언제 나누면 안 되는지 까지 봐야 진짜 이해 다.

1. 출발점 — 싱글 에이전트 의 물리적 한계

싱글 에이전트 는 계획 → 코딩 → 검증 → 배포 를 하나 의 컨텍스트 안 에서 다 한다. 문제 는 그 컨텍스트 가 유한 하다는 것.

  • 10만 줄 코드베이스 를 통째 로 읽을 수 없다
  • 긴 작업 일수록 앞 에서 읽은 내용 이 뒤 에서 밀려난다
  • 탐색 하며 읽은 파일 덤프 가 정작 판단 에 쓸 자리 를 잡아먹는다

즉 멀티 에이전트 의 일차 동기 는 화려함 이 아니라 메모리 관리 다. 사람 팀 이 분업 하는 이유 와 같다 — 한 사람 의 머리 에 다 안 들어가니까.

2. 나누는 세 가지 이유

① 컨텍스트 격리. 각 에이전트 는 자기 일 에 필요한 것 만 본다. 검색 담당 5개 가 코드베이스 를 나눠 훑고 결론 만 보고 하면, 지휘자 는 파일 덤프 없이 판단 만 하면 된다. 판단 하는 자리 를 깨끗 하게 유지 하는 것 — 이게 절반 이다.

② 병렬. 리뷰어 5명 이 동시에 다른 관점(버그 · 보안 · 성능 · 재현성) 으로 본다. 순차 로 5번 도는 것 보다 벽시계 시간 이 짧고, 관점 이 다양 해서 한 명 이 놓치는 걸 잡는다.

③ maker / checker 분리. 만든 에이전트 가 자기 결과물 을 채점 하면 후 하다. 그래서 검증 은 별도 에이전트 가 한다 — 심지어 “반박 해 보라(adversarial)” 고 시킨다. loop engineering 글 에서 나온 “두 번째 서브에이전트 가 검증 하고”, /goal 의 완료 판정 을 작업 한 모델 이 아닌 별도 모델 이 하는 것 — 전부 이 원칙 이다. 오래된 엔지니어링 격언 의 AI 버전: 만든 자 가 채점 하지 않는다.

3. 흔한 패턴 세 가지

패턴 구조 언제
오케스트레이터-워커 1명 이 쪼개고 N명 이 실행, 결과 취합 큰 작업 의 분할 정복 (마이그레이션 · 대규모 검색)
파이프라인 조사 → 작성 → 검증 → 종합 릴레이 단계 마다 필요한 능력 이 다를 때
심판 패널 같은 문제 를 N명 이 독립 으로 풀고 투표·채점 정답 이 불확실 · 관점 다양성 이 중요 할 때 (리뷰 · 설계 비교)

셋 은 배타 가 아니라 조합 이다 — 예: 워커 들 이 찾은 버그 후보 를 심판 패널 이 “진짜냐” 투표 로 거르는 식.

4. loop engineering 과 의 관계 — 루프 의 각 층 에 에이전트 가 들어간다

전 글 의 4중 루프 와 겹쳐 보면 구도 가 선명 해진다:

  • agent loop(안쪽) — 워커 에이전트 가 도는 곳
  • verification loop — checker 에이전트 가 도는 곳 (maker/checker 분리)
  • event-driven loop — 오케스트레이터 를 깨우는 트리거
  • hill-climbing loop — 지난 실행 기록 을 읽어 다음 판 의 에이전트 들 을 개선

즉 loop engineering 이 시간 축 의 설계 라면, 멀티 에이전트 는 공간 축(역할 분담) 의 설계 다. 실전 시스템 은 둘 을 같이 쓴다.

5. 공짜 가 아니다 — 언제 싱글 이 낫나

멀티 에이전트 도 기술 도입비용 의 저울 위 에 있다:

  • 토큰 비용 ×N. 에이전트 마다 컨텍스트 를 새로 채우니, 5명 이면 대략 5배 를 태운다. 간단 한 질문 에 패널 을 소집 하는 건 파리 잡는 대포.
  • 조율 오버헤드. 쪼개고 · 넘기고 · 취합 하는 비용 이 있다. 작업 이 강하게 순차적 이면(앞 결과 없인 뒤 를 못 함) 병렬 의 이득 이 없다.
  • 전달 손실. 에이전트 간 에는 요약 만 오간다. 맥락 이 중요한 미묘 한 작업 은 요약 을 거치며 뭉개질 수 있다.

경험칙: 한 컨텍스트 에 들어가고 순차적 인 일 은 싱글, 넓고(탐색) · 병렬 가능 하고(리뷰) · 검증 이 중요한(배포 전 게이트) 일 은 멀티.

6. 사실 내 홈랩 이 이미 멀티 에이전트 로 돈다

추상론 이 아니라 매일 쓰는 방식 이다:

  • 탐색 위임 — 코드베이스 전체 를 훑어야 하는 질문 은 검색 전용 에이전트(Explore) 에게 던지고, 지휘 세션 은 결론 만 받는다 (컨텍스트 격리)
  • 전문 checker — settlement 의 아키텍처 경계 는 ArchUnit 검증 전용 에이전트 가, 신학 콘텐츠 는 리뷰 전용 에이전트 가 게이트 한다 (maker/checker)
  • 파이프라인 검증 — 코드 는 사람+AI 가 만들고, 배포 후 검증 은 운영 도메인 E2E 가 한다 (AX 시대 의 백엔드 와 DevOps 의 “신뢰 는 파이프라인” 이 정확히 이 자리)

마무리 — 한 줄 정의

멀티 에이전트 = “한 명 의 만능” 대신 쪼개고(컨텍스트 격리) · 동시에(병렬) · 서로 검증(견제) 하며 일 하는 AI 팀 구조.

사람 조직 이 수백 년 걸려 배운 것 — 분업, 병렬, 그리고 만든 자 가 채점 하지 않는다 — 를 AI 팀 에 다시 적용 하는 것 뿐 이다. 새로운 건 팀원 이 사람 이 아니라는 것, 그리고 그 팀 을 코드(루프) 로 설계 할 수 있다는 것 이다.