Andrej Karpathy: "Claude 오류의 90%는 모델의 약함이 아니라 컨텍스트(Context) 부족에서 발생한다."

Andrej Karpathy: "Claude의 오류 90%는 모델이 약해서가 아니라 컨텍스트 (Context)가 누락되었기 때문에 발생한다."
수치 데이터가 이를 뒷받침합니다.

CLAUDE.md가 없을 때 오류율 41%. 기본적인 4가지 규칙(4-rule baseline)을 적용했을 때 11%. 아래의 12가지 규칙 버전을 적용했을 때 3%.

시니어 엔지니어들은 다음 사항들을 결정했습니다:

코딩하기 전에 생각하라. 가정을 명시적으로 기술하라. 모델은 당신의 마음을 읽을 수 없다.

단순함을 우선하라. 최소한의 코드, 추측에 기반한 추상화(speculative abstractions) 금지. "미래의 유연성을 위해"라는 명목은 다음 분기에 삭제하게 될 200줄의 코드를 추가하는 방식이다.

정밀한 변경(Surgical changes).

반드시 필요한 부분만 건드려라. Claude가 인접한 코드까지 개선하도록 내버려 두는 것이 PR(Pull Request) 규모를 폭발시키는 원인이다.

목표 중심의 실행. 성공 기준을 사전에 정의하라.

기준이 없으면 Claude는 무한 루프에 빠지거나 너무 일찍 멈춰버린다.

모델은 판단(judgment calls)에만 사용하라. 분류(Classification), 초안 작성(drafting), 요약(summarization), 추출(extraction) 등에 사용하라. 라우팅(routing), 재시도(retries), 상태 코드(status codes), 또는 결정론적 변환(deterministic transforms)에는 사용하지 마라. 코드로 답할 수 있다면, 코드가 답하게 하라.

토큰 예산(Token budgets)은 권장 사항이 아니다. 작업당 4,000개, 세션당 30,000개.

긴 디버깅 과정의 40번째 메시지쯤 되면, Claude는 당신이 5번째 메시지에서 거절했던 수정 사항을 다시 제안하고 있을 것이다.

충돌을 표면화하라, 평균 내지 마라. 코드베이스에 두 가지 패턴이 있다면 하나를 선택하라. 그것들을 혼합하는 것이 오류를 두 번 삼켜버리는 방식이다.

쓰기 전에 읽어라. Export(내보내기), 호출자(callers), 공유 유틸리티(shared utilities). Claude는 자신이 읽지 않은 함수 옆에 중복 함수를 추가할 것이다.

테스트는 단순히 동작(behavior)이 아니라 의도(intent)를 검증해야 한다. 비즈니스 로직이 변경되었을 때 실패할 수 없는 테스트는 잘못된 것이다.

함수가 상수(constant)를 반환하더라도 12개의 테스트가 모두 통과할 수 있다.

모든 중요한 단계마다 체크포인트(Checkpoint)를 설정하라. Claude는 4단계의 깨진 상태에서 5단계와 6단계를 완료했다. 한 시간 동안 아무도 알아차리지 못했다.

코드베이스 컨벤션(conventions)을 준수하라. 클래스 컴포넌트(Class components)를 사용한다면 조용히 훅(hooks)으로 분기하지 마라.

실패할 때는 명확하게 실패하라(Fail loud). 레코드의 14%가 조용히 누락되었음에도 "성공적으로 완료되었습니다"라고 출력하는 것이 최악의 버그 유형이다.

실제로 복리 효과를 내는 것들: 세션 전반에 걸친 기관의 기억으로서의 CLAUDE.md. 느낌(vibe)이 아닌 평가(Eval)에 기반한 변경.

속도보다는 체크포인트. 조용한 혼합보다는 명시적인 충돌 해결. 하나의 리포지토리(repo), 하나의 규칙 파일, 예외 없음.

더 나은 AI가 필요한 것이 아닙니다. 더 나은 컨텍스트 엔지니어링 (Context Engineering)이 필요할 뿐입니다.

전체 플레이북 (Playbook)은 아래와 같습니다.