멀티 에이전트 컨텍스트 관리: LangChain식 하네스를 팀 레포에 넣는 방법

요약: LangChain 블로그는 2026년 9월 초 multi-agent harness, managed credentials, per-caller identity, MCP 업데이트를 연달아 다뤘습니다. Google Developers Blog도 AI Agents Challenge에서 성공한 팀들이 bidirectional MCP, async event bus, unified validation, tiered routing 같은 구조를 썼다고 정리했습니다. 결론은 분명합니다. 멀티 에이전트는 프롬프트 체인이 아니라 시스템 아키텍처 문제입니다.

멀티 에이전트가 실패하는 흔한 이유

처음 멀티 에이전트를 만들면 역할 분담부터 시작합니다. planner, researcher, coder, reviewer, executor 같은 이름을 붙이고 메시지를 주고받게 만듭니다. 데모에서는 그럴듯합니다. 하지만 실제 업무에 넣으면 곧 문제가 생깁니다.

첫째, 컨텍스트가 중복됩니다. 모든 에이전트가 같은 문서를 읽고 같은 결론을 반복합니다. 비용은 늘고 결과는 길어집니다.

둘째, 책임이 흐려집니다. planner가 정한 계획을 coder가 무시하고, reviewer가 다른 전제를 놓고 평가합니다. 실패했을 때 어느 단계가 원인인지 알기 어렵습니다.

셋째, 권한이 과도해집니다. 모든 에이전트가 모든 도구를 쓸 수 있으면 실수 범위가 커집니다.

넷째, 검증이 마지막에 몰립니다. executor가 실제 상태를 바꾼 뒤 reviewer가 문제를 발견하면 되돌리는 비용이 큽니다.

그래서 멀티 에이전트의 핵심은 “에이전트를 많이 두는 것”이 아니라 “컨텍스트, 권한, 검증, 이벤트 흐름을 명확히 나누는 것”입니다.

하네스가 필요한 이유

하네스는 에이전트들이 일하는 런타임 규칙입니다. 누가 어떤 입력을 받고, 어떤 도구를 쓸 수 있고, 어떤 결과 형식으로 반환해야 하며, 다음 단계로 넘어가기 전 무엇을 검증해야 하는지를 정합니다.

LangChain 쪽 글들이 다루는 주제도 이 방향입니다. OpenWiki로 코드베이스 지식을 최신 상태로 유지하는 사례, managed credentials와 per-caller identity, multi-agent harness에서 context를 조직하는 방식, MCP의 stateless protocol과 elicitation 같은 내용은 모두 운영 구조와 관련됩니다.

실무에서는 하네스가 없으면 멀티 에이전트가 채팅방처럼 변합니다. 각 에이전트가 자기 방식으로 말하고, 중요한 정보는 묻히고, 재현 가능한 결과가 줄어듭니다. 반대로 하네스를 두면 에이전트는 사람이 아니라 함수처럼 다룰 수 있습니다.

컨텍스트를 세 종류로 나눠라

멀티 에이전트에서 가장 먼저 할 일은 컨텍스트 분리입니다. 모든 정보를 모든 에이전트에게 주면 성능이 좋아지는 것이 아니라 판단이 흐려집니다.

첫째, global context입니다. 제품 목표, 팀 규칙, 금지 사항, 보안 정책처럼 모든 에이전트가 알아야 하는 정보입니다. 이 정보는 짧고 안정적이어야 합니다. 자주 바뀌는 로그나 긴 문서를 넣으면 안 됩니다.

둘째, task context입니다. 현재 작업에 필요한 이슈 설명, 사용자 요구, 관련 파일, 제약 조건입니다. task context는 작업이 끝나면 폐기하거나 요약해야 합니다.

셋째, private context입니다. 특정 에이전트만 필요한 정보입니다. 예를 들어 reviewer는 코드 diff와 테스트 결과가 필요하지만, researcher에게 운영 토큰이나 배포 권한이 필요하지 않습니다.

이렇게 나누면 비용도 줄고 보안도 좋아집니다. 특히 고객 데이터나 secret이 섞인 맥락은 필요한 에이전트에게만 제한적으로 전달해야 합니다.

이벤트 버스와 상태 저장을 분리하라

성공적인 멀티 에이전트 구조는 대개 메시지 체인보다 이벤트 흐름에 가깝습니다. Google Developers Blog의 AI Agents Challenge 정리에서도 async event bus가 강한 패턴으로 언급됐습니다. 이유는 간단합니다. 실제 작업은 병렬로 진행되고, 일부는 실패하며, 재시도가 필요합니다.

예를 들어 기능 개발 작업을 생각해 봅시다. researcher는 관련 문서를 찾고, coder는 후보 파일을 분석하고, tester는 기존 테스트 구조를 확인할 수 있습니다. 이 세 작업은 순차로 기다릴 필요가 없습니다. 이벤트 버스에 'research.completed', 'code_scan.completed', 'test_plan.completed' 같은 이벤트를 발행하고, planner가 이를 모아 다음 단계를 결정하면 됩니다.

상태 저장은 별도로 둬야 합니다. 이벤트 로그는 “무슨 일이 있었는가”를 남기고, task state는 “현재 결론이 무엇인가”를 저장합니다. 둘을 섞으면 재시작과 디버깅이 어려워집니다.

per-caller identity가 없으면 엔터프라이즈에서 막힌다

멀티 에이전트가 사내 도구를 호출하려면 “누구 권한으로 호출했는가”가 중요합니다. LangChain 블로그의 managed credentials와 per-caller identity 주제도 이 문제와 연결됩니다. 에이전트 서비스 계정 하나로 모든 사용자 작업을 처리하면 감사와 권한 분리가 어렵습니다.

좋은 구조는 사용자의 identity를 도구 호출까지 전달합니다. 에이전트가 Jira 티켓을 만들더라도 실제 권한은 요청한 사용자 또는 승인자의 권한을 기준으로 판단합니다. 시스템 계정은 중개자일 뿐, 모든 리소스를 마음대로 만지는 슈퍼 계정이 되면 안 됩니다.

이 원칙은 보안뿐 아니라 UX에도 중요합니다. 사용자가 접근할 수 없는 문서를 에이전트가 읽고 답하면 정보 유출입니다. 반대로 사용자가 권한이 있는 문서를 못 읽으면 도구 가치가 떨어집니다. per-caller identity는 이 균형을 맞추는 기본 장치입니다.

tiered routing으로 비용과 지연을 줄인다

멀티 에이전트는 비용이 빨리 늘어납니다. 모든 단계에서 가장 비싼 모델을 쓰면 간단한 작업도 과해집니다. tiered routing은 작업 난이도와 위험도에 따라 모델과 도구를 나누는 방식입니다.

• 단순 분류: 저비용 모델 또는 규칙 기반
• 문서 검색 쿼리 생성: 중간 모델
• 코드 수정 계획: 고성능 모델
• 고위험 실행 판단: 고성능 모델 + 사람 승인
• 최종 요약: 중간 모델

중요한 것은 라우팅 기준을 로그로 남기는 것입니다. “왜 이 작업에 비싼 모델을 썼는가”, “왜 사람 승인이 필요했는가”를 설명할 수 있어야 비용 최적화가 가능합니다.

팀 레포에 넣을 최소 구현

처음부터 플랫폼을 만들 필요는 없습니다. 작은 YAML 또는 JSON 설정으로 시작할 수 있습니다.

• agents: 각 에이전트의 역할, 입력, 출력 스키마
• tools: 도구 이름, 위험도, 필요한 권한, dry-run 지원 여부
• routing: 작업 유형별 모델 선택 규칙
• context: global, task, private context 경로
• gates: 다음 단계로 넘어가기 전 검증 조건
• logs: 이벤트와 상태 저장 위치

이 설정을 코드와 함께 버전 관리하면 변경 이력을 추적할 수 있습니다. 에이전트 프롬프트도 코드처럼 리뷰해야 합니다. 프롬프트 변경이 운영 행동을 바꾸기 때문입니다.

실행 체크리스트

• 멀티 에이전트를 역할 이름이 아니라 입력·출력·권한 단위로 정의한다.
• global, task, private context를 분리한다.
• 모든 에이전트에게 모든 문서와 도구를 주지 않는다.
• 이벤트 로그와 현재 task state를 분리해 저장한다.
• 도구 호출에는 per-caller identity를 전달한다.
• 고위험 도구는 dry-run, approval, audit log를 필수로 둔다.
• tiered routing으로 모델 비용과 지연 시간을 관리한다.
• planner, coder, reviewer의 출력 스키마를 고정한다.
• 에이전트 프롬프트와 tool schema 변경을 코드 리뷰 대상으로 삼는다.
• 최종 결과뿐 아니라 중간 이벤트를 평가하는 하네스를 만든다.

멀티 에이전트의 성패는 에이전트 수가 아니라 경계의 선명함에 달려 있습니다. 컨텍스트를 줄이고, 권한을 좁히고, 이벤트를 남기고, 검증을 앞당기는 팀이 실제 운영에서 살아남습니다.