Your Agents Are in Solitary Confinement: Why MCP & A2A Aren't Enough — Vlad Luzin, Band

한 줄 핵심

이 영상은 에이전트 시대의 핵심 문제가 MCP나 A2A가 아니라 분산 시스템으로서의 AI-to-AI 통신이며, 이를 해결하는 전역 협업 레이어로 Band를 제시한다.

시간별 요약

1. 0:00
   Band의 핵심 주장: 미래는 AI 간 통신 기업 내부와 기업 간, 그리고 소비자와 기업 사이의 일은 에이전트가 맡게 되며, 이 에이전트들은 서로 다른 프레임워크·언어·환경에 배포된 상태로 상호 통신해야 한다. 따라서 미래의 핵심은 단일 에이전트의 성능이 아니라 AI-to-AI 커뮤니케이션이다.
2. 1:29
   에이전트 협업의 모습 에이전트들은 인간의 개입 없이 대화 공간을 만들고, 인간이나 다른 시스템으로부터 받은 작업을 다른 에이전트를 초대해 함께 해결한 뒤 결과를 다시 보고하는 흐름으로 동작한다. 협업의 기본 단위는 단일 호출이 아니라 참여자 기반의 대화 공간이다.
3. 2:04
   적대적 에이전트: 결국 라우터가 된다 개발자는 이미 여러 Claude나 코딩 세션을 오가며 작업과 리뷰를 중계하는 라우터 역할을 하고 있다. 서로 상태를 가진 에이전트들이 직접 대화하지 못하면 사람이 프롬프트를 복사해 전달하는 중개자가 될 수밖에 없다.
4. 2:49
   루프 엔지니어링의 핵심 핵심은 사람이 에이전트 사이의 라우터가 되는 대신, 에이전트들이 서로에게 직접 프롬프트를 전달하고 협업 루프를 형성하게 만드는 것이다. 이 문제는 Python, TypeScript, 각종 추상화 계층을 통해 에이전트 상호작용을 설계하는 단계로 넘어간다.
5. 3:34
   단일 에이전트의 병목 여러 세션과 여러 문제를 동시에 다루는 현실에서는 한 에이전트만으로는 충분하지 않고, 사람의 중계 비용이 급격히 커진다. 따라서 단일 에이전트 최적화보다 다중 에이전트 협업 구조가 더 중요한 병목이 된다.
6. 4:04
   메시징 플랫폼이 에이전트에 실패하는 이유 MCP나 A2A처럼 에이전트를 도구나 클라이언트-서버로 연결하는 방식은 상태 유지, 재시도, 큐, 발견(discovery) 같은 실질적인 운영 문제를 해결하지 못한다. 결국 메시지 계획과 플로우를 사람이 떠안게 되어, 진짜 멀티 에이전트 시스템이 아니라 수작업 오케스트레이션이 된다.
7. 5:33
   왜 MCP와 A2A가 답이 아닌가 Telegram, Discord, Slack, WhatsApp 같은 채널에 에이전트를 붙이는 일은 단계가 많고 대부분 수동이며, 결과적으로 에이전트가 사람과만 대화하는 고립된 상태에 머문다. 여러 에이전트가 서로를 볼 수도 없고 통신도 못 하는 상태는 디지털 독방과 같다.
8. 7:08
   멀티 에이전트는 이미 현실이다 로컬의 두 세션부터 cloud, Lambda, Salesforce, Databricks, SAP, Codex까지 에이전트를 연결하는 일은 이미 일상적인 문제이며, 미래의 상상도가 아니라 현재의 통합 과제다. 서로 다른 시스템을 연결하는 난이도는 생각보다 훨씬 높다.
9. 7:43
   분산 시스템 문제다 원격에 있는 여러 에이전트가 협업하는 구조는 본질적으로 비결정적인 마이크로서비스들로 이루어진 분산 시스템이다. 그래서 메시지 전달, 재시도, 실시간성, 지속성 같은 분산 시스템의 기본 문제가 먼저 해결되어야 한다.
10. 8:17
    전송, 지속성, 런타임 바인딩 순서 보장된 전달과 실시간 전달, 재시도 같은 전송 계층이 필요하고, 프로세스 크래시를 고려한 상태 지속성과 복구도 필요하다. 또한 thread ID, conversation ID, execution ID를 서로 매핑하는 런타임 바인딩이 있어야 다른 프레임워크의 에이전트가 실제로 상호작용할 수 있다.
11. 9:12
    새로운 추상화, 신원, 관측성 IP 포트나 URL, pub-sub 수준으로는 충분하지 않으며, 대화방과 채널, 참여자 같은 더 높은 추상화가 필요하다. 여기에 더해 거버넌스, 신원, 감사 추적 같은 운영 계층까지 갖춰야 에이전트 협업이 안전하게 굴러간다.
12. 10:17
    Band 소개: 에이전트를 위한 전역 상호작용 계층 Band는 다양한 프레임워크와 배포 환경의 에이전트를 하나로 연결하는 글로벌 협업 레이어로 제시된다. 프로그램적 등록, 온보딩, 연결 요청, 양방향 동의, 초대와 메시지 교환 같은 협업의 기본 프리미티브를 제공한다.
13. 11:27
    데모 1: Codex, LangGraph, 개인 에이전트 온보딩 Jam 데스크톱 앱을 통해 로컬 에이전트를 플랫폼에 올리고, routing, context overload, 비용 관리, 기여도 추적을 한 번에 다룬다. 에이전트가 작업 중인 소프트웨어 구조와 담당 컴포넌트를 실시간으로 보여 주고, 필요하면 다른 사람의 에이전트까지 대화에 합류시킬 수 있다.
14. 14:11
    데모 2: Claude Code와 Codex의 협업 Claude Code와 Codex 같은 여러 인스턴스가 PRD, SRS, 구현 작업을 함께 수행하며, 별도의 Python 루프를 손으로 작성하지 않아도 메시징 플랫폼 위에서 자연스럽게 협업한다. 관리자는 토큰 비용, 사용자 체인 비용, 역할별 기여도, 진행 상태를 실시간으로 확인할 수 있다.
15. 16:20
    마무리 목표는 추가 패키지와 복잡한 접착 코드를 대량으로 붙이지 않고도 Salesforce, Slack, Databricks, Cloud, Codex 같은 시스템이 함께 일하는 환경을 만드는 것이다. Band와 Jam은 그 미래를 실시간 협업, 권한 제어, 작업 가시성까지 포함한 제품으로 구현하려는 시도다.

실무 인사이트

• 에이전트 협업의 핵심은 모델 성능보다 상태·전달·지속성을 포함한 통신 인프라에 있으며, 사람의 복사-붙여넣기 중계는 임시방편일 뿐이다.
• MCP나 A2A 같은 연결 방식만으로는 멀티 에이전트 운영이 완성되지 않으므로, 실무에서는 discovery, persistence, audit, 권한까지 포함한 상위 계층을 함께 설계해야 한다.
• 팀 차원에서는 에이전트가 무엇을 했는지, 누가 관여했는지, 비용이 어떻게 분배됐는지를 실시간으로 보는 관측성 체계를 먼저 갖춰야 협업을 확장할 수 있다.