LLM 평가가 어려운 이유는 모델이 특별히 변덕스러워서만은 아닙니다. 더 큰 문제는 사람들이 보통 좋아 보이는 몇 장면을 운영 품질로 착각한다는 점입니다.
이번 글에서는 데모는 좋은데 운영 품질은 왜 다르게 느껴지는지, single-example 착시, 테스트셋 구성, 실패 패턴, human review 비용 관점으로 정리하겠습니다.
복잡도를 너무 빨리 올리지 말라는 점은 Anthropic의 Building Effective AI Agents 글과도 맞닿습니다. 평가가 약한 상태에서 복잡한 agent 구조를 올리면 문제 원인이 더 흐려질 수 있습니다.
왜 데모는 자주 좋아 보일까
데모는 보통 가장 보기 좋은 질문으로 구성됩니다. 즉 제품이 잘하는 장면을 먼저 보여주기 때문에, 실제 운영에서 마주칠 지저분한 입력 분포를 대표하지 않는 경우가 많습니다.
- 질문이 짧고 분명하다
- 문맥이 충분하다
- 모호하거나 애매한 표현이 적다
- 실패하기 쉬운 경계 사례가 빠져 있다
그래서 데모는 모델의 가능성을 보여주기에는 좋지만, 운영 품질을 보증해주지는 않습니다.
single-example 착시는 왜 위험할까
LLM 시스템은 한두 개 예시에서 아주 좋아 보일 수 있습니다. 하지만 운영에서는 입력 종류가 훨씬 넓고, 실패 양상도 더 복잡합니다. 즉 하나의 성공 예시는 신뢰가 아니라 착시를 만들기 쉽습니다.
예를 들어 고객센터 봇이 “환불 규정 알려줘”에는 잘 답해도, “지난번에 산 것 같은데 정확한 주문번호는 모르겠고 부분 환불 가능한가요?” 같은 질문에서 급격히 흔들릴 수 있습니다.
운영 품질은 입력 분포가 다르다
실제 운영에서는 오타, 불완전한 문장, 문맥 생략, 잘못된 전제, 감정 섞인 요청, 복합 의도가 섞입니다. 즉 평가셋이 실제 분포를 닮지 않으면 데모 성능과 운영 체감은 점점 벌어집니다.
실패 패턴을 먼저 모아야 한다
- 정답이 틀린 경우
- 부분적으로만 맞는 경우
- 형식은 맞지만 핵심 요청을 놓친 경우
- 출처나 근거가 약한 경우
- 너무 자신 있게 틀리는 경우
이런 실패 패턴을 모으지 않으면, 평가는 계속 “잘 된 예시 모음집”에 머물기 쉽습니다.
human review 비용도 평가의 일부다
운영형 LLM은 종종 사람 검토를 함께 둡니다. 그런데 여기서 중요한 것은 모델 점수만이 아닙니다. 사람 검토가 얼마나 자주 필요한지, 어떤 케이스에서 검토가 몰리는지, 검토 비용이 감당 가능한지도 평가의 일부입니다.
즉 평가는 “정답률 몇 퍼센트”보다, 운영 전체 비용을 얼마나 줄이거나 늘리는가까지 봐야 합니다.
실전 평가 루프는 이렇게 보는 편이 좋다
- 대표 입력만이 아니라 실패하기 쉬운 입력을 일부러 넣는다
- 정답 여부뿐 아니라 실패 유형을 분류한다
- retrieval, generation, policy check 단계를 나눠 본다
- human review 비용과 시간도 함께 측정한다
이 관점은 프롬프트 엔지니어링 글, RAG 글과도 바로 연결됩니다.
마무리
LLM 평가가 어려운 이유는 모델이 특별히 이상해서가 아니라, 운영 현실이 데모보다 훨씬 복잡하기 때문입니다. single-example 착시, 입력 분포 차이, 실패 패턴 누락, human review 비용이 겹치면 체감 품질은 금방 달라집니다.
좋은 평가는 모델을 칭찬하는 예시를 더 모으는 것이 아니라, 어디에서 어떻게 틀리는지 먼저 드러내는 일에서 시작합니다.
