Dive into Claude Code The Design Space of AI Agent Systems

🏷️ 논문 LLM

J. Liu, X. Zhao, X. Shang, Z. Shen, "Dive into Claude Code: The Design Space of Today's and Future AI Agent Systems", arXiv preprint arXiv:2604.14228, 2026.

Claude Code가 실제로 어떻게 만들어져 있는지를 소스 레벨로 파헤친 논문이 4월 14일 arXiv에 올라왔습니다. MBZUAI VILA Lab과 UCL 공동 연구로, Anthropic이 공개해 놓은 TypeScript 소스(v2.1.88)를 직접 분석해서 5가지 가치, 13가지 설계 원칙, 7개 컴포넌트, 5개 서브시스템 레이어, 7중 안전 레이어로 구조를 정리했습니다. 단순한 사용 후기가 아니라 실제 코드 파일과 줄번호까지 짚어가며 쓴 아키텍처 분석입니다.

가장 인상적인 한 줄은 이겁니다.

코드베이스 중 약 1.6%만이 AI 의사결정 로직이고, 나머지 98.4%가 운영 인프라다.

에이전트의 본체는 모델이 아니라 그 둘레에 깔린 권한·컨텍스트·세션·서브에이전트 시스템이라는 뜻입니다. 이 비율 자체가 Claude Code 설계 철학의 요약이라고 보면 됩니다.


다섯 가지 인간 가치

저자들은 Anthropic의 안전 프레임워크와 Claude Constitution을 출발점으로 삼아 설계 동인을 다섯 갈래로 묶습니다.

  1. Human Decision Authority — 사람이 최종 결정권을 가진다. 다만 "허락 프롬프트가 너무 잦으면 사람이 무뎌진다"는 게 핵심 통찰입니다. Anthropic 내부 자료에 따르면 사용자가 권한 프롬프트의 93%를 그대로 승인하더랍니다. 그래서 답을 "프롬프트 추가"가 아니라 "경계 안에서는 자유롭게"로 잡았습니다 (auto 모드, 샌드박스).
  2. Safety, Security, Privacy — 사람의 부주의를 시스템이 막는다. auto 모드 위협 모델은 과잉 행동, 단순 실수, 프롬프트 인젝션, 모델 misalignment 네 가지를 명시적으로 다룹니다.
  3. Reliable Execution — 같은 의도로 동작하고, 컨텍스트 경계를 넘어도 일관된다. "에이전트는 자기 결과를 자신만만하게 칭찬하는 경향"이 있어서 생성과 평가를 분리하는 게 원칙입니다.
  4. Capability Amplification — 사람이 할 수 있는 일의 양과 종류를 늘린다. Anthropic 내부 132명 설문에서 27%의 작업이 Claude Code 없었으면 시도조차 안 했을 일이었다고 합니다. 단순한 가속이 아니라 새 워크플로의 등장입니다.
  5. Contextual Adaptability — 사용자의 프로젝트·관습·숙련도에 맞춘다. 세션이 누적될수록 auto-approve 비율이 50회 미만 ~20%에서 750회 ~40%까지 올라간다는 종단 연구가 인용됩니다. 신뢰는 고정값이 아니라 함께 만들어가는 궤적이라는 시각입니다.

여기에 저자들은 평가용 잣대 하나를 더 얹습니다. 장기 인간 능력 보존(long-term capability preservation). AI 의존이 감시 능력을 위축시키는 "supervision paradox", 그리고 AI 보조 환경의 개발자가 코드 이해도 시험에서 17% 낮게 나온다는 별개 연구가 근거입니다. Anthropic이 명시한 다섯 가치에는 들어가 있지 않지만, 이 논문은 이 항목을 cross-cutting concern으로 본문 전반에 걸어둡니다.


7개 컴포넌트와 단일 루프

상위 구조는 단순합니다. 사용자 → 인터페이스 → 에이전트 루프 → 권한 시스템 → 도구 → 상태/영속화 → 실행 환경의 7개 박스. 인터페이스가 무엇이든(인터랙티브 CLI, headless claude -p, Agent SDK, IDE) 결국 **하나의 queryLoop()**으로 합류합니다.

이 루프 자체는 거의 ReAct 그대로입니다. 매 턴은 다음 순서를 밟습니다.

  1. 설정과 시스템 프롬프트 해소
  2. 단일 State 객체 초기화
  3. compact boundary 이후의 메시지를 모아 컨텍스트 조립
  4. 5단계 컨텍스트 shaper 순차 실행
  5. 모델 호출(스트리밍)
  6. tool_use 블록 파싱 → 권한 게이트
  7. 도구 실행 + 결과 수집
  8. 응답에 도구 호출이 없으면 턴 종료

저자들이 강조하는 포인트는 "추론은 모델, 실행은 하네스"라는 명확한 분리입니다. 모델은 파일시스템·셸·네트워크에 직접 접근하지 못하고 오직 구조화된 tool_use 프로토콜로만 외부와 통신합니다. 악의적으로 조작된 모델조차 권한 검사를 우회할 수 없는 보안 경계가 여기서 생깁니다.


컨텍스트는 자원, 5단계 압축 파이프라인

200K(레거시 모델) 또는 1M(Claude 4.6 시리즈) 컨텍스트가 binding constraint라는 전제로, 모델 호출 직전 다섯 단계의 shaper가 비용 낮은 순서대로 작동합니다.

각 단계가 다른 비용-효익 곡선을 갖고, 싸고 빠른 게 먼저 돕는 구조입니다. 단일 압축 전략이 모든 종류의 컨텍스트 압력을 못 다룬다는 인식이 5단 파이프라인의 이유입니다.

여기에 더해 컨텍스트 절약을 위한 보조 장치가 깔려 있습니다.


안전은 한 겹이 아니라 일곱 겹

권한 시스템은 단일 게이트가 아니라 7중 레이어로 설명됩니다. 어떤 레이어 하나라도 차단하면 동작이 막히는 구조입니다.

  1. Tool pre-filtering — 차단된 도구는 모델 시야에서 아예 제외.
  2. Deny-first 룰 평가 — deny가 allow를 항상 이긴다.
  3. 권한 모드 제약 — 현 모드가 룰에 없는 요청의 기본값을 결정.
  4. Auto-mode ML 분류기 — 룰이 허용해도 분류기가 거부 가능.
  5. 셸 샌드박스 — 승인된 명령도 파일/네트워크 접근 제한.
  6. Resume 시 권한 미복원 — 세션 권한이 재시작 시 살아나지 않는다.
  7. PreToolUse / PermissionRequest 훅 — 결정을 수정하거나 비동기 해소.

저자들이 비교 사례로 꺼내는 SWE-Agent·OpenHands는 Docker 컨테이너 격리 한 겹, Aider는 Git 롤백 한 겹에 의존합니다. Claude Code의 다층 방어는 명확히 다른 길입니다.


확장은 하나의 API가 아니라 비용 다른 네 가지

확장 메커니즘이 단일 API로 통일되지 않은 점도 이 논문이 짚는 특징입니다. MCP, plugins, skills, hooks 네 가지가 각기 다른 컨텍스트 비용으로 공존합니다. 한 줄 요약하면 "어떤 정보를 얼마짜리로 사용자가 부르고 싶은가"에 따라 골라 쓰라는 설계입니다.

추가로 서브에이전트는 AgentTool을 통해 같은 buildTool() 팩토리에서 생성되어 다른 도구와 똑같이 권한 체크를 받습니다. 차이는 격리된 컨텍스트 윈도요약-only 반환, 그리고 사이드체인 트랜스크립트 별도 저장입니다. 부모 컨텍스트가 자식 대화로 부풀어 오르지 않도록.


OpenClaw와 비교 — 같은 질문, 다른 답

비교 대상으로 등장하는 OpenClaw는 멀티 채널 개인 비서 게이트웨이입니다. 동일한 설계 질문에 대해 두 시스템이 어떻게 다르게 답하는지를 6개 축으로 짚어줍니다.

같은 원리라도 배포 컨텍스트가 바뀌면 답이 달라진다는 게 결론입니다. 코딩 어시스턴트는 행동 단위 안전이 합리적이고, 비서 게이트웨이는 통신 경계 단위 안전이 합리적입니다.


6개 열린 방향

마지막 섹션이 이 논문에서 실질적으로 가장 흥미로운 부분일 수 있습니다. 저자들이 후속 연구 영역으로 정리한 6가지입니다.

  1. observability ↔ evaluation 사이의 간극 — 로그가 풍부해도 평가가 빈곤하다.
  2. cross-session persistence — 세션을 넘는 학습·기억의 경계.
  3. harness boundary evolution — 하네스의 어디까지를 모델이 직접 만들 수 있나.
  4. horizon scaling — 더 긴 작업 지평을 견디는 구조.
  5. governance — 정책·감사·책임의 시스템화.
  6. evaluative lens — 능력 증폭과 능력 보존을 동시에 평가하는 잣대.

시사점

이 논문이 짚어주는 메시지는 두 가지로 정리됩니다.

첫째, 에이전트의 핵심은 루프가 아니라 그 둘레입니다. 1.6% / 98.4% 비율이 그대로 말해줍니다. 멋진 모델 위에 얇은 wrapper만 얹어 만든 에이전트가 프로덕션에서 자꾸 무너지는 이유입니다.

둘째, 하네스 설계는 가치·원칙 → 구체 코드 경로로 이어지는 일관된 결정 사슬입니다. 이 논문은 그 사슬을 파일명·줄번호 단위까지 보여줍니다. 자기 회사 에이전트를 평가하거나 만들고 싶다면, 이 5가치-13원칙 표를 그대로 자기 시스템에 매핑해 보는 것이 좋은 첫 단계입니다.

자체 코딩 에이전트나 하네스를 만들고 있다면 GitHub 저장소가 같이 공개돼 있어서 분석 노트와 다이어그램을 그대로 받아볼 수 있습니다. VILA-Lab/Dive-into-Claude-Code.

논문 자체보다 하네스 엔지니어링 흐름과 짝지어 읽으면 입체감이 좋습니다.