Anthropic은 왜 Claude Code 시스템 프롬프트의 80%를 지웠을까

AI가 실수할 때마다 규칙을 하나씩 추가하다 보면 시스템 프롬프트는 금세 두꺼워집니다. 숫자를 틀리면 “숫자를 틀리지 마”, 글이 길면 “세 문장 이내로 써”, 형식이 달라지면 예시를 하나 더 붙이는 식입니다. 그런데 모델이 충분히 발전한 뒤에도 이 규칙들이 그대로 필요할까요?

Anthropic은 최근 반대 방향의 실험 결과를 공개했습니다. Claude Code의 신형 모델용 시스템 프롬프트를 80% 이상 줄였지만, 자체 코딩 평가에서는 측정 가능한 성능 저하가 없었다는 내용입니다.

핵심은 “시스템 프롬프트를 없애라”가 아닙니다. 모델이 이미 할 수 있는 일을 붙잡고 있던 낡은 지시는 줄이고, 안전·권한·검증은 더 분명한 시스템으로 남기라는 이야기입니다.

무슨 일이 있었나: 시스템 프롬프트 80% 이상 삭제

Claude Code 팀의 Thariq Shihipar는 2026년 7월 24일 공개한 Claude 공식 글에서 Claude Opus 5와 Claude Fable 5 같은 신형 모델을 대상으로 시스템 프롬프트를 80% 이상 제거했다고 밝혔습니다. 결과는 “자체 코딩 평가에서 측정 가능한 손실이 없었다”였습니다. 같은 내용을 X 게시물로도 공유했습니다.

여기서 주의할 점이 있습니다. 시스템 프롬프트를 80% 줄이자 성능이 80% 좋아졌다는 뜻이 아닙니다. 모든 모델과 모든 업무에서 80%를 지우면 된다는 공식도 아닙니다. 공개된 범위는 Claude Code의 신형 모델과 Anthropic 내부 코딩 평가이며, 세부 평가 데이터는 공개되지 않았습니다.

중복되고 충돌하는 AI 지시를 줄이고 도구와 안전 및 검증 장치를 남기는 과정을 표현한 개념도

줄여야 하는 것은 중복 지시와 낡은 보정 규칙입니다. 도구·권한·안전·검증은 여전히 핵심 구조로 남습니다.

왜 지시가 많을수록 오히려 방해가 됐을까

Anthropic이 내부 사용 기록에서 발견한 첫 번째 문제는 지시의 충돌이었습니다. 시스템 프롬프트에서는 주석을 쓰지 말라고 하고, 사용자 요청이나 Skill에서는 필요한 문서를 남기라고 하면 모델은 본업보다 지시 사이의 우선순위를 해석하는 데 더 많은 판단을 써야 합니다.

두 번째는 예시의 제약입니다. 과거 모델에는 구체적인 예시가 사용법을 알려주는 좋은 장치였습니다. 하지만 더 강한 모델에서는 몇 개의 예시가 가능한 해결 방법의 경계를 좁힐 수 있습니다. Thariq는 AI Engineer 발표 6분 3초부터 신형 모델에는 더 작은 프롬프트가 맞았고, 예시가 모델의 상상력을 제한할 수 있었다고 설명합니다.

세 번째는 모든 정보를 미리 넣는 방식입니다. 코드 검토 절차가 필요하지 않은 작업에도 관련 지침을 매번 넣으면 정작 중요한 맥락의 신호가 약해집니다. 그래서 Anthropic은 검증이나 코드 리뷰 같은 절차를 별도 Skill로 옮기고, 필요한 순간에만 불러오는 점진적 공개 방식을 사용하고 있습니다.

그렇다고 하네스를 없앤 것은 아니다

이 내용을 “하네스 엔지니어링보다 프롬프트를 없애는 것이 낫다”라고 요약하면 중요한 절반이 빠집니다. 시스템 프롬프트는 하네스의 한 구성요소일 뿐입니다. 하네스에는 모델이 사용할 도구, 접근 권한, 메모리, 상태관리, 안전장치, 검증 방식과 사용자 인터페이스도 포함됩니다.

Claude Code 창시자 Boris Cherny는 Y Combinator 인터뷰 6분 28초에서 현재 하네스 코드의 많은 부분이 안전, 권한, 정적 분석과 사용자 인터페이스에 쓰인다고 설명합니다. 없앤 것은 하네스 자체가 아니라, 이전 모델의 행동을 보정하기 위해 쌓아두었던 설명형 지시와 일부 보조 장치에 가깝습니다.

오히려 Claude 공식 글은 자체 에이전트 하네스를 만든다면 시스템 프롬프트가 제품의 역할과 맥락을 정하는 곳이므로 충분한 시간을 들여야 한다고 말합니다. 짧다는 사실보다 어떤 책임을 어디에 둘 것인지가 더 중요합니다.

Anthropic이 제안한 여섯 가지 변화

기존 방식	새로운 방향
세부 규칙을 계속 추가	주변 맥락을 보고 판단할 기준 제공
도구 사용 예시를 여러 개 제공	표현력이 좋은 도구 인터페이스 설계
모든 정보를 처음부터 삽입	필요한 순간에만 맥락을 불러오는 점진적 공개
같은 지시를 여러 곳에서 반복	한 곳의 간결한 도구 설명으로 통합
CLAUDE.md에 기억을 계속 축적	자동 메모리와 목적별 파일 활용
짧은 설명형 스펙 전달	코드·테스트·HTML·승인 양식 같은 풍부한 참고자료 제공

이 변화에서 눈에 들어오는 건 프롬프트 작성 기술이 사라진 것이 아니라 컨텍스트 설계의 단위가 문장에서 시스템으로 넓어졌다는 점입니다. 무엇을 말할지뿐 아니라, 어떤 자료를 언제 보여주고 어떤 행동을 도구로 제한하며 어떻게 결과를 검증할지를 함께 설계해야 합니다.

실제 방법은 삭제가 아니라 ‘삭제 후 재검증’이다

Boris가 설명한 방법은 단순합니다. 새 모델이 나오면 기존 시스템 프롬프트를 비우고 실제 과제를 수행하게 합니다. 결과를 관찰한 다음, 같은 실패가 반복될 때만 필요한 지시를 한 줄씩 되살립니다. 연구에서 말하는 제거 실험, 즉 ablation에 가까운 방식입니다.

현재 결과를 비교할 수 있도록 대표 과제와 기준선을 남긴다.
중복·충돌·구형 모델 보정용 지시를 제거한다.
같은 과제를 새 모델로 실제 수행한다.
한 번의 실수가 아니라 반복되는 실패를 찾는다.
그 실패를 막는 최소한의 지시나 장치만 복원한다.
결과를 다시 평가하고 모델이 바뀔 때 재검토한다.

인터뷰 6분 3초부터 전체 프롬프트를 지운 뒤 한 줄씩 복원해 각 지시의 영향을 확인하는 과정을 설명합니다. 이어 7분 41초부터는 삭제한 상태로 먼저 사용하고, 같은 지점에서 계속 실패할 때만 다시 추가하라고 강조합니다.

AI 지시를 제거하고 실제 작업과 반복 실패를 관찰한 뒤 필요한 지시만 복원하는 검증 순환도

삭제 → 실제 사용 → 반복 실패 관찰 → 필요한 한 줄만 복원 → 재검증의 순환입니다.

본사 업무에 적용하면 어떻게 달라질까

예를 들어 매주 만드는 경영진 현황 보고를 생각해볼 수 있습니다. 매번 AI에게 사규집과 작성법 전체를 붙이는 대신, 항상 필요한 원칙과 해당 업무에서만 필요한 절차를 분리하는 방식입니다.

구성	주간 경영진 현황 보고 예시
기본 지시	결론 우선, 기준일 표시, 확인되지 않은 숫자 추측 금지
업무별 Skill	부서 자료 취합 → 증감 원인 분류 → 핵심 이슈·대응 작성
참고자료	지난주 승인 보고서, 경영진 보고 양식, 용어 정의, 이번 주 부서 제출자료
시스템 통제	개인정보 마스킹, 외부 전송 제한, 열람 권한, 최종 승인 절차
검증	합계 일치, 전주 대비 증감, 기준일, 출처, 누락 부서 확인

회의록도 같습니다. 모든 회의 규칙을 상시 프롬프트에 넣기보다, 회의록을 작성할 때만 결정사항·담당자·기한·공유사항을 분리하는 절차를 불러오면 됩니다. 자료 취합에서는 승인된 양식과 실제 원본을 참고자료로 주고, 숫자와 출처는 별도 검증 단계에서 확인하는 편이 더 안정적입니다.

본사에서 원본 자료와 승인 양식을 바탕으로 AI 보고서를 만들고 권한과 숫자를 검증하는 업무 흐름

본사 업무에서는 지시문보다 공식 원본, 승인 양식, 접근권한과 숫자 검증의 역할 분리가 더 중요합니다.

줄여도 되는 것과 반드시 남겨야 하는 것

우선 삭제 후보

다른 위치에도 똑같이 적혀 있는 중복 지시
서로 충돌하는 문체·형식 규칙
파일이나 공식 양식만 봐도 알 수 있는 설명
이전 모델의 반복 실수를 막기 위해 추가했던 임시 보정문
특정 업무에서만 필요한데 매번 불러오는 긴 절차

유지하거나 시스템으로 강화할 것

개인정보·고객정보·대외비 처리 기준
외부 공개와 발송 전 승인 권한
금액·인원·실적 등 중요 수치와 출처 검증
파일 삭제, 시스템 변경처럼 되돌리기 어려운 작업의 권한 통제
완료 여부를 판단하는 테스트·체크리스트·평가 기준

Anthropic의 Claude Code 운영 가이드도 같은 방향입니다. 상시 문서는 가볍게 유지하고, 반복 절차는 Skills로 옮기며, 반드시 실행돼야 하는 통제는 권한 설정이나 결정론적 Hook으로 강제하라고 권고합니다.

무작정 80%를 지우기 전에 확인할 것

이번 사례는 매우 흥미롭지만 숫자만 따라 하면 위험합니다. Claude Code의 내부 코딩 평가에서 나온 결과를 일반 문서 작성, 고객 응대, 금융·보험 의사결정에 그대로 적용할 근거는 아직 없습니다. 특히 규제, 개인정보, 외부 공시와 관련된 기준은 모델의 재량에 맡길 영역이 아닙니다.

좋은 점검 질문은 “얼마나 줄였는가”가 아니라 다음에 가깝습니다.

이 지시를 지웠을 때 실제로 같은 실수가 반복되는가?
이 내용은 상시 원칙인가, 특정 업무의 절차인가?
문장으로 부탁할 일인가, 권한이나 시스템으로 강제할 일인가?
설명보다 공식 문서·승인 양식·원본 데이터가 더 정확한 참고자료는 아닌가?
결과가 좋다는 것을 무엇으로 검증할 것인가?

지시는 가볍게, 참고자료는 풍부하게, 검증은 강하게. 신형 AI를 제대로 활용하는 방법은 더 긴 주문문을 만드는 것이 아니라, 모델이 판단할 영역과 조직이 책임지고 통제할 영역을 구분하는 데 있는 것 같습니다.