인턴할 때 LLM 평가 모델을 만들었었다.
평가 기준을 바꾸고, 프롬프트를 조정하면서 실험도 했고, 학습 데이터가 필요하니 데이터 생성용 프롬프트 엔지니어링도 했다.
요즘 면접을 다니면서 당시의 AS-IS와 지금의 TO-BE를 여러 번 설명했다. 구조는 설명할 수 있었다.
그런데 설명을 하면 할수록 찜찜했다. 말은 맞는데, 핵심을 비켜간 느낌이었다.
집에 와서 곱씹어 보면 결국 이 질문으로 돌아왔다.
무엇이 잘 된 LLM 평가인가.
---
많은 팀이 말하는 “평가”의 한계
평가는 보통 결과를 재는 일로 이해된다. 모델의 답변을 모아 점수를 매기고, 평균을 내고, 이전 버전과 비교한다. CSAT, 응답 품질 점수, 혹은 LLM grader가 준 1–5점 같은 수치들이다.
하지만 이 방식은 점수는 나오지만, 판단은 나오지 않는다.
“평균 점수가 4.2에서 4.4로 올랐습니다.”
그래서 무엇이 좋아졌을까. 정보 정확도가 개선된 걸까, 브랜드 톤이 안정된 걸까, 아니면 단순히 답변이 길어졌기 때문일까. 이 숫자 하나로는 알 수 없다. 이 상태에서의 평가는 모델을 이해하기 위한 도구라기보다는, 그럴듯함을 수치로 요약한 결과에 가깝다.
그래서 많은 팀이 선택하는 방식이 있다. CFT(Critique–Fine Tuning) 입니다. 모델의 출력에 대해 LLM이 코멘트를 달고, 그 코멘트와 함께 점수를 붙여서 모델이 이유를 외우게 한다. 형태는 보통 이런 식입니다.
{
"reason": "말투는 비교적 공손하지만 브랜드 톤과는 다소 어긋나고, 맥락 이해는 적절하나 핵심 질문에 대한 답변이 부족함",
"score": [4, 4, 5]
}이 방식은 분명 이전보다 나아졌다. 단순 점수보다 이유가 있고, 그 이유를 학습에 다시 넣을 수 있기 때문입니다. “왜 4점인지”를 텍스트로 남긴다는 점에서, 평가가 블랙박스는 아님.
그래도 ..
- 첫째, 이 critique는 행동 단위로 분해되어 있지 않다. 말투, 맥락, 문제 해결을 한꺼번에 서술하지만, 그게 시스템의 어떤 판단 단계에서 발생한 문제인지는 알기 어렵다. 톤이 어긋난 건 분류 단계의 문제일까요, 답변 생성 단계의 문제일까요, 아니면 정책 문구 자체가 애매해서 생긴 문제일까요??? critique 텍스트만으로는 다음 액션이 명확하지 않다.
- 둘째, 이 score는 의사결정과 직접 연결되지 않는다. 4, 4, 5라는 숫자를 보고 할 수 있는 말은 “조금 아쉽다” 정도. RAG를 고쳐야 할지, 프롬프트를 바꿔야 할지, 아니면 정책을 다시 써야 할지 판단하기 어렵다. 결국 다시 사람의 해석이 필요하다.
- 셋째, CFT는 여전히 최종 출력 중심 평가에 머무르는 경우가 많다. 모델이 어떤 판단을 거쳐 이 답을 냈는지, 중간에 어떤 선택지가 있었는지는 평가 대상이 아니다. 그래서 비슷한 critique가 반복되지만, 근본 원인은 계속 남아 있는 경우가 생긴다.
결국 CFT는 “왜 점수가 이렇다”는 설명은 해주지만, “그래서 시스템을 어디를 고쳐야 하느냐”까지는 잘 안내하지 못한다. 이 지점에서 평가가 학습 데이터 생성 도구를 넘어서지 못하고,,,
그래서 잘 된 eval은 critique를 쓰느냐 마느냐의 문제가 아니라, critique가 어떤 의사결정을 가리키고 있느냐의 문제로 본다. 그리고 이 지점에서 Golden set, error taxonomy, 워크플로우 기반 평가가 필요하다.
측정하지 못하면, 개선할 수 없다
AI 제품이 실패하는 이유는 대부분 모델이 나빠서가 아니다. 프롬프트를 못 짜서도 아니다. 무엇이 성공인지 정의하지 않은 상태에서 평가부터 시작했기 때문이다.
예를 들어 “고객 이메일에 잘 답하는 챗봇”을 만든다고 해보자. 여기서 ‘잘’이 무엇일까. 빠른 응답일까, 정확한 정보일까, 공감적인 톤일까, 아니면 다음 행동으로 자연스럽게 연결되는 것일까. 이 질문에 답하지 않으면 평가는 공중에 뜬다. 성공을 정의하지 않으면, 개선도 정의할 수 없다.
그래서 OpenAI를 포함한 여러 팀들은 평가를 추상적인 목표에서 시작하지 않는다. 목표를 구체적인 사례들의 집합으로 쪼갠다. 실제 고객 이메일을 입력으로 두고, 숙련된 담당자가 보냈을 법한 답변을 기대 출력으로 둔다. 동시에 무엇을 피해야 하는지도 명시한다. 너무 장황한 답변, 잘못된 정보, 애매한 추측 같은 것들이다. 이때 만들어지는 것이 흔히 말하는 Golden set이다.
하지만 중요한 건 Golden set이 존재한다는 사실이 아니다.
이 Golden set이 무엇을 기준으로 만들어졌느냐다.
1. 잘 만든 eval의 정의
그렇다면 잘 만든 eval이란 무엇일까. 정리해보면, 잘 만든 eval은 최소한 세 가지 질문에 답할 수 있어야 한다.
- 시스템이 언제 실패하는지 명확히 보이는가
- 그 실패가 왜 일어났는지 분류할 수 있는가
- 그래서 다음에 무엇을 고쳐야 할지 결정할 수 있는가
Golden set이 아무리 많아도 실패 원인을 말해주지 못하면 나쁜 eval이다. 반대로 Golden set이 많지 않더라도 결과를 보고 “아, 이건 RAG 문제네”, “이건 정책 정의가 애매해서 그렇네”, “프롬프트가 이 판단을 강제하지 못했네” 같은 말이 바로 나오면 좋은 eval이다.
평가는 모델을 채점하는 도구가 아니라, 개선 방향을 드러내는 장치여야 한다.
2. Golden set이 정말 다 커버하고 있는지 확인하는 질문들
Golden set이 충분한지를 고민할 때, 데이터 개수부터 세는 경우가 많다. 하지만 커버리지는 개수가 아니라 질문으로 확인하는 게 훨씬 정확하다. Golden set을 보면서 다음 질문들에 예/아니오로 답해보면 된다.
Q1. 이 예시가 실패했을 때, 무엇을 고쳐야 할지가 바로 떠오르는가
“음… 그냥 답변이 별로네요”에서 멈춘다면 그 예시는 평가로서 역할을 못 한다. 반면 “환불 조건 문서를 못 불러왔네”, “톤은 맞는데 핵심 질문을 놓쳤네”, “애매한 케이스를 추측으로 분류했네”처럼 바로 행동으로 연결되면 좋은 Golden example이다. 행동으로 이어지지 않는 예시는 나쁜 Golden set이다.
Q2. Golden set이 ‘모델이 고민해야 할 결정’을 강제로 포함하는가
좋은 Golden set은 명확한 정답 문제가 아니다. 갈등이 있는 문제를 포함한다. 환불 요청처럼 보이지만 사실은 제품 사용법 문의인 경우, 고객은 화가 나 있지만 정책상 즉시 환불은 불가한 경우, 정보 자체는 맞지만 브랜드 톤으로 쓰면 어색한 표현 같은 케이스들이다. 이런 사례가 없다면, 그 Golden set은 현실을 너무 쉽게 축소한 것이다.
Q3. “아무 일도 안 일어나는 구간”이 과소대표되어 있지는 않은가
많은 Golden set이 극단만 담는다. 완벽한 입력이나 완전히 망한 입력들이다. 하지만 실제 트래픽의 대부분은 애매한 질문, 맥락이 부족한 요청, 반쯤만 맞아도 큰 문제가 없는 상황들이다. Golden set의 30–50%는 조금만 잘못해도 사고가 나는 평범한 입력이어야 한다. 이 구간을 잡지 못하면 운영 단계에서 평가는 무력해진다.
3. Golden set 커버리지를 확인하는 실전 방법
가장 실용적인 방법은 커버리지를 기능이 아니라 실패 유형 기준으로 보는 것이다. 먼저 error taxonomy를 만든다. 처음부터 정교할 필요는 없다. 실제 아웃풋 20–30개만 리뷰해도 정보 오류, 정책 위반, 톤 문제, 질문 누락, 불필요한 장황함, 애매한 추측, 에스컬레이션 누락 같은 분류는 금방 나온다.
그 다음 Golden set을 이 taxonomy에 매핑한다. 각 Golden example을 보며 “이 예시는 어떤 실패를 잡기 위해 존재하나?”를 묻는다. 아무것도 떠오르지 않으면 제거 후보다. 여러 실패 유형이 동시에 떠오르면 좋은 예시다. 특정 taxonomy만 반복된다면, 그 지점이 커버리지의 구멍이다. 표로 정리하면 어디가 비어 있는지 바로 보인다. 이 순간이 eval이 말을 하기 시작하는 지점이다.
4. “Golden set이 충분한가”를 판단하는 현실적인 기준
Golden set이 충분한지를 판단할 때 완벽함을 목표로 할 필요는 없다. 다음 세 가지가 동시에 만족되면, 지금 단계에서는 충분하다고 볼 수 있다.
첫째, 새 프롬프트나 툴을 바꿨을 때 점수가 아니라 실패 분포가 어떻게 바뀌었는지 설명할 수 있는가.
둘째, 실제 운영 이슈 하나를 Golden set의 특정 예시나 taxonomy로 바로 연결할 수 있는가.
셋째, 도메인 전문가가 “이건 맞고, 이건 틀리다”를 빠르게 판단할 수 있는가. 토론이 길어지지 않는가.
이 세 가지가 된다면, 그 eval은 이미 모델 비교를 넘어서 의사결정을 돕는 도구가 되어 있다.
Golden set은 무엇을 대표하는가
Golden set은 현실을 대표하는 데이터셋이 아니다.
우리가 두려워하는 실패를 압축한 데이터셋이다.
그래서 많을 필요도 없고, 균등할 필요도 없고, 정적일 필요도 없다. 대신 지금 우리가 무엇을 통제하려는지, 시스템이 어디에서 흔들리면 안 되는지를 정확히 드러내야 한다.
“A Survey on Agent-as-a-Judge” 이 논문의 정리를 쓰려고 했는데 서론만 잔뜩 길어져서 다음 글에 이어서 쓸개요 ~~