디버깅

디버깅이란?

디버깅이 몸에 붙으면 개발 중 던지는 질문 자체가 바뀝니다. '왜 안 되지'라는 막연한 한탄 대신 '어느 단계까지는 되고 어디서부터 안 되는가'로 범위를 좁히게 됩니다. 재현 → 격리 → 가설 → 검증이라는 네 박자가 기본인데, 이 중 가장 먼저 무너지는 것이 재현입니다. 매번 다르게 나타나는 증상은 아직 손댈 단계가 아니라, 조건을 고정하는 일부터 해야 한다는 신호입니다.

오류는 크게 세 갈래입니다. 문법 오류는 실행 자체가 안 되니 차라리 쉽고, 런타임 오류는 특정 입력이나 특정 용량에서만 터지며, 가장 비싼 것은 논리 오류입니다. 에러 하나 없이 잘 돌아가는데 계산 결과만 틀린 경우라, 숫자를 직접 검산하기 전까지는 아무도 모릅니다. 테스트와 QA가 '버그가 있다'를 밝혀내는 일이라면, 디버깅은 원인 지점을 특정해 고치는 일이라는 점에서 역할이 갈립니다.

AI에게 디버깅을 맡길 때 함께 붙여야 할 것은 세 가지입니다. 재현 절차, 에러 메시지 전문, 문제가 난 파일 이름입니다. 특히 에러 메시지는 요약하지 말고 통째로 복사하는 편이 낫습니다. 스택 트레이스의 마지막 한 줄보다 중간에 적힌 파일명과 줄 번호가 결정적 단서인 경우가 많기 때문입니다. 수정은 한 번에 한 가지만 적용해야 무엇이 효과가 있었는지 가려낼 수 있습니다.

현장에서 가장 흔한 사고는 'AI가 알아서 고쳐주겠지'라는 기대입니다. '안 돼요'만 던지면 AI는 짐작으로 코드를 다시 써 주고, 그 과정에서 멀쩡히 돌아가던 기능까지 바뀝니다. 더 위험한 것은 에러를 없애는 것과 문제를 푸는 것을 혼동하는 일입니다. 오류를 잡아 조용히 삼켜 버리는 코드를 넣으면 화면은 깨끗해지지만 데이터는 계속 틀리게 쌓입니다. 손대기 전에 되돌릴 수 있는 지점을 저장해 두지 않으면, 세 번째 수정쯤에서 원래 코드가 어떤 모습이었는지 아무도 기억하지 못합니다.