나는 나의 CLAUDE.md를 삭제했다. 340줄 전체를, 단 한 번에, 편집도 없이, 어떤 규칙이 여전히 자리를 지킬 가치가 있는지 분류하는 과정도 없이 말이다. 9개의 기술(skills)도 함께 사라졌고, 4개의 훅(hooks)과 6개의 커스텀 명령(custom commands)도 마찬가지였다. 모든 것은 타임스탬프가 찍힌 백업 폴더로 들어갔으며, 실제로 잃어버린 것은 아무것도 없었다. 단지 더 이상 활성화된 것이 없을 뿐이다. 에이전트를 안내할 규칙이 전혀 없는 상태로 6일간 정상적인 업무를 수행했고, 나는 고장 나는 모든 것을 기록했다.

내가 실제로 알고 싶었던 것은 들리는 것보다 단순하면서도 대답하기는 더 어려웠다. 내가 삭제한 모든 것 중에서, 그 6일 동안 실제로 중요했던 것은 무엇인가? 그리고 나는 단순히 더 안전하다고 느껴졌기 때문에, 실제로 도움이 되어서가 아니라 순전히 반사적으로 다시 추가하려 했던 것은 무엇인가? 그 질문은 오후 한때에 답해지지 않았다. 일주일 내내 걸렸고, 그마저도 답의 일부는 미결 상태로 남았다.

나는 무서운 부분이 보안 가드레일(security guardrails)일 것이라고 생각했다. rm -rf를 절대 실행하지 않기, main 브랜치에 직접 푸시하지 않기, .env 파일을 절대 건드리지 않기 등, 한 번 작성해 두고 실제로 스트레스 테스트를 할 일이 없기를 바라는 종류의 경계선들 말이다. 결과적으로 그 두려움은 전혀 현실이 되지 않았다. 340줄의 설정을 한 번에 삭제하는 것은 마치 영구적인 죽음(permadeath) 모드로 게임을 시작하면서, 그사이 보스의 패턴이 바뀌지 않았기를 바라는 것과 같은 기분이었다. 다행히 패턴은 거의 바뀌지 않았다. 나를 정말 놀라게 한 것은 전혀 다른 곳에서 나타났다.

같은 사람, 6개월 후, 완전히 달라진 조언

2026년 1월, Boris Cherny(Claude Code를 만든 사람)는 InfoQ 기사에서 자신의 워크플로우를 설명했다. Anthropic의 모든 팀은 git에 CLAUDE.md를 유지하며, 그는 동료들의 풀 리퀘스트(pull requests)에 Claude를 태그하여 새로운 교훈을 파일에 즉시 추가한다. 그들은 이를 복리 엔지니어링(Compounding engineering)이라고 불렀다. 당시 그의 팀 파일은 약 2,500 토큰 규모였다.

2026년 7월, Y Combinator의 Startup School에서 그는 6개월 전과는 정반대의 조언을 했다. 그는 청중에게 6개월마다 모든 것을 삭제하라고 말했으며, 특히 Opus 5의 경우 정확히 그렇게 할 것을 강력히 권장했다. Anthropic은 Opus 5가 출시될 때 Claude Code의 시스템 프롬프트(system prompt) 중 80% 이상을 제거했다.

제가 이 글을 쓰는 것은 그가 모순된 말을 했다는 것을 잡아내기 위함이 아닙니다. 두 진술 모두 사실이며, 단지 서로 다른 시점에 사실이었을 뿐입니다. 그리고 그것이 바로 핵심입니다. 설정(Config)에는 유통기한이 있습니다. 저는 제 설정을 추적한 적이 없으며, 여러분도 아마 추적하지 않았을 것이라 확신합니다. 저는 지난 2월에 작성했던 구조를 작성했을 당시, 340줄의 코드가 부채가 아닌 절제된 규율처럼 느껴졌던 시절을 지나왔습니다.

관습인가 패치인가: 결코 일어나지 않는 분류

설정 파일의 모든 줄은 두 가지 유형 중 하나에 속하며, 이들은 완전히 다르게 노화됩니다. 어떤 줄들은 **프로젝트 관습 (project conventions)**입니다. 우리는 pnpm을 사용합니다. Clerk가 인증 (auth)을 처리합니다. Supabase는 블롭 스토리지 (blob storage) 용도로만 사용하며, 그 외의 것은 건드리지 않습니다. 이러한 것들은 프로젝트 자체의 형태가 바뀌기 전까지는 만료되지 않습니다. 다른 줄들은 모델이 실수를 저지른 날 작성된 **동작 패치 (behavior patches)**입니다. 테스트를 덮어쓰지 마세요. 변경 사항을 제안하기 전에 Glob을 호출하세요. 이러한 것들은 모델이 정확히 그 실수를 더 이상 하지 않게 되는 순간, 즉 보통 다음 릴리스(release)가 되는 순간 만료됩니다.

두 유형 모두 동일한 마크다운 (markdown) 파일 내에, 동일한 구문으로 존재하며, 날짜 스탬프도, 작성자도, 이유도 붙어 있지 않습니다. 페이지의 그 어떤 것도 무엇이 무엇인지 알려주지 않습니다. 이것이 제가 제 파일을 처음부터 끝까지 다시 읽어본 적이 없는 이유입니다. 분류 메커니즘이 없기 때문에, 남은 유일한 전략은 계속해서 쌓아 올리는 것뿐입니다. 한 독자는 자신의 파일을 두고 '2 버전 전에는 이미 사라진 약점들을 위한 스캐폴딩 (scaffolding)이 여전히 그곳에 남아, 매 호출마다 컨텍스트 (context)를 낭비하고 있다'라고 표현했는데, 제가 하는 말보다 훨씬 더 잘 설명했습니다. 그것이 바로 이 질병의 본질을 한 문장으로 요약한 것입니다.

**Glob 규칙 (Glob rule)**을 예로 들어보겠습니다. 저는 2026년 4월, Opus 4.7이 지시 사항을 이상할 정도로 문자 그대로 따르기 시작한 이후에 이 규칙을 추가했습니다. 그 결과 "프로젝트 구조를 확인하라"는 지시가 "당신은 반드시 Glob을 호출해야 합니다"로 변질되었고, 이는 Opus 4.7을 위해 제가 배포한 정확한 재작성 내용에 담겨 있습니다. 저는 Opus 5에게도 여전히 그런 채찍질이 필요한지 확인하러 돌아간 적이 없습니다. 단 한 번도요, 심지어 그걸 작성한 사람이 저인데도 말이죠. 그 규칙은 그저 매 턴마다 다시 읽히며, 이미 사라졌을지도 모를 버그를 위해 지시 사항 예산 (instruction budget)을 낭비하며 그 자리에 머물러 있었습니다.

당신이 의문을 제기하지 않고 방치한 모든 죽은 패치(dead patch)들도 지금 당신의 파일 안에서 조용히 똑같은 일을 하고 있습니다. 단지 당신이 아직 어떤 줄인지 알아차리지 못했을 뿐입니다.

프로토콜: 무엇을 제거하고, 무엇을 측정할 것인가

직접 실행해보고 싶다면, 다음의 프로토콜을 순서대로 따르십시오.

모든 것을 백업하십시오. 즉시 삭제하는 대신 타임스탬프가 찍힌 폴더에 백업해 두세요. 저장된 상태(save state)가 없고 되돌릴 수 없다면, 그것은 실험이 아니라 공포 영화의 시작이 될 것입니다.

계층별로 제거하십시오. 한꺼번에 다 제거하지 마세요. 특히 운영 코드(production code)의 경우, 기술(skills)과 훅(hooks)을 먼저 제거한 다음, 커스텀 명령(custom commands), 그 다음 CLAUDE.md 자체 순으로 진행하십시오. 보안 가드레일(security guardrails)은 제거의 시작이 아니라 맨 마지막 단계까지 남겨두어야 합니다.

무엇을 측정할지 시작 전에 결정하십시오. 그렇지 않으면 아무것도 측정하지 못하게 됩니다. 저는 세 가지를 추적했습니다: 세션당 수동 수정 횟수, 에이전트가 이미 알고 있어야 할 컨텍스트를 다시 설명해야 했던 빈도, 그리고 심각도가 포함된 실제 발생 사건입니다.

최소 며칠 동안 실행하십시오. 단 한 번의 세션으로는 아무것도 알 수 없습니다. 노이즈를 실제 신호로 오해하게 될 것입니다 (저도 2일 차에 아무것도 고장 나지 않자 자만했다가 하마터면 그럴 뻔했습니다). 여기서 실제 도구는 설정 파일(config file)이 아니라 로그(log)입니다. 로그 말입니다.

3일 차에 조카가 놀러 와서, 우리 둘 다 이유를 설명할 수 없는 이유로 계속 충돌이 발생하는 Scratch 프로젝트를 도와달라고 했습니다. 평소 사용하던 도구 하나 없이 20분 동안 블록 로직을 디버깅했습니다. 스택 트레이스 (stack traces)의 소중함을 깨닫게 되는 순간이죠 😅

이 모든 일의 타이밍이 기본적으로 우연이었다는 점은 인정합니다. 저는 6일간의 절제 테스트 (ablation test)를 계획했던 것이 아니라 평범한 한 주를 계획하고 있었는데, 첫째 날에 너무 많은 것들이 고장 나는 바람에 그냥 계속 진행하며 지켜보기로 결정하면서 이렇게 되어버렸습니다.

무엇이, 어떤 순서로 돌아왔는가

세 가지 유형이 돌아왔지만, 균등하지는 않았습니다.

**보안 가드레일 (security guardrails)**이 가장 먼저, 같은 날에 돌아왔습니다. 논쟁의 여지 없이, 당신이 원하든 원하지 않든 정해진 일정에 따라 리셋되는 NPC처럼 다시 나타났습니다. 여기서 발생하는 위양성 (false negative)의 비용은 영구적이며, 더 깔끔한 파일을 위해 도박을 걸어볼 만한 확률의 문제가 아닙니다.

다음으로는 모델이 코드로부터 추론할 수 없었던 **프로젝트 컨벤션 (Project conventions)**이 돌아왔습니다. 모델이 이것들 없이는 계속해서 잘못된 추측을 했기 때문입니다. Convex 쿼리 (query)는 뮤테이션 (mutation)을 직접 호출할 수 없고 반드시 액션 (action)을 거쳐야 하는데, 코드베이스를 아무리 들여다봐도 그 자체만으로는 알 수 없는 부분입니다.

행동 패치 (Behavior patches), 즉 실제 패치들은 거의 돌아오지 않았습니다. 모델이 더 이상 예전과 같은 실수를 하지 않았기 때문입니다. 340줄 중에서 정리 과정을 거쳐 살아남은 것은 단 11줄뿐이었습니다.

규칙은 버그가 사라진다고 해서 함께 사라지지 않습니다. 누군가가 마침내 그 규칙을 삭제할 때 비로소 사라집니다.

그 결과, 사전에 결정한 것이 아니라 로그에서 추출한 실제 임계값 (threshold)이 생겼습니다. 최소 2번의 동일한 실패가 발생한 후에야 해당 라인은 다시 살아남을 자격을 얻습니다. 제 로그에서 단 한 번 발생한 실패는 결코 반복되지 않았기 때문입니다. 이것은 제 특정 파일에 적용되는 규칙이 아니라, 제가 유지하고 있는 규칙입니다. 여러분의 11줄은 제 것과 전혀 다를 것입니다.

솔직한 주의 사항을 말씀드리자면, 회피하려는 것이 아닙니다. 돌아온 것 중 일부는 필요가 아닌 안도감 때문일 수도 있습니다. 저는 실제 라인 단위의 A/B 테스트를 수행한 적이 없으므로, 그 11줄 중 몇 개는 로그가 실제로 요구해서가 아니라, 그것을 제거하는 것이 유지하는 것보다 더 기분이 나쁘다는 이유만으로 살아남았을 수도 있습니다.

이 임계값은 하나의 모델과 하나의 하네스 (harness) 환경에서 유효합니다. 이것이 다른 곳에서도 유효할지는 완전히 다른 문제이며, 6일간의 실험으로는 답할 수 없는 문제입니다.

11줄, 그리고 여전히 의구심이 드는 것들

제 설정의 대부분은 이미 수정된 모델의 약점들을 보완하기 위한 임시 구조물(scaffolding)이었으며, 저는 아무런 이득 없이 에이전트가 매 턴마다 그것을 다시 읽게 만들고 있었습니다. 결국 11줄만이 살아남았습니다.

제가 모르는 부분은 솔직하게 말씀드리겠습니다. 저는 이 11줄이 실제로 핵심적인 역할을 하는지(load-bearing), 아니면 단순히 안심을 위한 것인지 솔직히 확신할 수 없습니다. 이를 확실히 알려줄 A/B 테스트를 실행해 본 적이 없기 때문입니다. 또한 이 더 가벼워진 파일이 얼마나 오랫동안 깨끗하게 유지될지도 모르며, 여기서 나타나는 그 어떤 것도 성능 저하(decay)가 예측 가능한 일정에 따라 발생한다는 점을 시사하지 않습니다. 그리고 이 모든 것이 Claude를 넘어 다른 모델에도 적용될 수 있는지도 알 수 없습니다. Anthropic은 자체적인 하네스(harness)를 기준으로 모델을 학습시키고 평가하기 때문에, 파일의 형태가 같다고 해서 다른 모델이 읽는 AGENTS.md가 반드시 동일하게 동작한다고 보장할 수 없기 때문입니다.

마지막 내용은 저에게 더 이상 가설이 아닙니다. 저는 올해 Claude Code 외에도 Grok과 Codex에 더 많이 의존해 왔으며, 조용히 Claude 전용이었던 CLAUDE.md에서 CLAUDE.md가 이를 가리키는 심볼릭 링크(symlink)로 작동하는 AGENTS.md 체제로 전환했습니다. 이론적으로는 모델 불가지론적(Model-agnostic) 설정인 셈입니다. 살아남은 11줄이 3개의 서로 다른 모델에게도 똑같은 의미를 갖는지는 제가 아직 검증할 수 없는 부분입니다.

다음 절제 실험(ablation)은 이미 일정에 잡혀 있습니다 📅

출처

• Boris Cherny, "Building Claude Code," Y Combinator Root Access transcript, 2026년 7월 28일
• "Inside the Development Workflow of Claude Code's Creator," InfoQ, 2026년 1월

이 포스트에는 제휴 링크가 포함되어 있을 수 있습니다. 링크를 클릭하시면 저에게 소정의 수수료가 지급될 수 있습니다 (귀하에게 비용이 발생하지 않으며, 제가 매일 양질의 글을 계속 발행하여 여러분의 즐거운 독서를 돕는 데 도움이 됩니다).