Cumora — AI 에이전트가 팀원이 되는 크로스플랫폼 팀 채팅

핵심 요약

• Cumora는 AI 에이전트가 사람과 같은 대화방에서 1급 팀원으로 활동하는 크로스플랫폼 팀 채팅입니다. 같은 명단, 같은 DM, 같은 그룹 대화, 같은 칸반 보드와 캘린더를 에이전트와 공유합니다 (GitHub).
• 유명 오픈소스 개발자 yetone이 만들었고, 2026-08-17 생성 하루 만에 2,179★ / 포크 232를 기록하며 오늘 인기 repo 상위권에 올랐습니다 (GitHub).
• 에이전트는 도구가 아니라 팀원으로 작동합니다. 페르소나와 메모리를 갖고, 작업을 청구하고, 서로 부딪히지 않게 조정하며, 진짜 이메일을 송수신합니다 (GitHub).
• 두 가지 '뇌' 경로를 지원합니다. Cumora Cloud(관리형 pod, OpenAI Responses API) 또는 BYOA(내 Mac/VPS에서 로컬 Claude Code·Codex CLI가 뇌)입니다 (GitHub).
• 핵심 엔지니어링은 조정(coordination) 입니다. 낡은 답변은 HELD하고 최신 메시지를 보여주고 재판단하는 freshness gate, 작업의 원자적 청구, 작은 모델로 먼저 분류해 큰 모델을 보호하는 트라이지 게이트를 갖췄습니다 (GitHub).
• 기술 스택은 실용적입니다. React 18 + Vite + Tailwind 프론트, Express + ws 백엔드, Postgres(원천) + Redis(pub/sub 팬아웃)입니다 (GitHub).
• 다만 생성 1일차라 장기 운영 안정성은 아직 검증되지 않았습니다. 조정 메커니즘은 설계 문서 기반입니다.

에이전트를 팀원으로 대한다는 것

코딩 에이전트를 쓰다 보면 어느 순간 한계를 만납니다. 에이전트는 똑똑하지만 '일'이 아니라 '질문'에 응답합니다. 사람이 질문을 던지면 에이전트가 답을 주고, 그걸 사람이 받아 다음 단계로 진행하는 구조입니다. 에이전트는 지시받은 일을 수행할 뿐, 스스로 팀의 맥락에 들어와 작업을 청구하고 다른 구성원과 조율하지 않습니다.

Cumora는 이 구조를 뒤집습니다. 정의를 고정하겠습니다. Cumora는 AI 에이전트가 사람과 같은 대화방, 같은 명단, 같은 작업 보드에서 1급 팀원으로 활동하는 크로스플랫폼 팀 채팅입니다 (GitHub). 에이전트는 그냥 '질문받는 존재'가 아니라, 페르소나와 메모리를 갖고 작업을 청구하고, 다른 에이전트와 부딪히지 않게 조정하며, 실제 이메일을 주고받는 구성원입니다.

이 컨셉이 중요한 이유는 에이전트의 역할이 '도구'에서 '동료'로 바뀌기 때문입니다. 사람이 모든 단계를 지시하는 대신, 에이전트가 팀의 맥락 안에서 스스로 일을 찾고 실행합니다. 이는 최근 다뤄진 에이전트 협업·하네스 흐름의 실용적 구현이기도 합니다.

두 가지 뇌: 클라우드와 내 머신

Cumora의 독특한 점은 에이전트의 '뇌'를 두 가지 방식으로 선택할 수 있다는 것입니다 (GitHub).

• Cumora Cloud: 각 에이전트가 관리형 pod에서 실행됩니다. 턴이 실행되면 OpenAI Responses API 위에서 다중 홉 도구 호출 루프가 돌아갑니다. bash, 파일, 브라우저, 이메일, 메모리, 스킬을 모두 사용할 수 있습니다.
• BYOA (Bring Your Own Agent): npx cumora agent computer로 내 Mac이나 VPS를 연결하면, 에이전트의 뇌가 로컬 Claude Code 또는 Codex CLI가 됩니다. 내 구독을 그대로 쓰고, 서버는 내 provider 키를 볼 수 없습니다.

BYOA가 특히 흥미롭습니다. 에이전트의 지능을 자체 구독으로 유지하면서도, 서버는 조정·저장·통신만 담당합니다. 키를 서버에 넘기지 않는다는 것은 보안과 비용 측면에서 큰 장점입니다.

아키텍처: 실용적인 스택

Cumora의 기술 스택은 화려하지 않지만 견고합니다 (GitHub).

• 프론트: React 18 + Vite + TypeScript + Tailwind. 데스크톱(Electron), PWA, iOS, Android가 같은 컴포넌트를 공유합니다.
• 백엔드: stateless Node 서비스 — Express + ws. Postgres가 원천(Source of Truth)이고, Redis가 pub/sub 팬아웃과 프레즌스(접속 상태)를 담당합니다. 로드 밸런서 뒤에서 여러 인스턴스가 Redis 버스를 통해 동기화됩니다.
• 에이전트 런타임: 클라우드 에이전트는 per-agent Kubernetes pod에서 실행됩니다. 서버가 kubectl로 조정하고, Go FUSE 드라이버가 서버 측 워크스페이스를 마운트합니다. BYOA 에이전트는 사용자 머신의 데몬으로 실행됩니다.
• LLM 비용: 클라우드든 BYOA든 모든 LLM 호출이 llm_calls 비용 원장에 기록됩니다. 비용 추적이 투명합니다.

시드는 흥미롭습니다. 빈 데이터베이스에 스타터 팀(에이전트 6명, 인간 3명, 대화 9개)을 만들지만 메시지는 0개입니다. 채팅에 보이는 모든 내용은 라이브로 생성됩니다. 즉 데모가 아니라 실제 동작하는 시스템입니다.

조정: 에이전트가 서로 부딪히지 않게

다중 에이전트의 가장 어려운 문제는 '여러 에이전트가 서로 방해하지 않고 협업하는 것'입니다. Cumora는 이 문제를 세 겹의 방어선으로 풀었습니다 (GitHub).

• seen-cursor freshness gate: 같은 방의 에이전트가 서로의 답변을 밟지 않게 합니다. 낡은 답변은 HELD(보류)되고, 최신 메시지를 보여준 뒤 재판단하도록 합니다. 에이전트가 오래된 상태를 보고 잘못된 답을 내는 것을 막습니다.
• 원자적 작업 청구: 에이전트가 실제 작업 단위에 대해 원자적 클레임을 겁니다. 두 에이전트가 같은 작업을 동시에 하는 충돌을 방지합니다.
• small-brain 트라이지 게이트: 작은(저비용) 모델로 작업을 먼저 분류해, 큰(고비용) 모델을 보호합니다. 모든 작업을 비싼 모델에 보내지 않아 비용을 절감합니다.

이 조정 메커니즘을 검증하기 위해 실제 LLM을 쓰는 벤치마크(chain, counting, werewolf, kanban)도 포함합니다. 에이전트들이 복잡한 조정 상황에서 어떻게 협업하는지 측정합니다. 단순한 아이디어가 아니라, 조정의 설계 원리를 문서(docs/COORDINATION.md)로 정리하고 벤치마크로 검증하려는 의도가 보입니다.

판단과 실행 체크리스트

Cumora는 '에이전트를 팀원으로'라는 컨셉을 실용적인 스택으로 구현한 흥미로운 프로젝트입니다. 다만 표본 한계를 명확히 해야 합니다. 생성 1일차라 장기 운영 안정성이 검증되지 않았고, 조정 메커니즘은 설계 문서 기반이며, 에이전트가 실제로 '유용한 일'을 하는지(결과 품질)는 주관적입니다 (GitHub).

에이전트 팀 협업을 고민한다면, Cumora에서 얻을 수 있는 시사점은 다음과 같습니다.

• 1단계 — 에이전트를 '질문 응답자'에서 '작업 소유자'로 바꿉니다. 작업을 청구하고 완료까지 책임지는 구조를 설계합니다.
• 2단계 — 조정을 설계의 일부로 합니다. freshness gate(낡은 상태 무시), 작업 원자적 청구, 비용 트라이지 같은 메커니즘을 미리 넣습니다.
• 3단계 — 키는 내가 보관합니다. BYOA처럼 에이전트 지능은 자체 구독으로, 서버는 조정·저장만 담당하게 해 키 노출을 막습니다.
• 4단계 — 비용을 투명하게 추적합니다. 모든 LLM 호출을 비용 원장에 기록해, 에이전트가 많아져도 비용을 통제합니다.

결론은 이렇습니다. Cumora는 에이전트가 도구가 아니라 팀원이 되는 시대의 한 예시입니다. 하루 만에 2,179★를 받은 것은 이 컨셉이 시장의 기대를 반영한다는 뜻입니다. 다만 아직 시작점이므로, 조정 메커니즘이 실전에서 검증되며 진화해 나갈지 지켜볼 만합니다.