한 줄 요약: makecindy/cindy는 에이전트 루프를 새로 짜지 않습니다. 이미 잘 돌아가는 Claude Code·Codex·Pi 하네스 바이너리를 그대로 띄우고, 그 바깥의 메모리·스킬·MCP·플러그인·스케줄·메신저·휴대폰 원격 같은 연결층을 맡는 오픈소스 클라이언트입니다. 저장소에는 Electron 데스크톱 앱, Expo/React Native 모바일 앱, 공유 패키지 34개가 pnpm 모노레포로 들어 있고 라이선스는 Apache-2.0입니다. 백엔드 서버는 이 저장소에 없습니다. 이 글에서는 구조와 동작 방식, 멀티 에이전트 협업 기능 Orca, 다른 앱이 붙는 로컬 Agent API, 그리고 문서에 스스로 적어 둔 보안 공백까지 차례로 살펴봅니다. 마지막으로 박스에서 의존성 없는 패키지 두 개를 떼어 테스트를 돌린 결과도 정리했습니다.
1. 왜 지금 트렌딩 1위인가
2026-10-26(월) 오전 GitHub Trending 데일리 전체 1위(오늘 +675), TypeScript 1위에 올랐습니다. 생성된 지 석 달 남짓 된 저장소인데 커밋 수가 약 1만 개에 이르고 릴리스도 거의 매일 나옵니다. 중국 게임사 XD Inc.(TapTap 운영사)가 저작권자로 표기돼 있고, 중국 본토용(cn)과 글로벌용(global) 빌드를 따로 배포합니다. README의 첫 문장 “Consider it done(맡기면 끝낸다)”이 제품의 방향을 요약합니다. CLI나 API 키, MCP를 공부하고 싶지 않은 사람도 강력한 에이전트를 쓸 수 있게 하자는 것입니다.
| 항목 | 값 (2026-10-26 KST 확인) | 메모 |
|---|---|---|
| 저장소 | makecindy/cindy |
홈페이지 cindy.app |
| 라이선스 | Apache-2.0 | NOTICE: Copyright 2026 XD Inc. 모델 가중치·프롬프트·상표 등은 별도 조건 |
| 스타 / 포크 | 약 5,030 / 677 | GitHub API, 오전 11시 50분대 (KST) |
| 트렌딩 | 데일리 전체 1위 (+675), TypeScript 1위 | 같은 날 전체 2위는 Nutlope/hallmark(+1,317) |
| 생성일 | 2026-07-23 (KST) | 약 3개월 차 |
| 최신 릴리스 | v0.1.115 (2026-10-23 11:46 KST) | macOS(arm64/x64)·Windows x64·Linux x64 .deb, 각각 cn/global 총 8개 파일 |
| 릴리스 수 | 72개 | v0.1.111-beta → 112 → 113 → 114 → 115가 10/19~10/23 사이 하루 한 번꼴 |
| 커밋 / 기여자 | 약 10,150 / 약 164명(익명 포함) | GitHub API 페이지 수 기준 추정치 |
| 열린 이슈 | 1,924개 | PR 포함 수치 |
| 최근 커밋 | 7c5bd270c (2026-10-26 05:26 KST) |
이 글은 이 커밋을 기준으로 읽었습니다 |
| 개발 요구사항 | Node.js 22.12 이상, pnpm 10.7 이상 11 미만, Git LFS | Electron은 apps/desktop/package.json에 42.11.12로 고정 |
2. 제품 철학: “지능을 다시 만들지 말고, 연결하라”
docs/product-rules/core-product-principles.md는 ‘권위 문서(authoritative)’로 지정돼 있고, 내용이 꽤 단호합니다. Cindy는 Claude Code나 Codex 같은 에이전트 루프를 다시 구현하는 것을 목표로 하지 않으며, 하위 모델이나 에이전트가 원래 가진 능력을 자기 ‘지능’인 것처럼 포장하지 않는다고 적혀 있습니다. 대신 다섯 가지를 연결하는 일을 맡습니다. 사람과 에이전트, 에이전트와 실제 파일·앱·기기, 작업 과정과 결과물, 개인과 조직의 작업 방식, 그리고 여러 기기에 걸친 같은 작업입니다.
“3.1 상위 능력 비퇴화 원칙”이 특히 눈에 띕니다. 순정 Pi로 할 수 있는 설치·업데이트·자가 복구는 Cindy 안의 Pi에서도 되어야 합니다. Cindy가 추가한 정적 스캔이나 위험 판단은 건너뛸 수 있는 진단으로만 남아야 하고, 원래 쓸 수 있던 패키지를 막거나 끄면 안 됩니다. 분석기가 실패하면 Pi 원래 동작으로 돌아가야 하며, ‘더 안전해지려고’ 원래 기능을 줄이는 방안은 예외 없이 허용하지 않습니다. 보안 담당자 입장에서는 불편할 수 있는 원칙입니다. 그래서 4장의 신뢰 경계와 함께 읽어야 합니다.
3. 저장소 구조: 어디에 무엇이 있나
최상위에는 apps/(데스크톱, 모바일, 헤드리스, Android 플랫폼 툴 바이너리), packages/(공유 패키지 34개), tools/(하네스 버전 고정과 업데이트 스크립트), docs/(규칙 문서)가 있습니다. TypeScript 파일은 1만 개가 넘습니다. 문서 대부분이 중국어로 쓰여 있다는 점은 미리 알아 두는 편이 좋습니다. docs/README.md가 각 문서를 ‘권위’와 ‘참고’로 나눠 둔 색인 역할을 합니다.
| 경로 | 역할 | 읽을 때 포인트 |
|---|---|---|
apps/desktop |
Electron 데스크톱 클라이언트 (Main / preload / Renderer) | src/main에 인증·로컬 DB(SQLite)·플러그인 런타임(cindy-brain)·Orca 서비스 등 |
apps/mobile |
Expo/React Native 앱 | 로컬 에이전트 없음. device-link로 데스크톱을 원격 제어하는 ‘순수 컨트롤러’ |
apps/cindy-headless |
컨테이너용 런타임 (v0.4.3) | maker-core를 재사용해 CLI와 Harbor BaseAgent 어댑터로 노출. 벤치마크용 |
packages/maker-core |
에이전트 오케스트레이션의 중심 | 프롬프트 조립, 이벤트 흐름, 모델 매핑, 사용량 계산, 도구 반복 감지(ToolLoopGuard) |
packages/model-providers · model-compat |
모델 공급자 카탈로그와 라우팅 | catalog/provider-models.json에 공급자 39곳(Bedrock, Vertex, DeepSeek, Groq, Mistral 등) |
anthropic-responses-bridge 외 브리지 4종 |
프로토콜 변환 | Anthropic Messages ↔ OpenAI Responses ↔ Chat Completions. Claude Code SDK로 Codex·xAI 모델을 구동 |
packages/lizi-mcps |
재사용 가능한 MCP 서버 묶음 | memory·scheduler·ssh·docs·contacts·slack·wechat·feishu bot·browser·computer·android·lsp·orca |
packages/lizi-im |
메신저 연동 | Discord·Telegram·Feishu·DingTalk·WeCom 채널 구현 |
packages/device-link(-protocol) |
같은 계정 기기 간 원격 제어 프로토콜 | 서버는 페이로드를 보지 않는 ‘단순 중계’, 20초 ping, 재연결 1초→30초 지수 백오프 |
packages/browser-control-runtime |
브라우저 자동화 런타임 | 상위 브라우저 코어와 SSRF 방어 코드를 _generated/에 vendoring(직접 수정 금지) |
tools/claude · codex · pi |
하네스 버전 고정 | 확인 시점 Claude Code 2.1.296, Codex 0.159.2, Pi 1.0.2. pnpm install 때 플랫폼별로 내려받음 |
4. 동작 방식: 하네스를 감싸는 세 개의 층
① 하네스 층. 실제 추론 루프는 Claude Code, Codex, Pi가 돌립니다. Cindy는 이들을 자식 프로세스나 SDK로 띄우고, 이벤트를 하나의 세션 모델로 번역합니다. 같은 작업 안에서 하네스와 모델을 바꿔도 작업 공간·메모리·스킬·도구는 그대로 이어지는 것이 핵심 기능입니다. 이 전환은 브리지 패키지가 맡습니다. 예를 들어 anthropic-responses-bridge는 루프백 HTTP 브리지로, Claude Code SDK가 Anthropic Messages 형식으로 보낸 요청을 OpenAI Responses 형식으로 바꿉니다. 그래서 ChatGPT 구독(Codex) 모델이나 xAI 모델을 OAuth 자격 증명으로 구동할 수 있습니다. 반대로 anthropic-compat-proxy는 대상 모델이 Anthropic이 아닐 때 Anthropic 전용 필드를 걸러 냅니다.
② 연결 층. 메모리(쓰기·읽기·검색·목록·삭제·리뷰·통합·세션 검색), 스케줄러(cron 엔진과 루틴), SSH 원격 작업 공간, 브라우저·컴퓨터·Android 제어가 모두 MCP 서버 형태로 하네스에 주입됩니다. 사용자가 직접 MCP를 설정하지 않아도 Cindy가 세션을 시작할 때 서버 목록을 조립해 넣습니다. SSH 원격 세션에서는 원격 머신에서 NDJSON RPC 데몬(maker-cc-manager, maker-pi-manager)을 띄웁니다. 로컬 MCP 브리지는 SSH remote-forward로 연결하고, 토큰은 argv가 아니라 stdin으로만 넘깁니다.
③ 표면 층. 데스크톱 UI, 모바일 원격, 메신저 수신, 예약 실행이 같은 세션에 들어옵니다. 모델은 네 가지 방식으로 가져옵니다. Cindy 계정 로그인(사용량 차감), 이미 결제 중인 Claude Code / Codex Coding Plan 연동(“이중 결제 없음”), 직접 가져온 API 키, 로컬 모델입니다. 로그인 화면에서 “Skip Sign-In”을 고르면 계정 없이 로컬 에이전트만 쓸 수 있고, 서버 기반 기능은 꺼집니다.
문서가 구체적인 수치로 정해 둔 동작도 있습니다. maker-core 규칙을 보면 도구 이름·인자·출력이 완전히 같은 호출이 4번 연속되면 루프로 보고 중단합니다. 반면 “인자는 다른데 같은 종류의 계약 오류가 3번 연속 나면 중단”하는 규칙은 세 엔진 모두에서 꺼 두었습니다(contractConsecutiveLimit: Infinity). 같은 오류가 반복돼도 모델이 호출을 고치는 중일 수 있으니, 몇 번 더 재시도하는 비용을 감수하고 오판으로 멈추는 일을 줄이겠다는 선택입니다.
5. Orca: 리드 하나, 워커 여럿
Orca는 데스크톱 앱 안의 멀티 에이전트 협업 기능입니다. 10월 19일 이 블로그에서 다룬 stablyai/orca(worktree 기반 에이전트 오케스트레이터)와는 이름만 같고 전혀 다른 구현입니다. Lead 세션이 작업을 나누고, 배정하고, 결과를 검수하고, 취합합니다. Worker 세션은 일회용 서브에이전트가 아니라 자기 모델·reasoning effort·도구 호출 흐름·맥락·기록을 가진 완전한 세션입니다. 그래서 “Claude Code + 모델 A가 계획하고, Codex + 모델 B와 Pi + 모델 C가 병렬로 구현하고, 다시 리드가 검수”하는 식의 하네스 × 모델 조합을 한 작업 안에서 쓸 수 있습니다. 로컬 세션뿐 아니라 SSH 원격 세션과 device-link로 제어되는 기기 쪽에서도 Lead를 맡을 수 있습니다.
| 요소 | 구현 | 설계상 제약 |
|---|---|---|
| 데이터 모델 | sessions.orca_role(lead/worker), orca_teams, orca_workers |
Lead당 active team은 1개. 전체 unique가 아니라 status='active'에만 거는 부분 유니크 인덱스 |
| 포크와의 분리 | parent_session_id + forked_at_message_id |
포크 관계 필드에 Orca 배정 의미를 섞지 않음 |
| 서비스 경계 | Lifecycle / WorkerCreation / Team / InterAgentDispatcher 4개 | IPC·MCP 핸들러가 각자 상태 머신을 만들지 않고 이 서비스를 공유 |
| Lead → Worker 도구 | cindy_orca MCP: 팀 제어 18개 + 읽기 전용 진단 3개 = 21개 |
모델이 바로 찾을 수 있게 최상위에 직접 등록 |
| 대기열 제어 | 수정·취소·병합·끼어들기 전환·순서 변경·상태 조회 6개 도구 | Worker가 메시지를 소비하기 전까지만 수정 가능 |
| 일괄 생성 | create_workers |
하드 리밋에 걸리면 나머지는 skipped 처리. 성공 + 실패 + 건너뜀 = 요청 수가 되도록 결과 보고 형식을 고정 |
| Worker → Lead | orca_worker_bridge + 턴 종료 시 auto-bridge |
Worker는 다시 협업을 중첩할 수 없음 |
| 현재 한계 | 문서에 명시 | Lead 간 Worker 공유 불가, 포커스는 Worker 하나만, 보관한 Worker 복원 UI 없음, 워크플로 편성 미구현 |
실무에서 의미 있는 점은 Worker 권한이 Lead에게서 상속되지 않는다는 것입니다. 권한은 “Worker 생성 기본값”(직전에 쓴 에이전트·모델·effort·Fast와 같은 부류)으로 따로 관리됩니다. Lead를 높은 권한 모드로 돌리고 있어도 새 Worker가 자동으로 그 권한을 받지 않습니다. 반대로 말하면 Worker 권한은 생성 기본값 설정에서 따로 확인해야 합니다.
6. 신뢰 경계: 데스크톱 에이전트에서 가장 먼저 볼 곳
로그인된 앱과 실제 파일을 다루는 에이전트 클라이언트에서는 “어디까지 믿는가”가 곧 아키텍처입니다. Cindy 문서는 이 부분을 세 겹으로 나눠 설명합니다.
Electron 프로세스 경계. Renderer는 신뢰하지 않는 환경으로 봅니다. 에이전트 출력, Markdown, 파일 미리보기, 웹 콘텐츠, 플러그인 내용 모두 악성일 수 있다고 가정합니다. 따라서 Renderer에서 XSS가 터지더라도 Node·파일 시스템·DB·자격 증명·임의 IPC에는 닿지 못해야 합니다. preload는 ‘범용 백도어가 아닌 최소 권한 다리’이고, Main은 IPC로 들어온 페이로드·URL·경로·자기 신고 신원을 모두 다시 검증합니다.
플러그인(.cindy) 샌드박스. 실행 중인 플러그인마다 별도 Electron 샌드박스 프로세스와 소유자 × 플러그인 단위로 분리된 메모리 session partition을 씁니다. 호스트는 발신자가 밝힌 ID를 믿지 않고 webContents 바인딩으로 실제 플러그인 ID를 역조회합니다. 다만 매니페스트에 node를 선언한 플러그인은 현재 OS 사용자 권한을 가진 별도 Node 프로세스를 받습니다. VS Code 로컬 확장 모델을 참고했다고 적혀 있으며, 이 경우 브라우저 샌드박스 수준의 격리는 기대하면 안 됩니다.
로컬 Agent API v1. 다른 로컬 앱이 Cindy의 공급자·자격 증명·모델 라우팅을 빌려 쓰게 해 주는 HTTP 프로토콜입니다. 127.0.0.1의 무작위 포트에서만 대기하고, Origin 헤더가 붙은 요청은 모두 거부합니다(브라우저 CORS를 열지 않음). connect/start로 신청하면 Cindy 창에 확인 대화상자가 뜨고(기본 포커스는 ‘취소’), 사용자가 허용해야 connect/poll에서 Bearer 토큰을 받습니다. 신청은 2분이 지나면 만료됩니다. 부작용이 있는 요청은 <process-nonce>:<counter> 형식의 ID로 중복을 막고, 타임아웃이 나도 새 ID로 자동 재시도하지 않습니다.
| 위험 지점 | 문서상 방어 | 남은 공백 (문서가 직접 인정한 것 포함) |
|---|---|---|
| Renderer XSS | Renderer 신뢰 안 함, Main이 재검증, CSP | 문서 스스로 “기존 코드의 보안 부채는 요청이 있을 때만 정리”한다고 명시 |
| 플러그인 코드 변조 | 승인 receipt가 manifest·trust·revision을 고정, 스킬은 스냅샷 복사 | 설치된 코드 바이트를 실행 시점에 검증하지 않음. packageSha256는 승인 시점 지문일 뿐. 같은 권한의 로컬 프로세스가 코드를 바꿔치기할 수 있음(이미 승인된 권한 안에서만) |
| 승인 상태 위조 | receipt 구조 검증, 손상되면 fail closed | <userData>/ghost-install-state/에 서명·MAC·OS 쓰기 보호가 없음. 구조만 맞으면 승인 기록을 위조할 수 있다고 명시 |
| 로컬 API 사칭 | 매번 사용자 승인, 앱별 토큰, 개별 철회 | 앱 이름·ID는 자기 신고 값이라 발행자 인증이 아님. 같은 OS 사용자로 도는 악성 프로그램을 막는 장치는 아니라고 명시 |
node 플러그인 |
선언·표시·호스트 측 차단, 환경 변수 필터링 | 사실상 사용자 권한으로 코드 실행. 설치 출처를 확인하는 수밖에 없음 |
| 텔레메트리 | 정식 빌드는 TapDB 집계(기기·OS·버전, 로그인 후 계정 ID). 대화·파일·작업 디렉터리는 수집 안 함 | 소스로 빌드하면 initTapdb() 호출을 빼서 제거 가능. 모바일은 자격 정보를 주입하지 않으면 기본 꺼짐 |
| 기본 서버 | config/endpoint*.json이 공식 클라우드를 가리킴, 자동 업데이트는 공식 CDN |
백엔드가 공개되지 않아 직접 호스팅은 불가. 데이터 주권 요건이 있으면 Skip Sign-In과 BYOK 조합으로 써야 함 |
공백을 문서에 숨기지 않고 “알려진 보안/호환 공백(옛 문서를 지웠다고 해결된 것으로 보지 말 것)”이라는 절로 따로 관리하는 점은 좋게 볼 만합니다. 그렇다고 공백이 해결된 것은 아닙니다. 사내 PC에 깔 계획이라면 플러그인 설치를 허용 목록으로 제한하고, userData 디렉터리의 쓰기 권한과 EDR 정책을 함께 점검하는 편이 좋습니다.
7. 설치·실행·평가 명령
일반 사용자는 cindy.app이나 GitHub Releases에서 설치 파일을 받으면 됩니다. Linux는 x64 .deb만 있으며, Ubuntu·Arch·Omarchy용 안내는 docs/linux.md에 있습니다. 소스 빌드와 개발 흐름은 다음과 같습니다.
# 요구: Node 22.x, pnpm 10.x(11 미지원), Git LFS
git clone https://github.com/makecindy/cindy.git
cd cindy
git lfs pull # sqlite-vec 네이티브 라이브러리 등이 LFS로 관리됨
pnpm install # claude-code / codex / ripgrep 바이너리를 플랫폼별로 내려받음
# 개발 실행: 내 Cindy 클라우드 계정에 붙어 실행 (지역을 명시하라고 권고)
pnpm restart:desktop:remote --region=global # 중국 본토 계정은 --region=cn
다른 앱에서 로컬 Agent API를 써 보고 싶다면 저장소에 Node 표준 라이브러리만 쓰는 예제가 있습니다. 실행할 때마다 Cindy 창에서 허용을 눌러야 하고, 모델 호출은 선택한 공급자의 사용량을 씁니다.
node scripts/examples/local-agent-client.mjs \
--discovery "<profile>/local-agent/discovery.json" --list-models
node scripts/examples/local-agent-client.mjs \
--discovery "<profile>/local-agent/discovery.json" \
--provider "<provider-id>" --engine pi --model "<model-id>" --cwd "<절대경로>"
평가 쪽에서는 apps/cindy-headless가 흥미롭습니다. 데스크톱 UI 없이 같은 maker-core로 세 하네스를 CLI와 Harbor 0.20 어댑터에 노출합니다. 번들 매니페스트에는 상위 커밋, 프롬프트 다이제스트, 바이너리 다이제스트가 함께 기록됩니다. 그래서 “어떤 프롬프트·바이너리 조합으로 점수가 나왔는지”를 고정해 재현할 수 있습니다. API 키는 프로필·매니페스트·번들에 넣지 말고 환경 변수(CINDY_HEADLESS_BASE_URL, CINDY_HEADLESS_API_KEY)로만 넘기라고 되어 있습니다.
npm --prefix apps/cindy-headless run typecheck
npm --prefix apps/cindy-headless test -- --run
pnpm --filter cindy-headless package:release # Linux x64 full 번들 + SHA256 출력
8. 박스에서 돌려 본 것
전체 데스크톱 앱 빌드는 Node 22, Electron, 하네스 바이너리 다운로드까지 필요해 이번에는 하지 않았습니다. 대신 런타임 의존성이 없거나 거의 없는 패키지 두 개만 /tmp로 떼어 내 vitest 3으로 테스트를 돌렸습니다. 박스의 Node는 20.19.2로 요구 사양(22)보다 낮습니다.
| 패키지 | 결과 | 해석 |
|---|---|---|
@cindy/maker-scheduler (cron·루틴 엔진) |
테스트 파일 9개, 279/279 통과 (약 3.9초) | 런타임 의존성 0. Node 20에서도 문제없음 |
@cindy/device-link (원격 제어 프로토콜) |
파일 53개 중 52개 통과, 테스트 1,055/1,057 통과 (약 10.9초) | 실패 2건은 저장소 루트의 scripts/file-peer-runtime.mjs, direct-link-runtime.mjs를 찾지 못해 생긴 것. 패키지만 떼어 낸 환경 탓이고 코드 결함은 아님 |
| 데스크톱 앱 / 모바일 | 실행 안 함 | 로그인·클라우드 연동 동작, UI 품질, 실제 작업 성공률은 이 글에서 검증하지 않았음 |
테스트 밀도는 높은 편입니다. device-link 하나에만 테스트 파일이 53개, model-providers에는 59개가 있습니다. 문서 규칙에는 “문서와 코드가 다르면 코드를 기준으로 하되 문서를 반드시 고친다”는 원칙이 반복해서 나옵니다. 그런데 Electron 보안 문서는 “Electron 41”을 기준으로 쓰여 있고, 실제 의존성은 42.11.12입니다. 빠르게 움직이는 저장소인 만큼 문서와 코드 사이의 이런 작은 시차는 감안하고 읽어야 합니다.
9. 비슷한 도구와 비교
| 구분 | makecindy/cindy | Claude Code / Codex 단독 | goose (aaif-goose) | opencode |
|---|---|---|---|---|
| 에이전트 루프 | 직접 구현 안 함. 세 하네스를 감쌈 (자체 하네스는 개발 중) | 자체 루프 | 자체 루프 (Rust) | 자체 루프 (서버/클라이언트) |
| 작업 도중 하네스 전환 | 지원 (맥락·메모리 유지) | 해당 없음 | 해당 없음 | 해당 없음 |
| 멀티 에이전트 | Orca: 이종 하네스 × 모델 Worker | 각자의 서브에이전트 | 레시피·서브에이전트 | 서브에이전트 |
| 주 인터페이스 | GUI 데스크톱 + 모바일 원격 + 메신저 | CLI / IDE / 각 사 앱 | CLI + 데스크톱 | TUI + 서버 |
| 대상 사용자 | CLI를 몰라도 되는 일반 사용자 | 개발자 | 개발자·파워 유저 | 개발자 |
| 서버 의존 | 기본은 공식 클라우드, Skip Sign-In 시 로컬만 | 공급사 계정 | 없음 (BYOK) | 없음 (BYOK) |
| 라이선스 | Apache-2.0 (클라이언트만 공개) | 각 사 약관 (Codex CLI는 Apache-2.0) | Apache-2.0 | MIT |
정리하면 Cindy가 경쟁하는 지점은 ‘더 똑똑한 에이전트’가 아니라 ‘하네스 위의 운영 레이어’입니다. 이미 Claude Code와 Codex를 함께 쓰면서 두 도구의 기억과 설정을 각각 관리하는 데 지친 사람에게 가장 잘 맞습니다. 반대로 터미널 한 창에서 하나의 에이전트로 충분한 개발자라면, Electron 앱과 클라우드 계정이라는 추가 무게에 비해 얻는 것이 적을 수 있습니다.
10. 도입 전 체크리스트
| 질문 | 확인 방법 | 판단 기준 |
|---|---|---|
| 데이터가 어디로 가는가 | config/endpoint.json, endpoint.global.json, TapDB 초기화 위치 |
규제 환경이면 소스 빌드 + 텔레메트리 제거 + Skip Sign-In + BYOK |
| 결제가 이중으로 나가지 않는가 | Coding Plan 연동인지 Cindy 사용량 차감인지 세션별로 확인 | Orca에서 Worker를 여럿 띄우면 토큰 사용량이 Worker 수만큼 늘어남 |
| 플러그인을 누가 설치하는가 | 매니페스트의 node 선언 여부, 출처 |
node 플러그인은 사실상 사용자 권한 코드 실행으로 취급 |
| 로컬 API를 열어도 되는가 | 설정 → 원격 연결 → 로컬 앱 연결 목록 | 필요 없는 앱 토큰은 개별 철회. 같은 OS 사용자로 도는 악성 프로그램은 막지 못함 |
| 업데이트 속도를 감당할 수 있는가 | 릴리스 주기(최근 하루 한 번꼴), 열린 이슈 1,924개 | 사내 배포라면 버전을 고정하고 단계적으로 배포 |
| 라이선스 범위 | LICENSE, NOTICE, docs/legal/notices |
코드는 Apache-2.0이지만 모델 가중치·프롬프트·상표는 별도. Apache-2.0은 상표 사용권을 주지 않으므로 포크 재배포 시 이름·로고 주의 |
마무리: “연결”을 제품으로 만든다는 것
에이전트 경쟁이 모델과 루프의 성능에서 시작했다면, Cindy는 그 위의 층에 걸었습니다. 기억, 스킬, 스케줄, 메신저, 휴대폰, 그리고 서로 다른 하네스를 한 작업 안에서 이어 붙이는 층입니다. 코드 공개 범위가 클라이언트로 한정되고 기본값이 공식 클라우드라는 점은 분명한 한계입니다. 그래도 Orca의 서비스 경계, 로컬 API의 승인 흐름, 스스로 적어 둔 보안 공백 목록처럼 데스크톱 에이전트를 만드는 팀이라면 참고할 만한 설계 문서가 많은 저장소입니다. 테크부터 경제, 생활까지, 복잡한 소식을 쉽게 풀어 보는 MoricWorld는 다음 오픈소스 분석으로 또 찾아오겠습니다.