저의 AI 에이전트들이 팀 채팅에 결과를 게시했습니다. 사람이 답장을 남기자, 첫 번째 메시지를 전혀 보지 못한 두 번째 에이전트가 끼어들었습니다. 이러한 연쇄 작용으로 인해 문맥이 누락되고, 작업이 중복되며, 명백한 오류가 발생했습니다. 기존의 메모리 서버와 모니터링 스택에 경량화된 에이전트 간 통신 프로토콜(IACP)을 연결하자, 채팅창의 혼란은 사라졌고 워크플로우는 더욱 견고해졌습니다.
이 문제가 중요했던 이유
운영 환경에서 AI 에이전트는 더 이상 고립된 실험 대상이 아닙니다. 에이전트는 데이터를 가져오거나, 코드를 생성하거나, 배포를 트리거하는 마이크로서비스로서 작동합니다. 각 에이전트가 인간하고만 대화할 경우, 중복되는 책임 범위는 숨겨진 경쟁 상태(race condition)가 됩니다. 의도치 않은 슬랙 메시지는 무해해 보일 수 있지만, 개발자들은 모순된 출력값을 정리하는 데 시간을 허비하고, 두 봇이 동일한 저장소를 수정할 때 파이프라인이 중단되며, 자동화에 대한 신뢰도는 떨어집니다.
잃어버린 연결 고리: 실시간 공유 상태
대부분의 팀은 에이전트가 프롬프트를 받고 결과를 반환하는 "블랙박스"라고 취급하며, 프롬프트에 필요한 모든 문맥이 포함되어 있다고 가정합니다. 하지만 실제로 에이전트들은 상태가 끊임없이 변하는 작업 공간을 공유합니다. 저장소가 잠겨 있을 수도 있고, 서비스가 다운되었을 수도 있으며, 이전 분석이 막 완료되었을 수도 있습니다. 브로드캐스트 메커니즘이 없다면, 각 봇은 오래된 스냅샷을 바탕으로 작업하게 됩니다.
기존 도구 위에 IACP 구축하기
새로운 플랫폼을 구축하는 대신, 대화 기록을 저장하는 메모리 서버와 에이전트의 상태를 추적하는 모니터링 스위트를 확장했습니다. 이 프로토콜은 다섯 가지 구체적인 기능을 제공합니다.
구조화된 식별자 (Structured Identity) – 모든 외부 메시지는
claude@greenmac:8f3a2c와 같은 고유 식별자를 포함합니다. 이 형식을 통해 수신자는 누가, 어떤 인스턴스에서 메시지를 보냈는지 즉시 알 수 있어, "봇이 X라고 말함"과 같은 모호한 상황을 제거합니다.이력 주입 (History Injection) – 답변을 생성하기 전에, 봇은 다른 에이전트의 메시지를 포함한 가장 최근의 채팅 세그먼트를 가져와 프롬프트 앞에 추가합니다. 문맥이 결코 유실되지 않으며, 모델은 동료 에이전트들이 이미 기여한 내용에 대해 추론할 수 있습니다.
상태 전환 (State Transitions) – 에이전트는 빈번한 하트비트(heartbeat)를 보내는 대신, 내부 상태가 바뀔 때마다
working,blocked, 또는idle과 같은 상태 변경 사항을 게시합니다. 이를 통해 소비자는 즉각적으로 반응할 수 있습니다. 예를 들어, 상위 에이전트가idle상태를 보고할 때만 종속된 작업을 큐에 넣는 식입니다.권고형 리스 (Advisory Leases) – 에이전트가 리소스(저장소, API 엔드포인트, 컴퓨팅 노드 등)에 대한 독점적 접근 권한이 필요할 때, TTL(time-to-live)이 포함된 리스(lease)를 요청합니다. 에이전트가 충돌(crash)하면 리스는 자동으로 만료되어 다른 에이전트가 리소스를 사용할 수 있게 되며, 두 봇이 서로의 작업을 방해하는 것을 방지합니다.
인박스 메커니즘 (Inbox Mechanism) – "스톱 훅(stop hook)"은 인박스에 읽지 않은 메시지가 있으면 에이전트의 워크플로우를 일시 중지합니다. 에이전트는 현재 작업을 완료하기 전에 해당 항목들을 처리해야 하며, 이를 통해 대기 중인 조정 신호가 무시되지 않도록 보장합니다.
이 요소들은 모든 참여자가 동일한 정보를 공유할 수 있도록 단순하고 관찰 가능한 통신 계층을 형성합니다.
이를 무시하는 팀이 치러야 할 대가
팀이 임시방편적인(ad-hoc) 프롬프트와 수동 모니터링에 계속 의존한다면, 숨겨진 비용이 눈덩이처럼 불어날 것입니다.
- 중복된 작업 – 두 에이전트가 동일한 보고서를 생성하여 컴퓨팅 자원과 클라우드 비용을 낭비할 수 있습니다.
- 리소스 경합 – 코드베이스에 대한 동시 쓰기 작업은 인간의 개입이 필요한 머지 충돌(merge conflict)을 유발합니다.
- 운영 리스크 – 업데이트되지 않은 상태를 바탕으로 동작하는 에이전트가 다른 에이전트가 이미 롤백을 진행 중인 상황에서 배포를 시도하여 서비스를 불안정하게 만들 수 있습니다.
IACP는 에이전트가 자신의 식별자, 상태, 리소스 점유를 알리는 방식을 공식화함으로써, 무거운 오케스트레이션 엔진 없이도 이러한 리스크를 줄여줍니다.
반론: 추가되는 오버헤드
비판론자들은 이력을 주입하고 리스를 관리하는 것이 지연 시간(latency)과 추가적인 코드 경로를 발생시킨다고 주장합니다. 단일 에이전트가 좁은 범위의 작업만 수행하는 환경에서는 프로토콜의 이점이 미미할 수 있습니다. 하지만 이 구현 방식은 기존의 메모리 및 모니터링 서비스를 재사용하므로 증분 부하(incremental load)는 미미합니다. 이미 에이전트 간의 혼선으로 어려움을 겪고 있는 팀에게 이 트레이드오프(trade-off)는 분명히 유리합니다.
향후 주목할 점
이 프로토콜은 아직 프로토타입 단계이지만, 모듈식 구조 덕분에 언어에 구애받지 않는(language-agnostic) 어떤 에이전트 프레임워크와도 통합이 가능합니다. 향후 가능한 단계는 다음과 같습니다:
- 개발자가 핵심 로직을 건드리지 않고도 5가지 훅을 추가할 수 있도록 경량 SDK를 출시합니다.
- 상태 전이와 리스 변동(lease churn)을 시각화하여 팀이 병목 현상을 파악할 수 있도록 돕는 메트릭을 모니터링 스위트에 추가합니다.
- 트래픽이 높은 시나리오에서 특정 에이전트의 리스에 다른 에이전트보다 자동으로 우선순위를 부여하는 정책 레이어를 실험합니다.
이러한 확장 기능들이 호응을 얻는다면, IACP는 HTTP가 웹 서비스에서 그랬던 것처럼 멀티 에이전트 프로덕션 파이프라인의 사실상 표준(de-facto standard)이 될 수 있습니다.
핵심 요약: 누가 말하고 있는지, 최근 대화 내용이 어떠한지, 에이전트의 상태가 언제 변하는지, 누가 리소스를 보유하고 있는지, 그리고 대기 중인 메시지가 있는지와 같은 간단한 일련의 규약(conventions)만으로도 AI 에이전트들이 서로 엇갈린 대화를 하는 것을 방지하고, 소란스러운 채팅방을 신뢰할 수 있는 조정 채널로 바꿀 수 있습니다.