LLM 관측성(Observability) 구축법: 환각률보다 중요한 건 실패를 재현하는 능력

LLM 서비스를 운영하면 가장 답답한 순간이 있습니다. "가끔 이상한 답이 나온다"는 제보는 계속 오는데, 재현이 안 됩니다. 이 상태에서는 개선도, 책임도, 우선순위도 모두 흐려집니다. 그래서 필요한 게 관측성입니다. 핵심은 대시보드 예쁘게 만드는 게 아니라 "실패를 다시 만들고 고칠 수 있는 구조"를 만드는 것입니다.

독자 문제: 왜 품질 이슈가 반복되는가

많은 팀이 아래 데이터만 봅니다.

• 총 요청 수
• 평균 응답 시간
• 에러율

이 지표만으로는 LLM 품질 이슈를 못 잡습니다. 왜냐하면 품질 문제는 보통 "정상 응답(HTTP 200)" 안에서 발생하기 때문입니다.

원인: LLM 품질 이슈가 숨는 5개 지점

1) 입력 버전이 기록되지 않는다

같은 질문처럼 보여도 프롬프트 템플릿 버전, 검색 컨텍스트, 도구 응답이 다르면 결과가 달라집니다.

2) 평가 기준이 없다

좋은 답/나쁜 답의 기준이 팀마다 다르면 개선 우선순위를 정할 수 없습니다.

3) 사람이 발견한 오류가 데이터로 환류되지 않는다

CS/운영팀이 발견한 사례가 평가셋으로 들어가지 않으면 같은 문제가 반복됩니다.

4) 온라인/오프라인 평가가 분리된다

오프라인 벤치마크가 좋아도 실제 트래픽에서 깨지는 경우가 많습니다.

5) 원인 분해가 안 된다

문제가 검색인지, 프롬프트인지, 모델인지, 후처리인지 분해가 안 되면 수정이 랜덤해집니다.

해결: 관측성 스택을 최소 구성으로 시작하는 법

1) Trace 단위 표준화

요청마다 아래를 반드시 기록합니다.

• 요청 ID
• 프롬프트 템플릿 버전
• 모델/파라미터
• 검색 후보와 점수
• 도구 호출 로그
• 최종 응답
• 사용자 피드백

이 7개만 모아도 재현 가능성이 크게 올라갑니다.

2) 평가셋 3계층 운영

• Golden set: 항상 통과해야 하는 핵심 질의
• Regression set: 과거 장애 사례
• Fresh set: 최근 7일 신규 이슈

배포 전에는 Golden/Regression, 배포 후에는 Fresh를 중심으로 모니터링합니다.

3) 자동 평가 + 사람 평가 결합

자동 평가는 속도가 빠르지만 맥락을 놓칠 수 있습니다. 사람 평가는 정확하지만 느립니다. 둘을 분리하지 말고 결합합니다.

• 자동: 근거 포함 여부, 금지 표현, 포맷 준수
• 사람: 정확성, 유용성, 업무 적합성

4) 원인 분해 대시보드

"품질 점수 하락"만 보면 액션이 안 나옵니다. 아래 축으로 분해합니다.

1. Retrieval 문제
2. Reasoning 문제
3. Tool-use 문제
4. Policy 문제

각 축의 실패율을 따로 보면 어디부터 고칠지 명확해집니다.

실무 예시: 고객지원 보조봇

고객지원 보조봇에서 "정책 잘못 안내" 이슈가 반복되던 사례를 가정해봅시다.

개선 전:

• 응답은 빠름
• 정확도 제보 다수
• 원인 불명

개선 후:

1. 정책 문서 버전과 검색 스니펫을 trace에 저장
2. 정책 관련 질의를 regression set으로 분리
3. 정책 답변은 근거 링크 없으면 자동 실패 처리
4. 주 2회 사람 평가 샘플링

이렇게 바꾸면 "왜 틀렸는지"가 보이고, 수정 후 재발 여부도 확인할 수 있습니다.

지표 설계: 꼭 봐야 할 8개

1. Task success rate
2. 근거 일치율
3. 재질문율
4. 정책 위반률
5. 도구 호출 실패율
6. 응답 지연 P95
7. 배포 후 회귀 실패 건수
8. 사용자 부정 피드백 비율

특히 2, 4, 7번은 "운영 신뢰"와 직접 연결됩니다.

2주 구축 플랜

1주차

• Trace 스키마 확정
• 핵심 질의 50개 Golden set 구성
• 회귀 사례 30개 Regression set 구성

2주차

• 배포 파이프라인에 자동 평가 연결
• 대시보드 8개 지표 연결
• 실패 상위 10건 원인 분해 회의 운영

실행 체크리스트

• 요청 단위 trace 필드를 표준화했다
• Golden/Regression/Fresh 평가셋을 분리했다
• 자동 평가와 사람 평가를 함께 운영한다
• 근거 없는 응답을 실패로 처리한다
• 배포 전후 평가 루프를 파이프라인에 넣었다
• 원인 분해 대시보드를 운영한다
• CS 이슈를 매주 회귀셋에 반영한다
• 월 1회 지표 재정의 회의를 한다

LLM 관측성의 목표는 "지표를 많이 보는 것"이 아닙니다. "실패를 재현하고, 원인을 분해하고, 같은 실패를 줄이는 것"입니다. 오늘 바로 trace 스키마부터 고정하면, 다음 배포부터는 감으로 대응하던 품질 이슈를 데이터로 다룰 수 있습니다.