엔트로픽이 클로드 코드 지시문 80%를 지웠는데 성능은 그대로였다

01핵심 개요

• 엔트로픽이 2026년 7월 24일 공개 글에서 클로드 코드 시스템 프롬프트를 "80% 넘게" 삭제했다고 공개.
• 시스템 프롬프트 분량이 약 2,600여 단어에서 500단어 근처로 축소됐지만 "코딩 평가에서 측정 가능한 손실이 없었다".
• 문제의 이름은 "과잉 제약(오버컨스트레이닝)" — 시스템 프롬프트·프로젝트 지시문 파일·스킬 세 곳에 겹치고 충돌하는 규칙이 쌓여 있었다.
• 9월 1일 출시된 "페이블 5.1"(내부명 미토스 5.1) 공식 프롬프팅 문서는 서식·파일 편집·범위 관련 억제 문구를 제거하거나 조건부 문장으로 바꾸라고 권고.
• 클로드 코드 팀 캣 우와 타릭 시파르, 그리고 사이먼 윌리슨의 발언을 근거로 "무엇을 남기고 무엇을 지울지" 기준을 제시.

02핵심 주장 / 논점 구조

• 출발점: 지시를 더 줬는데 결과가 나빠지는 현상 — 예시를 그대로 베끼거나, "하지 마라"를 나열했더니 정작 해야 할 일을 안 하는 문제.
• 1단계 주장(엔트로픽): 실제로 무엇을 얼마나 지웠는가 — 시스템 프롬프트 80%+ 삭제, 코딩 평가 손실 없음.
• 2단계 주장(캣 우·타릭): 왜 지시가 많으면 성능이 떨어지는가 — 규칙 간 충돌 시 모델이 작업 전에 "어느 규칙이 우선인지" 판정부터 해야 하고, 그 판정에 원래 일에 쓸 힘을 소모.
• 3단계 주장(페이블 5.1 문서·사이먼 윌리슨): 그럼에도 남겨야 하는 지시는 무엇인가 — 모델이 "알 수 없는 정보"는 반드시 남기고, 모델이 "혼자 판단할 수 있는 일"은 지운다.
• 반증적 사례: 캣 우는 퓨샷 예시를 "최고의 프롬프팅 팁"으로 꼽지만 타릭은 정반대로 예시 제거가 창의성을 높였다고 증언 — 두 사람의 차이는 모델 세대(능력)에서 갈린다.

03엔트로픽이 실제로 지운 것들

• 절대 명령형 문장("항상 테스트를 실행해라" 등) 제거 — 90%만 참인 규칙이 나머지 10% 상황에서 모델을 잘못된 방향으로 끌고 감을 확인.
• 예시(퓨샷) 블록 제거 — 예시는 "정답의 모양"을 알려줄 뿐인데, 능력이 충분한 모델은 그 모양을 목표로 착각해 더 나은 답이 있어도 예시 모양에 맞춘다는 것이 타릭의 설명.
• 대안으로 제시된 것은 "인터페이스" — 도구·스크립트·파일을 잘 설계해 모델이 쓸 수 있는 파라미터와 표현력을 늘리는 방향.
• 오프스 4.5에서 4.6으로 넘어갈 때 작업을 잘게 쪼개던 하니스 구조 하나를 통째로 제거할 수 있었던 사례 — 모델이 더 오래 버티고 스스로 실수를 잡아내게 되면서 그 구조가 불필요해짐.

04전략적 의미

• "지시를 늘리는 것"이 곧 "제어력을 높이는 것"이라는 프롬프트 엔지니어링의 오랜 전제가 최신 모델(클로드 오프스 5, 페이블 5.1)에서는 성립하지 않는다.
• 엔트로픽 프리트 라자세카란의 표현을 빌리면, 하니스(모델 바깥에 사람이 붙인 절차·구조·점검 규칙 전부)의 모든 조각은 "모델이 스스로 못 하는 일"이라는 가정을 담고 있고, 그 가정은 모델이 바뀔 때마다 재검사가 필요하다.
• 즉 프롬프트/지시문 관리가 일회성 작성이 아니라, 새 모델이 나올 때마다 재점검해야 하는 "지속적 유지보수" 대상으로 재정의된다.
• 비유: "비계는 건물이 완성되면 걷어내는 것"인데, 실무에서는 대체로 비계를 계속 덧대고 있었다는 지적.

05남길 것 vs 지울 것 비교표

06활용 시나리오

• CLAUDE.md·프로젝트 지시문 파일을 가진 개발자: 파일을 열어 "항상/절대"로 시작하는 문장을 전부 찾아 예외가 하나라도 있으면 조건부 설명으로 교체.
• 예시(퓨샷) 블록을 프롬프트에 넣어둔 사용자: 예시를 임시로 지우고 동일 작업을 재시도 — 결과가 나빠지지 않으면 그 예시는 이미 성능 천장으로 작용 중이었다는 신호.
• 새 규칙을 추가하려는 사람: 추가 전에 "이건 모델이 못하는 일인가, 아니면 모델이 알 수 없는 정보인가"를 자문 — 전자는 실제로 못하는지 재확인(생각보다 자주 아님), 후자만 반드시 남김.
• 서브에이전트·비용 최적화 담당자: 사이먼 윌리슨처럼 "어떤 작업에 어떤 모델을 쓸지" 표를 만들지 않고 "적절한 저전력 모델을 판단해서 쓰라"는 한 줄 지시로 대체.

07현황 및 전망

• 타임라인: 2026-07-03 사이먼 윌리슨 글 → 2026-07-24 엔트로픽 컨텍스트 엔지니어링 블로그(타릭 시파르) → 캣 우·타릭 공개 대담(사이먼 윌리슨 진행) → 2026-09-01 페이블 5.1 출시 및 공식 프롬프팅 문서 공개.
• 페이블 5.1과 동시에 나온 "미토스 5.1"은 초대받은 곳에서만 사용 가능해 영상에서는 페이블 5.1 기준으로만 논의됨.
• 사이먼 윌리슨은 판단 위임 방식 적용 후 "일은 훨씬 많이 하는데 사용량은 예전보다 천천히 줄고 있다"고 후기를 남겨, 비용 효율 측면에서도 긍정적 신호로 소개됨.
• 메이커 에반은 영상 말미에 시청자에게 "지웠더니 더 잘되더라"는 지시문 사례를 댓글로 요청 — 이 트렌드가 아직 개별 사용자 단위로 검증·수집되는 초기 단계임을 시사.

08용어 사전

• 과잉 제약(오버컨스트레이닝): 시스템 프롬프트·지시문 파일·스킬 등 여러 곳에 겹치거나 충돌하는 규칙이 쌓여 모델 성능을 오히려 저해하는 상태.
• 퓨샷(few-shot) 예시: 원하는 답의 형태를 예시 2~3개로 보여주는 프롬프팅 기법. 능력 낮은 모델엔 도움이 되지만 능력 높은 모델엔 천장으로 작용할 수 있음.
• 하니스(harness): 모델 바깥에 사람이 만들어 붙인 장치 전부 — 계획 단계 강제 절차, 작업 분할 구조, 중간 점검 규칙 등.
• 컨텍스트 엔지니어링: 프롬프트 문구 자체보다 모델에게 주어지는 맥락(지시문, 도구, 정보 구조) 전체를 설계하는 접근.
• 페이블 5.1: 영상에서 다루는 최신 클로드 세대 모델(오프스/소네트 5.1 계열)의 코드명. 별도 코드명 "미토스 5.1"은 초대받은 곳에서만 사용.