로그는 오후 시간을 제일 빨리 태우는 재료 중 하나다. AI에게 붙여 넣자마자 stack trace 하나, timeout 하나, 반복 경고 하나를 집어서 그럴듯한 설명을 해주기 시작하면 더 위험해진다. 빨라진 게 아니라, 검증되지 않은 이야기를 더 빨리 믿게 된 것일 수 있기 때문이다.

로그에서 AI를 잘 쓰는 방법은 원인을 대신 판정하게 두는 것이 아니다. 잡음을 줄이고, 후보를 묶고, 결국 사람이 직접 확인해야 할 지점을 더 빨리 보게 만드는 데 쓰는 것이다.

1. 처음부터 root cause를 말하게 시키지 않는다

가장 흔한 실수는 이거다. 로그를 붙여 넣고 “원인이 뭐야?”부터 묻는다. 그러면 AI는 대체로 하나의 매끈한 이론을 준다. 보기엔 효율적이지만, 실제로 가장 중요한 부분을 건너뛴다. 그 이론이 증거로 지지되는지 아직 확인하지 않았기 때문이다.

로그는 설명문이 아니라 흔적이다. 한 줄의 에러는 원인일 수도 있고, 증상일 수도 있고, 단지 제일 먼저 눈에 띈 결과일 수도 있다. 그런데 AI가 그 한 줄을 중심으로 너무 빨리 하나의 이야기로 묶어버리면, 조사 방향을 잘못 좁히게 된다.

2. 핵심 경계는 단순하다. AI는 압축까지만, 판정은 검증이 한다

여기가 이 글의 핵심이다. AI는 표면적 넓이를 줄이는 데 강하다. 반복되는 에러를 묶고, 어느 시간대에 몰렸는지 요약하고, 함께 자주 등장하는 서비스 이름을 모아주고, 뻔한 잡음과 진짜 신호 후보를 나누는 데는 꽤 유용하다. 원시 로그는 넓고 피곤하기 때문에 이 단계만 잘해도 체감이 크다.

하지만 압축에서 판정으로 넘어가는 순간 위험이 달라진다. “이 세 종류의 에러는 같이 움직이는 것 같다”는 유용한 힌트다. 반면 “이건 분명히 DB pool exhaustion이다”는 이미 직접 확인이 필요한 주장이다.

이 차이가 중요한 이유는 로그가 자주 거짓 중심을 만들기 때문이다. 제일 시끄러운 줄이 제일 중요한 줄이 아닐 때가 많다. 실제 원인은 2초 전에 있었던 설정 드리프트일 수도 있고, 다른 서비스의 retry loop가 간접 피해를 만든 것일 수도 있다.

그래서 실전 기준은 간단하다. AI에게는 내가 봐야 할 범위를 줄이게 하고, 어떤 패턴을 실제 원인으로 승격시키는 순간에는 바로 검증 단계가 따라붙어야 한다. 지금 당장 어떻게 확인할지 말할 수 없으면, 그 주장은 아직 후보일 뿐이다.

예를 들어 AI가 500줄 로그를 “cache miss 뒤에 upstream timeout이 연쇄적으로 터진다” 정도로 줄여주는 건 도움이 된다. 하지만 그 다음 해야 할 일은 그 문장을 믿는 게 아니다. cache hit ratio, upstream latency, retry fan-out이 timeout 전후 어디서 시작했는지 직접 확인해야 한다. 가치를 주는 지점은 답을 대신하는 게 아니라, 검증 경로를 줄이는 데 있다.

3. 로그를 읽을 때는 세 칸만 고정해도 충분하다

반복해서 쓰기 좋은 구조는 세 칸이면 충분하다.

• 증상 요약: 겉으로 무엇이 실패하는가
• 원인 후보: 그 패턴을 설명할 수 있는 가설은 무엇인가
• 직접 확인: 그 가설을 바로 살리거나 죽일 수 있는 검증 한 가지

이 구조가 좋은 이유는 AI를 올바른 자리로 묶어두기 때문이다. 첫 두 칸은 AI가 도와줄 수 있지만, 세 번째 칸이 반드시 증거 쪽으로 다시 손을 돌려놓는다.

AI가 후보만 주고 직접 확인 단계를 못 붙인다면, 그 출력은 아직 덜 된 것이다. 설명을 더 길게 받지 말고 검증 경로를 더 좁게 다시 요구하는 편이 맞다.

4. 예시 하나만 봐도 어디서부터 믿으면 안 되는지 보인다

예를 들어 로그에 504가 반복되고, queue backlog 경고가 보이고, 중간에 connection reset 라인이 섞여 있다고 하자. AI는 빠르게 “queue worker가 root problem 같다”고 제안할 수 있다.

그럴 수는 있다. 하지만 아직은 후보일 뿐이다. 직접 확인은 이렇게 생겨야 한다. 504 급증 전후 worker throughput이 실제로 떨어졌는지, queue age가 같이 늘었는지, reset 라인이 upstream에서 먼저 시작됐는지 worker 경계 안에서 시작됐는지 본다. 이 확인이 안 되면 AI 요약은 유용한 힌트였어도 최종 답은 아니었다.

5. 로그 트리아지 프롬프트는 짧을수록 좋다

복잡한 워크플로는 필요 없다. 아래 정도면 대부분의 로그 해석 시작점으로 충분하다.

이 로그를 읽고 증상 요약, 원인 후보, 각 후보의 직접 확인 단계로 나눠줘. 로그만으로 증명되지 않으면 root cause처럼 단정하지 말아줘.

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

반복 라인은 묶고, obvious duplicate는 줄이고, 다음에 내가 확인해야 할 지점을 바꾸는 부분만 강조해줘.

무엇부터 시작할까

지금 보고 있는 시끄러운 로그 묶음 하나를 골라 AI에게 세 가지만 요청해보자. 증상 요약, 상위 두 개 원인 후보, 각 후보의 직접 확인 한 가지. 그 결과가 바로 다음 검증 행동을 줄여주지 못하면, 아직 질문이 너무 넓었던 것이다.