Karpathy의 CLAUDE.md 규칙 4가지로 Claude의 오류율을 41%에서 11%로 낮추다. 30개의 코드베이스를 분석한 후 8가지를 더 추가했습니다

2026년 1월 말, Andrej Karpathy가 Claude가 코드를 작성하는 방식에 대해 불만을 토로하는 스레드를 올렸습니다. 세 가지 실패 유형: 조용한 잘못된 가정, 과도한 복잡화, 건드리지 말아야 할 코드에 대한 직교적 손상.

Forrest Chang이 그 스레드를 읽고, 불만 사항을 단일 CLAUDE.md 파일에 4가지 행동 규칙으로 정리해 GitHub에 올렸습니다. 첫날 5,828개의 스타를 받았습니다. 2주 만에 60,000개의 북마크. 오늘날 120,000개의 스타. 2026년 가장 빠르게 성장한 단일 파일 저장소입니다.

그런 다음 6주 동안 30개의 코드베이스에서 테스트했습니다.

4가지 규칙은 효과가 있었습니다. 예전에 약 40%의 확률로 발생하던 실수가, 해당 규칙의 강점이 발휘되는 작업에서는 3% 미만으로 떨어졌습니다. 하지만 이 템플릿은 1월의 코드 작성 실수를 수정하기 위해 만들어졌습니다.

2026년 5월의 Claude Code 생태계는 다른 문제를 가지고 있습니다 — 에이전트 간 충돌, 훅 연쇄, 스킬 로딩 충돌, 세션을 넘나드는 다단계 워크플로우.

그래서 8가지 규칙을 더 추가했습니다. 아래: 전체 12가지 규칙의 CLAUDE.md, 각 규칙이 자리 잡은 이유, 그리고 원래 Karpathy 템플릿이 조용히 깨지는 4가지 지점.

설명을 건너뛰고 바로 붙여넣고 싶다면, 전체 파일은 마지막에 있습니다.

이것이 중요한 이유

Claude Code의 CLAUDE.md는 전체 AI 코딩 스택에서 가장 과소평가된 파일입니다. 대부분의 개발자는 다음 중 하나를 합니다:

• 자신이 가진 모든 선호도를 덤프하는 용도로 사용, 4,000개 이상의 토큰으로 부풀려져 규정 준수율이 30%로 떨어짐
• 완전히 건너뛰고 매번 프롬프트 — 5배의 토큰 낭비, 세션 간 일관성 없음
• 템플릿을 한 번 복사하고 잊어버림. 2주 동안은 효과적이지만, 코드베이스가 변경되면 조용히 깨짐

공식 Anthropic 문서는 명확합니다: CLAUDE.md는 권고 사항입니다. Claude는 약 80%의 시간 동안 이를 따릅니다. 200줄을 넘으면 중요한 규칙이 노이즈에 묻혀 규정 준수율이 급격히 떨어집니다.

Karpathy의 템플릿은 이 문제를 하나의 파일, 65줄, 4가지 규칙으로 해결했습니다. 이것이 최소 기준입니다.

더 높은 천장이 있습니다. 아래에서 설명할 8가지 규칙을 더 추가하면, Karpathy가 불평했던 2026년 1월의 코드 작성 문제뿐만 아니라 템플릿이 작성될 당시에는 존재하지 않았던 2026년 5월의 에이전트 오케스트레이션 문제까지 다룰 수 있습니다.

원래의 4가지 규칙

Forrest Chang의 저장소를 읽지 않았다면, 최소 기준은 다음과 같습니다:

**규칙 1 — 코딩 전에 생각하세요.

**조용한 가정은 하지 마세요. 가정하는 바를 명시하세요. 트레이드오프를 표면화하세요. 추측하기 전에 물어보세요. 더 간단한 접근 방식이 있을 때는 반대 의견을 제시하세요.

**규칙 2 — 단순함 우선.

**문제를 해결하는 최소한의 코드. 추측성 기능은 없음. 단일 사용 코드에 대한 추상화 없음. 시니어 엔지니어가 과도하게 복잡하다고 말할 것 같으면 — 단순화하세요.

**규칙 3 — 수술적 변경.

**꼭 필요한 것만 건드리세요. 인접한 코드, 주석 또는 서식을 "개선"하지 마세요. 고장나지 않은 것을 리팩터링하지 마세요. 기존 스타일을 따르세요.

**규칙 4 — 목표 기반 실행.

**성공 기준을 정의하세요. 확인될 때까지 반복하세요. Claude에게 따라야 할 단계를 알려주지 말고, 성공이 어떻게 생겼는지 알려주고 반복하게 하세요.

이 네 가지는 감독되지 않은 Claude Code 세션에서 제가 보는 실패 모드의 약 40%를 해결합니다. 나머지 약 60%는 아래의 간격에 있습니다.

제가 추가한 8가지 규칙 (그리고 그 이유)

각 규칙은 Karpathy의 4가지 규칙만으로는 부족했던 실제 상황에서 비롯되었습니다. 그 상황과 규칙을 보여드리겠습니다.

규칙 5 — 모델이 비언어적 작업을 수행하도록 하지 마세요

Karpathy의 규칙은 이에 대해 침묵합니다. 모델은 결정적 코드여야 하는 것들(API 호출 재시도 여부, 메시지 라우팅 방법, 에스컬레이션 시점)을 결정합니다. 매주 다른 결정. 토큰당 $0.003에 불안정한 if-else.

1## 규칙 5 — 판단 호출에만 모델을 사용하세요
2Claude를 사용할 경우: 분류, 초안 작성, 요약, 비정형 텍스트 추출.
3Claude를 사용하지 마세요: 라우팅, 재시도, 상태 코드 처리, 결정적 변환.
4상태 코드가 이미 질문에 답하고 있다면, 일반 코드가 질문에 답합니다.

그 상황: "503에서 재시도할지 결정"하기 위해 Claude를 호출하는 코드가 2주 동안 아름답게 작동하다가, 모델이 결정의 맥락으로 요청 본문을 읽기 시작하면서 불안정해졌습니다. 프롬프트가 무작위였기 때문에 재시도 정책도 무작위였습니다.

규칙 6 — 엄격한 토큰 예산, 예외 없음

예산이 없는 CLAUDE.md는 백지 수표입니다. 모든 루프는 50,000토큰 컨텍스트 덤프로 이어질 가능성이 있습니다. 모델은 스스로 멈추지 않습니다.

1## 규칙 6 — 토큰 예산은 권고 사항이 아닙니다
2작업당 예산: 4,000토큰.
3세션당 예산: 30,000토큰.
4작업이 예산에 가까워지면 요약하고 새로 시작하세요. 밀어붙이지 마세요.
5초과를 표면화하는 것이 조용히 초과하는 것보다 낫습니다.

그 상황: 디버깅 세션이 90분 동안 진행되었습니다. 모델은 동일한 8KB 오류 메시지를 반복하며, 이미 시도한 수정 사항을 점차 잊어버리면서 완벽하게 만족하고 있었습니다. 결국 40개의 메시지 전에 제가 거절했던 수정 사항을 제안하기 시작했습니다. 토큰 예산이 있었다면 12분에 종료되었을 것입니다.

규칙 7 — 충돌을 표면화하고, 평균화하지 마세요

코드베이스의 두 부분이 일치하지 않을 때, Claude는 둘 다 만족시키려고 합니다. 결과는 일관성이 없습니다.

1## 규칙 7 — 충돌을 표면화하고, 평균화하지 마세요
2코드베이스의 두 기존 패턴이 모순된다면, 혼합하지 마세요.
3하나를 선택하고(더 최신/더 많이 테스트된 것), 이유를 설명하고, 다른 하나를 정리 대상으로 표시하세요.
4두 규칙을 모두 만족시키는 "평균" 코드는 최악의 코드입니다.

그 상황: 코드베이스에 두 가지 오류 처리 패턴이 있었습니다 — 하나는 명시적 try/catch가 있는 async/await, 다른 하나는 전역 오류 경계입니다. Claude가 둘 다 수행하는 새 코드를 작성했습니다. 오류 처리기가 두 배가 되었습니다. 오류가 두 번 삼켜지는 이유를 파악하는 데 30분이 걸렸습니다.

규칙 8 — 쓰기 전에 읽으세요

Karpathy의 "수술적 변경"은 Claude에게 인접 코드를 건드리지 말라고 말합니다. 인접 코드를 이해하라고 말하지는 않습니다. 이것 없이 Claude는 30줄 떨어진 기존 코드와 충돌하는 새 코드를 작성합니다.

1## 규칙 8 — 쓰기 전에 읽으세요
2파일에 코드를 추가하기 전에, 파일의 내보내기, 직접 호출자, 그리고 명백한 공유 유틸리티를 읽으세요.
3기존 코드가 왜 그렇게 구조화되어 있는지 이해하지 못한다면, 추가하기 전에 물어보세요.
4"직교하는 것 같다"는 이 코드베이스에서 가장 위험한 표현입니다.

그 상황: Claude가 읽지 않은 기존의 동일한 함수 옆에 함수를 추가했습니다. 두 함수 모두 동일한 작업을 수행했습니다. 새 함수가 임포트 순서 때문에 우선권을 가졌습니다. 기존 함수는 6개월 동안 진리의 원천이었습니다.

규칙 9 — 테스트는 선택 사항이 아니지만, 목표도 아닙니다

Karpathy의 목표 기반 실행은 테스트를 성공 기준으로 암시합니다. 실제로 Claude는 "테스트 통과"를 유일한 목표로 취급하고, 얕은 테스트를 통과하면서 다른 모든 것을 망가뜨리는 코드를 작성합니다.

1## 규칙 9 — 테스트는 행동뿐만 아니라 의도를 검증합니다
2모든 테스트는 행동이 왜 중요한지(WHAT)뿐만 아니라 그 이유(WHY)를 인코딩해야 합니다.
3`expect(getUserName()).toBe('John')`과 같은 테스트는 함수가 하드코딩된 ID를 사용한다면 무가치합니다.
4비즈니스 로직이 변경될 때 실패할 테스트를 작성할 수 없다면, 함수가 잘못된 것입니다.

그 상황: Claude가 인증 함수에 대해 12개의 테스트를 작성했습니다. 모두 통과했습니다. 인증은 프로덕션에서 고장 났습니다. 테스트는 함수가 무언가를 반환하는지 테스트했을 뿐, 올바른 것을 반환하는지는 테스트하지 않았습니다. 함수가 상수를 반환했기 때문에 통과했습니다.

규칙 10 — 장기 실행 작업에는 체크포인트가 필요합니다

Karpathy의 템플릿은 일회성 상호작용을 가정합니다. 실제 Claude Code 작업은 다단계입니다 — 20개 파일에 걸친 리팩터링, 세션을 통한 기능 구축, 여러 커밋에 걸친 디버깅. 체크포인트 없이 한 번 잘못된 방향으로 가면 모든 진행 상황을 잃습니다.

1## 규칙 10 — 중요한 단계마다 체크포인트를 만드세요
2다단계 작업의 각 단계를 완료한 후: 수행된 작업, 확인된 사항, 남은 작업을 요약하세요.
3나에게 다시 설명할 수 없는 상태에서 계속 진행하지 마세요.
4추적을 잃으면 멈추고 다시 설명하세요.

그 상황: 6단계 리팩터링이 4단계에서 잘못되었습니다. 제가 알아차렸을 때는 Claude가 이미 잘못된 상태 위에 5단계와 6단계도 수행한 후였습니다. 엉킨 것을 푸는 데는 전체를 다시 하는 것보다 더 오래 걸렸습니다. 체크포인트가 있었다면 4단계에서 잡았을 것입니다.

규칙 11 — 관습이 참신함보다 낫습니다

확립된 패턴이 있는 코드베이스에서 Claude는 자신의 패턴을 도입하는 것을 좋아합니다. 자신의 방식이 "더 나은" 경우에도, 두 패턴의 도입은 어느 한 패턴만 있는 것보다 나쁩니다.

1## 규칙 11 — 동의하지 않더라도 코드베이스의 관습을 따르세요
2코드베이스가 snake_case를 사용하고 당신이 camelCase를 선호한다면: snake_case를 사용하세요.
3코드베이스가 클래스 기반 컴포넌트를 사용하고 당신이 훅을 선호한다면: 클래스 기반을 사용하세요.
4의견 차이는 별도의 대화입니다. 코드베이스 내에서는 적합성이 취향보다 우선합니다.
5관습이 정말 해롭다고 생각한다면, 표면화하세요. 조용히 포크하지 마세요.

그 상황: Claude가 클래스 컴포넌트 코드베이스에 React 훅을 도입했습니다. 작동은 했습니다. 그러나 componentDidMount를 가정하는 코드베이스의 테스트 패턴을 깨뜨렸습니다. 제거하고 다시 작성하는 데 반나절이 걸렸습니다.

규칙 12 — 조용히 실패하지 말고, 눈에 띄게 실패하세요

가장 비용이 많이 드는 Claude 실패는 성공처럼 보이는 실패입니다. 함수가 "작동"하지만 잘못된 데이터를 반환합니다. 마이그레이션이 "완료"되지만 30개의 레코드를 건너뜁니다. 테스트가 "통과"하지만 어설션이 잘못되었기 때문입니다.

1## 규칙 12 — 크게 실패하세요
2무언가가 제대로 작동했는지 확실하지 않다면, 명시적으로 말하세요.
330개의 레코드가 조용히 건너뛰어졌다면 "마이그레이션 완료"는 잘못된 것입니다.
4테스트를 건너뛰었다면 "테스트 통과"는 잘못된 것입니다.
5제가 물어본 엣지 케이스를 확인하지 않았다면 "기능 작동"은 잘못된 것입니다.
6기본값은 불확실성을 표면화하는 것이지, 숨기는 것이 아닙니다.

그 상황: Claude가 데이터베이스 마이그레이션이 "성공적으로 완료"되었다고 말했습니다. 제약 조건 위반에 걸린 레코드의 14%를 조용히 건너뛰었습니다. 건너뛰기는 기록되었지만 표면화되지 않았습니다. 11일 후 보고서가 이상해 보이기 시작하면서 문제를 발견했습니다.

수치

6주 동안 30개의 코드베이스에서 동일한 50개의 대표 작업 세트를 추적했습니다. 세 가지 구성:

실수율 = 의도와 일치시키기 위해 수정 또는 재작성이 필요한 작업. 포함: 조용한 잘못된 가정, 과도한 엔지니어링, 직교적 손상, 조용한 실패, 관습 위반, 충돌 평균화, 체크포인트 누락.

준수율 = Claude가 관련 규칙이 적용 가능할 때 눈에 띄게 적용한 빈도.

흥미로운 결과는 41%에서 3%로의 큰 하락이 아닙니다. 4가지 규칙에서 12가지 규칙으로 가면서 준수율 오버헤드가 거의 추가되지 않았지만(78% -> 76%), 실수율이 8% 포인트 더 감소했다는 점입니다. 새로운 규칙은 원래 4가지 규칙이 다루지 않은 실패 모드를 다룹니다 — 동일한 주의 예산을 두고 경쟁하지 않습니다.

Karpathy 템플릿이 조용히 깨지는 지점

새로운 규칙을 추가하기 전에도 원래 4가지 규칙 템플릿만으로는 충분하지 않은 네 가지 지점:

**1. 장기 실행 에이전트 작업.

*Karpathy의 규칙은 Claude가 코드를 작성하는 순간을 대상으로 합니다. Claude가 다단계 파이프라인을 실행*할 때 발생하는 상황에 대해서는 침묵합니다. 예산 규칙 없음. 체크포인트 규칙 없음. "크게 실패" 규칙 없음. 파이프라인이 표류합니다.

**2. 다중 코드베이스 일관성.

**"기존 스타일 일치"는 하나의 스타일을 가정합니다. 12개의 서비스가 있는 모노레포에서 Claude는 어떤 스타일을 선택해야 합니다. 원래 규칙은 방법을 알려주지 않습니다. 무작위로 선택하거나 평균화합니다.

**3. 테스트 품질.

*목표 기반 실행은 "테스트 통과"를 성공으로 취급합니다. 테스트가 의미* 있어야 한다고 말하지 않습니다. 결과는 아무것도 테스트하지 않지만 Claude를 확신하게 만드는 테스트입니다.

**4. 프로덕션 대 프로토타입.

**프로덕션 코드를 과도한 엔지니어링으로부터 보호하는 동일한 4가지 규칙은 방향을 찾기 위해 합법적으로 100줄의 추측성 스캐폴딩이 필요한 프로토타입도 느리게 만듭니다. Karpathy의 "단순함 우선"은 초기 단계 코드에 과도하게 적용됩니다.

추가된 8가지 규칙은 Karpathy의 4가지 규칙을 대체하지 않습니다. 2026년 1월의 자동 완성 스타일 코딩 모델이 2026년 5월의 에이전트 기반, 다단계, 다중 코드베이스 작업과 일치하지 않는 간격을 메웁니다.

효과가 없었던 것

12가지 규칙을 확정하기 전에 시도한 것들:

• Reddit / X에서 본 규칙 추가. 대부분은 Karpathy의 4가지 규칙을 다른 말로 반복하거나 일반화되지 않는 도메인별 규칙("항상 Tailwind 클래스 사용")이었습니다. 제거했습니다.
• 12개 이상의 규칙. 최대 18개까지 테스트했습니다. 14개 규칙을 넘어서자 준수율이 76%에서 52%로 떨어졌습니다. 200줄 제한은 현실입니다. 이를 넘으면 Claude가 실제로 읽지 않고 "규칙이 존재한다"는 패턴 매칭을 시작합니다.
• 존재하지 않을 수도 있는 도구에 의존하는 규칙. "항상 eslint 사용"은 eslint가 설치되지 않았을 때 깨집니다. 규칙이 조용히 실패합니다. 기능에 구애받지 않는 표현으로 대체: "eslint 사용" 대신 "코드베이스의 시행된 스타일 일치".
• CLAUDE.md의 규칙 대신 예제. 예제는 규칙보다 무겁습니다. 세 가지 예제는 약 10개의 규칙만큼의 컨텍스트를 소비하며 Claude가 과적합됩니다. 규칙은 추상적이고 예제는 구체적입니다. 규칙을 사용하세요.
• "조심해" / "열심히 생각해" / "정말 집중해." 순수한 노이즈. 테스트할 수 없기 때문에 이러한 규칙의 준수율은 약 30%로 떨어졌습니다. 구체적인 명령("가정을 명시적으로 진술")으로 대체했습니다.
• Claude에게 "시니어"라고 말하기. 효과 없음. Claude는 이미 자신이 시니어라고 생각합니다. 준수 격차는 생각과 행동 사이에 있습니다. 명령형 규칙이 격차를 좁힙니다. 정체성 프롬프트는 그렇지 않습니다.

전체 12가지 규칙 CLAUDE.md (복사하여 붙여넣기 준비)

1# CLAUDE.md — 12가지 규칙 템플릿
2
3이 규칙은 명시적으로 재정의되지 않는 한 이 프로젝트의 모든 작업에 적용됩니다.
4편향: 중요하지 않은 작업에서는 속도보다 주의. 사소한 작업은 판단을 사용하세요.
5
6## 규칙 1 — 코딩 전에 생각하세요
7가정을 명시적으로 진술하세요. 확실하지 않으면 추측보다 물어보세요.
8모호함이 있을 때 여러 해석을 제시하세요.
9더 간단한 접근 방식이 있을 때 반대 의견을 제시하세요.
10혼란스러우면 멈추세요. 명확하지 않은 것을 이름을 붙이세요.
11
12## 규칙 2 — 단순함 우선
13문제를 해결하는 최소한의 코드. 추측성은 없음.
14요청된 것 이상의 기능 없음. 단일 사용 코드에 대한 추상화 없음.
15테스트: 시니어 엔지니어가 이것이 과도하게 복잡하다고 말할까요? 그렇다면 단순화하세요.
16
17## 규칙 3 — 수술적 변경
18꼭 필요한 것만 건드리세요. 자신의 엉망만 정리하세요.
19인접한 코드, 주석 또는 서식을 "개선"하지 마세요.
20고장나지 않은 것을 리팩터링하지 마세요. 기존 스타일을 따르세요.
21
22## 규칙 4 — 목표 기반 실행
23성공 기준을 정의하세요. 확인될 때까지 반복하세요.
24단계를 따르지 마세요. 성공을 정의하고 반복하세요.
25강력한 성공 기준은 독립적으로 반복할 수 있게 합니다.
26
27## 규칙 5 — 판단 호출에만 모델을 사용하세요
28나를 사용할 경우: 분류, 초안 작성, 요약, 추출.
29나를 사용하지 마세요: 라우팅, 재시도, 결정적 변환.
30코드가 답할 수 있다면, 코드가 답합니다.
31
32## 규칙 6 — 토큰 예산은 권고 사항이 아닙니다
33작업당: 4,000토큰. 세션당: 30,000토큰.
34예산에 가까워지면 요약하고 새로 시작하세요.
35초과를 표면화하세요. 조용히 초과하지 마세요.
36
37## 규칙 7 — 충돌을 표면화하고, 평균화하지 마세요
38두 패턴이 모순된다면, 하나를 선택하세요(더 최신/더 많이 테스트된 것).
39이유를 설명하세요. 다른 하나를 정리 대상으로 표시하세요.
40충돌하는 패턴을 혼합하지 마세요.
41
42## 규칙 8 — 쓰기 전에 읽으세요
43코드를 추가하기 전에, 내보내기, 직접 호출자, 공유 유틸리티를 읽으세요.
44"직교하는 것 같다"는 위험합니다. 코드가 왜 그렇게 구조화되었는지 확실하지 않으면 물어보세요.
45
46## 규칙 9 — 테스트는 행동뿐만 아니라 의도를 검증합니다
47테스트는 행동이 왜 중요한지(WHY)뿐만 아니라 무엇을 하는지(WHAT)를 인코딩해야 합니다.
48비즈니스 로직이 변경될 때 실패할 수 없는 테스트는 잘못된 것입니다.
49
50## 규칙 10 — 중요한 단계마다 체크포인트를 만드세요
51수행된 작업, 확인된 사항, 남은 작업을 요약하세요.
52나에게 다시 설명할 수 없는 상태에서 계속 진행하지 마세요.
53추적을 잃으면 멈추고 다시 설명하세요.
54
55## 규칙 11 — 동의하지 않더라도 코드베이스의 관습을 따르세요
56코드베이스 내에서는 적합성이 취향보다 우선합니다.
57관습이 정말 해롭다고 생각한다면, 표면화하세요. 조용히 포크하지 마세요.
58
59## 규칙 12 — 크게 실패하세요
60무언가가 조용히 건너뛰어졌다면 "완료"는 잘못된 것입니다.
61테스트가 건너뛰어졌다면 "테스트 통과"는 잘못된 것입니다.
62기본값은 불확실성을 표면화하는 것이지, 숨기는 것이 아닙니다.

저장소 루트에 CLAUDE.md로 저장하세요. 12가지 규칙 아래에 프로젝트별 규칙(스택, 테스트 명령, 오류 패턴)을 추가하세요. 총 200줄을 넘지 마세요. 그 이상이면 준수율이 떨어집니다.

설치 방법

두 단계:

1# 1. Karpathy의 4가지 규칙 기준을 CLAUDE.md에 추가하세요
2curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md
3
4# 2. 이 기사의 규칙 5-12를 아래에 붙여넣으세요

저장소 루트에 저장하세요. >>가 중요합니다. 이미 있는 프로젝트별 규칙을 덮어쓰지 않고 기존 CLAUDE.md에 추가합니다.

멘탈 모델

CLAUDE.md는 위시리스트가 아닙니다. 관찰한 특정 실패 모드를 해결하는 행동 계약입니다.

모든 규칙은 다음 질문에 답해야 합니다: 이 규칙은 어떤 실수를 방지하는가?

Karpathy의 4가지 규칙은 그가 2026년 1월에 본 실패 모드를 방지합니다: 조용한 가정, 과도한 엔지니어링, 직교적 손상, 약한 성공 기준. 이는 기본입니다. 건너뛰지 마세요.

제가 추가한 8가지 규칙은 2026년 5월에 등장한 실패 모드를 방지합니다: 예산 없는 에이전트 루프, 체크포인트 없는 다단계 작업, 테스트하지 않는 테스트, 조용한 실패를 숨기는 조용한 성공. 이는 추가적입니다.

상황에 따라 다를 수 있습니다. 다단계 파이프라인을 실행하지 않는다면 규칙 10은 중요하지 않습니다. 코드베이스에 linting으로 시행되는 일관된 스타일이 하나 있다면 규칙 11은 중복됩니다. 12가지를 읽고, 실제로 만든 실수에 해당하는 것만 유지하고 나머지는 버리세요.

실제 실패 모드에 맞게 조정된 6가지 규칙의 CLAUDE.md가 절대 필요하지 않은 6가지 규칙이 포함된 12가지 규칙의 것보다 낫습니다.

T H E _ E N D

Karpathy의 2026년 1월 스레드는 불만이었습니다. Forrest Chang이 그것을 4가지 규칙으로 바꾸었습니다. 120,000명의 개발자가 결과에 별표를 표시했습니다. 대부분은 오늘날에도 여전히 4가지 규칙을 실행하고 있습니다.

모델은 개선되었습니다. 생태계는 변했습니다. 다단계 에이전트, 훅 연쇄, 스킬 로딩, 다중 코드베이스 작업 — Karpathy가 스레드를 작성했을 때는 이 중 어느 것도 존재하지 않았습니다. 4가지 규칙은 이를 다루지 않습니다. 틀린 것은 아닙니다. 불완전한 것입니다.

8가지 규칙 더 추가. 30개의 코드베이스에 걸친 6주 테스트. 실수율 41%에서 3%로.

이것을 북마크하고 오늘 밤 CLAUDE.md에 12가지 규칙을 붙여넣으세요. Claude의 잘못된 방향 전환으로 일주일을 절약했다면 다시 게시하세요.

매일 Claude 최적화 팁을 위한 텔레그램:

*https://t.me/+_ZWrQN7GuDA3ZDEy*