막다른 길을 기록하라

긴 디버깅에서 가장 아까운 시간은 새로운 시도가 아닙니다. 이미 누군가(또는 과거의 내가) 해보고 안 됐던 접근을 또 하는 시간입니다. 큰 시스템일수록, 그리고 세션이 길어질수록 이 낭비가 쌓입니다. 해법은 단순합니다 — 막다른 길(dead end)을 기록하는 것.

디버깅 루프에 "확인" 한 단계를 넣는다

새 버그를 만나면 곧장 코드로 뛰어드는 대신, 이미 실패한 접근인지부터 확인합니다.

도식 렌더링 중…

이 루프의 핵심은 두 가지 기록입니다.

• 막다른 길 기록(dead-ends registry) — "이 접근은 이래서 실패했다"를 영구 보존. 다음에 같은 길로 안 가게.
• 현재 디버그 상태(current-debug) — 세션이 끊겨도 "어디까지 했는지"를 이어받게.

2회 실패하면 멈춰라

기록만큼 중요한 게 멈추는 규칙입니다.

⚠️ 같은 가설로 2번 고쳐 실패하면 정지 — 같은 방향으로 세 번째 수정을 하려 들면, 그건 추측의 늪입니다. 2회 실패는 "가설 자체가 틀렸다"는 신호입니다. 멈추고, 기록하고, 다른 각도에서 보거나 도움을 요청하세요. 고집은 디버깅에서 미덕이 아닙니다.

이건 instrument-first와 짝을 이룹니다 — 추측→수정→실패를 반복하는 대신, 한 번 실패하면 데이터를 모으고, 두 번 실패하면 멈춰 기록합니다.

왜 기록이 그렇게 중요한가

💡 기록은 미래의 나(혹은 동료)에게 보내는 편지 — "이 접근은 안 된다"는 한 줄이, 며칠 뒤의 누군가가 같은 늪에 빠지는 걸 막습니다. 특히 시뮬레이션처럼 "안 되는 이유가 미묘한"(물리 타이밍·환경 설정·silent fail) 분야에선, 실패의 이유까지 적어두는 게 성공의 절반입니다.

복잡한 시스템의 지식은 "무엇이 되는가"만큼 "무엇이 안 되는가" 로도 이루어집니다. 막다른 길의 지도가 곧 그 시스템을 아는 것입니다.

한 줄 정리

📌 긴 디버깅의 최대 낭비는 이미 실패한 접근을 다시 하는 것이다. 막다른 길(왜 안 됐는지)과 현재 상태를 명시적으로 기록하고, 버그를 만나면 그 기록부터 확인하라. 같은 가설로 2회 실패하면 멈추고 기록 — 고집이 아니라 기록이 디버깅을 전진시킨다.