AI 에이전트(AI agents)를 활용하여 구축하는 엔지니어링 팀들은 단일 에이전트(single-agent) 문제는 대체로 해결했습니다. 더 어려운 과제는 역량이 여러 개의 독립적으로 배포된 에이전트들로 분산될 때 발생합니다. 각 에이전트는 서로 다른 팀이 소유하며, 각기 다른 릴리스 주기(release cadence)에 따라 실행됩니다. 이러한 경계를 넘어 일관된 대화를 유지하는 것은 오늘날 프로덕션 에이전트 시스템(production agent systems)에서 가장 복잡한 아키텍처적 문제 중 하나로 드러났으며, 이는 컨텍스트 엔지니어링 (context engineering) 및 스킬 확산 (skill sprawl)에 관한 Tessl의 자체 연구가 다른 각도에서 다루어 온 주제이기도 합니다.

복잡한 기술적 프로젝트에서 고객사와 함께 협업하는 Microsoft의 Industry Solutions Engineering (ISE) 팀은 최근 프로젝트에서 이러한 컨텍스트 문제를 어떻게 해결했는지에 대한 상세한 기록을 발표했습니다.

Agent2Agent (A2A) — 원래 Google에서 개발되었으며 현재는 Linux Foundation의 여러 벤더로 구성된 기술 운영 위원회(technical steering committee)에서 유지 관리하는 개방형 에이전트 통신 프로토콜(open agent communication protocol) — 을 사용할 때, 이들은 공유 인프라나 영구 메모리(persistent memory)가 없는 도메인 에이전트(domain agents)에게 대화 이력(conversational history)을 전달할 코디네이터 에이전트(coordinator agents)가 필요했습니다. Model Context Protocol (MCP)이 에이전트가 도구 및 데이터에 연결하는 방식을 표준화하는 반면, A2A는 다른 수준에서 작동합니다: 이는 에이전트가 동등한 피어(peers)로서 서로 어떻게 통신하는지, 그리고 서비스 경계를 넘어 작업과 메시지를 어떻게 전달하는지를 정의합니다.

공유 저장소는 에이전트가 가져서는 안 될 의존성을 생성합니다

Microsoft는 가장 잘 작동하는 방식을 결정하기 전 세 가지 핵심 접근 방식을 평가했다고 밝혔습니다.

첫 번째 옵션은 도메인 에이전트가 공유 저장소 계층(shared storage layer)으로부터 읽어 들이고, 공통 식별자(common identifier)를 사용하여 대화 이력을 검색하는 방식이었습니다. 이 방식의 장점은 메시지 크기가 최소화되고 단일 진실 공급원(single source of truth)을 유지할 수 있다는 점이지만, 모든 도메인 에이전트가 다른 팀이 소유한 저장소에 대한 자격 증명(credentials)과 연결성을 가져야 한다는 점이 문제입니다. 이는 에이전트가 조직의 경계를 넘을 때 빠르게 다루기 힘든 의존성(dependency)이 됩니다. 두 번째 옵션은 각 도메인 에이전트를 상태 유지형(stateful)으로 만들어 자체적인 대화 기록을 유지하도록 하는 것입니다. 그러나 에이전트별 저장소를 실행하는 운영 오버헤드(operational overhead), 배포 중 상태 마이그레이션(state migration) 처리, 그리고 에이전트 간의 데이터 불일치(divergence) 방지 문제로 인해 이 방식은 초기에 제외되었습니다.

세 번째 접근 방식이자 Microsoft가 최종적으로 채택한 방식은 요약된 대화 기록 (conversation history)을 각 메시지 페이로드 (payload) 내부에 직접 전송하는 것입니다. 도메인 에이전트 (domain agents)들은 외부 저장소 (external store)를 건드리지 않고도 일관성 있게 응답하는 데 필요한 모든 정보를 전달받습니다. 대화가 10회 진행될 때마다 페이로드 크기를 관리 가능한 수준으로 유지하기 위해 기록을 요약하는데, 이는 팀에서도 인정하는 충실도 (fidelity)와 성능 (performance) 사이의 의도적인 트레이드오프 (trade-off)입니다.

"요약 (Summarisation)에 위험이 없는 것은 아닙,"라고 그들은 기술합니다. "모든 요약 단계는 중요한 세부 정보를 놓치거나 부정확함을 유발할 수 있으며, 잠재적으로 후속 응답 (downstream responses)의 품질을 저하시킬 수 있습니다."

하지만 그에 대한 반론은, 전체 대화 기록을 검증 없이 전달하는 것 자체가 또 다른 문제를 일으킨다는 점입니다. 너무 많은 컨텍스트 (context)를 입력받은 모델은 관련성보다 양을 우선시하게 되어 일관성을 잃을 수 있습니다. 10회 대화 임계값 (threshold)은 이에 대한 팀의 해답이며, 관찰된 출력 품질에 따라 조정할 수 있다고 그들은 말합니다. 또한 요약은 자연스러운 보안 경계 (security boundary)를 형성하여, 코디네이터 (coordinator)가 각 에이전트가 보는 정보에 대해 세밀한 제어 (fine-grained control)를 할 수 있게 해준다고 언급했습니다. 이는 일률적으로 적용되는 스토리지 수준의 액세스 제어 (access controls)로는 쉽게 복제할 수 없는 기능입니다.

"코디네이터는 각 도메인 에이전트가 어떤 컨텍스트를 받는지 정확하게 제어합니다,"라고 회사는 기술합니다. "대화의 한 부분에서 발생한 민감한 정보는 특정 에이전트에게 전송되는 컨텍스트에서 제외될 수 있습니다."

컨텍스트 아키텍처는 엔지니어링적 결과가 따르는 거버넌스 결정이다

Microsoft는 도메인 에이전트를 상태가 없는 (stateless) 상태로 유지하는 것이 즉각적인 컨텍스트 문제 해결을 넘어 더 큰 이득을 준다고 주장합니다. 자체적인 상태 (state)를 보유하지 않는 에이전트는 추론하기가 더 쉽습니다. 에이전트의 동작이 메시지에 도착하는 내용에 의해 전적으로 결정되므로, 장애 발생 시 진단이 명확해집니다.

"디버깅 (Debugging)은 에이전트의 내부 상태 기록을 재구성하는 대신 입력 메시지를 검사하는 것으로 단순화됩니다,"라고 Microsoft는 기술합니다. "이는 배포 (deployments) 또한 단순화합니다. 어떤 에이전트 인스턴스 (agent instance)라도 상태 마이그레이션 (state migration) 없이 교체하거나 롤백 (rolled back)할 수 있습니다."

그러한 속성들은 에이전트가 팀 또는 조직의 경계를 넘어 작동할 때 가장 중요해지며, 이 경우 감사 가능성 (auditability)과 예측 가능성 (predictability)이 실질적인 무게를 갖게 됩니다.

그러한 상황에 처한 엔지니어링 팀에게 컨텍스트 패턴 (context pattern)의 선택은 메시지 크기를 훨씬 넘어서는 결과를 초래합니다. 이는 대화 기록 (conversational record)의 소유권이 누구에게 있는지, 특정 에이전트가 무엇을 전달받았는지 누가 감사할 수 있는지, 그리고 새로운 에이전트가 추가되거나 팀의 경계가 변경될 때 시스템이 얼마나 안전하게 확장될 수 있는지를 결정합니다.