LLM 시스템을 다듬는 풍경은 대개 이렇다. 프롬프트를 바꾸고, 모델을 한 단계 올리고, RAG의 청킹을 손본다. 그리고 예시 몇 개를 돌려본 뒤 “음, 좋아진 것 같네” 하고 넘어간다.
그런데 그건 개선이 아니다. 좋아졌는지 나빠졌는지 모르는 채로 손대는 건, 그냥 운에 맡기는 것이다. 그리고 LLM은 그 운을 유난히 가리기 어려운 시스템이다.
눈대중으로는 측정이 안 된다
LLM은 입력이 사실상 무한하고 출력이 확률적이다. 같은 질문에 매번 다른 답을 내놓는다. 그러니 사람이 몇 개 눈으로 보고 “괜찮네” 하는 건 측정이 아니라 인상이다. 다섯 개가 좋아 보였다고 나머지 천 개가 좋아진 건 아니다.
그래서 순서를 뒤집어야 한다. 기능을 먼저 만들고 평가를 나중에 붙이는 게 아니라, 평가 셋과 측정 파이프라인을 먼저 세운다. eval이 있어야 변경 하나하나가 개선인지 회귀인지 점수로 갈리고, 그래야 빠르게 반복할 수 있다. “측정할 수 없으면 개선할 수 없다”는 오래된 말이 LLM에서 특히 들어맞는다.
싼 것부터 비싼 것까지, 피라미드로
평가를 다 사람이 할 수도, 다 자동화할 수도 없다. 그래서 3계층으로 쌓는다.
맨 아래는 자동 지표다. 정확도·정규식·코드 실행처럼 기계로 즉시 채점되는 것 — 비용이 거의 없으니 모든 변경마다 CI에서 돌린다. 가운데는 LLM-as-Judge다. 요약 품질·말투·근거성처럼 정답이 하나로 안 떨어지는 걸 모델이 루브릭으로 채점한다. 맨 위는 사람이다 — 가장 비싸고 느리니, 골드셋을 만들거나 judge가 사람과 맞는지 보정하는 결정적 순간에만 아껴 쓴다.
핵심은 피라미드 모양이다. 아래를 가장 많이, 위로 갈수록 적게. 아래 계층이 거른 것만 위로 올린다.
judge도 평가받아야 한다
LLM-as-Judge는 강력하지만 한 가지 함정이 있다. judge가 준 점수를 검증 없이 믿는 것. judge는 편향이 있다 — 두 답을 비교할 때 앞뒤 위치만 바꿔도 판정이 갈리고(position bias), 길고 장황한 답을 더 좋게 보고, 틀린 답에도 높은 확신을 준다.
그래서 judge 자체를 하나의 평가 대상으로 다뤄야 한다. 사람 골드셋으로 “이 judge가 사람과 얼마나 맞나”를 먼저 수치로 재고 시작한다. 강한 모델은 80~90%까지 사람과 일치하지만, 그건 태스크마다 다르고, 모르면 judge 점수를 믿을 근거가 없다.
eval은 바깥 루프의 계기판이다
한 단계 위에서 보면, 이건 「Loop Engineering」에서 말한 바깥 루프 이야기로 이어진다. 생성·검색·에이전트를 자동화할수록, 그 자동화를 신뢰할 수 있는지는 평가 게이트의 품질이 결정한다. 코드 리뷰가 바깥 루프의 검증 게이트였듯이, eval은 그 게이트를 돌리는 계기판이다. 계기판 없이 자동운전을 켜는 셈이 되면 안 된다.
그리고 eval은 한 번 만들고 끝나는 산출물이 아니다. 프로덕션에서 터진 실패를 계속 평가 셋에 흡수하며 자라는 살아 있는 자산이다. 그렇지 않으면 초기 골드셋이 실제 트래픽과 멀어진다.
3계층 아키텍처, judge 편향과 완화, 도구 지형까지 한 장으로 정리한 AI Eval 가이드를 따로 만들어 뒀다.