Claude Code에서 프롬프트를 입력하면 무슨일이 일어날까?

엔터를 누르는 순간, 모델이 호출되기 전에 이미 일곱 단계가 끝나 있습니다. 그리고 모델이 첫 응답을 돌려준 뒤에도 여덟 단계가 더 기다리고 있어요.

Claude Code를 하루에 수십 번 쓰지만, 엔터를 누른 직후 그 안에서 정확히 뭐가 돌아가는지 아는 사람은 생각보다 많지 않습니다. 저도 그랬어요. 그런데 공식 문서와 리크 분석 글들을 따라가며 한 번 끝까지 뜯어보니, 이게 단순한 "LLM 호출"이 아니라는 게 분명해졌습니다.

이 글에서는 Claude Code에서 프롬프트를 입력했을 때 실제로 일어나는 일을 순서대로 따라갑니다. 그리고 그 여행 끝에 남는 한 가지 설계 원칙이 있어요. 그게 이 글에서 가장 전하고 싶은 이야기입니다.

sequenceDiagram
    participant User as 사용자
    participant Harness as 하네스
    participant Model as 모델
    participant Tool as 툴 (Bash/Edit/...)

    Note over Harness: Phase 0 · 엔터 전 (이미 7단계 완료)
    Harness->>Harness: CLAUDE.md · Auto Memory · Skills<br/>MCP · System Prompt · JSONL · Flag

    User->>Harness: 프롬프트 입력 + 엔터

    Note over Harness,Tool: 마스터 루프 nO 진입
    loop tool_call 있는 동안 반복
        Harness->>Model: 시스템 프롬프트 + 히스토리 + tool 스키마
        Model-->>Harness: tool_call 포함 응답
        Note right of Harness: 3 관문 통과<br/>Permission → PreHook → Sandbox
        Harness->>Tool: 승인된 툴 실행 (샌드박스)
        Tool-->>Harness: 결과 (plain text)
        Harness->>Harness: 히스토리 append · PostHook<br/>(필요 시 wU2 Compactor)
    end

    Model-->>Harness: plain text (tool_call 없음)
    Harness->>User: 최종 응답 · 입력 대기

먼저, '하네스'라는 말을 아셔야 해요

답을 이해하려면 이 용어가 먼저 필요합니다.

Agent = Model + Harness.

하네스(harness)는 AI 에이전트에서 모델 자체를 제외한 전부를 가리켜요. 도구, 메모리, 컨텍스트 관리, 권한 파이프라인, 훅, 서브에이전트, 샌드박스까지 — 모델을 둘러싼 소프트웨어 인프라 전체입니다.

이 구분이 왜 중요하냐면요. Claude Code에서 프롬프트를 엔터 쳤을 때 일어나는 일의 대부분은 사실 "모델이 한 일"이 아니에요. 하네스가 한 일입니다. 모델은 그 과정에서 작은 박스 하나만 차지합니다.

실제로 2026년 기준으로 AI 엔지니어링의 관심사는 빠르게 이쪽으로 넘어오고 있어요. 프롬프트 엔지니어링(2022~24) → 컨텍스트 엔지니어링(2025) → 하네스 엔지니어링(2026) 이라는 흐름입니다. 세 개는 배타적이지 않고 계층적이에요. 프롬프트가 컨텍스트 안에 있고, 컨텍스트가 하네스 안에 있습니다.

Princeton 연구에서는 하네스 설정만 바꿔도 solve rate가 64% 향상된다는 결과가 나왔어요. 같은 Opus 4.6 모델이 Claude Code의 하네스에서는 순위 33위였는데, 다른 하네스에 넣자 5위로 점프했다는 사례도 있습니다. 하네스가 모델을 이길 수 있다는 증거입니다.

자, 용어가 정리됐으니 이제 진짜 여행을 시작합니다.

엔터를 누르기 전에 — 이미 모든 준비가 끝났습니다

터미널에서 claude --dangerously-skip-permissions(줄여서 cc)를 실행하면요. 프롬프트를 치기 전에 이미 일곱 단계가 완료되어 있습니다. 이걸 Phase 0이라고 부를게요.

1. CLAUDE.md 계층 로드 — 현재 디렉토리에서 상위로 올라가며 CLAUDE.md를 탐색하고, enterprise policy → ~/.claude/CLAUDE.md → project root → 하위 폴더 순서로 계층적 병합합니다. 이 병합본은 세션 내내 살아남는 persistent anchor입니다.

2. Auto Memory 인덱스 로드 — ~/.claude/projects/<경로>/memory/MEMORY.md에서 첫 200줄 또는 25KB 중 먼저 도달하는 값까지만 로드해요. 개별 메모리 파일은 아직 읽지 않습니다. 인덱스만 컨텍스트에 들어가요.

3. Skills 스캔 — .claude/skills/ 아래 모든 SKILL.md의 frontmatter(name, description)만 읽습니다. 본문은 절대 로드하지 않아요. 이게 Progressive Disclosure 원칙입니다. 필요할 때만, 필요한 만큼만.

4. MCP 서버 연결 + 이름만 등록 — 설정된 MCP 서버들과 HTTP/stdio/SSE로 연결한 뒤, 도구 이름만 인덱스에 넣어요. 전체 스키마는 실제 사용 순간에 온디맨드로 로드됩니다(deferred tool loading).

5. 시스템 프롬프트 조립 — Claude Code 정체성 + 현재 작업 디렉토리 + git 브랜치/상태 + 플랫폼 + 오늘 날짜 + CLAUDE.md 병합본 + Auto Memory 인덱스 + tool 목록 + skill description 목록 + hook 설정이 하나의 시스템 프롬프트로 합쳐집니다.

6. 세션 JSONL 파일 생성 — ~/.claude/projects/<경로>/ 아래에 세션 파일이 만들어지고, 이후 모든 메시지/툴콜/결과가 실시간으로 append됩니다.

7. Permission Mode 플래그 세팅 — bypass permissions ON으로 마크되어, 이후 루프 내 권한 평가 시 Tier 2("사용자에게 확인")를 건너뛰게 됩니다.

flowchart TB
    S1["① CLAUDE.md 계층 로드<br/>enterprise → user → project → subdir"]
    S2["② Auto Memory 인덱스<br/>첫 200줄 또는 25KB까지"]
    S3["③ Skills 스캔<br/>frontmatter만 (본문은 호출 시)"]
    S4["④ MCP 도구 등록<br/>이름만 (스키마는 온디맨드)"]
    S5["⑤ System Prompt 조립"]
    S6["⑥ Session JSONL 파일 생성"]
    S7["⑦ Permission Mode 플래그 세팅"]
    READY["프롬프트 입력 대기"]

    S1 --> S2 --> S3 --> S4 --> S5 --> S6 --> S7 --> READY

    style S1 fill:#fef3c7,stroke:#f59e0b,color:#1f2937
    style S2 fill:#fef3c7,stroke:#f59e0b,color:#1f2937
    style S3 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style S4 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style S5 fill:#e0e7ff,stroke:#6366f1,color:#1f2937
    style S6 fill:#e0e7ff,stroke:#6366f1,color:#1f2937
    style S7 fill:#fee2e2,stroke:#ef4444,color:#1f2937
    style READY fill:#dcfce7,stroke:#22c55e,color:#1f2937

핵심은 이겁니다. 프롬프트를 치기 전에 이미 하네스가 상당한 양의 일을 해놓은 상태예요. 컨텍스트 레이어, 메모리 레이어, 도구 레이어, 보안 레이어가 전부 준비되어 있습니다. 그런데 주목할 게 있어요. 이 단계에서 아무것도 "꽉 채워" 로드하지 않습니다. 인덱스와 이름만 가져오고 본문은 미룹니다. 이게 Claude Code의 컨텍스트 경제 설계입니다.

엔터를 누르는 순간 — 마스터 루프 nO

이제 프롬프트를 입력하고 엔터를 누릅니다.

내부적으로는 h2A라는 비동기 큐에 메시지가 푸시되고, 세션 JSONL에 사용자 메시지가 append됩니다. 그리고 첫 API 호출 페이로드가 조립돼요. 시스템 프롬프트 + 전체 히스토리 + 사용자 메시지 + 사용 가능한 tool 스키마.

그리고 마스터 루프가 켜집니다. Claude Code의 실행 엔진은 nO(리크 분석 글 기준)라는 단일 스레드 루프예요. 패턴은 극도로 단순합니다.

while (response contains tool_call):
    execute tool → feed results back → repeat

이게 전부입니다. 더 복잡한 건 없어요. Anthropic 공식 문서에서도 이 루프를 "Gather Context → Take Action → Verify Results" 3단계가 섞여 도는 구조로 설명합니다.

flowchart LR
    START(["루프 시작"]) --> CALL["모델 호출<br/>(추론)"]
    CALL --> CHECK{"tool_call<br/>있음?"}
    CHECK -->|"Yes"| EXEC["툴 실행"]
    EXEC --> FEED["결과를<br/>히스토리에 append"]
    FEED --> CALL
    CHECK -->|"No"| END_([/"루프 종료<br/>plain text 반환"/])

    style START fill:#f3f4f6,stroke:#6b7280,color:#1f2937
    style CALL fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style CHECK fill:#e0e7ff,stroke:#6366f1,color:#1f2937
    style EXEC fill:#fef3c7,stroke:#f59e0b,color:#1f2937
    style FEED fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style END_ fill:#dcfce7,stroke:#22c55e,color:#1f2937

첫 모델 호출이 일어나면, 모델이 돌려주는 응답은 둘 중 하나예요.

• Plain text만 있다 → 루프 종료. 응답 끝.
• Tool call이 하나 이상 포함 → 툴 실행 단계로 진입.

여기서 짚고 넘어갈 것이 있어요.

이 루프 안에서 모델이 호출되는 박스는 단 하나입니다. 나머지 박스 — 권한 평가, 훅 실행, 샌드박스, 결과 회수, 컨텍스트 정리 — 전부가 하네스예요. 모델은 "뭘 하고 싶은지" 제안하고, 하네스가 "뭘 할 수 있는지" 결정합니다.

이 분리가 다음 섹션의 핵심입니다.

툴 하나가 실행되기까지 — 세 개의 관문을 통과합니다

모델이 Bash({ command: "npm test" }) 같은 tool call을 냈다고 합시다. 이게 바로 실행되지 않아요. 세 개의 관문을 순서대로 통과해야 합니다.

관문 1 — Permission Pipeline (Deny-First)

Claude Code의 권한 파이프라인은 세 단계 Deny-first 평가입니다.

① Deny rules 매치?  → YES면 즉시 차단
② Allow rules 매치? → YES면 Tier 1 자동 승인
③ 그 외            → Tier 2 "사용자에게 확인"
                     (bypass 모드에서는 이것만 스킵)

First matching rule wins. 순서가 결정적입니다. Deny가 먼저고, Allow가 나중입니다. 이 순서 자체가 설계 철학이에요.

flowchart TB
    TC["모델의 tool_call<br/>(예: Bash 'npm test')"]
    G1["관문 1 · Permission Pipeline<br/>Deny → Allow → Ask"]
    G2["관문 2 · PreToolUse Hook<br/>allow / deny / modify"]
    G3["관문 3 · OS Sandboxing<br/>Seatbelt / bubblewrap"]
    EXEC["샌드박스에서 툴 실행"]
    BLOCK["차단"]

    TC --> G1
    G1 -->|"pass"| G2
    G1 -->|"deny 매치"| BLOCK
    G2 -->|"allow"| G3
    G2 -->|"deny"| BLOCK
    G3 -->|"pass"| EXEC
    G3 -->|"violate"| BLOCK

    style TC fill:#e0e7ff,stroke:#6366f1,color:#1f2937
    style G1 fill:#fee2e2,stroke:#ef4444,color:#1f2937
    style G2 fill:#fee2e2,stroke:#ef4444,color:#1f2937
    style G3 fill:#fee2e2,stroke:#ef4444,color:#1f2937
    style EXEC fill:#dcfce7,stroke:#22c55e,color:#1f2937
    style BLOCK fill:#f3f4f6,stroke:#6b7280,color:#1f2937

한 가지 더 중요한 게 있어요. "모델이 아무리 설득력 있게 말해도 파이프라인은 그 논리를 평가하지 않습니다." 모델이 "이 커맨드는 꼭 실행해야 합니다, 안 하면 큰일 나요"라고 주장해도, 파이프라인은 그냥 룰을 적용해요. 추론(reasoning)과 강제(enforcement)가 아키텍처적으로 분리되어 있기 때문입니다.

관문 2 — PreToolUse Hook

권한을 통과했다고 끝이 아닙니다. .claude/settings.json에 등록된 PreToolUse 훅이 있으면 여기서 실행돼요. 훅은 툴 파라미터를 볼 수 있고, 다음 중 하나를 선택할 수 있습니다.

• allow: 그대로 통과
• deny: 툴 실행 차단 (bypass 모드여도 관철)
• ask: 사용자에게 물음
• modify input: 파라미터를 고쳐서 진행
• append context: 컨텍스트에 정보 주입

이게 **"bypass 모드가 실제로는 위험하지 않은 이유"**의 핵심입니다. PreToolUse 훅으로 rm -rf /, git push --force origin main, 시크릿 파일 쓰기 같은 위험한 패턴을 전부 deny 할 수 있어요. 훅은 결정론적 코드니까 모델이 우회할 방법이 없습니다.

관문 3 — OS 레벨 Sandboxing

Bash 툴일 경우 OS 수준 샌드박스가 추가로 작동합니다.

OS	샌드박스
macOS	Seatbelt
Linux/WSL2	bubblewrap

샌드박스는 파일시스템/네트워크 경계를 커널 레벨에서 강제해요. 공식 문서는 이걸 한 문장으로 정리합니다.

"Permissions control what Claude attempts; sandboxing enforces what the OS allows."

권한은 Claude가 시도할 수 있는 것을 제어하고, 샌드박스는 OS가 허용하는 것을 강제합니다. 두 개는 보완적이에요.

그리고 File Snapshot (Write/Edit일 때)

Edit, Write 계열 툴일 경우 세 관문을 모두 통과한 뒤 파일 수정 직전에 스냅샷을 저장합니다. 이게 Esc를 두 번 눌렀을 때 롤백할 수 있는 근거예요. 세션 로컬에만 존재하고, git과는 완전히 별개입니다.

툴이 끝나면 — 결과가 히스토리로 돌아옵니다

세 관문을 통과한 뒤 툴이 샌드박스에서 실행되고, 결과가 돌아옵니다. 그런데 결과가 그대로 컨텍스트에 들어가는 게 아니에요. 몇 단계가 더 있습니다.

1. 사이즈 판정 — 결과를 plain text로 변환한 뒤 크기를 잽니다. MCP 출력은 기본 25,000 토큰 제한이에요. 넘치면 truncate되거나, 최대 500,000자까지 디스크로 persistence됩니다. 컨텍스트를 보호하는 첫 방어선입니다.

2. 히스토리에 append — 결과가 tool_result 메시지로 세션 히스토리에 들어갑니다.

3. PostToolUse Hook 실행 — 등록된 훅이 있으면 여기서 실행돼요. 전형적인 용례는 Edit 직후 자동 lint, 결과 audit logging, 외부 서비스 POST 같은 것들입니다. 여기서 주목할 설계 하나 — 훅은 보통 성공은 조용히, 에러만 컨텍스트에 재주입합니다. 잘 된 일은 말하지 않고, 잘못된 일만 말해요. 이것도 일종의 "deny first" 사고입니다. 중요한 건 잘된 것보다 잘못된 것이에요.

4. TodoWrite 상태 재주입 — 현재 태스크 리스트가 있으면, 시스템 메시지로 현재 상태를 다시 주입해서 모델이 포커스를 잃지 않게 합니다.

이 과정이 끝나면 다시 마스터 루프의 머리로 돌아갑니다. 모델에게 새 페이로드를 보내고, 모델이 다음 툴 콜을 내거나 plain text를 내죠.

루프가 길어지면 — wU2 Compactor가 컨텍스트를 정리합니다

턴이 쌓이면 컨텍스트가 점점 차오릅니다. 여기서 작동하는 게 wU2 Compactor예요.

약 92% 임계에 도달하면 자동으로 트리거됩니다. 동작은 3단계입니다.

1. 오래된 tool output부터 clear — 원래 요청이나 핵심 결정은 보존하고, 커다란 파일 읽기 결과 같은 걸 먼저 비워요.
2. 그래도 부족하면 대화를 요약 — long-term storage(Markdown project memory)로 이동시킵니다.
3. CLAUDE.md의 "Compact Instructions" 따르기 — CLAUDE.md에 보존 대상 지시가 있으면 그걸 우선 적용해요.

여기서 CLAUDE.md가 왜 **"persistent anchor"**로 불리는지 드러납니다. 컨텍스트가 몇 번 리셋되어도 CLAUDE.md는 살아남아요. 세션 전체를 관통하는 고정점이 되는 거죠.

재미있는 건 Anthropic의 자체 철학입니다. **"Context Reset > Compaction"**이라고 해요. 완전히 비우고 구조화된 아티팩트로 핸드오프하는 게, 요약으로 이어가는 것보다 낫다는 겁니다. 요약은 "context anxiety"를 유발해서 모델이 한계가 가까워졌다고 느끼면 작업을 조기에 마무리하는 경향이 있거든요. 리셋은 이 불안을 끊어냅니다.

탐색이 복잡해지면 — 서브에이전트가 분리된 컨텍스트에서 돕습니다

모델이 탐색 작업이 복잡하다고 판단하면 Task 툴로 서브에이전트를 디스패치합니다. 이게 Claude Code 하네스의 진짜 강력한 장치예요.

서브에이전트의 세 가지 핵심 특성:

1. 완전히 독립된 컨텍스트 창 — 메인 세션과 전혀 공유하지 않아요.
2. 완료 시 요약만 반환 — 서브에이전트가 100KB짜리 파일을 읽어도, 그 텍스트가 메인 히스토리에 올라오지 않습니다. 오직 요약만 돌아와요.
3. 재귀 폭발 방지 — 서브에이전트는 또 다른 서브에이전트를 띄울 수 없습니다. 이건 하드코딩된 제약입니다.

이 구조 덕분에 서브에이전트는 Context Firewall처럼 작동해요. 복잡한 탐색을 메인 컨텍스트를 오염시키지 않고 수행할 수 있습니다.

2026년부터는 git worktree 격리까지 지원됩니다. 각 서브에이전트가 자신만의 worktree를 받아서 병렬 편집까지 할 수 있게 된 거죠. 충돌 없이 동시에 여러 방향을 실험할 수 있습니다.

그런데 bypass permissions 모드면 뭐가 달라지나요?

자, 여기가 가장 많이 오해받는 부분입니다. --dangerously-skip-permissions가 켜져 있으면 "모든 안전 장치가 꺼지는 것"이라고 생각하는 분들이 많아요. 공식 명칭이 dangerously로 시작하니까 당연한 반응입니다.

하지만 실제로 이 플래그가 끄는 건 Tier 2의 "사용자에게 확인" 프롬프트 딱 하나입니다. 나머지 안전 레이어는 전부 살아있어요.

안전 레이어	Default 모드	Bypass 모드
Read 툴 (Tier 1)	자동	자동
Write/Edit/Bash (Tier 2)	매번 Yes/No 프롬프트	자동 실행 ✨
Deny rules	관철	관철
PreToolUse hooks	실행	실행
Network allowlist	적용	적용
Protected paths	보호	보호
Sandboxing (Seatbelt/bubblewrap)	적용	적용
File snapshot	생성	생성
Safety training	작동	작동
PostToolUse hooks	실행	실행

한 문장으로 정리하면 이거예요. Bypass 모드가 끄는 건 Tier 2의 "ask" 딱 하나입니다. 여덟 가지 안전 레이어는 전부 그대로 돌아갑니다.

이걸 이해하면 bypass 모드에 대한 태도가 바뀝니다. 위험한 건 bypass 모드를 켜는 것이 아니에요. 위험한 건 PreToolUse 훅과 deny rules를 설정하지 않은 채 bypass 모드를 켜는 겁니다. 훅과 deny rules를 잘 설정해놓았다면 bypass 모드는 Mitchell Hashimoto가 말한 **"Safe YOLO 모드"**로 동작할 수 있어요.

그래서, 프롬프트를 입력하면 무슨 일이 일어날까요?

이제 처음의 질문으로 돌아옵니다.

짧게 답하면 이거예요.

하네스가 일어납니다. 모델은 루프 안의 작은 박스 하나일 뿐이에요.

우리가 따라온 15+단계 전부를 그려보면, 모델이 실제로 호출되는 건 매 턴에 한 번입니다. 나머지 — CLAUDE.md 계층 로드, Auto Memory 인덱싱, Progressive Disclosure, 마스터 루프 오케스트레이션, Permission Pipeline, PreToolUse Hook, Sandboxing, File Snapshot, 결과 회수, PostToolUse Hook, wU2 Compactor, 서브에이전트 디스패치 — 전부가 하네스예요.

그리고 그 하네스를 관통하는 설계 원칙이 하나 있습니다. 이게 이 글에서 가장 전하고 싶은 이야기입니다.

하네스 설계는 "뭘 허용할지"가 아니라 "뭘 차단할지"에서 시작합니다

Claude Code의 하네스를 끝까지 뜯어보면, 계속 반복되는 패턴이 보여요.

flowchart TB
    L1["Permission Pipeline<br/>Deny가 먼저 매치"]
    L2["PreToolUse Hook<br/>막을 패턴을 명시"]
    L3["PostToolUse Hook<br/>성공은 조용히<br/>에러만 재주입"]
    L4["wU2 Compactor<br/>오래된 output부터 clear"]
    L5["Subagent<br/>재귀·누출 차단"]
    L6["Bypass 모드<br/>ask만 꺼짐<br/>거부 8개는 유지"]
    CORE(["Deny-First<br/>허용은 기본값<br/>차단은 명시"])

    L1 --> CORE
    L2 --> CORE
    L3 --> CORE
    L4 --> CORE
    L5 --> CORE
    L6 --> CORE

    style L1 fill:#fee2e2,stroke:#ef4444,color:#1f2937
    style L2 fill:#fee2e2,stroke:#ef4444,color:#1f2937
    style L3 fill:#fee2e2,stroke:#ef4444,color:#1f2937
    style L4 fill:#fee2e2,stroke:#ef4444,color:#1f2937
    style L5 fill:#fee2e2,stroke:#ef4444,color:#1f2937
    style L6 fill:#fee2e2,stroke:#ef4444,color:#1f2937
    style CORE fill:#dbeafe,stroke:#3b82f6,color:#1f2937

• Permission Pipeline은 Deny-first로 평가됩니다. Allow보다 Deny가 먼저 매치되어야 해요.
• PreToolUse Hook은 "뭘 막을지"를 정의하는 레이어입니다. 허용은 기본값이고, 명시하는 건 거부할 패턴이에요.
• PostToolUse Hook은 성공은 조용히, 에러만 재주입합니다. 주목할 건 잘된 것이 아니라 잘못된 거예요.
• wU2 Compactor는 "뭘 버릴지"를 먼저 결정합니다. 오래된 tool output부터 지우고, 그래도 부족할 때만 요약으로 넘어가요.
• 서브에이전트는 "뭘 못 하게 할지"로 격리를 만듭니다. 메인 컨텍스트로 결과가 못 올라오게, 또 다른 서브에이전트를 못 띄우게.
• Bypass 모드조차 끄는 건 "ask" 하나뿐이고, 여덟 가지 거부 레이어는 그대로입니다.

이게 우연이 아닙니다. 하네스의 각 레이어가 **"허용은 기본값, 차단은 명시적"**이라는 원칙으로 설계되어 있어요.

왜 이래야 할까요? 모델이 **비결정적(non-deterministic)**이기 때문입니다. 허용 목록만 있는 화이트리스트 설계는 모델이 창의적으로 목록 안에서 움직일 때 잘 작동해요. 하지만 모델은 때때로 목록 밖으로 나가려고 합니다. 목록 밖의 시도 자체가 문제가 아니라, 그 시도가 어떤 피해로 이어지는가가 문제예요. 그걸 막으려면 "뭘 못 하게 할지"를 명시해야 합니다.

허용 목록은 모델의 능력을 제한합니다. 차단 목록은 모델의 피해 반경을 제한해요. 둘은 전혀 다른 목표입니다. 그리고 에이전트의 시대에는 후자가 훨씬 중요해요.

세 가지 교훈

Claude Code를 까본 경험이 우리에게 주는 것을 세 가지로 정리해볼게요.

1. 추론과 강제를 분리하라. 모델이 "왜 해야 하는지"를 설명하게 두되, "할 수 있는지"는 결정론적 코드가 결정하게 하세요. 모델의 설득력은 권한 평가에 영향을 주면 안 됩니다.

2. Deny-First로 설계하라. 하네스를 만들 때 제일 먼저 쓸 룰은 "뭘 막을지"예요. "뭘 허용할지"는 그 다음입니다. 피해 반경을 제한하는 게 능력을 제한하는 것보다 우선이에요.

3. 성공은 조용히, 실패만 시끄럽게. 컨텍스트는 희소 자원입니다. 잘 된 일을 다 기록하지 말고, 잘못된 것만 남기세요. 이게 컨텍스트 엔트로피를 늦춥니다.

---

Claude Code는 잘 설계된 하네스의 교과서입니다. 직접 써보면서 한 번 끝까지 까보는 경험은, AI 에이전트를 진지하게 만드는 사람에게 정말 좋은 공부가 돼요. 모델만 잘 쓰는 단계에서 하네스를 직접 설계하는 단계로 넘어가는 전환점이 됩니다.

이런 AI 엔지니어링 인사이트를 함께 탐구하고 싶다면, PEC 커뮤니티에 가입해 주세요.