LLM 평가 스택: AI 기능을 실제로 측정하는 방법

아무도 훈련받지 못한 스킬

모든 팀이 LLM 기능을 출시하고 있습니다. 하지만 그 기능이 정말로 좋은지 알 수 있는 진짜 방법을 가진 팀은 거의 없습니다.

Hamel Husain과 Shreya Shankar의 AI Evals For Engineers & PMs 코호트는 OpenAI와 Anthropic 소속 엔지니어와 PM을 포함해 2,000명이 넘는 실무자를 훈련시켰습니다. 강좌가 가득 찬 이유는 이론 때문이 아닙니다. 이것을 만들고 있는 사람들이 자신들의 QA 프로세스가 "프롬프트 엔지니어에게 출력 30개를 읽혀 보고 직감을 믿는다" 수준이라는 사실을 깨달았기 때문입니다.

Hamel은 이를 "vibes eval"이라고 부릅니다. 이것이 지배적인 관행이며, 수많은 AI 기능이 출시되어 데모는 잘 통과한 뒤 조용히 품질이 저하되는 이유입니다. Lenny's Newsletter 팟캐스트에서 Hamel과 Shreya는 평가야말로 이제 AI 프로덕트 업무에서 가장 레버리지가 큰 스킬이며, 프롬프트 기술보다, 올바른 모델 선택보다 더 중요하다고 주장했습니다. 이유는 구조적입니다. 품질을 측정할 수 없다면, 개선할 수도 없습니다.

대부분의 팀은 이 사실을 압니다. 그래도 하지 않습니다. 왜일까요? 평가가 인프라 작업처럼 보이고, 명확한 담당자가 없으며, 첫 버전은 늘 손으로 출력을 읽는 것보다 더 안 좋아 보이기 때문입니다. 요령은 "손으로 출력을 읽는 것"이 곧 평가라는 사실을 깨닫는 데 있습니다. 한 번 제대로 하고, 본 것을 기록한 뒤, 같은 방식으로 두 번 다시 하지 않는 것이 핵심 원칙입니다.

이 글은 그 플레이북입니다. 의도적으로 도구에 구애받지 않습니다. 영국 AI Safety Institute의 Inspect AI, Arize의 Phoenix, Promptfoo, Langfuse, OpenAI Evals framework, Anthropic의 평가 도구, 또는 Python 스크립트와 Google Sheet 한 장으로도 이 스택을 운영할 수 있습니다. 무게중심은 방법론에 있습니다.

"좋아 보이네"가 규모에서 무너지는 이유

LLM 기능을 처음 출시할 때는 "좋아 보이네"가 괜찮은 기준입니다. 프롬프트를 작성하고, 입력 열 개를 테스트해 보고, 출력이 합리적으로 보이면 배포 버튼을 누릅니다.

두 번째부터는 곤란해집니다.

LLM 출력은 설계상 비결정적입니다. Temperature 0은 분산을 줄이지만 없애지는 못합니다. 같은 모델로 같은 프롬프트를 돌려도 실행마다 미묘하게 다른 답이 나오고, 모델 버전을 바꾸면 거의 확실히 달라집니다. 그 위에 여러분도 모르는 사이에 변하는 것들이 더해집니다.

모델 드리프트(Model drift). 공급자는 동일한 이름의 모델을 업데이트합니다. 오늘의 GPT-4o는 세 달 전의 GPT-4o가 아닙니다. config 안의 문자열은 같지만 동작은 다릅니다. 알림도 오지 않습니다.
분포 변화(Distribution shift). 실제 사용자가 보내는 입력은 여러분이 테스트한 입력과 다릅니다. 더 짧은 프롬프트, 다른 언어, 이상한 포맷팅, 첨부 파일. 평가가 가장 중요해지는 곳이 바로 이 롱테일입니다.
프롬프트 엔트로피(Prompt entropy). 누군가 사용자 하나의 불만을 해결하려고 시스템 프롬프트를 손볼 때마다, 잊고 있던 다른 세 가지 사용 케이스를 망가뜨릴 위험이 생깁니다. 평가가 없다면 이런 일은 지원 티켓이 폭증할 때까지 보이지 않습니다.
검색 드리프트(Retrieval drift). RAG를 쓰고 있다면 인덱스가 끊임없이 변합니다. 파이프라인의 검색 단이 조용히 열화됩니다.

숨어 있는 비용은 팀의 시간입니다. 모든 변경은 누군가가 프롬프트를 클릭해 가며 반나절을 소모하는 일이 됩니다. 모든 모델 업데이트는 일주일짜리 "몇 개만 확인해 볼게요" 작업이 됩니다. 모든 이슈 에스컬레이션은 일회성 조사가 되는데, "이게 회귀인가, 아니면 이런 종류의 쿼리에서는 원래부터 망가져 있었나"에 답할 수 있는 사람이 없기 때문입니다.

진짜 평가는 이런 질문에 답하는 비용을 싸게 만들어 줍니다. 비용은 선불입니다. 절약은 복리로 쌓입니다.

LLM 평가 스택의 해부도

다섯 개의 레이어가 있습니다. 서로의 위에 쌓입니다. 한 레이어를 건너뛰면 그 위 레이어들은 노이즈를 점수화하게 됩니다.

Layer	Purpose	Tooling examples	Gotchas
1. 트레이스	프로덕션 실행에서 모든 입력, 출력, 도구 호출, 검색 결과, 지연, 비용 수집	Langfuse, Phoenix, OpenTelemetry exporters	너무 공격적인 샘플링, 도구 호출 페이로드 누락, 로그 내 PII
2. 오류 분석	실제 트레이스 50~100개를 오픈 코딩하고, 실패 양상을 군집화하여 오류 분류 체계 구축	Notion, Airtable, CSV	이 단계를 건너뛰는 것, 캘리브레이션 없이 한 명이 단독으로 진행
3. 골든 데이터셋	각 실패 양상과 해피 패스를 커버하는 50~100개의 손으로 라벨링된 예제	Inspect AI 데이터셋 포맷, JSONL, 자체 스키마	합성 데이터만 사용, 2단계에서 찾은 실패 양상을 커버하지 못함
4. LLM-as-judge	루브릭을 가진 점수 매기기 모델로, 인간 라벨과 85% 이상의 일치도로 검증됨	OpenAI Evals, Promptfoo, Inspect AI, 직접 구축	검증하지 않은 판정기 사용, 단일 판정기 점수화, 루브릭 드리프트
5. CI 통합	모든 PR에서 평가를 실행하고, 회귀가 발생하면 머지를 게이트하며, 열화 시 알림	GitHub Actions, GitLab CI, 커스텀 러너	너무 느린 실행, 비용 상한 부재, 판정기 모델 가격 급등

순서가 중요합니다. 어떤 실패 양상이 존재하는지(오류 분석) 먼저 알지 못하면 골든 데이터셋을 만들 수 없고, 트레이스 없이는 오류 분석을 할 수 없습니다. 라벨링된 골든 셋이 없으면 판정기를 검증할 수 없습니다. 판정기를 실제로 신뢰할 수 있게 되기 전에는 파이프라인을 CI에서 돌릴 수 없습니다.

Aakash Gupta의 Hamel/Shreya 커리큘럼 단계별 정리는 약간 다른 명명으로 같은 골격을 따라가며, 이 분야에서 합의에 가장 근접한 형태를 보여 줍니다. 이제 레이어를 하나씩 살펴보겠습니다.

1단계: 트레이스 수집

트레이스란 하나의 LLM 상호작용에 대한 전체 기록입니다. 입력과 출력만이 아니라, 그 사이에 시스템이 한 모든 일이 포함됩니다.

쓸모 있는 트레이스에는 다음이 담깁니다.

전체 메시지 이력(system prompt, user turns, assistant turns)
호출된 그대로의 모델 이름과 버전
모든 도구 호출, 그 인자, 그리고 응답
RAG의 경우: 검색 쿼리, 반환된 문서, 점수, 최종 프롬프트에 실제로 사용된 문서
토큰 수, 단계별로 분해된 지연 시간, 그리고 달러 단위 비용
사용자 세션과 다시 조인할 수 있는 요청 ID
모든 피드백 신호(좋아요, 복사 클릭, 재생성, 이탈)

원칙은 이렇습니다. 트레이스가 진실의 원본입니다. 트레이스만으로 모델이 무엇을 보고 무엇을 했는지 정확히 재구성할 수 없다면, 여러분의 평가는 추측의 하류에 있는 셈입니다.

샘플링에 대해서 말하자면, 트레이드오프는 볼륨 대 비용입니다. 트래픽이 많은 제품이라면 트레이스의 100%를 로깅하되, 전체 페이로드는 일부 샘플(5~10%)에 대해서만 보관하고 나머지는 메타데이터만 남깁니다. 오류 트레이스(도구 호출 실패, 타임아웃, 낮은 신뢰도의 검색, 부정 피드백)는 100% 로깅합니다. 그것들이 여러분의 금광입니다.

PII에 관해서는, 트레이스에 사용자 데이터가 포함될 것입니다. 다른 프로덕션 로그에 적용하는 동일한 마스킹 및 보존 규칙을 그대로 적용하세요. 대부분의 팀은 사용자 ID를 해시 처리하고, 이메일을 제거하며, 로그를 30~90일 주기로 로테이션합니다.

직접 구현한다면, LLM SDK 주변에 구조화된 JSON을 로깅 파이프라인으로 내보내는 작은 래퍼를 작성하세요. 포맷보다 항상 로깅하는 규율이 더 중요합니다.

2단계: 오류 분석(Open Coding)

모두가 건너뛰는 단계이자, 다른 모든 것이 작동하게 만드는 단계입니다.

Shreya Shankar의 연구는 질적 연구에서 사용하는 open coding이라는 기법을 빌려 옵니다. 실제 트레이스 50~100개를 들고 앉아서, 그것들을 읽고, 잘못된(또는 잘된) 점을 주석합니다. 카테고리를 미리 강요하지 않습니다. 카테고리가 데이터에서 떠오르도록 둡니다.

구체적으로는 이렇습니다.

프로덕션에서 트레이스 100개를 끌어옵니다. 무작위 샘플과 부정 피드백, 오류, 또는 높은 지연이 표시된 트레이스를 섞습니다.
스프레드시트를 엽니다. 컬럼은 trace ID, 입력 요약, 출력 요약, 문제(자유 텍스트), 심각도(1~3), 태그(처음에는 비워 둠).
각 트레이스에 대해 무엇이 잘못됐는지 평이한 말로 적습니다. "나쁜 출력"이 아니라 구체적으로 적습니다. "사용자 코드에 존재하지 않는 함수 이름을 환각함" 또는 "엉뚱한 언어로 답변함" 또는 "양호한 요청을 거절함" 같은 식으로요.
트레이스 20~30개쯤 보다 보면, 같은 문제가 반복해서 나타납니다. 그때부터 태깅을 시작하세요. 두 단어 정도의 태그면 충분합니다.
100개를 다 본 뒤에 태그들을 묶습니다. 보통 "괜찮음"을 포함해 5~15개의 뚜렷한 실패 양상이 남습니다.

이것이 여러분의 오류 분류 체계입니다. Hamel은 Field Notes on LLM Evals에서 이 순간을 막연한 우려가 검증 가능한 주장으로 바뀌는 지점이라고 묘사합니다. "봇이 가끔 환각해요"가 "변수명이 흔치 않을 때 봇이 코드 관련 쿼리의 8%에서 함수명을 환각합니다"로 바뀝니다. 그것이 평가를 작성할 수 있는 무엇입니다.

두 번째 시선이 중요합니다. 다른 누군가에게 같은 30개 트레이스를 독립적으로 코딩하게 하세요. 의견이 갈리는 지점에서 분류 체계는 모호한 상태이며, 더 날카롭게 다듬어야 합니다. 이것은 나중에 LLM 판정기에도 적용하게 될 동일한 어노테이터 간 일치도 점검입니다.

3단계: 골든 데이터셋 구축

골든 데이터셋은 여러분의 파이프라인이 평가받게 될 고정된 입력, 기대 동작, 그리고 라벨의 집합입니다. LLM을 위한 회귀 테스트 스위트라고 생각하면 됩니다.

크기: 50~100개 예제가 현실적인 출발점입니다. 10개는 너무 시끄럽고, 1,000개는 너무 비싸고 느립니다. 새로운 실패 양상을 발견하면 키워 나가되, 첫 버전은 한 사람이 오후 한 번에 모두 읽을 수 있을 만큼 작아야 합니다.

커버리지: 오류 분석에서 나온 각 실패 양상마다 최소 5~~10개의 예제가 필요합니다. 거기에 해피 패스 예제 20~~30개를 더합니다. 그리고 몇 개의 엣지 케이스(아주 긴 것, 아주 짧은 것, 비영어, 적대적인 것)도 포함합니다. arXiv 논문 Constructing Domain-Specific Evaluation Sets for LLM-as-a-judge는 커버리지 전략을 다룬 좋은 읽을거리입니다.

포함 기준은 다음과 같습니다.

합성 입력보다는 실제 사용자 입력을 우선합니다. 합성 전용은 잘 알려진 함정입니다. 사용자가 실제로 보내는 것이 아니라 여러분 팀이 작성할 법한 프롬프트처럼 보이게 되기 쉽습니다.
각 예제는 라벨링된 기대 결과를 가집니다. 자유 형식 생성에서는 그것이 단일한 기대 문자열이 아니라 루브릭("X는 반드시, Y는 절대 안 되고, 이상적으로는 Z")입니다.
각 예제는 하나 이상의 실패 양상으로 태깅됩니다.
민감 데이터는 제거됩니다.

라벨링 루브릭: "좋다"가 어떤 모습인지 적어 둡니다. 어떤 과제에서는 정확 일치(올바른 API를 호출했는가)입니다. 대부분의 경우에는 속성의 루브릭입니다: "검색된 문서 중 최소 하나는 인용해야 한다", "거절하지 않아야 한다", "사용자의 언어로 답해야 한다", "함수명을 지어내지 않아야 한다". 각 속성은 이진 검사가 됩니다.

리프레시 주기: 분기에 한 번, 50~100개의 새로운 프로덕션 트레이스를 끌어와 오픈 코딩을 반복합니다. 새 실패 양상이 추가됩니다. 더 이상 나타나지 않는 옛 양상도 그대로 둡니다(회귀 커버리지를 원하니까요). 모델이나 프롬프트가 의미 있게 바뀔 때는 비정기 리프레시를 합니다.

피해야 할 함정: 프롬프트를 작성하는 팀이 골든 데이터셋도 혼자 다 작성하지 않도록 하세요. 프롬프트의 강점에 과적합됩니다. 일상적인 프롬프트 작업 바깥에 있는 사람이 최소한 절반의 예제를 라벨링하게 하세요.

4단계: 인간 검증을 곁들인 LLM-as-Judge

단일한 정답이 없는 과제(요약, 모호한 카테고리의 분류, 자유 형식 Q&A)에서는 출력을 대규모로 채점할 방법이 필요합니다. 수동 채점은 모든 PR마다 돌릴 수 없습니다.

LLM-as-judge는 그 기법입니다. 별도의 LLM 호출을 사용해 여러분의 파이프라인 출력을 루브릭에 대비해 점수화합니다. 효과가 있습니다. Confident AI의 LLM-as-judge 방식 분석은 2025-2026년 여러 벤치마크에서 판정기-인간 일치도가 85%를 넘었다고 보고합니다. 이는 주관적인 과제에서 두 명의 인간이 서로 보이는 일치도 수준입니다. 완벽하지는 않지만, 검증을 거친다면 충분히 유용한 수준입니다.

방법론을 순서대로 따라가 보겠습니다.

판정기를 위한 루브릭을 작성하세요. "이 답변이 좋은가"가 아닙니다. 구체적으로: "답변이 제공된 문서 중 최소 하나를 인용하는가? Y/N. 답변이 거절해서는 안 될 때 거절하는가? Y/N. 답변이 사용자 코드에 없는 함수명을 지어내는가? Y/N." 이진 또는 짧은 리커트 스케일이 좋습니다. 판정기는 1~10 척도에 약합니다.
판정기 모델을 고르세요. 강한 범용 모델(GPT-4 급이나 Claude Sonnet/Opus 급)은 보통 더 작은 모델보다 성능이 좋지만, 대량 평가 실행에서는 더 저렴한 판정기도 검증만 한다면 괜찮습니다.
골든 셋을 손으로 라벨링하세요. 두 명이 독립적으로 합니다. 어노테이터 간 일치도(Cohen's kappa 또는 이진에 대한 단순 백분율 일치)를 계산하세요. 인간끼리 80~85% 이상 일치하지 않는다면 루브릭이 너무 모호합니다. 더 날카롭게 다듬으세요.
같은 셋에 판정기를 돌리세요. 판정기 라벨을 인간 라벨과 비교합니다. 판정기-인간 일치도가 80% 미만이라면 판정기를 위한 루브릭 프롬프트가 잘못됐거나 판정기 모델이 너무 약한 것입니다. 판정기 프롬프트를 반복 개선하세요.
일치도가 85%에 도달하거나 그 이상일 때만 판정기를 출시하세요. 그 미만이라면 노이즈를 자동화하는 것일 뿐입니다.

흔한 실수들입니다.

검증 없이 단일 판정기 호출을 사용하기. 일치도가 60%일 수도 있는데, 알 길이 없습니다.
생성과 판정에 같은 모델을 사용하기. 잘 알려진 자기 선호 편향이 있습니다. 가능하다면 판정기에는 다른 모델 패밀리를 사용하세요.
판정기 루브릭이 인간 루브릭과 어긋나도록 두기. 둘은 같은 프롬프트여야 합니다. 하나를 손보면 다시 검증하세요.
단일 판정기 호출을 정답으로 취급하기. 고위험 평가에서는 판정기를 세 번 독립 호출하고 다수결을 취합니다. 판정기 호출들 간의 불일치 자체가 신호입니다.

검증되고 나면, 판정기는 수천 개의 출력을 몇 분 만에 몇 달러로 점수화할 수 있습니다. 그것이 보상입니다. "릴리스 전에 평가한다"에서 "모든 PR마다 평가한다"로 옮겨가게 됩니다.

5단계: CI/CD에 연결하기

이 스택의 핵심은 누구도 평가를 기억해서 돌리지 않아도 된다는 점입니다. CI가 알아서 합니다.

작동 가능한 형태는 다음과 같습니다.

프롬프트, 모델 설정, 또는 파이프라인 코드를 건드리는 모든 PR에서: 골든 평가를 실행합니다. 어떤 지표든 임계치(예: 정확도 3퍼센트 포인트 하락, 또는 "양호한 요청을 거절하지 않아야 한다" 같은 엄격한 검사에서의 어떤 회귀)보다 떨어지면 머지를 차단합니다.
모델 버전을 올릴 때마다: 프로덕션 동등 인프라에서 전체 평가를 실행합니다. 나란히 비교합니다.
야간 스케줄로: 새로운 프로덕션 트레이스 샘플에 대해 평가를 실행합니다. 정적 골든 셋이 놓치는 분포 변화를 잡아냅니다.
비용 상한: PR당 평가 예산을 한도로 둡니다. 합리적인 기본값은 실행당 $1~$5입니다. 평가가 그보다 비싸다면, 골든 셋을 샘플링하거나 PR 시점 평가에는 더 저렴한 판정기를, 릴리스에는 완전한 판정기를 사용하세요.

잘 작동하는 패턴이 있습니다. 매 커밋마다 20~~30개 예제로 돌리는 "빠른 평가"(2분 미만)와, PR 승인과 main 머지 시점에 100~~300개 예제로 돌리는 "전체 평가"입니다. 같은 파이프라인, 다른 샘플 크기입니다.

리포팅도 중요합니다. PR 코멘트는 전체 통과율, 실패 양상별 통과율, main 대비 diff, 그리고 실패한 트레이스로 가는 링크를 보여 줘야 합니다. 이걸 로그 파일에 묻어 두지 마세요.

베이스라인 드리프트에 알림을 거세요. 야간 통과율이 5포인트 떨어지고 이틀간 그대로 머무른다면, 무언가 바뀐 것입니다(모델 업데이트, 검색 인덱스 변경, 하류 서비스 등). 평가는 여러분의 모니터링 레이어이기도 합니다.

빌더들이 계속 출시하는 안티패턴

실제 팀들에서 반복해서 나타나는 몇 가지 패턴을 짚어 둡니다.

프로덕션에 출시된 느낌 평가. 엔지니어가 출력 20개를 흘긋 보고 "출시"라고 말하면 기능이 라이브로 나갑니다. 3주 뒤, "지난주보다 나아졌는가"에 답할 수 있는 사람이 아무도 없습니다.

검증 없는 단일 판정기로 점수 매기기. 누군가 LLM-as-judge에 대해 읽고, 한 줄짜리 프롬프트("이걸 1~10점으로 평가해")를 작성해서 그 점수로 의사결정을 시작합니다. 그 점수는 노이즈입니다.

오류 분류 체계 부재. 팀이 오픈 코딩을 건너뛰었습니다. 골든 셋은 누군가의 머릿속에서 즉흥적으로 작성됐습니다. 뻔한 케이스에 과적합되고, 실제 사용자가 부딪히는 흥미로운 실패 양상은 모두 놓칩니다.

인간 일치도 점검 부재. 두 명의 인간이 라벨에 동의하지 못했다면, 판정기가 그중 한 명과 보이는 "일치도"는 무의미합니다.

합성 데이터만 사용. 골든 셋이 다른 LLM으로 생성됐습니다. 멋져 보입니다. 모든 평가를 통과합니다. 실제 사용자 입력은 LLM이 만든 입력처럼 생기지 않았기 때문에 프로덕션은 망가집니다.

모든 것을 하나의 숫자로 요약하기. "우리 평가 점수는 87%입니다." 무엇에 대해서요? 어떤 실패 양상에 걸쳐서요? 실패 양상별 통과율이 필수입니다. 집계는 정작 중요한 실패를 숨깁니다.

평가가 부수적 일거리. 지속적인 파이프라인이 아니라 분기 행사로 취급됩니다. 한 릴리스 주기 안에 낡아 버립니다. 아무도 신뢰하지 않습니다.

평가가 전무한 팀을 위한 7일 평가 플랜

제로에서 시작한다면, 작동하는 파이프라인에 도달하는 한 주를 소개합니다.

Day 1: 트레이스 수집. LLM 기능 하나를 고릅니다. 입력, 출력, 도구 호출, 있다면 검색 컨텍스트, 모델 버전, 그리고 요청 ID를 캡처하는 로깅을 추가합니다. 로그가 있는 곳으로 보냅니다. 도구는 아직 고르지 마세요. 첫 주는 JSONL 파일이면 충분합니다. 하루가 끝날 때의 목표: 프로덕션에서 100개 이상의 트레이스.

Day 2: 오픈 코딩, 1라운드. 트레이스 50개를 끌어옵니다. 한 사람이 읽습니다. 무엇이 잘못됐고 무엇이 잘됐는지 자유 텍스트로 주석합니다. 아직 분류하지 마세요. 그저 묘사하세요.

Day 3: 오픈 코딩, 2라운드. 다른 사람이 같은 50개를 합니다. 노트를 비교합니다. 패턴에서 실패 양상 분류 체계를 만듭니다. 5~12개 정도의 이름 붙은 실패 양상을 목표로 합니다. 각각의 대략적 빈도를 추정합니다.

Day 4: 골든 데이터셋 v0. 각 실패 양상과 해피 패스를 커버하는 50~80개 예제를 가져옵니다. 각각을 루브릭으로 라벨링합니다: 좋은 응답이 갖춰야 할 조건들이 무엇인지. JSONL이든 스프레드시트든 상관없지만, 버전 관리에 넣어 두세요.

Day 5: 판정기 구축. 각 루브릭 속성을 이진으로 점수화하는 판정기 프롬프트를 작성합니다. 프로덕션 모델과 다른 패밀리에서 판정기 모델을 고릅니다. 골든 셋에 돌립니다.

Day 6: 판정기 검증. 두 명의 인간이 같은 골든 셋을 같은 루브릭으로 라벨링하게 합니다. 인간-인간 일치도와 판정기-인간 일치도를 계산합니다. 판정기-인간 일치도가 80% 미만이면 판정기 프롬프트를 반복합니다. 85%에 도달하거나 6일차가 끝날 때 멈춥니다. 85%에 도달할 수 없다면 문제는 루브릭에 있습니다. 이진 질문들을 더 날카롭게 다듬으세요.

Day 7: CI 연결. 프롬프트나 파이프라인 코드를 건드리는 PR에 평가를 돌리는 GitHub Action을 작성합니다. 통과율, 실패 양상별 분해, 그리고 실패한 트레이스로 가는 링크가 담긴 코멘트를 출력합니다. 예산을 설정합니다. 회귀 임계치를 설정합니다.

주의 끝: 여러분에게는 트레이스, 분류 체계, 골든 셋, 검증된 판정기, 그리고 CI 게이트가 생겼습니다. 스택 전체입니다. 작지만, 작아야 한다는 게 핵심입니다. 여기서부터 복리로 쌓입니다.

첫 주가 지나면, 평가 시간의 대부분은 세 가지에 쓰게 됩니다: 골든 셋을 키우는 일, 모호함을 발견할 때마다 루브릭을 다듬는 일, CI가 잡아낸 회귀를 조사하는 일. 어느 것도 또 다른 큰 빌드를 요구하지 않습니다.

자주 묻는 질문

느낌 평가와 진짜 평가의 차이는 무엇인가요?

느낌 평가는 "출력 20개를 읽어 봤는데 더 좋아 보여요"입니다. 진짜 평가에는 고정된 입력 세트, 적힌 루브릭, 누가 읽느냐에 따라 달라지지 않는 점수 매기기 메커니즘, 그리고 두 실행을 비교할 방법이 있습니다. 가장 빠른 리트머스 테스트는 이것입니다. "지난주와 이번 주의 평가 점수는 얼마였고, 어떤 실패 양상이 회귀했는가"에 답할 수 없다면, 진짜 평가가 없는 것입니다.

골든 데이터셋은 얼마나 커야 하나요?

첫 버전은 50~~100개 예제입니다. 각 실패 양상을 5~~10 케이스로 커버할 만큼 크되, 한 명이 오후 한 번에 다 읽을 수 있을 만큼 작게요. 프로덕션에서 새 실패 양상을 찾을 때마다 시간이 지나면서 키워 나가세요. 성숙한 파이프라인 대부분은 200~500개 예제 선에 자리 잡습니다. 여러 개의 뚜렷한 사용 케이스에 걸쳐 평가하는 경우가 아니라면 1,000개를 넘기는 데서 추가 이득을 보는 경우는 거의 없습니다.

LLM-as-judge가 정말 인간과 일치하나요?

검증한다면 그렇습니다. Confident AI의 연구는 2025-2026년 검증된 루브릭에서 판정기-인간 일치도가 85% 이상이라고 보고합니다. 이는 두 명의 인간이 서로 동의하는 수준 정도입니다. 단서가 있습니다. 이는 판정기를 인간 라벨에 대해 먼저 보정했을 때에만 성립합니다. 어딘가의 튜토리얼에서 베껴 와 검증한 적 없는 판정기 프롬프트는 그저 의견 생성기일 뿐입니다.

전용 평가 도구가 필요한가요, 아니면 직접 만들어도 되나요?

첫 주에는 직접 만드세요. JSONL 파일, Python 스크립트, 라벨용 스프레드시트면 됩니다. 그것을 넘어서면(보통 여러 사람이 라벨링해야 하거나, 트레이스를 둘러볼 UI가 필요해질 때) 도구를 고르세요. Inspect AI, Phoenix, Promptfoo, Langfuse, 그리고 OpenAI Evals framework는 모두 같은 기본 골격을 다른 사용감으로 다룹니다. 진입 장벽은 방법론이지 도구가 아닙니다.

골든 데이터셋은 언제 다시 라벨링해야 하나요?

기본은 분기마다입니다. 모델을 바꿀 때, 프롬프트를 크게 바꿀 때, 새로운 실패 양상으로 지원 티켓이 폭증할 때, 또는 새 프로덕션 트레이스에 대한 야간 평가에서 골든 셋이 더 이상 대표성을 갖지 못한다고 드러날 때는 주기 바깥에서도 합니다.

맺는말

다음 2년의 AI 프로덕트 작업에서 승리하는 팀은 가장 영리한 프롬프트를 가진 팀이 아닙니다. 어느 화요일에든 "우리 AI 기능이 지난달보다 오늘 더 나아졌는가, 어떤 차원에서, 어떤 사용자에게 그러한가"에 답할 수 있는 팀입니다. 그것은 프롬프트의 문제가 아니라 평가의 문제입니다.

방법론은 안정화됐습니다. 트레이스, 오류 분석, 골든 데이터셋, 검증된 판정기, CI 루프. 작은 팀이라면 각각을 하루나 이틀에 만들 수 있는 다섯 개의 레이어입니다. 평가 스택을 가진 팀과 그렇지 않은 팀 사이의 격차는 빠르게 벌어지고 있습니다.

LLM 기능을 출시했는데 회귀 질문에 자신 있게 답할 수 없다면, 첫 주의 과제는 또 다른 프롬프트 손보기가 아닙니다. JSONL 파일 하나, 트레이스 쉰 개, 그리고 라벨 스프레드시트입니다. 스택의 나머지는 거기서 자연히 흘러나옵니다. 작게 시작하고, 가차 없이 검증하고, 다음 기능 전에 파이프라인부터 출시하세요.