첫 확인은 보통 탐색 범위를 줄여야 한다. 그런데 실제 incident에서는 첫 확인을 하고도 여전히 시야가 복잡한 경우가 많다. AI는 여러 원인 후보를 그대로 살려두고, 새로 얻은 증거도 모두와 어중간하게 맞는 것처럼 보여서 다음 단계가 더 좁은 판단이 아니라 또 한 번의 가지 검토로 변한다.

이 글은 AI가 제안한 검증 순서 중 무엇을 먼저 확인할지 고르는 법 다음 단계다. 첫 컷은 이미 했다. 이제 해야 할 일은 그 결과를 이용해 약한 가설을 빨리 버리고, 실제로 조사 범위를 좁히는 것이다.

1. 후보를 실제로 지우지 않으면 필드는 줄어들지 않는다

많은 개발자는 첫 확인을 단지 신호 하나 더 수집하는 과정처럼 다룬다. 그러면 후보 목록이 너무 오래 그대로 남는다. 어떤 가지가 첫 확인 결과와 충돌하거나, 설명력이 약해지거나, 다음 확인을 더 시끄럽게 만든다면 그 가지는 더 이상 같은 무게로 남아 있으면 안 된다.

실제 문제는 AI가 가설을 너무 많이 주는 데 있지 않다. 문제는 팀이 그 가설을 지우는 데 주저한다는 데 있다. 이미 같은 수준의 관심을 받을 자격이 없는 후보도 테이블 위에 남겨두는 순간 계속 주의를 소비한다.

2. 충돌, 유지 비용, 잡음으로 버릴 가설을 정한다

첫 확인 뒤에는 “아직 가능하냐”만 물으면 안 된다. “이 후보가 아직 active set에 남아 있을 자격이 있느냐”를 물어야 한다. 기준은 세 가지면 충분하다.

확인 결과와 직접 충돌하는가

그 가지가 전제로 삼았던 신호가 첫 확인에서 보이지 않았다면, 우선순위는 크게 떨어져야 한다. 완전히 불가능해질 때까지 기다릴 필요는 없다.

살려둘 비용이 큰가

어떤 가설은 살려두기만 해도 비싸다. 대시보드를 더 열게 하고, 같은 timestamp를 반복 비교하게 하고, 탐색 트리를 넓게 유지하게 만든다. 이미 근거가 약한데 그 비용까지 크다면 낭비다.

다음 확인을 더 흐리게 만드는가

약한 가지 하나가 다음 확인의 해석을 흐리게 만들 때가 많다. 한 가설을 살려두는 것만으로 다음 판단이 더 모호해진다면 더 일찍 잘라내는 편이 낫다.

3. 남은 후보는 네 칸으로 다시 정리한다

첫 확인 결과가 나오면, 남은 후보를 네 칸으로 다시 적어보면 된다.

• 이미 반증된 후보: 첫 결과가 이 가지의 전제를 직접 깨뜨린 경우
• 설명력은 있지만 증거가 약한 후보: 이론상 맞을 수는 있지만 지금 단계에서 active attention을 줄 근거가 약한 경우
• 나중에 보류하면 되는 후보: 죽지는 않았지만 더 좁은 다음 확인 뒤에 다시 보면 되는 경우
• 잡음 후보: 지금 살려두면 다음 확인을 느리게 하거나 흐리게 만드는 경우

이 분류의 장점은 살아남은 가설을 전부 동등한 생존자로 다루지 않게 만든다는 데 있다. 대부분의 후보는 “계속 같은 비중으로 본다”가 아니라 “한 단계 내린다”가 맞다.

4. 약한 가설 제거와 강한 가설 제거는 결과가 다르다

예를 들어 AI가 5xx 증가 원인을 네 가지로 제안했다고 하자. upstream latency, retry burst, timeout config regression, 그리고 로컬 worker queue 가지다. 첫 확인은 deploy 시점과 auth failure, retry fan-out의 시간 관계를 비교하는 것이다.

약한 정리는 “네 가지 다 아직 가능하니 일단 다 살려두자”로 끝난다. 안전해 보일 수 있지만, 실제로는 조사 범위가 하나도 줄지 않았다.

더 강한 정리는 “queue 가지는 이번 시간 관계를 설명하지 못하고 다음 확인에 로컬 잡음만 추가하니 active set에서 뺀다. retry 가지는 보류. timeout regression과 upstream latency만 active로 남긴다”라고 말한다. 첫 확인이 더 좁은 조사로 이어지려면 이렇게 돼야 한다.

약한 가설 제거	강한 가설 제거
죽지 않은 후보를 전부 같은 무게로 살려둔다	약한 가지를 active set 밖으로 밀어낸다
가능성만 있으면 계속 본다	다음 확인에 가치가 있는지만 본다
다음 확인이 계속 시끄럽다	다음 확인이 더 좁고 읽기 쉬워진다

5. 가설 제거용 프롬프트 하나를 계속 쓴다

첫 확인 뒤에는 아래 프롬프트 하나만 반복해도 된다.

첫 번째 검증 확인을 실행했고 이런 결과가 나왔다. 지금 active set에서 빠져야 할 가설이 무엇인지 골라줘. 확인 결과와의 직접 충돌, 계속 들고 갈 비용, 다음 확인을 얼마나 흐리게 만드는지를 기준으로 설명하고, active로 남길 것과 보류할 것, 지금 버릴 것을 나눠줘.

답이 계속 흐리면 한 줄을 더 붙이면 된다.

이론적으로 아직 가능하다는 이유만으로 active 상태를 유지하지 말고, 다음 검증 선택에 실제 도움이 되는 경우만 active로 남겨줘.

지금 당장 할 일

지금 디버깅 중인 incident 하나를 골라 첫 확인 결과를 한 문장으로 적어라. 그다음 남은 가설을 네 칸 중 하나로 강제로 넣어라. 두 가지가 여전히 비슷해 보인다면, 어느 쪽이 다음 확인을 더 시끄럽게 만드는지 먼저 보라. 보통 그 가지가 먼저 내려가야 할 후보다.