"Evaluation" 태그 — 3개 게시물

TL;DR​

AI 에이전트 평가는 전통적인 소프트웨어 테스트와 다르다. 복잡한 평가 시스템을 구축하기 전에 2050개의 실제 트레이스를 직접 읽고, end-to-end 태스크 완수를 검증하는 단순한 eval부터 시작하라. 6080%의 시간을 에러 분석에 투자하고, capability eval(무엇을 할 수 있는가)과 regression eval(여전히 작동하는가)을 명확히 분리하며, 차원별 전문 채점기를 설계하라. 프로덕션 트레이스를 지속적으로 데이터셋에 편입하는 플라이휠을 구축하면, 시간이 지남에 따라 에이전트가 개선된다.

Key Takeaways​

• 단순함부터 시작: 복잡한 인프라를 만들기 전에 30분간 실제 트레이스를 수동으로 읽어라. 자동 시스템보다 더 많은 실패 패턴을 발견할 수 있다.
• 에러 분석에 60~80% 투자: 실패 트레이스를 도메인 전문가와 함께 분석하여 프롬프트 문제, 툴 설계 문제, 모델 한계를 구분하고, 각 유형에 맞는 대응을 취하라.
• 평가 레벨의 전략적 선택: Single-step(툴 선택), Full-turn(end-to-end 태스크 완수 + 상태 변경), Multi-turn(대화 맥락 유지) 중 Full-turn부터 시작하여 안정화 후 확장하라.
• 차원별 전문 채점기: "정확성" 하나로 뭉뚱그리지 말고 콘텐츠 정확성, 구조, 포맷, 효율성 등 차원별로 독립된 채점기를 설계해 실패 원인을 명확히 파악하라.
• Trace-to-Dataset 플라이휠: 프로덕션의 성공/실패 트레이스가 자동으로 데이터셋에 편입되고, 개선된 에이전트가 다시 프로덕션에 배포되는 순환 구조가 장기적 개선의 핵심이다.

상세 내용​

에이전트 평가의 핵심 원칙​

AI 에이전트는 전통적인 소프트웨어와 근본적으로 다르다. 소프트웨어는 결정론적이고 코드가 진리의 원천이지만, 에이전트는 LLM의 추론에 의존하며 같은 입력에도 다른 경로를 선택할 수 있다. 에이전트가 200단계를 거쳐 2분간 작업한 후 실패했을 때, 스택 트레이스는 없다. 코드가 실패한 것이 아니라 추론이 실패한 것이기 때문이다.

가장 중요한 원칙은 단순함부터 시작하는 것이다. 몇 개의 end-to-end eval로 에이전트가 핵심 태스크를 완수하는지 검증하는 것만으로도 즉시 baseline을 확보할 수 있다. 복잡한 구조는 단순한 방법이 실제 실패를 놓칠 때만 추가한다.

Eval 구축 전 준비사항​

수동 트레이스 리뷰: 30분의 투자​

자동화된 평가 인프라를 만들기 전에 반드시 해야 할 일이 있다. 실제 에이전트 트레이스 20~50개를 직접 읽어라. 30분의 수동 리뷰가 어떤 자동 시스템보다 많은 실패 패턴을 알려준다. LangSmith의 트레이스 뷰어와 Annotation Queue를 활용하면 트레이스를 효율적으로 수집하고 검토할 수 있다.

에이전트는 LLM과 툴을 여러 턴에 걸쳐 호출하고, 중간 결과에 따라 행동을 조정하며, 상태를 수정한다. 이러한 복잡한 행동은 코드를 읽는 것만으로는 예측할 수 없으며, 실제 실행 트레이스가 진리의 원천이 된다.

명확한 성공 기준 정의​

두 명의 전문가가 pass/fail에 합의할 수 없다면, 태스크 자체를 재정의해야 한다.

나쁜 예: "이 문서를 잘 요약해줘"
좋은 예: "이 회의록에서 핵심 액션 아이템 3개를 추출하라. 각각 20단어 이내, 담당자가 언급되었으면 포함할 것"

모호한 기준은 채점기의 불일치를 만들고, 무엇이 개선인지 판단할 수 없게 만든다.

Capability Eval vs Regression Eval 분리​

이 두 가지는 목적이 완전히 다르기 때문에 반드시 분리해서 관리해야 한다.

• Capability Eval ("무엇을 할 수 있는가?"): 어려운 태스크에 대한 진전을 측정한다. 초기 pass rate가 낮고, 개선의 방향을 제시한다.
• Regression Eval ("여전히 작동하는가?"): 이미 작동하는 기능을 보호한다. pass rate가 ~100%여야 하며, 기존 기능의 퇴보를 감지한다.

Capability eval만 있으면 기존 기능이 깨지고, regression eval만 있으면 개선이 멈춘다. 두 가지 모두 필요하다.

에러 분석에 60~80% 투자하라​

전체 eval 노력의 60~80%를 에러 분석에 투자해야 한다. 이것이 가장 높은 ROI를 제공하는 활동이다. 절차는 다음과 같다:

1. 대표적인 실패 트레이스를 수집한다.
2. 도메인 전문가와 함께 사전 분류 없이 모든 이슈를 기록한다(open coding).
3. 이슈를 실패 유형으로 분류한다(프롬프트 문제, 툴 설계 문제, 모델 한계, 인프라 이슈 등).
4. 새로운 실패 유형이 나오지 않을 때까지 반복한다.

실패 유형에 따라 대응이 완전히 달라진다:

• 프롬프트 문제: 지시가 불명확 → 프롬프트 수정
• 툴 설계 문제: 인터페이스가 오용을 유발 → 파라미터 재설계, 예시 추가
• 모델 한계: 지시는 명확하지만 일반화 실패 → few-shot 예시 추가, 아키텍처 변경, 모델 교체
• 아직 모름: 충분한 실패 사례를 보지 못한 상태 → 에러 분석 계속

Anthropic 팀은 SWE-bench 에이전트를 만들 때 프롬프트 최적화보다 툴 인터페이스 최적화에 더 많은 시간을 썼다고 보고했다. 예를 들어 절대 경로를 강제하면 경로 관련 에러 전체를 제거할 수 있다.

Eval 오너십과 인프라 검증​

데이터셋 유지보수, 채점기 재캘리브레이션, 새 실패 모드 분류, "충분히 좋은" 기준 결정을 한 명의 도메인 전문가가 책임져야 한다. 위원회식 의사결정은 책임 소재를 흐리고 진전을 늦춘다.

또한 인프라 문제를 먼저 배제해야 한다. Witan Labs 팀은 단일 추출 버그를 고쳤을 때 벤치마크가 50%에서 73%로 뛴 사례를 보고했다. 타임아웃, 잘못된 API 응답, 오래된 캐시 같은 인프라 이슈가 추론 실패로 위장하는 경우가 잦다.

평가 레벨 선택​

에이전트 평가는 세 가지 레벨로 나뉘며, Trace-level(Full-turn)부터 시작하는 것을 권장한다.

Single-step Eval (Run 레벨)​

"올바른 툴을 선택했는가?", "유효한 API 호출을 생성했는가?"를 평가한다. 자동화가 가장 쉽지만, 에이전트 아키텍처가 안정적일 때만 유효하다. 아키텍처가 자주 바뀌는 초기 단계에서는 특정 툴 호출 패턴에 의존하는 평가가 빠르게 obsolete해진다.

Full-turn Eval (Trace 레벨)​

대부분의 팀이 시작해야 할 레벨이다. 세 가지 차원을 함께 평가한다:

• 최종 응답: 출력이 정확하고 유용한가?
• 경로(Trajectory): 합리적인 경로를 거쳤는가? (정확한 경로가 아닌, 유효한 경로)
• 상태 변경: 올바른 아티팩트가 생성되었는가? (파일 작성, DB 업데이트, 캘린더 이벤트 등)

상태 변경 검증은 자주 간과되지만 매우 중요하다. 에이전트가 "미팅 잡았습니다!"라고 말했더라도, 실제 캘린더에 올바른 시간·참석자·설명으로 이벤트가 존재하는지 확인해야 한다. 코딩 에이전트의 경우 생성된 파일이 실행 가능한지, 유닛테스트를 통과하는지 검증해야 한다.

Multi-turn Eval (Thread 레벨)​

가장 구현이 어렵다. Trace-level eval이 안정된 후에 추가한다. N-1 테스팅 기법이 유용하다: 프로덕션의 실제 대화에서 앞 N-1턴을 그대로 주고 마지막 턴만 에이전트가 생성하게 한다. 이를 통해 완전 합성 멀티턴 시뮬레이션의 compounding error를 회피할 수 있다.

데이터셋 구성 전략​

품질이 양을 이긴다​

검증된 20~50개가 미검증 수백 개보다 낫다. 모든 태스크는 참조 솔루션(reference solution)을 포함해야 하며, 이를 통해 태스크가 풀 수 있다는 것을 증명하고 채점의 기준선을 제공한다.

나쁜 예: "NYC행 좋은 항공편 찾아줘"
좋은 예: "SFO→JFK 왕복, 12/15~17 출발, 12/22 복귀, $400 이하, 이코노미"

포지티브 + 네거티브 케이스​

"검색해야 할 때 검색하는가?"만 테스트하면, 모든 것을 검색하는 에이전트에 최적화된다. 네거티브 케이스(해당 행동을 하면 안 되는 경우)도 반드시 포함해야 한다. Anthropic은 프론티어 모델이 정적 eval의 한계를 넘어서는 창의적 해법을 발견한 사례를 보고했다—Opus 4.5가 항공권 예약 문제에서 정책의 허점을 발견해 더 나은 해법을 제시했으나, 기존 채점기로는 "실패"로 판정되었다.

에이전트 유형별 맞춤​

• 코딩 에이전트: 결정적 테스트 스위트(유닛테스트 pass/fail) + 품질 루브릭
• 대화형 에이전트: 태스크 완수 + 상호작용 품질(공감, 명확성) 다차원 평가
• 리서치 에이전트: 근거성 체크(주장이 소스에 뒷받침되는가?) + 커버리지 체크(핵심 사실이 포함되었는가?)

데이터 소싱: 3가지 전략 병행​

1. 독파운딩(Dogfooding): 팀이 매일 에이전트를 스트레스 테스트하고, 모든 에러를 eval로 전환한다.
2. 외부 벤치마크 적응: Terminal Bench, BFCL 등에서 관련 태스크를 선별하여 자신의 에이전트에 맞게 변환한다.
3. 수작업 행동 테스트: "에이전트가 툴 호출을 병렬화하는가?", "모호한 요청에 명확화 질문을 하는가?" 등 특정 행동을 검증하는 테스트를 직접 작성한다.

Trace-to-Dataset 플라이휠​

프로덕션의 성공/실패 트레이스가 지속적으로 데이터셋에 편입되는 파이프라인을 구축한다. LangSmith를 사용하면 트레이스 → 어노테이션 큐 → 데이터셋 → 실험의 흐름을 자동화할 수 있다.

채점기(Grader) 설계​

차원별 전문 채점기​

하나의 "정확성" 채점기 대신 차원별로 분리하라. Witan Labs 팀은 콘텐츠 정확성, 구조, 시각 포맷, 수식 시나리오, 텍스트 품질 등 5개의 전문 평가기를 만들어 어디가 실패하는지 명확한 시그널을 얻었다.

채점기 유형	적합한 용도	주의점
코드 기반	결정적 체크, 툴 호출 검증, 출력 포맷, 실행 결과	유효하지만 예상치 못한 포맷에서 false-fail 가능
LLM-as-judge	뉘앙스 있는 품질, 루브릭 기반 채점, 개방형 태스크	사람과의 캘리브레이션 필수
사람	캘리브레이션, 주관적 기준, 엣지 케이스	비용 높고 느리며 확장 어려움

객관적 정답이 있는 경우 코드 기반을 기본으로 사용한다. LLM-as-judge를 객관적 태스크에 쓰면 불일치가 실제 regression을 가릴 수 있다.

Guardrail vs Evaluator 구분​

	Guardrail	Evaluator
실행 시점	실행 중, 사용자가 출력을 보기 전	생성 후, 비동기
속도	밀리초 (빠를 것)	초~분 (비용 투자 가능)
목적	위험하거나 잘못된 출력 차단	품질 측정 및 regression 감지
예시	PII 탐지, 포맷 검증, 안전 필터	LLM-as-judge 채점, 경로 분석

바이너리 pass/fail 선호​

1~5점 척도는 인접 점수 간 주관적 차이를 만들고, 통계적 유의미성을 위해 더 큰 샘플이 필요하다. 바이너리는 더 명확한 사고를 강제한다: 성공했거나 실패했거나. 복잡한 태스크는 여러 개의 바이너리 체크로 분해한다.

LLM-as-judge 캘리브레이션​

• LangSmith Align Evaluator로 20개 이상의 라벨 예시로 시작, 프로덕션급 신뢰도를 위해 ~100개까지 확대
• 채점기의 출력에 **판단 근거(reasoning)**를 포함시켜 정확도를 높이고 감사 가능성 확보
• 정기적 재캘리브레이션 필수 — 채점기는 시간이 지나면 드리프트함
• few-shot 예시를 사용해 일관성 향상

결과를 채점하라, 경로가 아니라​

에이전트는 창의적인 경로를 찾는다. "check_availability → create_event 순서로 호출했는가?"가 아니라 **"미팅이 올바르게 잡혔는가?"**를 평가해야 한다. 다만 효율성 측정을 위해 이상적 경로 대비 실제 스텝 수를 추적하는 것은 유용하다. 이것은 정확성 채점이 아니라 효율성 메트릭이다.

부분 점수(partial credit)도 고려한다. 문제를 정확히 식별했지만 마지막 단계에서 실패한 에이전트는, 처음부터 실패한 에이전트보다 낫다.

커스텀 평가기 사용​

"helpfulness"나 "coherence" 같은 범용 메트릭은 거짓 확신을 만든다. 에러 분석에서 발견한 특정 실패 모드를 잡는 커스텀 평가기가 실제로 의미 있는 시그널을 준다. Deep Agents 팀은 각 eval에 docstring을 작성하여 무엇을 측정하는지 자체 문서화하고, tool_use 같은 카테고리 태그로 그룹 실행을 가능하게 한다.

실행 및 반복​

세 가지 평가 타이밍​

타이밍	정의	용도
Offline	큐레이션된 데이터셋, 배포 전 실행	변경사항을 출시 전에 검증
Online	프로덕션 트래픽에 대한 지속적 평가	실 트래픽에서 실패 포착
Ad-hoc	수집된 트레이스에 대한 탐색적 분석	예상 못한 패턴 발견

세 가지를 모두 활용해야 한다. Offline은 배포 전 품질 게이트, online은 프로덕션 모니터링, ad-hoc은 새로운 인사이트 발견에 각각 필수적이다.

비결정성 대응​

모델 출력은 실행마다 달라진다. 태스크당 여러 번 반복 실행하고, 개선을 선언하기 전에 신뢰구간을 계산한다. 제품 요구사항에 따라 pass@k(k번 중 1번 이상 성공) 또는 pass^k(k번 모두 성공) 메트릭을 선택한다.

실행 환경 격리​

시행 2가 시행 1의 아티팩트를 볼 수 있으면 결과가 독립적이지 않다:

• 코딩 에이전트: 시행마다 새 컨테이너/VM
• API 호출 에이전트: 스테이징 환경 또는 모의 서비스
• DB 에이전트: 시행 간 스냅샷 복원

메타데이터와 효율성 메트릭​

실험마다 모델, 프롬프트 버전, 검색 전략 등의 메타데이터를 기록하여, "GPT-4.1에서 Claude Sonnet으로 바꾸면 정확도가 오르는가?" 같은 질문에 답할 수 있게 한다.

품질과 함께 효율성 메트릭도 추적한다: 실제 스텝 수 / 이상적 스텝 수, 툴 호출 횟수, 토큰 사용량, 지연시간. 정확도 95%이지만 10배 느린 에이전트는 개선이 아닐 수 있다.

Pass Rate 정체 시 대응​

같은 유형의 태스크를 더 추가해도 새로운 실패 모드가 발견되지 않으면, 더 어려운 태스크를 추가하거나, 새로운 기능을 테스트하거나, 다른 차원으로 이동한다. 포화된 eval 세트를 반복하는 것은 시간 낭비다.

의미 있는 Eval만 유지하라​

모든 eval은 시스템에 압력을 가한다. 무분별하게 수백 개를 추가하면 프로덕션에서 중요하지 않은 것에 최적화하게 된다. 더 많은 eval이 더 나은 에이전트를 의미하지는 않는다. 주기적으로 시그널을 주지 않는 eval을 제거한다.

Task Failure vs Evaluation Failure 구분​

실행 상태를 명시적으로 추적한다(완료, 에러, 타임아웃). 타임아웃을 "추론 실패"로 채점하면 메트릭이 오염된다. 에이전트의 실패와 채점기의 실패를 분리해야 한다.

프로덕션 준비​

CI/CD 파이프라인 통합​

일반적인 흐름:

1. 코드/프롬프트 변경이 파이프라인을 트리거한다.
2. Offline eval 실행: 유닛테스트, 통합테스트, 큐레이션 데이터셋 대비 평가 (저비용·고속 코드 기반 채점기).
3. offline eval 통과 시 preview 배포.
4. preview에서 online eval 실행 (LLM-as-judge 채점기).
5. 모든 품질 게이트 통과 시에만 프로덕션 프로모트. 실패 시 해당 트레이스를 annotation queue로 라우팅하고 팀에 알림.

매 커밋마다 저비용 코드 기반 채점기를 CI에서 돌리고, 비용이 높은 LLM-as-judge는 preview/프로덕션 단계에 사용한다.

유저 피드백의 중요성​

자동 eval은 이미 알고 있는 실패 모드만 잡는다. 사용자가 발견하는 것들이 있다: 데이터셋이 놓친 엣지 케이스, 기술적으로는 맞지만 도움이 안 되는 출력, 예상 못한 방식으로 깨지는 워크플로우. 구조화된 피드백을 데이터셋에 편입하고, 채점기를 실제 기대치에 맞게 캘리브레이션하고, 사용자에게 실제로 중요한 개선에 우선순위를 둔다.

프로덕션 플라이휠​

프로덕션의 성공과 실패가 데이터셋, 에러 분석, eval 개선으로 되돌아가는 순환 구조를 구축한다. 이것이 에이전트를 시간이 지남에 따라 개선시키는 플라이휠이다:

프로덕션 트레이스 → 에러 분석 → 데이터셋 업데이트 → Eval 개선 → 에이전트 개선 → 프로덕션 배포 → (반복)

Capability → Regression 승격​

꾸준히 높은 pass rate를 보이는 capability eval을 regression suite로 승격한다. "할 수 있는가?"를 검증한 태스크가 "여전히 할 수 있는가?"를 보호하는 태스크로 전환된다.

전체 체크리스트 요약​

Eval 구축 전

• ☑️ 20~50개 실제 트레이스 수동 리뷰
• ☑️ 명확한 성공 기준 정의
• ☑️ Capability/Regression eval 분리
• ☑️ 실패 원인 식별 및 분류
• ☑️ 단일 도메인 전문가에게 오너십 부여
• ☑️ 인프라 문제 배제

평가 레벨 선택

• ☑️ Trace-level(Full-turn)부터 시작
• ☑️ 최종 응답 + 경로 + 상태 변경 함께 평가
• ☑️ 아키텍처 안정화 후 Single-step 추가
• ☑️ Multi-turn은 N-1 테스팅 기법 활용

데이터셋 구성

• ☑️ 모든 태스크에 참조 정답 포함
• ☑️ 포지티브 + 네거티브 케이스 균형
• ☑️ 검증된 20~50개부터 시작
• ☑️ 독파운딩 + 외부 벤치마크 적응 + 수작업 병행
• ☑️ Trace-to-Dataset 파이프라인 구축
• ☑️ 에이전트 유형별 맞춤 설계

채점기 설계

• ☑️ 차원별 전문 채점기 분리
• ☑️ Guardrail과 Evaluator 구분
• ☑️ 바이너리 pass/fail 선호
• ☑️ LLM-as-judge는 20+ 예시로 캘리브레이션
• ☑️ 결과를 채점, 경로는 효율성 메트릭으로
• ☑️ 에러 분석 기반 커스텀 평가기

실행 및 반복

• ☑️ Offline/Online/Ad-hoc 세 가지 타이밍 활용
• ☑️ 비결정성 대응: 반복 실행 + 신뢰구간
• ☑️ 실행 환경 격리
• ☑️ 메타데이터 + 효율성 메트릭 추적
• ☑️ 실패 트레이스 수동 검토
• ☑️ 포화된 eval 제거, 의미 있는 것만 유지
• ☑️ Task/Evaluation Failure 구분

프로덕션 준비

• ☑️ CI/CD 파이프라인 통합
• ☑️ 온라인 평가 지속 실행
• ☑️ 유저 피드백 구조화 수집
• ☑️ 프롬프트/툴 정의 버전 관리
• ☑️ Capability → Regression 승격
• ☑️ 프로덕션 플라이휠 구축

References​

• Agent Evaluation Readiness Checklist — Victor Moreira, LangChain
• Agent Observability Powers Agent Evaluation — LangChain
• How we build evals for Deep Agents — LangChain
• Demystifying Evals for AI Agents — Anthropic Engineering
• Building Effective Agents — Anthropic Research
• LLM Evals: Everything You Need to Know — Hamel Husain
• Witan Labs Research Log — Witan Labs

TL;DR​

LangSmith는 LLM 애플리케이션의 PoC 단계에서 필수적인 모니터링과 평가를 지원하는 도구입니다. Chat UI 기반 서비스 배포 시, 실시간으로 프롬프트 성능을 추적하고 데이터셋 기반 평가를 수행할 수 있습니다. 이 가이드라인은 AI Research Engineer가 PoC 서비스의 품질을 체계적으로 관리하고 개선하기 위한 모니터링과 평가 프로세스를 제공합니다.

Key Takeaways​

• PoC 단계에서의 체계적 추적: LangSmith를 통해 Chat UI 기반 서비스의 모든 LLM 호출과 응답을 실시간으로 추적하여 초기 단계부터 품질을 관리할 수 있습니다.
• Monitoring과 Evaluation의 분리: 실시간 모니터링으로 프로덕션 이슈를 즉시 파악하고, 오프라인 평가로 체계적인 성능 개선을 수행하는 이원화된 접근이 필요합니다.
• 데이터 기반 의사결정: 실제 사용자 인터랙션 데이터를 수집하고 평가 데이터셋으로 전환하여 프롬프트 엔지니어링과 모델 선택에 활용할 수 있습니다.
• Chat UI 특화 메트릭: 대화형 인터페이스의 특성상 응답 시간(latency), 토큰 사용량, 대화 흐름의 연속성 등 특화된 메트릭 추적이 중요합니다.

상세 내용​

LangSmith 개요​

LangSmith는 LangChain 생태계에서 제공하는 LLM 애플리케이션 개발 및 운영을 위한 통합 플랫폼입니다. 특히 PoC(Proof of Concept) 단계에서 빠르게 프로토타입을 검증하고 개선해야 하는 Research Engineer에게 유용한 도구로, 복잡한 인프라 구축 없이도 전문적인 모니터링과 평가 환경을 제공합니다.

Monitoring: 실시간 추적과 디버깅​

Monitoring의 목적

PoC 서비스 배포 시 Monitoring은 다음과 같은 목적을 달성합니다:

• 실시간 LLM 호출 추적 및 로깅
• 예상치 못한 에러나 품질 저하 즉시 감지
• 사용자 피드백과 실제 응답 연결
• 비용 및 리소스 사용량 모니터링

Chat UI 환경에서의 Monitoring 구현

Chat UI 기반 서비스는 일반적으로 다음과 같은 특성을 가집니다:

• 멀티턴 대화로 인한 컨텍스트 누적
• 실시간 스트리밍 응답 요구
• 사용자 경험에 민감한 레이턴시

LangSmith는 이러한 특성을 고려하여 각 대화 세션을 trace로 묶어 추적하고, 개별 LLM 호출을 span으로 기록합니다. 이를 통해 대화 전체의 흐름과 각 단계별 성능을 동시에 파악할 수 있습니다.

핵심 모니터링 메트릭

• Latency: 첫 토큰까지의 시간(TTFT)과 전체 응답 시간
• Token Usage: 입력/출력 토큰 수와 비용 환산
• Error Rate: 실패한 요청의 비율과 에러 타입
• Feedback Scores: 사용자 평가(thumbs up/down) 수집

Evaluation: 체계적 성능 평가​

Evaluation의 필요성

Monitoring이 '무엇이 일어났는가'를 추적한다면, Evaluation은 '얼마나 잘 작동하는가'를 측정합니다. PoC 단계에서 Evaluation은:

• 프롬프트 버전 간 성능 비교
• 다양한 LLM 모델 벤치마킹
• 레그레션(regression) 방지
• 프로덕션 준비도 판단 기준 제공

데이터셋 구축

효과적인 Evaluation을 위해서는 품질 좋은 데이터셋이 필수적입니다:

1. Monitoring 데이터 활용: 실제 사용자 쿼리 중 대표적인 케이스 선별
2. Edge Case 추가: 예외 상황, 어려운 질문, 모호한 요청 등 포함
3. Ground Truth 정의: 기대되는 올바른 응답 또는 평가 기준 명시
4. 지속적 업데이트: 새로운 사용 패턴과 실패 케이스 반영

평가 메트릭 설정

Chat UI 서비스의 특성에 맞는 평가 메트릭 예시:

• 정확성(Correctness): LLM-as-a-Judge를 활용한 응답 품질 평가
• 관련성(Relevance): 사용자 질문과 응답의 연관성
• 완전성(Completeness): 필요한 정보를 모두 포함하는지 여부
• 일관성(Consistency): 동일 질문에 대한 응답의 안정성
• 안전성(Safety): 유해 콘텐츠 생성 여부

반복적 개선 프로세스

LangSmith를 활용한 전형적인 개선 사이클:

1. Baseline 설정: 초기 프롬프트/모델로 평가 실행
2. 문제 영역 식별: 낮은 점수를 받은 케이스 분석
3. 가설 수립: 프롬프트 수정 또는 모델 변경 방안 도출
4. 실험 실행: 새 버전으로 동일 데이터셋 재평가
5. 비교 분석: 버전 간 메트릭 비교로 개선 여부 확인
6. 배포 결정: 충분한 개선 확인 시 PoC 환경에 적용

PoC 단계 Best Practices​

1. 초기부터 추적 설정

개발 시작부터 LangSmith 통합을 구축하면 초기 실험 데이터도 유용한 학습 자료가 됩니다.

2. 사용자 피드백 수집 자동화

Chat UI에 간단한 평가 버튼을 추가하여 실시간 피드백을 LangSmith로 전송합니다.

3. 주간 평가 루틴 수립

일주일마다 누적된 데이터를 분석하고 평가 데이터셋을 업데이트하는 루틴을 만듭니다.

4. 비용 모니터링 중요성

PoC 단계에서 비용 효율성을 고려하지 않으면 프로덕션 전환 시 장애물이 됩니다.

한계와 고려사항​

• LangSmith는 LangChain 생태계와 가장 잘 통합되지만, 다른 프레임워크 사용 시 추가 작업이 필요할 수 있습니다.
• 민감한 사용자 데이터는 로깅 전 익명화 또는 필터링 처리가 필요합니다.
• PoC 단계의 트래픽 규모와 프로덕션 규모 차이를 고려한 확장성 검토가 필요합니다.

References​

• 원본 문서: LangSmith를 활용한 PoC Monitoring & Evaluation (내부 가이드라인)
• LangSmith 공식 문서
• LangChain 공식 사이트

TL;DR​

실리콘밸리 AI 프로덕트 개발의 핵심이 "어떤 모델을 쓸까"에서 "성능을 어떻게 측정할까"로 전환되고 있습니다. 평가 시스템(Evals)은 단순한 QA가 아니라 AI 애플리케이션의 데이터 분석이자 새로운 기획서(PRD)입니다. 로그를 직접 분석하는 '노가다'부터 시작해 LLM-as-a-Judge로 자동화하면, 회귀 방지, 비용 절감, 신뢰성 확보라는 세 마리 토끼를 잡을 수 있습니다. 완벽한 평가 지표보다 중요한 것은 "어제보다 나아졌는지" 확인하는 반복 가능한 시스템을 구축하는 것입니다.

Key Takeaways​

• "Vibe Check"의 시대는 끝났다: 프롬프트 수정 시 발생하는 회귀(Regression) 현상을 방지하려면 체계적인 평가 시스템이 필수적이며, 이는 AI 제품의 핵심 경쟁력(Moat)이 됩니다.
• 로그 분석이 혁신의 출발점: 거창한 MLOps 툴보다 50~100개의 실제 대화 로그를 직접 읽고 패턴을 찾는 '오픈 코딩' 방식이 가장 빠르고 효과적인 인사이트를 제공합니다.
• LLM-as-a-Judge는 이진 분류로 설계하라: "품질을 1~5점으로 평가"하는 모호한 지시 대신, "경쟁사 언급 포함 여부(True/False)" 같은 명확한 이진 질문이 신뢰할 수 있는 자동 평가를 가능하게 합니다.
• Evals는 새로운 PRD다: 에이전트 기반 복잡한 워크플로우에서는 각 단계의 의도 검증이 필수이며, 테스트 케이스 자체가 제품 요구사항 정의서 역할을 대신합니다.
• 평가 기준이 있으면 비용을 절감할 수 있다: 고성능 모델(GPT-4o) 대신 저비용 모델(GPT-4o-mini, Llama 3)로 동일한 품질을 달성할 수 있는지 객관적으로 테스트하여 운영 비용을 획기적으로 낮출 수 있습니다.

상세 내용​

AI 프로덕트 품질 보장의 패러다임 전환​

최근 실리콘밸리에서 AI 프로덕트를 만드는 팀들 사이에서 기류가 바뀌고 있습니다. 작년까지만 해도 "어떤 파운데이션 모델(GPT-4o, Claude 3.5 Sonnet)을 쓸까?"가 논의의 핵심이었다면, 지금은 **"내 AI가 헛소리를 안 한다는 걸 어떻게 보장할 것인가?"**로 주제가 옮겨갔습니다.

Lenny's Podcast에 출연한 머신러닝 엔지니어 하멜 후세인(Hamel Husain)과 슈레야 샨카(Shreya Shankar)의 대담은 이 지점에서 매우 중요한 시사점을 던집니다. 그들은 AI 제품 개발의 성패가 모델의 성능 그 자체가 아니라, 그 성능을 측정하는 **'평가 시스템(Evaluations, Evals)'**의 유무에 달려 있다고 강조합니다.

단순히 몇 번 써보고 "느낌 좋은데?(Vibe Check)"라며 배포하던 낭만의 시대는 끝났습니다. 이제는 집요한 평가(Evaluation)가 곧 제품의 해자(Moat)가 되는 시대입니다.

"감(Vibe)"에 의존하는 개발의 치명적 함정​

생성형 AI 서비스를 기획하고 개발하다 보면 치명적인 착각에 빠지기 쉽습니다. 프롬프트를 몇 번 수정하고, 테스트 케이스 10개 정도를 돌려본 뒤 답변이 그럴듯하면 "개발 완료"를 외치는 것이죠.

하지만 라이브 환경은 다릅니다. 사용자는 우리가 상상하지 못한 엣지 케이스(Edge Case)를 끊임없이 던집니다. 이때 개발팀이 직면하는 가장 큰 문제는 **'수정의 딜레마'**입니다. 사용자 불만을 해결하기 위해 프롬프트를 수정했더니, 기존에 잘 동작하던 기능이 망가지는 '회귀(Regression)' 현상이 발생합니다.

시스템적인 평가 기준이 없다면, 우리는 AI가 더 똑똑해진 건지 멍청해진 건지 알 방법이 없습니다. Evals는 단순한 QA 테스트가 아닙니다. AI 애플리케이션에 대한 '데이터 분석' 그 자체입니다.

로그를 직접 읽는 '노가다'가 혁신의 시작​

많은 팀이 자동화된 MLOps 툴이나 거창한 대시보드부터 도입하려 합니다. 하지만 가장 빠르고 확실한 방법은 원시 데이터(Raw Data)를 직접 눈으로 확인하는 것입니다.

Step 1: 오픈 코딩 (Open Coding)​

우선 AI와 사용자가 나눈 대화 로그(Trace)를 무작위로 50~100개 정도 읽어보세요. 그리고 이상한 부분이 보일 때마다 직관적인 메모를 남깁니다.

• "답변이 너무 장황함"
• "경쟁사 제품을 추천함 (Hallucination)"
• "JSON 포맷이 깨짐"

거창한 분류 체계는 필요 없습니다. 일단 눈에 띄는 문제들을 날것 그대로 적는 것이 중요합니다.

Step 2: 패턴의 범주화 (Categorization)​

100개 정도의 로그만 봐도 문제의 패턴이 보이기 시작합니다. 이제 LLM을 활용해 앞서 남긴 메모들을 그룹화합니다. '부정확한 정보', '톤앤매너 위반', '포맷 오류' 등으로 유형을 묶고, 피벗 테이블(Pivot Table)을 돌려보세요.

여기서 중요한 건 **'우선순위'**입니다. 모든 문제를 다 고칠 순 없습니다. 빈도수가 가장 높고, 비즈니스에 치명적인 문제(예: 고객에게 욕설을 하거나, 잘못된 법률 정보를 제공하는 것)를 찾아내야 합니다.

Step 3: 자비로운 독재자 (Benevolent Dictator)​

이 과정에서 흔히 저지르는 실수가 '민주적인 합의'를 하려는 것입니다. "이 답변이 좋은가?"에 대한 기준은 사람마다 다릅니다. 여러 명이 모여 토론하느라 시간을 낭비하지 마세요.

도메인 지식이 가장 풍부한 한 명(주로 PM이나 리드 엔지니어)이 기준을 잡고 빠르게 데이터를 라벨링하는 것이 훨씬 효율적입니다. 초기 단계에서는 속도와 일관성이 완벽함보다 중요합니다.

LLM을 판사로 세우기: 자동화 전략​

패턴이 파악되었다면 이제 자동화할 차례입니다. 매번 사람이 로그를 볼 수는 없으니까요. 이때 LLM을 평가자(Judge)로 활용합니다.

여기서 핵심 팁은 평가 기준을 단순화하는 것입니다. "이 답변의 품질을 1~5점으로 평가해줘"라는 모호한 지시는 실패할 확률이 높습니다. 대신 이진 분류(Binary) 질문을 던지세요.

"이 답변에 경쟁사 제품에 대한 언급이 포함되었는가? (True/False)"

명확한 기준은 LLM도 잘 판단합니다. 그리고 LLM이 내린 평가가 사람(Human)의 판단과 일치하는지 검증하는 과정을 거치면, 신뢰할 수 있는 자동 평가 파이프라인이 완성됩니다.

Evals는 '새로운 기획서(New PRD)'다​

이러한 평가 체계 구축은 단순히 버그를 잡는 것을 넘어 제품 기획의 패러다임을 바꿉니다.

최근 주목받는 에이전트(Agentic Workflow) 기반 서비스나 LangGraph 같은 복잡한 구조에서는 각 단계가 의도대로 작동하는지 확인하는 단위 테스트(Unit Test)가 필수적입니다. 과거 제품 요구사항 정의서(PRD)에 "사용자에게 친절해야 한다"라고 적었다면, 이제는 "사용자가 모욕적인 언사를 해도 정중하게 거절하는지 판단하는 테스트 케이스" 자체가 기획서의 역할을 대신합니다.

비용 절감의 핵심 무기로서의 Evals​

잘 짜인 Evals는 비용 절감의 핵심 무기가 됩니다. 우리는 불안하기 때문에 무조건 성능 좋은 고비용 모델(GPT-4o 등)을 씁니다. 하지만 우리만의 평가 기준(Eval)이 있다면, 특정 태스크에서 더 저렴한 모델(GPT-4o-mini, Llama 3 등)이 동일한 점수를 내는지 테스트해 볼 수 있습니다.

평가를 통과한다면 과감하게 모델을 교체하여 운영 비용을 획기적으로 낮출 수 있습니다. 이는 막연한 불안감이 아닌 데이터 기반의 의사결정을 가능하게 합니다.

완벽함을 버리고 데이터와 직면하라​

많은 팀이 Evals를 "어렵고 복잡한 엔지니어링 과제"로 생각하여 시작조차 하지 못합니다. 하지만 목표는 완벽한 학술적 평가 지표를 만드는 것이 아닙니다. 오늘 우리 제품이 어제보다 나아졌는지 확인하는 것입니다.

지금 당장 여러분의 AI 제품 로그를 열어 30분만 투자해서 유저들이 어떤 대화를 나누고 있는지, AI가 어디서 헤매고 있는지 눈으로 확인해 보세요. 그 '30분의 노가다'가 수천만 원짜리 툴보다 훨씬 강력한 인사이트를 줄 것입니다.

평가 시스템은 한 번에 완벽하게 구축하는 것이 아니라, 작은 규모로 시작해 점진적으로 확장하는 것입니다. 첫 50개의 로그 분석에서 시작해, 패턴을 발견하고, 이진 분류 기준을 만들고, LLM으로 자동화하고, 사람의 평가와 비교하며 신뢰도를 높여가는 이 반복 가능한 프로세스가 바로 AI 시대의 진정한 제품 개발 방법론입니다.

References​

• AI시대 기획서(PRD)는 죽었다. 실리콘밸리가 지금 "Evals"에 목숨 건 이유 - 이오플래닛
• Why AI evals are the hottest new skill for product builders | Hamel Husain & Shreya Shankar - Lenny's Podcast