Cindy: Claude Code와 Codex를 하나의 로컬 에이전트로 묶는 오픈소스 클라이언트

무엇인가: 여러 코딩 에이전트를 묶는 로컬 클라이언트

Cindy(makecindy/cindy)는 "Consider it done"을 내건 오픈소스 AI 에이전트 클라이언트입니다. Claude Code, Codex 같은 서로 다른 코딩 에이전트를 오가는 대신, 여러 하네스(에이전트 실행 기반), 모델, 도구를 하나의 에이전트로 묶습니다. 이 에이전트는 사용자의 컴퓨터에서 실행되며 실제 파일과 이미 로그인된 앱을 사용해 일을 처리합니다. 라이선스는 Apache-2.0이고 pnpm 모노레포 구조입니다. Electron 데스크톱 앱, Expo / React Native 모바일 앱, 그리고 인증, 기기 연결, 에이전트 오케스트레이션, 모델 공급자 등의 공유 패키지가 들어 있습니다.

먼저 짚어야 할 점이 있습니다. 이 저장소에는 클라이언트만 있습니다. README는 백엔드 서비스가 별도 저장소에 있으며 이 모노레포에 포함되지 않는다고 밝힙니다. 여기서 "오픈소스"는 클라이언트 소스 코드를 뜻하며, 클라우드 서비스 전체를 뜻하지 않습니다.

핵심 구조: 하네스, 모델, 도구의 분리

README 설명으로 보면 설계는 세 가지를 분리합니다. 첫째는 하네스입니다. 처음 지원하는 것은 Claude Code와 Codex이며, 더 추가할 예정이고 자체 네이티브 하네스도 개발 중이라고 합니다. apps/*-bin 디렉터리에는 데스크톱 앱과 함께 배포되는 도구 바이너리가 있습니다. claude-code, codex, ripgrep은 pnpm install 때 플랫폼별로 내려받고, Android platform-tools는 Windows 패키징 전에 버전을 고정하고 sha256을 검증해서 가져옵니다. 즉 Cindy는 코딩 에이전트를 새로 만드는 것이 아니라, 기존 에이전트 CLI를 교체 가능한 실행 엔진으로 내장해 다룹니다.

둘째는 모델입니다. 모델과 하네스는 자유롭게 조합할 수 있고 작업 도중에도 바꿀 수 있습니다. README는 모델을 가져오는 네 가지 방법을 듭니다. 공식 Cindy 서비스에 로그인해 사용량을 투명하게 차감받는 방법, 이미 결제 중인 Claude Code / Codex Coding Plan을 인증해 중복 결제 없이 Cindy에서 계속 쓰는 방법, 자신의 API 키를 연결하는 방법, 로컬 모델을 쓰는 방법입니다. 셋째는 엔진을 바꿔도 이어지는 작업 환경입니다. 워크스페이스, 메모리, 스킬, 도구는 하네스나 모델을 바꿔도 유지됩니다. 이 부분이 설계에서 가장 가치 있고 가장 어렵습니다. 에이전트마다 컨텍스트, 도구 호출 형식, 스킬 기술 방식의 약속이 다르기 때문에, 엔진을 바꿔도 상태를 잃지 않으려면 자체 추상화 계층이 필요합니다.

멀티 에이전트 협업: 계획, 병렬 실행, 교차 검토

README에 따르면 하나의 작업을 서로 다른 하네스와 모델 조합의 에이전트가 계획하고, 병렬로 실행하고, 검토할 수 있습니다. 이는 최근 멀티 에이전트 개발에서 흔한 방식과 같습니다. 한 모델이 작업을 나누고, 여러 실행자가 겹치지 않는 범위에서 동시에 일하며, 출처가 다른 모델이 결과를 독립적으로 검토합니다. 같은 모델이 자기 결과를 검토할 때 생기는 맹점을 줄이는 효과가 있습니다. Cindy는 이 흐름을 제품 기능으로 제공하므로 사용자가 스크립트를 직접 이어 붙일 필요가 없습니다.

코드 작업 외에도 브라우저, 컴퓨터, 휴대폰을 조작할 수 있고, 메신저(IM)와 일정에서 작업을 받을 수 있습니다. 목표는 코딩 보조에 그치지 않는 상시 범용 업무 에이전트로 보입니다.

"직접 빚어 쓰는" 계층: 메모리, 스킬, 자동화, MCP, 플러그인

확장성은 "Yours to shape"라는 말로 정리됩니다. 메모리는 한 번 고쳐 주면 이후 하네스를 가로질러 공유됩니다. 스킬은 일하는 방식을 한 번 가르치면 어디서나 재사용하며, 팀 배포 기능은 개발 중입니다. 자동화는 반복 작업이 스스로 일정을 잡고 실행하고 보고합니다. MCP는 사내 도구와 업무 시스템을 연결합니다. 플러그인은 열린 마켓플레이스로 공유하는 구상이며 이 또한 준비 중입니다. 현재는 SkillHub 또는 수동으로 설치합니다. 소스 코드는 감사, 포크, 확장, 기여가 가능합니다.

배포와 사용 방식

로그인 화면에는 두 가지 모드가 있습니다. Cindy 클라우드 계정을 쓰는 호스팅 서비스와, 계정 없이 로컬 에이전트를 실행하는 "Skip Sign-In"입니다. 후자에서는 앱에 "로그인하지 않음"으로 표시되고 서버에 의존하는 기능은 쓸 수 없습니다. 클라이언트는 기본적으로 공식 클라우드 서비스에 접속합니다. 엔드포인트 매니페스트는 config/endpoint.json과 config/endpoint.global.json이며, 데스크톱 자동 업데이트도 공식 CDN에서 받습니다. 개발할 때는 pnpm restart:desktop:remote --region=cn 또는 --region=global로 자신의 Cindy 계정에 연결해 작업합니다. 요구 사항은 Node.js 22.x, pnpm 10.x(v11은 아직 미지원), Git LFS입니다. Linux 사용자를 위해 Ubuntu, Arch Linux, Omarchy 설치 안내가 있습니다.

성능과 비용: 공개된 벤치마크는 아직 없음

이 점은 분명히 말해야 합니다. README에는 벤치마크 수치가 없고 지연 시간, 성공률, 비용 비교도 없습니다. 따라서 Claude Code나 Codex를 단독으로 쓸 때보다 얼마나 빠르고 정확한지는 이 자료로 판단할 수 없습니다. 확실한 것은 비용 구조뿐입니다. 기존 Coding Plan을 인증하면 중복 청구가 없고, 공식 서비스를 쓰면 사용량이 차감되며, 자체 키나 로컬 모델은 사용자가 비용을 부담합니다. 여러 에이전트의 병렬 검토는 토큰 사용량을 늘립니다. 이는 이런 설계 전반의 절충이며, 실제 수치는 운용하며 측정해야 합니다.

영향, 한계, 전망

개발자에게 가치는 에이전트 도구 사이에서 컨텍스트를 옮기는 수고가 줄고, 검토 단계가 워크플로에 제도화된다는 점입니다. 기업에는 Apache-2.0 클라이언트, 감사 가능한 소스, 실제 파일을 쓰는 로컬 실행이 매력적입니다. 다만 데이터 경로는 선택한 모델 제공처와 공식 클라우드 사용 여부에 따라 달라집니다.

한계도 분명합니다. 첫째, 백엔드가 공개되지 않아 호스팅 서비스의 동작을 감사할 수 없습니다. 둘째, 실제 파일, 로그인된 앱, 휴대폰을 다루는 에이전트는 권한 범위가 매우 넓어 프롬프트 인젝션과 오동작 위험을 사용자가 직접 평가하고 격리해야 합니다. 셋째, Claude Code와 Codex 같은 상위 CLI에 의존하므로 그쪽 인터페이스나 약관이 바뀌면 Cindy가 직접 영향을 받습니다. 넷째, 네이티브 하네스, 팀 스킬 배포, 플러그인 마켓플레이스는 모두 준비 중이라 로드맵이 아직 실현되지 않았습니다. 앞으로 볼 지점은 네이티브 하네스 출시, 더 많은 하네스 지원, 독립적인 제3자 평가, 보안 모델의 문서화입니다.