debug

debug

에러가 나면 고치기 전에 먼저 이해한다. 같은 명령어를 다시 실행하지 않는다. 같은 방법을 두 번 시도하지 않는다.

⛔ Iron Law

근본 원인 진단을 출력으로 남기기 전에는 어떤 수정도 하지 않는다. 머릿속으로 "답했다 치고" 넘어가는 것은 진단이 아니다. 규칙의 문구를 어기는 것은 규칙의 정신을 어기는 것이다.

진단 게이트 (karpathy §1 — 출력 필수)

수정 코드를 작성하기 전, 아래를 채워서 출력한다. 빈 칸이 하나라도 있으면 수정 단계로 진입하지 않는다.

- 에러 전문: (메시지/스택 트레이스 붙여넣기)
- 마지막 동작 시점: (커밋 해시 / 시각)
- 변경점: (git diff 요약)
- 재현 조건: (재현 명령 또는 절차)
- 가설 1~2개: (3개 이상이면 범위가 너무 넓음 → 더 좁힌다)

빈 칸을 추측으로 메우지 않는다 — 모르면 명령을 실행해 확인한 뒤 채운다.

디버깅 루프

[관찰]: 에러 메시지 / 스택 트레이스 전문 확인
    ↓
[가설]: 원인 후보 1~2개 (3개 이상이면 범위가 너무 넓음)
    ↓
[검증]: 가설을 검증하는 최소한의 테스트 또는 로그
    ↓
[수정]: 원인이 확인된 경우에만 코드 수정 (karpathy §3 Surgical)
    ↓
[verify]: 재현 케이스가 통과하는지 확인

실패 분석 원칙

• 같은 접근으로 두 번 실패하면 → 접근 자체를 버린다
• 증상만 고치면 근본 원인이 남는다 → 근본 원인을 찾는다
• 작동하는 것처럼 보이는 것과 실제로 작동하는 것을 구분한다

Red Flags (이 생각이 들면 멈춘다)

떠오른 생각	현실
"일단 이거 바꿔보고 되나 보자"	진단 없는 추측 수정. 게이트를 먼저 채운다.
"에러 메시지는 대충 알겠음"	전문을 붙여넣기 전엔 모르는 것. ⬜.
"아까 그 명령 다시 돌려보자"	같은 명령 재실행은 새 정보가 아니다. 가설을 바꾼다.
"고친 것 같다"	재현 케이스가 통과해야 고친 것. 보이는 것과 구분한다.

재현 테스트 먼저

버그를 고치기 전에 버그를 재현하는 테스트를 먼저 작성한다:

실패하는 테스트 작성 → 테스트 통과하게 수정 → 커밋

이 순서가 뒤집히면 나중에 같은 버그가 다시 나타난다.

디버그 완료 후

원인과 수정 내용이 명확해지면 → execute로 복귀