가설, 로깅, 그리고 이진 탐색

AI가 원인을 제시하면 그냥 받아들이지 마라. 값싸게 시험하라. 가장 값싼 시험은 보통 로그 한 줄이다.

AI에게 임시 로깅을 추가하라고 요청하라:

"무언가 바꾸기 전에, 14번 줄 바로 앞에서 user의 값을 보여주는 console.log(또는 print)를 추가해줘. 그게 실제로 undefined인지 볼 수 있게."

실행하고, 출력을 다시 붙여넣어라. 이제 당신은 이론이 아니라 증거를 가졌다. user가 undefined일 수도 있다 — 가설을 확인하는 것이다. 멀쩡하고 진짜 범인이 한 단계 위에 있을 수도 있다. 어느 쪽이든 당신은 앞으로 나아갔다. 조사하는 동안에는 로그를 넉넉히 찍어라. 변수의 값, 그리고 그게 어느 변수이고 로그가 어디 있는지 알려주는 라벨까지. undefined를 찍는 맨 console.log(user)는 console.log("user at validate.js:14 =", user)보다 훨씬 덜 유용하다. 그리고 버그가 고쳐지면 임시 로그를 다시 빼내는 걸 잊지 마라 — 남겨진 디버그 잡음은 그 자체로 작은 어질러짐이다.

버그가 긴 과정 어딘가에 숨어 있고 어디인지 알 수 없을 때는 이진 탐색을 써라. 의심 구간을 절반으로 잘라라: 중간 지점에 로그를 추가하라.

핵심 아이디어: 각 확인이 남은 것의 절반을 버리므로, 거대한 탐색 공간이 빠르게 줄어든다. 여기 버그가 1단계와 8단계 사이 어딘가에 숨어 있다 — 세 번의 확인으로 그것을 몰아넣는다:

   단계:  1  2  3  4  5  6  7  8      버그가 이 안 어딘가에 있다
          ░░░░░░░░░░░░░░░░░░░░░░

   확인 1 ── 4에 로그 ── OK ──▶  버그는 4 뒤, 1–4 버림
                                  ░░░░░░░░░░░  (5 6 7 8 남음)

   확인 2 ── 6에 로그 ── BAD ─▶  버그는 6 이하, 7–8 버림
                                  ░░░░░  (5 6 남음)

   확인 3 ── 5에 로그 ── OK ──▶  버그는 6단계   ✔ 찾음

   8단계 → 3번 확인.  1000단계 → 약 10번 확인.

거기서 값이 올바르게 보였는가? 그렇다면 버그는 그 뒤에 있다 — 그 절반을 탐색하라. 이미 잘못 보였는가? 버그는 그 앞에 있다 — 그 절반을 탐색하라. 각 단계가 탐색 공간을 반으로 줄이므로, 천 줄짜리 경로라도 약 열 번의 확인으로 좁혀진다. AI에게 명시적으로 말하라: "이걸 이등분하게 도와줘 — 로그를 찍어야 할 중간 지점이 어디야?" 같은 기법은 코드뿐 아니라 이력에도 통한다. 어떤 기능이 지난주에는 동작했는데 오늘 깨졌다면, 커밋을 이등분해서 버그를 들여온 정확한 변경을 찾아라.