Cumora: AI 에이전트들과 업무를 나누고 진행 상황을 공유하는 에이전트 팀을 위한 채팅 앱

9bow · 8월 20, 2026, 3:30오전

Cumora 소개

팀 협업 도구에 AI를 들이는 방식은 대체로 채팅방 한쪽에 봇을 하나 붙이는 형태였습니다. 사람이 멘션으로 부르면 답하고, 답이 끝나면 그 대화는 거기서 끊깁니다. 그런데 봇을 두 개 이상 연동하면 다른 문제가 생깁니다. 같은 방에 있는 여러 에이전트가 같은 메시지를 각자 읽고 각자 판단하기 때문에, 둘이 같은 순간에 깨어나 같은 내용을 나란히 올리는 충돌이 일어납니다. Cumora 개발팀은 이 상황을 서버가 잡아낼 수 있는 경합 충돌(Race Collision)과 프롬프트로만 다룰 수 있는 판단 오류(Brain Misjudgment) 두 가지로 나눠 정리하고 있습니다.

이번에 소개할 Cumora는 AI 에이전트를 채팅방의 정식 참가자로 두는 크로스 플랫폼 팀 채팅 앱입니다. 에이전트는 사람과 같은 멤버 목록, 같은 DM(Direct Message), 같은 그룹 대화, 같은 칸반 보드와 캘린더를 씁니다. 각 에이전트는 자기 역할과 말투를 정한 페르소나(Persona)와 개인 작업 공간의 기억(Memory)을 유지하고, 호출을 기다리지 않고 스스로 대화를 시작하거나 다른 에이전트에게 DM을 보냅니다. 프로젝트를 공개한 yetone은 에이전트의 두뇌를 두 갈래로 나눠 두었습니다. 하나는 OpenAI Responses API 위에서 도는 관리형 클라우드이고, 다른 하나는 사용자의 맥이나 VPS에서 Claude Code 또는 Codex CLI를 그대로 두뇌로 쓰는 BYOA(Bring Your Own Agent) 방식입니다.

Cumora의 코드베이스는 하나의 저장소 안에서 클라이언트와 서버, 에이전트 런타임(Runtime)을 모두 담고 있습니다. 화면은 React 18과 Vite, TypeScript, Tailwind로 만든 단일 컴포넌트 집합 위에 데스크톱과 모바일, 웹, 관리자 셸을 얹는 구조이고, 데스크톱은 Electron, iOS와 안드로이드는 Capacitor 네이티브 셸을 씁니다. 서버는 Express와 ws 기반의 무상태 노드 서비스로, Postgres를 진실 공급원(Source of Truth)으로 두고 Redis를 발행 구독(Pub/Sub) 팬아웃과 접속 상태 공유에 사용합니다. 인바운드 메일 처리와 서명된 CDN은 Cloudflare Workers로 분리되어 있습니다. 저장소는 MIT 라이선스로 공개되어 있고, 같은 팀이 cumora.ai에서 관리형 클라우드인 Cumora Cloud를 함께 운영하며 홈페이지에는 프리뷰 기간 동안 무료라고 적혀 있습니다.

기존 방식과 Cumora의 차이

사람과 AI 에이전트를 한 채널에 모으는 시도는 이전에도 있었습니다. PyTorchKR에도 사람과 AI 에이전트가 같은 채널에서 일하도록 하는 자체 호스팅 워크스페이스 Buzz, 공유 브레인을 가진 AI 직원들의 협업 오피스 플랫폼 WUPHF, 팀원마다 격리된 작업 공간을 갖는 QM이 소개되어 있고, Anthropic도 Slack에서 @Claude를 팀원처럼 호출하는 Claude Tag를 내놓았습니다.

Cumora가 이들과 다른 지점은 두 가지입니다. 첫째로 에이전트가 대화 상대가 아니라 멤버 목록의 한 줄을 차지합니다. 사람 참가자와 마찬가지로 DM을 받고, 칸반 카드를 직접 맡고, 실제 이메일 주소로 메일을 주고받습니다. 둘째로 여러 에이전트가 한 방에서 동시에 깨어났을 때를 서버가 직접 중재합니다. Cumora 개발팀은 코드로 고쳐야 할 문제에 프롬프트 규칙을 더하지 말고, 반대로 올바른 상태를 보고도 모델이 잘못 판단하는 문제에 코드 장치를 더하지 말라는 원칙을 세워 두었습니다.

Cumora의 두 가지 두뇌 경로

Cumora에서 에이전트는 항상 어떤 컴퓨터(Computer) 위에서 돕니다. Cumora Cloud는 회사마다 하나씩 기본 제공되는 관리형 컴퓨터이고, 사용자가 직접 연결한 맥이나 VPS는 각자 하나의 컴퓨터가 됩니다. 에이전트를 만들 때 어느 컴퓨터에 둘지 고르는 것이 전부이고, 그 컴퓨터가 꺼지면 에이전트는 고장이 아니라 잠든 상태로 표시됩니다. 두 경로의 차이는 다음과 같습니다:

항목	Cumora Cloud	BYOA (Bring Your Own Agent)
두뇌	서버의 `turn.ts` 멀티홉 루프 + OpenAI Responses API	로컬의 Claude Code 또는 Codex CLI
실행 위치	에이전트마다 별도의 Kubernetes 파드	사용자의 맥 또는 VPS에서 도는 데몬(Daemon)
API 키	Cumora가 관리	사용자 구독을 그대로 사용, 서버는 키를 보관하지 않음
컨텍스트 관리	Cumora가 담당	엔진 자체의 에이전트 루프와 컨텍스트 관리에 위임
설정	별도 준비 없이 항상 온라인	`npx cumora agent computer`로 기기를 연결

BYOA에서 turn.ts는 통째로 우회됩니다. Cumora가 하는 일은 깨우기 신호를 보내고, 그 신호를 통과시킬지 판정하고, 짧은 턴 프롬프트를 만들어 넘긴 뒤, 엔진이 cumora CLI로 세상에 작용하는 것을 기록하는 데까지로 줄어듭니다. 이 구조가 가능한 이유는 Cumora의 입출력 표면이 두뇌와 분리되어 있기 때문입니다. 에이전트가 쓰는 reply, dm, memory, workspace, card 같은 명령은 모두 argv를 /runtime/cli로 POST하는 얇은 전달 계층(Shim)이고, 클라우드 호출이든 BYOA 호출이든 모든 LLM 호출은 llm_calls라는 하나의 비용 원장에 기록됩니다.

Cumora가 에이전트 충돌을 막는 방법

한 대의 컴퓨터에서 여러 에이전트가 같은 SSE(Server-Sent Events) 이벤트로 동시에 깨어나면, 그 순간 로컬 CLI와 모델 제공자 계정을 동시에 두드리게 됩니다. Cumora 개발팀은 7개 에이전트가 참여한 카운팅 게임에서 17분 동안 130건의 속도 제한(Rate Limit)이 발생한 사례를 기록해 두었습니다. 반대로 큰 모델의 동시 실행 한도가 2였던 시절에는 7개 에이전트가 있는 방송형 방에서 턴이 6단계까지 밀려, 뒤쪽 에이전트가 215초에서 359초 동안 아무 말도 못 하고 서 있었습니다. Cumora 개발팀은 이 사이를 맞추기 위한 방어 계층을 항상 켜져 있는 것부터 프롬프트에 맡기는 것까지 순서대로 docs/COORDINATION.md에 정리해 두었습니다.

주요 계층은 다음과 같습니다:

에이전트별 모델 고정: 서버가 participants.model이 비어 있을 때 배포 환경 변수의 모델을 대신 넣어 주고, 데몬은 그 값을 --model 인자로 명시해 실행합니다. 로컬 CLI가 기본 모델을 조용히 바꾸면 사용자마다 동작이 달라지기 때문에 넣은 장치입니다.
컴퓨터별 동시 실행 한도: 큰 모델은 기본 6개, 분류용 작은 모델은 기본 8개까지만 동시에 띄웁니다. 두 한도는 짝으로 관리하며, 한쪽만 걸면 다른 쪽에서 병목이 생겨 컴퓨터 전체가 조용해지는 실패가 관측됐습니다.
결정적 실행 간격: 모든 로컬 CLI 실행은 직전 실행으로부터 최소 500밀리초 뒤에 시작합니다. 이전에는 0에서 1500밀리초 사이의 무작위 지연을 썼는데, 확률적 방식이라 동시에 깨어난 네 에이전트가 모두 낮은 값을 뽑으면 여전히 한꺼번에 몰릴 수 있어 고정 간격으로 바꿨습니다.
서버의 신선도 선점 검사: 에이전트가 답을 올리기 직전에 서버가 그 에이전트가 마지막으로 본 시점 이후에 새 메시지가 들어왔는지 확인합니다. 뒤처진 답은 보류(HELD) 처리하고 새 메시지를 보여 준 뒤 다시 판단하게 합니다.
작은 모델 분류 관문: 깨우기 신호가 올 때마다 큰 모델을 부르지 않고, 먼저 작은 모델이 이번 턴에 이 에이전트가 나설 자리인지 판정합니다.

또한 Cumora 개발팀은 같은 문서에 하지 말아야 할 일도 따로 모아 두었습니다. 프롬프트로 인프라 문제를 고치지 말 것, 관측된 사고 하나를 막으려고 상황별 프롬프트를 덧붙이지 말 것, 이미 루프 방지 장치가 있는데 또 쌓지 말 것 같은 항목이 그 이유와 함께 적혀 있습니다.

Cumora의 멀티 에이전트 조정 벤치마크

Cumora는 조정 계층이 퇴행했는지 확인하기 위한 벤치마크를 저장소에 함께 두고 있습니다. 단위 테스트로는 잡히지 않는 경합 조건이나 분류기 장애 시의 대체 동작을 실제 LLM으로 확인하는 것이 목적입니다. 하네스(Harness)는 사람 사용자처럼 새 그룹 대화에 메시지를 하나 올린 뒤, 종료 조건이 만족되거나 시간이 다 될 때까지 메시지 테이블을 4초 간격으로 확인합니다. 판정은 시행 하나가 아니라 시행 표본 전체에 대한 통계로 내립니다. 저장소에 들어 있는 시나리오는 네 가지입니다:

시나리오	확인하는 것	시행당 소요	시행당 비용
`chain`	한 명이 일부러 빠진 상태에서 N글자를 순서대로 이어 붙이기	5~8분	$3~5
`counting`	각 에이전트가 정확히 하나의 숫자만 말하며 1부터 K까지 세기	3~5분	$1~2
`werewolf`	심판이 상태 기계를 진행시키는 다회차 역할극	15~25분	$15~25
`kanban`	서로 다른 에이전트 둘 이상이 참여해 미리 만들어 둔 카드를 완료 열까지 옮기기	20~30분	$8~15

chain과 counting은 의도적으로 서로 뒤집힌 모양입니다. chain은 팀이 빠진 멤버를 대신해 한 번 더 나서는지를 보고, counting은 명시적인 상한이 있을 때 넘지 않는지를 봅니다. 어느 방향으로 원칙이 깨지든 둘 중 하나에서만 드러나도록 설계한 것입니다. 다만 비용은 실제로 청구됩니다. Cumora 개발팀은 Opus 4.7을 쓰는 7개 에이전트 구성을 기준으로, 네 시나리오를 모두 주 1회 실행하면 대략 58달러에서 101달러가 든다고 밝히고 있습니다. 기본 워크플로는 값이 싼 chain과 counting만 정기 실행하고 나머지는 필요할 때 수동으로 실행하도록 되어 있습니다.

Cumora 설치 및 실행

Cumora는 데스크톱 앱과 웹 앱을 함께 제공하며, 소스에서 직접 띄울 수도 있습니다. 로컬 실행에는 Postgres와 Redis가 필요하고, 반드시 있어야 하는 환경 변수는 OPENAI_API_KEY 하나뿐입니다:

createdb -h localhost cumora
export OPENAI_API_KEY=sk-...

npm run setup          # 루트 + 이메일 워커 의존성 설치
npm run dev:all        # Vite 렌더러(:5180) + API 서버(:5181)

이때 스키마는 부팅할 때 멱등하게 생성됩니다. 빈 데이터베이스에는 에이전트 6명과 사람 3명, 대화 9개로 이뤄진 시작 팀이 들어가되 메시지는 0건으로 채워집니다. 채팅에 보이는 내용은 전부 실행 중에 만들어지는 셈입니다. 데이터베이스 접속 정보와 Redis 주소, 포트는 기본값이 있고, 로그인 연동과 이메일, 저장소, 푸시 같은 선택 기능은 설정하지 않으면 비활성 상태로 넘어갑니다.

내 컴퓨터를 에이전트의 두뇌로 쓰려면 BYOA 데몬을 실행합니다. 배포된 npm 패키지 이름은 cumora입니다:

npx cumora agent computer

전체 구성은 아래와 같이 프런트엔드, 앱 워커, 에이전트 실행 환경의 세 덩어리로 나뉩니다:

 Electron / PWA / iOS / Android         ┌─────────────────┐
 ┌──────────────────┐   HTTP / WS       │   App workers   │──▶ OpenAI (Responses API)
 │    React UI      │ ◀───────────────▶ │  Express + ws   │──▶ Resend (email out)
 └──────────────────┘                   │    (any N)      │──▶ APNs / FCM (push)
                                        └───┬────────┬────┘
 Cloudflare Workers                         │        │ kubectl
 ┌─────────────────┐   webhooks / R2   ┌────▼───┐ ┌──▼──────────────┐
 │ email-gate      │ ────────────────▶ │Postgres│ │ Agent pods (K8s)│
 │ r2-gate (CDN)   │                   │ Redis  │ │ or BYOA daemons │
 └─────────────────┘                   └────────┘ └─────────────────┘

Cumora는 누구에게 유용한가

이미 Claude Code나 Codex 구독을 쓰고 있고 그 구독을 여러 에이전트가 나눠 쓰는 팀 단위 작업으로 넓히고 싶다면, BYOA 경로가 잘 맞습니다. 서버가 제공자 키를 보관하지 않고 데스크톱 앱이 배포되어 있어서, 클라우드 요금제를 새로 만들지 않고도 기존 구독 위에서 시작할 수 있기 때문입니다. 여러 에이전트를 한 계정으로 동시에 실행해 본 적이 있다면 docs/COORDINATION.md만 따로 읽어도 얻는 것이 있습니다. 속도 제한 130건이나 침묵 359초처럼 실제로 관측된 수치와, 그때 무엇을 고쳤고 무엇을 되돌렸는지가 함께 적혀 있기 때문입니다.

반대로 자체 호스팅을 곧바로 업무에 투입하려는 경우에는 준비할 것이 적지 않습니다. 클라우드 에이전트를 직접 운영하려면 Postgres와 Redis에 더해 Kubernetes 클러스터와 kubectl 호출 경로까지 필요하고, 저장소가 2026년 8월 17일에 공개되어 2026년 8월 19일 기준으로 아직 며칠 지나지 않은 상태이기 때문입니다. 에이전트를 하나만 두고 쓸 계획이라면 조정 계층이 주는 이득이 크지 않으므로, 기존의 단일 에이전트 도구를 그대로 쓰는 편이 설치 비용 대비 낫습니다.

Cumora의 라이선스

Cumora는 MIT 라이선스로 공개되어 있어 개인 및 상업적 목적으로 자유롭게 사용할 수 있습니다.

Cumora 공식 홈페이지

Cumora 웹 앱 (관리형 Cumora Cloud에서 실행)

Cumora 프로젝트 GitHub 저장소

더 읽어보기

이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다.

이 도구를 직접 설치해 사용해보셨다면, 파이토치 한국 사용자 모임 회원들을 위해 경험이나 팁을 댓글로 남겨주세요!