디버깅에서 진짜 비싼 비용은 타이핑이 아니다. 가설 공간이 넓은 상태로 너무 오래 헤매는 것이다. 원인 후보가 다섯 개, 여섯 개씩 떠다니기 시작하면 팀은 디버깅을 하는 게 아니라 시스템을 아무 데나 찔러보기 시작한다.

AI는 이 지점에서 가설 공간을 줄이는 도구로 쓸 때 가장 실용적이다. 반대로 증거보다 더 강한 확신으로 “원인은 이거다”라고 말하게 두면 바로 위험해진다.

실전 목표는 “버그를 바로 해결하는 것”보다 작아야 한다. 하나의 흐린 증상에서 출발해 검증 가능한 원인 후보 몇 개로 좁히는 것이 먼저다.

1. 좋아하는 이론이 아니라 증상에서 시작한다

디버깅 시간이 새는 가장 흔한 이유는 원인을 너무 빨리 확정하는 것이다. stack trace, timeout, 잘못된 payload, stale UI state는 먼저 증상으로 다뤄야 한다.

시작 프롬프트는 좁을수록 낫다.

여기 정확한 증상, 최근 변경, 관측된 환경이 있다. 그럴듯한 원인 후보를 3개에서 5개만 적어줘. 증거가 충분하지 않으면 확신도 순위는 매기지 말아줘.

이렇게 해야 AI가 처음부터 한 가지 이야기로 뛰어들지 않고, 가설 모드에 머문다.

2. 정답 하나보다 원인 묶음을 먼저 받는다

버그가 아직 흐릴 때는 결론보다 분류가 먼저다. 보통 아래 같은 묶음으로 나누면 된다.

• 입력값 또는 데이터 shape 불일치
• 상태 전이 또는 순서 문제
• 환경 또는 설정 드리프트
• 네트워크, timeout, async 경계 문제
• 최근 리팩터링의 부작용

이 한 단계만으로 디버깅 자세가 바뀐다. “뭐가 망가졌지?”가 아니라 “이건 어느 종류의 실패에 더 가까운가?”로 바뀌기 때문이다.

3. 각 가설에 검증 단계 하나를 붙인다

검증 단계가 없는 가설은 말만 길어진 추측이다. 약한 아이디어를 빨리 치우는 가장 좋은 방법은 각 후보마다 실제 확인 단계 하나를 강제로 붙이는 것이다.

예를 들면 이런 식이다.

• 가설: cache invalidation이 stale 상태다
• 검증: 캐시를 우회한 뒤 응답 헤더를 비교한다
• 가설: client와 server가 payload shape를 다르게 본다
• 검증: 양쪽 경계에서 serialize된 payload를 로깅한다

원인 후보가 실제 검증 단계 하나로 연결되지 않으면, 아직 유지할 가치가 없는 가설인 경우가 많다.

4. AI는 원인을 늘리는 데보다 지우는 데 더 유용하다

생성은 절반짜리 가치다. 더 좋은 사용법은 제거다. 한두 번 확인한 뒤에는 어떤 가설을 버려야 하는지 다시 물어보는 편이 낫다.

이 두 관측 결과를 기준으로 보면, 앞서 나온 가설 중 무엇을 이제 제외할 수 있는가? 증거와 여전히 맞는 가설만 남겨줘.

이렇게 해야 루프가 짧아진다. 확인 한 번 할 때마다 후보 집합이 실제로 줄어들어야 한다.

5. 디버깅 메모 틀을 고정한다

디버깅이 잘 되는 팀은 상태를 눈에 보이게 남긴다. 작은 메모 틀 하나면 충분하다.

1. 증상
2. 최근 변경
3. 현재 환경
4. 상위 3개 가설
5. 각 가설의 다음 검증 단계
6. 제외된 원인

메모 구조가 이렇게 고정되면 AI도 더 쓸모 있어진다. 상상으로 문맥을 메울 공간이 줄어들기 때문이다.

무엇부터 시작할까

지금 잡고 있는 버그 하나를 골라 증상을 한 문장으로 적고, AI에게 원인 후보 세 개와 각 후보의 검증 단계 하나만 요청해봐라. 그 뒤에도 후보 집합이 줄지 않으면 프롬프트가 너무 넓었던 것이다.