qm, 조직 전체가 함께 사용하는 멀티플레이어 에이전트 하네스

AI 에이전트를 개인 업무에 활용하는 것을 넘어 조직 전체의 업무에 적용하려면 새로운 문제가 생깁니다. 직원마다 다른 권한과 작업 공간을 사용하면서도 Slack 채널이나 프로젝트에서는 같은 에이전트와 협업할 수 있어야 하고, 각자의 파일·메모리·자격 증명·예약 작업도 서로 섞이지 않아야 합니다.

qm은 이런 조직 환경을 고려해 설계된 멀티플레이어 에이전트 하네스입니다. 스타트업 구성원이 각자 격리된 작업 공간에서 에이전트를 사용할 수 있도록 하면서도 Slack, 그룹 메시지, 프로젝트와 같은 공유 공간에서는 여러 사람이 에이전트와 함께 작업할 수 있도록 구성합니다.

특히 특정 AI 모델이나 에이전트 하네스에 종속되지 않도록 코어와 세션 저장소, 샌드박스, 메모리 등을 인터페이스 뒤에 배치한 점이 특징입니다. 여기에 보안 모드, 조직 단위 권한 관리, 영구 샌드박스, 예약 작업, 자체 클라우드 계정 기반 배포까지 제공해 개인용 AI 도구가 아닌 조직용 에이전트 실행 환경을 지향합니다.

반응형

qm이 해결하려는 조직형 에이전트의 문제

개인 비서형 AI 에이전트를 회사 전체에 적용하면 단순히 사용자를 여러 명 추가하는 것만으로는 충분하지 않습니다.

각 직원이 사용하는 데이터와 권한이 분리돼야 하고, 반대로 프로젝트나 Slack 채널에서는 여러 사람이 동일한 에이전트와 협업할 수 있어야 합니다. 또한 에이전트가 파일을 수정하거나 명령을 실행하는 경우 해당 작업이 어느 범위에서 실행됐는지도 명확해야 합니다.

qm은 이를 개인과 공유라는 두 가지 범위로 나눠 접근합니다.

직원별로는 독립적인 작업 공간을 제공하고, Slack 채널·그룹 메시지·프로젝트와 같은 공유 공간에서는 여러 사람이 동일한 에이전트와 협업할 수 있도록 합니다.

각 사람과 대화방에는 다음과 같은 실행 환경이 별도로 제공됩니다.

• 메모리
• 파일
• 키체인 보기
• 권한
• 예약 작업
• 웹 앱
• 영구 샌드박스

따라서 개인의 작업 환경과 조직의 협업 환경을 하나의 구조 안에서 구분할 수 있습니다.

또한 Slack과 웹 앱 사이에서는 동일한 신원과 구성을 유지할 수 있어 사용자가 서로 다른 인터페이스를 이용하더라도 일관된 환경에서 에이전트와 작업할 수 있습니다.

조직 단위로 관리되는 에이전트 작업 공간

qm의 핵심은 에이전트를 단순한 개인 도구가 아니라 조직의 업무 환경에 포함시키는 데 있습니다.

관리자는 조직 수준에서 설정과 보안 태세, 사용할 수 있는 하네스와 모델을 통제할 수 있습니다. 반면 직원은 자신의 작업 공간에서 다른 사람의 작업에 영향을 주지 않고 에이전트를 사용할 수 있습니다.

기술 스킬 역시 범위를 기준으로 관리합니다.

스킬은 특정 범위가 소유하고 필요할 경우 권한 부여를 통해 공유할 수 있습니다. 조직 전체에 스킬을 승격하려면 관리자 승인이 필요하며, Git 저장소에서 스킬 팩을 가져오는 것도 가능합니다.

이 구조를 통해 개인이 사용하는 기능과 조직 전체에서 공유되는 기능을 구분할 수 있습니다.

특히 예약 작업과 감시 작업을 지원한다는 점도 중요합니다. 사용자가 계속 지켜보지 않아도 에이전트가 백그라운드에서 작업을 수행할 수 있기 때문입니다.

실제 업무에서는 어떻게 활용할 수 있을까

qm이 제공하는 구조는 다양한 조직 업무에 적용할 수 있습니다.

회사 내부 지식 검색

내부 메모, 이메일, 문서, 데이터베이스와 웹을 함께 검색해 회사의 지식을 조회할 수 있습니다.

정보가 여러 시스템에 분산돼 있더라도 에이전트가 여러 정보원을 함께 활용할 수 있는 구조입니다.

내부 웹 앱 생성

필요한 사람에게 공개할 수 있는 내부 웹 앱을 만들고 데이터를 최신 상태로 유지하는 작업도 지원합니다.

조직에서 반복적으로 확인해야 하는 데이터를 웹 기반 도구로 제공하는 방식으로 활용할 수 있습니다.

이메일 업무 자동화

과거에 발송한 기록을 기반으로 사용자의 문체를 학습한 뒤 일정에 따라 받은편지함을 분류하고 라벨을 지정하거나 답장 초안을 만들 수 있습니다.

즉, 단순히 이메일 내용을 요약하는 수준을 넘어 반복적인 받은편지함 관리 업무까지 에이전트가 담당할 수 있도록 구성돼 있습니다.

개발 업무 지원

기존 저장소에서는 테스트 실행, PR 생성, CI 감시, 시스템 로그 확인 등의 작업을 수행할 수 있습니다.

개발자가 직접 모든 과정을 확인하지 않고도 에이전트가 저장소와 실행 환경을 활용해 개발 업무의 일부를 처리할 수 있는 구조입니다.

프로젝트 진행 상황 관리

공유 채널에서는 프로젝트를 추적하고 진행 상황과 후속 작업을 게시할 수 있습니다.

이를 통해 에이전트가 개인 업무 보조 도구에 그치지 않고 팀 단위 프로젝트의 진행 상황을 함께 관리하는 역할도 수행할 수 있습니다.

다양한 모델과 하네스를 연결하는 qm의 코어 구조

qm의 실행 구조에서 중요한 부분은 모든 요청이 헤드리스 코어를 통과한다는 점입니다.

에이전트의 응답 생성에는 다양한 모델과 하네스를 연결할 수 있습니다. 현재 자료에서는 Pi, OpenCode, Codex, Claude Code를 동일한 코어에 연결할 수 있도록 설명하고 있습니다.

이 구조의 장점은 특정 모델이나 공급자에 시스템 전체가 종속되지 않는다는 것입니다.

세션 저장소, 샌드박스, 메모리 역시 각각 인터페이스 뒤에 배치돼 있습니다. 따라서 프로덕션 환경에서는 하나의 배선 파일에서 구현을 교체할 수 있도록 구성됩니다.

구조적으로 보면 다음과 같은 형태입니다.

사용자 및 협업 공간 → qm 코어 → 하네스·모델 → 도구 실행 및 샌드박스

이처럼 핵심 실행 로직과 실제 구현 환경을 분리해 특정 구성 요소의 변경이 전체 시스템에 미치는 영향을 줄이는 방식입니다.

영구 샌드박스로 분리되는 에이전트 실행 환경

qm에서 에이전트가 사용하는 도구 표면은 작고 고정돼 있으며, execute 도구를 통해 해당 범위에 속한 격리된 샌드박스에서 명령을 실행합니다.

이 샌드박스는 각 범위가 보유한 영구적인 컴퓨터처럼 동작합니다.

특히 설치한 도구가 다음 작업에도 유지된다는 점이 특징입니다. 매번 새로운 환경을 만들어 처음부터 도구를 설치하는 것이 아니라 작업 환경을 지속적으로 사용할 수 있습니다.

여기서 중요한 것은 작업 범위별 격리입니다.

개인이나 대화방에 연결된 실행 환경을 분리함으로써 서로 다른 작업이 동일한 실행 공간에서 뒤섞이지 않도록 설계할 수 있습니다.

웹 UI와 Slack은 선택적으로 붙이는 구조

qm의 코어가 모든 기능을 하나의 거대한 애플리케이션으로 가지고 있는 것은 아닙니다.

웹 UI, 관리자 패널, 공개 포털은 코어의 HTTP API 위에 설치할 수 있는 선택적 플러그인으로 구성됩니다.

Slack 역시 선택적인 인프로세스 플러그인으로 제공되며, 코어가 서비스 클라이언트로 직접 시작하고 감독합니다.

기술 스택은 다음과 같이 구성됩니다.

• 코어: Node에서 TypeScript 실행
• HTTP: Fastify
• Slack 플러그인: Bolt
• 웹 UI 빌드: Vite
• 웹 UI 렌더링: Lit
• 영속 상태 저장: Postgres

Postgres에는 사용자 데이터와 세션 기록, 큐, 메모리 등의 영속 상태가 저장됩니다.

이러한 구성은 에이전트의 핵심 실행 영역과 사용자 인터페이스를 분리하면서 필요에 따라 기능을 추가할 수 있도록 합니다.

qm의 보안 모드와 명령 정책

조직에서 에이전트를 사용하는 환경에서는 기능만큼 보안이 중요합니다.

qm은 조직별로 하나의 보안 태세를 선택하도록 하고, 더 좁은 범위에서는 조직 수준의 보안을 완화하지 않고 강화하는 방향으로 구성합니다.

제공되는 보안 모드는 Strict, Auto, Dangerous입니다.

Strict 모드

효과가 없는 두 가지 턴 종료 작업을 제외하고 모든 하네스 도구 호출을 사람이 승인하기 전까지 중단합니다.

즉, 에이전트가 도구를 사용하는 과정에서 사람의 확인을 강하게 요구하는 방식입니다.

Auto 모드

기본 모드입니다.

출처 라벨이 붙은 외부 데이터와 도구 결과를 모델에 전달하기 전에 분류기가 검사합니다.

배포 환경에서는 자체 검사 프록시를 지정할 수도 있습니다.

Dangerous 모드

콘텐츠 검사나 도구 호출 사이의 일시 중지가 없는 모드입니다.

다만 이름 그대로 모든 작업이 허용되는 것은 아닙니다.

qm에는 보안 모드와 별도로 사전에 선언된 명령 정책이 적용됩니다. 승인 규칙과 함께 재귀 삭제나 파괴적인 SQL과 같은 명령을 강제로 거부합니다.

중요한 점은 Dangerous 모드에서도 이 정책을 예외로 두지 않는다는 것입니다.

따라서 보안 수준을 낮추는 선택과 시스템 차원의 강제 거부 정책은 별도로 동작합니다.

에이전트는 사용자의 권한으로 작업한다

qm에서 에이전트는 함께 작업하는 사람의 자격 증명과 권한으로 행동합니다.

그리고 수행한 작업은 감사 기록에 남습니다.

이는 조직에서 에이전트를 사용할 때 중요한 구조입니다. 에이전트가 독립적인 별도 사용자처럼 무제한 권한을 갖는 것이 아니라 실제 작업을 수행하는 사람의 권한 범위를 기준으로 동작하도록 설계돼 있기 때문입니다.

결과적으로 조직은 에이전트에게 어떤 작업을 허용할 것인지뿐만 아니라 어떤 사용자와 범위에서 해당 작업을 수행할 수 있는지도 함께 관리할 수 있습니다.

조직별 배포는 자체 클라우드 계정에서 진행

qm의 또 다른 특징은 조직별 설정과 인프라를 코어와 분리한다는 점입니다.

회사별 구성과 사용자 정의 도구 및 스킬, 샌드박스 이미지, 인프라는 별도의 배포 디렉터리에 둡니다.

그리고 qm CLI가 해당 배포 디렉터리를 검증하고 배포합니다.

조직 소유 저장소에서 @yc-software/qm에 의존한 뒤 다음과 같은 방식으로 초기화할 수 있습니다.

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

초기화 과정에서는 인프라와 웹 로그인, 커넥터 자격 증명, 선택적인 Slack 접근, 배포 및 실제 검증 과정을 안내합니다.

또한 소스 체크아웃 없이 초기화할 수 있으며, 실제 배포는 운영자가 소유한 클라우드 계정에서 실행됩니다.

지원 대상은 Fly.io 또는 AWS입니다.

여기서 주의할 부분도 있습니다. 초기화 과정에서 배포 CI를 생성하거나 활성화하지 않으며, qm 저장소에도 프로덕션 배포 워크플로가 없습니다.

구체적인 배포 절차는 deployment.md에 정리돼 있습니다.

비공개 사용자 정의 저장소로 조직별 코드를 관리

배포 저장소만으로 충분하지 않은 조직은 코어와 비공개 사용자 정의 코드를 함께 읽을 수 있도록 비공개 복제 저장소를 운영할 수 있습니다.

다만 GitHub의 Fork 기능이 아니라 일반 복제 방식으로 만들어야 합니다.

공개 저장소의 GitHub 포크는 비공개로 전환할 수 없고, 포크가 원본과 객체 네트워크를 공유하기 때문입니다. 따라서 포크에 푸시한 커밋이 공개 측에서 SHA를 통해 조회될 수 있다는 문제가 있습니다.

일반 복제 저장소에서는 이러한 문제가 없지만 다른 고려 사항이 있습니다.

upstream CI 워크플로가 조직 계정에서 실제 실행되므로 필요한 비밀 정보를 제공하거나 원하지 않는 워크플로를 비활성화해야 합니다.

조직별 구성과 샌드박스 도구 및 스킬, 플러그인 이미지, 인프라는 deploy/layers/<org>/ 아래에 보관합니다.

그리고 코어는 upstream과 바이트 단위로 동일하게 유지해 향후 병합해야 하는 변경 규모를 줄입니다.

upstream과 조직별 코드를 분리하는 두 가지 스킬

비공개 사용자 정의 영역과 공개 코어 사이의 경계를 관리하기 위한 스킬도 제공됩니다.

update-qm은 upstream qm을 비공개 저장소에 병합하고 동기화 PR을 생성합니다.

upstream-pr은 upstream/main에서 브랜치를 만들고 조직과 무관한 수정 사항을 qm으로 보내는 역할을 합니다.

또한 upstream으로 코드를 보내기 전에 diff, 커밋 메시지, 스크린샷에서 조직 식별자를 검사합니다.

deploy/layers/ 아래의 파일은 upstream으로 전송하지 않습니다.

이 구조는 조직별 커스터마이징을 유지하면서도 공개 코어와의 차이를 가능한 한 작게 유지하려는 접근이라고 볼 수 있습니다.

qm을 사용할 때 조직이 고려해야 할 부분

qm은 단순히 설치해서 사용하는 일반적인 개인용 AI 도구와는 접근 방식이 다릅니다.

조직별 구성과 인프라가 코어와 분리돼 있으며 운영자가 자신의 Fly.io 또는 AWS 계정에 직접 배포해야 합니다.

따라서 실제 도입을 고려한다면 다음과 같은 요소를 함께 살펴볼 필요가 있습니다.

첫째, 조직에서 어떤 사용자가 어떤 범위의 에이전트 작업 공간을 사용할지 정해야 합니다.

둘째, 에이전트에게 제공할 권한과 기술 스킬의 공유 범위를 정의해야 합니다.

셋째, 조직의 보안 요구에 맞춰 Strict, Auto, Dangerous 가운데 적절한 보안 태세를 선택해야 합니다.

넷째, 샌드박스와 데이터, 커넥터 자격 증명 등 조직별 환경을 어떻게 구성할지 결정해야 합니다.

마지막으로 자체 클라우드 계정에서 배포하고 운영하는 구조인 만큼 조직의 인프라 운영 방식과도 함께 검토해야 합니다.

기여 방식과 라이선스

qm의 기여 방식도 일반적인 오픈소스 프로젝트와 조금 다릅니다.

코드 자체를 바로 제출하는 방식보다 사람이 작성한 .txt 또는 .md 문서를 통한 기여를 받습니다.

원하는 변경 사항은 adrs/에 비공식적으로 작성할 수 있으며, 프로젝트 측에서 합의한 뒤 구현합니다.

세부 규칙은 CONTRIBUTING.md에 정리돼 있습니다.

취약점은 공개 이슈가 아니라 SECURITY.md에 정의된 절차에 따라 비공개로 신고해야 합니다.

별도 표기가 없는 부분에는 MIT License가 적용됩니다.

728x90

qm은 여러 사람이 하나의 AI 에이전트를 사용하는 수준을 넘어, 조직 안에서 사람과 에이전트가 함께 일할 수 있는 실행 환경을 구성하는 데 초점을 둔 멀티플레이어 에이전트 하네스입니다.

개인별로 메모리와 파일, 권한, 키체인, 예약 작업, 웹 앱, 영구 샌드박스를 분리하면서도 Slack 채널이나 프로젝트에서는 여러 사람이 하나의 에이전트와 협업할 수 있도록 설계했습니다.

또한 Pi, OpenCode, Codex, Claude Code 등 다양한 하네스와 모델을 연결할 수 있고, 세션 저장소와 샌드박스, 메모리를 인터페이스 뒤에 배치해 특정 구현에 대한 종속성을 줄였습니다.

보안 측면에서는 Strict, Auto, Dangerous 모드를 제공하면서도 재귀 삭제나 파괴적 SQL과 같은 위험한 명령은 별도의 정책으로 강제 거부합니다. 에이전트가 사용자의 자격 증명과 권한으로 작업하고 모든 작업을 감사 기록으로 남긴다는 점도 조직 환경을 고려한 특징입니다.

배포 역시 조직별 설정과 인프라를 코어와 분리하고 운영자의 자체 Fly.io 또는 AWS 계정에서 진행하는 구조를 취합니다.

결국 qm이 보여주는 핵심 방향은 단순합니다. AI 에이전트를 개인의 생산성 도구로 사용하는 단계에서 조직의 업무 환경 안에서 함께 일하는 구성원으로 확장하는 것입니다.

개인 업무, 이메일, 내부 지식 검색, 개발 저장소, 프로젝트 관리 등 다양한 업무를 에이전트가 수행하게 되면 중요한 것은 모델 자체만이 아닙니다. 누가 어떤 범위에서 무엇을 할 수 있는지, 작업 환경을 어떻게 분리할지, 실행 결과를 어떻게 관리하고 감사할지까지 함께 설계해야 합니다.

qm은 바로 이 지점을 중심으로 조직 단위 에이전트 환경을 구성합니다. 앞으로 조직에서 AI 에이전트의 활용 범위가 넓어질수록 모델 성능뿐 아니라 권한, 격리, 협업, 실행 환경, 보안, 운영 구조를 함께 갖춘 에이전트 인프라의 중요성도 더욱 커질 것으로 볼 수 있습니다.

300x250

https://github.com/yc-software/qm

GitHub - yc-software/qm: Multiplayer agent harness for work