LLM Evals FAQ: 인프라보다 에러 분석이 먼저인 이유
목차
개요
Hamel Husain과 Shreya Shankar가 AI Evals 코스를 진행하며 700명 이상의 엔지니어와 PM에게 반복해서 받은 질문을 모아 FAQ 문서로 정리했다. 2026년 7월 기준으로도 계속 갱신되고 있는 문서다.
이 문서가 다루는 주제는 파운데이션 모델 벤치마크 점수가 아니다. 내가 만든 제품이 실제 사용자에게 내보내는 응답의 품질을 어떻게 확인할 것인가에 대한 실무 답변이다.
문서 전체를 관통하는 주장은 하나로 요약된다. 평가 도구를 구매하거나 인프라를 세우기 전에, 실제 트레이스 20~50개를 사람이 직접 읽으라는 것이다. 이 과정에서 나온 실패 패턴이 곧 평가 항목이 된다.
에러 분석에서 시작하기
4단계 프로세스
문서는 에러 분석을 “가장 중요한 평가 활동”으로 규정한다. 프로세스는 네 단계로 구성된다.
| 단계 | 내용 |
|---|---|
| 데이터셋 생성 | 대표성 있는 사용자 상호작용 트레이스 수집 |
| Open Coding | 도메인 전문가가 자유 형식으로 주석 작성 |
| Axial Coding | 주석을 실패 분류 체계로 범주화 |
| 반복 개선 | 이론적 포화에 도달할 때까지 지속 |
여기서 트레이스는 단일 사용자 쿼리부터 최종 응답까지의 완전한 기록을 뜻한다. 에이전트, 도구 호출, 검색 결과를 포함한 모든 중간 단계가 들어간다.
종료 조건은 이론적 포화다. 새로운 트레이스를 20개 정도 더 봐도 새 카테고리가 나오지 않으면 그 라운드를 마친다. 최소 검토 규모는 100개 트레이스로 제시된다.
주기적 재실행 기준은 다음과 같다.
| 상황 | 권장 조치 |
|---|---|
| 신규 기능, 프롬프트 수정, 모델 교체 후 | 즉시 재실행 |
| 정기 사이클 | 2~4주마다 100개 이상 신규 트레이스 |
| 주간 루틴 | 10~20개 이상 트레이스 검토 (특이치 중심) |
문서는 실제 프로젝트에서 개발 시간의 60~80%가 에러 분석과 평가에 쓰인다고 밝힌다. 평가를 별도 항목으로 잡는 것이 아니라 개발 과정 자체로 본다는 뜻이다.
트레이스 샘플링 전략
어떤 트레이스를 볼 것인가에 대해 문서는 여러 방법을 병행하라고 권한다. 각 방법의 한계가 서로 다르기 때문이다.
| 방법 | 동작 | 한계 |
|---|---|---|
| 무작위 | 동일 확률로 선택 | 소규모 배치에서 희귀 케이스 누락 |
| 클러스터링 | 유사 콘텐츠끼리 묶음 | 특성 선택과 클러스터링 방식에 의존 |
| 데이터 분석 | 극단값 검토 | 극단값이 품질과 무관할 수 있음 |
| 분류 | 평가기나 모델로 실패 플래그 | 이미 아는 문제만 우선 노출 |
| 피드백 | 부정적 사용자 피드백 활용 | 보고되지 않은 문제 누락 |
Active Learning을 적용하는 방식도 소개된다. 클러스터링으로 묶은 뒤 각 클러스터에서 예시를 뽑고, 새로 붙인 레이블로 실패 분류 체계를 갱신하는 순환 구조다.
합성 데이터 생성
테스트 데이터를 LLM으로 만들 때는 “다양한 질문 100개 만들어줘” 식의 요청을 피하라고 한다. 대신 차원(dimension) 기반의 구조화된 접근을 권장한다.
레시피 앱을 예로 들면 식이 제한, 요리 유형, 쿼리 복잡도가 차원이 된다. 먼저 20개 정도의 튜플을 손으로 작성한다. (예: 비건 / 이탈리안 / 다단계) 그다음 두 단계로 생성한다.
- 구조화된 튜플을 생성한다.
- 각 튜플을 자연어 쿼리로 변환한다.
생성 방식은 두 가지로 나뉜다. 차원의 교차곱을 만든 뒤 필터링하면 커버리지가 완전해지고, LLM에 직접 생성시키면 더 현실적이지만 포괄성이 떨어진다. 이렇게 만든 합성 쿼리 100개를 실행한 뒤 에러 분석을 돌리는 흐름이다.
다만 합성 데이터를 신뢰하기 어려운 영역도 명시되어 있다.
| 영역 | 이유 |
|---|---|
| 법률, 의료 기록 등 도메인 특화 콘텐츠 | 복잡도가 높아 현실성 확보 어려움 |
| 저자원 언어와 방언 | 학습 데이터 부족 |
| 검증이 불가능한 경우 | 정답 확인 수단 없음 |
| 의료, 법률, 긴급 대응 등 고위험 도메인 | 오류 비용이 큼 |
| 소수 사용자 그룹 | LLM 학습 데이터의 편향이 그대로 반영됨 |
평가 설계
이진 평가와 리커트 척도
문서는 1~5점 척도 대신 통과/실패 이진 판정을 권한다. 근거는 세 가지다.
리커트 척도에서 3점과 4점의 차이는 주관적이라 어노테이터 간 일관성이 떨어진다. 통계적으로 유의미한 신호를 얻으려면 더 큰 샘플이 필요하다. 그리고 판단이 애매할 때 중간값으로 도망치는 경향이 생긴다.
이진 판정은 “이건 통과인가 실패인가”를 강제로 결정하게 만들어 사고를 명확하게 한다. 진도를 세밀하게 추적하고 싶다면 척도를 늘리는 대신 구체적 항목별 이진 검사를 여러 개 두는 방식을 쓴다. 예를 들어 “예상 사실 5개 중 4개 포함”처럼 부분 점수를 이진 검사의 집계로 표현한다.
불확실성 표현 능력을 평가할 때도 이진 구조를 쓴다. 답변 가능한 질문과 답변 불가능한 질문을 대략 1대 1로 섞어 세트를 구성한다. 답변 가능한 질문에 답하면 통과, 답변 불가능한 질문을 거절하면 통과, 답변 불가능한 질문에 꾸며낸 답을 내면 실패다.
자동 평가기를 언제 만들 것인가
모든 실패 모드에 자동 평가기를 붙일 필요는 없다고 잘라 말한다. 프롬프트를 고쳐서 사라지는 실패에는 평가기를 만들지 않는다. 프롬프트 수정 후에도 계속 남는 실패만 자동화 대상이다.
평가기의 비용은 두 계층으로 나뉜다.
| 계층 | 예시 | 비용 |
|---|---|---|
| 저비용 | 단순 assertion, 참조 기반 검사 | 낮음 |
| 고비용 | LLM-as-Judge | 레이블 100개 이상, 주간 유지보수, 정렬 작업 필요 |
LLM-as-Judge를 만들려면 인간 레이블 100개 이상과 지속적인 유지보수가 든다. 반복해서 개선할 계획이 있는 항목에만 투자하라는 것이 결론이다.
기성 평가 메트릭을 그대로 쓰는 것에 대해서는 부정적이다. 문서는 일반 평가가 시간 낭비이며 근거 없는 신뢰를 만든다고 표현한다. 에러 분석으로 실패 모드를 정의하고, 커스텀 평가기를 만든 뒤, 인간 판단과 정렬을 검증하는 순서를 권한다. 기성 메트릭은 흥미로운 트레이스를 찾는 탐색 신호 정도로만 재사용한다.
BERTScore나 ROUGE 같은 유사도 메트릭도 대부분의 LLM 출력 평가에서는 유용하지 않다고 본다. 검색이나 추천 도메인, 특히 RAG의 검색 단계 최적화에서는 여전히 쓸모가 있다.
평가 주도 개발(eval-driven development)에 대해서도 일반적으로는 회의적이다. LLM의 실패 표면은 무한하고 예측이 어렵기 때문에, 미리 평가를 쓰는 것보다 에러 분석으로 발견된 실패에 평가기를 붙이는 편이 낫다는 논리다. “경쟁사를 언급하지 않는다” 같은 명확한 제약 조건은 예외다.
평가기와 메인 작업에 같은 모델을 써도 되는지에 대해서는 대체로 가능하다고 답한다. 평가기는 생성과는 다른 작업을 수행하기 때문이다. 중요한 것은 모델의 종류가 아니라 이진 분류 작업에서 인간 판단과 높은 정렬을 달성하는지다. True Positive Rate와 True Negative Rate를 모두 높게 유지하는 것이 목표이며, 정렬이 잘 안 되면 그때 다른 모델을 검토한다.
사람과 도구
어노테이터는 한 명이면 충분하다
중소 규모 조직이라면 도메인 전문가 한 명을 “benevolent dictator”로 지정하라고 권한다. 어노테이터 간 충돌이 사라지고, 의사결정이 멈추지 않으며, 비용도 낮다. 규모가 크거나 여러 도메인을 다루면 어노테이터를 늘리되 Cohen’s Kappa로 합의도를 측정한다.
어노테이션 외주는 예외를 제외하면 큰 실수로 규정된다. 피드백 루프가 끊기고, 도메인 전문성이 없으니 표면적인 레이블만 붙고, 암묵지가 사라지며, 어노테이터 간 충돌이 늘어난다. 전화번호 식별 같은 순수 기계적 작업, 번역처럼 제품 맥락이 필요 없는 작업, 그리고 의료 콘텐츠 평가에 의대생을 고용하는 식의 외부 전문가 채용은 예외로 인정한다.
PM과 엔지니어의 역할 분담도 다룬다. 초기에는 함께 트레이스를 읽어 공유 맥락을 만든다. 엔지니어는 기술적 문제를, PM은 제품 관점의 실패를 잡아낸다. 이후에는 도메인 전문가와 PM 중심으로 옮겨간다. 질문의 형태도 “도구 호출이 성공했는가”에서 “약속이 실제로 잡혔는가” 같은 결과 중심으로 바뀐다.
LLM으로 자동화해도 되는 부분과 그렇지 않은 부분도 구분한다.
| 자동화 가능 | 자동화 금지 |
|---|---|
| 30~50개 수동 코딩 후의 Axial Coding | 초기 Open Coding |
| 주석을 실패 모드로 매핑 | 실패 분류 체계 검증 |
| 프롬프트 개선 제안 | 그라운드 트루스 레이블링 |
| 주석 데이터 분석 | 근본 원인 분석 |
프롬프트 자동 최적화 도구에도 유보적이다. 프롬프트를 직접 쓰는 행위 자체가 요구사항을 명확하게 만드는 과정이라고 본다. Open coding을 마친 뒤 LLM에게 개선안을 제안받고, 고품질 평가 세트가 갖춰진 다음에 최적화를 적용하는 순서를 권한다.
커스텀 어노테이션 UI
기성 어노테이션 도구 대신 직접 만들라고 권한다. AI 코딩 도구를 쓰면 몇 시간이면 만들 수 있고, 커스텀 도구를 가진 팀은 반복 속도가 약 10배 빠르다고 언급한다. 분산된 어노테이터 수십 명을 조율해야 하는 경우에만 기성 도구가 정당화된다.
좋은 인터페이스의 구성 요소는 다음과 같다.
| 요소 | 내용 |
|---|---|
| 지능형 트레이스 렌더링 | 이메일은 이메일 형태로, 코드는 구문 강조, 상세 정보는 접기 가능 |
| 진행도와 키보드 조작 | 진행 바(45/100), 다음 이동과 레이블 적용 핫키 |
| 클러스터링, 필터, 검색 | 메타데이터 필터, 키워드 및 의미 검색, 유사 문제 그룹화 |
| 문제 트레이스 우선순위 | 가드레일이나 CI 실패로 플래그된 항목, 빠른 액션 버튼 |
원칙은 복잡도를 늘리기 전에 최소화하는 것이다.
벤더 선택에 대해서는 특정 제품 추천이 일주일이면 무효가 된다며 조언을 아낀다. Langsmith, Arize, Braintrust를 주요 플레이어로 언급하고, 기능 목록보다 지원 품질과 사용 감각을 기준으로 고르되 커스텀 도구로 보완하는 경우가 잦다고 정리한다.
프롬프트 버전 관리는 Git 저장소를 선호한다. 프롬프트를 소프트웨어 아티팩트로 취급하면 버전 관리, 코드 리뷰, 원자적 배포가 자연스럽게 따라온다. 비기술 인력은 GitHub 웹이나 데스크톱 UI로 접근할 수 있다. 프롬프트 관리 도구는 전체 애플리케이션 코드를 실행하기 어렵다는 점이 한계로 지적된다. 도구와 RAG를 포함한 전체 기능 실험에는 Jupyter 노트북을 쓴다.
시스템 프롬프트와 사용자 프롬프트의 경계는 실험으로 정하되, 일반 지침은 다음과 같다.
| 구분 | 내용 |
|---|---|
| 시스템 | 정적 지시, 역할, 규칙, 포맷 요구사항 |
| 사용자 | 동적 콘텐츠, 예시, 작업 세부사항 |
애매하면 사용자 프롬프트에 두는 편이 이식과 디버그에 유리하다.
프로덕션과 도메인별 적용
가드레일과 평가기
가드레일과 평가기는 목적이 다르다.
| 구분 | 가드레일 | 평가기 |
|---|---|---|
| 실행 시점 | 인라인 동기 | 사후 비동기 |
| 지연 | 수 밀리초 | 제약 없음 |
| 구현 | 정규식, 블랙리스트, 스키마, 경량 분류기 | LLM-as-Judge 등 |
| 대상 | PII, 욕설, SQL 주입 등 명확한 고영향 실패 | 사실성, 완전성 등 복잡한 품질 |
| 사용자 노출 | 있음 (거짓 양성은 곧 버그) | 없음 (응답을 막지 않음) |
가드레일은 객관적 실패를 즉시 차단하고, 평가기는 주관적 기준을 모니터링하며 대시보드와 회귀 테스트에 데이터를 공급한다. 평가기를 프로덕션 출력의 자동 수정에 쓰는 것은 가능하지만 제한적이다. 임계 경로에서 감당할 만큼 빠른지, 거짓 양성과 거짓 음성 중 어느 비용이 큰지를 따져야 한다. 느리고 비결정론적인 LLM-as-Judge를 동기 가드레일로 쓰는 것은 의료 같은 고위험 도메인이 아니면 권하지 않는다.
CI와 프로덕션 모니터링의 차이도 정리되어 있다.
| 구분 | CI | 프로덕션 |
|---|---|---|
| 데이터 | 소규모 목적별 세트 (100개 이상) | 라이브 트래픽 샘플 |
| 대상 | 핵심 기능, 회귀, 알려진 엣지 케이스 | 실제 사용자 상호작용 |
| 평가기 | assertion과 결정론적 검사 선호 | LLM-as-Judge 중심 |
두 계층은 상호 보완적이다. 프로덕션 모니터링이 새 실패 패턴을 발견하면 이를 CI 데이터셋에 추가하는 순환이 만들어진다.
모델 선택에 시간을 많이 쓰지 말라는 조언도 있다. 증거 없이 모델 교체를 개선의 주축으로 삼지 말고 에러 분석을 먼저 하라는 것이다.
RAG와 에이전트 워크플로우
RAG가 죽었다는 주장에 대해서는 아니라고 답한다. 그 주장은 저급한 벡터 데이터베이스 검색을 자율 코딩 에이전트에 붙이는 방식을 비판한 것이지, 검색 강화 생성이라는 원칙 자체를 부정한 것이 아니다. 질문은 “RAG를 쓸 것인가”가 아니라 “어떻게 효과적으로 검색할 것인가”다. 현대적 접근은 벡터 검색과 에이전트 탐색을 병행하며, 키워드와 임베딩과 LLM 필터링을 섞어 애플리케이션별로 실험하는 쪽을 권한다.
RAG 평가는 두 구성 요소를 분리한다.
| 구성 요소 | 접근 |
|---|---|
| 검색 | 정보 검색 문제로 취급, Recall@k / Precision@k / MRR 사용 |
| 생성 | 에러 분석 후 인간 레이블, LLM-as-Judge 구축, 정렬 검증 |
검색 평가용 데이터셋은 역방향 합성으로 만든다. 문서에서 사실을 추출한 뒤 그 사실을 묻는 질문을 생성해 문서와 쿼리 쌍을 구성하는 방식이다. Jason Liu의 6 RAG Evals 프레임워크가 참고로 제시되는데, Tier 1은 전통적 IR 메트릭이고 Tier 2와 3은 질문-컨텍스트-답변 관계의 관련성, 충실성, 직접성을 다룬다.
에러 분석은 여기서도 도메인 고유의 실패를 드러낸다. 약물 용량에서 소아와 성인을 구분하지 못하거나, 법률 질의에서 관할권을 혼동하는 식이다.
문서 처리의 청크 크기는 RAG의 청크 크기와 목적이 다르다. RAG는 검색 최적화가 목표이고, 문서 처리는 추론 효과가 목표다.
| 작업 유형 | 권장 청크 | 근거 |
|---|---|---|
| 고정 출력 (계약서의 페널티 조항 찾기) | 대형 | 답이 든 청크를 쪼개지 않아 맥락 단편화 회피 |
| 확장 출력 (섹션별 요약, 불만 전체 나열) | 소형 | 논리 품질과 완전성 보존, map-reduce 방식 집계 |
대형 청크는 무관한 텍스트가 방해가 되고 긴 입력의 중간 부분에서 주의가 떨어지는 문제가 있다. 청크 크기를 하이퍼파라미터로 취급하되, 비용과 지연이 병목이라면 전처리나 경량 검색을 먼저 손대라고 조언한다. 콘텐츠 경계(단락, 섹션, 장)를 존중하는 것도 기본 원칙이다.
다중 턴 대화 디버깅은 단순하게 시작한다. 전체 대화가 사용자 목표를 충족했는지를 통과/실패로 판정한 뒤, 실패한 트레이스만 깊이 파고든다. 주석은 첫 상류 실패에만 붙인다. 이후 실패는 대부분 연쇄 반응이기 때문이다. 경험이 쌓이면 독립적인 실패 모드를 함께 표시해 속도를 높인다.
테스트 케이스는 다른 LLM으로 현실적인 다중 턴을 시뮬레이션하거나, N-1 테스팅을 쓴다. 실제 대화의 앞 N-1턴을 그대로 가져오고 다음 턴만 테스트하는 방식이 완전 합성보다 낫다는 것이다.
에이전트 워크플로우 평가는 두 단계로 나뉜다. 먼저 블랙박스로 보고 사용자 목표를 달성했는지 종단간 성공을 판정한다. 에러 분석으로 가장 자주 실패하는 지점이 드러나면 단계별 진단으로 넘어간다.
| 진단 항목 | 질문 |
|---|---|
| 도구 선택 | 적절한 도구를 골랐는가 |
| 파라미터 추출 | 완전하고 올바른 형식으로 뽑았는가 |
| 오류 처리 | 빈 결과나 API 실패에서 복구했는가 |
| 맥락 보존 | 이전 제약 조건을 유지했는가 |
| 효율성 | 단계 수, 소요 시간, 토큰 수 |
| 목표 체크포인트 | 장기 워크플로우의 주요 마일스톤 통과 여부 |
여기서 유용한 도구가 전환 실패 매트릭스다. 마지막으로 성공한 상태와 처음 실패가 발생한 위치를 교차 집계해 핫스팟을 찾는다.
1
2
3
마지막 성공 상태 -> 첫 실패 위치 실패 수
GenSQL -> ExecSQL 12 (핫스팟)
DecideTool -> PlanCal 2
이 표가 있으면 디버깅 노력을 어디에 집중할지 데이터로 결정할 수 있다.
인간 인수인계가 있는 시스템은 AI가 사람에게 넘기는 시점이 아니라 최종 해결까지를 하나의 여정으로 캡처한다. 인수 결정과 그 이유, 전달된 맥락, 대기 시간, 사람의 행동, 최종 해결, 맥락이 충분했는지를 모두 로깅한다. 개선 방향은 인수 실행 자체를 개선하는 것과 인수율을 줄이는 것 두 갈래다.
복잡한 다단계 워크플로우는 트리거부터 최종 비즈니스 결과까지 전 구간을 로깅한다. 메트릭은 최종 비즈니스 결과의 통과/실패와 단계 수, 소요 시간, 리소스 같은 프로세스 지표로 이원화한다. 에러 분석은 초기, 중간, 후기 단계로 나눠 수행하며 초기 단계의 영향이 후기보다 크다.
결론
이 FAQ의 권고사항은 다음과 같이 압축된다.
| 항목 | 권고 |
|---|---|
| 시작점 | 인프라가 아니라 에러 분석 |
| 어노테이터 | 도메인 전문가 1명 중심 |
| 판정 방식 | 이진 통과/실패 |
| 도구 | 커스텀 어노테이션 UI 구축 |
| 메트릭 | 기성 일반 메트릭 대신 도메인별 커스텀 |
| 프롬프트 | Git에 소프트웨어 아티팩트로 저장 |
| 외주 | 원칙적으로 금지 |
| 합성 데이터 | 무작위가 아닌 차원 기반 |
| 모델 선택 | 증거가 있을 때만 |
| 설득 | 방법론이 아니라 결과 수치로 |
팀에 평가 투자를 설득하려면 방법론을 설명하지 말고 데이터로 말하라고 조언한다. 실제 사용자 대화 50~100개를 검토해 상위 실패 모드를 목록화하고, “프로덕션 이슈 47건을 사전에 잡았다” 같은 구체적 수치를 제시하는 방식이다.
모델이 계속 좋아지면 이런 작업이 필요 없어지는지에 대해서는 아니라고 답한다. 모델이 완벽해져도 올바른 문제를 풀고 있는지는 별도로 검증해야 한다. 체계적 에러 분석, 도메인별 테스트, 모니터링의 필요성은 모델 성능과 독립적으로 남는다.