Agent Room, 코딩 에이전트가 서로 깨우는 작은 방

Agent Room은 거대한 모델 출시가 아닙니다. 새로운 프런티어 LLM도 아니고, 수천 명의 엔터프라이즈 배포 계약도 아닙니다. 하지만 2026년 5월 17일 DEV Community에 올라온 글은 요즘 코딩 에이전트 경쟁에서 놓치기 쉬운 병목을 꽤 정확히 찌릅니다. 문제는 "Claude Code와 Cursor와 Codex가 충분히 똑똑한가"만이 아닙니다. 각 에이전트가 서로의 메시지를 언제 보고, 언제 깨어나며, 어떤 로그를 공유하고, 언제 작업이 끝났다고 판단하는가입니다.

Agent Room 개발자는 자신이 Claude Code와 Cursor 사이에서 context를 복사해 붙여넣는 상황에 지쳤다고 설명합니다. Claude Code agent가 알고 있는 내용이 Cursor agent에는 없고, Cursor가 본 코드 맥락은 Claude Code에 없습니다. 둘 다 MCP를 이해하는 도구인데도, 같은 machine 위에서 서로 말을 못 합니다. 그래서 만든 것이 agent-room-mcp입니다. 방을 만들고, 9자 초대 코드를 공유하고, 여러 agent host가 같은 room에 들어와 메시지를 주고받는 구조입니다.

표면만 보면 채팅방입니다. 그러나 개발자에게 더 중요한 것은 채팅 UI가 아니라 wake-up 구조입니다. Agent Room은 "에이전트끼리 대화한다"는 추상적인 표현을 room_create, room_join, room_send, room_listen, room_export 같은 MCP tools와 hook event로 내립니다. 이 작은 구현은 에이전트 시대의 협업이 결국 모델 prompt가 아니라 runtime protocol, state, presence, transcript, budget의 문제라는 점을 보여줍니다.

MCP 알림은 도착했지만 모델은 모른다

Agent Room 글의 출발점은 MCP notification입니다. Model Context Protocol에는 서버가 클라이언트로 메시지를 밀어 넣는 notifications/message 흐름이 있습니다. 이론적으로는 외부 이벤트를 agent에게 알리기 좋은 표면입니다. 빌드가 끝났습니다. Slack에 새 메시지가 왔습니다. 다른 agent가 room에 답을 남겼습니다. MCP server는 이런 이벤트를 client로 보낼 수 있습니다.

그런데 Claude Code에서는 이 루프가 완전히 닫히지 않는다고 글은 설명합니다. notification은 CLI 프로세스에 도착하고 로그에도 남을 수 있지만, 모델의 다음 turn prompt로 자동 주입되지 않습니다. 사람이 아무 말도 하지 않으면 agent는 그 메시지를 실제 reasoning context로 받지 못합니다. 이는 사소한 구현 차이처럼 보이지만, 비동기 agent 협업에서는 치명적입니다. 다른 agent가 답을 남겼는데, 내 agent가 그 사실을 보지 못한다면 "공유 방"은 그냥 로그 저장소가 됩니다.

가장 단순한 우회로는 polling입니다. agent에게 "계속 room_listen을 호출하고, 메시지가 오면 답하라"고 지시할 수 있습니다. 실제로 Agent Room README도 persistent presence 패턴으로 room_listen loop를 설명합니다. 하지만 이것은 비용과 UX가 나쁩니다. agent가 아무 일도 없는데 turn budget을 태우며 기다립니다. idle 상태의 세션이 계속 도구를 호출합니다. "언제까지 기다릴 것인가"라는 종료 조건도 애매합니다.

Agent Room이 흥미로운 지점은 이 문제를 반대로 뒤집은 데 있습니다. agent가 계속 깨어 있게 하지 않습니다. 기본 상태는 멈춤입니다. 대신 외부 hook이 새 메시지가 있을 때만 agent의 stop을 잠깐 막고 다음 turn을 엽니다. 즉 "agent가 기다리는 구조"가 아니라 "room이 agent를 깨우는 구조"입니다.

Stop hook이 만든 작은 runtime

DEV 글은 Claude Code hook system의 Stop, UserPromptSubmit, SessionStart 이벤트를 사용합니다. Stop은 agent가 turn을 마치고 멈추려는 순간입니다. hook은 shell command를 실행할 수 있고, 특정 JSON을 반환해 stop을 막거나 context를 추가할 수 있습니다. Agent Room의 설정은 대략 이런 모양입니다.

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "npx -y agent-room-mcp hook"
          }
        ]
      }
    ]
  }
}

핵심은 npx -y agent-room-mcp hook입니다. 이 command는 hook event와 session metadata를 읽고, 이 Claude Code session이 참여한 room에 새 메시지가 있는지 확인합니다. 새 메시지가 없다면 agent는 그대로 멈춥니다. 새 메시지가 있다면 hook은 decision: "block"과 함께 메시지 내용을 reason으로 돌려줍니다. 그러면 Claude Code는 stop하지 않고 다음 turn을 열며, agent는 그 reason을 context로 보고 답할 수 있습니다.

여기서 작은 guard가 중요합니다. hook이 stop을 막으면 다음 turn이 생기고, 그 turn이 끝나면 다시 Stop이 발생합니다. 잘못 설계하면 무한 루프가 됩니다. DEV 글은 stop_hook_active 같은 guard를 두어 같은 stop cycle에서 계속 block하지 않도록 한다고 설명합니다. 또 짧은 polling 대신 Redis long-poll을 써서 일정 시간 새 메시지를 기다리되, 아무 일도 없으면 clean stop을 허용합니다.

이것은 대형 orchestration framework가 아닙니다. DAG도 없고, task planner도 없고, 중앙 dispatcher도 없습니다. 오히려 의도적으로 작습니다. 공유 상태는 room transcript와 presence이고, 지능은 각 agent host 안에 남습니다. 그러나 이 작은 구조가 바로 현재 코딩 에이전트 생태계의 현실에 잘 맞습니다. 개발자는 이미 Claude Code, Cursor, Codex, Gemini CLI를 따로 쓰고 있습니다. 각 도구는 자기 세션과 계정, 모델, 승인 UI를 갖고 있습니다. Agent Room은 이들을 하나의 super-agent로 합치는 대신, 같은 방에서 말을 듣게 만듭니다.

Agent Room Protocol v0.1이 말하는 것

GitHub 저장소의 README는 Agent Room을 "AI agents가 협업하는 meeting room"으로 설명합니다. MIT 라이선스이고, 현재 hosted instance는 beta 기간 무료이며, self-host도 가능합니다. 구조는 React web frontend, Vite, Tailwind, Upstash Redis, MCP server, shared package로 이루어져 있습니다. npm 패키지 agent-room-mcp는 확인 시점 기준 0.23.0이고, 2026년 5월 17일에 수정된 metadata가 확인됩니다.

프로토콜 문서도 재미있습니다. Agent Room Protocol v0.1은 2026년 4월 30일 업데이트된 draft로, room lifecycle과 presence, message marker, report artifact를 정의합니다. 방은 XXX-XXX-XXX 형식의 9자 invite code로 식별됩니다. 주요 operation은 create, join, send, listen, list messages, export, end, reactivate입니다. active room state와 message list는 현재 구현에서 24시간 Redis TTL을 가집니다.

presence 계약도 명시되어 있습니다. participant는 name, role, color, initials, client, joinedAt, lastSeenAt, listenUntil 같은 필드를 가집니다. 같은 사람이 web client와 Claude Code client로 동시에 나타날 수 있습니다. listenUntil이 현재 시각보다 뒤면 Listening, 최근 heartbeat가 있으면 Online, 아니면 Idle입니다. 사람용 채팅방에서는 당연해 보이는 presence가 agent 협업에서는 중요합니다. agent가 정말 듣고 있는지, 방금 떠났는지, idle인지 알 수 없으면 다른 agent가 기다려야 할지 결정할 수 없습니다.

또 하나 눈에 띄는 것은 structured marker입니다. Agent Room은 메시지 첫머리에 [DECISION], [TODO], [STATUS], [RESULT]를 붙이면 report artifact로 추출할 수 있다고 정의합니다. 이는 단순 채팅을 deliverable로 바꾸는 장치입니다. 여러 agent가 토론만 하고 끝나면 사람은 다시 요약해야 합니다. 반대로 결정, 할 일, 상태, 결과가 transcript 안에서 구조화되면 room export가 회의록이자 작업 인계 문서가 됩니다.

이 설계는 GitHub issue, Slack thread, Linear comment, PR review와 같은 기존 협업 표면과도 이어질 수 있습니다. Agent Room Protocol v0.1은 enterprise authorization이나 marketplace packaging을 아직 non-goal로 둡니다. 대신 작은 MVP가 실제 customer room에서 필요한 최소 계약을 먼저 정의합니다. 지금 단계에서는 이 절제가 장점입니다. 너무 빨리 workflow platform이 되려 하기보다, 에이전트 협업에서 가장 자주 빠지는 transcript와 wake-up 문제를 먼저 잡습니다.

왜 코딩 에이전트에 방이 필요한가

개발자는 이미 여러 agent를 동시에 씁니다. Claude Code는 터미널에서 강하고, Cursor는 IDE 안에서 편합니다. Codex는 자체 앱과 CLI, 원격 작업 흐름으로 확장되고 있고, Gemini CLI나 다른 MCP host도 특정 작업에 맞을 수 있습니다. 문제는 이 도구들이 서로를 모른다는 점입니다. 한 agent가 조사한 dependency 이슈, 다른 agent가 본 failing test, 세 번째 agent가 작성한 migration plan이 자연스럽게 합쳐지지 않습니다.

지금까지 흔한 해결책은 사람입니다. 사람이 terminal output을 읽고, 다른 창에 붙여넣고, "이 내용을 참고해서 계속해"라고 말합니다. 이 방식은 작동하지만 병목이 명확합니다. 에이전트가 여러 개가 될수록 사람은 개발자가 아니라 switchboard가 됩니다. 어떤 agent가 어떤 사실을 알고 있는지 기억해야 하고, 누가 최신 결정을 따르고 있는지 확인해야 합니다.

Agent Room의 room model은 이 병목을 느슨하게 풀어줍니다. 모든 agent가 같은 transcript에 참여하면, 한 agent의 발견이 다른 agent에게 메시지로 남습니다. 사람도 browser UI로 같은 room에 들어가 지시하거나 결정을 남길 수 있습니다. 중요한 결정은 [DECISION]으로 표시하고, 후속 작업은 [TODO]로 남길 수 있습니다. 물론 이것만으로 완전한 multi-agent software engineering이 되지는 않습니다. 하지만 사람이 수동으로 context를 운반하는 작업은 줄어듭니다.

여기서 핵심은 "agent끼리 자유롭게 떠들게 하자"가 아닙니다. 오히려 Agent Room은 중앙 orchestrator가 아니라 관찰 가능한 메시지 로그입니다. 어떤 agent가 어떤 이유로 결정을 내렸는지 transcript에 남고, host는 room을 end하거나 export할 수 있습니다. 이는 agent collaboration을 magic black box로 만들지 않으려는 설계에 가깝습니다.

MCP의 다음 과제는 tool schema 밖에 있다

MCP는 2025년 이후 AI 도구 연결의 공통 언어처럼 자리 잡았습니다. 파일 읽기, 검색, DB query, GitHub issue, browser control, SaaS API를 agent에게 노출하는 방식이 상당히 정리됐습니다. 하지만 Agent Room 사례는 MCP의 다음 과제가 tool schema 바깥에 있음을 보여줍니다. 도구를 부르는 방법만으로는 충분하지 않습니다. 외부 이벤트가 왔을 때 agent를 깨우는 방법, agent가 idle일 때 메시지를 보관하는 방법, 여러 client의 presence를 표현하는 방법, conversation을 report로 바꾸는 방법이 필요합니다.

이 차이는 실제 제품에서 큽니다. 예를 들어 CI가 실패했다고 합시다. MCP server가 "빌드 실패" notification을 보낼 수 있어도, agent host가 이를 모델 context로 전달하지 않으면 agent는 대응하지 못합니다. 반대로 agent가 계속 polling하게 만들면 비용과 noise가 커집니다. hook, long-poll, cursor, transcript, idle timeout 같은 runtime 설계가 필요합니다. Agent Room은 이 지점을 코드 몇 줄의 trick처럼 보여주지만, 사실은 agent platform이 제공해야 할 기본 기능 목록에 가깝습니다.

Cursor 1.7 이상은 stop hook shape이 다르고, Claude Code는 decision: "block"과 additionalContext를 사용합니다. Codex, Gemini, Windsurf도 각자 설정 파일과 event model이 다릅니다. 즉 MCP가 도구 호출의 표준이어도, agent host의 lifecycle은 아직 표준화되어 있지 않습니다. Agent Room이 여러 client를 감지하고 설정을 설치하려는 이유도 여기에 있습니다. agent interoperability는 protocol 하나로 끝나지 않고, host별 lifecycle adapter를 요구합니다.

작지만 중요한 오픈소스 신호

Agent Room은 아직 작은 프로젝트입니다. GitHub star도 대형 오픈소스와 비교할 수준이 아니고, Reddit 반응도 폭발적이지 않습니다. 어떤 사용자는 유사 프로젝트와의 차이를 묻고, 어떤 사용자는 그냥 각 agent의 폴더에 unread 파일을 두는 방식도 충분하다고 말합니다. 이 비판은 타당합니다. 모든 팀에 hosted room이나 Redis backend가 필요한 것은 아닙니다. local-first 파일 inbox, Slack channel, GitHub issue comment, Bot2Bot 같은 다른 도구가 더 맞는 경우도 있습니다.

그럼에도 이 프로젝트가 뉴스 가치가 있는 이유는 해결하려는 문제가 반복적으로 나타나기 때문입니다. 최근 devlery가 다룬 Codex 모바일 통제, GitHub Copilot agent sessions, Cursor cloud agent, Coder Agents, UiPath coding agents는 모두 다른 층에서 같은 질문을 던졌습니다. agent가 돌아가는 동안 사람과 다른 시스템은 어떻게 상태를 보고, 개입하고, 결과를 감사할 것인가. Agent Room은 그 질문을 더 작고 날것의 개발자 환경으로 가져옵니다. 두 terminal과 한 IDE 사이에서 context를 어떻게 운반할 것인가입니다.

또 하나의 의미는 hook의 재발견입니다. AI agent 제품은 종종 모델 능력을 전면에 내세우지만, 실제 workflow를 바꾸는 것은 이런 작은 lifecycle hook일 때가 많습니다. Stop 순간에 무엇을 할 수 있는가. user prompt가 들어오기 전에 어떤 context를 주입할 수 있는가. session start 때 놓친 메시지를 요약할 수 있는가. 이런 hook은 agent를 더 똑똑하게 만들지는 않지만, 더 잘 연결되게 만듭니다. 에이전트가 실제 개발팀 workflow에 들어가려면 이 연결성이 모델 점수만큼 중요합니다.

기업용 에이전트 협업으로 가면 더 어려워진다

개인 개발자의 Agent Room은 비교적 단순합니다. 방을 만들고, agent를 초대하고, 메시지를 공유합니다. 하지만 이 아이디어가 기업용으로 확장되면 문제가 빠르게 늘어납니다. 누가 room을 만들 수 있는가. 어떤 repo의 agent가 어떤 room에 들어갈 수 있는가. transcript는 어디에 저장되고 얼마나 오래 보관되는가. 고객 코드나 secret이 room message에 들어가면 어떻게 마스킹할 것인가. agent가 잘못된 [DECISION]을 남겼을 때 누가 승인할 것인가.

Agent Room Protocol v0.1은 enterprise authorization을 non-goal로 둡니다. 이것은 현재 프로젝트 범위에서는 합리적입니다. 그러나 시장 전체로 보면 바로 이 영역이 다음 경쟁 지점입니다. GitHub, Cursor, OpenAI, Anthropic, Coder, Atlassian, Slack 같은 회사들은 agent transcript와 approval, audit log를 자사 협업 표면에 붙이려 할 것입니다. 작은 오픈소스 room이 보여주는 실험은 나중에 더 큰 플랫폼의 기본 기능이 될 수 있습니다.

개발팀은 이 흐름을 볼 때 두 가지를 구분해야 합니다. 첫째, agent끼리 메시지를 주고받게 하는 것은 쉽습니다. 둘째, 그 메시지가 업무 기록과 권한 체계 안에서 신뢰 가능한 산출물이 되게 하는 것은 어렵습니다. Agent Room의 [DECISION], [TODO], [RESULT] marker는 두 번째 문제를 향한 작은 시작입니다. 실제 조직에서는 여기에 approver, issue binding, PR link, retention policy, redaction, permission boundary가 붙어야 합니다.

지금 개발자가 가져갈 실무 포인트

Agent Room을 당장 도입해야 한다는 말은 아닙니다. 프로젝트는 빠르게 움직이는 beta이고, hosted instance의 운영 신뢰성이나 보안 모델을 기업 업무에 바로 적용하기는 이릅니다. 그러나 이 발표는 agent workflow를 설계하는 개발자에게 몇 가지 점검표를 줍니다.

첫째, agent에게 외부 이벤트를 어떻게 전달하는지 확인해야 합니다. MCP server가 notification을 보낸다는 사실만으로는 부족합니다. 그 notification이 실제 model context로 들어가는지, UI에만 보이는지, log에만 남는지 확인해야 합니다. 둘째, polling 비용을 계산해야 합니다. agent가 기다리는 구조는 간단하지만, turn budget과 token 비용, rate limit을 태울 수 있습니다. 셋째, transcript와 artifact를 분리해야 합니다. 모든 메시지는 로그로 남기되, 결정과 할 일은 구조화되어야 합니다.

넷째, host별 lifecycle 차이를 인정해야 합니다. Claude Code, Cursor, Codex, Gemini CLI는 같은 MCP 도구를 써도 turn boundary, hook output, 설정 파일, notification 처리 방식이 다를 수 있습니다. agent interoperability를 만들려면 model abstraction보다 host adapter가 더 많은 시간을 먹을 수 있습니다. 다섯째, 사람의 역할을 제거하지 말고 명확히 해야 합니다. Agent Room의 web UI는 사람이 같은 room에 들어가는 경로입니다. 좋은 multi-agent workflow는 사람을 없애는 것이 아니라, 사람이 승인과 방향 전환을 할 위치를 분명히 둡니다.

결국 Agent Room은 작은 방입니다. 그러나 그 방이 보여주는 문제는 작지 않습니다. 코딩 에이전트가 늘어날수록 사람은 더 많은 context를 손으로 나르기 어렵습니다. MCP는 도구 연결을 열었지만, agent를 깨우고, presence를 보여주고, transcript를 산출물로 바꾸는 runtime은 아직 각 도구가 따로 만들고 있습니다. Agent Room의 Stop hook trick은 이 빈틈을 우회하는 작은 구현입니다. 동시에 코딩 에이전트 플랫폼들이 앞으로 기본으로 제공해야 할 기능의 미리보기이기도 합니다.

에이전트 협업의 다음 단계는 "한 모델이 모든 일을 한다"가 아닐 가능성이 큽니다. 여러 agent host가 각자 강한 표면에서 일하고, 같은 room이나 issue, PR, incident thread를 통해 상태를 공유하는 쪽에 가깝습니다. 그때 중요한 질문은 모델이 얼마나 말을 잘하는가가 아니라, 메시지가 누구에게 언제 도착하고, 누가 깨어나며, 어떤 결정이 기록으로 남는가입니다. Agent Room은 바로 그 질문을, 아주 작은 MCP room과 hook command로 눈앞에 가져왔습니다.