TL;DR

QM은 스타트업용 멀티플레이어 에이전트 허브로, 각 사용자와 채널별로 격리된 워크스페이스·영속 샌드박스·권한 모델을 제공합니다. 코어는 하니스 무관성으로 Pi·OpenCode·Codex·Claude Code 같은 다양한 실행 백엔드를 연결하고 Postgres에 세션과 메모리를 저장합니다. 배포는 조직 소유의 deploy/layers 디렉터리에 커스터마이즈를 두고 qm CLI로 초기화하는 흐름을 사용하며 보안 태세는 Strict·Auto·Dangerous 세 가지로 운영자가 선택할 수 있습니다.

주요 기능

• QM은 각 사용자와 채널, 프로젝트마다 별도 스코프를 제공해 개인 메모리·파일·키체인·권한·크론을 분리합니다. 이 구조는 한 사용자의 설정이나 도구 설치가 다른 사용자의 작업에 영향을 주지 않도록 격리된 실행 환경을 유지합니다. 따라서 스타트업처럼 권한과 데이터 경계가 중요한 조직에서 동시에 여러 작업 흐름을 안전하게 운영할 수 있습니다.
• 코어는 하니스와 모델을 추상화해 Pi, OpenCode, Codex, Claude Code 같은 다양한 실행 백엔드를 동일한 인터페이스로 연결합니다. 이 추상화는 배포 후에도 하니스나 모델을 교체할 수 있게 해 벤더 종속을 줄입니다. 조직별 요구에 따라 다른 모델을 시험하고 전환하는 실험이 쉬워집니다.
• 웹 UI와 Slack 플러그인이 동일한 정체성과 설정을 공유해 사용자는 웹과 Slack 사이를 자연스럽게 이동할 수 있습니다. 웹은 Vite와 Lit으로 렌더링되고, Slack은 Bolt 기반 플러그인으로 동작하며 둘 다 코어의 API 위에서 동작합니다. 이 통합은 채널 기반 협업과 개인별 워크스페이스 사용을 동시에 지원합니다.

어떻게 동작하는가

QM 코어는 중앙의 API와 에이전트 루프를 통해 각 턴마다 모델 하니스로부터 응답을 생성하고 스코프별 샌드박스에 명령을 실행합니다. 영속성 계층으로 Postgres를 사용해 세션·메모리·큐를 보존하며, 샌드박스는 각 스코프의 도구와 자격증명을 담아 격리된 실행 환경을 유지합니다. 코어는 인터페이스 추상화를 통해 다양한 하니스와 세션 저장소를 플러그인 방식으로 교체할 수 있고, 웹 UI·Slack·관리 패널은 선택적 플러그인으로 코어의 HTTP API 위에서 동작합니다.

해결 문제

회사 규모로 확장하려는 개인형 에이전트가 권한과 데이터 충돌로 복잡해지는 문제를 해결합니다. QM은 각 사용자와 채널을 별도 스코프로 분리해 설정·메모리·도구 설치가 격리되도록 함으로써 충돌을 줄입니다. 또한 하니스 무관성과 배포 디렉터리 패턴으로 조직별 커스터마이즈와 벤더 전환을 용이하게 해 스타트업 환경에 맞는 운영 유연성을 제공합니다.

차별점

• 스코프별 영속 샌드박스를 제공해 해당 스코프에 설치된 도구와 인증정보가 지속적으로 유지됩니다. 이 방식은 매 세션마다 환경을 재설정하는 대신 한 번 설치한 도구를 계속 활용하게 해 자동화 워크플로우의 효율을 높입니다. 운영상으로는 권한 경계와 감사 추적을 더 세밀하게 적용할 수 있습니다.
• 하니스와 모델 구현을 인터페이스 뒤에 숨겨 어느 하니스든 연결할 수 있는 설계를 채택했습니다. 덕분에 조직은 Pi나 OpenCode, Codex, Claude Code 같은 여러 백엔드를 시험하거나 교체할 수 있습니다. 벤더 종속을 피하고 더 나은 비용·성능 트레이드오프를 추구할 때 장점이 있습니다.
• 배포 디렉터리 패턴과 qm CLI로 조직 전용 설정을 분리하는 워크플로우를 제공합니다. 공개 upstream 코어는 그대로 두고 deploy/layers/<org>/에 조직별 레이어를 두어 커스터마이즈를 유지합니다. 이 접근은 upstream과의 병합을 작게 유지하면서도 내부 규정·시크릿을 안전하게 관리하도록 돕습니다.

사용 사례

• 사내 노트·이메일·문서·데이터베이스·웹을 통합 검색해 회사 지식 베이스에서 정보를 빠르게 찾을 수 있습니다. QM의 스코프별 메모리와 파일 통합은 개인별 문맥을 유지한 검색 결과를 제공합니다. 검색 결과를 조직 채널로 공유하거나 워크플로우 트리거로 연결하는 것이 가능합니다.
• 정기적 이메일 처리·라벨링·답장 초안 작성 같은 개인 업무를 자동화하고 스케줄에 따라 실행할 수 있습니다. QM의 크론과 영속 샌드박스를 이용하면 주기 작업이 사용자 자격으로 실행되며 감사 로그에 기록됩니다. 팀 내에서 템플릿화한 스킬을 공유해 일관된 자동화 규칙을 배포할 수 있습니다.
• 코드 저장소에서 테스트를 실행하고 PR을 열거나 CI를 모니터링하는 등 리포지토리 작업을 에이전트에게 맡길 수 있습니다. 권한과 샌드박스 격리를 통해 에이전트가 조직 자격으로 안전하게 명령을 실행하게 할 수 있습니다. 개발자 워크플로우에 통합하면 반복 작업과 모니터링 부담을 줄일 수 있습니다.

시작하기

레포지토리는 qm CLI와 여러 문서로 초기 배포를 지원합니다. README에 제시된 npm exec qm init 명령으로 배포 디렉터리 골격을 생성하고 docs/getting-started.md와 cli/README.md를 따라 인프라·웹 로그인·커넥터 설정을 완료하면 됩니다. .env.example 파일에 주요 환경 변수가 정리되어 있으므로 초기 설정 시 이를 채우고 운영자의 클라우드 계정과 필요한 시크릿을 준비해야 합니다.

요구사항

• Node.js와 TypeScript 런타임에서 코어가 직접 실행되며 Fastify를 HTTP 서버로 사용합니다. 따라서 실행 환경에는 Node 기반 런타임이 준비되어 있어야 하고 패키지 설치와 빌드가 가능해야 합니다. 운영 환경에서 장기 가동을 고려하면 적절한 Node 버전 관리와 프로세스 감독이 필요합니다.
• 영속성으로 Postgres를 사용하므로 배포 전 Postgres 인스턴스와 접속 정보가 필요합니다. 세션·메모리·큐 데이터가 Postgres에 저장되므로 백업·접근 제어·성능 튜닝이 배포 전점검 항목에 포함되어야 합니다. 운영자는 데이터 보존 정책과 마이그레이션 절차를 준비해야 합니다.
• 실제 배포는 조직의 클라우드 계정에서 이루어지며 CI와 시크릿을 운영자가 관리해야 합니다. README는 배포가 운영자 클라우드 계정에서 실행된다고 명시하고 있으므로, 배포 파이프라인에 필요한 자격증명·비밀키·권한을 사전에 준비해야 합니다. 또한 운영자는 qm init이 생성하는 워크플로우에서 실행되는 CI를 검토해 필요 시 비활성화하거나 시크릿을 제공해야 합니다.