지난주 Y Combinator는 Claude Code를 구축한 엔지니어 Boris Cherny와의 인터뷰를 게시했습니다. 인터뷰 내용은 새로운 Opus 5 출시와 관련된 것이었습니다 (

). 영상은 배경에서 재생되고 있었고, 저는 그가 회의실에서 다음과 같이 말하기 전까지는 반쯤 건성으로 듣고 있었습니다:

...당신의 CLAUDE.md를 삭제하고, 당신의 skills를 삭제하고, 당신의 hooks를 삭제하세요...

워우! 뭐라고요?! 잠시 되감아 봅시다... 제가 잘못 들었을지도 모르겠네요:

...에이전트형 제품 (agentic products)을 만들고 있는 것이 아니라 Claude Code를 사용하고 있는 분들이라면, 6개월마다 당신의 CLAUDE.md를 삭제하고, 당신의 skills를 삭제하고, 당신의 hooks를 삭제하세요. 모델이 어떻게 작동하는지 확인해 보세요. 그러면 놀라게 될 수도 있습니다. 실제로 Opus 5의 경우, 이 모든 것들을 그냥 삭제해 보는 것을 정말로 권장합니다. 왜냐하면 모델이 이전 모델들에서 필요했던 그 모든 지침들을 정말로 필요로 하지 않을 수도 있기 때문입니다. (

)

좋습니다, 이제 영상을 처음부터 다시 볼 시간입니다.

영상에 담긴 내용

같은 대화의 앞부분에서 진행자는 Anthropic이 자체적으로 수행한 작업에 대해 다음과 같이 언급했습니다: **_

그렇다면 Anthropic은 어떻게 그런 결정을 내렸을까요? 내부적으로는 절제 연구 (ablation)를 수행했습니다: "전체 시스템 프롬프트 (system prompt)를 삭제한 다음, 각 개별 라인이 미치는 영향을 파악하기 위해 한 줄씩 다시 가져오는 방식" (

). 한 번에 한 줄씩, 각각에 대해 측정된 전후 상태를 확인했습니다. 이 과정이 현장의 개발자에게 전달될 때쯤에는 "그냥 삭제하고 확인해 보세요"라는 말로 압축되었습니다.

그렇다면 왜 이번 여름에 출시된 모델이, 당신이 4.x 버전에 맞춰 튜닝했던 지침 파일 (instruction file)과 다르게 동작하는 것일까요?

Opus 5가 당신의 지침에 변화를 준 점

저는 LLM-as-a-judge (판단자로서의 LLM) 방식이 아닌 결정론적 지침 평가 (deterministic instruction evals)를 연구합니다. 그래서 저는 어떤 일이 왜 일어나고 있는지, 그리고 성능 저하 (regression) 대신 업그레이드를 얻으려면 당신의 지침을 어떻게 검토해야 하는지 더 깊이 살펴보았습니다. 이 모델 생성 과정에는 당신이 1년 전에 작성한 파일이 적용되는 방식을 변화시키는 세 가지 메커니즘이 있으며, 이들은 복합적으로 작용합니다.

지침 검색 강도 (Instruction retrieval strength)

이제 모델이 더 넓은 범위에서 지침을 찾아냅니다. 따라서 이전에는 잠자고 있던 모호하고 추상적인 규칙들조차, 작성 의도가 없었던 작업에서도 활성화됩니다. 그리고 모호한 규칙은 결합할 구체적인 대상이 없기 때문에, 규칙이 활성화될 때 모델은 당신이 의도한 결과 대신 자신의 판단으로 그 공백을 채워버립니다.

내장된 LLM-as-a-judge

LLM-as-a-judge 과정이 내장되어 있는데, 제 관점에서는 일반적으로 좋지 않은 아이디어입니다. 모델이 기본적으로 자신의 출력을 스스로 평가하고 재확인합니다. 당신이 기존에 작성했던 "검증 / 재확인" 관련 문구들이 그 위에 쌓이게 되면 과도한 검증 (over-verifies)이 발생하며, 과도한 검증은 해당 턴에 더 많은 지침을 끌어들여 넓은 검색 (retrieval)이 이미 촉발한 경쟁을 더욱 심화시킵니다.

장기적 과업 (Long-horizon tasks)

Opus 5는 이제 Boris가 '자동 모드 (auto mode)'라고 부르는 장기적 과업 (long-horizon tasks)을 수행합니다. 이를 위의 두 메커니즘과 연결하면 동일한 문제가 다시 발생합니다. 추적 (trace)이 길어질수록 모델이 스스로 생성한 단계와 가설들이 당신의 지침을 밀어내게 되며, 그중 가장 취약한 지침부터 먼저 밀려나게 됩니다.

이 세 가지를 종합해 보면, 4.x 버전에서 잘 작동하던 CLAUDE.md가 코드 한 줄 건드리지 않았음에도 5 버전에서는 작동을 멈춘 것처럼 느껴질 수 있습니다. 파일을 삭제하면 노이즈가 즉시 사라지는데, 이것이 바로 "그냥 삭제하라"는 조언이 효과가 있는 이유입니다.

Three cards feeding one result: wider retrieval fires more of your vague rules, the baked-in self-judge stacks your redundant checks, and a long horizon buries what survived, together producing a CLAUDE.md that behaved on 4.x but feels like it quit working on 5 without you touching a line. None of the three is about file size.

Boris의 말이 73% 맞습니다

불필요한 것들을 삭제하라는 것은 타당한 조언입니다. 왜냐하면 당신의 지침 파일(instruction file) 대부분은 사실 지침이 아니었기 때문입니다. 우리는 에이전트 지침 파일을 포함하고 있는 약 30,000개의 공개 저장소(public repositories)를 대상으로 결정론적 분석기(deterministic analyzer)를 적용하여 모든 파일을 동일한 방식으로 읽었습니다. 모델을 개입시키지 않았으며, 동일한 파일에 대해 매번 동일한 결과를 얻었습니다. 해당 보고서의 핵심 내용은 다음과 같습니다: "당신의 지침 파일 중 당신이 의도한 대로 작동하는 부분은 단 27%뿐입니다. 나머지 73%는 스캐폴딩 (scaffolding)입니다" (The State of AI Instruction Quality). 제목, 재진술된 문맥(restated context), 예시, 그리고 모델에게 아무것도 시키지 않으면서 파일을 정리하기만 하는 산문(prose) 등이 이에 해당합니다. ETH Zürich의 독립적인 저장소 문맥 파일(repository context files) 연구에서도 동일한 결론을 내렸습니다. 지침은 준수되지만, 우리가 말하는 스캐폴딩(scaffolding)에 해당하는 기술적 개요(descriptive overviews)는 결과물을 개선하지 못하며 추론 비용(inference cost)을 20% 이상 증가시킵니다 (Evaluating AGENTS.md). Boris는 Claude Code 자체의 시스템 프롬프트(system prompt) 중 모델이 이미 초월해버린 스캐폴딩(scaffolding)을 80% 삭감했습니다. 우리의 데이터에 따르면 일반적인 개발자의 CLAUDE.md 역시 약 4분의 3이 사장된 데이터(dead weight)이며, 이는 Opus 5가 출시되기 훨씬 전부터 이미 그러했습니다.

A horizontal bar split 73 to 27: 73% scaffolding safe to delete, the headings, restated context, examples, and prose that tell the model nothing, versus 27% that is the part which could actually bind. A note marks that 89.9% of files carry at least one rule inside that 27% which names nothing. Boris is right about the 73%; the 27% left is where deleting stops helping.

남아 있는 27%는 그 비율이 시사하는 것보다 더 심각한 상태입니다. 동일한 코퍼스(Corpus) 내에서 에이전트 설정(Agent configs)의 89.9%는 자신이 무엇을 의미하는지 결코 명시하지 않는 지침을 최소 하나 이상 포함하고 있습니다 (The Undiagnosed Input Problem). 예를 들어

삭제 목록 안에는 범주 오류(category error)도 포함되어 있습니다. 왜냐하면 이는 CLAUDE.md를 넘어 기술(skills)과 훅(hooks)의 영역까지 넘어가기 때문입니다. 훅(hook)은 결정론적인 게이트(deterministic gate)입니다. 모델에게 문장을 평가하도록 요청하는 대신 행동을 즉각 거부합니다. 거부 규칙(deny-rule), 파괴적 명령 블록(destructive-command block), 또는 준수 확인(compliance check)은 모델의 능력이 향상되었다고 해서 그 필요성이 줄어들지 않습니다. 강제 집행(Enforcement)은 애초에 모델의 판단에 의존하지 않았으므로, 모델 업그레이드가 이를 폐기시키지 않으며, 훅의 부재가 재삽입 루프(add-back loop)가 잡아낼 수 있는 가벼운 실수로 나타나지도 않습니다. 대신 이는 실행되어 버리는 파괴적 명령으로 나타납니다. 모델이 더 이상 필요로 하지 않는 산문(prose)은 잘라내되, 게이트(gate)는 유지하십시오. 저는 이 분리에 대해 별도의 글에서 더 자세히 다루었습니다: 프롬프트는 조종하고, 훅은 강제한다 (prompts steer, hooks enforce).

A model upgrade splits two layers: steering prose the model may outgrow and can be cut, versus a deterministic hook gate that denies rm -rf, force-push and prod writes and does not expire on upgrade.

그 비용 (What it costs)

규칙을 삭제하고 모델이 망가지는 것을 지켜보며 어떤 규칙이 중요했는지 다시 배우는 것은, 시간이나 토큰(token) 제약이 없을 때는 공정한 거래입니다. 또한 거의 무제한에 가까운 예산을 가진 Anthropic 파워 유저에게 '실패를 통한 재발견 루프(rediscover-by-failure loop)'는 배경 소음에 불과합니다. 하지만 일반적인 예산을 가진 개발자에게는 그렇지 않으며, 그 비용은 결코 파일 하나로 끝나지 않습니다. 당신이 작업하는 모든 프로젝트에 걸쳐 모든 memory.md 참조, 모든 CLAUDE.md, 모든 규칙, 기술, 그리고 에이전트(agent)를 하나씩 제거(ablation)하는 상황을 상상해 보십시오. 규칙을 삭제하고 실수가 발생하기를 기다린다는 것은, 자신의 작업이 한 번에 하나씩 망가지는 것을 지켜보며 당신의 지침이 무엇을 위한 것이었는지 배우는 것을 의미하며, 결국 당신은 이미 가지고 있던 파일에서 그 기간 동안 우연히 망가지지 않은 것들을 제외하고 다시 배우게 될 뿐입니다. 정적 읽기(static read)는 단 한 번의 실패를 발생시키지 않고도 어떤 규칙이 구속력을 갖는지 알려줍니다.

접근 방법 (How to approach it)

그러니 파일을 읽으세요. 줄이지 마세요. Opus 5는 잘못된 지침을 만났을 때 더 가혹하기 때문에, 이 작업은 진단적입니다. 오작동하는 규칙들을 수정하고, 문자 그대로의 독자가 오해할 수 없도록 나머지를 작성한 다음, 반복합니다.

보이는 것을 고치기 (Fix what you are seeing)

다음 항목들은 각각 여러분이 주의 깊게 살펴볼 수 있는 실패 사례이며, 그 옆에 해결책이 제시되어 있습니다: