CLAUDE.md의 79개 규칙을 Boris Cherny의 '6개월마다 삭제' 조언에 따라 분류해 봄. 삭제 후보는 22%뿐이었음

월요일 YC 스타트업 스쿨에서 Claude Code를 만든 Boris Cherny가 Claude Code를 쓰면서 에이전트 제품은 안 만드는 사람들한테 이렇게 말했어. "6개월마다 CLAUDE.md랑 스킬, 훅을 싹 다 지워버려." 그러고 나서 모델이 어떻게 반응하는지 보라는 거지. Opus 5한테는 더 세게 밀어붙였어. 그냥 전부 다 지워보라고. 구형 모델들한테 필요했던 지시사항들이 최신 모델한테는 필요 없을 수도 있으니까.

다들 '지우라'는 말만 인용하더라고. 근데 그가 앞서 말했던 나머지 절반은 아무도 언급 안 해. 다 지운 다음에, 모델이 실제로 헤매는 걸 눈으로 확인했을 때만 지시사항을 하나씩 다시 추가하라는 거야. 이 두 번째 문장이 이 방법론의 핵심이야. 이거 안 하면 실험이 아니라 그냥 메모장 버리는 짓밖에 안 돼.

이 조언은 훌륭하지만, 대부분은 잘못 적용할 게 뻔해. 왜 그런지 알려줄게.

Anthropic한테는 왜 먹혔을까

Claude Code는 시스템 프롬프트의 80% 이상을 날려버리고도 Opus 5를 출시했는데, 성능 저하는 없었어. Cherny의 설명은 간단해. 프롬프트 상당수가 모델이 원래 잘했어야 하는데 못 해서 땜질해둔 것들이었거든.

이게 핵심이야. 시스템 프롬프트는 거의 전부 한 가지 종류거든. 바로 모델 행동 교정용 패치지. 그러니까 모델이 똑똑해지면 그 내용 대부분은 순식간에 짐덩어리가 되는 거야. 80%를 쳐내는 건 당연한 결과지.

근데 네 CLAUDE.md는 보통 그런 게 아닐걸?

CLAUDE.md에 들어가는 세 가지

내 글로벌 CLAUDE.md에 있는 규칙 79개를 싹 다 분류해 봤어. 세션마다 로드되는 토큰만 9.5k 정도 되거든. 분류 기준은 이거야.

만약 존나 똑똑한 모델이 내 레포를 읽는다면, 이걸 스스로 알아낼 수 있을까?

• 모델 패치 — 응, 알아내겠지. "응답에 패딩 넣지 마." "설명 좀 그만해." "주장하기 전에 확인부터 해." 이런 건 모델이 모자라서 땜질하는 거라, 모델이 업그레이드되면 유통기한 끝나는 거야. 79개 중 17개.
• 환경 정보 — 아니, 모델이 이걸 관찰할 순 없으니까. 내 셸은 zsh인데, ${PIPESTATUS[0]}가 비어 있어서 빌드 성공(0)을 실패로 보고하거든. 내 레포 중 하나는 iCloud 동기화가 걸려 있어서, 테스트 한 번 돌리는 데 1초가 아니라 4분씩 걸렸어. 모델이 아무리 업그레이드돼도 이런 건 절대 못 찾아내. 79개 중 37개.
• 취향과 결정 — 아니, 이건 정답이 없으니까. 영어로 대답해라, 큰 리팩토링 하기 전에 물어봐라 같은 거. 더 똑똑한 모델이 더 나은 추측을 할 순 있겠지만, 결국 추측인 건 똑같아. 79개 중 25개.

결국 내 파일의 22% 정도만 저 조언이 타겟팅하는 영역이야. 만약 내가 파일 전체를 다 지워버리면 Cherny의 실험을 하는 게 아니라, 내 작업 환경 문서랑 내 취향까지 다 날려버리고 iCloud 문제 같은 걸 다시 몸으로 때우면서 배워야 하는 거지.

분류하는 건 결국 자기 판단이고, 규칙들이 섞여 있는 경우도 많아. 내 규칙 중 하나는 자격 증명 경로(환경 정보)인데, 거기에 "에러 메시지에 비밀 키가 찍히지 않게 해라(패치)"라는 규칙이 붙어 있었거든. 이렇게 섞여 있으면 쪼개야 해. 그것만 해도 파일이 훨씬 짧아지더라.

아무도 말 안 하는 함정

"일단 지우고 무슨 일 일어나나 봐라"는 테스트는 사실 실패하기가 더 힘들어.

만약 어떤 규칙이 배포, 마이그레이션, 릴리스처럼 드문 상황에서만 작동하는데, 다음 주 내내 그런 일을 안 했다면? 그냥 "별일 없네"라고 생각하게 되지. 그건 규칙이 쓸모없다는 증거가 아니라, 그냥 그 규칙을 발동시킬 상황이 없었다는 증거야. 그러다 4개월 뒤에 뒤통수 맞고, 애초에 그런 규칙이 있었는지조차 까먹게 되는 거지.