직원마다 독립된 AI 에이전트 공간을 주는 오픈소스, QM이 설계한 방식 (github.com)

한줄 요약

팀원 각각에게 격리된 AI 에이전트 공간을 주면서도 협업은 그대로 — QM이 멀티플레이어 방식으로 푼 에이전트 아키텍처.

무엇이 달라지나?

기존 AI 에이전트 도구 대부분은 개인 비서 모델을 기반으로 설계됐다. 한 명이 쓰는 데는 괜찮지만, 조직 전체가 하나의 에이전트를 공유하면 빠르게 복잡해진다. 누군가의 설정이 다른 사람에게 영향을 미치고, 권한과 메모리가 뒤섞이며, 관리 부담이 커진다.

QM은 이 문제를 구조적으로 다르게 접근한다. 각 팀원은 자신만의 격리된 워크스페이스를 갖는다. 파일, 크론 작업, 키체인, 메모리, 스킬이 모두 개인 혹은 채널 단위로 스코프가 분리돼 있다. 동시에 Slack 채널, 그룹 메시지, 프로젝트 단위로는 에이전트와 함께 협업하는 것도 가능하다.

모델과 하네스 선택도 유연하다. Pi, OpenCode, Codex, Claude Code 중 어느 것을 쓰더라도 동일한 코어 위에서 동작하도록 설계됐기 때문에, 특정 AI 벤더에 락인되지 않는다. 코어는 TypeScript와 Node.js 기반이며, HTTP 서버로는 Fastify를 사용한다. Slack 연동은 Bolt로, 웹 UI는 Vite와 Lit으로 구성된다.

아키텍처 측면에서 보면, 모든 턴은 중앙 코어를 통해 실행된다. Postgres가 세션, 메모리, 큐를 관리하는 퍼시스턴스 레이어를 담당하고, 에이전트는 각 스코프 전용 격리 샌드박스에서 명령을 실행한다. 한번 설치된 도구는 그 샌드박스에 유지된다는 점이 실용적이다.

실무에서 어떤 의미인가?

이 구조가 실질적으로 흥미로운 이유는 단순히 "격리"가 아니라 격리와 협업을 동시에 달성하는 방식에 있다.

내부 노트, 이메일, 문서, 데이터베이스, 웹을 통합 검색하거나, 기존 코드 저장소에서 테스트를 실행하고 PR을 열고 CI 상태를 모니터링하는 작업을 에이전트가 수행한다. 과거 이메일 문체를 학습해 받은 편지함을 일정에 따라 트리아지하고 답장 초안을 생성하는 것도 가능하다. 공유 채널에서 프로젝트를 추적하고 업데이트를 자동으로 포스팅하는 기능도 있다.

개발 외주나 내부 툴 개발을 검토하는 팀이라면, 이런 에이전트 하네스가 어떻게 조직 운영 방식을 바꿀 수 있는지 주목할 만하다. 에이전트가 단순 보조 도구를 넘어 팀 단위의 워크플로우 자동화 레이어로 기능하는 방향으로 빠르게 이동하고 있기 때문이다.

보안 모델도 실용적으로 설계됐다. Strict(모든 도구 호출에 사람 승인), Auto(외부 데이터 분류 후 모델 전달, 기본값), Dangerous(스크리닝 없음) 세 단계 보안 포스처를 조직이 선택할 수 있다. 재귀 삭제나 파괴적 SQL 같은 위험 명령에 대한 사전 선언 정책은 어느 포스처에서도 항상 적용된다.

배포 방식도 자체 클라우드 계정(Fly 또는 AWS) 위에서 운영되는 구조라, 데이터가 외부 서비스에 종속되지 않는다.

도입 전 체크포인트

QM을 실제 조직에 도입하거나, 유사한 구조의 내부 에이전트 시스템을 구축하려 할 때 미리 짚어야 할 지점들이 있다.

스코프 설계부터 명확히. 개인 스코프와 공유 스코프의 경계를 초기에 잘 설정해야 한다. 스킬과 메모리가 어디까지 공유되고 어디부터 격리되는지 조직 내 합의 없이 배포하면, 이후 재설계 비용이 크다.

샌드박스 이미지 관리 주체를 정해라. 각 스코프의 격리 샌드박스에 설치된 도구는 유지되는 구조인 만큼, 샌드박스 이미지를 누가 어떻게 관리할지 운영 정책이 필요하다.

보안 포스처 선택은 팀 성숙도와 맞춰라. Auto가 기본값이지만, 조직의 데이터 민감도와 운영 팀의 모니터링 역량에 따라 Strict로 시작하는 게 현실적일 수 있다.

기여 방식을 확인하라. QM은 코드 기여가 아닌 텍스트(.txt, .md 파일)로만 기여를 받는 독특한 정책을 운영 중이다. 커스터마이징이 깊게 필요한 조직이라면 프라이빗 포크 전략을 처음부터 고려해야 한다. GitHub의 Fork 기능이 아닌 plain clone 방식을 사용해야 저장소 가시성 문제를 피할 수 있다는 점도 중요하다.