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

한 줄 핵심

에이전트는 비결정적이므로 코드보다 트레이스와 평가를 진실의 기준으로 삼고, 신호 탐지와 자동 수정까지 연결해야 대규모에서 지속적으로 개선할 수 있다.

시간별 요약

1. 0:00
   101에서 지속적 개선으로 이 세션은 AI 애플리케이션의 관측성, 평가, 수정 과정을 수동 작업에서 자동 루프로 확장하는 방법을 다룬다. 워크숍은 실제 코딩 에이전트를 사용해 트레이스를 분석하고 문제를 고치며, 마지막에는 Signal로 지속적 개선까지 이어가는 흐름으로 진행된다.
2. 3:12
   트레이스를 진실의 근원으로 에이전트는 같은 입력에도 매번 다른 경로와 출력을 만들기 때문에 코드만으로는 동작을 설명할 수 없다. 따라서 LLM 호출, 툴 호출, 에이전트 턴이 모두 기록된 트레이스가 실제 동작을 판단하는 기준이 된다.
3. 6:13
   수동 트레이스 검토를 넘어서 프로덕션 규모에서는 사람이 트레이스를 하나씩 읽는 방식이 병목이 된다. 이를 해결하려고 트레이스 전체를 평가하는 eval을 두고, 좋은/나쁜 이유를 설명한 결과를 다시 에이전트에게 넣어 개선 루프를 만든다.
4. 9:02
   신호를 찾아 루프를 닫기 규모가 커지면 eval 결과도 다시 사람이 다 볼 수 없기 때문에, 이제는 에이전트가 eval 실패 패턴에서 반복되는 신호를 찾아야 한다. 트레이스와 eval은 단순 관측이 아니라 자동 수정을 유도하는 행동 데이터가 된다.
5. 12:03
   워크숍 환경 설정 실습을 위해 Arize AX 계정, 저장소, OpenAI API key, Arize Space ID, Arize API key, 로컬 실행 환경이 필요하다. 문제가 있으면 화면의 예시 저장소를 따라가며 진행할 수 있도록 준비한다.
6. 14:13
   Wonder Toys와 신뢰 문제 실습 대상은 장난감 쇼핑용 에이전트형 웹스토어 Wonder Toys다. 자동 수정과 같은 고급 기능이 규제 산업에서 신뢰 가능한지에 대한 질문이 나오고, 실제로 금융권 고객도 이런 방식으로 사용 중이라는 답이 제시된다.
7. 16:31
   코딩 에이전트로 관측성 추가하기 현재 앱은 관측성이 없으므로 코딩 에이전트에게 Arize AX 관측성 추가를 맡긴다. OpenAI agents SDK가 이미 OpenInference로 계측되어 있어, 실제로는 설정을 켜고 트레이스를 Arize 엔드포인트로 보내기만 하면 된다.
8. 20:19
   라이브 트레이스 테스트와 확인 앱을 재시작하고 실제 질의를 보내면 Arize UI에 프로젝트별 트레이스가 쌓이는 것을 확인할 수 있다. 이제 요청 입력과 에이전트 응답, 실행 흐름을 실시간으로 볼 수 있는 첫 단계가 완성된다.
9. 22:25
   누락된 가격 필터 드러내기 의도적으로 가격 필터를 묻는 질의를 던져 현재 앱이 그 기능을 지원하지 않는다는 사실을 확인한다. 트레이스만으로도 어떤 요청이 실패했는지 드러나며, 관측성이 곧 디버깅의 출발점이 된다.
10. 24:41
    에이전트에게 트레이스 분석시키기 코딩 에이전트에게 트레이스를 내려받아 문제를 찾아보라고 시킨다. 설치된 skills 덕분에 에이전트는 Arize AX에서 트레이스를 읽고, 상태와 오류를 요약해 품질 문제를 자동으로 탐지한다.
11. 28:51
    검색 품질 문제 진단 분석 결과 일부 검색이 결과를 내지 못하고, 모든 인자가 null인 채 검색되는 등 품질 문제가 확인된다. 핵심 원인은 검색 필터 로직이며, 특히 잘못된 모델 입력이 빈 결과나 과도한 제한을 만드는 패턴이 드러난다.
12. 30:28
    가격 필터 추가 에이전트는 미리 만들어 둔 해결 버전을 참고해 가격 필터 기능을 구현한다. 수정 후에는 실제로 $9 이하 장난감이 잘 반환되고, 트레이스에도 정상 입력과 응답이 남아 루프가 닫혔음을 보여준다.
13. 33:05
    Signal로 지속 감시하기 Signal은 Arize AX 안에서 동작하며 6시간마다 트레이스를 자동 분석해 문제 패턴과 수정 제안을 만든다. 단발성 검토가 아니라, 금지 질의 처리나 잘못된 응답 같은 문제를 계속 찾아내고 PR이나 이슈로 연결할 수 있다.
14. 36:06
    배포와 회귀 평가 질문 로컬 저장, 규제 대응, 적은 트레이스 수에서의 신뢰성, 비용 부담 같은 실무 질문이 이어진다. 답변의 핵심은 운영 환경에 맞는 배포 옵션과, 변경 후 행동이 망가지지 않도록 회귀 eval을 미리 갖추는 것이다.
15. 40:22
    Signal 자체를 평가하기 Signal도 별도의 eval suite와 트레이싱으로 평가되며, LLM judge가 PR 생성 품질을 판정한다. 즉, 문제를 찾는 시스템 자체도 같은 개발 생명주기 안에서 계속 검증되고 개선된다.

실무 인사이트

• 프로덕션 에이전트는 코드 리뷰보다 트레이스와 eval 중심으로 봐야 하며, 사람이 직접 읽는 구조를 전제로 하면 규모가 커질수록 반드시 병목이 생긴다.
• 가치 있는 자동화는 문제를 ‘찾는 것’에서 끝나지 않고, 반복 패턴을 신호로 묶어 수정 후보까지 만드는 단계에서 실질적인 운영 효과가 난다.
• 회귀 eval이 먼저 있어야 자동 수정의 안전성이 확보되므로, 기능 추가보다 먼저 실패하면 안 되는 행동을 명시적으로 정의하는 것이 중요하다.