qm, 팀이 함께 쓰는 격리형 AI 작업 공간 공개

AI 도구를 회사 전체로 넓히면 개인용 챗봇과는 다른 문제가 생겨요. 직원마다 접근할 수 있는 자료가 다르고, 여러 명이 같은 업무를 이어서 처리할 때는 기록과 권한의 경계도 필요해요. 오픈소스 프로젝트 qm은 사람과 대화 공간마다 작업 환경을 분리하는 방식으로 이 문제를 풀려고 해요. 1
핵심 요약
| 구분 | 핵심 | 왜 볼 만한가요 |
| 협업 구조 | 개인 공간과 공유 공간을 나눠 여러 사람이 같은 AI와 일할 수 있어요 | 개인용 도구를 조직 단위로 확장할 때 필요한 권한 경계를 제품 구조에 넣었어요 |
| 실행 환경 | 메모리, 파일, 자격 증명 보기, 예약 작업, 영구 샌드박스를 공간별로 분리해요 | 한 사람의 작업과 다른 팀의 작업이 섞이는 위험을 줄이는 설계예요 |
| 모델 선택 | Pi, OpenCode, Codex, Claude Code를 같은 코어에 연결할 수 있어요 | 특정 모델이나 공급자에 묶이지 않고 조직 정책에 맞춰 선택할 수 있어요 |
| 운영 방식 | 운영자가 Fly.io 또는 AWS 계정에 직접 배포해요 | 데이터 위치와 클라우드 비용을 조직이 직접 관리할 수 있어요 |
1. 개인용 AI를 팀의 작업 공간으로 넓힌 qm
qm은 직원마다 독립된 공간을 주고, 프로젝트나 대화방에는 여러 사람이 함께 쓰는 공간을 만들어요. 각 공간은 메모리, 파일, 권한, 자격 증명 보기, 예약 작업과 영구 샌드박스를 따로 가져요. 개인 업무에서 만든 상태가 다른 사람의 작업에 바로 섞이지 않으면서도, 공동 프로젝트에서는 같은 맥락을 이어갈 수 있는 구조예요. 웹에서도 같은 신원과 설정을 유지해 작업 위치가 바뀌어도 권한 기준은 이어져요. 2
모델보다 범위와 권한을 먼저 설계했어요
여러 사람이 AI를 함께 쓰면 답변 품질만큼 "누가 어떤 자료와 도구를 쓸 수 있는가"가 중요해져요. qm은 개인과 공유 공간을 기본 단위로 삼고, 관리자가 조직 수준의 보안 설정과 허용 모델을 정하게 했어요. 기술 스킬도 소유 범위와 공유 권한을 나누며, 조직 전체에 배포할 때는 관리자 승인을 거쳐요.
모델 선택지는 하나로 고정하지 않았어요. Pi, OpenCode, Codex, Claude Code가 같은 코어를 사용할 수 있고, 세션 저장소와 메모리, 샌드박스도 교체 가능한 인터페이스 뒤에 놓였어요. 팀이 모델을 바꾸더라도 사용자와 프로젝트의 운영 구조를 전부 다시 만들지 않도록 한 선택이에요. 2
승인 모드가 있어도 별도 보안 검토는 필요해요
보안 설정은 Strict, Auto, Dangerous 세 단계예요. Strict는 대부분의 도구 실행 전에 사람의 승인을 기다려요. Auto는 출처가 표시된 외부 데이터와 도구 결과를 분류기로 검사해요. Dangerous는 검사와 승인 대기를 줄이지만, 재귀 삭제나 파괴적 SQL처럼 사전에 막아 둔 명령 정책은 계속 적용돼요.
다만 프로젝트 문서는 이 소프트웨어가 아직 초기 단계라고 밝혀요. 명령 정책은 난독화된 명령이나 스크립트 실행으로 우회될 수 있고, 사용 중인 자격 증명은 샌드박스 프로세스가 읽을 수 있어요. 브라우저 작업 일부는 코어의 승인 절차를 다시 거치지 않는다는 제한도 있어요. 감사 기록은 사고 조사를 돕지만 실행 자체를 막지는 않아요. 실제 회사 자료를 연결하려면 선택한 모드만 믿기보다 클라우드 계정, 네트워크, 자격 증명 수명과 관리자 권한을 함께 검토해야 해요. 3
자체 클라우드에 배포하는 오픈소스 구조예요
qm은 운영자가 소유한 Fly.io나 AWS 계정에 배포해요. 조직별 설정과 사용자 정의 도구, 샌드박스 이미지, 인프라는 코어 코드와 분리된 배포 디렉터리에 둬요. Node에서 TypeScript를 실행하고 Fastify, PostgreSQL, Vite, Lit 등을 사용해 코어와 웹 화면을 구성해요.
이 방식은 SaaS 계정을 열고 바로 쓰는 제품보다 초기 설정이 많아요. 반대로 데이터 저장 위치, 허용 모델, 클라우드 비용과 조직별 확장을 직접 관리하려는 팀에는 선택지가 넓어요. 저장소는 MIT 라이선스로 공개됐고, 설치와 배포 절차도 문서로 제공돼요. 2
왜 중요한가요
업무용 AI의 운영 문제는 여러 사용자가 같은 봇을 호출할 수 있느냐에서 끝나지 않아요. 직원별 권한, 공유 프로젝트의 기억, 실행 환경, 자격 증명, 예약 작업과 감사 기록을 한 체계에서 다뤄야 해요. qm은 이 요소를 개인 공간과 공유 공간으로 나눠 제품의 기본 구조에 넣었어요. 팀 단위 AI를 검토하는 개발자라면 모델 성능 비교와 함께 범위 분리 방식도 확인할 만해요. 2
도입 판단에서는 공개 저장소의 기능 목록보다 보안 문서가 더 중요해요. 프로젝트가 직접 밝힌 우회 가능성과 자격 증명 노출 범위를 먼저 읽고, 실제 조직의 위협 모델에 맞는지 확인해야 해요. 공개 초기 단계인 만큼 작은 비민감 업무에서 권한과 감사 기록을 검증한 뒤 연결 범위를 넓히는 편이 안전해요. 3
참고 자료
- qm - 협업을 위한 멀티플레이어 에이전트 하네스 — GeekNews
- yc-software/qm — GitHub
- QM Security policy — GitHub
'IT & AI' 카테고리의 다른 글
| Rails Action Text에 맞춘 리치 텍스트 에디터 Lexxy (0) | 2026.08.02 |
|---|---|
| AI 에이전트가 181개 노드를 등록한 경로, Tailscale이 돌아본 장기 키 (0) | 2026.08.01 |
| AI가 글쓰기 비용까지 낮춘 뒤, 출판은 무엇을 증명해야 할까요 (0) | 2026.08.01 |
| DeepSeek V4 Flash 0731, 50점 성능과 낮은 API 가격의 조건 (1) | 2026.08.01 |
| Chrome 보안 버그 1,072개, AI가 바꾼 취약점 대응 속도 (0) | 2026.08.01 |