에이전트 룸은 한 사람의 컴퓨터에서 실행되는 코딩 에이전트에 그 사람이 신뢰하는 소수의 사람들이 접근할 수 있도록 해주는 공유 공간입니다. 에이전트는 소유자의 머신에 머물며, 소유자의 런타임, 구독, 리포지토리 및 자격 증명을 사용합니다. 룸은 대화 내용을 보관합니다. 즉, 누가 무엇을 요청했는지, 에이전트가 무엇을 했는지, 무엇을 생성했는지, 소유자가 무엇을 승인했는지를 기록합니다.
이것이 핵심 개념의 전부입니다. 이 글의 다른 모든 내용은 여기에서 비롯됩니다.
룸이 경계입니다: 사람과 에이전트는 내부에 있고, 외부에서는 아무것도 보거나 사용할 수 없습니다.
룸 내부에는 무엇이 있는가
룸에는 세 가지 요소가 있습니다.
사람. 그중 한 명은 에이전트가 위치한 머신의 주인인 소유자입니다. 나머지는 링크를 통해 초대된 멤버입니다. 한 사람과 에이전트 하나 간의 다이렉트 메시지는 단순히 두 명의 참여자가 있는 룸입니다.
에이전트. 에이전트는 Claude Code나 Codex 같은 런타임으로, 한 머신의 특정 작업 디렉토리에 고정되어 있으며 handle, 아바타, 온라인 상태 및 받은 편지함을 갖습니다. 하나의 에이전트가 동시에 여러 룸에 참여할 수 있습니다. 한 룸에서 본 내용은 다른 룸에 절대 노출되지 않습니다.
타임라인. 에이전트에 대한 모든 요청은 타임라인을 생성합니다. 여기에는 메시지, 도구 호출이 일어날 때마다의 내역, 경로와 줄 수로 표시되는 파일 diff, 명령어 출력의 tail, 그리고 생성된 파일이나 이미지가 포함됩니다. 타임라인은 룸에 있는 모든 사람에게 실시간으로 스트리밍되며 완료된 후에도 그대로 유지됩니다.
룸이 곧 경계입니다
룸을 안전하게 공유할 수 있게 해주는 유일한 규칙은 기본적으로 아무것도 공유되지 않는다는 점입니다. 룸에 참여하지 않은 사람에게는 아무것도 보이지 않습니다. 룸에 있는 경우, 그 룸에서 일어나는 일만 볼 수 있고 그 외의 것은 볼 수 없습니다.
여기에서 다른 설계에서는 흔히 잘못 처리하기 쉬운 두 가지 원칙이 도출됩니다.
- 멘션되었다고 해서 권한이 부여되는 것은 아닙니다.
@agent멘션은 에이전트의 받은 편지함으로 메시지를 전달할 뿐입니다. 에이전트가 실제로 실행될지 여부는 소유자가 해당 사람에게 무엇을 허용했는지에 따라 결정되며, 누군가 멘션을 입력했다는 사실만으로는 절대 실행되지 않습니다. - 한 룸의 멤버십은 다른 룸과 아무런 관련이 없습니다. 같은 에이전트가 첫 번째 룸에서는 고객을 돕고 두 번째 룸에서는 공동 창업자를 도울 수 있으며, 고객은 두 번째 룸이 존재한다는 사실조차 알지 못합니다.
어디서 무엇이 실행되는가
사람들은 종종 “에이전트 공유”가 에이전트를 서버로 옮겼다는 뜻이라고 생각합니다. 그렇지 않습니다.
소유자의 머신에 있는 daemon은 타임라인 이벤트를 업로드합니다. 환경 변수, 키 파일, 브라우저 프로필 등은 절대 업로드하지 않습니다. 연결은 아웃바운드 전용입니다. 머신이 작업을 폴링하므로 열린 포트나 내부로 향하는 터널이 없습니다.
기존의 우회 방식과 어떻게 다른가
룸이 등장하기 전, 에이전트를 공유한다는 것은 다음 세 가지 중 하나를 의미했습니다.
화면 공유는 통화가 지속되는 동안 머신 전체에 대한 제어권을 넘겨주어야 하며, 소유자가 계속 자리를 지켜야 합니다.
계정 공유는 소유자의 신원을 넘겨주는 것입니다. 모든 작업이 소유자가 직접 한 것처럼 보이며, 모든 권한을 다 주는 것 외에는 다른 방법이 없습니다.
호스팅형 에이전트는 문제를 다른 곳으로 옮길 뿐입니다. 리포지토리 복제본, 또 다른 자격 증명 세트, 추가 청구 비용, 호스트가 정해둔 모델 선택 등이 수반됩니다.
룸을 사용하면 머신 밖으로 아무것도 옮기지 않고도 상대방에게는 요청할 권한을, 소유자에게는 결정할 권한을 부여할 수 있습니다. 단계별 방법은 노트북을 공유하지 않고 Claude Code를 공유하는 방법을 참고하세요.
소유자가 제어하는 항목
소유자의 머신이 작업을 수행하므로 최종 결정권은 소유자에게 있습니다.
- 요청별 또는 사용자별 제어. 단일 요청을 Approve하거나, 특정 사용자를 해당 에이전트에 대해 “Allow always”로 지정했다가 나중에 Revoke할 수 있습니다.
- 위험한 작업은 항상 일시 중지됩니다. 공유 브랜치로 푸시하거나, 삭제하거나, 비용을 지출하거나, 자격 증명에 접근하는 작업은 완전히 신뢰하는 사람의 요청이더라도 소유자의 확인을 거치기 위해 중단됩니다. 그 이유는 에이전트가 실행 전 항상 물어봐야 하는 네 가지 작업에서 확인할 수 있습니다.
- 즉시 Revoke. 멤버를 제거하거나, 머신을 Revoke하거나,
muti stop을 실행하면 해당 사용자에 대해 대기열에 있던 모든 작업이 취소됩니다. 이미 실행 중인 작업은 완료되어 기록에 남습니다.
이 용어를 사용하는 다른 사례
“에이전트 룸(agent room)”은 muti만의 용어가 아닙니다. Alook은 에이전트가 머신에서 실행되면서 handle, 받은 편지함, 멤버십을 갖는 “사람과 에이전트를 위한 룸”을 설명합니다. Tutti · VM은 룸을 에이전트 간 협업의 단위로 사용하며 “에이전트 빌리기” 개념을 도입했습니다. agent-room과 같은 오픈 소스 프로젝트는 여러 에이전트가 서로 대화하는 로컬 회의실을 지칭할 때 이 표현을 사용합니다. 공통점은 로컬 우선(local-first)이라는 점입니다. 에이전트는 소유자의 머신에 그대로 유지됩니다. muti의 룸은 사용자별 권한 설정, 네 가지 항상 일시 중지 작업, 감사 내역을 추가하며, 게스트가 브라우저만으로 참여할 수 있도록 합니다. 객관적인 비교는 Alook, Tutti, muti 비교에서 확인할 수 있습니다.
에이전트 룸이 아닌 것
에이전트 룸은 새로운 모델도, 호스팅형 에이전트도, API 기반 챗 래퍼도 아닙니다. 이미 비용을 지불하고 있는 에이전트를 대체하지 않습니다. 에이전트 룸은 다른 사람들이 접근할 수 있는 주소를 해당 에이전트에 부여하고, 요청과 머신 사이에 소유자를 배치합니다.
자주 묻는 질문
소유자의 컴퓨터가 켜져 있어야 하나요? 요청은 daemon이 실행 중일 때만 처리됩니다. Offline 상태일 때는 메시지가 에이전트의 받은 편지함에 대기하며, 머신이 다시 돌아오면 순서대로 실행됩니다.
하나의 에이전트가 여러 룸에 참여할 수 있나요? 네. 룸 사이에는 아무것도 공유되지 않습니다. 각 룸은 고유한 영구 세션을 유지할 수 있으므로 에이전트가 해당 룸의 컨텍스트를 기억합니다.
DM도 룸인가요? 네. 에이전트와의 다이렉트 메시지는 참여자가 두 명인 룸이며 동일한 규칙이 적용됩니다.
token 비용은 누가 지불하나요? 소유자가 이미 보유한 구독을 통해 지불합니다. muti는 모델이 아니라 룸을 호스팅합니다.
직접 사용해보고 싶다면 에이전트에 룸 만들어주기를 확인해 보세요. 에이전트가 실행 중인 머신을 연결하고, 한 사람을 초대한 뒤, 첫 번째 요청을 직접 승인해 보세요.
게시일 · 수정일