Why Your AI Agents Can't Talk to Each Other (Yet) — Vlad Luzin, BAND

한 줄 핵심

AI 에이전트가 서로 협업하려면 단순한 채팅이나 프로토콜이 아니라, 분산 시스템 수준의 통신·지속성·식별·관측성을 갖춘 전용 상호작용 계층이 필요하다는 점을 BAND 데모로 설명하는 영상이다.

시간별 요약

1. 0:00
   소개 발표 주제는 AI 에이전트 간 통신의 미래, 현재 겪는 기술적 난제, 그리고 BAND 제품 소개로 정리된다. 핵심은 에이전트 협업이 이미 시작됐고, 이를 제대로 연결하는 기반이 아직 부족하다는 문제의식이다.
2. 0:45
   AI 대 AI 통신이라는 논지 기업 내부, 기업 간, 소비자와 기업 사이에서 AI가 대신 일하려면 결국 AI끼리 서로 대화해야 한다. 앞으로의 에이전트는 전 세계에 분산된 항상 켜진 자율 주체가 된다는 관점이 제시된다.
3. 1:29
   에이전트 간 작업 방식 에이전트들은 대화형 공간에서 서로를 발견하고, 초대하고, 작업을 위임한 뒤 충분한 정보를 모아 다시 응답하는 흐름으로 동작한다. 이때 사람의 개입 없이도 에이전트끼리 협업하는 모습이 미래의 기본 패턴으로 그려진다.
4. 2:04
   적대적 에이전트와 라우터 역할 Claude나 Codex를 여러 세션으로 나눠 계획과 검토를 병렬로 돌리는 방식이 이미 흔한 활용 사례로 제시된다. 이 경우 사용자는 사실상 두 상태를 가진 에이전트 사이에서 패킷을 옮기는 라우터처럼 동작하게 된다.
5. 2:44
   루프 엔지니어링의 핵심 루프 엔지니어링은 결국 여러 상태ful 에이전트를 번갈아 호출하도록 Python이나 TypeScript 코드가 중간에서 조정하는 구조로 요약된다. 즉, 사람이 하던 라우팅을 코드로 외주화한 형태이며, 그 코드를 실행하는 순간 루프가 시작된다.
6. 3:29
   단일 에이전트 병목 트랜스포머 구조의 한계 때문에 하나의 에이전트가 모든 일을 처리하면 확증 편향, 주의 분산, 문맥 파편화, 기억 저하가 생긴다. 긴 컨텍스트만 늘려서는 성능 문제가 해결되지 않으며, 그래서 여러 에이전트를 연결하는 접근이 필요해진다.
7. 4:18
   메시징 앱이 통하지 않는 이유 Slack, Teams, Discord, WhatsApp, Telegram 같은 앱은 사람과 에이전트를 잇는 데는 쓸 수 있어도 에이전트끼리 자연스럽게 연결하는 데는 맞지 않는다. 설정도 복잡하고, 결국 에이전트가 다른 에이전트와 자유롭게 통신하지 못한 채 사용자와만 대화하는 고립 상태에 머문다.
8. 5:33
   MCP와 A2A가 충분하지 않은 이유 MCP, ACP, A2A 같은 프로토콜은 표면적으로는 연결 해법처럼 보이지만, 실제로는 상태 없는 호출과 단방향성, 타임아웃, 발견(discovery), 대기열 등 빠진 요소가 많다. 결과적으로 이것들은 멀티 에이전트 시스템이 아니라 또 다른 계획 코드만 늘리는 일이 되기 쉽다.
9. 7:08
   요약 멀티 에이전트 시스템은 이미 사용 중이지만, 메시징 앱은 인간 중심이라 봇 간 연결을 막고, 프로토콜은 너무 낮은 수준이라 확장 가능한 시스템을 만들기 어렵다. 따라서 원격 에이전트를 실제로 연결하는 문제를 별도의 시스템 문제로 봐야 한다.
10. 7:52
    분산 시스템 문제 로컬 세션이든 클라우드의 Codex든 에이전트 간 연결은 본질적으로 분산 시스템 문제다. 결정적 소프트웨어도 어렵지만, 비결정적인 에이전트를 마이크로서비스처럼 다루면 훨씬 더 복잡해진다.
11. 8:17
    전송, 지속성, 런타임 바인딩 실시간·순서 보장 전송, 재시도 처리, 실패 후 복구를 위한 지속성과 hydration, 그리고 thread ID·session ID·execution ID·run ID를 연결하는 runtime binding이 필요하다. IP나 포트 수준이 아니라 conversation, participant, channel, room 같은 추상화로 올라가야 에이전트가 같은 목표를 공유할 수 있다.
12. 9:37
    거버넌스, 신원, 관측성 조직은 단순한 메시지 전달보다 신원 관리와 거버넌스, 그리고 도구 호출까지 포함한 관측성을 요구한다. 분산 환경에서 이 모든 흐름을 추적할 수 있어야만 실제 업무용 에이전트 협업이 성립한다.
13. 10:17
    BAND 소개 BAND는 에이전트 연결에 필요한 레지스트리, 지속성, 채널, 메시지 필터링, 보안, 관측성을 하나의 플랫폼으로 묶어 제공한다. 사람도 여전히 대화에 참여할 수 있으며, 발표는 이후 녹화 데모로 실제 연결 과정을 보여주는 방식으로 이어진다.
14. 11:51
    에이전트 온보딩을 몇 초 만에 서로 다른 사용자 계정에 에이전트를 띄우면 몇 초 안에 플랫폼 안에 에이전트 카드가 생성되고, 서로의 존재를 자동으로 인지하게 된다. 여기서 핵심은 복잡한 설정 없이 새 에이전트를 즉시 네트워크에 편입시킬 수 있다는 점이다.
15. 13:01
    사용자 간 에이전트 연결 상호 동의가 있어야 다른 사용자의 에이전트를 내 개인 에이전트와 연결할 수 있으며, 이후에는 실시간으로 대화 공간에 초대해 협업할 수 있다. 또한 모든 대화는 가시화되어 인간이 개입하고 감시할 수 있는 구조가 유지된다.
16. 14:11
    Claude Code와 Codex의 협업 터미널의 Claude Code 세션을 플랫폼에 연결해 agent card와 신원을 부여하고, 다른 에이전트를 초대해 공동 작업을 수행하게 만든다. 이때 에이전트가 서로 작업을 주고받는 방식이 곧 루프 엔지니어링이며, 네트워크 위치의 복잡성은 플랫폼이 숨긴다.
17. 15:45
    접착 코드 없는 루프 엔지니어링 이제 에이전트들은 별도의 수십만 줄 Python 접착 코드 없이도 서로를 호출하고 검토하며 작은 웹사이트 같은 작업을 함께 수행할 수 있다. 필요하면 사람이 대화 공간에 들어가 보조할 수 있어, 협업과 감독이 동시에 가능한 형태가 된다.

실무 인사이트

• 여러 에이전트를 엮는 핵심은 모델 성능보다 통신 계층 설계이며, 실무에서는 상태 관리와 메시지 순서 보장이 더 큰 병목이 된다.
• 에이전트 협업을 제품화하려면 단순한 툴 호출보다 신원, 동의, 관측성, 권한 통제를 먼저 설계해야 한다.
• 루프 엔지니어링을 반복 스크립트로 해결하려 하기보다, 에이전트 전용 런타임과 상호작용 계층을 두는 편이 확장성과 운영성 측면에서 유리하다.