---
title: "QM, 슬랙과 웹에서 쓰는 회사용 멀티 에이전트 하네스 공개"
published: 2026-07-31T18:04:58.000Z
canonical: https://jeff.news/article/5300
---
# QM, 슬랙과 웹에서 쓰는 회사용 멀티 에이전트 하네스 공개

QM은 스타트업 조직 전체가 함께 쓰는 오픈소스 에이전트 하네스다. 개인별·채널별로 메모리, 파일, 권한, 샌드박스를 분리하면서도 Slack과 웹에서 같은 설정으로 협업할 수 있게 만든 게 핵심이다.

## 개인 비서가 아니라 회사 전체가 쓰는 에이전트 런타임

- QM은 ‘나만 쓰는 AI 비서’가 아니라 스타트업 조직 전체가 같이 쓰는 멀티플레이어 에이전트 하네스임
  - 직원마다 독립된 작업공간을 받고, 서로의 파일·메모리·권한을 건드리지 않게 설계돼 있음
  - 동시에 Slack 채널, 그룹 메시지, 프로젝트 안에서는 같은 에이전트와 협업할 수 있음

- 핵심 아이디어는 범위(scope)를 아주 진지하게 다루는 것임
  - 사람마다, 방마다 메모리, 파일, 키체인 뷰, 권한, 크론, 웹 앱, 샌드박스가 따로 있음
  - 회사용 에이전트에서 “누가 뭘 볼 수 있나”가 모델 성능만큼 중요하다는 걸 전제로 깔고 감

- Slack과 웹 앱을 둘 다 지원하지만, 정체성과 설정은 이어짐
  - Slack에서 쓰던 사용자 권한과 설정이 웹 UI에서도 같은 방식으로 적용됨
  - 웹 UI, 관리자 패널, 공개 포털은 코어 HTTP API 위에 붙는 선택 플러그인으로 설명됨

## 벤더에 묶이지 않게 만든 구조

- QM은 특정 모델이나 특정 코딩 에이전트에 락인되지 않는 쪽을 강조함
  - Pi, OpenCode, Codex, Claude Code가 같은 코어를 구동할 수 있다고 밝힘
  - 하네스, 세션 저장소, 샌드박스, 메모리 같은 구성요소가 인터페이스 뒤에 있어서 배포별로 갈아끼우는 구조임

- 내부 아키텍처는 꽤 실용적인 조합임
  - 코어는 TypeScript를 Node에서 직접 실행하고, HTTP는 Fastify를 사용함
  - Slack 플러그인은 Bolt, 웹 UI는 Vite와 Lit 기반임
  - Postgres가 세션, 메모리, 큐 같은 지속 상태를 저장함

```mermaid
sequenceDiagram
    participant 사용자
    participant 코어
    participant 모델하네스
    participant 샌드박스
    participant 저장소

    사용자->>코어: Slack 또는 웹에서 요청
    코어->>저장소: 범위별 메모리와 세션 조회
    코어->>모델하네스: 정책과 맥락을 포함해 실행 요청
    모델하네스->>샌드박스: 명령 실행 또는 파일 작업
    샌드박스-->>모델하네스: 실행 결과 반환
    모델하네스-->>코어: 응답 생성
    코어->>저장소: 기록과 상태 저장
    코어-->>사용자: 결과 전달
```

## 보안 모델은 ‘에이전트가 사람처럼 행동한다’에서 출발함

- QM은 로컬 코딩 에이전트 계열의 접근을 따름
  - 에이전트가 함께 일하는 사람의 자격 증명과 권한으로 행동함
  - 대신 모든 행동은 감사 가능해야 한다는 전제를 둠

- 조직은 하나의 보안 자세(security posture)를 고르고, 더 좁은 범위에서는 더 엄격하게만 조일 수 있음
  - Strict는 효과가 있는 도구 호출마다 사람 승인을 요구함
  - Auto는 기본값으로, 외부 데이터와 도구 결과를 모델에 넣기 전에 분류기가 검사함
  - Dangerous는 콘텐츠 검사나 도구 호출 사이의 중단이 없지만, 그래도 재귀 삭제나 파괴적 SQL 같은 명령 정책은 적용됨

> [!IMPORTANT]
> “Dangerous” 모드에서도 미리 선언된 명령 정책은 남아 있음. 이름은 위험해 보여도, 완전 무제한 실행을 뜻하진 않음.

## 배포 방식도 꽤 독특함

- QM은 소스 체크아웃 없이 조직 소유 배포 저장소를 만들 수 있게 함
  - `npm exec --package=@yc-software/qm@latest`로 초기화하고, 조직 slug와 Fly 또는 AWS 타깃을 지정하는 방식임
  - 초기화 과정에서 인프라, 웹 로그인, 커넥터 자격 증명, 선택적 Slack 접근, 배포, 실서비스 검증까지 안내함

- 조직별 커스터마이징은 배포 디렉터리에 몰아넣는 구조임
  - 조직 설정, 샌드박스 도구와 스킬, 플러그인 이미지, 인프라가 `deploy/layers/<org>/` 아래에 들어감
  - 코어를 업스트림과 byte-identical하게 유지해서 머지 비용을 줄이려는 의도임

- 조직이 전체 코드베이스를 한곳에서 보고 싶다면 ‘GitHub Fork 버튼’이 아니라 일반 private clone을 쓰라고 못 박음
  - GitHub에서 public repo를 fork하면 private으로 만들 수 없고, 객체 네트워크를 공유해서 SHA로 접근 가능한 커밋 문제가 생길 수 있다는 설명임
  - 일반 clone은 이런 문제를 피하지만, 업스트림 CI 워크플로가 자기 계정에서 실행될 수 있으니 secrets를 넣거나 꺼야 함

---

## 기술 맥락

- QM이 고른 핵심 선택은 에이전트를 모델 호출 API가 아니라 조직용 런타임으로 다루는 거예요. 회사 안에서는 “답변을 잘함”보다 “어떤 권한으로 어디까지 실행했는지”가 더 오래 남는 문제거든요.

- 범위별 메모리와 샌드박스를 둔 이유는 협업과 격리를 동시에 잡기 위해서예요. Slack 채널에서 같이 일하려면 공유 맥락이 필요하지만, 개인 키체인이나 파일까지 섞이면 바로 사고로 이어질 수 있어요.

- 모델과 하네스를 인터페이스 뒤에 숨긴 것도 운영 관점에서 꽤 현실적인 선택이에요. 특정 벤더 모델이 가격, 정책, 성능 문제로 흔들릴 때 전체 제품 구조를 갈아엎지 않고 배포 설정만 바꿀 여지를 남기는 거죠.

- 배포 디렉터리와 private clone 전략은 오픈소스 코어와 조직별 비밀을 분리하려는 장치예요. 에이전트가 내부 도구와 인프라를 알아야 쓸모가 생기지만, 그 정보가 업스트림으로 새면 안 되니까 경계를 파일 구조와 워크플로로 강제하려는 거예요.

## 핵심 포인트

- 개인 비서형 에이전트가 아니라 조직 단위 협업 에이전트를 목표로 함
- Pi, OpenCode, Codex, Claude Code 같은 여러 하네스와 모델을 같은 코어에서 바꿔 쓸 수 있음
- 각 사용자와 공간마다 메모리, 파일, 키체인, 권한, 크론, 샌드박스를 분리함
- 조직 설정, 보안 자세, 모델 선택, 내부 앱 배포를 관리자가 통제할 수 있음

## 인사이트

AI 에이전트를 회사 안에 넣을 때 제일 골치 아픈 지점은 모델 성능보다 권한, 격리, 감사 로그, 운영 경계임. QM은 이 문제를 ‘개인용 에이전트 여러 개’가 아니라 ‘조직용 런타임’으로 풀려는 시도라 꽤 흥미롭다.