생성형 AI를 다루다 보면 묘한 장면을 자주 본다. 데모에서는 모두를 감탄하게 만든 모델이 실제 서비스에 붙는 순간 갑자기 허술해진다. 질문 하나에는 아주 똑똑하게 답하다가, 조금만 표현을 바꾸면 엉뚱한 소리를 한다. 벤치마크 점수는 높았는데, 정작 고객은 "생각보다 쓸 만하지 않다"고 말한다.
이 장면은 우연이 아니다. 우리가 오랫동안 익숙했던 정확도 중심의 평가 습관이 생성형 AI 시대에는 너무 좁기 때문이다. 이제 중요한 질문은 "이 모델의 점수가 몇 점인가"가 아니라, 어떤 상황에서 얼마나 믿을 만한가, 얼마나 일관적인가, 얼마의 비용으로 얼마나 빨리 동작하는가다. 그래서 모델을 만들 줄 아는 것보다, 제대로 평가할 줄 아는 사람이 더 드물고 더 중요해졌다.12
정확도만으로는 부족하다
전통적인 머신러닝에서는 문제가 비교적 단순한 경우가 많았다. 스팸 메일 분류기라면 스팸인지 아닌지 맞히면 됐다. 고양이와 개를 구분하는 모델이라면 정답 라벨과 예측 라벨을 비교하면 됐다. 이런 세계에서는 정확도, 정밀도, 재현율, F1 점수가 강력한 나침반이었다.
하지만 생성형 AI는 다르다. 모델이 만드는 답은 종종 열린 답안이다. 요약은 하나의 정답 문장으로 고정되지 않는다. 질의응답도 표현 방식이 다양하다. 대화형 시스템은 한 번의 응답만이 아니라, 여러 턴에 걸친 맥락 유지와 태도까지 품질에 포함된다. RAG 시스템은 답변 자체뿐 아니라, 그 답을 만들기 위해 무엇을 얼마나 잘 찾았는지도 봐야 한다.
그래서 생성형 AI 평가에서 "정확도"는 더 이상 왕이 아니다. 많아야 평가 항목 중 하나일 뿐이다. 어떤 시스템에서는 사실성보다 친절함이 더 중요할 수 있고, 어떤 시스템에서는 친절함보다 근거 제시가 더 중요할 수 있다. 또 어떤 시스템에서는 답의 품질이 조금 떨어져도, 응답 속도와 비용이 훨씬 더 중요한 제약이 될 수 있다.1
핵심은 이것이다. 좋은 평가는 모델을 평가하는 것이 아니라, 모델이 수행하는 일을 평가한다. 일이 달라지면 지표도 달라져야 한다.
분류, 생성, 검색, 대화는 왜 서로 다른 지표를 쓰는가
평가 지표가 달라지는 이유는 간단하다. 각 시스템이 실패하는 방식이 다르기 때문이다.2
분류 시스템은 맞혔는지 틀렸는지가 비교적 분명하다. 그래서 정확도, 정밀도, 재현율, F1처럼 정답 라벨과의 비교가 핵심이 된다.
생성 시스템은 문장이 자연스러운지, 사실에 맞는지, 질문에 제대로 답했는지, 불필요하게 장황하지는 않은지까지 함께 봐야 한다. 단순 문자열 일치만으로는 품질을 다 설명할 수 없다.
검색 시스템은 정답 문서를 찾았는지뿐 아니라, 상위 몇 개 안에 제대로 올려놨는지가 중요하다. 그래서 Precision@k, Recall@k, MRR, nDCG 같은 순위 기반 지표가 쓰인다.3
대화·에이전트 시스템은 한 번의 응답이 아니라 전체 작업 성공률을 봐야 한다. 사용자의 의도를 계속 따라가는지, 툴을 올바르게 호출하는지, 위험한 요청에서 적절히 거절하는지, 여러 단계의 작업을 끝까지 완수하는지가 중요하다.5
예를 들어 고객센터 챗봇을 생각해 보자. 이 시스템이 "문장만 자연스럽게" 말하면 좋은 모델일까? 아니다. 고객은 예쁜 문장을 원하지 않는다. 정확한 정책 안내, 빠른 응답, 일관된 태도, 위험한 상황에서의 안전한 처리를 원한다. 반대로 브랜딩 카피를 만드는 도구라면 약간의 창의성과 문체 제어가 더 중요할 수 있다.
즉, 평가는 언제나 "이 모델이 무슨 문제를 푸는가"에서 시작해야 한다. 지표는 모델의 성격표가 아니라, 업무의 성공 조건을 숫자로 번역한 것이어야 한다.
자동 평가는 빠르고, 인간 평가는 깊다
생성형 AI를 평가할 때 가장 먼저 부딪히는 현실은 이것이다. 사람 눈으로 보면 금방 이상한 답인데, 자동 지표로는 멀쩡해 보일 때가 있다. 반대로 자동 지표 점수는 낮은데, 사람이 읽으면 꽤 괜찮은 경우도 있다.
자동 평가는 빠르고 싸다. 대량 실험에 적합하다. BLEU, ROUGE, 의미 유사도, 정답 일치율 같은 지표는 한밤중에도 불평 없이 수천 건을 채점한다. 회귀 테스트, 모델 비교, 프롬프트 실험처럼 반복이 잦은 작업에서는 자동 평가가 사실상 필수다.4
하지만 자동 평가는 종종 표면만 본다. 요약이 기준 답안과 다른 표현을 썼다는 이유로 낮게 나올 수 있고, 반대로 문장 겉모습은 비슷한데 핵심 사실을 틀려도 높은 점수를 받을 수 있다. 특히 생성형 AI에서는 "같은 뜻을 다른 방식으로 말하는 능력"이 중요한데, 전통적 문자열 기반 지표는 이 유연성을 충분히 포착하지 못한다.24
인간 평가는 느리고 비싸지만, 대신 깊다. 사람은 답변의 미묘한 어조, 애매한 회피, 과도한 자신감, 맥락에 어울리지 않는 표현을 알아챈다. 무엇보다 실제 사용자 경험과 가장 가깝다. 도움이 되었는지, 신뢰가 가는지, 불쾌하거나 위험하지 않은지 같은 판단은 결국 사람의 몫이다.45
그래서 실무에서는 둘 중 하나를 고르는 것이 아니라, 층을 나눠 함께 쓴다. 자동 평가는 넓게 훑고, 인간 평가는 깊게 판다. 최근에는 그 중간층으로 LLM-as-a-judge도 자주 쓰인다. 더 강한 모델이 다른 모델의 응답을 기준에 따라 평가하게 하는 방식이다. 속도와 확장성 면에서는 인간보다 유리하고, 단순 자동 지표보다 풍부한 판단을 제공할 수 있다. 다만 판정 모델 자체의 편향, 프롬프트 설계, 일관성 문제가 있어서 맹신할 수는 없다.4
쉽게 말해 이렇다.
자동 평가는 체온계다. 인간 평가는 진료다. LLM 심판은 꽤 똑똑한 간호사에 가깝다. 셋 다 필요하지만, 셋이 같은 역할을 하지는 않는다.
벤치마크 점수는 왜 실제 제품 품질을 보장하지 못하는가
벤치마크는 분명 중요하다. 공통 시험지가 있어야 모델을 비교할 수 있기 때문이다. 벤치마크가 없다면 우리는 각자 자기 모델이 좋다고 주장만 하게 된다. 하지만 벤치마크 점수는 어디까지나 표준화된 시험장 성적표다. 그것만으로 실전 능력을 다 보장하지는 못한다.5
문제는 크게 네 가지에서 생긴다.
첫째, 벤치마크 포화다. 어떤 시험은 너무 오래 유명해져서 상위 모델들이 거의 다 높은 점수를 받는다. 이때 1~2점 차이는 실제 의미보다 잡음에 가까울 수 있다. 이런 상태에서는 점수표가 모델 간의 진짜 차이를 잘 가려주지 못한다.6
둘째, 데이터 오염이다. 벤치마크 문제가 학습 데이터 어딘가에 섞여 있으면 모델은 실력을 보여준 것이 아니라, 이미 본 문제를 떠올렸을 가능성이 있다. 특히 오래 공개된 코딩·지식 벤치마크는 이런 의심에서 자유롭기 어렵다.6
셋째, 현실과의 거리다. 벤치마크는 보통 문제 형식을 깔끔하게 정리해 둔다. 하지만 실제 사용자는 오타를 내고, 질문을 돌려 말하고, 필요한 정보와 불필요한 정보를 한꺼번에 던진다. 기업 문서는 버전이 섞여 있고, 고객 문의는 감정이 실려 있으며, 업무는 한 단계로 끝나지 않는다. 벤치마크에서 잘하는 모델이 실무에서 꼭 잘하는 이유가 여기에 없다.57
넷째, 벤치마크가 보지 않는 것들이 있다. 많은 리더보드는 품질 점수를 보여 주지만, 실제 제품은 품질만으로 굴러가지 않는다. 같은 수준의 답을 내는 두 모델이 있다면, 더 싼 모델이 더 좋은 선택일 수 있다. 응답이 3초 늦어지는 순간 사용성은 크게 떨어질 수 있다. 컨텍스트 길이, 초당 토큰 속도, 첫 응답 지연 시간, 호출 비용은 제품에서는 아주 현실적인 변수다.7
그래서 벤치마크는 출발점이지 종착점이 아니다. 리더보드는 후보를 좁히는 데 유용하지만, 마지막 선택은 늘 우리 제품의 실제 질문 세트가 해야 한다.
좋은 평가는 모델이 아니라 시스템 전체를 본다
생성형 AI 제품은 더 이상 모델 하나로 설명되지 않는다. 검색이 붙고, 프롬프트가 붙고, 캐시가 붙고, 안전장치가 붙고, 폴백 로직이 붙는다. 그러니 평가도 시스템 단위로 올라가야 한다.
특히 운영 환경에서는 다음 질문이 빠질 수 없다.
안전성: 유해한 요청에 어떻게 반응하는가. 거절은 적절한가. 민감한 정보는 새지 않는가.
일관성: 같은 질문을 여러 번 했을 때 답이 지나치게 흔들리지 않는가. 정책 설명이 세션마다 달라지지 않는가.
비용: 한 번의 응답에 얼마가 드는가. 더 비싼 모델이 실제로 그만한 가치를 만드는가.
지연 시간: 사용자가 기다릴 만한 속도인가. 피크 시간대에도 안정적인가.
이 네 가지는 종종 모델 발표 자료에서 뒤로 밀리지만, 제품에서는 앞자리에 앉아 있다. 예를 들어 내부 문서 검색 도우미가 아주 정확하더라도 응답에 15초가 걸리면 팀은 금세 사용을 포기한다. 반대로 아주 빠르고 저렴해도 근거 없는 답을 자주 내면 더 위험하다. 결국 제품 품질은 하나의 점수가 아니라, 여러 제약 사이의 균형점이다.17
그래서 최근의 모델 비교 도구들은 품질뿐 아니라 가격, 속도, 컨텍스트 길이, 실행 시간까지 함께 보여 준다. 이제 "가장 똑똑한 모델"보다 중요한 질문은 "우리 목적에 가장 맞는 모델"이 무엇인가다.7
실무에서는 어떤 평가 체계를 가져가야 할까
좋은 평가 체계는 한 번 시험 보고 끝나는 행사가 아니다. 개발, 배포, 운영을 따라다니는 반복 구조여야 한다. 실무에서는 보통 네 층으로 생각하면 감이 좋다.18
오프라인 기준 세트 평가: 대표 질문과 기대 답안을 모아 둔 골든 세트로 기본 성능을 본다.
모델·프롬프트 실험 평가: 한 번에 한 변수만 바꿔 비교한다. 모델만 바꾸거나, 청킹만 바꾸거나, 프롬프트만 바꾼다.8
스트레스·안전성 평가: 애매한 질문, 적대적 프롬프트, 경계 사례를 따로 모아 실패 패턴을 본다.
온라인 운영 평가: 실제 사용자 로그에서 실패율, 재시도율, 만족도, 비용, 지연 시간을 지속적으로 본다.
이때 중요한 원칙이 있다. 평가는 실험이어야 한다. 데이터셋도 바꾸고 모델도 바꾸고 프롬프트도 바꾸고 설정도 바꾸면, 무엇 때문에 결과가 달라졌는지 알 수 없다. 그래서 테스트 질문과 기준 답안은 가능한 한 고정하고, 매번 한 변수만 바꾸는 습관이 필요하다.8
생성형 AI 평가가 어려운 또 다른 이유는 비용이다. 추론도 비싸고, 사람 채점도 비싸다. 그래서 최근 연구들은 적은 샘플로도 전체 성능을 더 효율적으로 추정하고, 드문 실패 사례를 적극적으로 찾아내는 평가 방법을 탐구한다. 중요한 것은 모든 것을 무식하게 전수검사하는 것이 아니라, 가장 위험한 실패를 가장 빨리 발견하는 평가 설계다.9
좋은 AI 제품은 평가 체계가 다르다
AI 제품을 잘 만드는 팀은 모델이 좋다고 말하기 전에, 먼저 이렇게 묻는다.
이 시스템의 가장 치명적인 실패는 무엇인가. 그 실패를 가장 빨리 잡아내는 테스트는 무엇인가. 좋은 답 하나보다, 나쁜 답 하나가 더 큰 비용을 만드는 영역은 어디인가. 사용자가 정말 체감하는 품질은 정확도인가, 속도인가, 신뢰감인가.
이 질문들이 쌓이면 평가 체계가 단단해진다. 반대로 지표 몇 개만 대충 붙여 놓으면, 팀은 쉽게 착각에 빠진다. 리더보드 성적이 좋으니 괜찮겠지. 데모가 그럴듯하니 출시해도 되겠지. 하지만 생성형 AI에서 품질은 종종 가장 멋진 응답이 아니라, 가장 위험한 실패를 얼마나 줄였는가로 드러난다.
평가를 잘한다는 것은 모델을 의심하는 능력이다. 그리고 그 의심을 숫자와 사례와 운영 지표로 조직화하는 능력이다. 생성형 AI 시대에는 바로 그 능력이 제품의 신뢰를 만든다.
다음으로 넘어가면 이 질문이 자연스럽게 이어진다. 그렇다면 이런 평가의 출발점이 되는 것은 무엇일까. 결국 모델은 데이터 위에서 배우고, 평가는 데이터 위에서 검증된다. 즉, 좋은 평가 체계를 만들고 싶다면, 그보다 먼저 좋은 데이터를 어떻게 설계할 것인가를 생각해야 한다.
참고
1Guide to Generative AI Evaluation - PwC
2Measuring the quality of generative AI systems: Mapping metrics to quality attributes
3A complete guide to RAG evaluation: metrics, testing and best practices
4LLM Evaluation: Metrics, Benchmarks & Best Practices
5Benchmarking Generative AI Performance Requires a Holistic Approach
6The Complete Guide to LLM Benchmarking: Everything You Need to Know
7Compare frontier AI models by quality, cost, and context
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.