Arize 에이전트 평가 워크숍은 「좋은 답변」 대신 통과·실패 기준 세 줄부터 씁니다 | DAKER 커뮤니티

에이전트가 답을 잘했는지 감으로 보던 팀이라면, 오늘은 「좋은 답변」이라는 말 대신 통과 조건 세 줄과 실패 조건 세 줄부터 적으십시오. AI Engineer 채널에 10월 25일 올라온 워크숍 영상 「How to Write Your First AI Eval」에서 Arize AI 제품 책임자 SallyAnn DeLucia가 약 35분 동안 보여 준 순서가 바로 이것입니다. 기준을 구체적으로 쓰고, 실행 기록에서 평가할 단계를 고르고, 다른 LLM에게 한 가지 품질만 채점하게 한 뒤 그 이유를 읽으며 고칩니다. 제출물에 검증 방법과 한계를 써야 하는 AI Agent 대회 참가자라면 그대로 가져갈 수 있는 절차입니다.

통과와 실패 조건이 적힌 클립보드와 에이전트 실행 단계를 돋보기로 살피는 손그림 일러스트 — 설명용 생성 이미지입니다.

영상에서 확인한 핵심: 평가는 단위 테스트가 아니라 기준을 문장으로 쓰는 일입니다

DeLucia는 먼저 감으로 확인하는 방식이 왜 오래가지 못하는지 설명합니다. 월요일에 프롬프트를 고치면 전반적으로 나아진 것처럼 보입니다. 그런데 일주일 뒤에는 고쳤다고 생각한 사례가 다시 깨져 있고, 고쳐졌는지 망가졌는지를 증명할 근거가 아무에게도 없습니다. 영상에서 꼽은 문제는 세 가지입니다. 프롬프트를 바꿨을 때 성능이 떨어진 것을 잡아내지 못하고, 프롬프트나 모델 버전을 객관적으로 비교하지 못하며, 배포 과정(CI)에 품질 기준을 넣지 못합니다.

많은 개발자가 평가를 단위 테스트와 같은 것으로 생각합니다. 영상의 설명은 다릅니다. 일반 소프트웨어 테스트는 입력 하나에 정답 출력 하나가 있고, 코드의 논리를 모두 읽을 수 있습니다. 에이전트는 그렇지 않습니다. 같은 여행 계획 요청에도 맞는 답이 여러 개이고, 에이전트가 어떤 논리로 움직였는지는 실행이 끝난 뒤 트레이스(trace)라는 실행 기록으로만 보입니다. DeLucia는 이를 이렇게 정리합니다. 트레이스는 AI의 로그이고, 평가는 실제 테스트입니다. 그래서 평가를 하려면 먼저 실행 기록을 남겨야 합니다.

평가 방식은 일곱 가지로 나뉘고, 이번 워크숍은 LLM 채점자를 다룹니다

영상에서 소개한 평가 방식은 다음과 같습니다.

LLM 채점자(LLM as a judge): 두 번째 LLM이 에이전트 출력의 한 가지 측면을 채점하고 라벨과 설명을 함께 돌려줍니다. 설명이 있어서 라벨을 그대로 믿지 않고 채점 이유를 확인할 수 있습니다.
결정 모델(decision model): 질문 하나에 참·거짓 같은 라벨과 확률만 돌려줍니다. 싸고 빠르지만 설명은 없습니다. DeLucia는 앞으로 평가에서 큰 비중을 차지할 것으로 봅니다.
코드 평가: 출력에 특정 단어가 있는지, JSON 형식인지처럼 결과가 정해진 검사에 씁니다. ROUGE, BLEU 점수도 여기에 들어갑니다.
주석(annotation): 사람이 정답을 붙인 골든 데이터셋입니다. 합성 데이터로 만들기도 합니다.
에이전트 채점자(agent as a judge): 에이전트 하나가 다른 에이전트를 평가합니다. 성공 기준이 아주 복잡할 때 쓸 만하다고 설명합니다.
사용자 피드백과 비즈니스 지표: 주로 서비스 운영 단계에서 씁니다.

앞의 네 가지는 개발 단계와 운영 단계 모두에서 쓸 수 있다는 점을 강조합니다. 개발용으로 만든 평가를 버리지 않고 서비스와 함께 키워 가야 일관된 성능을 확인할 수 있기 때문입니다.

트레이스를 읽는 법: 맨 위 스팬에서 시작해 한 단계씩 내려갑니다

실습 대상은 여행 계획 에이전트입니다. 사용자가 목적지, 기간, 예산, 여행 스타일을 보내면 에이전트가 추가 질문을 하고 도구를 호출한 뒤 일정표를 돌려줍니다. 영상 속 예시는 체코 프라하 3일, 예산 800달러, 관광지보다 현지 분위기가 나는 일정을 원하는 요청이었습니다.

트레이스 맨 위에는 루트 스팬(root span)이 있습니다. 기술적으로는 부모 ID가 비어 있는 스팬이고, 보통 사용자 입력과 최종 출력이 여기에 담깁니다. 그 아래 각 스팬은 에이전트가 수행한 작업 하나입니다. 리서치 에이전트가 날씨나 명소 같은 외부 정보를 가져오는 도구 스팬, 그 결과를 요약하는 LLM 스팬이 이어집니다. 질문을 받은 DeLucia는 LLM 스팬이 두 번 보이는 이유도 실제 트레이스를 따라가며 설명했습니다. 첫 번째 LLM 호출이 쓸 도구를 고르고, 두 번째 호출이 도구가 가져온 데이터를 요약했습니다. 어떤 단계가 무엇을 했는지는 이렇게 아래로 내려갔다가 다시 올라와야 보일 때가 많습니다.

이 단계에서 할 일은 측정할 대상을 메모하는 것입니다. 사용자가 무엇을 물었는지, 에이전트가 어떤 도구를 불렀는지, 최종 답을 그대로 사용자에게 보여 줄 수 있는지를 제품 담당자나 개발자의 눈으로 확인합니다.

기준 쓰기: 「도움이 된다」 대신 이 에이전트에만 맞는 조건을 씁니다

워크숍의 중심은 기준을 쓰는 단계입니다. DeLucia는 「도움이 된다」, 「정확하다」, 「좋은 답변이다」 같은 표현을 막연한 기준으로 봅니다. 여행 에이전트에 맞게 바꾸면 다음과 같습니다.

사용자가 보낸 추가 질문에 답했는가
요청한 여행 일수와 일정표의 일수가 맞는가
합계 비용이 사용자가 말한 예산 안에 있는가

두 번째 원칙은 평가 하나에 품질 하나만 채점하게 하는 것입니다. 결정 모델이나 에이전트 채점자는 여러 기준을 한 번에 다뤄도 괜찮을 때가 있지만, LLM 채점자는 기준을 하나씩 다룰 때 결과가 좋다는 연구가 많다고 설명합니다. 그래서 하나로 시작하고 나중에 늘리라고 권합니다.

실습에서는 다음 여섯 가지를 적게 했습니다.

평가할 작업: 어떤 상황의 출력을 볼 것인가
성공이 어떤 모습인가
실패가 어떤 모습인가
채점자가 판단할 대상
통과에 해당하는 조건 세 줄
실패에 해당하는 조건 세 줄

영상 속 예시는 이렇습니다. 평가할 작업은 사용자가 여행에 대해 추가 질문을 보낸 상황입니다. 성공은 여행의 세부 정보를 써서 그 질문에 바로 답하는 것이고, 실패는 일반적인 예산 이야기로 돌아가 버리는 것입니다. 한 줄 요약만으로 부족하냐는 질문에 DeLucia는 이 메모가 그대로 채점용 프롬프트가 되기 때문에 구체적이어야 한다고 답했습니다. 동료나 이해관계자에게 성공이 무엇인지 설명하듯 쓰면 된다는 것입니다.

데이터셋과 채점 프롬프트: 20개 트레이스, 한 가지 기준, 한 명의 채점자

기준을 쓴 다음에는 트레이스에서 평가할 스팬을 골라 데이터셋으로 저장합니다. 입력과 일정표 전체가 맞는지 보려면 루트 스팬을 모으고(부모 ID가 비어 있는 스팬으로 필터링), 도구 호출이 올바른 정보를 가져왔는지 보려면 도구 스팬을 모읍니다. 평가 대상이 어디에 있는지에 따라 모을 단계가 달라집니다.

채점 프롬프트는 세 부분으로 씁니다. 먼저 채점자의 역할을 정합니다. 예를 들어 출력이 입력에서 요청한 세부 사항을 정확히 반영했는지 평가하는 역할이라고 적습니다. 다음으로 평가할 데이터를 변수로 넣습니다. 데이터셋과 실제 트레이스에서 필드 이름이 달라도 변수 연결만 바꾸면 되므로 프롬프트를 매번 고칠 필요가 없습니다. 마지막으로 앞에서 쓴 통과·실패 조건을 붙이고, 어떤 경우에만 정답으로 표시할지 명시합니다.

라벨은 정답·오답 두 개로 시작했지만, 부분 정답이나 해당 없음을 추가할 수도 있습니다. DeLucia는 자사 에이전트에서 일부만 맞은 경우를 따로 아는 것이 중요할 때가 있다고 말합니다. 채점자는 라벨 하나와 설명을 돌려주고, 이 설명을 읽으며 동의하지 않는 채점이 나오면 프롬프트를 고쳐 다시 돌립니다. 영상에서는 작은 모델로 실행해 결과를 바로 확인했습니다.

마무리 권고는 짧습니다. 트레이스 20개 정도, 기준 하나, 채점자 하나로 시작하고, 설명을 읽으며 반복한 뒤 평가를 늘리라는 것입니다.

32개로 늘어난 평가도 처음에는 몇 개였습니다

DeLucia가 처음 맡은 일은 Arize 플랫폼 안에 AI 에이전트 Alex를 만드는 것이었습니다. 처음 만든 평가는 질문 답변 정확성, 사용자 불만 감지, 탈옥·유해성 같은 안전 평가 정도로 단순했습니다. 지금 Alex에는 평가 32개가 돌아갑니다. 사용량이 늘면서 실제 운영 데이터를 근거로 필요한 평가를 하나씩 추가했다는 설명입니다.

범용 평가와 맞춤 평가 중 무엇이 낫냐는 질문에는 대체로 맞춤 평가가 낫지만, 평가가 하나도 없는 것보다는 범용 평가라도 있는 편이 낫다고 답했습니다. 질문 답변 정확성이나 환각 감지 같은 기본 템플릿으로 시작하고, 사용 사례에 맞게 다듬어 가면 됩니다.

그 다음 단계로는 두 가지를 꼽았습니다. 하나는 정렬(alignment)입니다. 데이터셋 예시에 사람이 직접 라벨을 붙이고, 채점자의 판단이 사람의 판단과 맞는지 비교합니다. 다른 하나는 온라인 평가로, 새 트레이스가 들어올 때마다 평가를 자동으로 돌려 서비스를 모니터링합니다. DeLucia는 지표와 평가의 차이도 이렇게 구분했습니다. 지표는 무언가 고장 났을 수 있다고 알려 주고, 평가는 실제로 어떤 방식으로 실패했는지 알려 줍니다. 그리고 평가 기준은 개발자 한 사람이 아니라 제품, 개발, 고객 지원, 도메인 전문가, 보안 담당자가 함께 정해야 한다고 강조했습니다.

대회 참가자에게 바뀌는 점: 검증 방법과 한계를 쓰는 근거가 생깁니다

이 절차는 지금 DAKER에서 진행 중인 제주 AI·빅데이터 활용 AI Agent 개발 챌린지에 바로 연결됩니다. 대회 페이지의 평가 기준을 보면 내부 전문가 평가가 70%, ELO 기반 참가팀 상호 평가가 30%입니다. 전문가 평가 100점 가운데 AI Agent 기술성 및 완성도가 25점이고, 평가 내용은 목표에 따른 도구·데이터 활용과 주요 기능의 안정적 수행입니다. 결과 신뢰성 및 재현성은 15점이며 결과 근거·한계의 명확성과 코드·매뉴얼을 통한 재현 가능성을 봅니다.

제출 규칙도 같은 방향입니다. 최종 결과물 zip 파일에 들어갈 결과 설명자료에는 문제 정의, Agent 구조, 주요 기능, 실행 결과와 함께 검증 방법·한계를 적어야 합니다. 운영진은 정상 작동 여부를 확인하려고 코드 실행을 요청할 수 있고, 제출 결과물이 발표나 시연 내용과 현저히 다르면 평가에 반영될 수 있다고 안내합니다. 센터 Agent 운영 PC 최소사양도 Intel Core i7-8700, GTX 1060, RAM 32GB로 정해져 있습니다.

「잘 돌아갑니다」라고 쓰는 것과 「트레이스 20건 가운데 몇 건이 이 조건을 통과했고, 실패한 사례는 이런 유형이었습니다」라고 쓰는 것은 설득력이 다릅니다. 영상의 여섯 가지 메모와 LLM 채점자가 그 문장을 쓸 근거를 만들어 줍니다. 상호 평가에서도 다른 팀의 산출물 두 개를 비교해 더 나은 쪽에 투표하는 방식이므로, 실패 유형과 한계를 분명히 밝힌 설명자료가 비교하는 사람에게 더 잘 읽힐 수 있습니다. 동점일 때는 AI Agent 기술성 및 완성도, 편의성 및 실용성, 필수 데이터 활용 적절성 순으로 우선 선정한다는 점도 대회 페이지에 적혀 있습니다.

현재 대회 페이지에 표시된 참가자는 115명이고, 기획서와 최종 결과물 제출은 11월 20일(금) 오전 10시에 마감됩니다. 참가자 상호 평가는 11월 23일(월) 12시부터 27일(금) 오전 10시까지 진행됩니다.

오늘 할 일: 핵심 기능 하나에 통과 조건 세 줄을 붙이십시오

에이전트의 핵심 기능 하나를 고릅니다. 예를 들어 데이터를 조회해 요약하는 기능이라면 그 기능 하나만 봅니다.
영상의 여섯 가지 항목을 적습니다. 통과 조건에는 요청한 지역과 기간이 결과에 반영됐는지, 사용한 데이터 출처가 답에 표시됐는지처럼 확인 가능한 문장을 씁니다.
실제 실행 기록을 20개 정도 모읍니다. 로그를 남기지 않고 있었다면 입력, 호출한 도구, 최종 출력부터 저장하도록 바꿉니다.
LLM 채점자에게 조건 하나만 채점하게 하고, 라벨과 함께 설명을 받습니다. 동의하지 않는 채점이 나오면 기준 문장을 고칩니다.
통과·실패 건수와 실패 유형을 결과 설명자료의 검증 방법·한계 부분에 그대로 옮깁니다.

평가를 처음부터 많이 만들 필요는 없습니다. 영상의 결론처럼 기준 하나, 채점자 하나로 시작하면 됩니다. 제출 마감 전에 이 작업을 한 번 해 두면, 프롬프트나 모델을 바꿀 때마다 성능이 좋아졌는지 나빠졌는지 숫자로 비교할 수 있습니다.

출처: AI Engineer 채널 영상 「How to Write Your First AI Eval - SallyAnn DeLucia, Arize AI」(2026년 10월 25일 공개). 대회 정보는 DAKER 대회 페이지 기준이며 10월 29일 오전에 확인했습니다. 본문 이미지는 설명용 생성 이미지입니다.