Claude Code 시스템 프롬프트 감축과 최소 컨텍스트 설계

Anthropic이 Claude Code의 시스템 프롬프트를 Claude 5 세대로 옮기는 과정에서 80% 이상을 삭제했지만, 코딩 평가 점수에서는 측정 가능한 성능 손실이 없었다는 사례가 2026년 7월 개발 커뮤니티에서 다시 언급됐다. 약 800토큰이던 프롬프트는 164토큰이 됐고, 사용자 콘텐츠에 쓸 수 있는 공간은 요청당 약 636토큰 늘어났다.

이 변화는 단순한 압축 사례가 아니다. 삭제된 지시 가운데 상당수는 서로 충돌했고, 모델은 파일을 수정하기 전부터 어느 지시를 우선해야 하는지 판단하는 데 추론을 써야 했다. 프롬프트의 길이보다 지시 체계의 구조가 더 큰 문제가 된 것이다.

긴 지시문이 모델을 돕지 못하는 순간

한 지시는 적절한 문서화를 요구하는데 다른 지시는 주석을 추가하지 말라고 하면, 모델은 작업 내용보다 지시 간 우선순위를 먼저 해석해야 한다. 이 판단은 호출마다 달라질 수 있으며, 결과의 일관성도 약해진다.

최소 컨텍스트 설계는 네 방향으로 이동한다.

규칙을 늘리는 대신 모델이 판단할 여지를 남긴다.
사용 예시를 계속 나열하기보다 스키마와 타입이 드러나는 인터페이스를 만든다.
모든 정보를 처음부터 주입하지 않고, 파일 읽기·도구 호출·참조 문서 조회를 통해 필요한 시점에 제공한다.
반복된 지시는 단일 출처로 모은다.

Claude Code에는 Claude 5 세대에서 더 이상 필요하지 않은 지시를 자동 식별하는 /doctor 명령도 제공된다. 다만 진단 결과가 곧 삭제 결정은 아니다. 안전 경계와 평가 결과를 함께 봐야 한다.

프롬프트 자산을 계층과 예산으로 관리하기

시스템 프롬프트는 같은 위험도로 다룰 수 없다. 불변 정체성과 안전 경계는 최상위에 두고, 조직 표준·작업별 지시·세션 컨텍스트를 그 아래에 배치한다. 감축 후보는 안전 경계가 아니라 반복, 중복, 구세대 모델의 오동작을 보정하려고 추가된 지시다.

또한 시스템 프롬프트는 독립적으로 존재하지 않는다. 매 호출의 컨텍스트 예산에는 시스템 프롬프트, 도구 정의, 대화 이력, 검색 결과, 사용자 입력이 함께 들어간다. 항목별 상한이 없으면 시스템 프롬프트가 계속 증식하고, 그만큼 사용자 콘텐츠가 들어갈 공간은 줄어든다.

도구 설명도 같은 관점에서 관리해야 한다. 도구가 많아지면 설명의 총량이 시스템 프롬프트보다 커질 수 있다. 도구 사용 규칙은 도구 설명에 두고, 전역 원칙은 시스템 프롬프트에 둔다. 양쪽에 같은 규칙을 적으면 중복일 뿐 아니라 상충 가능성도 생긴다.

⤢✕

삭제는 범주별로 진행하고 결과를 남긴다

먼저 시스템 프롬프트, 규칙 파일, 도구 설명, 에이전트별 지시문, 사내 프롬프트 라이브러리를 모두 수집한다. 각 지시에는 도입 시점과 도입 사유를 남긴다. 왜 들어갔는지 알 수 없는 지시는 우선적인 삭제 후보가 되며, 상당수는 구세대 모델의 특정 오동작을 막기 위해 추가된 항목일 수 있다.

감축 순서는 중복 제거, 상충 해소, 구세대 보정용 지시 삭제, 예시의 인터페이스 전환, 점진적 공개 전환으로 잡을 수 있다. 한 번에 전량을 지우기보다 범주 단위로 진행해야 실패했을 때 원인 범주를 추적할 수 있다. 삭제 이력도 버전 관리해 부분 복원이 가능해야 한다.

감축안은 평가 하네스에 통과해야 적용한다. 하네스에는 대표 과제 평가셋, 형식 준수 검증, 실패 사례 회귀셋, 토큰 사용량 계측이 포함된다. 운영 게이트에서는 과제 성공률, 형식 준수율, 안전 정책 준수율, 평균 토큰·지연을 확인한다.

안전 정책 준수율은 별도 게이트로 둔다. 성능 지표가 유지되더라도 안전 경계가 약화됐다면 삭제를 되돌려야 한다.

감축안과 상세 지시를 선택하는 기준

구분	감축 프롬프트	상세 지시 유지
최신 세대 성능	유지 또는 개선	저하 가능(지시 충돌)
구세대 호환성	저하 위험	안정
토큰 비용	낮음	높음
사용자 콘텐츠 여유	확대	축소
동작 예측성	모델 판단 의존	명시적
유지보수	단순	지시 누적으로 악화

약 800토큰에서 164토큰으로 줄이는 동안 성능 손실이 없었다는 결과는, 삭제된 636토큰의 상당 부분이 순수한 잡음이었음을 시사한다. 상세 지시는 동작 예측성을 줄 수 있지만, 누적되면 충돌로 인해 그 예측성 자체가 무너질 수 있다.

구세대용 프롬프트를 신세대 모델에 그대로 재사용하면 즉시 동작하고 별도 공수도 들지 않는다. 반면 과거의 오동작을 보정하던 지시가 새 모델에는 과제약으로 작용할 수 있다. 세대별 재작성은 공수가 필요하지만 프롬프트 자산을 정리하고 토큰 예산을 회복한다.

수동 감축은 도메인 맥락을 반영하기 쉽지만 삭제 판단이 주관적이고, 대규모 프롬프트 자산에서는 누락이 생길 수 있다. 평가 기반 자동 축약은 후보를 기계적으로 제거하고 하네스로 검증하므로 규모 확장에 유리하다. 다만 안전 경계가 삭제 후보가 되지 않도록 보존 목록을 분명히 해야 한다. 벤더 진단 명령은 1차 스크리닝에 쓰고, 최종 판단은 하네스 결과로 내리는 조합이 적합하다.

프롬프트를 사양과 형상 항목으로 다루기

프롬프트는 코드가 아니라 사양이다. 사양에 상충 조항이 있으면 구현이 흔들리는 것처럼, 프롬프트의 충돌도 모델의 동작을 흔든다.

점진적 공개는 정보 은닉과 지연 로딩을 프롬프트에 적용한 형태로 볼 수 있다. 전량을 미리 제공하면 결합도와 변경 비용이 커진다. 반대로 시스템 프롬프트를 얇게 유지하고 도구·파일·스키마를 정보 전달 경로로 쓰면, 필요한 정보만 필요한 시점에 다룰 수 있다.

단일 출처 원칙도 그대로 적용된다. 같은 규칙을 여러 위치에 쓰면 갱신 과정에서 일부가 빠지고, 그 순간 상충 지시가 만들어진다. 새 지시를 추가할 때는 사유, 대상 모델 세대, 만료 검토 시점을 기록해야 한다. 그렇지 않으면 프롬프트는 삭제 근거를 잃은 지시의 퇴적층이 된다.

시스템 프롬프트 토큰은 모든 요청에 곱해지는 고정 비용이다. 요청당 636토큰을 줄이면 호출량이 커질수록 절감액은 선형 증가한다. 프롬프트 캐싱을 적용하면 접두 감축의 직접 비용 효과는 줄어들지만, 사용자 콘텐츠를 위한 컨텍스트 여유 확대 효과는 유지된다.

세대 전환 때 다시 점검할 항목

프롬프트는 모델 버전과 쌍으로 저장할 필요가 있다. 세대 전환 시에는 기존 프롬프트를 그대로 옮기기보다 감축 절차를 다시 실행하고, 이를 정례 절차로 편입한다. 세대 전환이 월 단위로 반복되는 환경이라면 감축 방법 자체를 표준화해 반복 비용을 낮추는 일이 과제가 된다.

프롬프트 최적화는 지시를 추가하는 작업에서 불필요한 지시를 제거하는 작업으로 이동하고 있다. 이 변화는 평가 하네스를 전제로 한다. 하네스가 없으면 감축으로 인한 손실을 사용자 신고가 들어온 뒤에야 알게 될 수 있다.