AI 에이전트가 제대로 작동하는지 어떻게 평가할까: Phoenix와 Claude로 하는 평가

메타데이터

• 원문 제목: How to Know If Your AI Agent Is Any Good: Evals With Phoenix & Claude — Laurie Voss, Arize AI
• 채널: aiDotEngineer
• 발표자: Laurie Voss, Arize AI 개발자 관계 책임자. 과거 npm에서 JavaScript 개발을 했다.
• 원문 URL: https://www.youtube.com/watch?v=SHMCGrNJJGc
• 원본 업로드일: 2026-10-17 (YouTube 메타데이터 기준)
• 정리일: 2026-10-18 (Asia/Seoul)
• 영상 길이: 6,973초 (1시간 56분 13초)
• 주요 기술: Phoenix, Claude Agent SDK, Claude Haiku 4.5/5.5, Claude Sonnet 5.5, TypeScript, OpenTelemetry, OpenInference, Vitest

📌 핵심 질문 / 이 영상이 답하는 핵심 논점

==에이전트가 좋은지, 프롬프트나 모델을 바꾼 뒤 실제로 나아졌는지, 그리고 다음 변경에서 회귀하지 않을지를 트레이스와 신뢰할 수 있는 평가로 증명해야 한다.==

• 트레이스(trace)는 에이전트가 어떤 입력·도구·모델 호출을 거쳐 결과에 도달했는지 보여주고, 평가는 그 결과가 기준에 맞는지 측정한다.
• 코드 평가(code eval), LLM 심판(LLM-as-a-judge), 도메인 전문가의 사람 평가(human eval)는 서로 다른 실패를 보완하므로 함께 써야 한다.
• 성공적인 평가는 실패를 찾아내는 데서 끝나지 않고 원인 분석, 프롬프트·데이터 개선, 동일 입력 실험, 회귀 평가(regression eval), CI와 실제 트래픽 감시로 이어진다.

에이전트의 출력과 경로는 비결정적이다. 몇 번의 수작업 확인이나 정확한 문자열 일치를 기대하는 단위 테스트만으로는 품질을 보장할 수 없다. 실행을 자세히 남기고, 무엇을 좋은 결과로 볼지 먼저 합의하고, 서로 다른 관점의 평가를 조합해야 한다. 모든 숫자를 맹신하지 말고 실패 설명과 원본 트레이스를 열어 평가 자체가 공정한지도 확인해야 한다.

1. “괜찮아 보인다”를 테스트 기준으로 바꿔라

1.1. 트레이스는 실행 기록이고 평가는 품질 검사다

1. LLM 출력에는 고정된 정답 문자열이 없다

   1. 같은 프롬프트도 실행할 때마다 다른 문장을 만들며, 표현이 다른 수천 개 답변이 모두 정답일 수 있다.
   2. 개발자가 몇 번 시험해 “괜찮아 보인다”고 배포하면, 예상하지 못한 고객 입력에서 깨지거나 톤 수정이 기능 환각을 만들 때 회귀를 알아차리지 못한다.
   3. 프롬프트 변경은 한 종류의 입력만 바꾸지 않는다. 사용자가 보낼 수 있는 여러 입력에 영향을 주므로 수동으로 전부 확인할 수 없다.

2. 트레이스(trace)와 스팬(span)이 원인을 드러낸다

   1. 트레이스는 한 번의 에이전트 실행에서 각 단계, 도구 호출, LLM 호출의 입력과 출력을 기록한다. 각 스팬은 실행의 한 단계를 나타낸다.
   2. 에이전트 전체 턴은 여러 스팬을 포함하는 부모 스팬으로 구성된다. 스팬에는 입력·출력 외에 실행 시간, 토큰 수, 때로는 비용이 담긴다.
   3. “트레이스는 무슨 일이 있었는지, 평가는 그 일이 잘됐는지를 말해준다.” 평가 결과는 보통 점수와 사람이 읽을 수 있는 라벨을 포함하고, LLM 심판은 왜 그렇게 판단했는지 설명까지 돌려준다.

1.2. 평가 세 종류는 서로 대체하지 않는다

1. 코드 평가(code eval)는 결정적인 조건을 빠르고 싸게 검사한다

   1. JSON 파싱 여부, 500단어 이하인지, 필수 필드나 요청한 티커가 들어 있는지, 금지 문구가 있는지처럼 명확한 조건에 알맞다.
   2. 밀리초 안에 실행되고 모델 호출 비용이 없지만, 의미를 이해하지 못하므로 같은 뜻을 다른 말로 쓴 유효한 답을 놓칠 수 있다. “코드 평가”는 문자열 비교만 뜻하지 않으며 데이터베이스 상태, API 결과, 도구 동작도 검사할 수 있다.

2. LLM 심판은 의미를 읽고 사람은 낯선 실패와 심판을 검증한다

   1. 정확성, 출처 충실성(faithfulness), 고객에게 맞는 어조, 유용성처럼 문맥 이해가 필요한 항목은 LLM 심판이 루브릭(rubric)에 따라 판단한다. 루브릭은 특별한 마법이 아니라 “판단 규칙”이다.
   2. 심판도 비결정적이고 틀릴 수 있으며 비용이 든다. 특히 자신과 같은 계열 모델의 답을 편들거나 자신 있게 틀릴 수 있으므로 사람이 검사해야 한다.
   3. 사람은 아직 예상하지 못한 실패를 발견하는 기준점이지만 느리고 비싸며 반복 판정에 지쳐 결과를 대충 읽을 수 있다. 세 방식은 경쟁 관계가 아니라 서로 다른 구멍을 막는 방어층이다.

1.3. 에이전트에서는 초반 오차가 뒤 단계로 번진다

1. 초기 검색 오류가 유창한 오답 보고서가 될 수 있다

   1. Tesla 분석을 시켰는데 검색기가 Tesla 자동차 회사 대신 18세기 발명가 Nikola Tesla 자료를 가져오면, 에이전트는 그 발명가에 관해 문법과 형식이 완벽한 보고서를 만들 수 있다.
   2. 형식·어조·문법 검사만 통과하므로 결과가 엉뚱한 주제라는 사실은 놓친다. 에이전트는 한 단계의 실수를 다음 단계들이 이어받아 점점 더 그럴듯하게 틀릴 수 있다.
   3. “명백히 틀린 답보다 확신에 차서 틀린 답이 더 위험하다.”

2. 평가가 경로를 고정해 창의적인 정답을 오답 처리하지 않게 하라

   1. Anthropic의 τ²-bench 고객 서비스 항공편 사례에서, 이코노미석 승객의 좌석 변경은 규칙상 불가능해 보였다. 에이전트는 먼저 일등석으로 업그레이드하고 좌석을 바꾼 다음 다시 이코노미로 내리는 우회로로 요청을 완수했다.
   2. 기존 테스트는 예상하지 못한 절차를 밟았다는 이유로 실패 판정을 내렸지만, 실제 요구는 충족됐다. 평가할 때는 특정 도구 호출 순서를 강요하기보다 결과가 적절한지 확인해야 한다. 궤적(trajectory) 평가는 필요할 때 별도로 설계한다.

3. 평가 설명은 다음 수정을 찾는 데이터가 된다

   1. 점수는 대개 0/1이고, 라벨은 pass/fail 또는 actionable/not actionable처럼 뜻을 보여준다. LLM 심판의 설명은 무엇이 빠졌고 무엇을 고치면 좋을지 드러내는 가장 유용한 부분이다.
   2. 수십·수백·수천 개 설명을 모아 다른 LLM이나 코딩 에이전트가 반복 패턴을 찾게 하면 체계적인 실패 원인을 추릴 수 있다.

2. Phoenix로 에이전트 실행 전체를 관찰하라

2.1. 실습 환경과 재현 가능한 출발점

1. 실습은 기존 에이전트의 신뢰성을 높이는 데 집중한다

   1. 이미 준비된 저장소에는 작동하는 에이전트와 단계별 체크포인트가 있다. 길을 잃으면 다음 체크포인트로 옮겨 계속할 수 있고, 실습 도중 프롬프트를 바꾸고 실제 평가를 실행한다.
   2. Node.js 22 이상, TypeScript, Anthropic API 키, 로컬 Phoenix 실행이 필요하다. uvx가 Python 실행을 대신 처리하므로 참가자는 Python을 직접 실행하지 않아도 된다. Phoenix 화면은 localhost:6006에서 열어 둔다.
   3. 컨퍼런스 Wi‑Fi로 내려받기가 느릴 수 있어 진행자는 미리 저장소를 가볍게 만들었다. 과거 World’s Fair 실습에서 제품 이미지 400MB를 넣었다가 참가자들이 저장소조차 받지 못한 일을 겪고 “오늘은 이미지가 없다”고 농담했다.

2. Phoenix는 로컬 또는 팀 서버에서 쓸 수 있는 오픈소스 관측 도구다

   1. Phoenix는 AI 앱의 트레이스를 수집하고, 평가 결과를 트레이스 옆에 저장하며, UI에서 조사할 수 있게 한다. 데이터세트와 실험(experiment)도 지원한다.
   2. 노트북에서 실행하면 데이터가 로컬에 머물고, 서버에 띄우면 팀과 공유할 수 있다. TypeScript 실습 저장소에는 instrumentation.ts, agent.ts, prompts.ts, evals/, queries.json이 있고, 각 단계는 가능한 한 하나의 npm 명령으로 실행된다.
   3. Phoenix CLI의 설정 명령과 코딩 에이전트를 사용하면 언어별 계측 설정을 자동화할 수도 있다. 진행자는 2026년의 튜토리얼은 모든 설정법을 직접 가르치기보다 에이전트에게 README를 읽혀 설정시키는 편이 자연스럽다고 농담했다.

2.2. 데모 에이전트의 흐름과 계측

1. 금융 분석 에이전트는 조사와 보고서 작성 두 턴으로 움직인다

   1. 사용자에게 주식 티커와 “Tesla 차량 인도량” 같은 초점을 받으면 웹을 검색해 현재 자료를 모은 뒤, 별도 작성 턴에서 분석 보고서를 만든다. 실제 투자 분석 제품처럼 보이도록 구성했지만, 오류를 관찰하기 쉽도록 일부러 단순하게 설계했다.
   2. Claude Agent SDK를 쓰며 연구 턴의 세션 ID를 작성 턴에 resume으로 넘긴다. 작성기는 같은 세션에서 앞서 수집한 검색 자료와 연구 노트를 볼 수 있다.
   3. 두 턴을 trace agent로 감싸 하나의 부모 스팬 아래 묶으면 Phoenix에서 연구와 작성이 형제 스팬으로 흩어지지 않아 전체 흐름을 읽기 쉽다.

2. 자동 계측은 도구와 모델 호출을 별도 로깅 코드 없이 포착한다

   1. Phoenix의 등록 함수로 OpenTelemetry(OpenTelemetry)와 OpenInference(OpenInference) 기반 계측을 켜고 로컬 Phoenix를 가리키면 프레임워크에 내장된 LLM·도구 호출 기록이 자동으로 수집된다.
   2. Vercel AI SDK, Mastra, LangChain, OpenAI Agent SDK 등 여러 프레임워크와 제공자를 지원한다. 직접 계측을 추가할 수도 있지만 모든 호출에 수동 로그를 쓰지는 않아도 된다.
   3. TypeScript에서 Claude Agent SDK는 ES module이고 export가 읽기 전용이라, Phoenix가 계측해 돌려준 SDK 복사본을 실제로 사용해야 한다. 원래 패키지를 직접 import하면 앱은 동작해도 트레이스가 기록되지 않는다.

3. 실습 모델과 격리 설정은 의도적으로 실패를 드러낸다

   1. 빠르고 싸며 실수를 관찰하기 좋은 Claude Haiku 4.5를 시작 모델로 삼는다. 프론티어 모델도 틀리지만, 간단한 에이전트에서 오류를 꾸준히 재현하기 어려워 실습에 덜 적합하다.
   2. 도구는 웹 검색을 허용하고 권한 모드는 don't ask로 두어 자동 실행한다. 이 설정은 파일 쓰기를 요청해도 사용자 확인을 받을 수 없는 상황을 만들며, 나중에 하네스(harness) 문제의 원인이 된다.
   3. Claude Agent SDK와 Claude Code를 같은 환경에서 돌리면 에이전트가 개발자 측 키·도구·스킬을 가져가 평가를 비결정적으로 만들 수 있다. 별도 SDK 환경을 마련해 개발 환경 누출을 막는다. 이 격리 문제는 Phoenix 자체의 문제가 아니다.

2.3. 트레이스가 모호한 지시의 원인을 밝혀낸다

1. “보고서를 작성하라”는 출력 위치를 정하지 않았다

   1. 연구 프롬프트와 작성 프롬프트는 일부러 한 줄짜리로 허술하게 두었다. 참가자들에게 “실수하지 마, 팁 100달러 줄게” 같은 문구를 더해도 좋다고 농담하며 서로 다른 프롬프트를 시험하게 했다.
   2. 보고서를 어디에 출력하라고 지정하지 않자 에이전트는 파일로 저장하려 했다. 권한 확인을 하지 않는 설정이라 파일 쓰기가 실패했고, 한 실행은 “재무 보고서 파일을 쓸 권한이 필요하다. 여기서 보고서를 보여줄까?”라고 되물었다. CLI에 결과를 출력하길 원했던 사용자의 의도와 어긋났다.
   3. 같은 입력이라도 어떤 실행은 보고서를 바로 출력하고 어떤 실행은 파일을 쓰려 했다. 이 차이가 비결정성의 실제 모습이다.

2. Phoenix에서는 검색부터 실패한 도구 호출까지 연결해 본다

   1. 상위 트레이스 아래 연구 호출과 작성 호출이 보이고, 연구 스팬 안에는 세 차례 웹 검색이 들어 있다. 각 검색어, 도구 입력과 결과, 이후 보고서 작성, 컴퓨터 경로에 파일을 쓰려다 실패한 호출까지 확인할 수 있다.
   2. 문제 원인은 명확하지 않은 쓰기 지시와 don't ask 권한 설정의 조합이다. 사용자 질문을 더 명확히 했다면 해결될 수 있는 하네스/프롬프트 문제다.
   3. 도구 입력은 JSON 구조를 가지며 스팬 종류, 걸린 시간, 토큰 수, 때로는 비용도 확인할 수 있다. 이런 구조화 입력은 이후 티커처럼 결정적인 조건을 뽑아 평가하기 쉽게 만든다.

3. 실제 트레이스를 읽고 “좋음”을 정의하라

3.1. 평가하기 전 도메인 기준과 입력 분포를 정한다

1. 좋은 재무 보고서의 조건을 먼저 문장으로 써라

   1. 실시간 자료를 사용하고, 올바른 회사를 다루고, 실제 검색 결과에 충실하며, 독자가 무엇을 해야 하는지 말해야 한다.
   2. 이 실습의 구체 기준은 매수(buy)·보유(hold)·매도(sell) 추천이다. “좋은 투자처”라는 모호한 문장만으로는 독자가 행동할 수 없다.
   3. 기준을 쓰기 전에는 사람마다 좋은 결과의 뜻이 다를 수 있다. 제품·지원·영업처럼 고객과 도메인에 가까운 동료를 정의 과정에 참여시켜야 한다.

2. 합성 질의로 시작하되 실제 사용자 입력을 빨리 포함한다

   1. 합성 데이터가 없다면 LLM에 질의를 생성하게 하고, “Tesla의 재무 성과를 조사해라”, “Tesla 주식은 어떤가?”, “야, Tesla 지금 사도 돼?”처럼 문체와 구체성을 일부러 바꾼 뒤 사람이 검토한다.
   2. 합성 질의는 시작점으로 유용하지만 보수적이고 실제 사용자만큼 엉뚱한 범위까지 가지 않는 경향이 있다. 에이전트가 아예 주제 밖 요청을 받을 때의 동작도 고려해야 한다.
   3. 실제 트래픽은 가장 가치 있는 평가 자료다. 제품이 운영되기 시작하면 실제 입력과 실패 사례를 데이터세트에 가능한 한 빨리 편입한다.

3. 실습용 15개 질의는 경계 사례를 의도적으로 포함한다

   1. Apple·Nvidia·Amazon처럼 흔한 회사 외에 Apple과 Microsoft 비교, 비상장사 Rivian, 기술주와 성격이 다른 Coca-Cola가 들어간다.
   2. 가짜 티커 ZZQ는 회사명을 지어내는지, 비슷한 종목을 추측하는지, 존재하지 않는 티커라고 말하는지 확인한다. “yo, Tesla 지금 사도 돼?”는 구어체·모호한 실제 질문을 대표한다.
   3. 배치는 한 번에 다섯 개씩 실행하며 약 3~4분 걸릴 수 있다. 참가자 실습이 실패할 경우 Phoenix의 Phoenix 101 golden 시드 데이터에 미리 실행한 16개 트레이스를 제공한다.

3.2. 자동화 전에 표본을 직접 읽고 나중에 범주화한다

1. 최소 12개 트레이스를 처음부터 끝까지 읽는다

   1. 무엇을 물었고 무엇을 받았는지, 실제로 어떤 점이 잘못됐는지 사람 말로 적는다. 이 수작업은 오래된 방식처럼 보이지만 기대하지 못한 실패(unknown unknown)를 찾는 데 높은 가치가 있다.
   2. Anthropic 팀도 평가 트랜스크립트를 직접 읽고 내부 도구를 만들어 이를 돕는다. 실패 양상을 이해하기 전에 자동화하면 중요한 품질 대신 측정하기 쉬운 것만 재게 된다.
   3. 16개 정도는 직접 충분히 읽을 수 있어도 1,600개를 전부 읽으면 일주일이 걸릴 수 있다. 코딩 에이전트로 대량 분석을 확장하되, 사람의 표본 검토를 유지한다.

2. 관찰을 먼저 적고 분류는 그다음에 한다

   1. 개방 코딩(open coding)은 각 결과에서 관찰한 사실을 범주 없이 서술하는 단계다. 축 코딩(axial coding)은 기록된 관찰을 비교해 공통 실패 범주로 묶는 단계다.
   2. 처음부터 개발자가 예상한 범주에 끼워 맞추면 실제로 생긴 실패를 놓치거나 범주가 지나치게 넓고 좁아진다. Phoenix 플러그인이나 스킬을 설치한 코딩 에이전트에게 트레이스를 읽고 실패 유형·빈도를 분석해 주석(annotation)으로 붙이게 할 수 있다.
   3. 진행자의 에이전트 분석은 파일 저장 권한을 되묻는 반복 문제를 harness leakage로, Tesla 비율 오류를 추론 오류로, 그 밖의 사례를 환각 등으로 분류했다. 참가자별 에이전트가 달라 분석 결과와 라벨도 서로 다를 수 있다.

3. 빈도와 심각도를 곱해 수정 우선순위를 정한다

   1. 가장 자주 발생하는 실패가 늘 가장 먼저 고칠 문제는 아니다. 실패율 40%의 환각도 심각하지만, 금융 에이전트가 폭탄 제조법을 1% 확률로 안내한다면 빈도가 낮아도 즉시 막아야 한다.
   2. 빈도(frequency)와 심각도(severity)를 함께 보아 우선순위를 잡는다. 한 가지 거대한 심판으로 모든 문제를 검사하기보다 서로 다른 평가를 겹쳐서 스위스 치즈 모델처럼 취약점을 보완한다.

4. 비용 없는 코드 평가로 확실한 오류부터 잡는다

4.1. 티커 일치 평가를 작게 만든다

1. 요청한 회사에 대해 썼는지는 단순 코드로 판별할 수 있다

   1. Tesla를 물었는데 Microsoft에 대해 보고서를 쓰면 유용하지 않다. 출력 본문에 요청한 티커가 포함되는지 확인하는 데 별도의 LLM 심판을 쓰는 것은 과한 비용이다.
   2. Phoenix에서 부모가 없는 최상위 스팬을 가져오고, 보조 함수 get agent runs로 실행 ID·입력·출력·조사 결과를 모은다. JSON 입력에서 티커를 읽어 보고서에 있는지 검사하고, 점수·라벨·빠진 티커를 함께 반환한다.
   3. 동일 입력에 같은 결과를 내는 검사는 모두 코드 평가가 될 수 있다. JSON 형식, 길이, 필수어 외에도 DB 상태, 도구 호출의 실제 결과, 외부 API의 주가 대조 등을 활용할 수 있다.

2. 15개 실행에서 무료 검사가 두 회사를 놓쳤다

   1. 코드 평가가 Tesla와 Amazon 두 실행을 실패로 표시했다. Amazon은 AWS 수익성을 물었지만 에이전트가 클라우드 사업만 다루고 Amazon의 소매 사업을 다루지 않았다.
   2. 이런 실패를 비용 없이, 거의 즉시, 결과에 빠진 티커까지 알리는 형태로 잡았다. “코드 평가는 장난감이 아니다.”

4.2. 결과를 평가하고 경로를 과도하게 통제하지 않는다

1. 정답을 만들기 위해 반드시 거쳐야 하는 도구 순서를 고정하지 않는다
   1. “검색 도구를 먼저 부르고 다음 도구를 불렀는가?”처럼 경로를 검사하면 창의적으로 다른 절차를 쓴 정답도 오답으로 처리할 수 있다.
   2. 항공편 사례처럼 에이전트가 예상하지 못한 합법적 해결책을 찾을 수 있으므로, 대개는 결과 품질을 평가한다. 티커 평가는 어떻게 조사했는지가 아니라 보고서가 올바른 회사를 다뤘는지를 본다.
   3. 도구 궤적 평가가 필요한 경우에는 어떤 목적의 평가인지 분리해 설계한다.

5. Phoenix 기본 심판으로 의미와 도구 행동을 점검한다

5.1. 평가 가능한 질문을 고르고 맥락을 제공한다

1. 기본 LLM 심판은 이미 작성된 루브릭을 재사용한다

   1. Phoenix 기본 평가에는 정확성(correctness), 충실성(faithfulness), 완전성(completeness), 환각(hallucination), 거절(refusal), 개인정보(PII), 유해성(toxicity) 등이 있다.
   2. 에이전트 도구 평가로 도구를 골랐는지, 적절한 인자를 전달했는지, 응답을 합리적으로 처리했는지도 검사할 수 있다. 기본 평가는 마법이 아니라 검증해 둔 프롬프트다.
   3. TypeScript 평가기는 Vercel AI SDK를 통해 모델을 호출한다. 실습에서는 에이전트에 Haiku를 쓰고 심판에는 더 능력 있는 Claude Sonnet 5.5를 사용한다. 가능하면 Claude 출력을 OpenAI처럼 다른 제공자 모델로 평가해 동일 모델 선호 편향을 줄인다.
   4. 심판 호출 자체도 전체 추적 설정에 잡히므로 suppress tracing을 켜야 불필요한 심판 트레이스가 쌓이지 않는다. 진행자의 시드 데이터에는 이 설정을 빠뜨려 심판 자신의 트레이스가 섞인 사례도 있었다.

2. 정확성(correctness)은 최신 금융 데이터와 심판 지식이 어긋나 실패했다

   1. 16개 보고서가 전부 0점(부정확)으로 나왔다. 심판은 자신이 알고 있는 정보와 비교했지만 지식 시점이 대략 1월이어서, 에이전트가 10월 주가를 다룬 내용을 미래의 지어낸 정보로 오해했다.
   2. 16개 중 7개 심판 설명은 최신 데이터를 검증할 수 없다고 지적했다. 일부는 숫자의 합이 맞지 않거나 날짜가 모순되는 실제 문제도 집었다.
   3. 모두 실패한 숫자 하나만으로 품질을 판단할 수 없다. 심판이 답할 수 없는 질문을 준 것이므로, 적합한 평가를 고르는 일이 심판을 미세 조정하는 것보다 먼저다.

3. 충실성(faithfulness)은 관찰 가능한 자료와 보고서를 대조한다

   1. “에이전트가 받은 자료로부터 이 보고서를 뒷받침할 수 있는가?”를 묻는다. 사용자 입력, 최종 보고서뿐 아니라 웹 검색 원문과 연구 노트도 심판의 문맥(context)으로 제공한다.
   2. 처음에는 연구 노트만 전달해, 실제 웹 검색에 나온 숫자도 심판이 근거 없는 수치로 오인했다. 검색 결과와 노트를 함께 주자 자료가 어디서 나왔는지 판단할 수 있었다.
   3. 16개 중 14개를 불충실로 판단했고 설명도 구체적이었다. Microsoft 보고서에는 Azure가 2위 클라우드 제공자라는 주장, 3년치 백로그 가시성, 검색 결과에 없는 FY2027 목표가 있었고, Nvidia 보고서는 서로 다른 데이터 포인트를 합쳐 썼다.

5.2. 도구 선택·인자·결과를 각 스팬에서 검사한다

1. 도구 평가는 세 가지 다른 결정을 본다

   1. 도구 선택(tool selection)은 요청에 맞는 도구를 골랐는지 또는 불필요하게 검색했는지를 본다.
   2. 도구 호출(tool invocation)은 회사에 관한 검색어처럼 인자가 타당한지 본다.
   3. 도구 응답 처리(tool response handling)는 반환된 결과를 에이전트가 다음 단계에서 합리적으로 썼는지 본다.
   4. 호출된 도구는 트레이스에서 찾을 수 있지만 당시 사용할 수 있었던 도구 전체는 자동으로 나타나지 않을 수 있어 평가 코드에 목록을 직접 적어야 한다.

2. 모호한 사용자 지시 때문에 도구 심판도 에이전트를 편들 수 있다

   1. 16개 작성 턴 가운데 13개가 보고서를 파일로 저장하려 했고, 일부는 이미 쓰기를 시도한 뒤 bash를 한 번 더 불렀다. 심판은 중복 호출을 지적하면서도 파일 쓰기 자체는 “쓰기 도구가 있고 안전하니 타당하다”고 본 경우가 있었다.
   2. 실제 작성 지시는 “위 조사로 간결한 재무 보고서를 작성하라”뿐이었다. 파일로 쓰라고도, 화면에 출력하라고도 하지 않았으므로 심판이 에이전트의 선택을 합리적이라고 본 이유가 있다. 설명 중 사용자가 파일 저장을 요청하지 않았다고 짚은 것은 한 건뿐이었다.
   3. 프롬프트와 평가 기준은 상호작용한다. 에이전트에 맡긴 요청의 모호성을 명확히 하지 않으면, 올바른 도구 행동이 무엇인지 평가도 일관되게 판단할 수 없다.

3. Phoenix UI는 실패에서 원인 스팬으로 빠르게 이동하게 한다

   1. 평가 결과는 점수와 함께 원본 트레이스 또는 특정 턴·스팬에 붙는다. 루트 실행 점수와 문제를 일으킨 도구 턴의 평가를 구분할 수 있다.
   2. 평가별 필터링과 점수 정렬로 나쁜 실행부터 보고, 실패 점수에서 원인 단계로 한 번에 이동한다. 시연에서는 “정확성은 쓸모가 적고 충실성은 유용했다”는 차이가 분명했다.

6. 애플리케이션에 맞는 LLM 심판을 설계한다

6.1. 행동 가능성을 측정 가능한 조건으로 정의한다

1. 좋은 루브릭은 다섯 요소를 분명히 한다

   1. 심판의 역할과 맥락을 준다. 전문가 역할 지정은 도움이 될 수 있지만, 더 중요한 것은 어떤 업무 결과를 원하는지 설명하는 것이다.
   2. “도움이 되고 정확하게 답하라” 같은 추상적인 요구 대신 관찰 가능한 기준을 적는다. 이 재무 분석에서는 구체적인 매수·보유·매도 제안, 구체적인 위험, 과거 요약에 그치지 않는 미래 지향적 분석을 요구한다.
   3. 입력·출력·지시문·예시를 각기 XML 태그로 감싼다. 경계를 명확히 해 프롬프트 혼동과 인젝션 위험을 낮춘다. Phoenix 템플릿 변수는 각 트레이스의 실제 데이터를 삽입한다.
   4. 예시를 넣을 수 있지만 과적합을 만들 수도 있다. 선택지를 제한된 라벨(actionable / not actionable)로 출력시키고, 최신 평가기는 도구 호출로 구조화된 결과를 반환해 단순 문자열 출력보다 안정성을 높인다.

2. 좋은 보고서와 사실이지만 행동 불가능한 보고서를 구분한다

   1. 행동 가능한 예시는 매출 성장 수치, 동종업계 대비 가치평가, 구체적인 위험, 실행 가능한 추천, 판단을 바꿀 조건을 담는다.
   2. 반대로 사실에 틀린 곳이 없더라도 “투자자는 여러 요소를 고려해야 한다”는 문장만 있고 결론이 없으면 사용자가 행동할 수 없다.
   3. 기준은 읽어 둔 실제 실패에서 도출한다. 자료만 요약하고 해석하지 않은 문제가 트레이스에서 보였으므로, 그 실패를 해결하는 조건을 루브릭에 추가한다.

6.2. 예시와 프롬프트를 실험 대상으로 취급한다

1. 예시는 기준을 구체화하지만 기준보다 강한 의무를 암묵적으로 만들 수 있다

   1. 동일한 16개 보고서에서 예시를 넣었을 때 사람과 심판이 세 번의 실행 중 각각 15/16씩 일치했고, 예시를 뺐을 때는 16/16이 두 번, 15/16이 한 번 일치했다.
   2. 심판의 예시에는 위험 요소가 반드시 있었다. 사람은 위험 목록이 없어도 “Microsoft는 매수”라는 추천이 있으면 행동 가능하다고 표시했지만, 심판은 예시를 엄격히 따라 위험이 빠졌다고 거절했다.
   3. 이는 예시가 나쁘다는 결론이 아니다. 사람의 느슨한 라벨링과 기준을 엄격하게 따르는 심판 중 무엇이 더 타당한지 질문해야 한다. 후속 골든 라벨링에서 발표자는 자신이 기준을 어겼고 심판이 더 엄격하게 맞았다고 인정한다.

2. XML 경계 하나가 같은 데이터의 판단을 뒤집을 수 있다

   1. 예시를 평문으로 넣자 심판은 실제 입력과 예시를 구분하지 못해 모두 비행동 가능으로 판단했다. 예시를 XML 태그로 감싸자 같은 지시·입력·출력인데도 결과가 전부 행동 가능으로 바뀌었다.
   2. 예시를 넣은 평가와 뺀 평가를 모두 시험해 성능을 비교한다. Coca-Cola처럼 경계 사례는 예시 포함 여부에 따라 판단이 달라질 수 있다.
   3. 심판 프롬프트는 코드처럼 버전 관리하고 검토하고 테스트해야 한다. 작은 문구 변화도 정답 라벨에 큰 차이를 만들 수 있다.

3. 사람과 심판이 실제로 다툰 경계 사례를 기록한다

   1. Coca-Cola 보고서는 KO를 보수적 소득형 포트폴리오에 이상적이라고 표현했다. 사람은 이것이 추천인지 망설였고, 심판도 경계선으로 보았다.
   2. Microsoft 보고서는 매수 추천과 기간은 있었지만 위험을 한 건도 적지 않았다. 사람은 허용했지만, 기준에 위험이 명시됐으므로 심판은 약한 사례로 판정했다.
   3. 질의응답에서 “예시를 빼면 위험이 필수 조건이 아니라고 판단해 Microsoft도 행동 가능하다고 본 것인가?”라는 질문이 나왔다. 대답은 루브릭이 모호해 사람과 심판의 엄격성이 달랐다는 것이었다.

6.3. 거대한 만능 심판 대신 분리된 평가와 운영 기준을 둔다

1. ‘신 평가자(god evaluator)’ 하나에 모든 차원을 넣지 않는다

   1. 정확성·어조·완전성·형식·정책을 한 프롬프트에 몰아넣으면 실패했을 때 무엇이 틀렸는지 알기 어렵다. 라벨이 15개로 늘어나는 식의 복잡한 처방도 관리하기 힘들다.
   2. 정확성, 충실성, 행동 가능성 등 평가 차원마다 별도 심판을 둔다. 여러 작은 평가는 서로 다른 사각지대를 가진 방어층으로 작동한다.

2. 릴리스 차단용 가드레일과 개선 목표인 북극성 지표를 나눈다

   1. 주가를 지어내지 않는 것, 요청된 회사를 다루는 것은 지키지 못하면 배포를 막을 가드레일(guardrail)이 될 수 있다.
   2. “추가로 살펴볼 종목을 추천한다”처럼 있으면 좋지만 반드시 배포를 차단할 필요는 없는 품질 목표는 북극성(north star)으로 둔다.

7. 심판도 전문가의 골든 데이터로 검증한다

7.1. 사람 라벨을 고품질 골든 데이터세트로 만든다

1. 심판을 분류기로 보고 사람의 기준과 비교한다

   1. 행동 가능/불가능 같은 예측을 내리는 심판은 분류기다. 예측의 진실값은 해당 분야 전문가가 같은 기준으로 내린 판정으로 만든다.
   2. Phoenix 트레이스에 human actionable 주석을 붙여 전문가가 10개, 20개, 50개 실행을 읽고 골든 데이터세트(golden dataset)를 만들 수 있다. 시연에서는 발표자가 16개 모두에 기준을 적용해 미리 라벨링해 두었다.
   3. 라벨을 붙일 때 사람도 자신의 기준을 지켜야 한다. “위험을 포함해야 한다”고 정해 두고 위험이 없는 Microsoft 보고서를 통과시킨 것은 사람과 심판이 달라진 이유였다.

2. 라벨 수보다 판정 일관성과 과제의 타당성이 중요하다

   1. 100개를 지쳐가며 훑어 대충 표시하기보다 50개를 정확하게 라벨링하는 편이 낫다. 피로는 골든 데이터 품질을 떨어뜨린다.
   2. 사람이 성공할 수 있는 과제를 만들고, 각 과제마다 성공 답안이 실제로 존재함을 확인한다. 에이전트가 항상 실패한다면 에이전트보다 과제 자체가 잘못됐을 수 있다.
   3. 한쪽 방향만 검사하지 않는다. “웹 검색을 해야 할 때 검색하는가?”만 검사하면 불필요한 요청에도 늘 검색하게 학습할 수 있으므로 검색하지 않아야 할 때도 검사한다.
   4. 프로덕션에서 발견한 까다로운 사례를 정답과 함께 골든 데이터세트에 계속 추가한다.

3. 개발용과 테스트용을 분리해 과적합을 막는다

   1. 골든 데이터를 평가 프롬프트를 조정하는 개발(dev) 세트와 최종 검증(test) 세트로 나눈다. Phoenix 데이터세트 분할 기능을 사용한다.
   2. 16개 예시를 span ID 순으로 정렬한 뒤 네 개마다 하나를 테스트로 보내고, 나머지 12개를 개발용으로 쓴다. 정렬하면 다시 실행해도 같은 예시가 같은 세트에 남으며, span ID로 원본 트레이스를 찾을 수 있다.
   3. 실험은 데이터세트, 각 예시에 실행할 작업(task), 결과를 점수화할 평가기(evaluator)로 구성한다. 여기서는 행동 가능성 심판을 실행하고 작은 코드 평가로 사람 라벨과 맞는지 확인한다.

7.2. 일치율과 함께 오류 유형, 편향, 공정성을 본다

1. 12/12 일치는 작은 표본에서 문제 신호가 없다는 뜻이다

   1. 개발용 12개에서 사람과 심판이 전부 일치했지만, 표본이 작아 생산 환경에서도 정확하다는 증명은 아니다. 테스트 세트가 4개뿐이므로 더 큰 데이터가 필요하다.
   2. 루브릭에 “네 기준을 모두 만족해야 행동 가능하다”는 문장을 추가했더니 개발 일치가 12/12에서 11/12로 떨어졌고, 테스트 Apple 보고서도 위험 항목이 약하다는 이유로 새로 실패했다. 더 구체적인 문구가 평가를 더 인간답게 만들거나 개선한다는 보장은 없다.
   3. 사람과 심판의 혼동을 볼 때 정밀도(precision)는 “불가능” 판정 중 실제 불가능한 비율, 재현율(recall)은 실제 불가능한 사례 중 심판이 찾아낸 비율이다. 놓친 실패가 고객에게 전달되는 비용이 크다면 재현율을 우선할 수 있지만, 거짓 경보가 늘어날 수 있다.

2. 심판은 순서·길이·확신·자기 선호 편향을 가진다

   1. 두 선택지 중 첫 번째나 마지막 항목을 선호하는 위치 편향(position bias)이 있으므로 선택 순서를 바꿔 시험한다.
   2. 긴 답변과 유창하고 자신감 있는 답변을 선호하는 길이·확신 편향이 생길 수 있다. 심판 모델이 자기 계열 출력을 높게 평가하는 자기 선호도 고려한다.
   3. 사람끼리도 같은 결과에 동의하지 않는다. 두 전문가의 일치도를 재는 Cohen’s kappa가 이 분야에서 0.2~0.3에 불과할 때도 있다. 심판이 사람과 100% 같아야 하는 게 아니라, 다른 사람의 판정만큼 또는 그보다 나아야 하고 대량 적용할 수 있는지가 중요하다.

3. 실패가 불공정하게 느껴지면 평가부터 다시 살핀다

   1. 실패한 출력을 보고 “이건 괜찮은데?”라는 반응이 나오면 평가 기준이 잘못됐거나 과제가 모호할 수 있다.
   2. CORE-Bench 과학 논문 재현 벤치마크에서 Claude Opus 4.5가 처음 42%를 받았지만, 트랜스크립트를 검토하자 답을 맞게 내고도 요구된 6자리 대신 2~4자리 정밀도를 제시했다는 이유로 오답 처리된 사례가 있었다. 모호하거나 재현 자체가 불가능한 과제도 발견됐다.
   3. 평가를 고친 뒤 점수가 95%로 올랐다. SWE-bench를 포함한 유명 벤치마크도 버전 2·3·4로 계속 개정된다. 제품 평가도 골든 데이터와 기준을 반복해서 재검토해야 한다.

8. 동일 입력 실험으로 개선을 증명한다

8.1. 실패 원인에 맞춰 프롬프트를 고치고 비교한다

1. 측정 없는 프롬프트 변경은 느낌일 뿐이다

   1. 몇 사례를 새로 돌려 눈으로 보는 대신 같은 입력, 같은 평가를 변경 전후에 적용하는 통제된 비교를 한다.
   2. Phoenix에서 실패한 트레이스를 골라 데이터세트로 만들면 전체 예시를 매번 돌리지 않고 문제 사례에 집중할 수 있어 시간과 비용을 절약한다.
   3. 연구 과제와 평가기, 모델 설정을 기록한 실험을 실행하면 각 예시의 결과와 점수를 나란히 비교할 수 있다. 데모에서는 실험을 세 번 반복해 모델의 비결정성이 비교를 흔들지 않도록 했다.

2. 실패 관찰을 해당 수정과 일대일로 연결한다

   1. 추천을 하지 않는다는 판정에는 명시적 추천을 쓰게 하고, 근거 없는 위험에는 근거 자료를 함께 대게 한다.
   2. 충실성 평가에서 지어낸 수치가 보이면 조사 자료에 나온 수치만 쓰라고 지시한다. 반복된 파일 저장 문제에는 보고서를 파일이 아닌 응답으로 출력하라고 명확히 쓴다.
   3. 같은 에이전트 전체를 재실행할 수도 있고 특정 행동이나 하위 과제만 시험할 수도 있다. 충실성 심판에는 계속 조사 자료를 함께 전달한다.

3. 예시 수는 개발 단계와 신뢰 수준에 맞춰 늘린다

   1. 10~20개는 개발 중 방향성을 잡는 데 쓸 만하다. 프로덕션 품질 판단에는 수백 개의 사례가 필요하다.
   2. 오차 범위를 크게 줄이려면 표본 수를 네 배로 늘리는 것이 유용하다. 25개를 100개로 늘리는 변화는 실용적이며, 이후 400개는 비용이 더 커진다.
   3. 표본 수를 실제로 겪은 프로덕션 실패로 채울수록 테스트가 현실에 가까워진다.

8.2. 비결정적 에이전트는 반복 성공의 의미도 정의해야 한다

1. pass@k와 pass^k는 다른 품질 질문에 답한다

   1. pass@k는 k번 시도 중 한 번 이상 성공했는지 본다. 코딩 보조자가 두 번째 시도에서 해결하면 충분한 경우에 알맞다.
   2. pass^k는 k번 모두 성공했는지 본다. 다섯 번에 한 번 오답을 내는 고객 지원 봇이나 부정확한 금융 추천처럼 한 번의 실패가 큰 경우에 더 중요하다.
   3. k를 키우면 pass@k는 성공 기회가 늘어 올라가지만, 모든 시도 통과를 요구하는 pass^k는 적어도 한 번 실패할 가능성이 높아져 내려간다.

2. 개선 순서는 데이터, 프롬프트, 모델, 하이퍼파라미터다

   1. 입력과 검색 자료가 읽기 어렵거나 모호하면 프롬프트를 손봐도 심판과 에이전트가 제대로 판단하지 못한다. 먼저 데이터 품질을 고친다.
   2. 다음은 프롬프트와 루브릭이다. 모델 변경은 효과가 클 수 있지만 여러 성능 요소를 한꺼번에 바꾸고 비용을 올릴 수 있다.
   3. 온도(temperature) 같은 하이퍼파라미터는 상대적으로 영향이 작고, 최신 Claude 모델은 온도 설정조차 허용하지 않기도 한다. 가장 낮은 레버리지부터 시간을 쓰지 않는다.

3. 실험은 개선과 남은 실패를 동시에 보여줬다

   1. 프롬프트 개선 후 티커 포함 검사는 15/16에서 48/48로, 행동 가능성은 5/16에서 48/48로 올라갔다. 기존에 통과했던 다섯 보고서도 계속 통과했다.
   2. 충실성은 2/16에서 3/48로만 개선됐다. “연구에 있는 숫자만 사용하라”는 한 줄로 추천은 나아졌어도 데이터 환각은 해결되지 않았다. 측정한 실패를 하나 고쳐도 다른 실패는 남는다.
   3. 안정적으로 통과하는 능력 평가(capability eval)는 버리지 말고 회귀 평가로 바꿔 이미 잘되던 기능이 다시 깨지지 않게 한다.

8.3. 새 모델은 점수와 함께 비용·행동 성향을 비교한다

1. Haiku 5.5는 충실도를 높였지만 비용도 네 배였다

   1. Haiku 4.5에서 5.5로 바꾼 실험에서 충실성은 세 배 넘게 개선됐지만 여전히 나빴다. 모델 변경만으로 에이전트의 근거 없는 데이터 생성을 해결하지 못했다.
   2. 세 번 반복하는 전체 실험은 약 13분이 걸렸고, 실습 시간상 발표자는 사전 실행 결과를 보여줬다. 비용이 네 배로 늘어난 만큼 추가 품질이 가치 있는지 운영자가 결정해야 한다.

2. 일관성 점수만 높아져도 품질이 좋아진 것은 아니다

   1. 새 모델은 45회 중 41회 보유(hold)를 추천했다. 매번 거의 같은 답을 내므로 일관성은 좋아졌지만, 지나치게 보수적으로 모든 상황에 같은 선택을 한 셈이다.
   2. buy/sell 사이를 오가던 변동은 줄었어도, 한 가지 답만 반복하는 행동은 오히려 나쁠 수 있다. 평가에는 일관성뿐 아니라 추천의 타당성과 다양한 상황에 대한 적절한 반응도 넣어야 한다.

9. 신뢰할 수 있는 기준을 CI와 프로덕션에 연결한다

9.1. 능력 평가를 회귀 테스트로 바꾸고 CI에서 차단한다

1. 새로운 능력을 키우는 평가와 보존하는 평가를 구분한다

   1. 아직 잘하지 못하는 능력을 꾸준히 올리는 시험은 capability eval이다. 반복해서 안정적으로 통과하는 기준은 regression eval로 바꿔 이후 변경에서 다시 실패하면 릴리스를 막는다.
   2. 평가 주도 개발(eval-driven development)은 기능을 구현하기 전에 요구사항 평가를 써서 “완성”의 정의를 측정 가능한 목표로 만든다. 예를 들어 환불 전에 지원 에이전트가 고객 신원을 확인하는지 먼저 검사할 수 있다.

2. Vitest 테스트 스위트에 평가를 넣고 기준으로 게이트한다

   1. agent.eval.ts는 일반적인 Vitest 테스트 파일이다. Coca-Cola, Apple/Microsoft 비교, Rivian, 가짜 ZZQ 등 회귀 질의마다 에이전트를 실행하고 보고서를 코드 평가와 행동 가능성 심판에 통과시킨다.
   2. 요청한 회사 언급 여부는 반드시 지켜야 할 가드레일로 둔다. 행동 가능성은 단일 LLM 판정이 흔들릴 수 있으므로 한 건씩이 아니라 평균 0.8 이상을 목표로 게이트한다.
   3. 데모 실패 사례에서는 네 테스트 모두 티커를 언급했지만 Rivian 보고서가 행동 가능하지 않아 평균이 0.75가 됐다. 결과는 단순한 빨간 십자가가 아니라 무엇이 왜 실패했는지 보여준다.
   4. 같은 테스트를 GitHub Actions에서도 돌릴 수 있으며 Phoenix를 서비스 컨테이너로 시작한다. 전체 에이전트를 모든 커밋마다 반복하면 시간이 오래 걸리고 비용이 크므로 변경 위험에 맞춰 실행한다.

9.2. 배포 뒤 실제 트래픽의 지속적인 품질 저하를 감시한다

1. 사람이 좋은 결과를 아는 팀원은 평가를 정의할 수 있다

   1. 제품 관리자, 지원팀, 반복 고객 불만을 듣는 영업 담당자는 TypeScript를 몰라도 좋은 답의 조건을 말할 수 있다.
   2. 개발자나 코딩 에이전트가 그 기준을 실제 평가 코드로 만들 수 있다. 도메인 지식과 구현 역할을 분리하면 좋은 기준을 더 빨리 만든다.

2. 평가는 배포 시점에서 끝나지 않는다

   1. 운영 중 실제 트래픽 표본에 평가를 계속 적용하고, 한 번의 실패가 아니라 점수가 떨어진 상태가 지속될 때 경보를 낸다. 개별 오답은 잡음일 수 있지만 추세는 회귀 신호가 된다.
   2. “월요일에 모든 체계를 다 갖출 필요는 없다.” 먼저 계측하고 트레이스 12개를 읽는 것만으로도 최종 출력만 볼 때 놓친 정보를 얻을 수 있다. 결과를 읽고 한 단계씩 확장한다.
   3. 전체 주기는 계측, 트레이스 검토, 평가 설계, 심판 검증, 개선 실험, CI 고정, 프로덕션 감시로 이어진다. Phoenix는 오픈소스이므로 저장소 예제를 가져와 자기 코드베이스에 맞게 적용하고 문제를 발견하면 개선에 기여할 수 있다.

주요 발언 모음

“눈에 보기에 괜찮다는 건 테스트 스위트가 아니다.”

“트레이스는 무슨 일이 있었는지를, 평가는 그 일이 잘됐는지를 알려준다.”

“틀린 답은 증상이지 원인이 아니다.”

“측정하지 않은 프롬프트 변경은 그저 감각에 불과하다.”

“나는 ‘잘 된다고 생각한다’에서 ‘잘 된다는 걸 보여줄 수 있다’로 가고 싶다.”

“사람이 무엇이 좋은지 안다면, 이제 누구나 평가를 작성할 수 있다.”

핵심 데이터 & 수치

• 15개 사용자 질의 / 16개 골든 트레이스: 기본 회사 외에 비교, 비상장사, 비기술 회사, 가짜 티커, 구어체 추천 요청을 포함했다. 실습 장애에 대비해 미리 만든 16개 실행을 시드 데이터로 제공했다.
• Tesla 분석가 합의 오류: 서로 다른 웹 검색 자료를 합쳐 매수 50%, 보유 52.6%, 매도 13.1%라고 적어 총합 116%가 됐다.
• 코드 평가: 15개 실행 중 Tesla와 Amazon 두 건에서 보고서가 요청한 티커/대상을 놓쳤다.
• 정확성 심판: 16/16을 부정확으로 판정했고, 그중 7개 설명은 최신 자료를 검증할 수 없다는 심판의 한계를 드러냈다.
• 충실성 심판: 조사 노트와 검색 원문을 함께 주자 14/16을 불충실로 표시하고 근거 없는 Microsoft 주장과 Nvidia 수치 혼합을 지적했다.
• 행동 가능성 라벨: 기존 보고서 16개 중 5개가 행동 가능, 11개가 불가능했다. 개선 프롬프트는 반복 실행 48/48에서 행동 가능으로 평가됐으나 충실성은 3/48에 그쳤다.
• 심판 검증 표본: 16개 라벨 중 12개를 개발용, 4개를 테스트용으로 분리했다. 개발용 12/12 일치는 작은 표본에 대한 초기 신호일 뿐이다.
• 프롬프트 실험의 예시 효과: 예시를 넣었을 때 사람과 15/16 일치, 예시를 뺐을 때는 16/16 두 번과 15/16 한 번 일치했다.
• 표본 설계: 개발 방향은 10~20개로 볼 수 있고 운영 판단에는 수백 개가 유용하다. 오차 폭을 줄이려면 표본을 네 배로 늘리는 것이 도움이 된다.
• 반복 성공: pass@k는 k번 중 한 번 성공, pass^k는 k번 모두 성공을 뜻한다. 서비스 위험에 따라 요구 지표를 골라야 한다.
• 모델 비교: Haiku 5.5는 충실성이 세 배 넘게 나아졌지만 비용은 네 배였고, 45회 중 41회 같은 보유 의견을 냈다.
• CI 기준: 티커 언급은 릴리스 가드레일, 행동 가능성 평균 0.8은 목표로 설정했다. 단일 실패가 아닌 평균을 사용해 심판의 잡음을 완화한다.
• 벤치마크 타당성: CORE-Bench는 정밀도·과제 모호성 문제를 수정한 후 42%에서 95%로 보고 점수가 변했다.

결론 및 시사점

1. 에이전트에 계측을 붙이고 최소 12개의 트레이스를 직접 읽어 실제 실패를 이해하라.
2. 도메인 전문가와 함께 좋은 결과의 기준을 구체적인 판정 조건으로 정의하라.
3. 입력 형식·필수 값은 저비용 코드 평가로, 의미·근거·행동 가능성은 여러 개의 좁은 LLM 심판으로, 새로운 실패와 심판 신뢰도는 사람 평가로 다뤄라.
4. 심판 설명과 검색 흔적을 보고 실패를 검색·추론·환각·범위·하네스 문제로 나눠라. 빈도와 심각도를 모두 반영해 고쳐라.
5. 사람과 심판 모두에게 동일한 기준을 적용하고 골든 데이터의 개발·테스트 분할, 편향, 표본 크기, 경계 사례를 계속 검토하라.
6. 동일 입력·동일 평가를 이용한 반복 실험으로 프롬프트·데이터·모델 변경을 검증하고, 기존 통과 사례가 깨졌는지도 확인하라.
7. 안정된 능력은 회귀 평가로 고정하고 CI 게이트와 실제 트래픽의 지속적 품질 감시로 연결하라.