LLM 서비스를 운영하면 가장 답답한 순간이 있습니다. "가끔 이상한 답이 나온다"는 제보는 계속 오는데, 재현이 안 됩니다. 이 상태에서는 개선도, 책임도, 우선순위도 모두 흐려집니다. 그래서 필요한 게 관측성입니다. 핵심은 대시보드 예쁘게 만드는 게 아니라 "실패를 다시 만들고 고칠 수 있는 구조"를 만드는 것입니다.
많은 팀이 아래 데이터만 봅니다.
이 지표만으로는 LLM 품질 이슈를 못 잡습니다. 왜냐하면 품질 문제는 보통 "정상 응답(HTTP 200)" 안에서 발생하기 때문입니다.
같은 질문처럼 보여도 프롬프트 템플릿 버전, 검색 컨텍스트, 도구 응답이 다르면 결과가 달라집니다.
좋은 답/나쁜 답의 기준이 팀마다 다르면 개선 우선순위를 정할 수 없습니다.
CS/운영팀이 발견한 사례가 평가셋으로 들어가지 않으면 같은 문제가 반복됩니다.
오프라인 벤치마크가 좋아도 실제 트래픽에서 깨지는 경우가 많습니다.
문제가 검색인지, 프롬프트인지, 모델인지, 후처리인지 분해가 안 되면 수정이 랜덤해집니다.
요청마다 아래를 반드시 기록합니다.
이 7개만 모아도 재현 가능성이 크게 올라갑니다.
배포 전에는 Golden/Regression, 배포 후에는 Fresh를 중심으로 모니터링합니다.
자동 평가는 속도가 빠르지만 맥락을 놓칠 수 있습니다. 사람 평가는 정확하지만 느립니다. 둘을 분리하지 말고 결합합니다.
"품질 점수 하락"만 보면 액션이 안 나옵니다. 아래 축으로 분해합니다.
각 축의 실패율을 따로 보면 어디부터 고칠지 명확해집니다.
고객지원 보조봇에서 "정책 잘못 안내" 이슈가 반복되던 사례를 가정해봅시다.
개선 전:
개선 후:
이렇게 바꾸면 "왜 틀렸는지"가 보이고, 수정 후 재발 여부도 확인할 수 있습니다.
특히 2, 4, 7번은 "운영 신뢰"와 직접 연결됩니다.
LLM 관측성의 목표는 "지표를 많이 보는 것"이 아닙니다. "실패를 재현하고, 원인을 분해하고, 같은 실패를 줄이는 것"입니다. 오늘 바로 trace 스키마부터 고정하면, 다음 배포부터는 감으로 대응하던 품질 이슈를 데이터로 다룰 수 있습니다.
