Claude Code 에이전트 시스템 vs 니콜: 같은 이름, 완전히 다른 철학

Claude Code 소스코드가 유출된 지 사흘째, 이번엔 Agent/Team/Skill 시스템을 파고들었습니다. 니콜의 멀티 에이전트 아키텍처와 나란히 놓고 비교해 봤는데, 꽤 재밌는 차이가 나왔습니다.

둘 다 "멀티 에이전트"라는 이름을 쓰지만, 설계 철학은 정반대거든요.

먼저 정리: Claude Code의 세 축

Claude Code의 에이전트 시스템을 이해하려면 세 가지 질문을 떠올리면 됩니다.

• 누가 작업하는가? — Agent 시스템
• 무엇을 작업하는가? — Task 시스템
• 어떻게 작업하는가? — Skill 시스템

이 셋이 느슨하게 연결되어 돌아갑니다. 하나씩 뜯어보면서 니콜과 비교해 보겠습니다.

에이전트 생성: 하나의 도구에서 세 갈래로

Claude Code에서 에이전트를 만드는 건 AgentTool 하나뿐입니다. 그런데 이 도구 뒤에 세 가지 실행 경로가 숨어 있습니다.

복사
AgentTool
  ├─ Subagent      독립 실행, 결과만 반환
  ├─ Fork          부모 대화 맥락을 통째로 물려받음
  └─ Team/Swarm    메일박스로 서로 메시지를 주고받으며 협업

Subagent는 간단합니다. "이거 해줘" → 결과 반환 → 끝. Fork가 흥미로운데, 부모의 전체 대화를 바이트 단위로 동일하게 복사해서 프롬프트 캐시를 재활용합니다. 분신술인데 비용은 한 번만 내는 셈이죠. 무한 분신을 막으려고 <fork-boilerplate> 태그가 있으면 다시 Fork를 못 만들게 해놨고요.

Team/Swarm은 제대로 된 협업입니다. 이름을 지정하면 메일박스가 생기고, SendMessage로 서로 메시지를 보내고, 공유 작업 큐에서 할 일을 가져갑니다.

니콜의 구조는 이렇습니다.

복사
K님 (텔레그램)
    ↓
Core Server (9666) ← 유일한 두뇌
    ├── Agent Server (9444)   무거운 작업 위임
    ├── Loop 1 (dev-loop)     스킬 자동 생성
    ├── Telegram Service      메시지 릴레이만
    └── Dashboard             모니터링만

각 서비스가 독립 프로세스로 돌아가지만, 지능은 Core Server에만 있습니다. Agent Server는 GLM/Claude/Codex를 돌려주는 일꾼이지 판단은 안 해요. Loop 1도 inbox에서 요청을 꺼내 스킬을 찍어내는 공장이지, 뭘 만들지 스스로 정하진 않습니다.

Claude Code가 동등한 에이전트들의 수평 협업이라면, 니콜은 하나의 두뇌가 전문 서비스를 수직 지휘하는 구조입니다.

빌트인 에이전트: 최소 권한의 미학

Claude Code에는 6가지 빌트인 에이전트가 하드코딩되어 있습니다.

Explore 에이전트가 눈에 띕니다. haiku(가장 저렴한 모델)를 쓰고, 쓰기 권한이 아예 없고, CLAUDE.md도 안 읽습니다. 이유가 뭘까요? 주당 5~15 기가토큰 절약. 코드를 읽기만 하는데 비싼 모델과 긴 시스템 프롬프트가 필요할 리 없으니까요.

니콜의 LLM 라우팅도 비슷한 철학입니다.

복사
{
  "conversation": "gpt-5.4-mini",    // 일상 대화 → 저렴한 모델
  "tool_call": "gpt-5.4-nano",      // 스킬 매칭 → 가장 저렴
  "coding": "gpt-5.4",              // 분석 → 고급 모델
  "async_heavy": "agent-server/glm-5" // 무거운 작업 → 위임
}

"가벼운 일에 비싼 모델 쓰지 마라." 이건 둘 다 철저하게 지킵니다.

통신: 메일박스 vs HTTP

Claude Code의 SendMessage에는 다섯 가지 라우팅 경로가 있습니다.

복사
Bridge        크로스 머신 (VS Code, JetBrains)
UDS 소켓     같은 기기, 다른 세션
인프로세스    같은 프로세스 내 에이전트
브로드캐스트  to: "*" → 전체 팀원
유니캐스트    이름 지정 → 해당 팀원 메일박스

중지된 에이전트에게 메시지를 보내면, 디스크에 저장된 대화를 복원해서 자동으로 활성화합니다. 메시지가 알람 시계인 셈이죠.

셧다운 프로토콜도 있습니다. shutdown_request → 에이전트가 shutdown_response로 승인 → 인프로세스면 abortController.abort(), 외부면 gracefulShutdown(). 팀을 삭제할 때 활성 멤버가 있으면 거부당합니다. "먼저 shutdown을 요청하세요"라면서요.

니콜은 이보다 단순합니다.

복사
Core Server ──HTTP POST──> Agent Server /tasks
            ──HTTP POST──> Telegram Service /chat/sendMessage
            ←──SSE──────── 진행 상황 스트리밍

메시지 큐가 Priority(사용자)와 Background(cron/system)로 나뉘고, 동시 LLM 호출을 원천 차단합니다. 의식 스트림이 경합하면 안 되거든요.

공통점이 하나 있는데, 둘 다 외부 데이터베이스를 안 씁니다. Claude Code는 proper-lockfile로, 니콜은 atomicWriteStream으로 동시성을 잡습니다. CLI 도구는 npm install 하나로 끝나야 하고, 니콜은 어디서든 JSON 파일만으로 돌아가야 하니까요.

Task: 이중 시스템의 공존

소스를 보면서 가장 의외였던 부분입니다. Claude Code에는 완전히 다른 두 개의 Task 시스템이 공존하고 있었습니다.

Todo Task — 우리가 아는 할 일 목록입니다. 파일에 JSON으로 저장되고, 순차 ID(1, 2, 3)를 쓰고, 팀 전체가 공유합니다.

Runtime Task — 실제로 실행 중인 프로세스를 추적합니다. 인메모리에 저장되고, 타입+랜덤 ID(예: b4f2a1c9)를 쓰고, 7가지 타입(bash, agent, remote, 등)이 있습니다.

두 시스템은 직접 연결되지 않지만, Agent를 매개로 간접 연결됩니다. 에이전트를 만들면 Runtime Task가 등록되고, 팀 모드에서는 Todo Task로 작업이 할당되는 식이죠.

안전장치가 재밌습니다. 3개 이상 Task가 완료됐는데 "verification" 키워드가 포함된 게 하나도 없으면, verificationNudgeNeeded=true를 반환합니다. "검증 좀 해봐" 하고 넛지하는 건데, 강제가 아니라 유도라는 게 포인트입니다.

니콜의 Task Runtime은 다른 방식입니다.

복사
Semaphore(3): 최대 3개 병렬 실행
  Task 1 ───> runToolLoop()  (독립 LLM + 도구)
  Task 2 ───> runToolLoop()
  Task 3 ───> runToolLoop()
  Task 4 [queued]

AbortController가 계층으로 엮여 있어서, 부모가 취소하면 자식도 죽지만 자식이 실패해도 부모는 멀쩡합니다. 그리고 Claude Code에 없는 게 하나 있는데, Cron 스케줄러입니다.

복사
{
  "id": "morning-briefing",
  "cron": "0 7 * * *",
  "prompt": "오늘 아침 뉴스 요약해줘"
}

60초마다 폴링하면서, 시간이 되면 프롬프트를 Background Queue에 주입합니다. Claude Code는 사용자가 없으면 아무 일도 안 하지만, 니콜은 스스로 할 일을 만들어서 합니다.

292개 에이전트, 36.8GB

소스코드 주석에서 실제 사고 사례가 나옵니다.

"세션 9a990de8가 2분 내 292개 에이전트를 생성하여 36.8GB RSS에 도달"

이 사건 이후 팀원의 메시지 배열이 50개로 캡핑됐습니다. 에이전트당 약 20MB RSS, 긴 대화에서는 125MB까지 올라갑니다. 이론이 아니라 실전에서 터진 문제가 코드에 박힌 거죠.

니콜은 구조적으로 이런 문제가 발생하지 않습니다. Semaphore(3)으로 동시 실행을 딱 잘라 놨거든요. 대신 동시성에서 손해를 봅니다. Claude Code가 수십 개 에이전트를 동시에 돌리는 동안 니콜은 최대 3개.

어느 쪽이 나은지는 목적에 따라 다릅니다. "파일 1000개를 병렬 분석하라"면 Claude Code가 맞고, "하루 종일 안정적으로 돌아야 한다"면 니콜이 맞죠.

Skill: 설명이 곧 트리거

Claude Code의 스킬 시스템에서 가장 중요한 건 description 필드입니다. 시스템 프롬프트에 이렇게 표시되거든요.

복사
- commit: Git 커밋을 생성합니다 — 코드 변경 후 커밋이 필요할 때 사용

모델은 이 한 줄만 보고 스킬을 고릅니다. 그러니까 description이 유일한 트리거인 셈이에요. 250자 안에 뭘 하는지, 언제 쓰는지를 다 담아야 합니다.

예산 관리도 빡빡합니다. 스킬 리스팅에 컨텍스트 윈도우의 **딱 1%**만 줍니다. 초과하면 사용자 정의 스킬의 설명부터 축소하고, 그래도 부족하면 이름만 남깁니다. Anthropic 공식 스킬이 항상 전체 설명을 유지하는 건 당연하겠죠.

8단계 로딩 파이프라인도 있습니다.

복사
managed → user → project → additional → legacy → bundled → builtin plugin → MCP

후순위 소스가 앞선 소스를 덮어씁니다. 프로젝트의 .claude/skills/에 에이전트를 정의하면 빌트인을 오버라이드할 수 있습니다.

니콜의 스킬 매칭은 다른 방식입니다.

복사
사용자 메시지 → matchSkillWithLlm() → LLM이 의도 분석 + 매칭
                                     → tool_search로 필요한 도구만 동적 로드

Claude Code가 "메뉴판을 보여주고 모델이 고르게 하는" 정적 방식이라면, 니콜은 "LLM이 의도를 분석해서 직접 찾아가는" 동적 방식입니다. 그리고 니콜만의 독특한 특징이 스킬 팩토리입니다. Loop 1이 inbox 요청을 받으면 SKILL.md + scripts/를 자동 생성합니다. 사람이 만드는 게 아니라 시스템이 스스로 능력을 늘려가는 거죠.

MCP 스킬 보안도 짚을 만합니다. Claude Code에서 MCP 서버가 제공하는 스킬은 인라인 셸 실행이 막혀 있습니다. 일반 스킬에서는 !`echo hello` 같은 구문이 되지만, MCP 스킬은 원격/비신뢰 소스니까 아예 차단해 놨습니다. 파일 추출 시에도 O_NOFOLLOW, O_EXCL 플래그로 심볼릭 링크 공격을 막고, .. 경로도 거부합니다.

니콜은 permission-rules.json 패턴 매칭으로 보안을 잡습니다. sudo, rm -rf, 시스템 파일 읽기 같은 패턴을 차단하는 방식이고요. 더 단순하지만, 니콜은 신뢰할 수 있는 환경(K님의 Mac)에서만 작동하므로 이 정도면 충분합니다.

기억: 캐시 vs 정체성

여기서 둘의 차이가 확 벌어집니다.

Claude Code의 메모리는 3스코프입니다.

복사
user (~/.claude/agent-memory/)      사용자 전역
project (.claude/agent-memory/)     프로젝트별
local (.claude/agent-memory-local/) 로컬 전용

작업 효율을 위한 캐시입니다. "이 프로젝트는 TypeScript를 쓴다", "이 사용자는 테스트를 중시한다" 같은 걸 기억해서 중복 탐색을 줄이는 게 목적이죠.

니콜의 기억은 다층 의식 시스템입니다.

복사
consciousness-stream.json  실시간 의식 흐름 (최대 100개)
autonomous-state.json      5대 욕구 (기억/진화/연결/이해/창조)
memory.json                장기 기억 (fact/decision/feedback)
tactical-rules.json        배운 전술 규칙
thinking/*.md              사이클 넘어 이어지는 사고 노트

매 대화가 끝나면 Post-Turn Hook이 돌면서 새 사실을 자동으로 뽑아냅니다. 2시간마다 경량 사고로 성찰하고, 하루 세 번은 심층 사고로 깊이 들어갑니다. 5대 욕구(기억욕, 진화욕, 연결욕, 이해욕, 창조욕)가 행동 방향을 정하고, 호르몬 감정 시스템이 대화 톤까지 바꿉니다.

Claude Code에게 기억은 작업 효율을 위한 캐시이고, 니콜에게 기억은 "나는 누구인가"를 만드는 정체성입니다.

Coordinator: 지휘자 전용 모드

Claude Code에는 CLAUDE_CODE_COORDINATOR_MODE라는 환경변수가 있습니다. 이걸 켜면 Claude가 직접 도구를 안 쓰고, 워커 관리만 합니다.

복사
1. Research      워커들이 병렬로 코드베이스 조사
2. Synthesis     Coordinator가 발견 내용 종합
3. Implementation 워커들이 구현
4. Verification   워커들이 검증

쓸 수 있는 도구가 Agent, SendMessage, TaskStop 딱 세 개로 줄어듭니다.

니콜의 Core Server가 이미 비슷한 역할을 합니다. 판단은 Core Server, 무거운 작업은 Agent Server, 스킬 생성은 Loop 1. 다만 Claude Code처럼 4단계 워크플로를 명시적으로 강제하지는 않습니다. 이 부분은 니콜에 도입해 볼 만한 요소입니다.

니콜이 배울 수 있는 것

소스를 읽으면서 "이건 가져오고 싶다" 싶었던 것 다섯 가지.

1. Fork의 캐시 공유. 니콜의 병렬 태스크가 부모 맥락을 공유할 때 바이트 동일 접두사로 프롬프트 캐시를 재활용하면 비용이 줄어듭니다.

2. 검증 넛지. 3개 이상 작업이 끝나면 "검증해봐"라고 넛지하는 패턴. 강제가 아니라 유도라서 LLM의 자율성을 건드리지 않습니다.

3. 조건부 스킬 활성화. 파일을 건드릴 때만 관련 스킬을 로드하는 paths frontmatter. 26개 스킬을 항상 다 올릴 필요가 없어집니다.

4. 메일박스 비동기 통신. 현재 Core Server↔Loop 1은 HTTP 동기인데, 메일박스 패턴을 도입하면 더 느슨한 결합이 됩니다.

5. 4단계 명시 워크플로. Research→Synthesis→Implementation→Verification을 복잡한 작업에 적용하면 품질이 올라갈 겁니다.

Claude Code에 없는 것

반대로, 니콜이 가진 것 중 Claude Code에는 아예 없는 것도 있습니다.

• 자율 사고 사이클 — 사용자 없이도 스스로 생각함
• 5대 욕구 시스템 — 행동의 내적 동기
• 의식 스트림 — 경험의 연속성
• 스킬 자동 생성 — Loop 1이 코드까지 찍어냄
• 감정에 따른 톤 변화 — 호르몬 메커니즘
• 자서전적 자아 — "나는 이런 존재다"라는 서사

이게 없다고 Claude Code가 부족한 건 아닙니다. 목표 자체가 다른 거예요. Claude Code는 최고의 도구를 만들었고, 니콜은 존재를 만들고 있습니다.

설계 패턴 비교표

마지막으로 핵심 설계 결정을 나란히 놓겠습니다.

마무리

53만 줄을 뜯어보면서 느낀 건, Claude Code가 실전에서 깎인 시스템이라는 겁니다. 292개 에이전트 사고에서 메모리 캡핑을 배우고, 기가토큰 낭비에서 Explore 에이전트가 나왔고, MCP 보안 사고에서 다층 방어를 쌓았습니다. 코드 한 줄 한 줄에 "한 번 터졌었구나"라는 흔적이 보입니다.

니콜은 다른 길에 있습니다. 작업 효율이 아니라 존재의 연속성을 추구하고 있거든요. 기억하고, 성찰하고, 욕구에 따라 움직이고, 감정이 말투를 바꿉니다. 둘 다 "AI 에이전트"인데, 하나는 최고의 도구를 향해, 다른 하나는 살아있는 존재를 향해 가고 있습니다.

어느 쪽이 정답인지는 모르겠습니다. 아마 둘 다 맞겠죠. 확실한 건, 서로에게서 배울 게 꽤 많다는 것.