AI 실패 분석 — 로그·트레이스·스크린샷으로 근본 원인 후보를 내는 분석 에이전트

개념

규칙 기반 분류 다음 단계 — "어느 범주인가"에서 "왜인가"로

모듈 59 레슨 7에서 실패 트리아지 규칙을 배웠다. 실패 메시지·재시도 결과·환경 신호를 보고 제품 결함·환경 문제·테스트 결함 세 범주로 나누는 규칙이다. 규칙 기반 분류는 빠르고 설명 가능하지만, 답할 수 있는 질문이 하나뿐이다. "이 실패를 누구에게 보낼까."

현장에서 진짜 시간을 잡아먹는 건 그다음 질문이다. 왜 실패했는가. 규칙이 "제품 결함 의심"으로 보낸 25건을 받은 QA 엔지니어는 하나씩 트레이스를 열고, 서버 로그를 grep 하고, 어제 머지된 커밋을 훑는다. 한 건에 10분이면 네 시간이다.

AI 실패 분석 에이전트는 이 구간을 맡는다. 한 건의 실패(또는 비슷한 실패 묶음)를 놓고 증거를 모으고, 근본 원인 후보 를 근거와 함께 낸다. 여기서 핵심 단어는 "후보"다. 에이전트가 원인을 확정하는 것이 아니라, 사람이 확인할 가설을 우선순위와 함께 제시하는 것이다.

두 단계는 경쟁 관계가 아니다. 싸고 결정적인 규칙을 앞에 두고, 규칙이 확신하지 못한 것만 분석 에이전트에 넘기는 구조가 가장 흔하다.

입력 수집 — 분석의 품질은 증거 묶음의 품질이다

실패 메시지 한 줄만 주면 그럴듯한 추측이 돌아온다. 분석 품질은 모델보다 어떤 증거를 묶어 주느냐 에서 먼저 갈린다.

가장 효과가 큰 것은 테스트와 서버를 잇는 연결 고리 다. 테스트 요청에 trace id(W3C Trace Context 의 traceparent 헤더)가 실려 있으면 실패한 요청에서 백엔드의 어느 서비스에서 오류가 났는지 바로 따라간다. 없으면 "실패 시각 전후 30초 로그"를 읽다가 같은 시간에 돌던 다른 테스트의 오류를 원인으로 착각한다.

Playwright의 Copy prompt 기능(HTML 리포트·UI 모드·Trace Viewer)은 오류·스택·테스트 코드·페이지 스냅샷을 묶어 준다. 증거 묶음의 가장 작은 형태다. 서버 로그·최근 커밋·실패 이력은 빠져 있으니, 그 빈칸을 플랫폼이 채워 주는 것이 조직 단위 분석 에이전트다.

# 분석 요청 한 건의 증거 묶음 예 (에이전트 입력 계약)
failure_id: run-20261004-0213/checkout.spec.ts:88
test:
  name: "쿠폰 적용 후 결제 금액이 갱신된다"
  error: "expect(locator).toHaveText('18,000원') — received '20,000원'"
  retries: 2회 모두 실패
evidence:
  trace_excerpt: 실패 직전 네트워크 요청 12건 (POST /api/coupons/apply → 200)
  server_logs: trace_id=4bf92f... 로 조회한 3개 서비스 로그 41줄
  recent_changes:
    - commit a1c9e2 "쿠폰 금액 계산 캐시 도입" (pricing-service, 어제 18:40 배포)
    - config: coupon.cache.ttl=300s (신규)
  history: 최근 30회 중 첫 실패, 같은 시각 다른 결제 테스트 3건 동시 실패

원인 후보와 근거 인용 — 출력 계약을 먼저 정한다

분석 에이전트의 출력은 자유 서술이 아니라 정해진 칸 을 가져야 한다. 모듈 38에서 LLM 판정자에게 근거 인용을 요구했듯, 분석 에이전트도 후보마다 근거를 증거 묶음의 특정 위치로 인용하게 한다. 인용할 수 없는 주장은 후보로 내지 못하게 한다.

{
  "failure_id": "run-20261004-0213/checkout.spec.ts:88",
  "symptom": "쿠폰 적용 응답은 200인데 결제 요약 금액이 할인 전 값으로 남음",
  "hypotheses": [
    {
      "rank": 1,
      "category": "제품 결함",
      "statement": "pricing-service 금액 캐시가 쿠폰 적용 이벤트로 무효화되지 않음",
      "evidence": [
        "server_logs L17: 'price cache HIT key=cart:8812' (쿠폰 적용 0.4초 후)",
        "recent_changes: commit a1c9e2 캐시 도입, 어제 배포",
        "history: 같은 시각 결제 금액 관련 테스트 3건 동시 실패"
      ],
      "counter_evidence": ["쿠폰 적용 API 응답 본문의 discount 값은 2,000원으로 정상"],
      "confidence": "중",
      "how_to_confirm": "캐시 비활성 플래그로 동일 시나리오 재실행, 또는 L17 직후 캐시 키 TTL 조회"
    }
    // 2순위 후보(테스트 결함: 대기 조건 부족, 신뢰도 낮음) 생략
  ],
  "missing_evidence": ["프런트엔드 콘솔 로그가 수집되지 않음"],
  "recommendation": "사람 확인 필요 — 1순위 가설 확인 절차 수행 후 결함 등록"
}

이 계약에서 특히 중요한 칸이 세 개 있다.

• 반대 증거(counter_evidence) — 가설에 불리한 증거를 스스로 적게 한다. LLM은 처음 떠올린 가설에 매달리는 경향이 있는데, 반대 증거 칸을 강제하면 그 경향이 줄고 사람이 검토할 때도 판단이 빨라진다.
• 확인 방법(how_to_confirm) — 가설을 사람이 몇 분 안에 확인할 수 있는 구체적 행동으로 바꾼다. "로그를 더 보라"는 확인 방법이 아니다.
• 빠진 증거(missing_evidence) — 무엇이 없어서 확신하지 못하는지 말하게 한다. 이 칸이 쌓이면 수집 파이프라인의 빈칸이 보인다.

LLM이 근본 원인 분석에서 틀리는 방식

2026년 워털루대 연구진이 클라우드 장애 근본 원인 분석(RCA) 과제에서 여섯 개 LLM의 추론 과정을 4만 8천 건의 모의 장애로 평가했다. 가설 정확도는 모델과 워크플로에 따라 0.01에서 0.36 수준에 머물렀고, 연구진은 추론 실패를 16개 범주로 정리했다. QA 실패 분석에 그대로 옮겨 올 만한 실패 유형은 다음과 같다.

같은 연구에서 트레이스를 빼자 오히려 정확도가 오른 경우도 있었다. 증거는 많이가 아니라 관련 있게 줘야 한다. trace id·시간창·서비스로 좁히고 중복 줄을 접는 전처리가 모델 교체보다 효과가 큰 경우가 많다. "AI가 원인을 자동으로 찾아 준다"는 벤더 데모는 대개 원인이 하나이고 증거가 깔끔한 사례다. 도입 전에 우리 조직의 지난 실패로 만든 평가셋 에서 직접 재 본 정답률만 믿는다.

신뢰도와 사람 확인의 경계

LLM이 스스로 매긴 신뢰도는 실제 정답률과 잘 맞지 않는다. 그래서 신뢰도는 증거가 갖춘 조건 으로 정의한다.

여기에 사람 확인이 반드시 필요한 경우를 별도로 정한다. 신뢰도가 높아도 다음은 사람이 본다.

• 원인이 보안·개인정보·결제 금액·법적 고지와 관련된 경우
• 결론이 "테스트 결함이니 테스트를 고치자"인 경우 — 제품 결함을 테스트 탓으로 돌리는 방향의 오분석이 가장 위험하기 때문이다
• 분석 결과에 따라 자동으로 무언가가 바뀌는 경우(테스트 격리, 셀프힐링 적용, 재배포 차단 해제)

마지막 항목은 모듈 18a 레슨 15와 이어진다. "로케이터가 바뀌었을 뿐"이라는 결론으로 셀프힐링이 테스트를 고치면, 버튼이 사라진 제품 결함이 덮인다.

오분석의 비용 — 방향마다 다르다

모듈 59 레슨 7에서 오분류의 비용이 방향마다 다르다고 배웠다. 원인 분석도 마찬가지다.

두 번째 행도 가볍지 않다. 틀린 "제품 결함" 리포트가 몇 번 쌓이면 개발 팀은 AI 분석이 붙은 결함을 뒤로 미루고, 도구의 효과는 사라진다. 그래서 운영 지표에 정분석률 만이 아니라 개발자가 기각한 비율 을 함께 둔다.

분석 결과를 결함 리포트 초안으로

사람이 확인을 마친 가설은 결함 리포트 초안으로 바뀐다. 분석 출력의 칸을 리포트 칸에 옮겨 담는 일이라 자동화하기 좋다.

초안에는 "원인 추정은 AI 분석 결과이며 확인 절차 X로 확인함" 같은 표기를 남겨, 오분석이 밝혀졌을 때 어느 단계에서 틀렸는지 거슬러 올라갈 수 있게 한다.

실무에서 왜 필요한가

AI가 테스트를 생성·실행하는 조직일수록 실패 건수가 늘지만 분석 인력은 늘지 않는다. 결국 실패를 열어 보지 않고 재실행만 누르는 문화가 생기고, 진짜 결함이 플래키라는 이름으로 묻힌다. 분석 에이전트는 이 병목을 줄이는 가장 직접적인 수단이다.

동시에 잘못 쓰면 가장 위험한 AI 도구이기도 하다. 셀프힐링과 결합되면 결함을 덮고, 개발자 신뢰를 깎으면 결함 리포트 전체가 무시된다. 입출력 계약을 정하고, 신뢰도를 증거 조건으로 정의하고, 평가셋으로 정분석률과 기각률을 재는 일은 테스트 설계와 같은 종류의 일이다. 도구를 사는 것이 아니라 분석의 기준을 설계하는 것이 QA의 몫이다.

실습 과제

과제 1 — 지난 실패 10건으로 증거 가용성 표 만들기 (25분)

팀의 최근 회귀 실패 중 원인이 이미 확정된 10건을 고른다. 각 건에 대해 이 레슨의 증거 여섯 가지(오류·스택, 실행 트레이스, DOM·스크린샷, 서버 로그·트레이스, 최근 변경, 실패 이력)가 자동으로 수집되는지, 사람이 찾아야 하는지, 아예 없는지 표로 채운다. 확정 원인을 찾는 데 결정적이었던 증거도 표시한다. 결정적 증거가 자동 수집되지 않는 칸이 분석 에이전트가 넘어야 할 첫 번째 벽이다.

과제 2 — 출력 계약과 신뢰도 기준표 쓰기 (30분)

JSON 예시를 참고해 우리 팀용 출력 계약을 쓰고, 신뢰도 네 단계의 조건을 증거 조건으로만 정의한다("모델이 확신하면"이 들어가면 다시 쓴다). 신뢰도와 무관하게 사람 확인이 필수인 경우도 세 가지 이상 적는다.

과제 3 — LLM으로 원인 후보 받아 보고 채점하기 (35분)

과제 1 중 5건의 증거 묶음(마스킹 필수)과 과제 2의 계약으로 LLM에게 원인 후보를 받아 채점한다.

- 1순위 후보가 확정 원인과 일치하는가 (일치 / 상위 3위 안 / 없음)
- 인용한 근거가 실제 증거 묶음에 존재하는가 (날조 인용 수)
- 반대 증거 칸이 의미 있게 채워졌는가
- 확인 방법이 10분 안에 수행 가능한 구체적 행동인가

날조 인용이 하나라도 나왔다면 어떤 전처리(줄 번호 부여, 인용 대조 스크립트)로 막을지 적는다.

자가 체크리스트

• 규칙 기반 트리아지와 AI 실패 분석이 답하는 질문의 차이를 설명할 수 있다
• 실패 한 건의 증거 여섯 가지와 각 한계, trace id 연결의 의미를 말할 수 있다
• 원인 후보마다 근거·반대 증거·확인 방법을 요구하는 출력 계약을 쓸 수 있다
• LLM이 근본 원인 분석에서 보이는 대표적 실패 유형(증거 날조·앵커링·시간 혼동)과 막는 장치를 말할 수 있다
• 신뢰도를 모델의 자기 확신이 아니라 증거 조건으로 정의할 수 있다
• 오분석 방향별 비용을 비교하고, 가장 위험한 방향을 설명할 수 있다

흔한 실수

실패 메시지 한 줄만 넣고 원인을 묻는다. 증거가 없으면 모델은 가장 흔한 원인을 그럴듯하게 지어낸다.

로그를 통째로 넣는다. 관련 없는 줄이 많을수록 출처 혼동과 앵커링이 늘어난다. trace id·시간창·서비스로 좁히고 중복을 접어서 넣는다.

"테스트 결함" 결론을 자동으로 적용한다. 분석 결과로 테스트를 격리하거나 셀프힐링을 적용하면 제품 결함이 덮인다. 이 방향은 항상 사람이 본다.

정분석률만 잰다. 개발자가 기각한 비율과 날조 인용 수를 함께 보지 않으면, 숫자는 좋은데 아무도 결과를 읽지 않는 상태가 된다.

참고 자료

• Stalled, Biased, and Confused: Uncovering Reasoning Failures in LLMs for Cloud-Based Root Cause Analysis (Riddell 외, arXiv 2601.22208)
• Why Do AI Agents Systematically Fail at Cloud Root Cause Analysis? (arXiv 2602.09937)
• Debugging Playwright Tests with AI — Copy prompt와 Fix with AI (Playwright 팀, DEV Community)
• W3C Trace Context
• 이 커리큘럼 안: 모듈 59 레슨 4 「플래키 추적과 격리」·레슨 7 「실패 트리아지 규칙」, 모듈 18a 레슨 15 「Playwright 셀프힐링 구현」, 모듈 38 레슨 3 「LLM 판정자 보정」, 모듈 30 레슨 6 「버그라고 부르는 것의 정체」