멀티 에이전트 설계할 때 진짜 도움 됐던 글 하나

요즘 팀에서 에이전트 시스템을 설계하고 있어요. 에이전트 하나는 어느 정도 감이 잡혔는데, 여러 개를 엮으려니까 생각보다 고민이 많아지더라고요.

어떤 구조로 조율하지? 통신은? 메모리는 어떻게 관리하지?

그러다 Rohit Ghumare가 쓴 글을 발견했는데, 궁금했던 것들이 거의 다 정리되어 있어서 공유드립니다. 제가 고민한 내용도 함께 적었습니다.

왜 멀티 에이전트인가

이전 포스트에서도 말씀드렸지만 항상 멀티 에이전트가 정답은 아닙니다. 그런데 저는 단일 에이전트의 컨텍스트 관리에 있어서 작년 내내 실패했었어요.

문제는 단일 에이전트의 경우 컨텍스트 윈도우가 금방 차오르고, 이때 쉽게 맥락을 잊습니다. 또한 여러 도메인을 동시에 다루면 판단이 흐려져요.

멀티 에이전트로 이걸 해결할 수 있는데, 대신 조율 과정에서의 오버헤드가 생겨요. 이걸 어떻게 관리하느냐가 핵심이고, 글에서 그 방법을 구체적으로 다뤄요.

세 가지 오케스트레이션 패턴

이 부분이 가장 실용적이었어요. “뭐가 멋있나”가 아니라 “언제 뭘 쓰나” 기준으로 정리되어 있거든요.

수퍼바이저 패턴 (Supervisor)

관리자 에이전트가 작업을 분해하고, 워커에게 분배하고, 결과를 종합하는 구조.

• 적합한 경우: 작업이 서브태스크로 명확히 나뉠 때, 추적이 필요할 때
• 적정 규모: 워커 3~8개
• 주의점: 모든 결정이 수퍼바이저를 거치므로 병목 가능

스웜 패턴 (Swarm)

중앙 관리자 없이 에이전트들이 P2P로 직접 소통하며 자율 조직화.

• 적합한 경우: 여러 관점이 필요하거나 실시간 반응성이 중요할 때
• 주의점: 중복 작업, 무한 루프, 비최적 수렴 위험. 디버깅이 까다로움

계층형 패턴 (Hierarchical)

수퍼바이저 패턴의 재귀 확장. 최상위 → 중간 관리자 → 워커의 다층 구조.

• 적합한 경우: 에이전트 10개 이상, 전략과 전술을 분리해야 할 때
• 주의점: 조율 레이어마다 토큰 비용 급증

개인적으로 작업해보면 수퍼바이저 패턴이 가장 안정적이라고 생각합니다. 다만 워커 분배 과정에서의 효율성과 에러 핸들링이 매우 중요합니다. 안 그러면 관리자 에이전트에서 작업이 터질 수 있습니다.

멀티 에이전트 간 통신 방식

오케스트레이션 패턴이 구조를 정한다면, 통신 방식은 에이전트 간 정보가 실제로 어떻게 흐르는지를 정해요.

• 공유 상태 (Shared State): 모든 에이전트가 하나의 상태 객체를 읽고 씀. 구현 단순하고 디버깅 쉬움. 대부분 여기서 시작하면 충분
• 메시지 패싱 (Message Passing): 이벤트 버스를 통한 비동기 통신. 에이전트 간 결합을 느슨하게 유지해야 할 때
• 핸드오프 (Handoff): 에이전트 간 명시적 바통 터치와 컨텍스트 전달. 순서가 고정된 파이프라인에 적합

멀티 에이전트의 메모리 아키텍처

핵심 문제는 단순해요. 상태를 어떻게 공유하면서도 충돌하지 않게 할 것인가. 글에서는 이걸 세 가지 패턴으로 풀어요.

세션 기반 메모리 (Session-Based)

각 에이전트가 격리된 로컬 상태에서 작업하고, 완료 시 공유 메모리로 병합.

• 적합한 경우: 병렬 워커들이 서로 간섭 없이 독립적으로 작업해야 할 때
• 작동 방식: 세션 시작 시 공유 상태의 스냅샷을 받아서 로컬에서 작업 → 세션 종료 시 변경사항만 머지
• 장점: 워커 간 충돌 없이 병렬 처리 가능

윈도우 메모리 (Window Memory)

슬라이딩 윈도우로 최근 N개의 교환 내용만 유지하고, 오래된 건 요약해서 압축.

• 적합한 경우: 긴 대화에서 컨텍스트를 유지하면서도 토큰을 관리해야 할 때
• 작동 방식: 윈도우 초과 시 가장 오래된 1/3을 요약본으로 압축
• 장점: 무한히 커지는 상태 문제 해결

에피소딕 메모리 (Episodic Memory)

특정 에이전트 조합의 과거 협업 이력과 결과를 저장해서 학습에 활용.

• 적합한 경우: 자주 협업하는 에이전트들이 과거 경험을 바탕으로 개선해야 할 때
• 작동 방식: 어떤 에이전트 조합이 어떤 작업에서 성공/실패했는지 기록
• 장점: “이전에 이 조합이 잘 됐으니 다시 쓰자” 같은 판단 가능

프로덕션 고려사항

토큰 비용

• 수퍼바이저 + 워커 4개 기준: 분해 1K + 워커 12K + 종합 2K = 약 15K 토큰
• 단일 에이전트로 같은 작업하면 4K 정도. 조율 비용이 거의 4배
• 최적화: 수퍼바이저 지시 캐싱, 워커 출력은 구조화 데이터로, 필요할 때만 호출

지연 시간

• LLM 호출당 25초 기준, 에이전트 4개 직렬이면 12초, 병렬이면 34초
• 독립 작업은 무조건 병렬화

에러 전파 방지

• 타임아웃: 모든 계층에 필수
• 서킷 브레이커: N회 실패 시 해당 에이전트 호출 중단
• 그레이스풀 디그레이데이션: 일부 에이전트 없이도 핵심 기능 작동
• 상태 격리: 워커 실패가 공유 상태를 오염시키지 않게

확인할 수 없으면 고칠 수도 없어요. 모니터링은 Day 1부터 필수입니다.

피해야 할 안티 패턴

• 과잉 조율: 독립적으로 돌아도 되는 에이전트를 굳이 엮음
• 만능 에이전트: 하나가 다 하면 멀티 에이전트 의미 없음
• 비용 무시: 토큰 모니터링 없이 배포했다가 청구서 보고 놀람
• 폴백 없음: 모든 에이전트가 항상 작동한다고 가정

결론

글의 결론이 가장 인상 깊었어요.

에이전트 하나 만들고 → 한계 지점 파악하고 → 그 지점에 두 번째 에이전트 붙이고 → 필요하면 수퍼바이저 얹고 → 반복.

저도 처음엔 계층형으로 거창하게 설계했다가, 결국 수퍼바이저 + 워커 3개로 단순화했거든요. 두 개 에이전트가 안정적으로 협업하는 시스템부터 만들어보는 게 맞는 것 같아요.

멀티 에이전트 고민 중이시라면 원본 글 한번 읽어보시길 추천드립니다.

원본: Building Effective Multi-Agent Systems