근본 원인 대 증상

디버깅에서 가장 솔깃한 함정은 원인을 고치지 않고 에러를 사라지게 만드는 패치다. user가 undefined인데 if (user) { ... }로 그것을 "고치면" 에러는 멈춘다 — 하지만 이제 회원가입이 조용히 아무것도 안 하게 되어 더 나쁘다. 요란한 충돌은 적어도 뭔가 잘못됐다고 말해줬는데, 이제는 아무것도 말해주지 않는다. 진짜 질문은 *왜 여기서 user가 undefined인가?*이다. 데이터베이스 조회가 실패했을 수도 있다. 필드 이름이 바뀌었을 수도 있다. 상류에서 await가 빠졌을 수도 있다.

AI가 수정을 제안하면, 이렇게 물어라:

• "이게 원인을 고치는 거야, 아니면 증상을 가리는 거야?"
• "그 값이 잘못된 원래 이유가 뭐였어?"
• "이 같은 근본 원인이 다른 무언가도 깨뜨릴 수 있어?"

근본 원인을 고치면 보통 코드가 더 단순해지거나 더 명확해진다. 증상 패치는 보통 가드 하나, 에러를 삼키는 try/catch, 또는 진짜 문제를 덮어버리는 기본값을 추가한다. 두 번째 종류를 의심하라. 배워둘 만한 신호가 있다. 어떤 수정이 올바른 일을 하는 대신 충돌을 막는 것이 유일한 임무인 코드를 더한다면, 당신은 아마 증상을 패치하고 있는 것이다. 진짜 수정은 불가능한 상태를 단지 견디는 게 아니라 아예 제거하는 경향이 있다.