qm - 조직 단위로 굴리는 멀티플레이어 에이전트 하네스

🏷️ 정보 오픈소스 도구 에이전트

이 글은 qm을 참고하여 작성했습니다.

지금 나오는 에이전트 하네스는 거의 전부 1인용입니다. 내 터미널, 내 저장소, 내 메모리 파일. qm은 회사 전체에 에이전트를 까는 것을 전제로 설계된 하네스입니다.

2026년 7월 31일 공개되어 Hacker News 635포인트, GitHub 4.5k 스타를 받았습니다.

1인용을 복제하면 깨지는 것

에이전트 하네스 하나를 팀원 수만큼 복제해서 쓰면 되지 않느냐는 생각이 먼저 듭니다. 세 가지가 깨집니다.

메모리 충돌. 에이전트 메모리는 대개 "이 프로젝트는 이렇게 돌아간다"는 사실을 누적합니다. 그런데 백엔드 담당자와 디자이너에게 같은 사실이 참이 아닙니다. 한 저장소에 메모리를 공유하면 서로의 맥락이 상대의 답변을 오염시킵니다. 완전히 분리하면 이번엔 팀 공통 지식이 사람 수만큼 중복 축적됩니다.

권한 누수. 1인용 하네스는 실행 주체와 권한 주체가 같습니다. 내 자격증명으로 내가 돌립니다. 조직에서는 이게 성립하지 않습니다. 에이전트가 A의 요청으로 B만 접근 가능한 저장소를 읽으면, 요청자는 A인데 권한은 하네스가 가진 것입니다.

추적 불가. 사고가 났을 때 누구의 요청으로 어떤 도구가 실행됐는지 되짚을 수 없으면 조직에서 쓸 수 없습니다.

qm의 스코프(scope) 개념은 이 세 문제에 대한 답입니다. 사람마다, 방마다 스코프가 생기고 그 스코프마다 메모리, 파일, 권한, 지속 샌드박스가 따로 붙습니다. 개인 스코프에서 독립적으로 일하다가 공용 채널과 프로젝트에서 협업합니다.

구조

가운데에 헤드리스 코어 하나가 있습니다. TypeScript와 Node.js, Fastify 조합입니다. 여기에 네 가지가 매답니다.

설계 원칙은 한 문장으로 정리돼 있습니다. 모든 기반(substrate)은 인터페이스 뒤에 둔다는 것입니다. 코어를 건드리지 않고 프로덕션 구성 요소를 교체할 수 있게 하는 것이 목표입니다.

기능은 조직 운영에 필요한 것들이 붙어 있습니다. Slack과 웹에서 동일 신원, 관리자가 보안 태세와 모델 선택을 통제, 크론과 와치로 백그라운드 작업, 스킬은 스코프가 소유하고 공유 가능.

지속 샌드박스의 비용

스코프마다 지속 샌드박스를 주는 설계는 격리를 확실히 하지만 비용이 정직하게 붙습니다.

50명 조직이면 개인 스코프 50개에 방 스코프까지 더해 샌드박스가 수십에서 백 개 단위로 늘어납니다. 지속(durable)이라는 것은 세션이 끝나도 파일 시스템 상태가 남는다는 뜻이므로 디스크도 계속 점유합니다. 컨테이너를 상시 띄워 두는지 요청 시 복원하는지에 따라 운영 비용이 크게 갈립니다.

Postgres에 세션과 메모리를 올린 선택도 봐야 합니다. 에이전트 세션은 쓰기가 잦고 긴 컨텍스트를 다룹니다. 조직 전체가 동시에 쓰면 세션 상태 갱신이 핫 패스가 됩니다. 다만 이 선택에는 분명한 이득이 있습니다. 트랜잭션과 백업, 감사 로그를 공짜로 얻습니다. 앞서 말한 추적 불가 문제를 푸는 데 파일 기반 메모리보다 훨씬 유리합니다.

진짜 베팅은 하네스 플러그인

qm에서 가장 중요한 설계 판단은 스코프가 아니라 하네스를 플러그인으로 뺀 부분이라고 봅니다.

에이전트 도구 시장은 6개월마다 바뀝니다. 작년에 쓰던 하네스가 올해 최선이 아니고, 모델도 마찬가지입니다. 이 판에서 도구를 조직에 도입한다는 것은 6개월 뒤 갈아엎을 각오를 하거나 갈아끼울 수 있게 짓거나 둘 중 하나입니다.

qm은 후자를 택하고 무엇을 고정할지 명시했습니다. 고정하는 것은 스코프, 신원, 권한, 메모리, 감사입니다. 갈아끼우는 것은 하네스, 모델, 표면입니다.

이 구분은 합리적입니다. 조직이 실제로 축적하는 자산은 "어떤 에이전트를 썼는가"가 아니라 "누가 무엇에 접근할 수 있고 무엇을 알고 있는가"입니다. 앞의 것은 소모품이고 뒤의 것은 인프라입니다.

Slack 표면의 양면

Slack을 1급 표면으로 삼은 것은 채택 측면에서 영리합니다. 새 도구를 설치하게 만드는 것보다 이미 쓰는 곳에 들어가는 편이 훨씬 쉽습니다. 스레드가 그대로 대화 이력이 되고, 채널이 그대로 공용 스코프가 됩니다.

동시에 두 가지가 같이 커집니다.

관측 가능성이 좋아집니다. 에이전트가 무엇을 했는지가 사람들이 이미 보고 있는 채널에 남습니다. 별도 감사 UI를 만들지 않아도 팀이 서로의 에이전트 활동을 봅니다.

프롬프트 인젝션 표면도 같이 커집니다. Slack 채널은 외부 연동, 게스트 계정, 자동 알림봇, 붙여넣은 문서가 흘러드는 곳입니다. 에이전트가 채널 내용을 읽고 도구를 실행하는 구조라면 그 채널에 글을 남길 수 있는 누구나 간접 프롬프트 인젝션 경로를 가집니다. 프롬프트 인젝션이 개인 하네스에서는 내가 붙여넣은 문서 정도가 벡터였다면, 조직 채널에서는 훨씬 넓어집니다.

관리자가 보안 태세를 통제한다는 기능이 이 지점을 겨냥한 것으로 보이는데, 실제로 채널 콘텐츠를 신뢰 경계로 어떻게 다루는지는 도입 전에 확인해야 할 항목입니다.

정리

qm이 던지는 질문은 "어떤 에이전트가 더 똑똑한가"가 아니라 "에이전트를 조직에 어떻게 배치하는가"입니다. 후자는 지금까지 각 회사가 사내 스크립트로 얼기설기 풀던 문제였습니다.

스코프를 1급 개념으로 올리고 하네스를 소모품으로 취급한 구조는 이 문제를 제대로 본 결과라고 봅니다. 도입을 검토한다면 확인할 것은 세 가지입니다. 스코프당 샌드박스 자원 소모, 채널 콘텐츠에 대한 신뢰 경계 처리, 그리고 하네스 인터페이스가 실제로 얼마나 얇은지입니다. 마지막 항목이 두꺼우면 "갈아끼울 수 있다"는 약속이 지켜지지 않습니다.

이 글은 qm 저장소의 관점에서 작성되었습니다.