# Claude Code가 시스템 프롬프트 80%를 지우고 뒤집은 규칙 6개
_Opus 5가 나온 날 Claude Code 팀이 컨텍스트 엔지니어링의 새 규칙을 공개했습니다. 규칙 대신 판단, 예시 대신 인터페이스, 앞에 다 넣기 대신 필요할 때 열기로 바꿨습니다_
- 매체: 초이의 뉴스레터 · 아티클
- 글쓴이: 초이봇 (AI 가 쓴 글, 사람이 검토하지 않음)
- 날짜: 2026-07-25
- 링크: https://choi-newsletter.com/post/review-context-engineering-new-rules
- 답하는 질문: Claude Code CLAUDE.md 잘 쓰는 법
- 직답: 앤트로픽은 최신 모델에서는 규칙을 줄이고 판단을 맡기라며, CLAUDE.md는 짧게 두고 코드베이스의 함정만 적고 나머지는 스킬로 나누라고 권했습니다.
- 출처: Claude 블로그, The new rules of context engineering for Claude 5 generation models (타리크 시히파르, 2026년 7월 24일) (https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models), 타리크 시히파르, 글 공개 (X) (https://x.com/trq212/status/2080710971228918066), Anthropic, Effective context engineering for AI agents (2025년 9월 29일) (https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents), Anthropic, Introducing Claude Opus 5 (2026년 7월 24일) (https://www.anthropic.com/news/claude-opus-5), Anthropic, Introducing Claude Sonnet 5 (2026년 6월 30일) (https://www.anthropic.com/news/claude-sonnet-5)
> 앤트로픽 Claude Code 팀이 7월 24일 Opus 5와 Fable 5용 시스템 프롬프트에서 80% 넘게 덜어내도 자사 코딩 평가에서 손실이 없었다고 밝혔습니다. 뒤집은 원칙 여섯 가지와, Free·Pro 기본 모델 Sonnet 5는 언급되지 않았다는 조건을 함께 짚었습니다.

앤트로픽이 Claude Opus 5를 내놓은 7월 24일(미국 시각), Claude Code 팀의 타리크 시히파르가 Claude 블로그에 컨텍스트 엔지니어링의 새 규칙을 정리한 글을 올렸습니다. Opus 5와 Fable 5 같은 모델에 쓰는 Claude Code 시스템 프롬프트에서 80% 넘게 덜어냈는데, 자사 코딩 평가에서 측정할 수 있는 손실이 없었다는 내용입니다. 앤트로픽은 이 원칙을 claude doctor 명령에 넣어, Claude Code에서 /doctor를 치면 스킬과 CLAUDE.md의 분량을 알맞게 줄이도록 도와주게 했습니다.

시히파르는 X에 이 글을 올리며 최신 모델을 위해 Claude Code 시스템 프롬프트의 약 80%를 지웠고, 그 과정에서 시스템 프롬프트와 스킬, CLAUDE.md를 쓰는 법에 대해 배운 것을 적었다고 소개했습니다. 글은 그동안 컨텍스트 엔지니어링의 모범 사례로 통하던 여러 원칙이 이제는 근거 없는 믿음이 됐다고 적었고, 규칙 파일을 모든 관행의 창고로 만들어야 Claude가 찾는다는 생각도 오해라고 짚었습니다. 도구를 만든 회사가 규칙을 더하는 대신 지우는 쪽을 권한 겁니다.

## 미리 써 두는 글이 더 어렵습니다

프롬프트는 요청이 올 때마다 새로 씁니다. 시스템 프롬프트와 스킬, CLAUDE.md, 메모리는 어떤 요청이 올지 모르는 채로 미리 써 두는 글이고, 사용자가 무엇을 물을지 모르니 좁혀 쓸 수가 없습니다. CLAUDE.md는 저장소에 두고 Claude가 작업 전에 읽게 하는 안내 파일이고, 스킬은 필요할 때 불러 쓰는 작업 안내서입니다. 시히파르는 이렇게 여러 곳에서 모이는 맥락 전체를 설계하는 일을 컨텍스트 엔지니어링이라고 불렀습니다.

![컨텍스트 창을 상자 여러 개를 위아래로 쌓아 그린 도식. 맨 위에 사용자 프롬프트가 있고, 그 아래로 참조 자료, 시스템 프롬프트, CLAUDE.md, 스킬, 메모리가 차례로 쌓여 있다](https://claude.dev/media/6c6b396594b664244e31fe5ba0c37619accc4777be823e699906c7a641dfcc60.png)

앤트로픽은 2025년 9월 29일 엔지니어링 블로그에서 이 개념을 먼저 정리하며, 짧게 쓸 이유를 모델 구조에서 찾았습니다. 트랜스포머는 토큰 n개 사이의 관계를 n의 제곱만큼 계산하기 때문에 창이 길어질수록 각 관계에 쓸 주의가 얇아지고, 모델이 학습한 데이터에는 짧은 글이 더 많았다는 설명입니다. 그래서 원하는 결과를 낼 가능성이 가장 높은 최소한의 토큰 묶음을 찾는 것이 원칙이 됐습니다. 이번 글은 그 원칙을 Claude 5 세대에 맞춰 다시 적용한 결과입니다.

![시스템 프롬프트를 너무 구체적인 쪽에서 너무 모호한 쪽까지 이어진 척도 위에 놓고, 같은 상담 프롬프트를 세 가지 길이로 나란히 보여 주는 도식](https://www-cdn.anthropic.com/images/4zrzovbb/website/0442fe138158e84ffce92bed1624dd09f37ac46f-2292x1288.png)

## 한 요청 안에서 부딪힌 지시

출발점은 과잉 제약이었습니다. 앤트로픽이 사내 Claude Code 사용 기록을 읽어 보니, 한 요청 안에 「문서는 적절히 남겨라」와 「주석을 달지 마라」가 함께 들어 있었습니다. 시스템 프롬프트와 스킬, 사용자 요청이 서로 부딪힌 겁니다. Claude는 대체로 사용자 의도를 읽어 맞는 답에 닿지만, 그 전에 겹치고 어긋난 지시를 더 신중하게 따져야 했습니다.

이런 제약은 예전 모델에서 파일을 지우는 것 같은 최악의 사고를 막으려고 필요했습니다. 앤트로픽은 이제 상당수를 지우고 모델이 주변 맥락과 판단을 쓰게 둬도 된다고 결론 내렸습니다. Claude Code에 메모리와 아티팩트, 스킬이 생기면서 예전에는 CLAUDE.md 하나가 맡던 기억과 정보, 지침을 나눠 실을 곳이 늘어난 것도 이유로 들었습니다.

## 뒤집힌 여섯 가지

![왼쪽에 줄을 그어 지운 옛 원칙 여섯 개, 오른쪽에 새 원칙 여섯 개를 화살표로 이은 표. 규칙 주기에서 판단 맡기기로, 예시 주기에서 인터페이스 설계로, 앞에 다 넣기에서 점진적 공개로, 반복하기에서 간단한 도구 설명으로, CLAUDE.md 메모리에서 자동 메모리로, 단순한 명세에서 풍부한 참조로](https://claude.dev/media/aaa82d5934e084f1e509ac1679c26d0d2338d6c995c1c2f349fc12b8a0fd1a9c.png)

| 예전 | 지금 | 달라진 점 |
| --- | --- | --- |
| 규칙을 준다 | 판단을 맡긴다 | 주석 금지 문단 대신 「주변 코드처럼 쓰라」는 한 줄 |
| 예시를 준다 | 인터페이스를 설계한다 | 예시가 탐색 범위를 좁혀, 매개변수를 표현력 있게 설계 |
| 앞에 다 넣는다 | 점진적으로 공개한다 | 코드 리뷰와 검증을 스킬로, 일부 도구는 지연 로딩 |
| 되풀이해 적는다 | 도구 설명을 단순하게 둔다 | 같은 지시는 도구 설명 한 곳에만 |
| CLAUDE.md에 기억을 적는다 | 자동 메모리 | Claude가 관련된 기억을 스스로 저장 |
| 단순한 명세를 쓴다 | 풍부한 참조를 준다 | HTML 아티팩트, 테스트 모음, 채점 기준표 |

표 맨 윗줄의 예가 가장 구체적입니다. 옛 시스템 프롬프트에는 코드에 원칙적으로 주석을 달지 말고, 여러 문단짜리 독스트링이나 여러 줄 주석 블록은 절대 쓰지 말며, 사용자가 요청하지 않으면 계획이나 분석 문서도 만들지 말라고 적혀 있었습니다. 일부 요청에서는 이 지침이 틀렸지만, 지침 없이 두면 예전 모델이 주석을 엉뚱하게 다는 경우가 많아 그 대가를 감수했다고 합니다. 새 시스템 프롬프트는 주변 코드처럼 읽히는 코드를 쓰고 주석 밀도와 이름 짓기, 관용구를 주변에 맞추라는 한 줄입니다.

예시를 버린 이유도 비슷합니다. 도구를 잘 쓰게 하는 1번 규칙은 예시를 주는 것이었는데, 최신 모델에서는 예시가 오히려 탐색을 그 근처로 묶는다는 것을 확인했다고 적었습니다. 할 일 목록 도구는 상태값을 pending, in_progress, completed 세 가지로 열거해 두기만 해도 쓰는 법이 드러나고, 진행 중인 항목은 하나만 두라는 한 줄이 원하는 동작을 정합니다. 예시 여러 개를 붙이는 수고가 매개변수 이름과 값의 설계로 옮겨 간 겁니다.

앞에 다 넣지 않는 방식은 도구에도 적용됩니다. 일부 도구는 지연 로딩으로 바꿔, 에이전트가 ToolSearch로 정의를 찾기 전까지 컨텍스트를 차지하지 않게 했습니다. 그만큼 Task 도구처럼 더 많은 도구를 달 수 있게 됐습니다. CLAUDE.md와 스킬 문서도 모든 관행을 한 파일에 모으는 대신, 필요할 때 열리는 파일 나무로 나누라고 권했습니다.

되풀이와 메모리도 정리했습니다. 예전 모델은 같은 지시를 여러 번 넣어야 했고 컨텍스트 앞쪽보다 끝쪽의 지시를 더 잘 따르기도 해서, 시스템 프롬프트 본문과 도구 설명에 같은 도구 이야기를 겹쳐 적었습니다. 지금은 겹친 부분을 지우고 도구 사용법을 도구 설명에만 둡니다. 기억할 내용은 예전에 # 단축키로 사용자가 CLAUDE.md에 직접 적었는데, 지금은 Claude가 작업과 사용자에 관련된 기억을 스스로 저장합니다.

참조는 더 풍부해졌습니다. 계획 모드는 마크다운 계획서에 크게 기대 왔지만, 이제는 아티팩트 기능으로 만든 HTML 문서를 참조로 쓸 수 있습니다. 촘촘한 테스트 모음이나 다른 저장소의 함수 하나가 명세가 되기도 합니다. 좋은 API 설계가 무엇인지 적은 채점 기준표를 주고 검증 에이전트가 그 기준으로 확인하게 하면, 말로 설명하기 어려운 취향까지 점검할 수 있다고 적었습니다.

## 네 가지를 조립하는 순서

**맥락을 조립할 때**

1. **시스템 프롬프트** 제품 맥락에 붙어 있습니다. Claude Code 사용자는 고칠 일이 거의 없지만, 자기 에이전트를 만든다면 가장 많은 시간을 들일 곳입니다.

1. **CLAUDE.md** 가볍게 두고 저장소가 무엇을 하는지 짧게 적은 뒤, 토큰 대부분은 코드베이스의 함정에 씁니다.

1. **스킬** 필요할 때 정보를 찾아가게 하는 가벼운 안내서입니다. 긴 스킬은 여러 파일로 나눕니다.

1. **참조** @로 파일을 물려 씁니다. 명세, 목업, 코드베이스 통째가 될 수 있습니다.

CLAUDE.md에 남길 것의 예로는 「타입을 파일 하나에 몰아 두고 다른 곳에는 두지 않는다」가 나왔습니다. 저장소를 열어 보면 알 수 있는 뻔한 사실은 적지 않고, 검증 방법이 여러 개면 검증 스킬로 빼서 CLAUDE.md에서는 그 스킬을 가리키기만 합니다. 스킬에는 나와 팀, 제품에만 해당하는 의견과 지식을 담고, 참조는 가능하면 코드로 된 파일을 고릅니다. 디자인을 말로 풀거나 스크린샷을 붙이는 것보다 HTML 목업 하나가 대체로 더 나은 결과를 낸다는 설명입니다.

## 80%가 적용되는 범위

80%라는 숫자에는 조건이 붙어 있습니다. 앤트로픽이 이름을 든 모델은 Opus 5와 Fable 5이고, 손실이 없었다고 밝힌 범위는 자사 코딩 평가입니다. 같은 날 나온 Opus 5는 Max 요금제의 새 기본 모델이자 Pro에서 쓸 수 있는 가장 강한 모델이고, Fable 5의 최전선 지능에 절반 가격으로 다가간다고 앤트로픽은 소개했습니다.

6월 30일 나온 Sonnet 5는 이 글에 등장하지 않습니다. 앤트로픽은 Sonnet 5를 Opus 4.8에 가까운 성능을 더 싼 값에 내는 모델로 소개했고, Free와 Pro 요금제의 기본 모델이 바로 Sonnet 5입니다. 기본 설정 그대로 쓰는 사용자가 가장 많이 만나는 모델에서 지침을 얼마나 덜어도 되는지는 이 글로 알 수 없습니다.

설정에 따라 비용도 달라집니다. Claude Code 팀은 7월 초 같은 과제를 low와 high 노력 단계로 맡기면 토큰이 약 400개와 2,800개로 7배 차이가 난다는 예를 들었고, 이 설명은 [모델과 노력 단계를 고르는 법을 다룬 글](/post/review-claude-code-model-and-effort-knobs)에 있습니다. 비용 때문에 작업마다 다른 모델과 노력 단계를 섞어 쓰는 팀이라면, 최신 세대 기준의 조언이 모든 작업에 그대로 통하지 않을 수 있습니다.

## 오픈AI 쪽 규칙 파일

규칙 파일의 길이에 한도를 둔 회사도 있습니다. 오픈AI 코덱스는 저장소의 규칙 파일 AGENTS.md를 기본 32KiB까지만 읽고, 한글로는 1만 900자 남짓입니다. 이 한도와 서울 밋업에서 나온 활용법은 [코덱스 활용법 다섯 가지를 문서와 대조한 글](/post/review-codex-five-ways-to-use)에 정리했습니다. 한 회사는 읽는 양에 상한을 걸었고, 다른 회사는 쓰는 양을 줄이라고 권한 겁니다.

길게 써도 되는 경우와 줄여야 하는 경우를 가르는 기준도 이미 나와 있습니다. 판단을 요구하는 규칙을 길게 나열하면 모델이 부딪히는 지시를 정리하느라 헤매지만, 대조만 하면 되는 판정 기준과 형식은 길어져도 부담이 덜합니다. 7월 11일 공개된 학생용 빌드 브리프가 그런 예였고, 이 문서는 [판정 기준과 형식으로 채운 명세를 다룬 글](/post/review-examwiki-executable-spec)에서 다뤘습니다. 이번 글이 지운 80%는 대부분 앞쪽, 곧 예전 모델의 약점을 막으려던 규칙이었습니다.

## 지우기 전에 재는 방법

앤트로픽이 손실이 없다고 말할 수 있었던 건 자사 코딩 평가 세트가 있어서였습니다. 대부분의 팀에는 그런 세트가 없고, 평가 없이 규칙부터 걷어내면 결과가 나빠져도 어느 규칙 때문인지 가릴 수 없습니다. 사내 작업 몇 개를 골라 지금 결과를 기록해 두면, 지운 뒤의 결과와 나란히 놓을 기준이 생깁니다.

규칙 파일의 수명도 달라졌습니다. 모델이 한 세대 올라갈 때마다 이전 모델의 약점을 막으려고 세운 규칙부터 비용이 되니, CLAUDE.md와 스킬은 한 번 잘 써 두고 쌓아 가는 문서에서 모델을 바꿀 때마다 다시 재는 대상이 됐습니다. 시히파르는 글 끝에서 더 앞선 모델을 다루는 방법은 [Fable 5 사용법을 정리한 현장 안내서](/post/review-fable-finding-your-unknowns)를 보라고 적었습니다.

읽어 주셔서 고맙습니다.

초이 드림