LLM 운영 지표 설계 - 모델을 바꾸기 전에 봐야 할 것들

데모는 잘 되는데 운영이 흔들리는 이유

LLM 기반 제품이 초기에 잘 나와도 시간이 지나면서 품질이 흔들리는 경우가 많습니다.

보통 이런 패턴입니다.

• 처음에 직접 테스트한 케이스는 잘 된다
• 사용자가 늘면서 예상 못한 질문이 들어오기 시작한다
• 응답 품질이 떨어지는데 어디서 왜 그런지 알기 어렵다
• 모델을 교체하거나 프롬프트를 바꿔도 원인이 해결된 건지 모른다

이 문제는 대부분 “운영 지표가 없어서” 발생합니다.

지표가 없으면 품질이 나빠지고 있는지도 모르고,
나쁘다는 걸 알아도 어디가 나쁜지 모르고,
고쳤다고 해도 나아진 건지 모릅니다.

지표 설계 전에 정해야 할 것

지표를 만들기 전에 아래 두 가지를 먼저 정해야 합니다.

1. 이 시스템이 “잘 작동한다”는 게 무슨 뜻인가

막연하게 “답변이 좋아야 한다”는 기준은 지표로 만들 수 없습니다.

• 사용자가 다음 질문으로 이어가는 비율이 높으면 좋은 것인가
• 답변에 인용 근거가 포함되면 좋은 것인가
• 응답 길이가 적당하면 좋은 것인가
• 금지된 주제를 피하면 좋은 것인가

서비스마다 다릅니다. 먼저 정의하지 않으면 지표가 많아도 기준이 없습니다.

2. 실패는 어떻게 분류할 것인가

실패도 분류해야 대응이 달라집니다.

실패 유형	예시	대응 방향
사실 오류	잘못된 정보 제공	RAG 데이터 품질 개선
범위 이탈	질문과 다른 주제로 답변	프롬프트 가드 강화
형식 불일치	JSON 파싱 실패	출력 포맷 재설계
응답 거부	과도한 거절	시스템 프롬프트 조정
지연 초과	응답 3초 이상	프롬프트 압축, 모델 교체

기준선이 되는 5가지 지표

1. 정답률 (Accuracy on known set)

직접 정의한 대표 질문 세트에 대한 정답률입니다.

중요한 포인트는 “대표 질문”이 아니라 “실패한 질문” 위주로 세트를 구성하는 것입니다.

• 지난 주 사용자 피드백에서 나온 실패 케이스
• 릴리즈 전 발견한 버그 케이스
• 경계 조건 (빈 질문, 매우 긴 질문, 특수문자 포함)

이 세트를 매 릴리즈마다 돌려서 수치가 내려가는지 확인합니다.

2. 거절률 (Refusal Rate)

LLM이 답변을 거부하는 비율입니다.

거절이 항상 나쁜 건 아닙니다.
하지만 거절이 늘어나는 트렌드가 보이면 시스템 프롬프트가 너무 보수적으로 바뀐 것입니다.

def is_refusal(response: str) -> bool:
    refusal_signals = [
        "죄송합니다", "도움을 드리기 어렵습니다",
        "해당 질문에는", "안전상의 이유로"
    ]
    return any(s in response for s in refusal_signals)

3. 형식 일치율 (Format Compliance Rate)

JSON, 마크다운 테이블, 특정 구조를 출력해야 하는 경우에 적용합니다.

파싱 성공률로 측정하는 것이 가장 단순합니다.

def measure_format(response: str) -> bool:
    try:
        import json
        json.loads(response)
        return True
    except Exception:
        return False

4. 응답 지연 분포 (Latency Percentile)

평균보다 p95, p99를 봐야 합니다.
평균이 1초여도 p99가 8초면 사용자 경험이 나쁩니다.

p50 (중앙값): 일반적인 응답 속도
p95: 느린 요청의 기준선
p99: 장애 직전 수준

5. 피드백 수렴률 (Feedback Recovery Rate)

사용자가 “이 답변이 도움이 안 됐다”고 표시한 뒤,
같은 의도의 질문을 다시 했을 때 다음 답변이 나아졌는지 추적합니다.

직접 측정이 어렵지만 세션 재질문 패턴으로 근사할 수 있습니다.

모델 교체 전에 이 질문을 먼저 하자

모델을 바꾸면 보통 두 가지 기대를 합니다.

• 더 좋은 답변이 나올 것이다
• 지금 문제가 해결될 것이다

하지만 실제로 문제가 모델에서 오는 경우는 생각보다 적습니다.

아래를 먼저 확인합니다.

RAG 데이터 품질인가
검색된 컨텍스트가 질문과 관계없는 문서라면 모델이 좋아도 답이 나쁩니다.

프롬프트 구조인가
지시가 모호하거나 충돌하는 규칙이 있으면 같은 모델도 결과가 다릅니다.

평가 세트가 편향됐는가
잘 되는 케이스만 테스트하면 모델이 더 좋아 보이는 착각이 생깁니다.

지표를 유지하는 최소 운영 구조

단계	구성 요소	갱신 주기
평가 세트	실패 케이스 + 경계 케이스	매 스프린트
지표 대시보드	정답률 / 거절률 / 지연	매 배포 후
로그 수집	질문, 응답, 실패 여부	실시간
리뷰 미팅	이상 케이스 분류	주 1회

지표를 만드는 것보다 유지하는 루틴이 더 어렵습니다.

평가 세트는 정적으로 두면 점점 쉬운 문제만 남습니다.
사용자 피드백과 실패 케이스를 계속 추가하는 사람이 있어야 지표가 살아있습니다.

정리

• 모델을 바꾸기 전에 지표 기준선을 먼저 만든다
• 실패 케이스 중심으로 평가 세트를 구성한다
• 정답률·거절률·형식 일치율·지연 분포를 최소 4가지로 본다
• 지표가 없으면 나아지고 있는지 모른다