AI가 로그를 줄여준 뒤에도 오후가 그대로 날아가는 경우가 많다. 반복 라인은 묶였고, 후보 원인도 두세 개로 줄었는데, 막상 무엇부터 확인해야 할지 순서가 없기 때문이다. 그 상태에서는 로그를 덜 읽게 됐을 뿐, 여전히 랜덤하게 움직이게 된다.

이 지점은 AI로 로그를 읽을 때 어디까지 믿고 어디부터 검증할지 정하는 법 바로 다음 단계다. AI는 읽는 시간을 줄여줄 수는 있어도, 검증 순서를 대신 고르지는 못한다. 그 순서를 정하려면 별도의 운영 기준이 필요하다.

1. 가장 흥미로운 이론부터 보는 게 보통 첫 실수다

AI가 원인 후보를 보기 좋게 정리해주면 많은 개발자가 가장 설명이 길고 그럴듯한 가설부터 잡는다. 대개 그게 첫 실수다. 제일 흥미로운 이론이 제일 빨리 죽일 수 있는 이론도 아니고, 제일 넓은 피해를 설명하는 이론도 아니고, 제일 싸게 확인할 수 있는 이론도 아닌 경우가 많다.

이 실수는 겉으로는 생산적으로 보인다. 대시보드를 더 열고, 한 서브시스템을 깊게 파고, 이야기 구조를 만들기 시작하기 때문이다. 하지만 서비스 경계에서 한 번만 보면 바로 접힐 가지를 30분 동안 붙잡고 있을 수도 있다.

겉으로 보이는 문제는 “AI가 후보를 너무 많이 줬다”처럼 보인다. 실제 문제는 다르다. 후보 수가 아니라 순서가 없다. 순서가 없으면 후보가 세 개뿐이어도 여전히 랜덤하게 움직이게 된다.

2. 검증 순서는 파급도, 확인 비용, 반증력으로 정한다

여기가 이 글의 핵심이다. 실전에서 쓸 만한 검증 순서는 보통 세 질문으로 정리된다. 이 후보가 맞다면 얼마나 넓게 번지는가, 직접 확인하는 비용은 얼마나 작은가, 확인했을 때 이 가설을 빨리 죽이거나 살릴 수 있는가.

파급도: 실패가 넓게 번지는 후보를 먼저 본다

하나의 후보가 여러 서비스 경계를 가로지르거나 많은 요청 경로를 동시에 설명할 수 있다면, 우선순위가 올라간다. 여기서 중요한 건 “제일 그럴듯한가”가 아니라 “맞다면 제일 넓은 피해를 설명하는가”다.

확인 비용: 싸고 빠른 직접 확인을 먼저 둔다

비슷하게 그럴듯한 후보 둘이 있어도, 하나는 metric 하나와 timestamp 비교로 확인되고 다른 하나는 replay나 코드 추적으로 내려가야 할 수 있다. 더 싸고 더 빠르게 직접 확인되는 쪽이 먼저다.

반증력: 빨리 죽일 수 있는 확인을 고른다

여기서 시간이 가장 많이 새어난다. 약한 확인은 해석만 더 만든다. 강한 확인은 가설을 깨끗하게 죽인다. 다음 단계가 “봐도 여전히 여러 해석이 가능하다”에 머무르면 그 확인은 약한 편이다.

이 기준은 AI로 디버깅 가설을 더 빨리 좁히는 법과도 바로 이어진다. 가장 그럴듯한 이야기보다, 탐색 공간을 가장 빨리 무너뜨리는 가지부터 보는 쪽이 맞다.

3. 무엇부터 볼지 정할 때는 네 칸으로 나눈다

반복해서 쓰기 좋은 프레임이 필요하면 후보를 먼저 네 칸으로 나눠보면 된다.

• 서비스 경계: 요청이나 이벤트가 다른 시스템으로 넘어가는 지점
• 시간 순서: 무엇이 먼저 바뀌었고 무엇이 나중에 드러났는지
• 최근 변경: 배포, 설정 변경, 플래그 변경, 의존성 변화가 incident 근처에 있었는지
• 직접 측정값: metric, queue age, 상태 코드 분포, latency spike처럼 후보를 빨리 죽일 수 있는 값

이 네 칸이 좋은 이유는 순서를 이론에서 끌어내는 게 아니라 확인 방식에서 끌어내기 때문이다. “어느 설명이 더 멋진가” 대신 “어느 칸이 제일 싸고 결정적인 컷을 주는가”를 묻게 만든다.

예를 들어 502가 배포 직후 반복되기 시작했다면, 깊은 애플리케이션 내부 설명보다 최근 변경과 시간 순서가 먼저다. reset 라인이 upstream latency 급증과 동시에 나타났다면, 로컬 worker 추정보다 서비스 경계 확인이 먼저일 수 있다.

4. 약한 검증 순서와 강한 검증 순서는 확실히 다르다

예를 들어 AI가 로그를 이렇게 정리했다고 하자. cache miss가 늘고, upstream latency가 튀고, retry fan-out이 보이고, worker queue age도 함께 커졌다.

약한 순서는 이렇다. worker 코드부터 본다, retry 구현 세부를 본다, 그다음 cache miss가 진짜 의미가 있는지 본다. 기술적으로 보여도 시작이 비싸고 너무 로컬하다.

더 강한 순서는 다르다. 먼저 upstream latency와 retry fan-out의 시간 관계를 본다. 그다음 cache miss가 spike 전후 어느 쪽에서 먼저 커졌는지 본다. 그 다음에 queue age를 봐서 worker backlog가 중심 문제인지, 단지 하류 증상인지 확인한다.

약한 순서	강한 순서
가장 디테일한 이론부터 들어간다	가장 넓고 가장 싼 결정적 확인부터 본다
로컬 내부를 너무 빨리 연다	시간 순서와 경계부터 본다
해석을 더 만든다	가지를 더 빨리 죽인다

다른 예시도 비슷하다. database timeout 라인이 반복된다고 해서 바로 connection pool 내부부터 보면 안 될 수 있다. 같은 시간대에 배포, 트래픽 급증, credential refresh 실패가 같이 보인다면, 첫 확인은 구현 세부보다 시간 상관과 파급도 쪽이 먼저다.

5. 검증 순서 프롬프트는 하나만 있어도 충분하다

복잡한 incident workflow가 없어도 시작은 가능하다. 아래 정도면 대부분 충분하다.

이 로그와 원인 후보를 읽고, 다음 검증 순서를 파급도, 확인 비용, 반증력 기준으로 정해줘. 각 후보마다 무엇을 먼저 보고, 어떤 증거가 그 이론을 빨리 죽이는지, 무엇은 나중에 봐도 되는지 나눠줘.

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

깊은 구현 추정보다 서비스 경계, 시간 순서, 최근 변경, 직접 측정값을 우선해서 순서를 정해줘.

무엇부터 시작할까

지금 보고 있는 로그 묶음 하나에서 다음 확인 세 가지만 순서대로 적어보자. 첫 번째 확인이 싸지도 않고 반증력도 약하다면, 실제로 보기 전에 순서부터 다시 고치는 편이 맞다.