많은 디버깅 세션이 같은 지점에서 멈춘다. AI가 로그를 요약했고, 후보 원인도 깔끔해졌고, 검증 순서도 그럴듯해 보인다. 그런데 막상 첫 번째로 무엇을 확인할지 정하려 하면 다시 흐려진다. 약한 가지에 30분을 써버릴지, 탐색 공간을 바로 줄일 첫 확인을 고를지가 여기서 갈린다.

이 글은 그 더 좁은 지점을 다룬다. 이제 문제는 “검증 순서가 뭐지?”가 아니다. “첫 확인 하나가 탐색 공간을 가장 빨리 줄이는가?”가 핵심이다. 이걸 놓치면 좋아 보이는 검증 순서도 결국 느린 혼란으로 바뀐다.

1. 그럴듯한 순서가 있어도 첫 확인이 틀릴 수 있다

많은 개발자는 AI가 순서를 보기 좋게 정리해주면 어려운 구간이 끝났다고 생각한다. 그렇지 않다. 전체 순서는 대체로 맞아도, 첫 확인 하나가 틀리면 첫 20분이 완전히 달라진다. 그 시간 동안 incident tree를 접을 수도 있고, 너무 이른 로컬 스토리에 깊게 들어갈 수도 있다.

이 글은 AI가 읽어준 로그에서 무엇부터 검증할지 순서를 정하는 법 바로 다음 단계다. 지난 글이 전체 필드를 정리하는 글이었다면, 이번 글은 첫 번째 실제 컷을 고르는 글이다.

겉으로는 “후보 셋 다 그럴듯하다”처럼 보인다. 실제 문제는 다르다. 그럴듯함은 약한 기준이다. 무엇이 첫 확인을 받을 자격이 있는지를 가르는 더 강한 기준이 필요하다.

2. 첫 확인은 반증력, 실행 속도, 탐색 공간 절단으로 고른다

강한 첫 확인은 대체로 세 가지에서 이긴다. 그 확인 하나로 가지를 깔끔하게 죽일 수 있고, 빨리 실행할 수 있고, 결과가 나오면 불확실성을 크게 줄인다.

반증력 먼저

확인 결과를 봐도 같은 가지가 거의 그대로 살아남는다면 그 확인은 약하다. 좋은 첫 확인은 기대한 증거가 없을 때 한 가지 설명을 바로 접게 만든다.

실행 속도 다음

비슷하게 중요한 확인 둘이 있어도, 하나는 metric 하나와 timestamp 비교로 끝나고 다른 하나는 replay나 코드 trace, 여러 대시보드 이동이 필요할 수 있다. 더 빨리 결정적인 답을 주는 쪽이 먼저다.

탐색 공간 절단은 세 번째

첫 확인은 가장 넓은 불확실성을 잘라내야 한다. 그래서 종종 한 로컬 컴포넌트 안으로 바로 들어가기보다, 서비스 경계나 최근 변경, 시간 관계를 먼저 자르는 확인이 더 낫다.

3. 첫 확인을 고를 때는 네 칸으로 나눈다

AI가 다음 확인 후보를 여러 개 줬다면, 아무것도 열기 전에 먼저 네 칸으로 나눠보면 된다.

• 지금 바로 측정 가능한 것: metric, queue age, 상태 코드 분포, 에러율처럼 당장 볼 수 있는 값
• 시스템 경계를 자르는 확인: 문제가 서비스 경계 바깥에서 시작되는지 알려주는 확인
• 최근 변경과 직접 닿는 확인: 가장 최근 deploy, config 변경, 의존성 변화에 직접 연결된 확인
• 틀렸을 때 빨리 버릴 수 있는 가설: 기대한 신호 하나만 없으면 바로 접을 수 있는 가지

이 네 칸이 좋은 이유는 설명의 멋으로 고르는 습관을 막아주기 때문이다. 어느 이론이 더 멋진지가 아니라, 어느 확인이 제일 작은 비용으로 가장 큰 불확실성을 지우는지를 먼저 보게 만든다.

4. 약한 첫 확인과 강한 첫 확인은 바로 느낌이 다르다

예를 들어 AI가 incident를 이렇게 정리했다고 하자. upstream latency가 증가했고, retry fan-out이 보이고, queue age도 올랐고, 최근 config 변경에서 timeout 값도 바뀌었다.

약한 첫 확인은 queue age가 눈에 띈다는 이유로 worker 내부부터 여는 것이다. 나중에는 중요할 수 있지만, 출발이 너무 로컬하고 비싸다.

더 강한 첫 확인은 upstream latency, retry fan-out, timeout config 변경의 시간 관계를 먼저 비교하는 것이다. 시간이 안 맞으면 큰 가지 하나가 바로 죽는다. 시간이 맞으면 그 다음 확인 범위도 훨씬 좁아진다.

약한 첫 확인	강한 첫 확인
가장 눈에 띄는 증상부터 본다	가장 싸고 결정적인 컷부터 본다
로컬 내부를 너무 빨리 연다	시간 관계, 변경, 경계를 먼저 본다
해석만 더 늘어난다	한 가지를 빨리 죽인다

다른 예시도 비슷하다. deploy 직후 5xx가 튀고 AI가 cache, worker, upstream auth failure를 후보로 냈다면, 첫 확인은 종종 auth failure와 deploy timing의 관계다. 시간대가 안 맞으면 큰 가지 하나가 바로 2순위로 밀린다.

5. 첫 확인 선택 프롬프트는 하나만 있어도 된다

이걸 반복하려고 더 큰 workflow가 필요한 건 아니다. 아래 정도면 충분하다.

다음 검증 후보들 중 첫 번째로 실행할 확인 하나를 골라줘. 기준은 세 가지만 본다. 어떤 확인이 가장 반증력이 강한지, 어떤 확인이 가장 빨리 실행되는지, 어떤 확인이 맞거나 틀렸을 때 불확실성을 가장 많이 줄이는지다. 그리고 나머지 확인이 왜 뒤로 가야 하는지도 설명해줘.

로그가 특히 시끄럽다면 한 줄만 더 붙이면 된다.

깊은 구현 추정보다 지금 바로 측정 가능한 신호, 서비스 경계, 최근 변경, 빨리 죽일 수 있는 가지를 먼저 보게 해줘.

무엇부터 시작할까

지금 디버깅 중인 incident 하나에서 다음 확인 세 개만 적어보자. 그리고 첫 번째 확인에 대해 한 문장으로 답해보면 된다. 왜 이 확인이 가장 작은 비용으로 가장 큰 불확실성을 죽이는가. 이 답이 또렷하지 않다면, 아직 첫 확인을 제대로 고른 게 아니다.