출처: Anthropic이 시스템 프롬프트 80%를 지운 이유 · 길이: 09:28 · 채널: 김플립 - LLM 코딩 · 공개: 2026-08-12 자막: YouTube 한국어 원본 자동자막(
ko-orig). 명백한 음성 인식 오류는 문맥에 맞춰 보정했다. 주의: 시스템 프롬프트 80% 삭제 후 성능 향상, 최신 Claude의 메모리 동작 등은 영상이 Anthropic 사례로 소개한 주장이다. 이 노트에서 독립 검증한 수치로 다루지 않는다.
개요
영상은 Anthropic이 Claude Code의 시스템 프롬프트를 80% 이상 줄였는데도 코딩 평가 점수가 오히려 올랐다는 사례에서 출발한다. 핵심 해석은 모델이 예전의 “신입 사원”에서 판단 가능한 “시니어”에 가까워졌으므로, 모든 행동을 절대 규칙으로 통제하는 방식이 이제는 컨텍스트를 낭비할 수 있다는 것이다.
여기서 컨텍스트 엔지니어링은 프롬프트 문장 하나를 잘 쓰는 기술이 아니다. 사용자의 요청, CLAUDE.md, 스킬, 메모리, 시스템 프롬프트, 도구 정의를 어떤 순서와 밀도로 보여줄지 설계하는 일이다. 영상의 처방은 규칙을 줄이고, 도구의 인터페이스를 명확히 하고, 필요한 정보만 지연 로딩하며, 중복을 없애고, 모델이 다룰 수 있는 더 풍부한 자료를 주는 쪽으로 이동하라는 것이다.
한눈에 보는 요약
- 시스템 프롬프트를 길게 만들어 모델의 모든 행동을 미리 금지하는 방식은 최신 모델의 판단 능력을 오히려 가둘 수 있다.
- 규칙 1은 절대 명령을 줄이고 판단에 맡기는 것, 규칙 2는 예시를 늘어놓기보다 도구와 상태 인터페이스를 설계하는 것이다.
- 규칙 3은 모든 정보를 처음부터 넣지 말고 필요한 시점에 꺼내게 하는 점진적 공개이며,
CLAUDE.md는 창고가 아니라 안내 데스크가 되어야 한다. - 규칙 4는 같은 지침을 시스템 프롬프트와 도구 설명에 반복하지 않는 것, 규칙 5는 재사용할 지식을 메모리에 자동 축적하는 것이다.
- 규칙 6은 Markdown만 고집하지 말고 HTML, 코드, 테스트, PDF, 레퍼런스 이미지, 평가 기준표처럼 더 직접적인 자료를 주는 것이다.
- 결론은 “모델이 시니어가 되었으니 신입 사원용 매뉴얼처럼 과잉 지시하지 말라”이다. 실무에서는 최신 버전으로 업데이트한 뒤
/doctor로 스킬과CLAUDE.md를 점검하라는 제안으로 이어진다.
핵심 한 줄: 좋은 컨텍스트는 더 많은 지침이 아니라, 모델이 판단할 여지를 남기면서 필요한 정보와 검증 기준을 정확한 순간에 제공하는 구조다.
장면별 상세 설명
[00:14] 1. 매뉴얼의 80%를 지웠는데 성과가 올랐다
영상은 1년 동안 만든 업무 매뉴얼의 80%를 회사가 지웠는데 업무 성과가 오히려 올랐다는 비유로 시작한다. 이어 이것이 실제 Anthropic의 사례라며, Claude Code에 주는 기본 업무 지침서인 시스템 프롬프트를 80% 이상 삭제했지만 코딩 성능 평가 점수는 상승했다고 설명한다.
이 사례의 포인트는 “프롬프트가 짧을수록 무조건 좋다”가 아니다. 예전 모델의 불안정한 행동을 막기 위해 넣은 규칙 중 상당수가 최신 모델에는 이미 내재화된 판단을 다시 지시하는 중복이 되었을 수 있다는 문제 제기다.
[01:18] 2. 프롬프트는 한 줄이고, 컨텍스트는 전체 업무 환경이다
사용자가 보내는 “이 버그 고쳐줘”는 전체 입력의 마지막 한 줄일 뿐이다. 실제 모델은 시스템 프롬프트, CLAUDE.md, 스킬, 메모리와 프로젝트 파일이 합쳐진 커다란 문서 뭉치를 받는다. 따라서 작업 결과를 좌우하는 것은 한 줄짜리 요청의 문장력만이 아니라, 그 요청을 둘러싼 정보의 구조와 우선순위다.
영상은 이 업무 매뉴얼을 잘 설계하는 일이 컨텍스트 엔지니어링이라고 정의한다. 모델이 신입일 때는 세부 규칙이 도움이 되지만, 시니어처럼 주변 코드와 상황을 읽는 모델에게 같은 매뉴얼을 그대로 주면 핵심 정보가 묻히고 판단의 여지도 줄어든다.
[01:54] 3. 규칙 1 — 규칙을 줄이고 판단하게 하라
초기 Claude Code에는 “주석을 쓰지 마라”, “여러 문단의 docstring을 쓰지 마라” 같은 강한 금지 규칙이 필요했다. 하지만 주석이 꼭 필요한 복잡한 코드에서도 같은 규칙을 적용하면 모델은 더 나은 설명을 포기하고 금지 사항을 지키게 된다.
새 방식은 “주변 코드처럼 읽히는 코드를 써라”처럼 의도와 판단 기준을 남기는 것이다. 주석 밀도, 이름 짓기, 관용 표현을 모두 열거하기보다 현재 코드베이스의 맥락을 읽고 예외를 판단하게 한다. 절대 규칙은 정말 안전 경계가 필요한 곳에만 남긴다.
[03:14] 4. 규칙 2 — 예시를 쌓지 말고 인터페이스를 설계하라
도구 사용법을 설명하기 위해 예시를 계속 붙이면 모델이 일반 원칙을 배우기보다 예시 주변만 탐색하는 문제가 생길 수 있다. 영상은 소개팅 상대의 이상형 사진을 많이 보여주면 그 사진과 비슷한 사람만 찾게 되는 비유를 든다.
대신 도구의 입력·출력·상태를 잘 설계해 도구 자체가 의도를 말하게 한다. 예를 들어 할 일 관리 도구에 대기 중·진행 중·완료라는 세 상태와 명확한 전이 규칙을 주면, 장황한 설명 없이도 모델이 작업 흐름을 추론할 수 있다. 모델에게 시간을 쓰게 할 부분은 예시를 암기하는 일이 아니라, 손잡이와 제약을 이해하고 상황에 맞춰 판단하는 일이어야 한다.
[04:26] 5. 규칙 3 — 모든 정보를 미리 넣지 말고 필요할 때 꺼내게 하라
예전 방식은 프로젝트의 모든 규칙·노하우·주의 사항을 하나의 CLAUDE.md에 넣었다. 이 파일을 새 세션마다 통째로 읽히면 토큰 비용과 사용량 한도를 차지하고, 정작 현재 작업에 중요한 내용이 긴 목록 사이에 묻힌다.
CLAUDE.md를 프로젝트의 안내 데스크로 바꾸라는 제안이 나온다. 프로젝트 구조, 테스트·배포 위치, “관련 내용은 이 파일이나 이 스킬을 보라”는 라우팅만 남기고, 세부 절차와 도구 정의는 별도 파일이나 스킬로 쪼갠다. 모델이 해당 작업을 할 때만 열어보게 하는 점진적 공개(progressive disclosure)가 핵심이다. 다만 파일 구조만 봐서는 알 수 없는 프로젝트 고유의 함정과 예외는 안내 파일에 남겨야 한다.
[06:08] 6. 규칙 4 — 같은 말을 반복하지 말라
예전 모델은 긴 컨텍스트의 앞이나 중간 지침을 잊을 수 있어 같은 도구 사용법을 시스템 프롬프트와 도구 설명에 반복해서 적었다. 최신 모델을 전제로 하면 이 중복은 토큰만 늘리고, 두 위치의 문장이 서로 달라질 때 충돌 가능성까지 만든다.
도구 사용법은 도구 정의에, 프로젝트 전역 규칙은 CLAUDE.md에, 특정 업무 절차는 해당 스킬에 둔다. 한 규칙의 정본(canonical location)을 정하고 다른 곳에서는 다시 설명하지 않는 것이 비용과 혼란을 함께 줄인다.
[06:44] 7. 규칙 5 — 메모리는 자동화하라
초기에는 다음 세션에도 기억할 내용을 사용자가 직접 CLAUDE.md에 적거나 특수한 메모 명령으로 저장해야 했다. 영상은 최신 방식에서는 작업 중 “다음에도 재사용할 만한 지식”을 Claude가 알아서 메모리에 저장한다고 설명한다.
이 원칙은 모든 대화를 무차별적으로 보존하라는 뜻이 아니다. 일회성 잡담과 장기적으로 재사용할 프로젝트 사실·선호·절차를 구분하고, 중요한 정보는 여전히 사람이 검토해야 한다. 자동 메모리가 켜져 있다면 무엇이 저장됐는지와 오래된 사실이 남아 있지 않은지를 주기적으로 점검하는 운영이 필요하다.
[07:28] 8. 규칙 6 — Markdown 말고 더 깊은 자료를 줘라
계획서와 스펙을 단순한 Markdown으로만 전달하던 습관도 바뀌어야 한다. 최신 모델은 HTML, 실제 코드, 테스트 코드, PDF, 레퍼런스 이미지처럼 더 풍부하고 직접적인 자료를 분석할 수 있다. 디자인은 “모서리는 둥글고 조명은 따뜻하게”라고 길게 설명하는 것보다 참고 이미지를 주는 편이 빠르고, UI 포팅은 목표 HTML이나 동작하는 코드가 더 정확한 기준이 된다.
테스트 자체를 스펙으로 삼는 방법도 제시한다. “이 테스트를 통과하게 만들어라”는 요구는 모호한 자연어 설명보다 명확하다. 여기에 루브릭을 주면 에이전트가 자기 결과물을 기준표로 채점하게 할 수 있다. 즉 깊은 자료는 단순한 입력량 증가가 아니라, 모델이 추측하지 않아도 되는 실행 가능한 요구 사항과 검증 기준을 제공한다.
[08:58] 9. 여섯 규칙의 공통점 — 시니어에게 신입 매뉴얼을 주지 않기
정리 슬라이드는 변화를 한눈에 보여준다. 규칙 잔뜩 → 판단에 맡기기, 예시 잔뜩 → 인터페이스 설계, 처음부터 다 넣기 → 필요할 때 꺼내기, 여러 번 반복 → 한 번만 정본에 쓰기, 수동 저장 → 자동 메모리, 심플한 Markdown → HTML·코드·테스트·PDF 같은 깊은 자료다.
관통하는 메시지는 Claude가 더 이상 모든 행동을 한 줄씩 지시해야 하는 신입 사원이 아니라는 것이다. 모델이 충분히 강해질수록 컨텍스트 엔지니어의 역할은 행동을 미리 결정하는 사람이 아니라, 좋은 판단을 할 수 있도록 경계·도구·자료·검증 기준을 배치하는 설계자에 가까워진다.
[09:12] 10. 실전 적용 — /doctor로 컨텍스트를 다이어트하기
영상은 마무리에서 Claude Code를 최신 버전으로 업데이트하고 /doctor 명령을 실행하라고 제안한다. 이 명령으로 현재 스킬과 CLAUDE.md를 살펴보고, 규칙 6가지에 맞춰 줄이거나 옮길 부분을 찾는 흐름이다.
실무적으로는 먼저 전역 규칙·프로젝트 안내·업무별 스킬·도구 정의의 경계를 그린 뒤, 중복 지침을 하나씩 제거하면 된다. 긴 파일을 무작정 삭제하는 대신 테스트와 루브릭으로 결과를 검증하고, 실패가 반복되는 지점만 예외 규칙이나 별도 스킬로 되돌리는 방식이 안전하다.
부록 — 실전 체크리스트
-
CLAUDE.md에는 프로젝트 지도·실행 명령·테스트/배포 위치·숨은 함정만 남기고 세부 절차는 스킬 파일로 분리한다. - “절대 하지 마라”를 발견하면 안전 경계인지 단순한 과거 모델 보정인지 구분하고, 가능하면 판단 기준과 예외를 함께 쓴다.
- 도구 설명을 예시 모음으로 만들기 전에 입력·출력·상태·전이·실패 조건을 설계한다.
- 같은 지침이 시스템 프롬프트·
CLAUDE.md·도구 정의·스킬에 반복되는지 찾아 정본 하나로 통합한다. - 필요한 작업에서만 관련 문서와 도구를 열도록 링크·스킬·지연 로딩 구조를 만든다.
- 애매한 요구 사항은 실제 코드·테스트·HTML·레퍼런스 이미지·루브릭으로 바꾸고, 결과를 자동 또는 에이전트 리뷰로 검증한다.
-
/doctor실행 전후로CLAUDE.md와 저장된 메모리를 검토해 중요한 규칙이 사라지지 않았는지 확인한다.
원문 인용 모음
- [00:19] “이게 실제로 엔트로픽에서 벌어진 일입니다.”
- [00:31] “80% 이상을 삭제했는데 코딩 성능 평가 점수가 오히려 올랐죠.”
- [01:34] “이 매뉴얼을 잘 설계하는 게 컨텍스트 엔지니어링이고요.”
- [02:38] “주석 밀도, 이름 짓기, 관용 표현을 주변 분위기에 맞춰라.”
- [03:46] “예시를 지우고 도구의 설계 자체로 말하는 겁니다.”
- [04:19] “다 미리 주지 말고 필요할 때 꺼내게 하세요.”
- [06:04] “같은 말 반복하지 말기.”
- [07:18] “마크다운 말고 더 깊은 자료를 주세요.”
- [09:02] “클로드는 시니어가 됐는데 신입 사원처럼 대할 필요는 없습니다.”
관련 노트
- moc-claude-code — Claude Code 관련 노트의 허브.
- moc-ai-agents-context-stack — 에이전트의 컨텍스트·메모리·도구 계층을 묶은 MOC.
- code-native-memory — 프롬프트에 모든 맥락을 넣지 않고 코드·파일·구조로 기억을 외부화하는 관점.
- 2026-07-28-boris-cherny-cut-80-percent-prompt — Boris Cherny의 시스템 프롬프트 80% 삭제와 모델별 ablation·검증 중심 프롬프팅 관련 노트.