qm은 스타트업 구성원이 각자 격리된 작업 공간을 사용하면서 Slack 채널·그룹 메시지·프로젝트에서 함께 에이전트와 협업할 수 있는 멀티플레이어 에이전트 하네스임

• 사람과 대화방마다 메모리·파일·키체인·권한·예약 작업·웹 앱·영구 샌드박스를 분리하며, Slack과 웹에서 동일한
  신원과 설정을 유지함
• Pi·OpenCode·Codex·Claude Code를 동일한 코어에 연결할 수 있고 세션 저장소·샌드박스·메모리도 인터페이스 뒤에 배치해 특정
  모델이나 공급자 종속을 피함
• Strict·Auto·Dangerous 보안 모드를 제공하며, 모든 모드에서 재귀 삭제나 파괴적 SQL 같은 작업에 대한
  명령 정책과 강제 거부를 적용함
• 조직별 설정과 인프라는 별도 배포 저장소나 일반 복제로 만든 비공개 저장소에 유지하며, 운영자가 자신의 Fly.io 또는 AWS 계정에 직접 배포해야 함

조직 단위 에이전트 작업 공간

• 개인 비서형 에이전트를 회사 전체에 적용할 때 생기는 복잡성을 줄이도록
  개인 및 공유 범위(scope) 를 기본 단위로 설계함

• 직원마다 독립된 작업 공간에서 다른 사람에게 영향을 주지 않고 작업할 수 있음

• Slack 채널·그룹 메시지·프로젝트에서는 여러 사람이 같은 에이전트와 협업할 수 있음

• 각 사람과 대화방은 별도의
  메모리·파일·키체인 보기·권한·예약 작업·웹 앱·영구 샌드박스를 가짐

• Slack과 웹 앱 사이에서 같은 신원과 구성을 사용함

• 관리자는 조직 수준 설정, 보안 태세, 사용 가능한 하네스와 모델을 통제할 수 있음

• 기술 스킬은 범위가 소유하며 권한 부여로 공유할 수 있음

• 조직 전체 승격에는 관리자 승인이 필요함

• Git 저장소에서 스킬 팩을 가져올 수 있음

• 예약 작업(cron)과 감시 작업(watch)은 사용자가 지켜보지 않아도 백그라운드에서 실행됨

지원하는 업무

• 내부 메모·이메일·문서·데이터베이스·웹을 함께 검색하고
  회사 지식을 조회할 수 있음
• 내부 웹 앱을 생성해 필요한 사람에게 공개하고 데이터를 최신 상태로 유지할 수 있음
• 과거 발송 기록에서 사용자의 문체를 학습한 뒤 일정에 따라 받은편지함을 분류하고 라벨과 답장 초안을 만들 수 있음
• 기존 저장소에서 테스트 실행, PR 생성, CI 감시, 시스템 로그 확인을 수행할 수 있음
• 공유 채널에서 프로젝트를 추적하고 진행 상황과 후속 작업을 게시할 수 있음

코어와 실행 구조

• 모든 요청은
  헤드리스 코어를 통과하며 다양한 모델과 하네스로 응답을 생성함
• Postgres가 사용자 데이터, 세션 기록, 큐, 메모리 등 영속 상태를 저장함
• 에이전트가 사용하는 도구 표면은 작고 고정돼 있으며,
  execute

도구는 해당 범위의 격리된 샌드박스에서 명령을 실행함

• 샌드박스는 각 범위가 보유한 영구 컴퓨터로 동작함

• 설치한 도구는 다음 작업에도 유지됨

• 웹 UI·관리자 패널·공개 포털은 코어의 HTTP API 위에 설치하는 선택적 플러그인임

• Slack은 코어가 직접 서비스 클라이언트로 시작하고 감독하는 선택적 인프로세스 플러그인임

• 코어는 Node에서 TypeScript를 직접 실행하고 HTTP에는
  Fastify를 사용함

• Slack 플러그인은 Bolt를 사용함

• 웹 UI는 Vite로 빌드하고 Lit으로 렌더링함

• 하네스·세션 저장소·샌드박스·메모리는 각각 인터페이스 뒤에 있으며, 프로덕션 구현은 하나의 배선 파일에서 교체할 수 있음

조직별 배포 모델

• 회사별 구성·사용자 정의 도구와 스킬·샌드박스 이미지·인프라는 코어와 분리된
  배포 디렉터리에 둠
  qm

CLI가 배포 디렉터리를 검증하고 배포함

• 조직 소유 저장소에서
  @yc-software/qm

에 의존한 뒤 다음과 같이 초기화할 수 있음

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

• 초기화 과정은 인프라, 웹 로그인, 커넥터 자격 증명, 선택적 Slack 접근, 배포, 실제 검증을 안내하며 소스 체크아웃이 필요하지 않음
• 배포는 운영자 자신의
  클라우드 계정에서 실행됨
• 초기화는 배포 CI를 생성하거나 활성화하지 않으며, qm 저장소에도 프로덕션 배포 워크플로가 없음
• 구체적인 절차는
  deployment.md

에 정리돼 있음

보안과 비밀 정보

• 에이전트는 함께 작업하는 사람의 자격 증명과 권한으로 행동하며, 수행한 모든 작업이
  감사 기록에 남음
• 조직은 하나의 보안 태세를 선택하고, 더 좁은 범위에서는 이를 완화하지 않고 강화만 할 수 있음
  Strict: 효과가 없는 두 가지 턴 종료 작업을 제외하고 모든 하네스 도구 호출을 사람의 승인 전까지 중단함
  Auto: 기본 모드로, 출처 라벨이 붙은 외부 데이터와 도구 결과를 모델에 전달하기 전에 분류기가 검사함
• 배포 환경에서 자체 검사 프록시를 지정할 수 있음

Dangerous: 콘텐츠 검사나 도구 호출 사이의 일시 중지가 없음

• 사전 선언된 명령 정책은 모든 보안 모드에 적용됨

• 승인 규칙과 함께 재귀 삭제·파괴적 SQL 같은 명령을 강제로 거부함

• Dangerous 모드도 예외가 아님

• 위협 모델, 운영자 전제 조건, 알려진 한계는
  SECURITY.md

에서 확인할 수 있음

비공개 사용자 정의 저장소

• 배포 저장소만으로 충분하지 않은 조직은 코어와 비공개 사용자 정의 코드를 한곳에서 읽을 수 있도록
  비공개 복제 저장소를 운영할 수 있음

• GitHub의 Fork 기능이 아니라 일반 복제로 만들어야 함

• 공개 저장소의 GitHub 포크는 비공개로 전환할 수 없음

• GitHub 포크는 원본과 객체 네트워크를 공유하므로 포크에 푸시한 커밋이 공개 측에서 SHA로 조회될 수 있음

• 일반 복제 저장소에서는 이런 문제가 없지만 upstream CI 워크플로가 조직 계정에서 실제 실행됨

• 필요한 비밀 정보를 제공하거나 원하지 않는 워크플로를 비활성화해야 함

• 조직별 구성·샌드박스 도구와 스킬·플러그인 이미지·인프라는
  deploy/layers/<org>/

에 보관함

• 코어를 upstream과
  바이트 단위로 동일하게 유지해 병합 규모를 줄임
• 두 가지 스킬이 공개 코어와 비공개 사용자 정의 영역의 경계를 관리함
  update-qm

은 upstream qm을 비공개 저장소에 병합하고 동기화 PR을 생성함
upstream-pr

은 upstream/main

에서 브랜치를 만들고 조직 독립적인 수정 사항을 qm으로 보냄

• 푸시 전에 diff·커밋 메시지·스크린샷에서 조직 식별자를 검사함
  deploy/layers/

아래의 파일은 upstream으로 전송하지 않음

기여와 라이선스

• 기여는 코드가 아니라 사람이 작성한
  .txt

또는 .md

문서로 받음

• 취약점은 공개 이슈가 아니라
  SECURITY.md

의 절차에 따라 비공개로 신고해야 함

• 별도 표기가 없는 부분은
  MIT License로 제공됨