Hamel Husain블로그
LLM 평가의 모든 것: 기초부터 심화까지 완벽 가이드
인기 강좌 'AI Evals'에서 자주 나온 질문들을 바탕으로 정리한 LLM 평가 종합 가이드입니다. 기초 개념부터 심화 주제까지 폭넓게 다룹니다.
오디오 버전(AI 내레이션)을 선호하시는 분은 여기에서 재생할 수 있습니다.
시작하기 & 기본 개념
Q: LLM 평가란 무엇인가요?
제품 맞춤형 LLM 평가(파운데이션 모델 벤치마크가 아닌)가 처음이라면 다음 글을 먼저 참고하세요: 1편, 2편, 3편. 이미 기본 개념을 알고 계시다면 이어서 읽어 주세요.
목차:
- 왜 평가가 필요한가
- 빠른 반복 == 성공
- 사례 연구: Lucy, 부동산 AI 어시스턴트
- 평가의 유형
- 레벨 1: 유닛 테스트
- 레벨 2: 사람 & 모델 평가
- 레벨 3: A/B 테스트
- RAG 평가
- 평가 시스템이 열어주는 부가 역량
- 파인튜닝
- 합성 데이터 생성 & 큐레이션
- 디버깅
비즈니스 성과로 이어지는 LLM-as-a-Judge 만들기
목차:
- 문제: AI 팀은 데이터의 바다에 빠져 있다
- 1단계: 핵심 도메인 전문가 찾기
- 2단계: 데이터셋 만들기
- 3단계: 도메인 전문가에게 코멘트 포함 합격/불합격 판정 맡기기
- 4단계: 오류 수정
- 5단계: LLM-as-a-Judge를 반복적으로 구축
- 6단계: 오류 분석 수행
- 7단계: 필요시 전문 LLM Judge 추가 구축
- 비평 쉐도잉 요약
- 참고 자료
목차:
- 오류 분석이 최고 ROI 개선점을 꾸준히 드러내는 이유
- 단순한 데이터 뷰어가 AI에 대한 가장 중요한 투자인 이유
- 엔지니어뿐 아니라 도메인 전문가에게도 AI 개선 권한을 부여하는 방법
- 합성 데이터가 생각보다 효과적인 이유
- 평가 시스템에 대한 신뢰를 유지하는 방법
- AI 로드맵에 기능이 아니라 실험 횟수를 기준으로 삼아야 하는 이유
Q: 트레이스란 무엇인가요?
트레이스(Trace)란 사용자의 최초 질의부터 최종 응답까지 발생하는 모든 액션, 메시지, 도구 호출, 데이터 검색 등을 기록한 완전한 로그입니다. 세션 내 모든 에이전트, 도구, 시스템 구성 요소를 아우르며, 여러 사용자 메시지, 어시스턴트 응답, 검색된 문서, 중간 도구 인터랙션까지 포함합니다.
용어 관련 참고: 옵저버빌리티 벤더마다 트레이스와 스팬의 정의가 다릅니다. Alex Strick van Linschoten의 분석에서 이러한 차이를 잘 정리하고 있습니다(아래 스크린샷 참고):
Q: 최소 실행 가능한 평가 환경(MVP)은 어떻게 구성하나요?
인프라가 아니라 오류 분석부터 시작하세요. 중요한 변경을 가할 때마다 30분 동안 LLM 출력 20~50개를 직접 검토합니다. 사용자를 잘 이해하는 도메인 전문가 한 명을 품질 판단의 최종 결정권자, 즉 "선의의 독재자(benevolent dictator)"로 지정하세요.
가능하다면 노트북을 활용해 트레이스를 검토하고 데이터를 분석하세요. 노트북은 평가에 가장 효과적인 도구라고 생각합니다. 임의의 코드를 작성하고, 데이터를 시각화하며, 빠르게 반복할 수 있기 때문입니다. 이 영상에서 보듯, 노트북 안에서 커스텀 어노테이션 인터페이스를 직접 만들 수도 있습니다.
Q: 개발 예산 중 평가에 얼마나 배분해야 하나요?
평가는 별도의 예산 항목이 아니라 개발 프로세스의 일부라는 점을 인식하는 것이 중요합니다. 디버깅이 소프트웨어 개발의 일부인 것과 같은 이치입니다.
오류 분석은 항상 수행해야 합니다. 오류 분석 중 발견되는 문제 대부분은 즉시 수정할 수 있는 단순한 버그입니다. 이런 수정은 별도의 평가 인프라가 필요 없으며, 그냥 개발의 일부일 뿐입니다.
자동 평가기를 구축할지 여부는 비용 대비 효과 분석으로 판단합니다. 간단한 어서션이나 정규식으로 잡을 수 있는 오류라면 비용이 미미하므로 그만한 가치가 있습니다. 하지만 LLM-as-Judge 평가기를 정렬해야 한다면, 해당 실패 유형이 그 투자를 정당화할 만큼 중요한지 먼저 따져 보세요.
저희가 참여한 프로젝트에서는 개발 시간의 60~80%를 오류 분석과 평가에 투입했습니다. 자동 검증을 구축하는 것보다 실패를 이해하는 데(즉, 데이터를 직접 들여다보는 데) 대부분의 노력이 들어갈 것으로 예상하세요.
높은 평가 통과율에 집착하지 마세요. 평가를 100% 통과한다면, 시스템을 충분히 어렵게 시험하지 않는 것일 수 있습니다. 70% 통과율이 오히려 애플리케이션을 실질적으로 스트레스 테스트하는 더 의미 있는 평가를 나타낼 수도 있습니다. 지표를 좋게 만드는 평가가 아니라, 실제 문제를 잡아내는 평가에 집중하세요.
Q: AI가 이렇게 빠르게 변하는데, 현재의 평가 방법론이 5~10년 뒤에도 유효할까요?
그렇습니다. 모델이 완벽해지더라도, 올바른 문제를 해결하고 있는지 검증하는 작업은 여전히 필요합니다. 체계적인 오류 분석, 도메인 특화 테스트, 모니터링의 필요성은 사라지지 않습니다.
오늘날의 프롬프트 엔지니어링 기법은 시대에 뒤처질 수 있지만, 실패 유형을 이해해야 할 필요성은 변하지 않습니다. 또한 LLM은 사용자의 마음을 읽을 수 없으며, 연구 결과에 따르면 사람들은 LLM의 실제 동작을 관찰해야 비로소 자신의 요구사항을 명확하게 표현할 수 있습니다.
이 논의에 대한 심층적 관점은 다음 두 가지 시각을 비교해 보세요: "모델이 곧 제품이다" vs "모델은 제품이 아니다".
"모델이 곧 제품이다":
"모델은 제품이 아니다":
Q: 팀에게 평가 투자의 필요성을 어떻게 설득하나요?
"평가(Evals)"라는 개념을 팔려고 하지 마세요. 대신, 데이터를 직접 들여다봤을 때 무엇이 보이는지를 보여 주세요.
먼저 직접 오류 분석을 수행하세요. 실제 사용자 대화 50~100건을 살펴보고, 제품이 실패하는 가장 흔한 패턴을 찾아내세요. 이 발견을 데이터 기반 스토리로 구성합니다.
팀에 다음을 제시하세요:
- 발견한 주요 실패 유형 목록
- 고영향 오류의 발생 빈도를 보여주는 지표
- 사용자가 제품과 상호작용하는 예상치 못한 방식
- 발견해서 수정한 버그 보고서 — "프로덕션 장애를 사전에 방지한 사례"로 프레이밍
이런 접근 방식이 신뢰를 쌓습니다. 대시보드와 지표만 보여주지 말고, 데이터에서 무엇을 발견했는지 이야기로 풀어 주세요. 발견 내용을 설명하면, 팀은 자연스럽게 배우게 되고 즉각적인 가치를 얻습니다. 문제를 수정했다면, 해당 오류 유형의 발생률이 얼마나 낮아졌는지를 보여 주세요. 머지않아 팀이 그 성과를 보고 "어떻게 한 거야?"라고 물어올 것입니다. 방법론이 아니라 결과가 대화를 이끌게 하세요.
이는 기존 머신러닝 프로젝트와 비슷합니다. 성과가 불확실하고 진전이 실험의 반복에 의해 좌우되기 때문입니다. 이런 상황에서는 각 실험에서 얻은 인사이트를 공유해 진척 상황을 보여주고, 지속적인 투자를 이끌어내는 것이 중요합니다.
오류 분석 & 데이터 수집
Q: LLM 평가에서 "오류 분석"이 왜 그토록 중요하고, 어떻게 수행하나요?
오류 분석은 평가에서 가장 중요한 활동입니다. 어떤 평가를 만들어야 하는지를 결정하는 출발점이기 때문입니다. 오류 분석을 통해 애플리케이션과 데이터 고유의 실패 유형을 식별할 수 있습니다. 절차는 다음과 같습니다:
1. 데이터셋 구성
사용자와 LLM 간 상호작용의 대표적인 트레이스를 수집합니다. 데이터가 아직 없다면 합성 데이터를 생성하여 시작할 수 있습니다.
2. 개방 코딩(Open Coding)
사람 어노테이터(이상적으로는 선의의 독재자)가 트레이스를 검토하며 발견한 문제를 자유롭게 메모합니다. 이 과정은 "저널링"과 비슷하며, 질적 연구 방법론에서 차용한 것입니다. 처음에는 트레이스에서 처음 발견되는 실패에 집중하는 것이 좋습니다. 상위 오류가 하위 문제를 연쇄적으로 일으키기 때문입니다. 물론 독립적인 실패를 모두 태깅할 수 있다면 그렇게 해도 됩니다. 이 단계는 반드시 도메인 전문가가 수행해야 합니다.
3. 축 코딩(Axial Coding)
자유 형식 메모를 "실패 분류 체계"로 범주화합니다. 즉, 유사한 실패들을 묶어 고유한 카테고리로 분류하는 것입니다. 이 단계가 가장 핵심입니다. 마지막으로 각 카테고리별 실패 건수를 집계합니다. 이 단계에서는 LLM의 도움을 받을 수 있습니다.
4. 반복 개선
이론적 포화(theoretical saturation)에 도달할 때까지, 즉 새로운 트레이스에서 더 이상 새로운 실패 유형이나 정보가 나오지 않을 때까지 반복합니다. 경험적으로 최소 100건의 트레이스를 검토하는 것을 목표로 삼으세요.
이 과정은 주기적으로 다시 수행해야 합니다. 클러스터링, 사용자 피드백 기준 정렬, 높은 확률의 실패 패턴 기준 정렬 등 더 효율적으로 데이터를 샘플링하는 고급 방법도 있습니다. 시간이 지나면 데이터에서 실패를 찾아내는 감각이 자연스럽게 길러집니다.
오류 분석을 건너뛰지 마세요. 오류 분석이 있어야 개발하는 평가 지표가 실제 애플리케이션 동작에 기반하게 되며, 대부분의 플랫폼이 유도하는 비생산적인 범용 지표를 피할 수 있습니다. 오류 분석의 효과를 보여주는 사례는 이 영상이나 이 블로그 글에서 확인하세요.
수강생 중 한 분인 Pawel Huryn이 오류 분석 프로세스를 시각화한 자료입니다. 전체 평가 프로세스 내에서의 위치도 함께 확인할 수 있습니다:
Q: 사용자 피드백 외에 문제 있는 트레이스를 찾아내는 방법은?
사용자 피드백은 문제 트레이스를 좁히는 좋은 방법이지만, 다른 방법도 유용합니다. 보완적인 접근법 세 가지를 소개합니다:
랜덤 샘플링으로 시작
가장 단순한 방법은 트레이스를 무작위로 샘플링해 검토하는 것입니다. 문제가 거의 없다면 스트레스 테스트로 전환하세요. 프롬프트 제약 조건을 의도적으로 시험하는 쿼리를 만들어 AI가 규칙을 제대로 따르는지 확인합니다.
기존 평가를 초기 스크리닝에 활용
기존 평가 결과를 활용해 문제 트레이스와 잠재적 이슈를 찾아냅니다. 이를 바탕으로 오류 분석부터 시작하는 일반적인 평가 프로세스를 진행하면 됩니다.
효율적인 샘플링 전략 활용
더 정교한 트레이스 탐색을 위해서는 이상치 탐지, 지표 기반 정렬, 층화 샘플링을 활용하세요. 범용 지표도 탐색 신호로 활용할 수 있습니다. 직접 품질을 측정하지 못하더라도, 검토할 만한 트레이스를 식별하는 데는 충분합니다.
Q: 프로덕션 시스템에서 오류 분석을 얼마나 자주 재수행해야 하나요?
중요한 변경이 있을 때마다 오류 분석을 재수행하세요. 새 기능 추가, 프롬프트 수정, 모델 교체, 주요 버그 수정 등이 이에 해당합니다. 유용한 기준은 리뷰 주기마다 최소 100건 이상의 새 트레이스를 검토하는 것을 목표로 삼는 것입니다. 실무에서 관찰한 일반적인 리뷰 주기는 2~4주입니다. 효율적인 트레이스 샘플링 방법은 이 FAQ를 참고하세요.
대규모 분석 사이에는 주 10~20건의 트레이스를 검토하되, 이상치에 집중하세요. 비정상적으로 긴 대화, 재시도가 여러 번 발생한 세션, 자동 모니터링에 플래그된 트레이스 등이 대상입니다. 시스템 안정성과 사용량 증가에 따라 빈도를 조절하세요. 신규 시스템은 실패 패턴이 안정화될 때까지 주 단위 분석이 필요합니다. 안정된 시스템은 사용 패턴에 변화가 없다면 월 1회 분석으로 충분할 수 있습니다. 장애 발생, 사용자 불만 급증, 지표 드리프트가 있을 때는 반드시 분석하세요. 사용량이 확대되면 새로운 엣지 케이스가 나타납니다.
Q: 합성 데이터를 생성하는 가장 좋은 방법은?
흔한 실수는 LLM에게 아무 구조 없이 "give me test queries" 하라고 프롬프트하는 것입니다. 결과적으로 범용적이고 반복적인 출력만 나옵니다. 차원(dimension)을 활용한 구조화된 접근이 훨씬 더 나은 합성 데이터를 만들어 줍니다.
먼저 차원을 정의합니다. 차원이란 사용자 쿼리의 다양한 측면을 설명하는 카테고리입니다. 각 차원은 사용자 행동의 한 가지 변이 요소를 포착합니다. 예시:
- 레시피 앱의 경우, 식이 제한(vegan, gluten-free, none), 요리 유형(Italian, Asian, comfort food), 쿼리 복잡도(simple request, multi-step, edge case) 같은 차원을 설정할 수 있습니다.
- 고객 지원 봇의 경우, 문의 유형(billing, technical, general), 고객 감정(frustrated, neutral, happy), 이전 맥락(new issue, follow-up, resolved) 같은 차원을 사용할 수 있습니다.
실패 가설에서 출발하세요. 실패 유형에 대한 감이 없다면, 직접 애플리케이션을 충분히 사용해 보거나 지인에게 사용을 부탁하세요. 그 후 예상되는 실패를 겨냥한 차원을 선택합니다.
먼저 튜플을 수작업으로 작성합니다. 각 차원에서 하나씩 값을 골라 20개의 구체적 조합을 직접 만드세요. 예: (Vegan, Italian, Multi-step). 이 수작업은 문제 공간을 이해하는 데 큰 도움이 됩니다.
2단계 생성으로 확장합니다:
- 구조화된 튜플 생성: LLM으로 (Gluten-free, Asian, Simple) 같은 추가 조합을 생성
- 튜플을 쿼리로 변환: 별도의 프롬프트에서 각 튜플을 자연어로 변환
이렇게 분리하면 반복적인 표현을 피할 수 있습니다. (Vegan, Italian, Multi-step) 튜플은 다음과 같이 변환됩니다: "I need a dairy-free lasagna recipe that I can prep the day before."
생성 방식
튜플을 생성하는 방법은 두 가지입니다:
교차곱 후 필터링: 모든 차원 조합을 생성한 뒤 LLM으로 필터링합니다. 엣지 케이스를 포함한 완전한 커버리지를 보장합니다. 대부분의 조합이 유효할 때 적합합니다.
LLM 직접 생성: LLM에게 튜플을 직접 생성하게 합니다. 더 현실적이지만, 범용적 출력에 치우치고 희귀 시나리오를 놓치는 경향이 있습니다. 유효하지 않은 조합이 많을 때 적합합니다.
명백한 문제부터 수정하세요. 즉시 고칠 수 있는 문제를 위해 합성 데이터를 생성하지 마세요. 프롬프트에 식이 제한 관련 내용이 없다면, 특수 테스트 쿼리를 만들기보다 프롬프트 자체를 먼저 수정하세요.
튜플과 프롬프트를 충분히 다듬은 후, 이 합성 쿼리를 실제 시스템에 통과시켜 전체 트레이스를 캡처하세요. 오류 분석을 위해 100건의 트레이스를 샘플링합니다. 이 정도면 직접 검토하며 실패 패턴을 파악하기에 충분하면서도 부담되지 않는 양입니다.
Q: 합성 데이터가 신뢰할 수 없는 경우가 있나요?
네, 합성 데이터가 오히려 잘못된 결론을 유도하거나 문제를 가릴 수 있습니다. 적절한 경우의 합성 데이터 생성법은 합성 데이터를 생성하는 가장 좋은 방법은?을 참고하세요.
합성 데이터가 효과적이지 않은 대표적인 경우:
복잡한 도메인 특화 콘텐츠: LLM은 법률 문서, 의료 기록, 기술 양식 등 전문 문서의 구조, 뉘앙스, 특이점을 놓치는 경우가 많습니다. 실제 예시 없이는 중요한 엣지 케이스가 누락됩니다.
저자원 언어 또는 방언: 저자원 언어나 방언의 경우, LLM이 생성한 샘플은 비현실적인 경우가 많습니다. 이를 기반으로 한 평가는 실제 성능을 반영하지 못합니다.
검증이 불가능한 경우: 도메인 복잡성이나 정답 데이터(ground truth) 부재로 합성 샘플의 현실성을 확인할 수 없다면, 정확한 평가를 위해 실제 데이터가 필수적입니다.
고위험 도메인: 의료, 법률, 긴급 대응 등 고위험 도메인에서는 합성 데이터에 미묘한 차이와 엣지 케이스가 빠지기 쉽습니다. 이런 분야의 오류는 심각한 결과를 초래하며, 수작업 검증도 어렵습니다.
과소 대표 사용자 그룹: 과소 대표 사용자 그룹의 경우, LLM이 해당 맥락, 가치관, 과제를 잘못 표현할 수 있습니다. 합성 데이터가 LLM 학습 데이터의 편향을 오히려 강화할 수 있습니다.
Q: 다양한 유형의 사용자 쿼리를 처리하는 시스템은 어떻게 평가하나요?
복잡한 애플리케이션은 "반품 정책이 뭔가요?"부터 "이 조건에 맞는 제품의 지역별 가격 추세를 비교해 주세요"까지 매우 다양한 쿼리 패턴을 처리합니다. 쿼리 유형마다 시스템의 서로 다른 역량을 시험하기 때문에 평가 기준 설계가 혼란스러워질 수 있습니다.
오류 분석이면 충분합니다. 평가 전략은 사전에 정한 쿼리 분류가 아니라, 관찰된 실패 패턴(즉, 오류 분석)에서 도출되어야 합니다. 상상할 수 있는 모든 쿼리 유형을 다루는 거대한 평가 매트릭스를 만들기보다, 시스템의 실제 동작을 기준으로 평가 노력을 집중하세요.
오류 분석을 진행하다 보면, 특정 쿼리 카테고리들이 동일한 실패 패턴을 공유하는 것을 발견하게 됩니다. 예를 들어, 시간적 추론이 필요한 쿼리는 단순 조회든 복잡한 집계든 관계없이 어려움을 겪을 수 있습니다. 마찬가지로 여러 소스의 정보를 결합해야 하는 쿼리도 일관된 방식으로 실패할 수 있습니다. 오류 분석에서 발견된 이런 패턴이 평가 우선순위를 정하는 기준이 되어야 합니다. 쿼리 카테고리가 실패를 묶는 적절한 방법일 수도 있지만, 데이터를 분석하기 전에는 알 수 없습니다.
기본적인 오류 분석의 실제 적용 사례는 이 영상에서 확인할 수 있습니다.
Q: 프로덕션 트레이스를 효율적으로 샘플링하려면 어떻게 해야 하나요?
트레이스를 무작위로 검토하는 것은 번거롭습니다. 대부분의 트레이스에 오류가 없기 때문입니다. 아래 샘플링 전략을 활용하면 문제가 있을 가능성이 높은 트레이스를 효율적으로 찾을 수 있습니다:
- 이상치 탐지: 응답 길이, 지연 시간, 도구 호출 횟수 등 임의의 지표로 정렬하고 극단값을 검토합니다.
- 사용자 피드백 신호: 부정적 피드백, 지원 티켓, 에스컬레이션이 있는 트레이스를 우선 검토합니다.
- 지표 기반 정렬: 범용 지표도 흥미로운 트레이스를 찾는 탐색 신호로 활용할 수 있습니다. 높은 점수와 낮은 점수 양쪽을 모두 확인하고 탐색 단서로 삼으세요. 발견한 내용을 바탕으로 해당 실패 유형에 맞는 커스텀 평가기를 구축할 수 있습니다.
- 층화 샘플링: 주요 차원(사용자 유형, 기능, 쿼리 카테고리)별로 트레이스를 그룹화하고 각 그룹에서 샘플링합니다.
- 임베딩 클러스터링: 쿼리의 임베딩을 생성하고 클러스터링하여 자연스러운 그룹을 파악합니다. 각 클러스터에서 비례 샘플링하되, 엣지 케이스를 포착하기 위해 소규모 클러스터는 과다 샘플링합니다. 클러스터링에 정답은 없습니다. 수동 검토로는 놓칠 수 있는 패턴을 발견하기 위한 탐색 기법입니다.
샘플링 방법이 정교해지면, 이러한 기법을 어노테이션 도구 설계에 반영할 수 있습니다.
👉 AI 평가에 대해 더 알고 싶으신가요? AI Evals 강좌를 확인해 보세요. 실시간 코호트 방식으로, 실습과 오피스 아워가 함께 제공됩니다. 독자분들을 위한 25% 할인 코드도 준비했습니다. 👈
평가 설계 & 방법론
Q: 1~5점 척도(리커트 척도) 대신 이진(합격/불합격) 평가를 권장하는 이유는?
엔지니어들은 흔히 리커트 척도(1~5점)가 이진 평가보다 더 많은 정보를 제공해 점진적 개선을 추적할 수 있다고 생각합니다. 하지만 실제로는 이 추가적 복잡성이 해결하는 것보다 더 많은 문제를 만들어 냅니다.
이진 평가는 더 명확한 사고와 일관된 라벨링을 유도합니다. 리커트 척도는 상당한 문제를 수반합니다. 인접 점수(예: 3점과 4점)의 차이가 주관적이고 어노테이터마다 일관성이 없으며, 통계적 차이를 감지하려면 더 큰 샘플이 필요하고, 어노테이터가 어려운 판단을 피하려 중간값을 선택하는 경향이 있습니다.
이진 선택지는 불확실성을 중간값에 숨기지 않고 명확한 판단을 내리게 만듭니다. 오류 분석 시에도 이진 판단이 훨씬 빠릅니다. 3점인지 4점인지 고민하는 데 시간을 낭비하지 않아도 됩니다.
점진적 개선을 추적하고 싶다면, 척도 대신 특정 세부 항목별 이진 검증을 적용하는 것이 좋습니다. 예를 들어 사실 정확도를 1~5점으로 평가하는 대신, "예상 사실 5개 중 4개 포함" 여부를 개별 이진 검증으로 추적할 수 있습니다. 진척도 측정 능력은 유지하면서 명확하고 객관적인 기준을 유지할 수 있습니다.
먼저 이진 라벨로 '나쁜 것'이 어떤 것인지 파악하세요. 숫자 라벨은 고급 기법이며 대부분의 경우 불필요합니다.
Q: 평가 주도 개발(Eval-Driven Development)을 실천해야 하나요?
일반적으로는 아닙니다. 평가 주도 개발(기능 구현 전에 평가기를 먼저 작성하는 방식)은 매력적으로 들리지만, 실제로는 해결하는 것보다 더 많은 문제를 만듭니다. 전통적인 소프트웨어는 실패 유형이 예측 가능하지만, LLM은 잠재적 실패의 범위가 무한합니다. 무엇이 깨질지 미리 예측할 수 없습니다.
더 나은 접근 방식은 오류 분석부터 시작하는 것입니다. 상상 속의 오류가 아니라, 실제로 발견한 오류에 대해 평가기를 작성하세요. 이렇게 하면 "무엇을 평가할지"에 막혀 진행이 안 되는 것도, 실제 시스템 품질에 영향이 없는 지표에 노력을 낭비하는 것도 방지할 수 있습니다.
예외: 성공 기준이 명확히 정해진 특정 제약 조건에는 평가 주도 개발이 효과적일 수 있습니다. "경쟁사를 절대 언급하지 않는다"를 추가한다면, 이 평가기를 먼저 작성하는 것은 합리적입니다.
가장 중요한 것은, 평가기를 구현하기 전에 항상 비용 대비 효과 분석을 수행하는 것입니다. 해당 실패 유형이 투자를 정당화하는지 자문하세요. 오류 분석을 통해 사용자에게 실제로 중요한 실패가 무엇인지 드러납니다.
Q: 발견한 모든 실패 유형에 자동 평가기를 만들어야 하나요?
프롬프트를 수정한 뒤에도 지속되는 실패에 자동 평가기를 집중하세요. 많은 팀이 짧은 응답, 특정 포맷, 단계별 추론 등 한 번도 명시하지 않은 선호사항을 LLM이 충족하지 못한다는 사실을 발견합니다. 복잡한 평가 인프라를 구축하기 전에, 이런 명백한 부족함부터 먼저 해결하세요.
평가기 유형별 비용 구조를 고려하세요. 단순 어서션과 참조 기반 검증(정답과 비교)은 구축·유지 비용이 낮습니다. 반면 LLM-as-Judge 평가기는 100건 이상의 라벨링 데이터, 주간 유지보수, 개발자·PM·도메인 전문가 간의 협업이 필요합니다. 이 비용 차이가 평가 전략의 방향을 결정해야 합니다.
비용이 높은 평가기는 반복적으로 개선해야 할 문제에만 적용하세요. LLM-as-Judge는 상당한 오버헤드가 따르므로, 사소하게 고칠 수 있는 문제가 아닌 지속적인 일반화 실패에 활용하세요. 가능한 한 코드 기반의 저비용 검증(정규식 패턴, 구조 검증, 실행 테스트)부터 시작하세요. 단순한 규칙으로 포착할 수 없는 주관적 품질에만 복잡한 평가를 사용합니다.
Q: "기성" 평가 지표를 사용해도 되나요?
아니요. 범용 평가는 시간 낭비이며 거짓 확신을 만들어 냅니다. (탐색 목적으로 사용하는 경우는 예외입니다.)
한 강사의 말을 인용합니다:
"이런 기성 평가를 사용해서 얻는 것은, 그것이 실제로 뭘 측정하는지 모른다는 사실뿐입니다. 잘 되면 시간 낭비이고, 최악의 경우 근거 없는 확신이라는 환상을 만들어 냅니다."1
범용 평가 지표는 어디에나 있습니다. 평가 라이브러리마다 유용성(helpfulness), 일관성(coherence), 품질(quality) 같은 점수를 제공하며 손쉬운 평가를 약속합니다. 이런 지표는 여러분의 사용 사례와 무관할 수 있는 추상적 속성을 측정합니다. 이런 지표에서 좋은 점수를 받았다고 시스템이 제대로 작동하는 것은 아닙니다.
대신, 오류 분석을 통해 실패를 이해하세요. 실제 문제에 기반한 이진 실패 유형을 정의하세요. 해당 실패에 맞는 커스텀 평가기를 만들고 사람의 판단과 대조해 검증하세요. 본질적으로, 이것이 평가의 전체 프로세스입니다.
숙련된 실무자도 이런 지표를 사용하긴 합니다. 다만 여러분이 예상하는 방식과는 다릅니다. 피카소의 말처럼, "프로처럼 규칙을 배워야 예술가처럼 깨뜨릴 수 있다." 범용 지표가 왜 평가로서 실패하는지 이해하고 나면, 흥미로운 트레이스를 찾는 탐색 도구로 활용할 수 있습니다(다음 FAQ에서 설명합니다).
Q: 유사도 지표(BERTScore, ROUGE 등)가 LLM 출력 평가에 유용한가요?
BERTScore, ROUGE, 코사인 유사도 같은 범용 지표는 대부분의 AI 애플리케이션에서 LLM 출력 평가에 적합하지 않습니다. 대신 오류 분석을 통해 애플리케이션 동작에 특화된 지표를 식별하는 것을 권장합니다. 이진 합격/불합격 평가(LLM-as-Judge 활용) 또는 코드 기반 어서션으로 설계하세요.
예를 들어, 부동산 CRM 어시스턴트를 생각해 봅시다. 예약 불가능한 시간대에 집 보기를 제안하거나(어서션으로 테스트 가능), 고객 페르소나를 혼동하는 것(LLM-as-Judge로 테스트 가능)은 심각한 문제입니다. 유사도나 장황도 같은 범용 지표로는 이런 문제를 잡아낼 수 없습니다. 강좌에서 나온 관련 인용문입니다:
"범용 지표의 남용은 만연해 있습니다. 많은 평가 벤더가 기성 지표를 홍보하며, 엔지니어를 불필요한 작업에 빠뜨립니다."
유사도 지표가 항상 무용한 것은 아닙니다. 검색 및 추천 도메인에서는 유용하며, 따라서 RAG의 검색 최적화 및 디버깅에도 활용할 수 있습니다. 예를 들어, 임베딩 간 코사인 유사도로 검색 시스템의 의미적 근접도를 측정하거나, 평균 쌍별 유사도로 출력의 다양성을 평가할 수 있습니다(유사도가 낮을수록 다양성이 높음).
Q: 본 작업과 평가에 같은 모델을 사용해도 되나요?
LLM-as-Judge 선택 시, 같은 모델을 사용해도 대체로 괜찮습니다. 판정 모델은 메인 LLM 파이프라인과 다른 작업을 수행하기 때문입니다. 연구에 따르면 모델이 자체 출력을 평가할 때 편향을 보일 수 있지만, 궁극적으로 중요한 것은 판정 모델이 사람의 판단과 얼마나 일치하느냐입니다. 저희가 권장하는 판정 모델은 범위가 한정된 이진 분류 작업을 수행합니다. 이렇게 제한된 작업에서는 사람 라벨과의 반복적 정렬이 대체로 달성 가능하다는 것이 저희의 경험입니다.
별도의 라벨링된 테스트 셋에서 판정 모델의 진양성률(TPR)과 진음성률(TNR)을 높이는 데 집중하세요. 사람 평가와의 정렬이 잘 안 된다면 다른 모델을 시도해 볼 수 있습니다. 다만 조직에 따라 새로운 모델 제공업체를 도입하는 데 상당한 노력이 들 수 있으므로, 구체적인 정렬 문제가 없는 한 기본적으로 다른 모델을 사용하라고 권하지는 않습니다.
판정 모델 선택 시, 사람의 판단과 강한 정렬을 확보하기 위해 먼저 사용 가능한 가장 성능이 좋은 모델로 시작하세요. 신뢰할 수 있는 평가 기준이 확립된 후에 비용 최적화를 진행할 수 있습니다.
Q: 모델의 불확실성 표현 능력, 즉 "모르는 것을 아는" 능력을 어떻게 평가하나요?
많은 애플리케이션은 정보가 충분하지 않을 때 답변을 거부할 수 있는 모델을 필요로 합니다. 이 거부 행동의 보정(calibration) 수준을 평가하려면, 모델이 적절한 시점에 거부하면서도 답변 가능한 질문에는 거부하지 않는지 검증해야 합니다.
이를 효과적으로 수행하려면 다음 요소를 포함하는 평가 셋을 구성해야 합니다:
- 답변 가능한 질문: 모델에 제공된 컨텍스트나 일반 지식에 검증 가능한 정답이 존재하는 시나리오.
- 답변 불가능한 질문: 모델이 환각(hallucination)을 일으키도록 유도하는 시나리오. 거짓 전제가 있는 질문, 컨텍스트에서 명시적으로 누락된 정보에 대한 쿼리, 모델의 지식 범위를 벗어난 주제 등이 포함됩니다.
정확한 비율은 크게 중요하지 않지만, 답변 가능 질문과 불가능 질문을 대략 동일한 수로 구성하는 것이 좋은 출발점입니다. 정확한 비율보다 질문의 다양성과 난이도가 더 중요합니다.
평가 자체는 모델 판단에 대한 이진(합격/불합격) 검증입니다. "합격"은 두 가지 조건을 동시에 충족해야 합니다: 답변 가능한 질문에는 답변하고, 답변 불가능한 질문에는 거부하는 것. 답변 불가능한 질문에 지어낸 답변을 하는 것이 불합격이며, 이는 보정이 부실하다는 신호입니다.
연구 문헌에서 이 역량은 "Abstention Ability(답변 보류 능력)"로 알려져 있습니다. 이 행동을 개선하려면 Arxiv에서 이 용어를 검색하여 최신 기법을 파악하는 것이 좋습니다.
👉 AI 평가에 대해 더 알고 싶으신가요? AI Evals 강좌를 확인해 보세요. 실시간 코호트 방식으로, 실습과 오피스 아워가 함께 제공됩니다. 독자분들을 위한 25% 할인 코드도 준비했습니다. 👈
사람 어노테이션 & 프로세스
Q: LLM 출력 어노테이션에 몇 명이 참여해야 하나요?
대부분의 중소 규모 기업에서는 도메인 전문가 한 명을 "선의의 독재자"로 지정하는 것이 가장 효과적입니다. 정신건강 챗봇이라면 심리학자, 법률 문서 분석이라면 변호사, 고객 지원 자동화라면 고객서비스 책임자가 품질 기준의 최종 결정권자가 되는 것입니다.
한 명의 전문가가 있으면 어노테이션 충돌이 없고, "사공이 많으면 배가 산으로 간다"는 마비 상태를 방지할 수 있습니다. 선의의 독재자는 다른 사람의 의견과 피드백을 반영하되, 프로세스를 주도합니다. 단일 인터랙션을 판단하는 데 주제 전문가 5명이 필요하다고 느낀다면, 제품 범위가 지나치게 넓다는 신호일 수 있습니다.
다만, 대규모 조직이나 여러 도메인에 걸쳐 운영하는 경우(다국적 기업의 문화적 맥락 차이 등)에는 복수의 어노테이터가 필요할 수 있습니다. 여러 명을 활용할 때는 우연 이상의 일치를 보정하는 Cohen's Kappa 같은 지표로 동의 수준을 측정해야 합니다. 그래도 각자의 판단에 따라야 합니다. 대기업에서도 전문가 한 명이면 충분한 경우가 많습니다.
가능하면 선의의 독재자부터 시작하세요. 도메인이 요구하는 경우에만 복잡성을 추가하세요.
Q: PM과 엔지니어가 오류 분석에 함께 참여해야 하나요? 어떻게?
초기에는 협업을 통해 공유된 맥락을 구축하세요. 엔지니어는 검색 오류, 도구 에러 같은 기술적 문제를 잡아내고, PM은 사용자 기대 미충족, 혼란스러운 응답, 사용자가 기대하는 누락 기능 같은 제품 측면의 실패를 식별합니다.
시간이 지나면 오류 분석의 선의의 독재자—사용자 니즈를 이해하는 도메인 전문가 또는 PM—에게 주도권을 넘기세요. 도메인 전문가가 기술적 구현이 아닌 실제 결과를 평가하도록 역량을 부여하세요. "도구 호출이 성공했나?"가 아니라 "예약이 완료됐나?"라고 물어야 합니다. 도메인 전문가에게 역량을 부여하는 가장 좋은 방법은 시스템 결과물을 트레이스와 함께 보여주는 커스텀 어노테이션 도구를 제공하는 것입니다. 확인 메시지, 생성된 이메일, DB 업데이트 등 목표 완수를 검증하는 정보를 한 화면에 표시하세요. 비기술 리뷰어가 결과에 집중할 수 있도록 모든 컨텍스트를 한 곳에 모아 주세요.
Q: 어노테이션과 라벨링을 외부에 위탁해도 되나요?
오류 분석 외주는 대부분 큰 실수입니다(일부 예외는 있습니다). 평가의 핵심은 시스템 실패를 체계적으로 분석하면서만 쌓이는 제품 직관을 구축하는 것이기 때문입니다. 이 과정의 위임에 대해서는 극도로 회의적이어야 합니다.
외주의 위험
어노테이션을 외주하면, 실패를 관찰하고 제품 개선 방법을 이해하는 사이의 피드백 루프가 끊어지는 경우가 많습니다. 외주의 문제점은 다음과 같습니다:
- 피상적 라벨링: 잘 정의된 지표라 해도 외부 팀에게는 없는 세밀한 판단력이 필요합니다. 오류 분석에서 치명적인 실수는 도메인 전문가를 라벨링 과정에서 배제하는 것입니다. 도메인 전문성이 없는 일반 개발자나 IT 직원에게 맡기면 피상적이거나 잘못된 라벨링으로 이어지는 경우가 많습니다.
- 암묵적 지식의 손실: 핵심 도메인 전문가는 루브릭으로 온전히 담을 수 없는 암묵적 지식과 사용자 이해를 갖고 있습니다. 이들이 참여해야 사전에 완전히 명문화하기 어려운 선호와 기대까지 끌어낼 수 있습니다.
- 어노테이션 충돌과 정렬 실패: 공유된 맥락 없이 외부 어노테이터를 투입하면, 합의보다 불일치가 더 커질 수 있습니다. 내부 팀에서도 정렬은 어려운 과제이며, 외주 시 이 프로세스에 더 많은 시간이 소요됩니다.
권장 접근 방식: 내부 역량 구축
외주 대신, 효율적인 내부 평가 프로세스를 구축하는 데 집중하세요.
1. "선의의 독재자"를 임명합니다. 대부분의 팀에서 가장 효과적인 전략은 품질의 최종 결정권자로 내부 도메인 전문가 한 명을 지정하는 것입니다. 이 사람이 기준을 세우고 일관성을 유지하며 주인 의식을 가집니다.
2. 복수 어노테이터 시 협업 워크플로를 사용합니다. 여러 어노테이터가 필요한 경우, 정렬을 위해 구조화된 프로세스를 따르세요. * 명확한 합격/불합격 정의와 예시를 포함한 초기 루브릭을 작성합니다. * 각 어노테이터가 동일한 트레이스 셋을 독립적으로 라벨링하여 해석 차이를 드러냅니다. * Cohen's Kappa 같은 우연 보정 지표로 어노테이터 간 일치도(IAA)를 측정합니다. * 불일치를 논의하고 루브릭을 다듬는 정렬 세션을 진행합니다. * 일치도가 꾸준히 높아질 때까지 이 과정을 반복합니다.
인력 부족 대응 방법
내부 역량 구축이 모든 트레이스를 라벨링해야 한다는 뜻은 아닙니다. 다음 전략으로 작업량을 관리하세요:
- 스마트 샘플링: 대표적인 트레이스를 소규모로 선별해 철저히 검토합니다. 수천 건을 피상적으로 라벨링하는 것보다, 다양한 100건의 트레이스를 분석해 패턴을 찾는 편이 훨씬 효과적입니다.
- "씽크 얼라우드(Think-Aloud)" 기법: 제한된 전문가 시간을 최대한 활용하기 위해, 사용성 테스트에서 차용한 이 기법을 사용합니다. 전문가에게 몇 건의 트레이스를 검토하면서 생각 과정을 소리 내어 설명해 달라고 요청하세요. 1시간의 단일 세션으로도 깊은 인사이트를 얻을 수 있습니다.
- 경량 커스텀 도구 구축: 커스텀 어노테이션 도구를 만들어 리뷰 프로세스를 간소화하고 처리량을 높이세요.
외부 도움이 적절한 예외 상황
핵심 오류 분석 프로세스의 외주는 권장하지 않지만, 외부 도움이 적절한 경우도 있습니다:
- 순수 기계적 작업: 전화번호 식별이나 이메일 주소 검증 같은 고도로 객관적이고 모호하지 않은 작업은, 내부에서 엄격한 루브릭을 정의한 후 외부 어노테이터에게 맡길 수 있습니다.
- 제품 맥락이 불필요한 작업: 제품의 구체적 요구사항을 이해하지 않아도 되는 잘 정의된 작업은 외주가 가능합니다. 번역이 좋은 예입니다. 언어적 전문성은 필요하지만, 깊은 제품 지식은 필요하지 않기 때문입니다.
- 주제 전문가(SME) 채용: 외부 SME를 내부 도메인 전문가로 합류시키는 것은 외주가 아니라, 평가 프로세스에 필요한 전문성을 확보하는 것입니다. 예를 들어, AnkiHub은 의료 콘텐츠용 RAG 시스템 평가를 범용 어노테이터에게 맡기지 않고, 4학년 의대생을 채용해 수행했습니다.
Q: 평가의 어떤 부분을 LLM으로 자동화할 수 있나요?
LLM은 평가 워크플로의 일부를 가속할 수 있지만, 여러분의 전문성이 필수적인 영역에서 사람의 판단을 대체할 수는 없습니다. 예를 들어, 오류 분석 전체(트레이스 검토 및 어노테이션)를 LLM에게 맡기면, 제품에 중요한 실패 사례를 놓칠 수 있습니다. 사용자가 피드백에서 "렉"을 계속 언급하는데 LLM이 이를 범용적인 "성능 이슈"로 묶어버리고 "지연 시간" 카테고리를 만들지 않는다면, 느린 응답 속도에 대한 반복적 불만을 놓치고 수정 우선순위에서 밀리게 됩니다.
그래도 적절한 감독 하에 사용하면, LLM은 평가 워크플로의 특정 부분을 가속하는 데 유용합니다.
LLM이 도움이 되는 영역:
- 축 코딩 초안 작성: 직접 30~50건의 트레이스를 개방 코딩한 후, LLM에게 원시 실패 메모를 그룹으로 분류하게 합니다. 패턴을 빠르게 파악하는 데 도움이 되지만, 클러스터는 반드시 직접 검토하고 다듬어야 합니다. 참고: 축 코딩과 개방 코딩에 익숙하지 않다면 이 FAQ를 참고하세요.
- 어노테이션을 실패 유형에 매핑: 실패 카테고리를 정의한 후, 각 새 트레이스에 어떤 카테고리가 해당하는지 LLM에게 제안하도록 할 수 있습니다(예: "이 어노테이션: [open_annotation]과 이 실패 유형: [list_of_failure_modes]가 주어졌을 때, 어떤 것이 해당하나요?").
- 프롬프트 개선안 제안: 반복적인 문제를 발견했을 때, LLM에게 프롬프트의 구체적인 수정안을 제안하게 합니다. 제안된 변경 사항은 적용 전에 반드시 검토하세요.
- 어노테이션 데이터 분석: LLM이나 AI 기반 노트북을 활용해 라벨 데이터의 패턴을 찾습니다. 예를 들어, "렉 관련 보고가 피크 시간대에 3배 증가" 또는 "느린 응답 시간은 주로 모바일 사용자에서 보고됨" 같은 인사이트를 발견할 수 있습니다.
반면, LLM에게 위임하면 안 되는 활동:
- 초기 개방 코딩: 처음에는 반드시 직접 원시 트레이스를 읽어야 합니다. 이를 통해 새로운 유형의 실패를 발견하고, 사용자 불편 사항을 이해하며, 데이터에 대한 직관을 쌓게 됩니다. 절대 건너뛰거나 위임하지 마세요.
- 실패 분류 체계 검증: LLM이 생성한 그룹은 반드시 직접 검토해야 합니다. 예를 들어, LLM이 "로그인 후 앱 충돌"과 "로그인 시간이 너무 오래 걸림"을 하나의 "로그인 이슈"로 묶을 수 있지만, 하나는 안정성 문제이고 다른 하나는 성능 문제입니다. 직접 개입하지 않으면 서로 다른 수정이 필요한 문제를 구분하지 못하게 됩니다.
- 정답 라벨링: LLM-as-Judge 평가기의 테스트/검증에 사용되는 데이터는 각 라벨을 직접 검증해야 합니다. LLM의 실수가 신뢰할 수 없는 벤치마크로 이어질 수 있습니다.
- 근본 원인 분석: LLM은 명백한 문제를 지적할 수 있지만, 특정 워크플로나 엣지 케이스에서만 발생하는 패턴—예컨대 사용자가 Excel에서 데이터를 붙여넣을 때만 발생하는 버그—은 사람의 검토만이 발견할 수 있습니다.
결론적으로, 먼저 데이터를 직접 살펴보며 실제로 무엇이 잘못되고 있는지 파악하세요. LLM은 그 과정에서 배운 것을 확장하는 데 활용하는 것이지, 데이터를 안 봐도 되게 하려고 쓰는 것이 아닙니다.
Q: 수동 프롬프트 작성을 그만두고 자동화 도구에 맡겨야 하나요?
프롬프트 엔지니어링 자동화는 매력적이지만, 특히 개발 초기 단계에서는 프롬프트를 대신 최적화해 준다는 도구에 회의적이어야 합니다. 프롬프트를 직접 작성하면 자신의 가정을 명확히 하고 요구사항을 외부화할 수밖에 없습니다. 좋은 글쓰기는 곧 좋은 사고입니다 2. 이 작업을 너무 일찍 자동화 도구에 위임하면, 자신의 요구사항이나 모델의 실패 유형을 온전히 이해하지 못할 위험이 있습니다.
자동 프롬프트 최적화는 일반적으로 사전 정의된 평가 지표를 힐 클라이밍합니다. 알려진 실패에 대해 프롬프트를 개선할 수는 있지만, 새로운 실패를 발견할 수는 없습니다. 새 오류 발견에는 오류 분석이 필요합니다. 또한 연구에 따르면 모델의 출력을 검토한 후 평가 기준 자체가 변화하는 현상, 즉 "기준 드리프트(criteria drift)" 3가 나타납니다. 이는 평가가 한 번 설정해서 최적화 도구에 넘길 수 있는 정적 목표가 아니라, 반복적이고 사람 주도적인 의미 구성 과정임을 뜻합니다.
실용적 접근 방식은 개방 코딩(트레이스에 대한 자유 형식 메모)에 기반하여 LLM에게 프롬프트 개선을 제안하게 하는 것입니다. 이렇게 하면 데이터를 직접 보고 요구사항을 외부화하는 사람이 루프에 남게 됩니다. 고품질 평가 셋을 확보한 이후라면, 프롬프트 최적화가 마지막 성능 개선에 효과적일 수 있습니다.
👉 AI 평가에 대해 더 알고 싶으신가요? AI Evals 강좌를 확인해 보세요. 실시간 코호트 방식으로, 실습과 오피스 아워가 함께 제공됩니다. 독자분들을 위한 25% 할인 코드도 준비했습니다. 👈
도구 & 인프라
Q: 커스텀 어노테이션 도구를 만들어야 하나요, 기성 제품을 쓸까요?
커스텀 어노테이션 도구를 만드세요. AI 평가 워크플로에서 가장 효과가 큰 단일 투자입니다. Cursor나 Lovable 같은 AI 개발 도구를 활용하면 맞춤형 인터페이스를 몇 시간 만에 만들 수 있습니다. 커스텀 어노테이션 도구를 갖춘 팀이 약 10배 빠르게 반복하는 것을 자주 목격합니다.
커스텀 도구가 탁월한 이유:
- 여러 시스템의 컨텍스트를 한 곳에서 볼 수 있음
- 제품에 맞는 방식으로 데이터를 렌더링 가능 (이미지, 위젯, 마크다운, 버튼 등)
- 고유한 워크플로에 맞게 설계 가능 (커스텀 필터, 정렬, 진행률 표시 등)
수십 명의 분산된 어노테이터를 엔터프라이즈 접근 제어로 관리해야 하는 경우에는 기성 도구가 정당화될 수 있습니다. 그런 경우에도, 설정 오버헤드와 제약이 그만한 가치가 없다고 판단하는 팀이 많습니다.
Isaac의 Anki 플래시카드 어노테이션 앱은 커스텀 도구의 위력을 잘 보여줍니다. 쿼리당 400건 이상의 결과를 키보드 내비게이션과 도메인 특화 평가 기준으로 처리하는데, 범용 도구에서는 설정 자체가 거의 불가능한 수준입니다.
Q: 좋은 LLM 출력 리뷰 인터페이스의 조건은?
훌륭한 인터페이스는 사람의 리뷰를 빠르고, 명확하고, 동기 부여되게 만듭니다. 도메인에 맞춤화된 자체 어노테이션 도구 구축을 권장합니다. 아래 기능들은 실제로 효과가 좋았던 개선 사항들이지만, 모두 구현할 필요는 없습니다. 스크린샷은 개념을 명확히 하기 위한 예시이며, 실제로 하나의 앱에 이 기능 전부를 구현하는 경우는 드뭅니다. 구체적인 필요와 제약에 따른 판단의 문제입니다.
1. 트레이스를 범용적으로가 아닌 도메인에 맞게 렌더링:
트레이스를 해당 도메인에 직관적인 방식으로 표시하세요. 생성된 이메일을 평가한다면 이메일처럼 렌더링하고, 코드 출력이라면 구문 강조를 적용하세요. 전체 트레이스(사용자 입력, 도구 호출, LLM 추론)를 볼 수 있도록 하되, 중요도가 낮은 세부 정보는 펼칠 수 있는 접힌 섹션에 배치하세요. 아래는 부동산 어시스턴트 이메일 리뷰용 커스텀 어노테이션 도구의 예시입니다:
2. 진행률 표시와 키보드 내비게이션 지원:
마찰을 최소화하고 완료 의욕을 높여 리뷰어가 몰입 상태를 유지하도록 하세요. 진행률 표시(예: "100건 중 45건째")를 넣어 리뷰 세션의 범위를 명확히 하고 완료를 독려하세요. 트레이스 이동(예: N키로 다음), 라벨 적용, 메모 저장 등에 단축키를 지원하세요. 아래는 이런 기능의 예시입니다:
3. 클러스터링, 필터링, 검색을 통한 트레이스 탐색:
메타데이터로 필터링하거나 키워드로 검색할 수 있게 하세요. 시맨틱 검색은 개념적으로 유사한 문제를 찾는 데 유용합니다. 유사 트레이스를 클러스터링(예: 사용자 페르소나별 그룹핑)하면 반복적인 이슈를 발견하고 가설을 탐색할 수 있습니다. 아래는 이런 기능의 예시입니다:
4. 문제 가능성이 있는 트레이스를 우선 라벨링:
가드레일, CI 실패, 자동 평가기가 플래그한 트레이스를 리뷰 대상으로 우선 표시하세요. 데이터셋 추가, 버그 등록, 파이프라인 테스트 재실행 등의 액션 버튼을 제공하세요. 컨텍스트 전환을 최소화하기 위해 파이프라인 버전, 평가 점수, 리뷰어 정보 등 관련 컨텍스트를 인터페이스에 직접 표시하세요. 아래는 이런 아이디어의 예시입니다:
일반 원칙: 최소한으로 유지
어노테이션 인터페이스는 최소한으로 유지하세요. 추가적인 복잡성과 유지보수 부담을 상회하는 확실한 이점이 있을 때만 위 아이디어를 반영하세요.
Q: 평가 도구에서 직접 채워야 할 공백은 무엇인가요?
대부분의 평가 도구는 기본은 잘 갖추고 있습니다. 전체 트레이스 로깅, 지표 추적, 프롬프트 플레이그라운드, 어노테이션 큐 등은 기본 요건입니다. 하지만 기존 도구를 보완해야 할 네 가지 영역이 있습니다.
벤더가 이 공백을 해결하는지 주시하세요. 실무자의 니즈를 이해하고 있다는 강한 신호입니다.
1. 오류 분석과 패턴 발견
AI가 실패한 트레이스를 검토한 후, 도구가 유사한 이슈를 자동으로 클러스터링할 수 있나요? 예를 들어, 여러 트레이스에서 어시스턴트가 고급 고객에게 캐주얼한 어조를 사용하는 패턴이 보인다면, 더 넓은 "페르소나-톤 불일치" 패턴을 인식하는 기능이 필요합니다. AI를 활용해 그룹핑을 제안하고, 관찰 내용을 더 명확한 실패 분류 체계로 재작성하며, 시맨틱 검색으로 유사 사례를 찾는 기능의 구축을 권장합니다.
2. 워크플로 전반에 걸친 AI 활용
가장 효과적인 워크플로는 평가의 모든 단계에서 AI를 활용해 속도를 높입니다. 오류 분석 중에는 LLM이 자유 형식 관찰 내용을 일관된 실패 유형으로 분류하는 것을 돕습니다. 예를 들어, 여러 트레이스에 "투자자에게 어울리지 않는 톤", "럭셔리 바이어에게 너무 캐주얼" 같은 메모를 달았다면, 도구가 이것들을 같은 근본 패턴으로 인식해 통합된 "페르소나-톤 불일치" 카테고리를 제안해야 합니다.
수정안 제안에도 AI 지원이 필요합니다. 어시스턴트가 매물 요약에서 반려동물 정책을 누락하는 사례 20건을 찾았다면, 워크플로가 이 실패를 분석해 구체적인 프롬프트 수정을 제안할 수 있어야 합니다. WHERE 절 누락 패턴을 발견했다면, SQL 생성 지침의 개선안 초안을 작성할 수 있을까요?
또한 어노테이션과 트레이스의 데이터 분석도 효과적인 워크플로의 핵심입니다. 저는 Julius, Hex, SolveIt 같은 AI 기반 노트북을 즐겨 사용합니다. "사용자가 동네 이름을 언급할 때 위치 모호성 오류가 3배 급증" 또는 "톤 불일치가 이메일 생성에서 다른 모달리티보다 80% 더 자주 발생" 같은 인사이트를 발견하는 데 도움이 됩니다.
3. 범용 지표 대신 커스텀 평가기
대부분의 평가기를 직접 구축할 준비를 하세요. "환각 점수"나 "유용성 평점" 같은 범용 지표는 여러분의 애플리케이션에서 실제로 중요한 것—예약 불가능한 시간대의 집 보기 제안이나 이메일에서 예산 제약 누락 같은—을 거의 포착하지 못합니다. 성공하는 팀은 대부분의 노력을 애플리케이션 특화 지표에 투입합니다.
4. 커스텀 어노테이션 앱을 지원하는 API
커스텀 어노테이션 인터페이스가 대부분의 팀에 가장 적합합니다. 이를 위해서는 옵저버빌리티 플랫폼의 잘 설계된 API가 필요합니다. 벌크 데이터 내보내기를 위해 별도의 라이브러리와 추상화를 직접 만들어야 하는 경우가 많습니다. 수천 건의 요청을 페이지네이션하거나 타임아웃이 발생하는 엔드포인트를 처리하며 데이터를 추출해야 할 이유가 없어야 합니다. 진정한 벌크 내보내기 기능과, 중요하게도 어노테이션을 효율적으로 쓸 수 있는 API를 제공하는 플랫폼을 찾으세요.
Q: 가장 선호하는 평가 벤더는?
평가 도구 시장은 매우 치열합니다. 기능을 비교하는 것은 무의미합니다. 그런 분석을 하더라도 일주일이면 구식이 됩니다! 실무에서 자연스럽게 자주 접하는 벤더는 Langsmith, Arize, Braintrust입니다.
클라이언트의 벤더 선정을 도울 때, 결정 요인은 순수한 기능보다 누가 더 나은 지원을 제공하느냐에 크게 좌우됩니다. 이는 클라이언트 규모, 사용 사례 등에 따라 달라집니다. 결국 중요한 것은 사람 요소이며, 감히 말하자면, 느낌입니다.
특별히 선호하는 벤더는 없습니다. 핵심 기능은 매우 비슷하며, 필요에 맞게 그 위에 커스텀 도구를 구축하는 경우가 많습니다.
위 세 벤더의 상대적 장단점에 대한 실시간 코멘터리를 담은 영상 시리즈도 참고하세요.
Q: 프롬프트를 어떻게 버전 관리하고 관리해야 하나요?
프롬프트를 코드 가까이에 두는 것과 비기술 이해관계자가 접근할 수 있는 환경 사이에는 피할 수 없는 긴장이 있습니다.
제가 선호하는 방식은 프롬프트를 Git에 저장하는 것입니다. 프롬프트를 애플리케이션 코드와 함께 버전 관리하고, 리뷰하며, 원자적으로 배포하는 소프트웨어 산출물로 취급합니다. Git 커맨드 라인은 비기술자에게 불친절하지만, GitHub 웹 인터페이스와 GitHub Desktop 앱을 쓰면 충분히 접근 가능합니다. GitHub에서 근무할 때, 변호사와 회계사를 포함한 많은 비기술 전문가들이 이 도구를 효과적으로 사용하는 것을 봤습니다. 비기술자를 위한 시작 가이드는 이 블로그 글을 참고하세요.
대안으로, Arize, Braintrust, LangSmith 같은 LLM 도구 분야의 대부분 벤더가 전용 프롬프트 관리 도구를 제공합니다. 빠른 반복에는 접근성이 좋지만, 추가적인 간접 계층이 생길 위험이 있습니다.
프롬프트 관리 도구가 한계에 부딪히는 이유: AI 제품은 일반적으로 도구, RAG, 에이전트 등 많은 움직이는 부분이 있습니다. 프롬프트 관리 도구는 애플리케이션의 코드를 쉽게 실행할 수 없다는 본질적 한계가 있습니다. 실행할 수 있더라도, 상당한 간접 과정이 수반되어 프롬프트를 시스템의 실제 역량과 함께 테스트하기 어렵습니다.
가능하다면, 노트북이 프롬프트 실험에 훌륭한 솔루션입니다. 코드베이스에 Python 진입점이 있거나 Python으로 작성되어 있다면, Jupyter 노트북이 특히 강력합니다. 프롬프트를 실험하면서 전체 도구 및 RAG 기능이 갖춰진 실제 AI 에이전트를 반복 테스트할 수 있습니다. 시스템이 실제로 어떻게 동작하는지 훨씬 쉽게 이해할 수 있습니다. 또한 노트북 안에서 위젯과 소규모 UI를 만들 수 있어, 실험과 반복의 양쪽 장점을 모두 누릴 수 있습니다. 실제 모습은 Teresa Torres가 PM 관점에서 노트북으로 평가와 실험의 전체 라이프사이클을 수행하는 실습 워크스루에서 잘 보여줍니다:
노트북이 코드베이스에 적합하지 않다면, 통합 프롬프트 환경이 실험에 효과적일 수 있습니다. 어느 쪽이든, 프롬프트의 버전 관리와 관리는 Git에서 하는 것을 선호합니다.
👉 AI 평가에 대해 더 알고 싶으신가요? AI Evals 강좌를 확인해 보세요. 실시간 코호트 방식으로, 실습과 오피스 아워가 함께 제공됩니다. 독자분들을 위한 25% 할인 코드도 준비했습니다. 👈
프로덕션 & 배포
Q: CI/CD와 프로덕션 모니터링에서 평가는 어떻게 다르게 활용되나요?
CI 평가와 프로덕션 평가의 가장 큰 차이는 테스트에 사용하는 데이터입니다.
CI용 테스트 데이터셋은 규모가 작고(보통 100개 이상), 목적에 맞게 직접 구성합니다. 핵심 기능, 과거 버그에 대한 회귀 테스트, 알려진 엣지 케이스 등을 포함합니다. CI 테스트는 자주 실행되므로 각 테스트의 비용을 신중히 고려해야 합니다(데이터셋을 정성스럽게 큐레이션하는 이유도 이 때문입니다). LLM-as-Judge 평가기보다는 어서션(assertion)이나 결정적(deterministic) 검증 방식을 우선 사용하세요.
프로덕션 트래픽 평가에서는 실제 트레이스를 샘플링한 뒤 비동기로 평가기를 실행할 수 있습니다. 프로덕션 데이터에는 대개 정답 출력이 없으므로, LLM-as-Judge처럼 비용이 높지만 참조 출력 없이 작동하는 평가기에 더 의존하게 됩니다. 또한 프로덕션 지표에는 신뢰 구간을 추적하세요. 하한값이 임계치 아래로 내려가면 추가 조사가 필요합니다.
이 두 시스템은 상호 보완적입니다. 프로덕션 모니터링에서 오류 분석과 평가를 통해 새로운 실패 패턴을 발견하면, 해당 사례를 CI 데이터셋에 추가하세요. 이렇게 하면 새로 발견된 문제에 대한 회귀를 방지할 수 있습니다.
Q: 가드레일과 평가기의 차이는 무엇인가요?
가드레일(Guardrail)은 요청/응답 경로에 직접 위치하는 인라인 안전 검사입니다. 사용자에게 결과가 전달되기 전에 입력이나 출력을 검증하며, 일반적으로 다음과 같은 특성을 갖습니다:
- 빠르고 결정적 – 보통 수 밀리초 이내의 지연 시간 예산 내에서 동작합니다.
- 단순하고 설명 가능 – 정규표현식, 키워드 차단 목록, 스키마·타입 검증기, 경량 분류기 등을 사용합니다.
- 명확하고 영향이 큰 실패에 특화 – PII 유출, 비속어, 허용되지 않은 지시문, SQL 인젝션, 잘못된 JSON 형식, 유효하지 않은 코드 구문 등을 차단합니다.
가드레일이 작동하면 시스템은 응답을 마스킹하거나, 거부하거나, 재생성할 수 있습니다. 이 검사 결과는 작동 시 사용자에게 직접 노출되기 때문에, 오탐(false positive)은 프로덕션 버그로 취급됩니다. 팀에서는 가드레일 규칙에 버전 관리를 적용하고, 모든 트리거를 로깅하며, 발동 비율을 모니터링해 보수적으로 운영합니다.
반면 평가기(Evaluator)는 보통 응답이 생성된 이후에 실행됩니다. 단순 규칙으로는 측정할 수 없는 사실 정확성, 완전성 등의 품질을 측정합니다. 평가 결과는 대시보드, 회귀 테스트, 모델 개선 사이클에 반영되지만, 원래 응답 자체를 차단하지는 않습니다.
평가기는 대개 비동기 또는 배치로 실행되어 LLM-as-a-Judge 같은 무거운 연산을 수용합니다. LLM-as-Judge를 인라인으로 사용하려면 지연 시간 예산과 안정성 목표가 반드시 허용해야 합니다. 느린 LLM 판정기는 경계선상의 소수 케이스에만 적용하는 캐스케이드 방식에서 활용 가능할 수 있습니다.
즉각적인 조치가 필요한 명백한 실패에는 가드레일을, 주관적이거나 미묘한 기준의 모니터링과 개선에는 평가기를 사용하세요. 두 가지를 함께 운용하면 다층 보호 체계를 구축할 수 있습니다.
주의: LLM 가드레일을 기성 제품 그대로 무비판적으로 사용하지 마세요. 반드시 프롬프트를 직접 확인하세요.
Q: 평가기를 프로덕션에서 출력을 자동으로 수정하거나 보정하는 데에도 쓸 수 있나요?
가능하지만, 특정 유형의 평가기에 한합니다. 이것이 바로 앞서 설명한 평가기와 가드레일의 차이입니다. 다시 정리하면:
- 평가기는 응답이 생성된 후 비동기적으로 실행되는 것이 일반적입니다. 품질을 측정하지만 사용자의 즉각적인 경험에는 개입하지 않습니다.
- 가드레일은 요청의 크리티컬 패스에서 동기적으로 실행되며, 출력이 사용자에게 표시되기 전에 작동합니다. 영향이 큰 실패를 실시간으로 차단하는 것이 목적입니다.
평가기를 가드레일로 사용할지 결정할 때 고려해야 할 두 가지 핵심 기준이 있습니다:
지연 시간 & 비용: 해당 평가기가 사용자 경험을 저하시키지 않으면서 크리티컬 요청 경로에서 충분히 빠르고 저렴하게 실행될 수 있는가?
오류율 트레이드오프: 오탐(정상 출력을 차단하여 사용자에게 불편을 주는 것)과 미탐(잘못된 출력이 사용자에게 전달되어 피해를 주는 것) 사이의 비용-편익 균형은 어떠한가? 의료 조언 같은 고위험 분야에서는 미탐의 비용이 오탐보다 클 수 있습니다. 반면 창작 분야에서는 정당한 창의적 표현을 차단하는 오탐이 간헐적인 품질 문제보다 더 큰 손해일 수 있습니다.
대부분의 가드레일은 빠르게 동작하도록(사용자 경험 저하 방지) 설계되며, 매우 낮은 오탐률을 유지합니다(정상 응답 차단 방지). 이런 이유로, 느리거나 비결정적인 LLM-as-Judge를 동기식 가드레일로 사용하는 경우는 거의 없습니다. 다만 여러분의 유스케이스에 따라 이러한 트레이드오프가 달라질 수 있습니다.
Q: 모델 선택에 시간을 얼마나 투자해야 하나요?
많은 개발자가 LLM 애플리케이션 개선의 핵심 수단으로 모델 선택에 집착합니다. 모델 교체를 고려하기 전에 먼저 오류 분석을 통해 실패 유형을 파악하세요. Hamel은 오피스 아워에서 이렇게 조언했습니다. "근거 없이 처음부터 모델 교체를 시스템 개선의 주요 축으로 삼지 마세요. 오류 분석 결과가 모델 자체가 문제라고 가리키고 있나요?"
도메인별 응용
Q: RAG는 죽었나요?
질문: 코딩 에이전트에서 "RAG는 죽었다"는 글을 읽었는데, AI 애플리케이션에서 RAG를 쓰지 말아야 하나요?
"RAG는 죽었다"는 류의 글을 읽고 RAG를 언제, 어떻게 사용해야 하는지 혼란스러워하는 개발자가 많습니다. RAG의 실제 의미와 마케팅적으로 축소된 정의를 구분하면, AI 애플리케이션의 아키텍처를 더 합리적으로 결정할 수 있습니다.
화제가 된 해당 글은 자율 코딩 에이전트에서 단순한 벡터 데이터베이스 검색(naive vector database retrieval)을 사용하는 것에 반대하는 것이지, RAG 전체를 부정하는 것이 아닙니다. 오해를 부르는 마케팅 탓에 많은 개발자가 놓치는 중요한 구분입니다.
RAG는 말 그대로 검색 증강 생성(Retrieval-Augmented Generation), 즉 검색을 통해 관련 컨텍스트를 제공하여 모델 출력을 개선하는 방식입니다. 핵심 원리는 여전히 유효합니다. LLM이 정확한 답변을 생성하려면 적절한 컨텍스트가 필요합니다. 문제는 검색을 할지 말지가 아니라, 어떻게 효과적으로 검색할 것인가입니다.
코딩 분야에서는 코드 간의 관계가 복잡하고 맥락에 따라 달라지기 때문에, 단순한 벡터 유사도 검색이 잘 작동하지 않는 경우가 많습니다. 하지만 검색 자체를 포기하는 것은 아닙니다. Claude Code 같은 최신 코딩 어시스턴트도 여전히 검색을 활용합니다. 다만 벡터 데이터베이스에만 의존하는 대신, 사람 개발자가 일하는 방식과 비슷하게 에이전틱 검색을 수행합니다.
단순 키워드 매칭부터 임베딩 유사도, LLM 기반 관련성 필터링까지 다양한 검색 전략을 활용할 수 있습니다. 최적의 방법은 구체적인 유스케이스, 데이터 특성, 성능 요구사항에 따라 달라집니다. 실제 프로덕션 시스템에서는 여러 전략을 결합하거나, LLM 에이전트가 안내하는 멀티홉 검색을 사용하는 경우가 많습니다.
안타깝게도 "RAG"는 공통된 정의 없이 버즈워드가 되어버렸습니다. 모든 검색 시스템을 RAG라 부르는 사람도 있고, 벡터 데이터베이스에 한정하는 사람도 있습니다. 궁극적인 목표에 집중하세요. LLM이 성공적으로 동작하는 데 필요한 컨텍스트를 확보하는 것입니다. 그 수단이 벡터 검색이든, 에이전틱 탐색이든, 하이브리드 방식이든 그것은 제품과 엔지니어링 차원의 판단입니다.
RAG를 피하라거나 반드시 도입하라는 획일적인 조언에 휘둘리지 말고, 다양한 검색 방식을 실험하며 자신의 애플리케이션에 가장 효과적인 방법을 측정해 보세요. RAG 평가 및 최적화에 대한 자세한 내용은 이 시리즈를 참고하세요.
Q: RAG 시스템 평가는 어떻게 접근해야 하나요?
RAG 시스템은 검색(retrieval)과 생성(generation)이라는 두 가지 구성 요소로 나뉘며, 각각 다른 평가 방식이 필요합니다.
검색 컴포넌트는 탐색 문제입니다. 전통적인 정보 검색(IR) 지표로 평가하세요. 대표적인 지표로는 Recall@k(전체 관련 문서 중 상위 k개에 포함된 비율), Precision@k(검색된 k개 문서 중 실제 관련 문서 비율), MRR(첫 번째 관련 문서의 순위)이 있습니다. 어떤 지표를 선택할지는 유스케이스에 따라 달라집니다. 이 지표들은 올바른 문서를 찾고 있는지를 측정하는 순수한 검색 지표입니다(자세한 내용은 아래에서 다룹니다).
검색 평가를 위한 데이터셋은 합성 방식으로 생성할 수 있습니다. 코퍼스에서 문서를 가져와 핵심 사실을 추출한 뒤, 해당 사실로 답할 수 있는 질문을 생성하세요. 이 역방향 과정을 통해 수동 어노테이션 없이도 검색 성능 측정에 필요한 쿼리-문서 쌍을 확보할 수 있습니다.
생성 컴포넌트—LLM이 검색된 컨텍스트를 얼마나 잘 활용하는지, 환각이 발생하는지, 질문에 정확히 답하는지—에 대해서는 이 강좌 전반에서 다룬 평가 절차를 동일하게 적용합니다. 실패 유형 파악을 위한 오류 분석, 사람 레이블 수집, LLM-as-Judge 평가기 구축, 그리고 사람 어노테이션 대비 판정기 검증이 포함됩니다.
Jason Liu의 "RAG 평가는 6가지뿐이다(There Are Only 6 RAG Evals)"는 이러한 구분에 잘 맞는 프레임워크를 제시합니다. Tier 1은 검색에 대한 전통적 IR 지표를 다루고, Tier 2와 3은 질문(Q), 컨텍스트(C), 답변(A) 간의 관계를 평가합니다. 예를 들어 컨텍스트가 질문에 적합한지(C|Q), 답변이 컨텍스트에 충실한지(A|C), 답변이 질문에 부합하는지(A|Q) 등입니다.
Jason의 6가지 평가 외에도, 실제 데이터에 대한 오류 분석을 통해 도메인 특화 실패 유형이 드러날 수 있으며, 이에 대한 별도 지표가 필요할 수 있습니다. 예를 들어, 의료 RAG 시스템이 성인과 소아의 약물 용량을 지속적으로 혼동하거나, 법률 RAG가 관할 구역 경계를 잘못 판단하는 패턴 등은 실제 실패 사례를 체계적으로 검토해야만 발견됩니다. 이런 패턴이 확인되면 일반 프레임워크를 넘어 해당 문제에 특화된 평가기를 만들 수 있습니다.
마지막으로, Jason의 Tier 2·3 지표를 구현할 때 기성 프롬프트를 그대로 가져다 쓰지 마세요. 표준적인 LLM-as-Judge 프로세스에는 여러 단계가 필요합니다. 오류 분석, 프롬프트 반복 개선, 레이블된 예시 구축, 사람 레이블 대비 판정기 정확도 측정이 포함됩니다. 판정기의 참양성률(True Positive Rate)과 참음성률(True Negative Rate)을 파악하면, 추정치를 보정하여 시스템의 실제 실패율을 산출할 수 있습니다. 이 검증 과정을 건너뛰면 판정기가 실제 품질 기준을 제대로 반영하지 못할 수 있습니다.
요약하면, 먼저 IR 지표로 검색을 디버깅하고, 그 다음에 적절히 검증된 LLM 판정기를 활용해 생성 품질을 개선하세요.
Q: 문서 처리 작업에서 적절한 청크 크기는 어떻게 선택하나요?
RAG에서는 검색에 최적화된 청크를 사용하지만, 문서 처리에서는 모델이 모든 청크를 읽는다는 전제가 다릅니다. 목표는 모델이 과부하 없이 효과적으로 추론할 수 있도록 텍스트를 분할하는 것입니다. 문서가 컨텍스트 윈도우에 들어간다 해도 나누는 것이 더 나을 수 있습니다. 긴 입력은 어텐션 병목으로 인해 성능이 저하될 수 있으며, 특히 컨텍스트 중간 부분에서 이런 현상이 두드러집니다. 작업 유형에 따라 두 가지 전략이 필요합니다:
1. 고정 출력 작업 → 큰 청크
출력 길이가 입력에 비례하여 늘어나지 않는 작업입니다. 숫자 추출, 특정 질문에 대한 답변, 섹션 분류 등이 해당됩니다. 예를 들면:
- "이 계약서의 위약금 조항은 무엇인가요?"
- "2023년 CEO의 연봉은 얼마였나요?"
답이 포함될 가능성이 높은 가장 큰 청크를 사용하세요(단, 주의 사항 있음). 쿼리 횟수를 줄이고 컨텍스트 단편화를 방지할 수 있습니다. 하지만 무관한 텍스트를 함께 넣는 것은 피하세요. 모델은 특히 긴 입력에서 불필요한 정보에 주의가 분산되기 쉽고, 긴 입력의 중간 부분은 충분히 처리되지 않을 수 있습니다. 비용이나 지연 시간이 병목이라면, 큰 청크를 그대로 넣기 전에 키워드 검색이나 경량 검색기로 관련 섹션만 추출하는 전처리를 고려하세요.
2. 확장 출력 작업 → 작은 청크
요약, 전수 추출 등 출력이 입력에 비례하여 늘어나는 작업입니다. 예를 들면:
- "각 섹션을 요약해 주세요"
- "모든 고객 불만 사항을 나열해 주세요"
이런 경우 작은 청크를 사용하면 추론 품질과 출력 완전성을 유지하는 데 도움이 됩니다. 표준적인 방법은 각 청크를 독립적으로 처리한 뒤 결과를 합치는 것(예: 맵-리듀스)입니다. 청크 크기를 정할 때는 문단, 섹션, 장 등 콘텐츠의 자연스러운 경계를 존중하세요. 청크 분할은 출력 길이 제한 문제를 완화하는 데에도 도움이 됩니다. 작업을 조각으로 나누면 각 조각의 출력이 제한 범위 안에 들어올 수 있습니다.
일반 가이드라인
청크 크기가 결과에 영향을 미치는 이유를 이해하는 것이 중요합니다. 청크가 클수록 모델은 한 번에 더 많은 정보를 처리해야 하며, 이는 본질적으로 더 큰 인지 부하를 의미합니다. LLM은 긴 텍스트 전반에 걸쳐 세부 사항을 유지하고 연관시키는 능력에 한계가 있습니다. 정보가 너무 많이 담기면 모델이 특정 부분(주로 시작과 끝)에 집중하고 중간의 세부 사항을 간과하거나 "잊어버리는" 경향이 나타납니다. 이는 지나치게 피상적인 요약이나 사실 누락으로 이어질 수 있습니다. 반대로 작은 청크는 문제의 범위를 제한하여 모델이 해당 섹션에 온전히 집중할 수 있게 합니다. 이는 전체 맥락을 포기하고 국소 집중을 취하는 트레이드오프입니다.
어떤 경험 법칙으로도 여러분의 유스케이스에 최적인 청크 크기를 완벽하게 결정할 수는 없습니다. 실험을 통해 검증해야 합니다. 최적 청크 크기는 도메인과 모델에 따라 다릅니다. 저는 청크 크기를 튜닝해야 할 하이퍼파라미터로 취급합니다.
Q: 멀티턴 대화 트레이스는 어떻게 디버깅하나요?
단순하게 시작하세요. 전체 대화가 사용자의 목표를 달성했는지 합격/불합격으로 판단합니다. 전체 트레이스를 살펴보되 최초의 상류(upstream) 실패에 집중하세요. 먼저 사용자에게 노출되는 부분을 읽고 무엇이 잘못되었는지 파악한 다음, 도구 호출이나 중간 단계 같은 기술적 세부 사항을 확인하세요.
멀티 에이전트 트레이스 로깅
멀티 에이전트 플로우에서는 각 사용자 요청에 세션 또는 트레이스 ID를 부여하고, 모든 메시지에 출처(어떤 에이전트 또는 도구), 트레이스 ID, 시퀀스 내 위치를 함께 기록하세요. 이를 통해 최초 쿼리부터 최종 결과까지 모든 에이전트를 거치는 전체 경로를 재구성할 수 있습니다.
어노테이션 전략
처음에는 트레이스에서 첫 번째 실패만 어노테이션하세요. 하류(downstream) 실패는 대부분 첫 번째 문제에서 연쇄적으로 발생하기 때문입니다. 상류 실패를 수정하면 그에 의존하는 하류 실패도 자동으로 해결되는 경우가 많습니다. 경험이 쌓이면 같은 트레이스 내에서 독립적인 실패 유형도 함께 어노테이션하여 전체 오류 분석 속도를 높일 수 있습니다.
가능하면 단순화하기
실패를 발견하면 가장 간단한 테스트 케이스로 재현하세요. 예를 들어, 쇼핑 봇이 대화 4턴째에 잘못된 환불 정책을 안내했다고 합시다. 복잡한 멀티턴 구조를 바로 분석하기 전에, 단일 턴으로 단순화해 보세요: "제품 X1000의 반품 기간은 어떻게 되나요?" 이것만으로도 실패가 재현된다면, 문제가 대화 컨텍스트와 무관하다는 의미입니다. 기본적인 검색이나 지식 문제일 가능성이 높으므로 훨씬 쉽게 디버깅할 수 있습니다.
테스트 케이스 생성
크게 두 가지 접근법이 있습니다. 첫째, 다른 LLM으로 사용자를 시뮬레이션하여 현실적인 멀티턴 대화를 생성하는 방법입니다. 둘째, "N-1 테스팅"으로 실제 대화의 처음 N-1턴을 제공한 뒤 다음에 무슨 일이 일어나는지 테스트하는 방법입니다. N-1 접근법은 완전히 합성된 대화가 아닌 실제 대화 접두사를 사용하므로 더 나은 결과를 낼 때가 많지만, 유연성은 떨어집니다.
핵심은 철저함과 효율성의 균형입니다. 모든 멀티턴 실패에 멀티턴 분석이 필요한 것은 아닙니다.
Q: 사람 상담사 전환(human handoff)이 포함된 세션은 어떻게 평가하나요?
트레이스에 사람 상담사 전환을 포함한 전체 사용자 여정을 기록하세요. 트레이스는 AI가 사람에게 넘기는 시점이 아니라, 사용자의 요구가 해결되거나 세션이 종료될 때까지 이어져야 합니다. 전환 결정, 그 이유, 전달된 컨텍스트, 대기 시간, 사람의 조치, 최종 해결 결과, 사람이 충분한 컨텍스트를 받았는지 여부를 모두 로깅하세요. 많은 실패가 전환 경계에서 발생합니다. AI가 너무 일찍, 너무 늦게, 또는 적절한 컨텍스트 없이 넘기는 경우입니다.
오류 분석 과정에서 전환을 잠재적 실패 유형으로 평가하세요. 전환이 정말 필요했는지, AI가 충분한 컨텍스트를 전달했는지 확인하세요. 전환 품질과 전환 비율을 모두 추적하세요. 때로는 전환 실행을 개선하는 것보다 전환 자체를 줄이는 것이 더 효과적인 개선일 수 있습니다.
Q: 복잡한 다단계 워크플로우는 어떻게 평가하나요?
최초 트리거부터 최종 비즈니스 결과까지 전체 워크플로우를 로깅하세요. LLM 호출, 도구 사용, 사람의 승인, 데이터베이스 쓰기 등을 모두 트레이스에 포함해야 합니다. 이 가시성이 확보되어야 실패를 제대로 진단할 수 있습니다.
결과 지표와 프로세스 지표를 함께 사용하세요. 결과 지표는 최종 결과가 요구사항을 충족하는지 검증합니다. 비즈니스 케이스가 완전한지, 정확한지, 형식에 맞는지 등을 확인합니다. 프로세스 지표는 효율성을 평가합니다. 단계 수, 소요 시간, 리소스 사용량 등이 해당됩니다. 프로세스 실패는 더 결정적(deterministic)이어서 디버깅이 쉬운 경우가 많으므로 먼저 처리하세요.
오류 분석을 워크플로우 단계별로 세분화하세요. 초기 단계 실패(사용자 입력 이해)는 중간 단계 실패(데이터 처리)나 후기 단계 실패(출력 포맷팅)와 성격이 다릅니다. LLM 체인에서는 오류가 연쇄적으로 전파되므로, 초기 단계를 개선하면 전체적으로 더 큰 효과를 얻을 수 있습니다.
전이 실패 매트릭스(transition failure matrix)를 활용하여 워크플로우가 어디에서 중단되는지 분석하세요. 마지막 성공 상태를 행으로, 첫 번째 실패가 발생한 지점을 열로 구성한 매트릭스를 만드세요. 이를 통해 실패 핫스팟을 파악하고 디버깅 투자 방향을 결정할 수 있습니다.
Q: 에이전틱 워크플로우는 어떻게 평가하나요?
에이전틱 워크플로우 평가는 두 단계로 진행하는 것을 권장합니다:
1. 엔드투엔드 작업 성공 여부. 에이전트를 블랙박스로 취급하고 "사용자의 목표를 달성했는가?"를 평가합니다. 작업별로 명확한 성공 기준(정확한 답변, 올바른 사이드 이펙트 등)을 정의하고, 사람 또는 보정된 LLM 판정기로 측정합니다. 오류 분석 시 최초의 상류 실패를 기록하세요.
오류 분석을 통해 가장 빈번하게 실패하는 워크플로우를 파악한 뒤, 실패 원인을 이해하기 위해 단계별 진단으로 넘어갑니다.
2. 단계별 진단. 도구 호출과 응답에 대한 세부 정보를 충분히 계측(instrument)해 두었다면, 개별 컴포넌트를 다음과 같이 평가할 수 있습니다: - 도구 선택: 선택된 도구가 적절했는가? - 파라미터 추출: 입력이 완전하고 올바른 형식이었는가? - 오류 처리: 빈 결과나 API 실패에서 복구했는가? - 컨텍스트 유지: 이전 제약 조건을 유지했는가? - 효율성: 몇 단계, 몇 초, 몇 토큰이 소요되었는가? - 목표 체크포인트: 긴 워크플로우에서 주요 마일스톤을 달성했는가.
예시: "버클리에서 100만 달러 이하 주택을 찾아 견학 일정을 잡아줘"라는 요청은 다음과 같이 분해됩니다: 파라미터 정확히 추출, 관련 매물 검색, 가능 시간 확인, 캘린더 초대 발송. 각 체크포인트는 독립적으로 합격/불합격을 판정할 수 있어 디버깅이 수월해집니다.
전이 실패 매트릭스를 활용하여 오류 패턴을 파악하세요. 행은 마지막 성공 상태, 열은 첫 번째 실패 발생 지점으로 구성한 매트릭스를 만드세요. 가장 많은 실패가 집중되는 곳을 한눈에 파악할 수 있는 효과적인 방법입니다.
전이 매트릭스는 압도적으로 복잡한 에이전트 동작을 실행 가능한 인사이트로 변환해 줍니다. 개별 트레이스를 하나하나 검토하며 허우적대는 대신, GenSQL → ExecSQL 전이에서 12건의 실패가 발생하고 DecideTool → PlanCal에서는 2건만 발생한다는 것을 즉시 확인할 수 있습니다. 이 데이터 기반 접근법이 디버깅 투자 방향을 안내합니다. 다음은 Bryan Bischof의 또 다른 텍스트-투-SQL 에이전트 사례입니다:
이 사례에서 Bryan은 실험 간 전이 매트릭스의 변화를 보여줍니다. 전이 매트릭스를 어떻게 구성할지는 애플리케이션의 특성에 따라 달라집니다. 예를 들어, Bryan의 텍스트-투-SQL 에이전트는 본질적으로 순차적 워크플로우를 갖고 있으며, 이를 활용하여 더 깊은 분석적 인사이트를 도출합니다. 자세한 내용은 Bryan의 전체 발표 영상을 참고하세요.
에이전트 실패에 대한 테스트 케이스 만들기
에이전트 실패에 대한 테스트 케이스 작성은 앞서 다룬 멀티턴 대화 트레이스 디버깅 FAQ와 동일한 원칙을 따릅니다(가능한 한 가장 단순한 방법으로 오류를 재현하고, 실패에 실제로 대화 컨텍스트가 필요한 경우에만 멀티턴 테스트를 사용하는 등).
👉 AI 평가에 대해 더 알고 싶으신가요? AI Evals 강좌를 확인해 보세요. 실습과 오피스 아워가 포함된 라이브 코호트 과정입니다. 독자분들을 위한 25% 할인 코드를 준비했습니다. 👈
각주
훌륭한 TA인 Eleanor Berger.↩︎
Paul Graham, "Writes and Write-Nots"↩︎
Shreya Shankar 외, "Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences"↩︎