Shipping AI That Works: An Evaluation Framework for PMs - Aman Khan, Arize

영상 링크: Shipping AI That Works: An Evaluation Framework for PMs – Aman Khan, Arize
채널명: AI Engineer

잘 동작하는 AI 출시: PM을 위한 평가 프레임워크 핵심 요약

• 아라이지(Arize)사의 AI PM 아만 칸이 직접 공유한 평가 시스템 및 실제 실습 기반 워크숍
• 스포티파이, 우버, 인스타카트 등 대형 AI 활용 기업의 실사례를 바탕으로, ‘eval(에발, AI 평가)‘의 필요성과 설계, 운영법을 제시
• LLM 기반 에이전트 시스템의 ‘비결정적·다경로’ 특성 때문에 기존 SW 테스팅과 본질적으로 다름을 강조
• AI 트립 플래너(여행 일정 짜기) 멀티 에이전트 예제를 실습하며 프로토타이핑부터, 프롬프트 플레이그라운드 활용, 데이터셋 구축→평가 실행까지 구체적 절차 시연
• Eval 프레임워크를 설계할 때 ‘LLM as a Judge’ 방식(LLM으로 레이블 생성)이 대규모 확장성과 반복 실행에 적합하다고 강조
• PM(프로덕트 매니저)이 프롬프트 설계 및 평가 기준(acceptance criteria)을 소유 테스트하여, 기존 PRD 문서 대신 ‘평가 데이터셋’ 자체를 요구 명세로 활용할 수 있음을 제안
• Arize 및 오픈소스 Phoenix를 활용해 트레이스·스팬·프롬프트 버전 관리, 프롬프트 체이닝, AB 테스트, 프로그램적 이밸실행 등 고도화된 에이전트 개발·운용 워크플로우를 공개
• 모델의 신뢰성(환각 등) 한계 때문에, LLM 자동 평가(LLM as a Judge)와 휴먼 라벨 대조, 코드 기반 매칭 등 다층 검증이 필수임을 실제 데이터 기반으로 확인
• PM이 기술적 실습까지 직접 해야 하는 시대 도래: 프로토타입 신속 구현, 프롬프트 반복 최적화 권장
• Q&A 세션에서 실무 데이터셋 구축, 휴먼 인더루프, 역량 스택 기반 조직 재편 등 다양한 현장 문제와 모범 사례 공유

세부 요약 - 주제별 정리

발표자는 스포티파이·크루즈 등에서 AI 평가 시스템을 설계하며 실제 대기업의 실전 문제를 해결해 옴

• 아만 칸(Aman Khan)은 크루즈(Cruise)에서 자율주행차 AI 평가 시스템 PM을 역임(2018~2019)하며 ML 시스템 신뢰성 확보 경험 쌓음
• 스포티파이(Spotify)에도 합류하여 ML 플랫폼, 추천/검색(Discover Weekly, Embedding 활용 등) 관련 PM 경험
• 현재는 Arize에서 3년 반째 재직, ‘AI 평가 시스템’ SaaS 상품을 구축하는 동시에, 과거 매니저들에게 플랫폼도 실제로 판매함
• Uber, Instacart, Reddit, Duolingo 등 고도화된 AI/ML 도입 기업의 에이전트·생성AI·랭킹/분류 등 다양한 실제 use case를 긴밀히 지원
• 기존 ML(분류/회귀 등)에서 최신 생성형AI, 멀티에이전트/코드 에이전트 등으로 적용범위 확장
• 고객사 서비스 실제 운영 중에도, AI가 ‘예상대로’ 동작하는지 정량적 신뢰성 확보하는 것이 핵심 과제
• 업계 선도 사례/문제점을 현장에서 받아들여, 제품에 적극적으로 반영 중

LLM 및 에이전트 시스템의 특성상 평가(eval) 및 관측(Observability)는 기존 SW와 전혀 다른 필수 항목임

• LLM/에이전트는 본질적으로 비결정적(nondeterministic) 운영 및 여러 작동 경로(branching, tool-calling) 존재
• SW의 테스팅(1+1=2처럼)과 달리 같은 입력에도 결과가 항상 다를 수 있음
• LLM의 환각(hallucination)은 기본 속성: OpenAI, Anthropic 등 시장 점유율 95%의 CMOs도 “모델은 항상 hallucinate 한다”고 공식 발표
• 신뢰성이 제한적임을 파는 쪽(모델 제공자)도 인정 → 평가 시스템 구축, 다층 검증이 필수
• AI의 진입 장벽 및 고객 신뢰 확보 경쟁에서 eval 시스템이 스타트업의 B2B/엔터프라이즈 진입에 있어 실제적인 무기가 됨(Gary 등 인용)
• ‘Whimo’ 등 실제 자율주행(AI 기반) 서비스 사례가 AI 에이전트 평가·관측 프레임워크 설계에 많은 통찰 제공

Eval(에발)의 정의 및 세부 구성: 효과적 평가 프레임워크 설계법

• Eval은 ‘소프트웨어 테스팅’의 개념을 비슷하게 가져오나, 결정론/문서기반 vs 데이터/텍스트 기반의 구조적 차이가 큼
• 핵심 구성요소 4가지:
  • 역할(Role) 설정: 에이전트에 실행할 태스크/목표(ex. “텍스트의 독성 판단”)를 명시적으로 제시
  • 컨텍스트(Context): 실제 평가할 텍스트·상황이 들어가는 부분(코드상의 중괄호 표기 예시)
  • 목표(Goal): 어떤 논리/비즈니스 기준(독성, 정확도 등)으로 판단할지 구체화
  • 용어·레이블 예시(Terminology/Label): 긍·부정/톡식·논톡식 등 구체적 레이블 및 실제 예시 데이터 삽입
• 숫자(1~5 등) 직접 생산보다는, 텍스트 라벨→점수 매핑 방식을 권장(LLM이 숫자를 자체적으로 잘 못 다룸)
• 평가 방식은 LLM as a Judge(LLM 판정), 코드 기반, 사람(휴먼) 기반 등 다양하며, LLM 판정 방식이 확장성·실전 운영에는 유리

AI 트립 플래너: 폼-프롬프트-멀티에이전트-룰 트레이스-AB테스트 전체 워크플로우 실습 공개

• 노트북·깃허브 기반 실습 환경 제공, 실시간 데모로 프로젝트 구조 설명(폼 입력→멀티에이전트 호출→결과 생성)
• Crew AI, Langraph 등 대표 오픈소스 멀티에이전트 프레임워크로 구성
• 예시 폼: 목적지(Tokyo), 기간(7일), 예산($1000), 관심(푸드, 어드벤처)
• 하위 에이전트(예산, 현지 경험, 리서치)가 병렬·동시 호출되어, 상위 itinerary 에이전트가 최종 일정 생성
• 예산 제한 등 실제 비즈니스 속성을 반영(입력값 기반 “합산해 $1000 안에서 일정관리”, 관심사별 일정 추천 등)
• API 로그, 트레이스/스팬 구조, 각 에이전트의 행위/산출물 시각화를 통해 내부 구조 투명하게 드러냄
• Arize와 오픈소스 Phoenix 모두 트레이스 시각화, 프롬프트 필드 자동 매핑 등 제품간 차이 비교

’프롬프트 플레이그라운드’로 입력값, 프롬프트, 모델 버전을 손쉽게 교체/실험 가능함

• 입력값(여행지/기간/스타일 등), 프롬프트 텍스트, 모델 버전을 한 UI에서 언제든지 수정 후 바로 결과 확인
• PM이 직접 다양한 옵션을 반복 실험(500자 이내, 더 친근하고 간결하게 등)하며, 결과의 품질·응답시간 등 체감할 수 있음
• AB테스트, 프롬프트 버전 관리 등 자동화된 지원 기능 탑재
• 프롬프트 최종 산출물이 엔지니어 몫인지, PM이 명확히 제시해야 하는지에 대한 문제 제기 → PM이 제품 품질 직접 책임지는 구조 권장

데이터 수집부터, 데이터셋 생성→평가(실행)→실험 관리까지 실제적 엔드투엔드 실습

• 실제로 예시 데이터를 만들어 데이터셋(tabular, 구글시트 유사)에 저장, 여러 예시 반복 평가(스팸 판별, 친근함 등 레이블링)
• 실무 팀 대부분이 초기에 스프레드시트로 수작업 평가→전문 annotate 팀 도입→확장 자동화가 일반적임을 설명, 휴먼 평가 경험의 필요도 인정
• AB테스트 기반으로 프롬프트/모델 교체 후 전체 데이터셋 대상 반복 실행→수치적 정확도, 다양성, 신뢰성 등 비교
• 프롬프트 체이닝(A→B→C, 곧 지원예정), 각각의 변동/실험영향 분해 평가 등 발전적 워크플로우 가능

’LLM as a Judge’ 평가 자동화와 휴먼 라벨 대조 및 검증은 실제 대규모 운영에 반드시 병행해야 함

• 친근한 레이블, 할인 제공 여부, 컨텍스트 일치/환각(hallucination), 정합성 등 자유롭게 평가 기준(Eval Definition) 생성 가능
• 프롬프트·산출물(친근함, 할인정보 등)을 LLM이 자동 평가→변동(온도/temperature) 파라미터로 결과 일관성 제어 가능
• 휴먼 레이블 큐 직접 제공: 사용자가 직접 각 예시에 친근함/로봇적임 판단 등 레이블 부여, 실제 평가 세트에 즉시 반영됨
• 코드 기반 비교(매칭/불일치 정규식 등)로 LLM 자동라벨과 휴먼 레이블 일치율, 확신도, 신뢰할만한 hard example 추출 및 관리
• 신뢰할 수 없는 프롬프트·평가 프로세스는 직접 문제점 확인 후 기준/레이블/프롬프트 반복 강화
• 팀 규모에 따라 라벨링·평가를 단계적으로 확대(휴먼→LLM as a Judge→hard example 집중 보완)

평가 기준(Eval)을 결국 제품 요구조건(acceptance criteria) 그 자체로 활용하라는 새로운 협업 제안

• 기존 요구명세(PRD) 대신 실제 평가 데이터셋, 평가 기준, pass/fail 판정체계를 엔지니어·PM이 공유함으로써 명확하고 공유된 목표 수립 가능
• 특히 PM이 뭉뚱그린 요구가 아니라, 실제 예시와 평가 기준을 제품명세로 제시→팀 내 오해/재작업 최소화
• 단순 브레인스토밍보다 데이터 기반 반복 실험(이터레이션, 골든셋 구축·확장) 중요성 강조
• 빠른 프로토타입→평가기준(acceptance criteria)→생산 현장 실운영까지 일련의 데이터 중심 워크플로우 제안

실전 조직/인력 구성, PM의 기술 역할, 평가 팀 구축 전략

• AI PM/AIE(엔지니어) 등 신직종 대두: PM이 직접 평가 작성·실험→채용/역량 파악, 관련 질의/면접을 위한 사전 경험 권장
• 초기엔 헤드오브프로덕트도 직접 실습하며, 인력 채용 전 시스템 이해-수립 우선
• 팀 평가체계 미스매치 발생시, 레이블 적합도 기준 강화, 샘플링, 지속적 품질관리, 평가 기준 반복 수정
• 조직문화 변화(300인 규모 회사 기준) 예시: 공공 포럼·AI 데모 등 내부 역량 전파, 기술적 PM의 적극적 역할 교차
• 엔지니어-프로덕트 간 책임·경계 모호화 이후, 역할 스택/개인별 역량조합(스킬스택 vs 고정 직군제)으로의 조직 전환 고민
• 프로덕트→프로토타입→데이터셋 구축→학습/테스트/기준 강화의 르네상스적 역할 기대

프롬프트·에이전트 체인의 고도화, 평가 자동화, 실전 환경 연계(Related API/Infra/Logging)

• OpenTelemetry 기반 표준 logging/tracing 구조 채택하여, Arize·Phoenix 등과 연동시 원활한 계측·분석 지원
• 코드 한 줄(langchain.instrument 등)만으로 다양한 Agent/Framework/언어에 무리 없이 계측 데이터 자동 업데이트 가능
• 메타데이터 확장(user_id, session_id, context 등)으로 기존 로그 대비 AI 평가에 최적화
• 특정 스팬, 함수에 직접 데코레이터 추가하여 시스템 전체/부분별 세밀한 평가 가능
• 데이터셋 추출·로컬 노트북 실험 등 코드베이스 접근이 제한된 조직/PM도 빠른 프로토타입 실험 가능 제공

지속적으로 변화하는 데이터셋, ‘hard example’ 수집, 평가 기준의 점진적 개선 전략

• 데이터셋의 대표성(representativeness) 확보, 환경 변화(시간,트렌드)에 따른 평가 기준 보완, hard example 중심 보강 반복
• 프로덕션/개발 데이터 모두 반복적으로 평가, 불일치/애매함·confident/uncertain 샘플 위주로 골든셋 확장
• 자율주행차 예시: 직진→좌회전→사람 무단횡단 등 실제 도전 상황이 등장할 때마다 new hard-example 데이터셋 확장
• 실무 속도상 초기 소량 데이터/평가로 출발, 프로덕션 진입 후 점진적으로 신뢰 구간 관리, 품질 고도화

실전 Q&A: Model 기반 평가, 연속적 샘플링, 평가 신뢰성, End-to-End 평가 등 현장 문제 답변

• BERT/Alberta 등 어떤 모델로도 평가기준 생성 가능(Arize, 커스텀 엔드포인트 지원)
• 친근함·정확성 등 평가 일치율 낮을 때, 프롬프트·few-shot 예시·strictness 등 반복 보완이 해법
• 평가 대상(로그, 텍스트 등) 구조, 메타데이터 구성, 실제 현장 트레이스와의 연계 등 구체적 쟁점 논의
• 평가-인력-프로덕트 간 동기화, 인더루프(human as a tool), 자동화+확실성 등 첨단 실제 워크플로우 공유

팀/역할 변화, PM의 기술 성숙 필요성, 내부 역량 강화 방법 등 미래 조직에 대한 현실적 조언

• PM의 코드·데이터 직접 실습 기회 확보, Cursor 등 AI 코드 도구로 비권한 접근/빠른 프로토타이핑 추천
• PM이 데이터 일부를 활용해 독립적 데모/평가를 설계→시연하고, 엔지니어를 설득하는 방식 권장
• 기술/프로덕트 경계 최소화: 조직/프로덕트/엔지니어가 역할이 아니라, 원하는 고객 경험·문제를 중심으로 역량을 보완/분배하는 ‘스킬스택’ 개념 도입 주장
• 전체 워크숍 종료 후에도, 팀별/역할별/전문화 현장 문제에 대해 지속적 소통 강조