QM: 팀원마다 격리된 작업공간을 갖는 슬랙과 웹 기반 멀티플레이어 AI 에이전트

9bow · 8월 4, 2026, 3:30오전

QM 소개

에이전트를 회사 업무에 들이는 일은 보통 봇 계정 하나를 슬랙에 초대하는 것으로 시작합니다. 그 계정이 열 명, 스무 명의 요청을 동시에 받기 시작하면 곤란한 상황이 이어집니다. 누군가 프롬프트를 손보면 다른 사람의 작업 방식이 함께 바뀌고, 한 사람이 연결해 둔 서비스 자격증명을 전원이 공유하게 되며, 지난 대화에서 쌓인 기억이 엉뚱한 사람의 요청에 섞여 들어갑니다. QM 개발팀은 이 지점을 "대부분의 에이전트는 개인 비서처럼 설계되어 있어서, 회사 전체가 쓰도록 만들 수는 있지만 금세 복잡해진다" 라는 문장으로 정리하고 있습니다.

QM은 그 복잡도를 스코프(scope) 단위 격리 로 푸는 업무용 멀티플레이어 에이전트 하니스(harness)입니다. 구성원은 각자 격리된 작업공간을 받아 서로 영향을 주지 않고 독립적으로 일하다가, 필요할 때는 슬랙 채널과 그룹 메시지, 프로젝트 안에서 같은 에이전트와 함께 작업합니다. 사람 하나하나와 대화방 하나하나가 자기만의 기억, 파일, 키체인 뷰, 권한, 크론(cron), 웹 앱, 그리고 재사용되는 샌드박스(sandbox)를 따로 가지는 구조입니다.

설계에서 눈에 띄는 또 하나는 하니스와 모델을 고정하지 않았다는 점입니다. Pi, OpenCode, Codex, Claude Code가 모두 동일한 코어를 구동하기 때문에, 한 번 배포한 환경이 특정 공급사에 묶이지 않습니다. 코어는 Node 위에서 TypeScript를 그대로 실행하고 HTTP 처리에 Fastify를 쓰며, 슬랙 플러그인은 Bolt를, 웹 UI는 Vite로 빌드해 Lit으로 렌더링합니다. 저장소는 yc-software 조직이 2026년 7월 말 공개했고, 공식 홈페이지는 qm.ycombinator.com 주소를 쓰고 있으며, 현재 배포판은 v0.1.4입니다.

개인 비서형 에이전트와 QM의 차이

조직에서 에이전트 하나를 공용으로 돌릴 때 생기는 문제와, QM이 같은 상황을 어떻게 다루는지를 나란히 두면 설계 의도가 분명해집니다. 아래 표의 왼쪽은 QM 개발팀이 기존 방식의 한계로 지목한 지점이고, 오른쪽은 저장소 문서에서 확인되는 QM의 대응입니다.

항목	공용 비서 하나를 조직 전체가 사용	QM의 접근
설정 단위	조직 전체가 같은 설정을 공유	사람과 대화방마다 별도 스코프
기억과 파일	하나의 저장소에 누적	스코프별 기억, 파일, 키체인 뷰 분리
실행 환경	공용 실행 환경	스코프 전용 샌드박스에서 `execute` 도구로 실행
모델과 하니스	도입 시점의 선택에 고정	Pi, OpenCode, Codex, Claude Code 중 선택 및 교체
접근 표면	대개 한 가지 채널	슬랙과 웹에서 동일한 신원과 설정 사용

특히 샌드박스는 일회성 컨테이너가 아니라 스코프가 계속 쓰는 컴퓨터에 가깝습니다. 한 번 설치한 도구가 다음 세션에도 그대로 남아 있어서, 사용자가 매번 환경을 다시 만들 필요가 없습니다.

QM은 누구에게 유용한가

QM은 슬랙을 이미 쓰고 있고 Fly나 AWS 계정에 직접 배포할 수 있는 팀에 맞습니다. 배포가 운영 주체의 클라우드 계정에서 이뤄지고 조직 설정과 보안 태세를 관리자가 직접 정하는 구조라, 사내 데이터를 외부 서비스에 넘기지 않으려는 스타트업이 주된 대상입니다. 반대로 노트북에서 혼자 쓸 코딩 도구를 찾고 있다면 QM은 과한 선택이고, Pi나 OpenCode, Claude Code 같은 하니스를 단독으로 쓰는 편이 간단합니다. v0.1.x 단계이고 저장소가 공개된 지 얼마 지나지 않았다는 점도 도입 시점을 정할 때 함께 고려할 부분입니다.

QM의 계층 구조

모든 대화 턴은 중앙의 헤드리스 코어(headless core)를 통과합니다. 코어는 API와 신원, 정책, 스케줄러를 담당하면서 에이전트 루프와 짝을 이루고, 이 루프가 여러 모델과 하니스를 골라 응답을 만듭니다. 사용자 데이터와 세션 기록, 그 밖의 지속 상태는 Postgres 영속 계층이 보관합니다.

에이전트가 쥔 도구 표면은 작고 고정되어 있습니다. 그중 하나인 execute 가 스코프 전용 샌드박스에서 명령을 실행하는 통로입니다. 웹 UI와 관리자 패널, 공개 포털은 코어의 HTTP API 위에 얹히는 선택적 플러그인이고, 슬랙은 코어가 직접 기동하고 감독하는 인프로세스 플러그인으로 붙습니다.

코어 자체는 특정 회사에 종속되지 않는 일반 코드로 유지됩니다. 조직 설정, 커스텀 도구와 스킬, 샌드박스 이미지, 인프라처럼 한 회사에만 해당하는 것은 모두 배포 디렉토리(deployment directory) 에 모이고, qm CLI 가 그 디렉토리를 검증한 뒤 배포합니다. 하니스, 세션 저장소, 샌드박스, 기억 같은 기반 요소가 각각 인터페이스 뒤에 있어서, 운영용 구현체는 배선 파일 하나로 갈아 끼울 수 있습니다.

QM의 작업 화면과 주요 기능

웹 UI는 동시에 진행되는 여러 세션과 함께 개인 파일, 크론, 키체인, 배포, 기억, 스킬을 사이드바에 모아 둡니다. 같은 신원과 설정이 슬랙과 웹 사이를 그대로 따라다니기 때문에, 채널에서 시작한 작업을 웹에서 이어받는 흐름이 끊기지 않습니다.

기능은 크게 다섯 갈래로 정리됩니다.

개인 스코프와 공유 스코프: 사용자가 에이전트를 자기 방식대로 길들이면서도, 슬랙 채널과 프로젝트에서는 같은 에이전트와 협업합니다.
관리자 제어: 조직 수준 설정과 보안 태세, 사용 가능한 하니스와 모델 목록을 관리자가 정합니다.
웹 앱: 사내용 앱을 만들어 필요한 사람에게만 게시할 수 있습니다.
공유 스킬: 스킬은 스코프가 소유하고 부여(grant)를 통해 공유되며, 조직 전체로 승격하려면 관리자 승인을 거칩니다. Git 저장소에서 스킬 팩을 가져오는 것도 가능합니다.
백그라운드 작업: 크론과 워치(watch)가 아무도 보지 않는 동안 작업을 진행합니다.

문서에 적힌 활용 예시로는 사내 노트와 메일, 문서, 데이터베이스, 웹을 함께 검색하는 작업, 과거에 보낸 메일에서 글투를 학습한 뒤 일정에 맞춰 받은편지함을 분류하고 라벨과 회신 초안까지 만드는 작업, 기존 저장소에서 테스트를 돌리고 PR을 열고 CI와 시스템 로그를 확인하는 작업 등이 있습니다.

QM의 보안 태세 세 단계

QM은 로컬 코딩 에이전트와 같은 전제를 따릅니다. 에이전트는 자신이 일해 주는 사람의 자격증명과 권한으로 행동하고, 그 행동은 모두 감사 기록으로 남습니다. 조직은 보안 태세 하나를 고르고, 더 좁은 스코프는 그것을 완화하지 못한 채 조이기만 할 수 있습니다.

Strict: 하니스의 모든 도구 호출이 사람의 승인을 기다립니다. 예외는 아무 효과가 없는 두 가지 턴 종료 호출뿐입니다.
Auto (기본값): 분류기가 출처 표시가 붙은 외부 데이터와 도구 결과를 모델에 닿기 전에 걸러 냅니다. 배포 환경이 자체 검사 프록시를 지정하는 것도 가능합니다.
Dangerous: 콘텐츠 검사도, 도구 호출 사이의 정지도 없습니다.

세 태세와 별개로 사전 선언된 명령 정책은 항상 적용됩니다. 재귀적 삭제나 파괴적인 SQL 같은 명령에 대한 승인 규칙과 강제 거부는 Dangerous에서도 살아 있습니다. 위협 모델과 운영자 전제, 알려진 한계는 저장소의 SECURITY.md 에 정리되어 있습니다.

QM 배포하기

조직 소유의 배포 저장소를 만들고 @yc-software/qm 패키지에 의존하게 하는 방식입니다.

npm exec --yes --package=@yc-software/qm@latest -- \
  qm init . --org <slug> --target <fly-or-aws>
npm install

초기화 과정은 에이전트가 사용할 배포 스킬을 만들어 두고, 인프라와 웹 로그인, 커넥터 자격증명, 선택 사항인 슬랙 연동, 배포, 실제 동작 확인까지 차례로 안내합니다. 소스 체크아웃은 필요하지 않습니다. 배포는 운영 주체의 클라우드 계정에서 돌아가며, 초기화가 배포용 CI를 생성하거나 활성화하지는 않습니다. 세부 내용은 저장소의 deployment.md 와 docs/getting-started.md 에 있습니다.

코드베이스 전체를 한곳에 두고 싶은 조직을 위한 경로도 따로 안내되어 있습니다. GitHub의 Fork 버튼 대신 평범한 클론으로 비공개 저장소를 만들어 두는 방식인데, GitHub 포크는 원본 저장소의 공개 여부를 물려받고 객체 네트워크를 공유해서 비공개 유지가 되지 않기 때문입니다. 조직 고유의 내용은 deploy/layers/<org>/ 아래에만 두고 코어는 상류와 바이트 단위로 동일하게 유지하는 것이 병합 비용을 낮추는 규칙입니다.

기여 방식도 조금 특이합니다. QM은 코드가 아니라 "사람이 직접 쓴 텍스트" 로 기여를 받습니다. 바꾸고 싶은 내용을 adrs/ 디렉토리에 .txt 나 .md 파일로 편하게 적어 두면, 방향이 맞을 경우 개발팀이 구현을 맡습니다.

QM의 라이선스

QM은 MIT 라이선스로 공개되어 있어 개인 및 상업적 목적으로 자유롭게 사용할 수 있습니다. 다만 저장소는 "별도로 명시된 경우를 제외하고" 라는 단서를 두고 있으므로, 하위 디렉토리에 다른 표기가 붙어 있는지는 사용 전에 확인하는 편이 좋습니다.

QM 공식 홈페이지

QM 프로젝트 GitHub 저장소

더 읽어보기

이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다.

이 도구를 직접 설치해 사용해보셨다면, 파이토치 한국 사용자 모임 회원들을 위해 경험이나 팁을 댓글로 남겨주세요!