QM, 회사용 agent를 개인 비서가 아닌 공유 작업공간으로 설계한 이유

QM은 개인 assistant 하나를 회사 전체가 돌려 쓰는 방식의 불편함을 정면으로 다룬다. README가 내세우는 핵심은 사람마다 독립된 workspace를 주고, 동시에 Slack 채널이나 프로젝트 방에서는 agent와 함께 일할 수 있게 만드는 구조다. 각 사용자와 각 room은 memory, files, keychain view, permissions, crons, web apps, durable sandbox를 따로 가진다.

흥미로운 부분은 모델보다 운영 경계다. QM은 Pi, OpenCode, Codex, Claude Code 같은 harness와 model을 같은 core 위에서 바꿔 쓸 수 있다고 설명한다. 회사가 특정 vendor에 묶이지 않게 하면서도, agent가 실제 repository에서 테스트를 돌리고 PR을 만들거나 내부 문서와 이메일, 데이터베이스를 함께 검색하는 흐름을 목표로 한다.

아키텍처도 이 방향을 따른다. Postgres가 sessions, memory, queue를 맡고, headless core가 identity, policy, scheduler, agent loop를 처리한다. agent가 명령을 실행할 때는 scope별 sandbox에서 움직이므로 설치된 도구와 파일 상태가 유지된다. Slack, web UI, admin panel은 core API 위에 얹히는 plugin에 가깝다.

댓글의 관심은 “multiplayer”라는 단어의 실체에 쏠렸다. 일부는 협업 제품들이 너무 쉽게 multiplayer를 붙인다고 봤고, 다른 쪽은 회사 전체 assistant에서는 per-person scope와 shared room을 나누는 답이 꽤 현실적이라고 평가했다. 특히 보안 posture가 strict, auto, dangerous로 나뉘고, destructive SQL이나 recursive delete 같은 명령을 policy로 다루는 점은 실제 도입에서 빠질 수 없는 논점이다.

QM이 보여주는 변화는 agent 성능 경쟁보다 배치 방식에 가깝다. 사내 agent가 유용해지려면 좋은 prompt만으로는 부족하다. 누가 어떤 credential로 무엇을 실행했는지, 공유 메모리와 개인 메모리가 어디서 갈라지는지, background work가 누구 책임으로 남는지가 제품의 중심 문제가 된다.