Let Your Agent Cook: Using Skills to Evaluate and Improve Your App — Ankur Duggal, Arize AI

한 줄 핵심

에이전트의 실제 트레이스와 평가를 코딩 에이전트의 Skills로 연결해, 문제를 찾고 실험으로 고치고 다시 검증하는 흐름을 몇 분 단위로 자동화하는 방법을 보여준다.

시간별 요약

1. 0:00
   직감에서 신뢰 가능한 평가로 에이전트가 제대로 동작하는지 감으로 확인하는 방식은 시작점으로는 유용하지만, 운영 환경에서는 어떤 부분이 깨지는지 알아내지 못해 배포 기준으로는 부족하다. 신뢰할 수 있는 평가는 실제 실패 사례를 지속적으로 잡아내는 체계가 있어야 한다.
2. 1:58
   트레이스가 에이전트의 실제 결정을 드러낸다 일반 소프트웨어와 달리 에이전트는 단일 호출 뒤 어떤 도구를 고를지, 어떤 추론을 할지 흐름이 보이지 않으므로 트레이스가 필요하다. 트레이스를 보면 에이전트가 실제로 무엇을 했는지 따라갈 수 있어 디버깅의 출발점이 된다.
3. 3:19
   환불 질문과 잘못된 도구 예시에서는 사용자가 환불 상태를 물었는데 `get order status` 같은 잘못된 도구를 써서 엉뚱한 답을 내는 문제가 드러난다. 이처럼 같은 실패처럼 보여도 실제로는 도구 선택, 프롬프트, 라우팅 등 여러 원인이 있을 수 있다.
4. 4:15
   개선 루프 운영 실패를 발견하면 원인 추정, 데이터 수집, 평가 구성, 수정, 실험, 배포를 반복하는 루프가 필요하다. 문제는 이 과정이 길고 수동적이라는 점이며, 이를 더 짧은 시간 안에 반복할 수 있게 만드는 것이 목표다.
5. 6:03
   트레이스·평가·코드를 한곳에 묶기 트레이스, 평가 결과, 인간 주석, APM 정보, 코드베이스를 한곳으로 모으면 실패 원인을 빠르게 연결할 수 있다. 이런 통합 정보는 Claude Code, Cursor, Codex 같은 코딩 에이전트가 수정안을 만들 때 특히 강력하다.
6. 7:27
   CLI와 Skills를 인터페이스로 쓰기 CLI와 Skills를 설정하면 코딩 에이전트가 트레이스 내려받기, 데이터셋 만들기, 실험 실행, 평가 수행까지 직접 하게 할 수 있다. 즉, 플랫폼을 오가며 수동 작업을 하는 대신 한 인터페이스에서 전체 흐름을 다룰 수 있다.
7. 8:06
   결함이 있는 금융 에이전트 금융 조언을 해서는 안 되는 에이전트가 투자 여부를 묻는 질문에 섣불리 답하는 사례를 통해 문제 정의가 시작된다. 여기서는 사용자 정보 부족, 근거 부족, 검증 부재, 가드레일 부족 등 여러 개선 포인트가 함께 드러난다.
8. 11:05
   프로필을 설정하고 Skills를 설치하기 CLI를 설치하고 프로필을 연결하면 Arize 같은 저장소에서 트레이스와 평가 정보를 가져올 수 있다. 그다음 Skills를 설치해 코딩 에이전트가 해당 데이터를 읽고 분석하도록 만든 뒤, 개선 요청을 자연어로 지시할 수 있다.
9. 13:19
   슈퍼바이저와 전문가 트레이스 살펴보기 실행 중인 에이전트의 트레이스를 보면 상위 슈퍼바이저와 하위 전문가가 어떤 도구를 언제 호출했는지 한눈에 보인다. 이 구조 덕분에 문제 구간을 빠르게 특정하고, 어떤 단계에서 오동작했는지 바로 확인할 수 있다.
10. 16:03
    근거성, 환각, 침묵 실패 분석 결과에는 숫자 근거성 문제, fabricated answers, 중복 도구 호출, silent tool failures 같은 전형적 실패가 드러난다. 특히 도구는 성공했다고 말하지만 실제 응답이 비어 있거나, 실패를 숨기고 환각으로 메우는 문제가 치명적이다.
11. 18:24
    평가를 만들고 실험을 돌리기 발견한 문제를 바탕으로 도구 실패 침묵 검출과 numeric groundedness 같은 평가를 만들고, 실패를 일으킨 스팬을 데이터셋으로 삼아 실험한다. 이를 통해 수정안이 실제 실패 사례에서 얼마나 좋아졌는지 재현 가능하게 확인할 수 있다.
12. 20:05
    국제 주식 질의에 대한 이전 수정 사례 국가별 주식 질의에서 발생한 실패를 데이터셋으로 만들고, 여러 차례 수정을 거쳐 성공률을 끌어올린 사례를 보여준다. 처음의 단순한 보정은 실패했고, 도구 버전 업데이트까지 반영한 세 번째 반복에서야 약 90% 성공률에 도달했다.
13. 22:23
    실험과 판정자가 실행되는 위치 실험은 로컬 머신이나 클라우드에서 돌릴 수 있고, 평가는 Arize 쪽에서 실행하도록 구성할 수 있다. 판정은 codebased 평가와 LLM judge를 함께 쓰되, 설정 과정에서 codebased가 막히면 LLM judge를 최종 기준으로 둘 수도 있다.
14. 23:31
    평가 모델 고르기 평가용 모델은 Claude, OpenAI, 로컬 오픈소스 모델 등 원하는 것을 선택할 수 있으며, 운영 모델과 평가 모델을 꼭 같게 둘 필요는 없다. 중요한 것은 비용보다도 자신의 사용 사례에서 더 믿을 만한 판정기를 고르는 일이다.
15. 24:37
    코드만이 아니라 더 많은 문맥이 필요하다 버그 수정은 코드만 보는 것이 아니라 트레이스, APM 로그, Jira 티켓, 평가 결과, 주석 같은 문맥을 함께 봐야 정확해진다. 이런 정보가 있어야 에이전트가 왜 실패했는지와 어떻게 고쳐야 하는지를 더 잘 판단할 수 있다.
16. 26:13
    좋은 요약의 기준 좋은 요약은 전체 컨텍스트에서 핵심을 정확히 반영하고 질문에 맞게 답하는 것이다. 이를 판정하려면 별도의 summary eval이 필요하며, 시간이 지나 모델이 바뀌거나 질문 방식이 달라져도 성능이 유지되는지 계속 감시해야 한다.
17. 28:35
    린팅만 보지 않기 코딩 에이전트가 자칫 린팅 같은 표면적 수정에만 몰입할 수 있지만, Skills를 통해 실제 트레이스와 실패 정보를 주면 핵심 문제에 더 집중하게 된다. 도구 사용과 추론 흐름이 보이면 단순 코드 스타일 수정으로 빠지는 것을 줄일 수 있다.
18. 30:21
    평가 비용과 샘플링 평가는 추가 LLM 호출이므로 비용이 발생하며, 트레이스 히스토리와 함께 비용을 확인할 수 있어야 한다. 모든 호출에 평가를 걸지 말고 샘플링이나 특정 영역만 대상으로 삼아 비용 대비 효과를 조절하는 것이 중요하다.
19. 31:28
    제안된 변경 사항 검토하기 에이전트가 수정안을 자동으로 제시하고 실험까지 돌려주더라도 마지막 검토는 사람이 해야 한다. 핵심은 린팅만 고친 듯한 얕은 수정이 아니라, 실제 에이전트 품질을 높이는 변경인지 확인하는 일이다.
20. 33:19
    애플리케이션에 맞게 평가를 맞춤화하기 기본 평가만으로는 부족하며, 자신의 애플리케이션에서 자주 터지는 실패 유형을 기준으로 평가를 설계해야 한다. 범용 벤치마크보다 실제 운영 환경에 맞춘 평가가 있어야 에이전트 품질을 제대로 판단할 수 있다.

실무 인사이트

• 에이전트 개선은 '문제 발견 → 트레이스 확인 → 데이터셋 생성 → 평가 설계 → 실험 → 재검증'의 폐루프로 표준화해야 가장 빨라진다.
• 평가의 핵심은 정답을 맞히는 모델보다, 실제 실패를 잘 가려내는 판정 기준과 샘플링 전략을 설계하는 데 있다.
• 코딩 에이전트에 트레이스와 평가 문맥을 연결하면 단순 코드 수정 도구가 아니라 운영 장애 분석과 수정 제안 도구로 활용할 수 있다.