영상 링크: Break It ‘Til You Make It: Building the Self-Improving Stack for AI Agents - Aparna Dhinakaran
채널명: AI Engineer
스스로 개선되는 AI 에이전트를 위한 평가 및 관찰 스택 구축 방법 핵심 요약
- 본 영상은 Arise의 공동 창업자 아파르나(Aparna Dhinakaran)가 AI 에이전트 개발 과정에서의 평가(evaluation)와 모니터링, 개선 루프 구축에 대해 심층적으로 논의함
- 에이전트 개발은 프롬프트·모델·툴콜 정의 등 다양한 측면에서 반복적이고 복잡해, 체계적인 평가 체계 없이는 실제 개선이 매우 어려움
- 많은 팀이 아직도 단순한 수동 평가(엑셀 기반, 직관 평가, 소수 사례 등)에 의존하고 있어, 실질적이고 재현 가능한 개선 포인트를 찾기 어렵다고 지적
- 에이전트 행동을 신뢰도 높게 파악·개선하기 위해서는 ‘툴콜 수준’, ‘전체 트레이스/경로 수준(trajectory)’, ‘멀티턴 대화 세션’ 등 다양한 평가 관점이 필요함
- Arise의 자사 에이전트(Co-pilot)와 제품에서 실제로 사용하는 평가 지표·분석법(예: 툴콜 및 전달 인자 적합성, 트레이스 단위의 성공률, 병목구간 식별 방법 등)이 상세히 소개됨
- 실제로 에이전트가 어떤 경로/업무에서 성능 저하(예: 검색 답변의 정답률이 절반 이하) 문제가 발생했는지, 이를 찾고 개선하는 방식을 구체적으로 시연
- 멀티턴 대화에서는 문맥 유지, 일관된 톤, 중복 질문 유무 등 추가적인 동적 평가 포인트를 설정해야 함을 강조
- 에이전트 프롬프트 및 코드만큼 ‘평가 프롬프트(평가지표)’도 지속적으로 개선하는 별도의 루프가 필요하며, 이를 통해 전반적 제품 품질 개선이 가능함
- Arise Phoenix, AriseEX 등 오픈소스 도구를 통한 실습 기회 제공도 안내
- 영상은 실제 사례, 제품 인터페이스, 트레이스 예시 등 구체적 데이터와 함께 단계별 평가 및 개선 방법을 체계적으로 제시함
세부 요약 - 주제별 정리
Arise 팀이 체계적 에이전트 평가에 집중하게 된 이유와 기존 방식의 한계
- 아파르나와 Arise 팀은 에이전트 개발 과정에서 발생하는 반복적 과정과 어려움 때문에 체계적 평가 도구 개발에 착수함
- 기존 팀들은 주로 엑셀 등으로 프롬프트 변경 비교, 모델 교체 효과 평가, 툴콜 수정 여부 판단 등을 진행했으나 반복적·주관적 평가에 그침
- 산발적 사례 및 “느낌”에 의존한 평가라 확실한 개선 포인트를 도출하기 어려움
- 특히 팀 내부의 다른 멤버(프로덕트 매니저, 타 엔지니어 등)와 협업하며 검증하기가 매우 비효율적임
- 종합적으로, “무엇을 개선하면 에이전트가 실제로 좋아지는가”를 일관되게 파악할 체계가 부재함
단순 프로토타이핑에서 벗어나 프로덕션급 에이전트 평가가 필요한 이유
- 프로덕션에 배포하면 평가가 더 어려워짐: 특정 서브 에이전트 혹은 툴콜에 병목이 있는지, 지속적으로 잘못된 응답이 어디서 발생하는지 파악이 힘듦
- 정확히 병목 위치를 식별·수정해야 실질적인 성능 개선이 가능
- 인프라 수준에서 ‘에이전트의 전체 경로, 결정 포인트, 도구 호출 패턴’까지 포괄적으로 추적·관측해야 함
툴콜 수준에서의 평가가 에이전트 개선의 1차적 출발점임을 시연
- 대부분의 에이전트는 여러 개의 “툴(도구)”을 호출해 문제를 해결하므로, 올바른 시점에 올바른 툴을 선택했는지 평가 필수
- 툴콜 평가의 절차:
- 올바른 툴콜을 선택했는가?
- 그 툴콜에 올바른 argument(전달 인자)를 포함했는가?
- Arise 제품(인터페이스) 내에서는 각 질의별 트레이스를 추적해 사용자 질문에 대해 어떤 툴콜이 이뤄졌고 파라미터가 적합했는지를 실시간 확인 가능
- 실제 Co-pilot 예시에서 사용자 질문들에 대한 성공률·실패 사례를 구체적으로 확인하고 분석
전체 트레이스(trajectory)와 경로 분석으로 결함 지점을 체계적으로 도출할 수 있음을 설명
- 단일 툴콜이 아닌, 여러 툴/서브툴을 거치는 전체 경로(trajectory)를 평가하는 것이 필수
- Arise 제품의 DAG(의존성 그래프) 형태 트레이스 뷰에서 에이전트의 다양한 실행 경로와 의사 결정 흐름을 시각적으로 파악
- 상위 레벨(planner, orchestrator 등)이 어떤 정보에 따라 어떤 툴을 호출하는지, 중간에 라우팅이 어떻게 이뤄지는지 종합적으로 분석해야 함
- 실제 사례: “검색 관련 Q&A 응답 정확도”에서 올바른 툴콜이 빈번히 실패함(정답률 50%선), 이 구간이 명확한 병목임을 찾아냄
- 구체적으로 해당 트레이스 내에서 ‘인자는 틀렸으나, 선택 툴은 맞음’ 등 세밀한 문제 유형을 빠르게 파악 가능
멀티턴 대화에서 문맥 유실, 일관성 등 추가 평가 포인트가 필수적임을 제시
- 실제 에이전트 활용에서는 다수의 턴(예: 사용자 ↔︎ 에이전트 왕복 3회 이상)이 연속적으로 발생
- 멀티턴 세션에 대해 평가할 주요 질문:
- 에이전트가 대화 톤을 일관성 있게 유지하는가?
- 동일/유사 질문을 중복해 묻지 않는가?
- 이전 턴의 컨텍스트(context)를 제대로 기억·활용해서 응답하는가?
- 실제 프로젝트 예시에서는 세션 전체를 바라보며 누락된 문맥, 잘못된 답변 등을 체계적으로 검출
- ‘세션 단위 evaluation’을 반복적으로 수행하고 개선하는 방식을 강력히 권장
성공적 프롬프트 개선을 위해서는 올바른 평가 지표(이밸 프롬프트)부터 지속적으로 개선해야 함을 강조
- 많은 팀이 에이전트 프롬프트/파라미터 최적화에 집중하나, “이밸 프롬프트(평가지표)” 구축과 개선의 중요성은 간과되는 경우가 많음
- 실제 전달 인자와 툴콜 평가에서 평가 로직 자체의 오류(오검출/오분류)가 발생할 수 있음
- 따라서 “평가 프롬프트 자체”도 반복적으로 검토·수정·정제하는 별도의 루프를 운영하여, 원본 데이터셋(골든 데이터), 평가 기준 등도 꾸준히 개선해야 함
- 결과적으로 두 개의 병렬 루프: (1) 에이전트 프롬프트/로직 개선, (2) 평가 프롬프트/로직 개선이 동시에 진행되어야 전체 품질이 보장됨
Arise Phoenix 및 AriseEX 오픈소스 도구의 실습 활용 안내 및 마무리
- 본 강연에서 소개한 평가 접근법, 실습 예시는 모두 Arise Phoenix(완전 오픈소스)에서 직접 실험, 활용 가능
- AriseEX 등 추가 도구로 자체 데이터에 맞는 다양한 평가 루프 구축 및 테스트 지원
- 영상을 통해 실제 트레이스 분석, 평가 항목 및 단계별 개선 사이클을 직접 데모하여 실증적 이해를 돕고 있음