생성형 AI 평가 방법 정리: 검증 데이터셋 구축과 LLM 심판 활용 실무 워크플로

핵심 메시지

• 데모에서 잘 돌아가던 생성형 AI 앱도 실제 운영에서는 엉뚱한 답변과 환각을 내놓기 때문에, 공개 벤치마크가 아니라 자기 서비스에 맞춘 평가 데이터셋이 필요하다.
• 같은 프롬프트와 같은 모델에서도 결과가 달라진다. 프롬프트 표현, 시스템 프롬프트, 모델 버전 갱신, 추론 인프라, GPU 연산의 비결정성이 모두 출력에 영향을 준다.
• 사람이 모든 답변을 검수할 수는 없으므로, 정답과 모델 출력이 '같은 뜻인지' 판정하는 LLM 심판을 두고 그 판정이 사람 판단과 어긋나지 않는지 주기적으로 맞춰야 한다.
• 무엇이 나쁜 답변인지는 책상에서 정해지지 않는다. 도메인 전문가와 사용자에게 직접 물어 실패 유형을 언어화한 뒤에야 자동화된 테스트로 옮길 수 있다.
• 에이전트처럼 모델이 스스로 도구와 경로를 고르는 구조에서는 전체를 한 번에 보지 말고 라우팅 판단과 개별 단계로 쪼개 각각 평가해야 한다.

쉽게 이해하기

발표자는 고객 응대 메일을 대신 써 주는 생성형 AI를 예로 들어 이야기를 시작한다. 프롬프트를 대충 붙여도 그럴듯한 결과가 나오기 때문에 다 됐다고 착각하기 쉽지만, 조금만 오래 운영해 보면 배송 지연을 물었는데 신제품 안내가 돌아오거나, 팔지도 않는 에스프레소 머신이 파손됐다며 사과하는 답변이 나온다. 실제로 코드 편집기 커서(Cursor)의 고객 응대 봇은 '구독 하나당 기기 한 대만 쓸 수 있다'는 존재하지 않는 정책을 만들어 냈고, 이를 사실로 받아들인 이용자들이 구독을 해지하는 일까지 벌어졌다.

이런 실수가 위험한 이유는 법적 책임과도 이어지기 때문이다. 발표자는 법원이 생성형 AI 봇의 행위를 직원의 행위와 다르게 보지 않을 수 있다고 지적한다. 봇이 약속을 만들어 냈다면 회사가 그 약속을 감당해야 한다는 뜻이다. 여기에 더해 2025년에는 경영진이 먼저 투자 대비 성과를 따져 묻기 시작했다. 그는 '95%가 실패한다'는 식의 수치는 과장됐다고 선을 그으면서도, 생성형 AI가 언제나 큰 성과를 보장하지는 않는다는 점은 인정한다.

평가가 어려운 근본 원인은 같은 조건에서도 출력이 달라진다는 데 있다. 발표자는 이를 입력·모델·출력 세 단계로 나눠 설명한다. 입력 쪽에서는 객관식 문제를 푸는 MMLU 벤치마크조차 평가 도구마다 프롬프트 문장이 조금씩 달라 점수가 갈렸고, 선택지 표기를 괄호 알파벳에서 숫자로 바꾸거나 둥근 괄호를 대괄호로 바꾸는 것만으로도 결과가 흔들렸다. 사용자가 쓴 질문뿐 아니라, 평소 아무도 읽지 않는 수천 단어짜리 시스템 프롬프트도 답변을 좌우한다. 중동에서 공개된 한 오픈소스 모델이 유독 아부다비를 추천했던 사건도, 가중치가 아니라 '너는 아부다비에서 만들어진 모델'이라고 적힌 시스템 프롬프트가 원인이었다.

모델과 출력 쪽에도 변수가 많다. 같은 계열의 라마 70B와 소형 모델은 비슷해 보여도 출력이 완전히 같지 않고, 상용 API는 통보 없이 갱신돼 성능이 뒤로 밀리기도 한다. 발표자는 실제로 모델 버전을 올렸다가 여러 동작에서 퇴행을 겪고 프롬프트를 다시 손봤다고 말한다. 오픈소스를 쓰더라도 추론 서버가 바뀌면 결과가 달라지므로 인프라 전체를 함께 봐야 한다. 여기에 GPU 추론은 시드를 고정해도 완전히 같은 값이 나오지 않는 비결정성이 있다. 부동소수점 오차 누적, 전문가 혼합 모델의 배치 차이 등이 원인인데, 최근 싱킹 머신스(Thinking Machines)가 배치 처리를 바로잡아 이를 없애는 방법을 제시했고 vLLM에도 도입됐다는 소식이 이어졌다.

그렇다면 무엇을 해야 하나. 발표자가 제시하는 출발점은 단순하다. 프롬프트와 사람이 만든 정답(ground truth)을 짝지어 놓고, 모델 출력이 정답과 같은 뜻인지 판정한다. 글자가 똑같을 필요는 없다. 이 '동등성' 판정을 사람이 모두 하기엔 비싸고 지치므로 LLM을 심판으로 세운다. 그러면 전통적인 머신러닝처럼 프롬프트나 모델을 하나씩 바꿔 가며 동등성 점수를 올리는 익숙한 작업이 된다. 다만 심판 모델은 자기 계열이 쓴 글을 더 좋아하는 편향, 앞쪽 답변을 선호하는 편향 등을 갖고 있으므로 심판을 여러 회사 모델로 섞고 사람 판단과 정렬을 계속 확인해야 한다.

동등성만으로는 잡히지 않는 부분은 '테스트'로 옮긴다. 핵심은 무엇이 나쁜 답변인지 사람이 명확히 말할 수 있게 만드는 일이다. 발표자는 데이터 과학자들이 자리에서 일어나지 않고 논문과 알고리즘으로 답을 찾으려 한다고 꼬집으며, 도메인 전문가와 사용자에게 직접 물어보라고 강조한다. '너무 짧다', '어조가 전문가답지 않다'처럼 이유가 언어로 정리되면 길이는 파이썬 몇 줄로, 어조는 LLM 심판으로 자동 검사할 수 있다. 금융 분석 에이전트라면 맥락·명료성·정확성·규정 준수·실행 가능성·위험 고지 여섯 항목을 각각 단위 테스트로 만들어, 어느 항목에서 무너졌는지 바로 볼 수 있다.

마지막은 실패를 모아 패턴을 찾는 오류 분석과, 그것을 반복하는 순환이다. 한 번에 여러 설정을 바꾸지 말고 하나씩 바꾸며 효과를 보고, 이상치와 좋은 사례는 따로 저장해 두고, 로그와 추적 기록을 남기는 도구를 쓰라는 조언이 이어진다. 생성형 AI에는 전통적 머신러닝의 홀드아웃 데이터셋이 없고 사용자가 곧 시험 세트이므로, 초기 평가셋으로 어느 정도 다듬은 뒤에는 반드시 실제 사용자에게 내보내 피드백을 다시 평가셋에 넣어야 한다. 에이전트에서는 어떤 작업 흐름을 고를지 정하는 라우팅 판단과 이후 실행 단계를 나눠 각각 평가하는 식으로 문제를 쪼갠다. 발표자는 에이전트 프레임워크가 데모에는 좋지만 세부 구현을 감춰 두기 때문에, 운영 단계에서는 순수 파이썬으로 직접 짜는 편을 권한다.

주요 인사이트

• 공개 벤치마크 점수는 모델의 대략적인 수준을 알려 줄 뿐, 우리 서비스에 맞는지는 말해 주지 않는다. 평가의 첫 작업은 자기 사례를 반영한 데이터셋을 직접 만드는 것이다.
• 출력이 흔들리는 원인을 입력·모델·출력으로 나눠 보면, 프롬프트 문구부터 시스템 프롬프트, 모델 갱신, 추론 서버, GPU 비결정성까지 손댈 수 있는 지점과 통제 불가능한 지점이 구분된다.
• 평가는 기술 지표만의 문제가 아니다. 발표자는 투자 대비 효과와 함께 24시간 자체 GPU 운영 같은 총소유비용을 처음부터 계산에 넣으라고 조언한다.
• LLM 심판은 사람의 검수 부담을 줄이는 도구일 뿐, 사람을 대체하지 않는다. 판정 근거를 한 문장으로 설명하게 하고 사람 판단과 정렬을 확인하는 절차가 함께 있어야 신뢰할 수 있다.
• 성능 개선은 우상향 직선이 아니라 전진과 후퇴의 반복이다. 처음부터 모든 예외를 잡으려 하지 말고 테스트를 몇 개로 시작해 수개월에 걸쳐 수십 개로 늘려 가는 편이 현실적이다.

자주 묻는 질문

관련 AI 소식