qm — 협업을 위한 멀티플레이어 에이전트 하네스 실전 가이드
에이전트 기반 개발이 일반화되면서, 한 사람이 여러 AI와 동시에 작업하는 시대가 열렸습니다. 단순한 단일 채팅 인터페이스로는 한계가 있고, 이제는 사람과 에이전트가 같은 채널에서 협업할 수 있는 하네스가 필요합니다. 이번 글에서 다룰 qm은 바로 그 지점에 위치한 도구입니다.
1. qm은 무엇인가 — 멀티플레이어 에이전트 하네스의 등장
qm은 스타트업 구성원이 각자 격리된 작업 공간을 사용하면서, Slack 채널·그룹 메시지·프로젝트 안에서 함께 에이전트와 협업할 수 있도록 만든 멀티플레이어 에이전트 하네스입니다. 사람과 대화방마다 메모리·파일·키체인·권한·예약 작업·웹 앱·영구 샌드박스를 분리해서 부여하기 때문에, 여러 팀원이 동시에 같은 하네스 위에서 작업해도 서로의 작업이 섞이지 않습니다.
핵심 차별점은 두 가지입니다. 첫째, 격리 단위가 사람이라는 점입니다. 일반적인 단일 에이전트는 한 컨텍스트 안에서 모든 작업이 누적되지만, qm은 사람/대화방 단위로 컨텍스트를 분할합니다. 둘째, Slack과 웹이 동일한 신원과 권한을 공유한다는 점입니다. 즉 채널에서 에이전트에게 보낸 메시지와 웹 UI에서 보내는 메시지가 같은 권한·같은 파일 시스템으로 처리됩니다.
2. 격리 기반 설계 — 왜 하네스인가
하네스(harness)라는 단어가 등장한 배경에는 에이전트의 자율성을 관리하는 껍데기가 필요하다는 현실이 있습니다. 단순히 LLM을 호출하는 것은 도구(tool)이고, 그 도구를 감싸는 정책·권한·영속성·관측 가능성을 함께 제공하는 것이 하네스입니다. qm은 다음 다섯 가지 자원을 사람/대화방 단위로 격리합니다.
- 메모리 — 채널별로 별도 컨텍스트, 다른 대화의 프롬프트가 섞이지 않음
- 파일 — 각 사용자의 작업 디렉터리 격리, 같은 파일을 다른 팀원이 동시에 수정해도 안전
- 키체인 — API 키·OAuth 토큰을 사용자/대화방 단위로 보관, 권한 상승 최소화
- 예약 작업(cron) — 사람별 스케줄러, 팀원이 다른 사람의 작업을 트리거할 수 없음
- 영구 샌드박스 — 코드 실행 환경도 분리, 한 사람의 셸 작업이 다른 사람에게 누설되지 않음
이 다섯 자원을 통째로 묶어서 workspace라는 단위로 다루기 때문에, 새 팀원이 합류하면 workspace 하나만 만들면 되고, 그가 퇴사하면 workspace를 폐기하면 모든 산출물이 함께 사라집니다.
3. 실전 구성 패턴
qm을 실제로 운영하는 팀들은 보통 다음과 같은 형태로 채널을 구성합니다.
# 채널별 workspace 매핑 예시
# 1) 개인 작업 채널 — 자기 workspace만 보임
qm workspace attach --channel "#alice-dev"
# 2) 페어/팀 채널 — 두 workspace가 합쳐진 공유 뷰
qm workspace attach --channel "#alice-bob-pair" --shared alice,bob
# 3) 프로젝트 채널 — 여러 workspace + 읽기 전용 옵저버
qm workspace attach --channel "#proj-foo" \
--members alice,bob,carol --observers dave실제 코드 실행은 각자의 샌드박스에서 일어나지만, 메시지 단위로 누가 어떤 명령을 보냈는지 추적되기 때문에 감사 로그(audit log)가 자동으로 쌓입니다. Slack 메시지 → 에이전트 호출 → 샌드박스 실행 → 결과 반환의 전 과정이 같은 권한 컨텍스트 안에서 처리됩니다.
4. 다른 하네스 대비 qm의 위치
에이전트 하네스 영역에는 이미 다양한 도구가 있습니다. Claude Code나 OpenAI Codex CLI는 개인 CLI에 가깝고, OpenHands/Aider는 저장소 단위 자동화에 강합니다. 반면 qm은 팀 단위 협업 채널에 특화된 점이 다릅니다. Slack이라는 이미 팀이 쓰는 인터페이스를 그대로 활용해 진입 비용을 낮추고, 그 위에 격리된 멀티플레이어 계층을 얹은 구조입니다.
따라서 다음 조건에 부합하면 qm이 특히 매력적입니다.
- 팀 단위로 AI 에이전트를 도입하려고 하지만, 단일 컨텍스트 오염을 걱정하는 경우
- Slack에 이미 업무 채널이 있어 그 위에서 에이전트를 함께 쓰고 싶은 경우
- 감사 로그와 권한 분리가 필요한 엔터프라이즈 환경
- 사람마다 서로 다른 API 키와 토큰을 안전하게 운용해야 하는 경우
5. 운영 시 주의할 점
qm이 아무리 격리를 잘해줘도 사람 단위 권한 정책은 운영자가 정의해야 합니다. 키체인에 어떤 토큰을 올릴지, 예약 작업이 다른 사용자의 자원을 건드릴 수 있는지, 샌드박스에서 네트워크 egress를 어디까지 허용할지 등은 하네스 차원에서 기본값을 제공하지만 조직 정책에 맞춰 조정하는 것이 안전합니다.
또한 메모리 격리는 채널을 잘못 매핑하면 무너지기 쉽습니다. 한 workspace를 여러 채널에서 공유하면 컨텍스트가 섞이고, 컨텍스트가 섞이면 결국 단일 에이전트와 다를 바가 없어집니다. 처음에 채널-워크스페이스 매핑을 단순하게 유지하고, 공유는 명시적으로 표현하는 것이 운영의 핵심입니다.
6. 전망 — 멀티플레이어 에이전트의 다음 단계
qm이 보여주는 방향성은 분명합니다. 에이전트는 더 이상 한 사람이 혼자 쓰는 도구가 아니라, 팀이 함께 운영하는 인프라로 이동하고 있다는 점입니다. Slack 같은 업무 채널과 같은 권한 모델을 공유한다는 점, 그리고 사람/대화방 단위로 격리 자원을 묶는다는 점은 향후 다른 하네스들도 채택할 가능성이 높은 패턴입니다.
단기적으로는 예약 작업·웹 앱·영구 샌드박스를 하네스 차원에서 얼마나 정교하게 제공하느냐가 경쟁력이 될 것이고, 장기적으로는 감사 로그를 외부 SIEM과 통합하거나 정책 엔진(OPA 등)과 연동하는 방향으로 진화할 가능성이 큽니다. 지금 qm을 시험 삼아 도입해 보면, 향후 어떤 형태로 에이전트 협업이 표준화될지 가늠할 수 있는 좋은 출발점이 됩니다.
요약
- qm은 사람/대화방 단위 격리를 핵심으로 하는 멀티플레이어 에이전트 하네스입니다.
- 메모리·파일·키체인·예약 작업·샌드박스를 workspace 단위로 묶어 다중 사용자 협업을 안전하게 만듭니다.
- Slack과 웹이 같은 권한·같은 신원을 공유해 진입 비용이 낮습니다.
- 도입 시에는 채널-워크스페이스 매핑을 단순하게 유지하고, 권한 정책과 egress 허용 범위를 명시적으로 정의하는 것이 안전합니다.
- 에이전트가 팀 단위 인프라로 이동하는 흐름을 가장 먼저 실험해 볼 수 있는 도구입니다.
📰 원본 출처 · https://news.hada.io/topic?id=32023 (#N=32023)
이 글은 GeekNews(긱뉴스)에 게제된 글을 기반으로 작성되었습니다. 원본의 라이선스와 저작권은 원작자에게 있습니다.