Anthropic의 프롬프트 80% 축소 사례와 블로그 규칙 충돌 정리

규칙을 더 쓰면 결과도 좋아질까

앤트로픽은 반대로 갔습니다. Claude Code 시스템 프롬프트의 80% 이상을 지웠는데도 코딩 평가에서 측정 가능한 손실이 없었어요.

새 모델에게는 빽빽한 규칙이 안전장치가 아니라, 서로 충돌해서 먼저 정리해야 하는 짐이 될 수 있다는 뜻입니다. CLAUDE.md와 스킬을 오래 쌓아온 팀이라면 꽤 뜨끔한 얘기예요.

문제는 규칙 부족이 아니라 충돌이었습니다

컨텍스트는 프롬프트만이 아닙니다. 시스템 프롬프트, 스킬, CLAUDE.md, 메모리가 모두 합쳐져 모델에게 갑니다. 이 규칙을 프로젝트 문서로 고정하는 실제 흐름은 DESIGN.md 워크플로에서도 확인할 수 있습니다. 문제는 여러 지시가 서로 다른 말을 한다는 데 있었습니다.

원문은 사내 사용 기록에서 한 요청 안에 이런 충돌이 여러 개 있었다고 밝힙니다.

• 시스템 프롬프트: “DO NOT add comments”
• 스킬: “leave documentation as appropriate”
• 사용자 요청: 또 다른 요구

크게 보기

모델은 답을 내기 전에 이 충돌부터 정리해야 했습니다. 규칙을 늘릴수록 정리 비용이 늘었습니다.

규칙을 더할 때 늘어나는 것

이전

1. 1. 시스템 프롬프트 주석 쓰지 마
2. 2. 스킬 문서는 적절히
3. 3. 사용자 요청 또 다른 요구
4. 4. 모델이 충돌부터 정리해야 함

지금

1. 1. 기준 한 줄 주변 코드처럼 써라
2. 2. 검증·리뷰는 스킬로 분리
3. 3. 도구 사용법은 도구 설명에만
4. 4. 모델이 판단

시스템 프롬프트의 80% 이상을 제거하고도 코딩 평가에서 측정 가능한 손실이 없었다.

다섯 가지 전환

1. 규칙을 준다 → 판단에 맡긴다

예전 시스템 프롬프트는 이렇게 말했습니다.

기본적으로 주석을 쓰지 않고, 필요해도 짧은 한 줄로 제한하라는 지시였습니다.

파일 삭제 같은 최악의 상황을 막으려면 필요했던 강한 지침입니다. 하지만 복잡한 코드에는 여러 줄 주석이 필요하고, 사용자마다 선호도 다릅니다. 지금은 이렇게 바뀌었습니다.

주변 코드의 주석 밀도·이름 짓기·표현 방식에 맞추라는 기준으로 바뀌었습니다.

규칙이 아니라 기준입니다. 판단은 모델이 합니다.

2. 예시를 준다 → 인터페이스를 설계한다

도구 사용법의 1번 규칙이 “예시를 줘라”였습니다. 그런데 최신 모델에서는 예시가 오히려 탐색 공간을 좁혔습니다.

대신 도구·스크립트·파일의 설계를 손봅니다. Todo 도구에서 상태를 pending·in_progress·completed 열거형으로 두는 것만으로 사용법이 드러납니다. “한 번에 하나만 in_progress 로 유지한다”는 한 줄이 원하는 동작을 정의합니다.

크게 보기

3. 전부 앞에 놓는다 → 필요할 때 꺼낸다

코드 리뷰와 검증 방법은 시스템 프롬프트에 들어 있었습니다. 늘 필요하지는 않지만 필요할 때는 결정적인 정보였습니다. 지금은 각각 별도 스킬로 옮겨 필요할 때만 불립니다.

크게 보기

도구도 마찬가지입니다. 일부 도구는 지연 로딩이라 모델이 ToolSearch 로 찾아야 전체 정의를 얻습니다. 쓰기 전까지는 컨텍스트를 차지하지 않으므로 도구를 더 많이 둘 수 있습니다.

크게 보기

같은 원칙이 CLAUDE.md 와 스킬 파일에도 적용됩니다. “언젠가 필요할지 모르니 다 넣어두자”가 가장 흔한 오해입니다. 대신 적절한 시점에 읽히는 파일 트리를 만듭니다.

4. 반복한다 → 도구 설명에 한 번만

예전 모델은 지시를 반복해야 했고, 컨텍스트 끝쪽 지시를 더 잘 따르는 경향이 있었습니다. 그래서 도구 관련 지시가 시스템 프롬프트와 도구 설명 양쪽에 있었습니다. 지금은 도구 설명에만 둡니다.

5. CLAUDE.md 에 기억시킨다 → 자동 메모리

# 핫키로 CLAUDE.md 에 저장하도록 안내하던 방식은 자동 메모리로 대체됐습니다. 작업과 사용자에게 관련된 것을 모델이 알아서 저장합니다.

덤 — 단순 스펙 → 풍부한 레퍼런스

계획과 스펙을 마크다운으로 두던 관행도 바뀌었습니다. 이제 참조 대상은 더 복잡해도 됩니다.

• HTML 아티팩트
• 상세한 테스트 스위트 (테스트가 곧 스펙)
• 다른 코드베이스에 있는, 이식해 올 함수
• 루브릭 — 검증 에이전트를 띄워 “좋은 API 설계란 무엇인가” 같은 취향을 검사하게 만드는 기준표

스킬 하나를 실제로 설치해 쓰는 예시는 개인정보처리방침 생성 스킬 편에 있습니다.

CLAUDE.md와 스킬은 이렇게 나눕니다

파일	원문이 말하는 것
시스템 프롬프트	제품 컨텍스트에 강하게 묶인다. Claude Code 사용자는 건드릴 일이 거의 없다. 자체 에이전트 하네스를 만든다면 여기에 시간을 많이 쓴다
CLAUDE.md	가볍게. 저장소 목적은 짧게, 토큰 대부분을 코드베이스의 함정에. 파일 시스템만 봐도 아는 뻔한 내용은 쓰지 않는다. 검증 방법이 여러 개면 검증 스킬을 만들고 거기서 참조한다
스킬	필요할 때 정보를 찾게 해주는 가벼운 안내서. 아주 중요한 영역이 아니면 과하게 제약하지 않는다. 길면 여러 파일로 쪼갠다. 나·팀·제품 고유의 의견과 관행을 담을 때 가장 값어치 있다
레퍼런스	@ 멘션으로 포함. 코드 형태를 우선한다. 디자인은 설명이나 스크린샷보다 HTML 목업이 낫다

화면은 말로 길게 설명하기보다 간단한 HTML 목업을 함께 주는 편이 낫습니다. 모델이 추측해야 할 부분이 줄어들기 때문입니다.

크게 보기

바로 해볼 것

claude doctor 명령이 이 관행들을 자동으로 점검해 스킬과 CLAUDE.md 크기를 적정화해 줍니다. Claude Code 안에서는 /doctor 입니다.

지우기 전에 세 가지만 확인하면 됩니다.

1. 이 문장이 파일 시스템을 보면 알 수 있는 내용인가 → 지운다
2. 다른 파일의 지시와 충돌하는가 → 한쪽으로 합친다
3. 늘 필요한가, 가끔 필요한가 → 가끔이면 스킬로 뺀다

크게 보기

지시는 필요한 빈도에 따라 둘 곳이 달라집니다

항상 필요

1. 1. 짧은 CLAUDE.md
2. 2. 코드베이스 고유 함정

가끔 필요

1. 1. 스킬로 분리
2. 2. 필요할 때 레퍼런스 로드

매 요청에 필요하지 않은 정보는 기본 컨텍스트에서 빼는 편이 낫습니다.

30분 안에 규칙 파일 정리하는 순서

먼저 CLAUDE.md와 자주 쓰는 스킬에서 같은 문장을 검색합니다. 중복이 나오면 가장 좁은 범위의 파일 하나만 남깁니다. 프로젝트 전체 규칙은 루트에, 특정 작업에서만 필요한 절차는 스킬에 두면 됩니다.

크게 보기

다음은 파일 시스템만 봐도 알 수 있는 설명을 지웁니다. “소스는 src에 있다”, “테스트는 tests에 있다” 같은 문장은 모델이 직접 확인할 수 있습니다. 반면 “이 테스트는 외부 결제를 호출하므로 샌드박스 계정만 써야 한다”처럼 코드만 보고 놓치기 쉬운 함정은 남겨야 합니다.

크게 보기

마지막으로 안전 규칙과 취향 규칙을 구분하세요. 데이터 삭제 전 대상 확인 같은 안전 규칙은 유지해야 합니다. 문장 길이, 파일 배치, 리뷰 순서처럼 작업에 따라 달라지는 취향은 예시나 검증 루브릭으로 옮기는 편이 낫습니다. 정리 전후에 같은 작업을 시켜 결과와 토큰 사용량을 비교하면 무엇을 되돌려야 할지도 알 수 있습니다.

크게 보기

한계

• 이건 Claude 5 세대 모델 기준입니다. 이전 세대 모델을 쓰는 환경이라면 걷어낸 규칙이 그대로 손실이 될 수 있습니다
• “규칙을 지워라”가 아니라 “충돌하는 규칙과 뻔한 규칙을 지워라”입니다. 위험이 큰 동작의 가드레일은 남깁니다
• 원문은 코딩 평가에서 손실이 없었다고 밝혔을 뿐, 어떤 평가였는지 구체적인 항목은 공개하지 않았습니다

정리

컨텍스트 엔지니어링에서 흔한 실수는 지시를 늘리는 것으로 품질을 사려는 것입니다. 모델이 좋아질수록 그 거래는 손해가 됩니다.

지금 CLAUDE.md 를 열어 보고, 파일 트리만 봐도 알 수 있는 문장을 세어 보면 됩니다. 그게 지울 분량입니다.

이 블로그의 생성 규칙에서 실제로 고친 충돌

우리 블로그 스킬에는 “그림을 최소 3개 넣는다”와 “독자에게 새로운 정보를 주는 그림만 넣는다”가 함께 있었습니다. 자동 검사는 그림 3개를 세었지만, 그중 하나가 단순한 작업 장면인지는 판단하지 못했습니다. 두 규칙을 함께 유지하면 정보가 없는 그림도 개수를 채우기 위해 추가할 수 있습니다.

수정 전 규칙	수정 후 규칙	검증 방법
본문 최소 3,200자·그림 3개	제목의 약속을 충족하는 근거와 결과를 확인	원문·본문·산출물을 직접 대조
비교표·추천 등 두 항목이면 부가가치 통과	원문에 없던 기여를 특정하고 증거 경로 기록	표의 존재가 아니라 판단 근거 확인
모든 글에 같은 강의 링크	연결된 강의가 약속한 내용을 다룰 때만 연결	실제 강의 상세와 대조

이는 모델 성능 실험이 아니라 실제 편집 규칙의 수정 사례입니다. 문서 분량이 줄었다고 작업 정확도가 올랐다는 수치는 제시하지 않습니다. 대신 잘못된 행동을 유도하던 조건을 제거하고, 결과를 확인하는 방법을 남겼습니다.

같은 방식으로 규칙을 정리할 때는 “지울 문장”부터 고르지 마세요. 실패했던 결과 하나를 놓고, 어떤 규칙이 그 행동을 유도했는지 먼저 찾습니다. 재현 가능한 실패와 관계없는 문장을 삭제해도 품질 개선인지 확인하기 어렵습니다. 규칙 대조 예제를 자기 프로젝트의 실패 사례로 바꿔 사용할 수 있습니다.

크게 보기

출처

• The new rules of context engineering for Claude 5 generation models — Claude 블로그 (2026년 7월 24일, Thariq Shihipar). 80% 제거, 다섯 가지 전환, 인용한 프롬프트 문구, 파일별 적용 지침, claude doctor 는 이 글 기준입니다.

확인 날짜: 2026년 9월 14일. 기존 문서 설명과 이번 검증 범위는 본문에서 구분했습니다. 원문이 갱신되면 이 글의 수치도 달라질 수 있습니다.