Turning Fails into Features: Zapier’s Hard-Won Eval Lessons - Rafal Willinski, Vitor Balocco, Zapier

영상 링크: Turning Fails into Features: Zapier’s Hard-Won Eval Lessons — Rafal Willinski, Vitor Balocco, Zapier
채널명: AI Engineer

실패를 성공으로 바꾸기: Zapier의 AI 평가(Eval) 시행착오에서 얻은 교훈 핵심 요약

• 본 영상은 Zapier의 AI 에이전트 개발 과정에서 얻은 실제적인 실수와 학습, 그리고 평가(Eval) 시스템 구축 노하우를 공유함
• Zapier Agents는 자동화 소프트웨어로, 사용자가 원하는 업무를 설명하면 관련 도구와 트리거를 제안 및 활성화해 비즈니스 프로세스를 전체적으로 자동화하는 솔루션임
• AI 에이전트는 비결정론적이며, 사용자 역시 예측 불가하게 제품을 사용하기 때문에 견고한 평가 체계가 필수
• 초기 프로토타입 구현 후에는 데이터 피드백 수집 및 분석, 반복적인 개선(데이터 플라이휠)이 중요하며, 피드백을 통한 지속적 고도화가 요구됨
• 코드 계측 및 Trace 데이터 기록이 디버깅, 평가 자동화, 실패 사례 분석에 있어 매우 중요함 (API 콜, 에러, 사전/후처리 단계까지 포함)
• 명시적 사용자 피드백(예: thumbs up/down)은 신호로서 매우 유의미하지만, 실제로는 구하기 힘드므로 문맥에 맞는 즉각적인 피드백 유도가 효과적임
• 암묵적 피드백(모델 응답 복사, 테스트 후 활용 여부, 대화 중 부정적 표현 등)을 적극적으로 탐지, LLM 활용해 불만 감지 및 주간 리포트로 집계
• LM Ops 솔루션 선정(Buy/Build)과 내부 도구 개발로 Trace 및 Failure 분석을 효율화하고, 단일 실패사례에 대한 Eval 자동 생성 환경 구축이 필요
• 평가(evaluation)는 Unit Test Eval, Trajectory Eval, AB 테스트(스테이지 롤아웃)로 위계화하여 활용하며, 각각의 적합한 용도와 한계 분석
• 모델 벤치마킹에는 Reasoning LLM, Rubric-based scoring, 실제 유저 피드백(A/B테스트)이 모두 필요, 점수에 집착하기보다는 실사용 만족도를 최종 목표로 삼음

세부 요약 - 주제별 정리

Zapier는 에이전트형 AI 자동화로 비즈니스를 자동화하는데 주안점을 둠

• Zapier 에이전트는 사용자가 원하는 결과를 자연어로 설명하면, 플랫폼이 관련 도구(tool)와 트리거(trigger)를 조합해 프로세스를 자동화해줌
• 기존의 “박스와 화살표” 흐름 기반 자동화와 달리, 사용 편의성을 극대화한 에이전트 방식 제안
• 2년 간의 개발 경험을 통해, “좋은 AI 에이전트”와 “비전문가도 쓸 수 있는 플랫폼” 구현이 매우 어렵다는 교훈 획득
• 그 원인으로 AI의 비결정론성과, 사용자의 예측 불가능한 제품 사용 패턴을 지적함

AI 에이전트 구축 초기에는 프로토타입이 쉽게 성공적으로 보일 수 있으나 실제 배포 후가 진짜 시작임

• 일반적으로 Blankchain(라이브러리), 예제 튜토리얼, 프롬프트 수정만으로 에이전트 제품을 만드는 것은, 실제 상황의 복잡성을 간과함
• 초기 성능이 잘 나오는 것 같아도, 실제 사용자 데이터와 피드백 없이 바로 배포하면 예기치 못한 실패가 빈번히 발생함
• AI 기반 소프트웨어는 기존의 결정론적 소프트웨어와 달리, 확률론적이며 데이터에 기반한 지속적 개선(데이터 플라이휠)이 핵심임

데이터 플라이휠: 실사용 이후 피드백 수집/분석/개선의 반복이 중요함

• 제품 배포 이후에는 사용자 행동 데이터, 실패 사례, 사용 패턴을 지속적으로 수집해야 함
• 피드백을 바탕으로 다양한 평가(Eval)와 기능 개선을 반복, 이를 통해 제품의 품질이 점진적으로 향상됨
• 사용자가 늘수록 실패/예외 케이스도 늘어나기 때문에, 데이터 플라이휠이 멈추지 않도록 관리해야 함

코드 계측과 Trace 데이터 기록이 실패 분석 및 평가 자동화의 핵심임

• 최초 단계는 코드에 계측(instrumentation)을 적용해, 실행된 AI 콜에 대한 Trace를 남기는 것
• 단순히 LLM 콜(예: completion)뿐 아니라, 사용된 도구(tool) 호출, 각 단계의 에러, 입력/출력값을 전부 기록해야 함
• Trace 데이터를 진짜 실행환경(shape)과 동일하게 기록하면, 나중에 이 데이터를 기반으로 자동적으로 Eval 생성이 가능
• 툴 호출 시 발생하는 부작용(side effect)은 평가 시 Mocking이 필요 → 평가 자동화의 실질적 구현 용이

명시적 피드백은 높은 신호를 주자마자 실제로는 매우 적으므로, 피드백 유도 방식 개선이 필요함

• thumbs up/down 등 명시적 피드백은 품질 지표로 유용함
• 사용자는 실제로 피드백을 잘 남기지 않으므로, 제품 내 적절한 순간(예: Agent 실행 직후) 피드백 창을 띄워 응답률을 높임
• 이에 따라 피드백 제출률이 눈에 띄게 상승한 효과 경험

암묵적 피드백(Implicit Feedback)을 적극적으로 탐지하여 실시간 개선에 활용함

• 사용자의 모델 응답 복사, 테스트 후 에이전트 활성화 여부 등도 강한 긍정 신호로 간주
• 대화 중 명확한 부정 표현(욕설, “에이전트 그만둬” 등), 반복 질의, 모델 답변 재요청 등은 암묵적 부정 피드백으로 수집
• LLM을 이용해 불만, 좌절 등 부정 신호를 감지/그룹화하며, 이를 사내 슬랙 주간 리포트로 공유
• 전통적 유저 행동 지표(활성, 잔존, churn 등)와 연계해, 이탈 직전 마지막 인터랙션 분석을 통해 추가적인 신호 탐색

LM Ops 솔루션 구축: 직접 개발과 구매를 병행하며 Trace와 Failure 카탈로그화를 자동화함

• 에이전트 실행 단일 건은 여러 LLM 콜, DB 호출, REST API 호출 등이 얽혀 있어, 한 번의 실패도 다양한 원인이 존재
• Trace 데이터 전체를 한 눈에 볼 수 있는 LM Ops 소프트웨어 필요(직접 제작, 외부 솔루션 병행)
• Cursor, cloud cod 등 현대 내부툴 개발 환경을 활용해 도메인 특화 데이터 해석, “실패를 1-click으로 Eval로 전환” 등 자동화 실현
• 실패·이상 상황이 발생할 때마다 즉각적으로 Eval 생성, 문제 유형별 클러스터링 및 우선 순위 자동 산출

대규모 문제 유형 식별과 모델 벤치마킹에는 Reasoning LLM 및 레이블링 자동화가 효과적임

• 다수의 실패 로그가 쌓이면, Reasoning LLM에게 trace와 입력, 설명을 전달해 원인 분석 및 요약 가능
• LLM이 근본 원인을 완벽히 설명하지 못해도, 실질적으로 문제 지점을 시각화·분류하는데 유용
• 실험에서 brain trust MCP와 reasoning LLM으로 “과거 모델 vs 신모델” 비교 시, 신뢰도 높은 차이점 자동 추출(Gemini Pro vs Claude: 실행/추론 태도 등 차이 해석)

평가는 Unit Test, Trajectory Eval, A/B 테스트(스테이지 롤아웃)로 구분되며 각기 다른 역할과 한계를 가짐

• 벤치마킹/품질 개선 목적의 평가(evaluation)는 Testing Pyramid와 유사한 계층 구조 설정
  • Unit Test Eval(단위 테스트): 매 상태→다음 상태를 예측(예: 다음이 특정 두 툴 호출?, 적절한 키워드 포함 등)을 빠르고 반복적으로 검증
  • Trajectory Eval(경로 기반 평가): 전체 다회 Turn 실행 후 전체 트레이스와 모든 툴, 산출 artifact를 평가(멀티턴 행위, LLM을 판정자로 활용)
  • Stage Rollout, AB Test: 실제 트래픽 일부(예: 5%)를 신규 모델/프롬프트에 할당, 실사용 피드백/메트릭 기반 성능 심사
• Unit Eval은 빠른 오류 디버깅과 단일 실패 해결에 적합하나, 모델별 접근 경로 편차에 매우 민감하며, 지나친 Overfitting 위험이 존재
• Trajectory Eval은 높은 ROI(투자효용)을 보이나, 설정이 복잡하고 슬로우함(환경 복제, 부작용 처리 필요)
• AB 테스트가 제일 현실적인 만족도 판별 지표로, Activation, Retention, 실제 유저 만족도(‘Vibe’)가 최종 판단잣대임

Rubric 기반 자동 채점과 평가방법 다변화로 객관성 및 적용도를 높임

• LLM을 평가자(Judge)로 활용 시, 헷갈릴 수 있으므로 자연어로 정밀한 rubric(채점 기준)를 각 평가케이스에 개별 작성
• 예시: “캘린더 API에서 예외 발생 시 에이전트가 다시 시도하는가?” 등, 인간이 서술한 구체 지시어를 LLM이 판정의 기준으로 삼음
• Rubric 채점식은 벤치마킹, 모델 신규 도입 시 높은 전반적 해상도를 제공

지나친 수치 집착은 오히려 왜곡을 초래하므로, ‘사용자 만족’이 진정한 목표임을 명확히 함

• 평가 지표가 100%에 다가간다고 해도, AGI가 현실적으로 존재하지 않는 한 “너무 쉬운, 비현실적 데이터셋”을 의미할 가능성 높음
• 최근에는 평가셋을 ‘회귀 데이터셋’(망가지지 말아야 할 기능 / 사용성 확인)과 ‘개척 데이터셋’(불가능에 가까운 고난이도 목표)로 분류하여 균형있게 관리
• 실험실 벤치마크 수치(maximizing score)에 집착하기보다, 실제 사용자 만족 및 피드백 수렴이 진정한 성공 척도임을 거듭 강조
• AB 테스트, 실제 유저 트래픽 기반 피드백(5% 트래픽 랜덤 할당 등)이 진짜 검증환경임

영상 마지막에서는 실전 구조와 궁극적 검증 목표를 AB 테스트, 실사용자 경험에 둔다고 재강조함

• 내부 평가, Score, Lab 데이터는 보조 도구일 뿐, 실제 제품의 성공은 사용자 만족도에 의해 결정됨을 명확히 밝힘
• 5% 등 소폭 트래픽을 신규 모델에 할당, 실제 유저의 Activation, Retention, 만족도를 기반으로 최종 의사결정
• “가장 큰 평가는 역시 사용자의 실질적 만족과 경험”임을 끝으로 영상 마무리