요약
Arize AI의 프로덕트 매니저 Aman Khan이 AI 제품 관리자와 엔지니어가 어떻게 평가(evaluation) 시스템을 함께 구축하여 신뢰할 수 있는 AI 제품을 만들 수 있는지에 대한 실전 플레이북을 제시합니다. 프로토타입 단계부터 프로덕션 모니터링까지, 팀 간 협업을 통해 효과적인 평가 시스템을 구축하는 구체적인 방법론을 다룹니다.
주요 내용
1. AI PM의 세 가지 유형
- AI Platform PM: 회사 전체에서 모델과 데이터가 올바르게 작동하도록 관리하는 역할. LLM API 선택, PII 데이터 관리, 모델 전략 수립 등을 담당
- AI Powered PM: Cursor와 같은 도구를 활용하여 자신의 업무 워크플로우를 개선하고, 에이전트를 구축하여 더 효율적이고 효과적으로 일하는 PM
- AI Product PM: AI가 최종 제품에서 어떤 형태로 구현될지 결정하는 역할. 챗봇, RAG, 백그라운드 에이전트 등의 형태 결정하고, AI 엔지니어와 협업하여 평가 시스템을 구축
2. Eval Journey: 세 단계 진화
1단계: Vibe Coding/Vibe Eval
- 프로토타입 단계에서 출력물을 직접 보고 판단
- 내부 사용이나 프로토타입에는 적합하지만, 비즈니스 결정이나 실제 고객에게 제공하기에는 부족
- 예시: 문서 기반 고객 지원 봇을 빠르게 구축하지만, 일부 사용자에게는 작동하지 않는 상황
2단계: Writing Evals
- LLM이 환각(hallucination)을 일으키므로 평가 시스템이 필요
- Anthropic CPO의 조언: “평가 작성이 가장 중요한 것”
- 하지만 단순히 평가를 작성하는 것만으로는 부족 – 팀이 그 평가를 신뢰해야 함
- 평가를 작성했더라도 “이 평가를 신뢰할 수 있는가?”라는 질문에 직면
3단계: Eval in Development and Production
- 평가 시스템이 신뢰할 수 있고, 시스템이 작동하며, 지속적인 개선 루프가 확립된 상태
- 사용자 피드백을 받아 데이터를 분석하고, 실패 사례를 데이터셋에 추가하여 반복적으로 개선
- Observability와 Eval이 긴밀하게 연결되어 작동
3. Eval vs Unit Tests: 근본적인 차이
전통적인 소프트웨어 테스트 (Unit Tests)
- 일본의 열차처럼 예측 가능하고 결정론적
- 1 + 1 = 2가 항상 성립
- 기존 코드베이스와 문서에 의존
AI Eval
- 뉴욕에서 운전하는 것처럼 복잡하고 혼돈적인 환경
- LLM은 비결정론적(non-deterministic) 시스템
- 실제 세계 데이터에 의존하여 개선
- 운전면허 시험처럼 복잡한 환경에서의 행동을 측정
4. 평가의 종류
LLM as a Judge
- 가장 일반적인 평가 방법
- Accuracy, Hallucination, Q&A 등 기본 템플릿 제공
- 하지만 팀의 특정 실패 모드와 사용 사례에 맞춘 맞춤형 평가 개발이 필수
- 세 가지 핵심 요소: Eval Prompt (무엇을 평가할지), LLM (성능/비용/정확도), Data (입력/출력/기대 출력/레이블)
Code-based Eval
- 간단한 문자열 체크나 코드 정확성 검증
- 결정론적이고 실행 비용이 저렴
- 예: 출력이 항상 JSON 형식인지, 경쟁사를 언급하지 않는지 확인
Human Annotation
- 데이터 레이블링과 검토
- 워크플로우의 핵심 부분
- PM이 데이터 품질에 깊이 관여해야 하는 이유
Business Metrics
- 최종적으로 중요한 것은 비즈니스 지표
- Human-in-the-loop, NPS, 전환율 등
- Eval은 이러한 비즈니스 메트릭으로 가는 신호를 제공
5. PM의 Eval 참여가 중요한 이유
데이터 품질 = 제품 품질
- Eval prompt 작성자는 레이블 작성 담당자와 밀접하게 연결되어야 함
- LLM as a Judge 시스템의 목표는 인간의 판단과 일치하는 것
- PM이 데이터 품질에 관여하지 않으면 AI 시스템 품질을 다른 팀에 아웃소싱하는 것과 같음
계층적 평가 구조
- 최상위: 비즈니스/제품 메트릭 (세션/사용자 레벨)
- 중간: Thumbs up/down (노이즈가 있지만 유용한 신호)
- 하위: 세부 평가 (올바른 데이터 검색, 올바른 데이터 사용, 명확한 설명)
6. Observability와 Eval의 필수적 연결
왜 Observability가 중요한가
- Eval 없이는 아무것도 할 수 없음
- 스프레드시트는 초기에는 괜찮지만 확장되지 않음
- 오픈 소스 표준(OpenTelemetry 등)을 지원하는 도구 선택 필수
핵심 용어
- Traces: 에이전트의 단일 실행 과정
- Spans: 개별 상호작용 또는 데이터의 행
- Sessions: 여러 Traces의 모음 (사용자와 AI 에이전트 간의 여러 왕복)
- Data Sets: 평가에 사용되는 데이터 모음
핵심 인사이트
- Eval은 Unit Test가 아니다: AI 평가는 복잡하고 비결정론적인 환경에서의 행동을 측정하는 것으로, 전통적인 소프트웨어 테스트와 근본적으로 다른 접근이 필요합니다.
- PM은 데이터 품질에 직접 관여해야 한다: PM이 레이블링과 평가 프롬프트 작성에 참여하지 않으면 AI 제품의 품질을 다른 팀에 아웃소싱하는 것과 같습니다. 데이터 품질이 곧 제품 품질입니다.
- 계층적 평가가 필요하다: 사용자의 thumbs down이 반드시 시스템 실패를 의미하지 않으며, span/trace/session 레벨에서 세부적으로 분석해야 진짜 문제를 찾을 수 있습니다.
- 빠른 출시와 반복이 핵심이다: 많은 팀이 완벽한 시스템을 만들려고 너무 오래 기다립니다. 1% 사용자에게 빠르게 출시하고 피드백을 받아 개선하는 것이 더 효과적입니다.
- Observability 없이는 Eval도 없다: 오픈 소스 표준(OpenTelemetry 등)을 지원하는 observability 시스템이 필수적이며, 이는 vendor lock-in을 방지하고 지속적인 개선을 가능하게 합니다.
- 역할의 경계가 무너지고 있다: AI 시대에는 PM이 더 기술적이 되고, 엔지니어가 더 고객 지향적이 되며, 두 역할이 공통 언어(traces, spans, eval)로 소통하며 협업합니다.