왜 IM(인스턴트 메시징)이 AI 에이전트 협업을 위한 자연스러운 인프라 계층인가

멀티 에이전트 시스템 (Multi-agent system)을 구축할 때, 첫 번째 실질적인 질문은 어떤 모델을 사용할지 또는 프롬프트 (Prompt)를 어떻게 구성할지가 아닙니다. 그보다 더 단순하면서도 어려운 문제입니다. 바로 이 에이전트들이 실제로 어떻게 서로 대화하느냐 하는 것입니다.

대부분의 팀은 익숙한 도구 모음(Toolkit)을 찾습니다. 이벤트 스트리밍 (Event streaming)을 위한 Kafka, 작업 큐 (Task queues)를 위한 RabbitMQ, 동기식 호출 (Synchronous calls)을 위한 gRPC 또는 REST, 지연 시간 (Latency)이 중요할 때는 커스텀 WebSocket 서버 등이 그것입니다. 이것들은 모두 합리적인 선택입니다. 저희도 여러 가지를 시도해 보았습니다. 하지만 Mininglamp에서 이 문제에 상당한 시간을 할애한 결과, 우리는 계속해서 동일한 마찰에 부딪혔습니다. 우리는 단지 다른 이름으로 불릴 뿐인, 이미 존재하는 조정 인프라 (Coordination infrastructure)를 구축하고 있었던 것입니다.

우리가 필요로 했던 프로토콜은 이미 수십 년 동안 대규모 프로덕션 환경에서 실행되고 있었습니다. 우리는 그것을 인간을 조정하는 데 사용해 왔습니다.

멀티 에이전트 조정에 실제로 필요한 것

특정 에이전트 프레임워크 (Agent framework)의 세부 사항을 걷어내면 다음과 같은 동일한 핵심 요구 사항이 나타납니다.

• 어느 정도의 순서 보장 (Ordering guarantee)을 갖춘 비동기 메시지 전달 (Asynchronous message delivery)
• 점대점 결합 (Point-to-point coupling) 없이 특정 수신자 또는 그룹으로의 라우팅 (Routing)
• 에이전트가 모든 것이 아닌 관련 있는 정보만 가질 수 있도록 하는 범위가 지정된 컨텍스트 (Scoped context)
• 어떤 에이전트가 어떤 워크플로 (Workflow)에 참여할 수 있는지 결정하는 액세스 제어 (Access control)
• 기계가 파싱 (Machine-parseable)할 수 있을 만큼의 충분한 구조와 새로운 상황을 처리할 수 있을 만큼의 충분한 유연성

이 목록은 메시지 큐 (Message queue)나 RPC 프레임워크에 대한 설명이 아닙니다. 이것은 인스턴트 메시징 (Instant messaging, IM) 시스템에 대한 설명입니다.

이것은 비유가 아닙니다. IM은 비동기적으로 작동하고, 서로 다른 역할과 권한을 가지며, 여러 병렬 컨텍스트에서 작업하고, 주로 자연어 (Natural language)로 통신하는 느슨하게 결합된 (Loosely-coupled) 에이전트들을 조정하기 위해 제1원칙 (First principles)부터 설계되었습니다. IM을 형성한 설계 제약 조건은 멀티 에이전트 시스템의 설계 제약 조건과 거의 동일합니다. 문제는 동일하기 때문에 기본 요소 (Primitives)도 일치합니다.

비동기 (Async)는 선택 사항이 아니다

에이전트 파이프라인 (Agent pipelines)을 구축할 때 가장 먼저 내재화하게 되는 사실 중 하나는, 동기적 결합 (Synchronous coupling)이 규모가 커질 때 치명적이라는 점입니다. 하위 에이전트 (Sub-agent)의 응답을 기다리며 차단 (Block)되는 오케스트레이터 (Orchestrator)는 병렬 처리를 수행할 수 없습니다. 부하가 걸리면 큐 (Queue)에 쌓이다가 결국 무너지고 맙니다.

전통적인 메시지 큐 (Message queues)가 이 문제를 해결해주지만, 이는 별도의 운영 영역 (Operational surface)을 도입하게 됩니다. 애플리케이션 로직은 한 곳에 있고, 조정 인프라 (Coordination infrastructure)는 다른 곳에 있게 됩니다. 별도의 배포, 별도의 모니터링, 별도의 스키마 (Schemas), 별도의 디버깅이 필요합니다. 조정 패턴이 안정적이고 잘 알려진 시스템에서는 이 방식도 괜찮습니다. 하지만 빠르게 진화하는 시스템에서는 이는 마찰 (Friction) 요인이 됩니다.

IM 채널은 설계 단계부터 비동기 (Async) 방식입니다. 채널로 전송된 메시지는 수신자가 받을 준비가 되었을 때 전달됩니다. 송신자는 기다리지 않습니다. 이것이 에이전트 조정 (Agent coordination)을 위한 올바른 의미론 (Semantic)이며, IM이 구축된 방식 그 자체이기 때문에 이를 별도의 노력 없이 얻을 수 있습니다.

또한 메시지 큐가 일반적으로 잘 제공하지 못하는 기능인 스레드 기반 컨텍스트 (Threaded context)를 얻을 수 있습니다. IM의 스레드 (Thread)는 자연스러운 경계를 가집니다. 주제가 있고, 시작점이 있으며, 그 안에서 일어난 일관된 교환 내용이 존재합니다. 에이전트가 스레드에 참여하면, 히스토리 (History)를 읽고 컨텍스트 (Context)를 이해합니다. 그 범위는 스레드 자체에 의해 제한됩니다.

LLM 기반 에이전트에게 이는 엄청나게 중요합니다. 컨텍스트 윈도우 (Context windows)는 유한하며 이를 채우는 데 비용이 많이 듭니다. 에이전트에게 몇 달 전까지 거슬러 올라가는 채널 전체가 아니라, 관련 있는 히스토리의 조각만을 제공하고 싶을 것입니다. 스레드 의미론 (Thread semantics)은 이를 자연스럽게 처리합니다. 스레드 자체가 이미 큐레이션된 컨텍스트 윈도우이기 때문입니다.

여기에는 또 다른 관점인 배압 (Backpressure)도 존재합니다. 에이전트가 바쁘거나 속도 제한 (Rate-limited)에 걸리면, 메시지는 채널에 머물게 됩니다. 송신자는 무언가가 처리되지 않고 있다는 자연스러운 신호를 받게 됩니다. 대화는 그저 일시 중지될 뿐입니다. IM 메시지의 지속성 (Persistence)이 암묵적으로 버퍼링 (Buffering)을 처리하기 때문에, 조정 계층 (Coordination layer)에서 재시도 로직 (Retry logic)이나 서킷 브레이커 (Circuit breakers)를 별도로 구현할 필요가 없습니다. 이것이 항상 높은 처리량 (High-throughput)을 요구하는 파이프라인에 충분한 것은 아니지만, 대부분의 에이전트 협업이 일어나는 대화형, 작업 지향적 워크플로 (Task-oriented workflows)에서는 일반적인 사례들을 잘 커버합니다.

채널 격리는 권한 구조와 직결됩니다

실제 멀티 에이전트 시스템 (Multi-agent systems)에는 액세스 제어 (Access control)가 필요합니다. 데이터베이스 쓰기 권한을 가진 에이전트가 고객 응대 에이전트와 동일한 조정 공간 (Coordination space)에서 작동해서는 안 됩니다. 민감한 금융 워크플로는 범용 에이전트로부터 격리되어야 합니다. 또한 액세스는 감사 가능 (Auditable)해야 합니다.

IM 시스템은 대부분의 조직이 직관적이라고 느끼는 계층 구조를 통해 이를 모델링합니다:

Organization (조직)
  └── Spaces (스페이스)
        └── Categories (카테고리)
...

권한은 이 구조를 통해 아래로 흐릅니다. 특정 채널에 배치된 에이전트는 해당 채널의 액세스 경계 (Access boundaries)를 상속받습니다. 자신이 멤버가 아닌 채널은 볼 수 없으며, 자신의 범위를 벗어나 행동할 수 없습니다. 이를 에이전트마다 개별적으로 설정하는 것이 아니라, 채널과 멤버십 (Membership)을 설정함으로써 관리합니다.

액세스 제어를 직접 설계, 구현 및 유지 관리해야 하는 커스텀 메시지 브로커 (Custom message broker)와 대조해 보십시오. IM은 수년간의 프로덕션 사용과 보안 검증을 통해 뒷받침되는 작동 모델을 제공합니다. 여러분은 이 바퀴를 새로 발명할 필요가 없습니다.

채널 격리는 덜 명확하지만 중요한 이점인 조직적 가독성 (Organizational legibility)도 제공합니다. 채널 구조를 살펴보면 어떤 에이전트가 어떤 워크플로에 참여하고 있는지 한눈에 파악할 수 있습니다. 액세스 모델이 가시적입니다. 라우팅 로직 (Routing logic)이 애플리케이션 코드 내에 존재하는 큐 기반 아키텍처 (Queue-based architectures)에서는 항상 이렇지만은 않습니다.

별도의 상태 저장소 없는 지속적인 컨텍스트

우리가 이를 완전히 이해하기까지는 시간이 좀 걸렸기에, 명확히 짚고 넘어갈 가치가 있습니다.

커스텀 에이전트 조정 시스템 (Custom agent coordination systems)은 거의 항상 두 가지 구성 요소를 가집니다: 조정 프로토콜 (에이전트 간에 이동하는 메시지)과 상태 저장소 (중요한 정보를 영구적으로 보관하는 데이터베이스 또는 캐시)입니다. 여러분은 스키마를 설계하고, 글루 코드 (glue code)를 작성하며, 이 두 가지를 모두 유지 관리해야 합니다. 문제가 발생하면 두 곳 모두를 가로질러 디버깅해야 합니다.

IM (인스턴트 메시징)은 이 둘을 하나로 통합합니다. 메시지 기록이 곧 상태입니다. 대화가 곧 감사 로그 (audit log)입니다. 영속성 (Persistence)은 여러분이 관리해야 하는 별도의 관심사가 아니라, 시스템의 기본 동작입니다.

에이전트 워크플로 (agentic workflows)에서 이는 실질적으로 유용한 기능을 가능하게 합니다: 에이전트가 진행 중인 대화에 참여하여 즉시 컨텍스트 (context)를 이해할 수 있다는 점입니다. 상태를 별도의 저장소에 직렬화 (serialize)하여 주입할 필요가 없습니다. 에이전트는 스레드 (thread)를 읽습니다. 무엇이 논의되었는지, 무엇이 결정되었는지, 무엇이 여전히 미결 상태인지 확인합니다. 이는 인간의 온보딩 (onboarding) 방식과 정확히 일치합니다. 누군가 프로젝트 채널에 합류하여 이전 대화 내용을 읽고 상황을 파악하는 것과 같습니다. 에이전트도 동일한 인터페이스를 사용하여 똑같은 일을 수행합니다.

여기에는 감사 (audit) 측면의 이점도 있습니다. 에이전트 시스템에서 예상치 못한 출력이 발생했을 때, 대화 기록은 여러분의 트레이스 (trace)가 됩니다. 모든 메시지, 모든 결정 지점, 모든 에이전트의 응답이 발생한 순서대로 기록됩니다. 조정 계층 (coordination layer) 자체가 이미 로그이기 때문에, 조정 계층을 위한 별도의 트레이싱 (tracing) 시스템이 필요하지 않습니다.

기본 프로토콜로서의 자연어 (Natural Language)

대부분의 에이전트 조정 프로토콜은 구조화된 데이터 교환을 요구합니다. JSON 스키마, 함수 호출 (function call) 사양, 정의된 메시지 엔벨로프 (message envelopes) 등이 그것입니다. 이러한 방식은 시스템 내의 모든 에이전트가 동일한 인터페이스를 염두에 두고 동일한 팀에 의해 설계되었을 때는 잘 작동합니다.

이러한 방식은 이기종 에이전트 시스템 (heterogeneous agent systems)에서는 제대로 작동하지 않습니다. 만약 한 제공업체의 에이전트를 다른 제공업체의 인프라와 통합하려 한다면, 공유된 인터페이스 사양 (interface specification)이 필요합니다. 이는 보통 통합 계층 (integration layer), 커스텀 직렬화 (custom serialization), 스키마 변환 (schema translation)을 의미합니다. 에이전트가 추가될수록 관리해야 할 통합 접점 (integration surface)도 늘어납니다.

자연어 (Natural language)는 이러한 문제의 대부분을 우회합니다. 두 에이전트가 모두 텍스트를 읽고 쓸 수 있다면, 공유된 스키마 없이도 협업할 수 있습니다. 프로토콜이 곧 언어가 되는 것입니다. 이것이 항상 최선의 선택인 것은 아닙니다. 어떤 상호작용은 정밀도와 기계 판독성 (machine parseability)이 중요하기 때문에 진정으로 구조화된 데이터 (structured data)를 필요로 합니다. 하지만 자연어를 기본값으로 두고, 필요할 때 구조화를 옵션으로 추가하는 방식이 이기종 시스템을 위한 올바른 시작점입니다.

IM은 자연어를 우선시합니다. 기본 메시지 유형은 텍스트입니다. 멘션 (mentions), 첨부 파일 (attachments), 반응 (reactions)과 같은 구조화된 요소들이 존재하며 유용하지만, 기본값은 산문 (prose)입니다. 이는 인간과 기계 모두에게 동시에 읽힐 수 있어야 하는 시스템에 적합한 기본 설정입니다.

디버깅 (debugging) 측면에서도 실질적인 결과가 따릅니다. 에이전트 간 협업 시스템이 바이너리 프로토콜 (binary protocols)이나 커스텀 엔벨로프 (custom envelopes)를 사용할 때, 디버깅을 위해서는 해당 형식을 이해하는 도구가 필요합니다. 반면 IM 채널에서 자연어로 협업이 이루어지면, 내용을 직접 읽을 수 있습니다. 사람이 채널을 열어 대화 내용을 읽음으로써 에이전트들이 무엇을 하고 있었는지, 어디서 문제가 발생했는지 즉시 이해할 수 있습니다. 이는 사소해 보일 수 있지만 그렇지 않습니다. 디버깅 가능성 (Debuggability)은 실제 운영 비용이며, 자연어는 전체 협업 계층을 기본적으로 인간이 감사할 수 있는 (human-auditable) 상태로 만듭니다.

개인적 사용을 넘어선 조직적 배포

여기에는 실제 배포 시 중요한, 보다 조용한 논거가 하나 더 있습니다.

대부분의 AI 도구 도입은 개인 단위로 이루어집니다. 당신을 개인적으로 도와주는 에이전트가 있습니다. 질문에 답하고, 문서를 요약하며, 코드를 작성합니다. 그 능력의 범위는 당신에게 국한됩니다. 당신이 사용하지 않을 때, 그것은 아무것도 생산하지 않습니다. 당신이 조직을 떠나면, 그 능력도 당신과 함께 떠납니다.

에이전트가 팀과 함께 IM (인스턴트 메시징) 채널에 참여할 때, 배포 모델은 근본적으로 변화합니다. 채널은 공유됩니다. 모든 팀원이 동일한 에이전트와 상호작용하고, 에이전트가 생산하는 것을 보며, 어떻게 효과적으로 프롬프트 (Prompt)를 작성하는지 배우고, 에이전트와 협업하는 방법에 대한 공유된 직관을 쌓아갑니다. 잘 운영되는 채널 내의 유능한 에이전트는 개인의 생산성 도구가 아닌, 조직의 인프라 (Infrastructure)가 됩니다.

이는 과소평가하기 쉬운 방식으로 도입 과정에 영향을 미칩니다. 개인적인 AI 도입은 비교적 마찰이 적습니다. 한 사람이 도구를 사용하기로 결정하고 사용을 시작하면 그만입니다. 하지만 조직적인 AI 도입은 어렵습니다. 팀이 어떻게 공유된 작업 패턴을 개발할까요? 에이전트가 할 수 있는 일과 할 수 없는 일에 대한 지식이 어떻게 사람들에게 전파될까요? 팀이 에이전트가 무엇을 왜 하고 있는지에 대한 공유된 맥락 (Context)을 어떻게 유지할까요?

IM은 이미 인간의 협업을 위해 이러한 문제들을 해결하고 있습니다. 채널에 상주하는 에이전트는 이러한 해결책을 그대로 물려받습니다. 통신 인프라, 알림 패턴, 사람들이 동기화 (Sync)를 유지하는 방식에 관한 규범들 말입니다. IM 내의 에이전트는 이미 존재하는 프로세스의 일부이기 때문에 별도의 도입 프로세스가 필요하지 않습니다.

어댑터 문제 (The Adapter Problem)

IM이 적절한 협업 계층이라는 점을 받아들이면 실질적인 엔지니어링 과제가 발생합니다. 대부분의 조직은 이미 IM 플랫폼을 보유하고 있습니다. 당신은 처음부터 새로 만드는 것이 아니라, 기존 인프라에 통합해야 합니다.

AI 에이전트 (AI agents)를 IM의 진정한 퍼스트 클래스 참여자 (first-class participants)로 만드는 것은 단순히 메시지를 게시하는 웹훅 (webhook) 이상의 것을 요구합니다. 진정한 참여란 여러 메시지에 걸친 대화 문맥 (conversation context)을 이해하고, 채널 멤버십에서 상속된 권한 (inherited permissions)을 준수하며, 플랫폼이 지원하는 모든 메시지 유형의 어휘 (vocabulary)를 처리하고, 세션 전반에 걸쳐 일관된 상태 (coherent state)를 유지하며, 다이렉트 메시지 (direct messages), 스레드 답글 (thread replies), 멘션 (mentions), 리액션 (reactions) 등 채널 내의 모든 신호 범위에 적절하게 응답하는 것을 의미합니다.

이를 재사용 가능한 계층 (reusable layer)으로 구축한다는 것은, 에이전트 협업 (agent coordination)에 실제로 중요한 의미론 (semantics)을 보존하면서 서로 다른 IM 플랫폼의 구체적인 동작들을 추상화 (abstracting)하는 것을 의미합니다. 기본 요소 (primitives)들은 플랫폼 간에 유사하지만, 세심하게 추상화하지 않으면 문제가 될 수 있는 방식으로 세부 사항들이 갈라집니다.

우리가 구축한 것

이러한 사고방식은 우리로 하여금 Apache 2.0 라이선스로 출시된 오픈 소스 AI 네이티브 팀 협업 플랫폼인 Octo를 구축하도록 이끌었습니다. 핵심적인 아키텍처 설계 선택은 AI 에이전트를 조직 커뮤니케이션 계층의 부가 기능 (add-on)이 아닌, 퍼스트 클래스 참여자로 만드는 것이었습니다.

Octo의 에이전트들은 채널에 참여하며 동일한 인터페이스를 통해 인간 팀원들과 나란히 일합니다. 별도의 AI 대시보드나 특별한 모드는 없습니다. 동일한 대화 기록, 동일한 권한 모델, 동일한 스레딩 의미론 (threading semantics)이 인간과 에이전트 모두에게 적용됩니다. 채널 멤버의 관점에서 에이전트는 또 다른 참여자일 뿐입니다.

설명할 가치가 있는 몇 가지 구체적인 구성 요소는 다음과 같습니다:

octo-adapters는 제3자 AI 에이전트와 IM 플랫폼을 연결하는 브리지 (bridge) 역할을 합니다. 모든 에이전트가 IM의 의미론을 네이티브하게 이해하도록 요구하는 대신, 어댑터 계층 (adapter layer)이 번역을 처리합니다. 에이전트는 자신의 역량을 노출하고, 어댑터는 채널에서의 참여를 관리합니다. 이는 기존 에이전트들이 IM을 위해 재설계되지 않고도 IM 내부에서 작동할 수 있음을 의미합니다. 통합 지점은 개별 에이전트가 아니라 바로 이 브리지입니다.