research

Claude Code — 패러다임과 약점

Claude Code — 패러다임과 약점

Anthropic이 만든 closed-source agent CLI. 산업이 "harness가 무엇인가"를 다시 정의하게 만든 표준점. "98.4%가 infrastructure, 1.6%만 AI logic"이라는 명제로 harness engineering의 시대를 열었다.

Claude Code가 서있는 가정들

가정표현
모델은 수렴한다, harness가 차별화다프런티어 모델이 SWE-bench 1% 안에 모이면, 운영 harness가 진짜 자산
Context는 binding constraint모든 설계 결정의 출발점은 context 희소성
안전은 layer로 쌓는다단일 layer는 깨진다. 독립적 7개 layer가 진짜 deny-first
격리가 병렬보다 중요하다sub-agent의 본질은 multi-tasking이 아니라 context 격리
Audit-able은 simple과 같다append-only JSONL. 재구성 가능, 쿼리 약함
권한은 세션마다 재확립보안 상태는 session boundary를 넘지 않는다
단일 binary가 옳다통합 product. SDK는 별도 product line(Claude Agent SDK)

핵심: harness가 곧 product고, model은 그 안의 부속이다. 이게 Goose의 "model = service" 가정과 미세하게 다르다 — Anthropic은 자기 모델을 부속으로 본다.

추상적 작동 구조

핵심 통찰: 확장은 한 종류가 아니라 비용 차등이 있는 4종류. 이게 Goose의 "모든 tool은 MCP" 일원화와 다른 결정적 분기점.

이 패러다임의 강점

  • 모델 수렴 가정의 정확성 — SWE-bench 상위 모델이 1% 안에 모여 있는 게 실제 관측
  • Context를 first-class constraint로 다룸 — lazy loading, deferred tool schema, 모든 결정의 일관된 기준
  • 확장의 차등 비용 모델 — hooks(0)/skills(low)/plugins(med)/MCP(high)는 진짜 통찰. 모든 게 토큰 쓰는 건 아니라는 인식
  • fault isolation의 실용성 — sub-agent로 maintenance task 격리. main agent의 train of thought 보호
  • append-only audit — 단순하지만 사후 재구성·디버깅·safety review 다 가능

약점 — 어디서 균열이 보이는가

1. closed source로 인한 분석 글 의존

산업 전체가 Claude Code를 분석 글(decodeclaude.com, VILA-Lab/Dive-into-Claude-Code, Haseeb Qureshi의 비교)에 의존해서 학습한다. 라이선스 안전 영역이 매우 좁고, 누출 코드를 직접 보면 위험. 이건 산업의 학습 속도를 늦추고, 결과적으로 Anthropic만 진화하게 만든다.

2. Vendor lock-in의 구조적 제약

Claude Code는 Anthropic 모델 specific. 다른 모델 provider를 끼워넣는 게 SDK 차원에서 가능해 보이지만(Claude Agent SDK), 실제 product의 prompt·tool·context 전략이 Claude의 거동에 맞춰져 있다. 모델을 갈아끼우면 harness 전체가 흔들린다.

3. 7-layer permission의 UX 피로

7개 독립 layer는 안전성에는 좋지만, 사용자에게 보이는 결과는 승인 피로. 분석에 따르면 93%의 prompt가 검토 없이 승인된다. 즉 layer는 있지만 사람이 그 layer를 무시. 단계적 신뢰 메커니즘이 필요하다는 신호.

4. compound command bypass — layer가 독립적이 아닌 증거

Claude Code issue #36637: git status && rm -rf X에서 첫 토큰만 검사. 이건 7개 layer가 사실은 독립적이지 않다는 강한 증거. 모두 같은 경제적 제약(token cost)을 공유 → 50개 subcommand 넘으면 보안 분석 우회.

5. 두 product line의 분기

Claude Code (full harness) + Claude Agent SDK (minimal scaffolding) 두 product가 분리되어 진화. 사용자 입장에서 어디서 무엇을 받을지 혼란. SDK 사용자는 Claude Code의 통찰을 직접 흡수 못 함.

6. sub-agent의 ~7배 토큰 비용

context 격리는 좋지만 비용이 ~7배. 이게 paradigm의 fundamental limit. 격리하지 않으면 main이 corrupt, 격리하면 비용 폭발.

7. closed-source가 만드는 암묵적 의존

다른 harness들이 Claude Code의 패턴을 추측해서 따라간다. 정확한 spec이 없으니 다 어림짐작. 산업의 표준화가 늦어진다.

이 약점들을 깨려는 흐름들

A. clean-room reverse engineering

  • VILA-Lab/Dive-into-Claude-Code — 누출 분석 정리
  • decodeclaude.com — 시리즈 글로 architecture 해부
  • Yuyz0112/claude-code-reverse — LLM 상호작용 시각화
  • OpenHarness / Ohmo (HKUDS) — leak 의존 0으로 같은 패러다임을 다시 만듦
  • shareAI-lab/learn-claude-code — "Bash is all you need" 미니멀 재현

→ 의미: 산업이 Claude Code의 패러다임은 받되 코드는 안 받겠다고 결심하고 있음. 라이선스 안전한 representation이 모이고 있음.

B. multi-vendor harness가 같은 통찰 흡수

  • Goose, OpenHands, Crush가 Claude Code의 차등 비용 모델·context 관리 통찰을 자기 모델 위에서 재현
  • vendor lock-in 약점에 대한 시장의 답

C. declarative agent 정의의 표준화

  • AGENTS.md — agents.md 표준이 생기면서 product-specific format에서 declarative format으로 이동
  • agentskills.io SKILL.md — skill 정의도 표준화
  • prompt가 product가 아니라 spec이 되는 흐름

D. capability-based + parsed permission

  • Cerbos 같은 policy engine — compound command parser + 동적 정책
  • sparkishy/openclaw-harness — plugin hook + API proxy로 tool call 가로채기, 35+ dangerous shell builtins 차단
  • compound bypass 같은 약점에 대한 정교한 답

E. ACP (Agent Client Protocol)로 외부화

  • agent를 protocol로 외부화하면 Claude Code도 그 protocol의 한 implementation이 됨
  • Goose가 이미 ACP client로 Claude Code를 provider로 쓸 수 있음
  • product line 분기 약점에 대한 시장의 답

F. agent-as-MCP-server

  • agent 자체를 MCP server로 노출 → 다른 agent가 tool로 사용
  • Anthropic의 product 경계 밖에서 같은 패러다임 사용 가능

v0.1이 흡수할 인사이트

(코드가 아니라 철학 단위로)

  1. Context를 binding constraint로 다루는 사고방식 — v0.1은 이걸 가르치진 않지만, 그 위에 쌓을 layer가 이 가정을 따르도록 substrate를 설계
  2. 확장은 차등 비용 — 모든 확장이 token을 쓰는 건 아니다. v0.1이 trait 설계할 때 zero-cost lifecycle path를 위한 자리를 남겨둘 것
  3. Permission layer의 독립성 — 같은 경제 제약을 공유하면 진짜 독립이 아니다. v0.8 sandbox 단계에서 이 통찰을 design 원칙으로
  4. fault isolation을 위한 sub-agent — 단순히 병렬화가 아니라 주 train of thought 보호. v0.4에서 이 가정으로 들어감
  5. append-only audit — 단순한데 강력. v0.1 SDK 단계에서는 안 다루지만, 그 위 layer에서 표준 패턴으로 권장
  6. 권한은 세션마다 재확립 — 신뢰는 자동 복원되지 않는다. v0.8 보안 layer 원칙

v0.1이 다르게 갈 가설

  • closed가 아니라 open — 라이선스 안전한 표준이 산업의 학습 속도를 결정한다. 오픈소스가 paradigm 변화의 가장 큰 lever
  • 단일 vendor가 아니라 multi-vendor first — provider 추상화가 v0.1에 있는 이유
  • 단일 product가 아니라 layered library — Claude Code가 product line을 분기시키는 비용을 본 후, v0.1은 처음부터 layer로 쌓는 형태
  • 확장 비용 모델은 따라가되, 사용자에게 명시적 선택을 줌 — hooks/skills/plugins/MCP 중에서 사용자가 경제 비용을 보고 고르도록
  • declarative spec(AGENTS.md, SKILL.md)을 v1.0부터 채택 — Claude Code가 product format으로 닫혀 있는 부분을 처음부터 표준으로 열기

메타 통찰 — Claude Code가 산업에 남긴 것

Claude Code의 가장 큰 영향은 코드가 아니라 명제다:

"프런티어 모델이 수렴하면, harness가 차별화 요소가 된다. 결정론적 인프라(context 관리·안전·복구)가 planning 제약 추가보다 더 큰 신뢰성을 준다."

이 명제가 산업이 agent loop를 trivial하게 보고 그 주변 인프라에 투자하게 만든 결정적 전환점. v0.1의 학습 메타 목표(설계 실력 향상)는 이 명제를 내 손으로 다시 검증하는 여정.

관련

Sources

← research 목록으로홈으로