멀티 에이전트와 컨텍스트 격리

협업은 전체 공유가 아니다

한 에이전트가 도구를 잘 쓰게 되면 다음 질문은 자연스럽다. 여러 에이전트를 붙이면 더 똑똑해질까. 답은 조건부다. 역할이 분리되고, 전달되는 정보가 정리되어 있고, 공유 상태가 안정적으로 관리될 때는 좋아진다. 반대로 모든 에이전트가 같은 대화 기록, 같은 도구, 같은 메모리, 같은 권한을 보면 시스템은 쉽게 흔들린다.

멀티 에이전트 시스템에서 흔한 실패는 단체 채팅방처럼 설계하는 것이다. 기획 에이전트, 검색 에이전트, 실행 에이전트, 검증 에이전트가 모두 같은 원시 대화를 읽고 자유롭게 말한다. 처음에는 활발한 협업처럼 보인다. 하지만 곧 문제가 생긴다. 누가 최종 결정을 했는지 불분명해진다. 중간 가설이 확정 사실처럼 전달된다. 한 에이전트의 임시 추론이 다른 에이전트의 입력을 오염시킨다. 같은 상태를 여러 에이전트가 동시에 고쳐 결과가 덮어써진다.

따라서 멀티 에이전트의 핵심은 더 많이 공유하는 것이 아니다. 공유해야 할 것과 숨겨야 할 것을 구분하는 것이다. 좋은 협업은 전체 공개가 아니라 정해진 인터페이스를 통한 전달에서 나온다.

역할이 다르면 컨텍스트도 달라야 한다

각 에이전트는 서로 다른 일을 맡는다. 일을 다르게 맡는다면 보는 정보도 달라야 한다. 모든 에이전트에게 동일한 시스템 지시, 동일한 도구 목록, 동일한 메모리를 주면 역할 분리는 이름뿐이 된다.

예를 들어 고객 지원 업무를 생각해 보자.

이 분리는 전문성을 높인다. 검색 에이전트는 좋은 근거를 찾는 데 집중하고, 실행 에이전트는 안전한 변경에 집중한다. 검증 에이전트는 이전 에이전트의 의도를 맞춰 주는 역할이 아니라, 결과가 조건을 만족하는지 독립적으로 확인하는 역할을 맡는다.

권한도 역할별로 달라야 한다. 읽기만 필요한 에이전트에게 쓰기 도구를 줄 이유가 없다. 검증 에이전트에게 결제 취소 권한을 줄 필요도 없다. 도구 권한을 줄이는 것은 보안을 위한 조치이면서 동시에 컨텍스트 품질을 높이는 조치다. 모델이 할 수 없는 행동은 고민하지 않게 되기 때문이다.

메모리 역시 분리해야 한다. 사용자 선호를 기억하는 메모리, 프로젝트 진행 상태를 기억하는 메모리, 운영 로그를 보관하는 저장소는 목적이 다르다. 특정 에이전트가 만든 임시 가설은 장기 메모리에 들어가면 안 된다. 확정된 사실, 승인된 결정, 재사용 가능한 규칙만 공유 메모리로 승격해야 한다.

전달 단위는 원시 대화가 아니라 산출물이다

에이전트 사이에 정보를 넘길 때 가장 쉬운 방법은 이전 대화를 통째로 붙이는 것이다. 하지만 쉬운 방법이 좋은 방법은 아니다. 원시 대화에는 질문, 중간 추론, 잘못된 시도, 취소된 조건, 감정적 표현, 불필요한 반복이 섞여 있다. 다음 에이전트는 이 모든 것을 다시 해석해야 한다. 그 과정에서 중요하지 않은 말이 중요해지고, 임시 판단이 확정 사실처럼 보일 수 있다.

멀티 에이전트에서는 원시 대화 대신 구조화된 산출물을 전달해야 한다. 산출물은 다음 에이전트가 바로 사용할 수 있는 형태여야 한다.

예를 들면 다음과 같다.

artifact_type: customer_issue_summary
created_by: support_triage_agent
status: verified
user_request: 배송 예정일 확인 및 지연 시 보상 가능 여부 문의
entities:
  customer_id: C12345
  order_id: O99881
  product_id: P771
facts:
  - 주문은 2026-05-18에 결제 완료됨
  - 현재 배송 상태는 출고 준비 중임
  - 약속 배송일은 2026-05-22임
open_questions:
  - 실제 지연 여부는 배송사 조회가 필요함
next_recommended_agent: shipping_lookup_agent
source_refs:
  - conversation_turn: 14
  - order_record: O99881

이런 산출물에는 몇 가지 장점이 있다. 첫째, 무엇이 사실이고 무엇이 아직 질문인지 구분된다. 둘째, 엔티티 ID가 명확해 도구 호출 오류가 줄어든다. 셋째, 출처 참조가 남아 나중에 검증할 수 있다. 넷째, 다음 에이전트가 불필요한 대화 전체를 읽지 않아도 된다.

검색 기반 시스템에서는 문서 원문보다 검색 결과 요약, 문서 ID, 인용 위치, 그래프 경로가 더 좋은 전달 단위가 될 수 있다. 예를 들어 GraphRAG 방식의 탐색 결과라면 단순 문단 모음보다 고객 → 주문 → 배송 이벤트 → 보상 정책처럼 연결 경로를 넘기는 편이 낫다. 그래야 다음 에이전트가 왜 그 근거가 선택되었는지 이해할 수 있다.

핵심은 명확하다. 에이전트 사이의 메시지는 대화가 아니라 계약이어야 한다. 입력과 출력의 형식, 검증 여부, 신뢰도, 출처, 다음 행동 후보가 포함되어야 한다.

병렬 읽기와 단일 쓰기로 충돌을 막는다

멀티 에이전트는 병렬 처리와 잘 어울린다. 한 에이전트는 정책을 찾고, 다른 에이전트는 주문 상태를 조회하고, 또 다른 에이전트는 과거 상담 이력을 요약할 수 있다. 문제는 읽기가 아니라 쓰기에서 생긴다.

여러 에이전트가 같은 상태를 동시에 수정하면 충돌이 발생한다. 한 에이전트는 배송 상태를 지연 가능성 있음으로 바꾸고, 다른 에이전트는 예전 정보를 근거로 정상 배송으로 바꿀 수 있다. 둘 다 각자의 관점에서는 맞지만, 최종 상태는 엉망이 된다.

실무에서는 병렬 읽기, 단일 쓰기 패턴이 안전하다. 여러 에이전트는 같은 상태 스냅샷을 읽고 각자의 제안을 만든다. 하지만 공유 상태에 최종 반영하는 권한은 하나의 오케스트레이터나 상태 관리자에게만 둔다.

흐름은 단순하다.

1. 상태 관리자가 현재 스냅샷과 버전 번호를 만든다.

2. 여러 에이전트가 같은 스냅샷을 읽고 병렬로 작업한다.

3. 각 에이전트는 상태를 직접 수정하지 않고 변경 제안을 제출한다.

4. 상태 관리자가 제안을 검증하고 충돌을 해결한다.

5. 승인된 변경만 새 버전으로 커밋한다.

변경 제안은 다음처럼 작게 만들 수 있다.

patch_type: state_update_proposal
base_state_version: 27
proposed_by: shipping_lookup_agent
updates:
  shipment.status: delayed_risk
  shipment.latest_event_id: E5521
evidence:
  - carrier_event: E5521
confidence: 0.82
requires_review: false

여기서 중요한 값은 base_state_version이다. 에이전트가 어떤 상태를 기준으로 판단했는지 알아야 한다. 그 사이 상태가 바뀌었다면 바로 반영하지 않고 다시 계산하게 할 수 있다. 데이터베이스의 동시성 제어와 비슷하다. AI 시스템도 결국 상태를 다루는 소프트웨어다.

쓰기 작업에는 책임자가 필요하다. 모든 에이전트가 말할 수는 있지만, 모두가 기록할 수 있어서는 안 된다. 공유 상태는 회의록이 아니라 운영 데이터다.

서브에이전트는 탐색을 격리하는 장치다

서브에이전트는 큰 작업을 작은 작업으로 나누는 데 유용하다. 하지만 더 중요한 역할은 컨텍스트 격리다. 상위 에이전트가 모든 탐색 과정을 직접 품고 있으면 컨텍스트가 빠르게 오염된다. 검색 실패, 틀린 가설, 중복 실험, 긴 도구 로그가 모두 상위 컨텍스트에 쌓인다.

좋은 구조에서는 상위 에이전트가 서브에이전트에게 제한된 목표와 입력만 준다. 서브에이전트는 자기 작업 공간에서 검색하고, 코드를 실행하고, 문서를 읽고, 여러 번 실패해도 된다. 그 과정은 샌드박스에 남긴다. 상위 에이전트에게는 최종 요약, 검증된 결과, 남은 불확실성, 참조만 돌려준다.

이 방식을 컨텍스트 폴딩이라고 볼 수 있다. 긴 중간 과정을 접어서 짧은 의미 단위로 바꾸는 것이다. 접힌 결과에는 적어도 다음 정보가 있어야 한다.

• 수행한 작업의 목적

• 확인된 사실

• 버린 가설과 그 이유

• 아직 불확실한 부분

• 사용한 도구와 원본 참조

• 다음 에이전트가 해야 할 일

예를 들어 리서치 서브에이전트가 30개의 문서를 읽었다고 해서 그 문서 요약 전체를 상위 에이전트에 넘길 필요는 없다. 상위 에이전트가 필요한 것은 대개 결론, 핵심 근거 3개, 충돌하는 근거, 원문 참조다. 원본은 샌드박스나 저장소에 남기고 필요할 때 다시 열면 된다.

샌드박스는 안전에도 중요하다. 코드 실행, 파일 생성, 대량 검색, 외부 API 호출처럼 소음이 많은 작업은 격리된 공간에서 처리해야 한다. 실패한 실험이 공유 메모리에 들어가지 않게 하고, 임시 파일이 최종 산출물처럼 보이지 않게 해야 한다.

오케스트레이터는 판단자가 아니라 교통정리자다

멀티 에이전트 시스템에는 보통 오케스트레이터가 필요하다. 오케스트레이터는 모든 일을 직접 해결하는 에이전트가 아니다. 어떤 에이전트에게 어떤 일을 맡길지 정하고, 입력을 줄이고, 산출물을 검증하고, 상태 반영 순서를 관리하는 역할이다.

오케스트레이터가 강해질수록 개별 에이전트는 단순해질 수 있다. 검색 에이전트는 검색을 잘하면 된다. 실행 에이전트는 안전하게 실행하면 된다. 검증 에이전트는 기준에 맞춰 확인하면 된다. 복잡도는 역할 내부가 아니라 역할 사이의 계약에서 관리한다.

오케스트레이터가 특히 신경 써야 할 질문은 네 가지다.

1. 이 에이전트가 이 정보를 볼 필요가 있는가.

2. 이 에이전트가 이 도구를 사용할 권한이 있는가.

3. 이 산출물은 검증되었는가, 아니면 가설인가.

4. 이 변경을 지금 공유 상태에 반영해도 되는가.

이 질문에 답하지 못하면 멀티 에이전트는 빠르게 복잡해진다. 에이전트 수가 늘어날수록 지능이 늘어나는 것이 아니라 조정 비용이 늘어난다.

설계 체크리스트

멀티 에이전트 컨텍스트를 설계할 때는 다음 원칙을 기준으로 삼으면 된다.

1. 에이전트별 역할, 시스템 지시, 도구, 메모리, 권한을 분리한다.

2. 모든 에이전트에게 전체 대화 기록을 주지 않는다.

3. 원시 로그 대신 검증된 요약, 엔티티 ID, 문서 ID, 그래프 경로를 전달한다.

4. 산출물에는 작성자, 상태, 신뢰도, 출처, 다음 행동 후보를 포함한다.

5. 병렬 처리는 읽기 중심으로 설계하고, 공유 상태 쓰기는 단일 책임자에게 맡긴다.

6. 상태에는 버전 번호를 두고, 오래된 스냅샷 기반 변경은 재검토한다.

7. 서브에이전트의 중간 탐색 과정은 샌드박스에 격리한다.

8. 상위 에이전트에는 접힌 요약과 원본 참조만 돌려준다.

9. 임시 가설은 장기 메모리에 저장하지 않는다.

10. 검증된 사실만 공유 상태로 승격한다.

멀티 에이전트 시스템의 목표는 많은 모델을 한 방에 넣는 것이 아니다. 각 에이전트가 자기 역할에 필요한 만큼만 보고, 안전하게 말하고, 정해진 방식으로 상태를 넘기게 만드는 것이다. 모든 것을 공유하면 협업이 아니라 혼란이 생긴다. 좋은 컨텍스트 격리는 에이전트를 고립시키는 것이 아니라, 협업이 가능한 형태로 연결하는 기술이다.