From Vibes to Production: Evaluating and Shipping AI Agents That Work 101 — Laurie Voss, Arize AI

한 줄 핵심

AI 에이전트를 “감으로” 출시하지 말고, 트레이스·평가·인간 라벨·실험으로 실패를 계량화해 개선하는 방법을 배우는 실전 워크숍이다.

시간별 요약

1. 0:00
   워크숍 개요와 노트북 준비 오늘 다룰 핵심은 평가의 기본 개념, 트레이싱 설정, Claude Agent SDK로 만든 에이전트 추적, 다양한 평가 작성, 인간 라벨과의 비교, 그리고 실패를 데이터셋과 실험으로 바꿔 개선하는 전 과정이다. 실습을 위해 노트북, Anthropic API 키, Arize 계정과 API 키가 필요하다.
2. 7:31
   트레이스·평가·감각만 믿는 방식의 한계 트레이스는 AI가 런타임에 실제로 무엇을 했는지 보여주는 로그이고, 평가는 그 결과가 좋은지 나쁜지를 판단하는 장치다. 몇 번 돌려보고 괜찮아 보인다는 식의 감각적 출시는 비결정성과 회귀를 잡지 못하므로, 측정 가능한 기준이 필요하다.
3. 11:21
   코드·LLM·인간 평가의 역할 분담 코드 평가는 JSON 형식, 길이 제한, 금지어처럼 결정적인 조건을 빠르고 싸게 검사한다. LLM 평가는 사실성, 충실성, 톤처럼 의미를 이해해야 하는 기준을 다루고, 인간 평가는 최고 품질 기준이지만 느리고 비싸며 항상 함께 써야 한다.
4. 14:27
   에이전트 실패와 정답을 잘못 채점하는 문제 에이전트는 도구 호출과 의사결정이 연쇄되므로 중간 단계의 실패와 루프, 핸드오프 오류가 누적되기 쉽다. 또한 예상하지 못한 창의적 정답을 오답으로 채점할 수도 있으므로, 경로가 아니라 결과를 기준으로 평가해야 한다.
5. 17:18
   능력 평가와 회귀 평가 능력 평가는 “이 일을 할 수 있는가”를 보는 초반용 평가로, 대체로 일부 실패가 기대된다. 한 번 통과하기 시작하면 같은 항목은 회귀 평가로 바뀌며, 이후에는 거의 항상 통과해야 하는 보호선이 된다.
6. 21:19
   Claude Agent SDK 계측하기 평가를 하려면 먼저 관찰 가능해야 하므로, OpenTelemetry와 OpenInference를 통해 Claude Agent SDK에 트레이싱을 붙인다. Arize AX에 스팬을 전송하도록 등록하고, 노트북에서 동일한 키로 다시 읽어와 추적 데이터를 다룬다.
7. 28:47
   금융 분석 에이전트 만들기와 추적 실습용 에이전트는 주식 티커를 받아 웹 검색으로 최신 금융 정보를 수집하고 보고서를 작성한다. 연구 단계와 작성 단계를 분리해 트레이스로 묶으면, 검색 횟수·도구 호출·파일 쓰기 시도 같은 실제 동작이 그대로 드러난다.
8. 36:26
   다양한 테스트 질의 생성 의미 있는 평가는 한두 개의 예제가 아니라 다양한 티커, 난이도, 질문 유형, 엣지 케이스를 포함한 데이터가 필요하다. Apple, Microsoft 같은 일반 사례뿐 아니라 비교 질문, 덜 알려진 종목, 배당·성장 질문처럼 분포를 넓혀야 한다.
9. 38:54
   트레이스를 읽고 성공 기준 정의하기 평가를 쓰기 전에 먼저 실패한 트레이스를 읽고 무엇이 잘못됐는지 직접 확인해야 한다. 성공 기준은 정확한 티커 사용, 최신 데이터 반영, 실행 가능한 권고, 역사 요약과 미래 전망의 구분처럼 도메인 지식에 기반해 명시해야 한다.
10. 45:31
    실패 유형 분류와 우선순위 결정 트레이스의 문제를 먼저 자연어로 적는 오픈 코딩을 하고, 이후 공통 원인별로 묶는 축 코딩을 한다. 빈도만 보지 말고 심각도를 함께 봐야 하며, 여러 평가가 서로 다른 구멍을 메우는 스위스 치즈처럼 조합되어야 한다.
11. 49:16
    결정적인 티커 검사 작성 가장 단순하고 값싼 1차 방어선은 보고서에 티커가 실제로 등장하는지 검사하는 코드 평가다. 이 평가는 경로가 아니라 결과만 보고, 동일 입력에 항상 같은 답을 내는 결정적 로직이어야 한다.
12. 58:14
    모든 보고서를 거절하는 정확성 판정기 일반 정확성 평가는 최신 웹 검색 기반 보고서를 판단하기에 부적합하며, 지식 기준 시점 때문에 거의 전부 0점을 줄 수 있다. 이번 사례처럼 외부 근거가 필요한 작업은 정확성보다 충실성 평가가 더 적합하다.
13. 1:02:11
    연구 맥락을 이용한 충실성 평가 충실성 평가는 에이전트가 참고한 연구 컨텍스트를 함께 넣고, 그 안에서 보고서가 근거를 벗어나지 않았는지 판단한다. 이 방식으로는 보고서가 절반가량 환각을 내는지, 즉 근거에 충실한지를 훨씬 정확히 볼 수 있다.
14. 1:06:25
    맞춤형 실행 가능성 루브릭 작성 좋은 맞춤 평가 루브릭은 역할 정의, 명확한 합격·불합격 기준, XML 태그로 구분된 입력/출력, 그리고 좋은·나쁜 예시를 포함해야 한다. 특히 실행 가능성은 구체적 권고, 수치, 미래 지향적 분석처럼 관찰 가능한 조건으로 써야 한다.
15. 1:17:35
    집중형 평가와 프로덕션 기준 하나의 거대 평가자보다 정확성, 충실성, 실행 가능성처럼 역할이 분리된 평가자가 낫다. 또한 어떤 평가는 배포 차단용 가드레일이고, 어떤 평가는 장기 개선용 나침반인지 구분해야 운영 방식이 달라진다.
16. 1:20:00
    판정기와 인간 주석 비교하기 LLM 판정기도 분류기이므로 인간 라벨과 비교해 정답률을 검증해야 한다. 주석을 통해 골든 데이터셋을 만들고, 불명확한 규칙은 설명을 읽으며 수정한 뒤 개발용·테스트용으로 나눠 과적합을 막아야 한다.
17. 1:26:25
    정밀도·재현율·판정 편향 실무에서는 대체로 재현율을 우선해 놓치는 실패를 줄이는 것이 더 중요하다. 위치 편향, 길이 편향, 자신감 편향, 자기 선호 편향이 있으므로, 생성 모델과 다른 모델을 판정기로 쓰는 편이 안전하다.
18. 1:30:27
    실패를 평가 데이터셋으로 바꾸기 실패한 트레이스와 성공한 트레이스를 데이터셋으로 저장하면 회귀 테스트와 골든 데이터셋이 된다. 실제 사용자 트래픽이 생기면 합성 데이터보다 실제 실패 사례를 우선 반영해 평가 세트를 계속 갱신해야 한다.
19. 1:32:39
    설명을 이용해 프롬프트 개선하기 평가 설명을 그대로 코드 에이전트에 넘기면, 실패 원인에 근거한 프롬프트 수정안을 자동으로 만들 수 있다. 중요한 것은 “평가를 통과하게”가 아니라, 구체적 실패 설명을 바탕으로 실제로 더 나은 출력을 만들게 하는 것이다.
20. 1:35:24
    통제된 실험으로 변경 사항 비교하기 같은 데이터셋과 같은 평가자를 유지한 채 프롬프트만 바꾸고 다시 실행하면, 변경 효과를 통제된 실험으로 볼 수 있다. 실제 운영에서는 온라인 평가와 모니터링, 실패 수집, 데이터셋화, 재실험, 배포가 하나의 순환 루프로 이어진다.

실무 인사이트

• AI 에이전트는 먼저 트레이스로 관찰 가능하게 만든 뒤, 코드 평가부터 하나씩 쌓는 방식이 가장 빠르게 안정화된다.
• 좋은 평가는 모델 성능보다 데이터와 기준 정의의 품질에 더 크게 좌우되므로, 실패 사례를 읽고 루브릭을 구체화하는 작업이 핵심이다.
• 실무에서는 평가를 한 번 만드는 것으로 끝나지 않고, 실패를 데이터셋과 실험으로 연결해 계속 회귀 방지 체계를 갱신해야 한다.