From Agent Traces to Agent Simulations — Rustem Feyzkhanov, Snorkel AI

URL: https://www.youtube.com/watch?v=Ib5t2RLtxvM 날짜: 2026-07-25 채널: aiDotEngineer

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

에이전트를 평가·출시·개선하려면 ==프로덕션 트레이스(trace)를 오프라인 시뮬레이션(simulation)으로 전환한, 회사 전용의 재현 가능한 벤치마크==가 필요하다.

• 트레이스만으로는 변형 비교와 재현성을 보장하기 어렵다.
• 공개 벤치마크는 특정 도메인·패스 레이트(pass rate)에 치우쳐 있어 실제 출시 의사결정에는 부족하다.
• 벤치마크는 정적인 평가 도구가 아니라, 프로덕션 트레이스로 지속적으로 채워지는 에이전트 라이프사이클의 핵심 구성 요소여야 한다.

Rustem Feyzkhanov는 Snorkel AI AI 플랫폼 팀 리더로서, 매월 수백만 건의 에이전트 시뮬레이션을 운영하며 벤치마크 구축을 엔지니어링 규칙으로 만든 경험을 바탕으로, 에이전트 시뮬레이션의 구조와 운영 방법을 설명한다.

---

1. 에이전트 평가의 패러다임 전환: 트레이스에서 시뮬레이션으로

1.1. 트레이스 기반 평가의 강점과 한계

1. 트레이스가 보여주는 것

   1. 입력 프롬프트(Input prompt): 에이전트가 받은 원래 요청
   2. 수행 행동(Actions): 에이전트가 호출한 도구, API, 검색, 코드 실행 등
   3. 최종 출력(Final output): 에이전트가 내놓은 결과물
   4. 사용 사례: 프로덕션에서 실패 사례를 찾고, 엣지 케이스(edge case)를 분석하는 데 유용하다.

2. 트레이스 기반 평가의 구조적 한계

   1. 변형 비교의 어려움: A/B 테스트는 가능하지만, 데이터베이스 상태, 툴 버전, 외부 API 응답이 매번 달라져서 정확한 "apples-to-apples" 비교가 불가능하다.
   2. 재현성 부족: 같은 프롬프트라도 실행 시점의 환경 차이로 결과가 달라진다.
   3. 비용·지연·재시도 관점 부재: 트레이스는 주로 성공/실패만 보여주고, 운영 비용이나 지연 시간(latency), 재시도 횟수를 체계적으로 비교하기 어렵다.

1.2. 오프라인 시뮬레이션이 해결하는 문제

1. 트레이스를 재현 가능한 실험으로 변환

   1. 프로덕션 트레이스 수집: 실제 사용자 요청이나 내부 워크플로우에서 나온 사례를 끌어온다.
   2. 작업(task)으로 구성: 트레이스를 초기 상태, 입력 프롬프트, 기대 결과가 명확한 평택 단위로 바꾼다.
   3. 오프라인 시뮬레이션 실행: 동일한 환경에서 여러 에이전트 설정을 반복해서 실행할 수 있다.

2. 다양한 메트릭으로 비교

   1. 성공률(Success rate): 과업 해결 여부
   2. 비용(Cost): 토큰 소비, API 호출 비용
   3. 지연 시간(Latency): 전체 및 단계별 소요 시간
   4. 재시도 횟수(Retries): 불필요한 호출이나 루프 빈도
   5. 병렬 실행: 여러 설정을 동시에 평가해 반복 속도를 높인다.

1.3. 전체 스택(full stack) 관점에서의 평가

1. 모델 비교가 아닌 시스템 비교

   1. 프롬프트 변경: system prompt, few-shot, instruction 변형
   2. thinking 레벨 조정: reasoning depth, chain-of-thought 설정
   3. 도구·스킬 구성: 사용 가능한 MCP 도구, API, 파일 접근 범위
   4. 하드니스(hardness) 튜닝: 평가 난이도나 제약 조건 조절
   5. 핵심 원칙: 환경(environment)과 검증기(evaluator)를 고정한 채, 에이전트 시스템의 다른 요소만 바꿔야 한다.

2. 에이전트를 출시하기 위한 삼위일체(trifecta) 사용 사례

   1. 평가(Evaluation): 에이전트가 잘 동작하는지 확인
   2. 통합 테스트/릴리스 게이트(Integration test / release gate): 스택 변경 시 회귀(regression) 방지
   3. 학습 데이터(Training set): 시뮬레이션 결과를 활용해 소형 모델을 미세 조정(fine-tuning)
   4. Snorkel 사례: 시뮬레이션 환경에서 대형 planning 모델의 성능을 소형 모델에 재현시키는 예시를 웹사이트에 공개했다고 언급.

---

2. 공개 벤치마크와 사내 벤치마크의 차이

2.1. 공개 벤치마크의 한계

1. 도메인 특화

   1. SWE-bench: GitHub issue 수정에 특화
   2. TerminalBench: 터미널 기반 에이전트에 특화
   3. Co-Bench(Computer Use Benchmark): 컴퓨터 사용 에이전트에 특화
   4. 문제점: 회사의 실제 도메인, 정책, 도구를 반영하지 못한다.

2. 패스 레이트 중심

   1. 새로운 모델이 발표될 때마다 "X% 달성" 식으로 비교하는 데 초점이 맞춰져 있다.
   2. 적합한 용도: 모델 능력의 프론티어(frontier)를 파악하고 사전 지식(prior)을 쌓는 데는 유용하다.
   3. 부족한 용도: 실제 운영에서는 비용, 지연, 재시도, 정책 준수 등 다양한 메트릭이 중요하다.

2.2. 사내(private) 벤치마크가 필요한 이유

1. 회사 도메인 정합성

   1. 사용 사례(use case): 실제 고객이나 내부 직원이 요청하는 업무
   2. 도구: 회사 에이전트가 실제로 갖춘 API, MCP 도구, 데이터베이스
   3. 정책: 데이터 접근 권한, 승인 절차, 보안 규정
   4. 프로덕션 환경: 실제 배포 상태와 유사한 인프라

2. 출시(ship)를 위한 근거

   1. 공개 벤치마크는 방향성을 제시한다.
   2. 사내 벤치마크는 "이 에이전트를 실제로 출시해도 되는가"를 결정한다.

---

3. 벤치마크 태스크의 해부학(anatomy)

3.1. 벤치마크 실행 흐름

1. 입력 단계

   1. 프롬프트: 에이전트에게 주어지는 사용자 요청
   2. 초기 환경: 데이터베이스, 파일, API 상태, 시뮬레이션된 사용자 상태

2. 에이전트 실행 단계

   1. 도구 호출: APIs, MCP tools, database queries, file operations
   2. 상호작용: 환경과 지속적으로 데이터를 주고받으며 과업 해결
   3. 산출물: 출력 텍스트, 변경된 환경 상태, 아티팩트(artifact, 생성 파일 등)

3. 검증(verification) 단계

   1. 최종 환경 상태: 데이터베이스, API 응답, 파일 변화 등
   2. 트레이스: 에이전트가 수행한 전체 행동 기록
   3. 아티팩트: 생성된 코드, 문서, 보고서 등
   4. 메트릭 산출: 성공 여부, 비용, 지연, 재시도, 품질 점수

3.2. Oracle의 역할

1. Oracle이란?

   1. 정답 솔루션: 실제 에이전트 대신 "정답" 절차를 수행하는 코드나 스크립트
   2. 목적 1: 태스크가 처음부터 해결 가능한지(solvable) 확인한다. 해결 불가능한 태스크로 에이전트를 평가하는 것은 무의미하다.
   3. 목적 2: 환경과 검증기가 제대로 작동하는지 확인하는 기준점

2. Oracle 실행 결과의 활용

   1. 기대 상태 생성: 어떤 최종 환경 상태가 "올바른" 것인지 알려준다.
   2. 검증기 검증: Oracle이 통과해야만 해당 태스크를 벤치마크에 포함할 수 있다.

3.3. Harbor 형식의 파일 구조

1. Harbor 형식 개요

   1. TerminalBench 팀이 만든 벤치마크 포맷
   2. 세 가지 파일 그룹으로 구성

2. 파일 그룹

   1. instruction.md: 에이전트가 보는 작업 지시서
   2. environment: Dockerfile, docker-compose 등 실행 환경 정의
   3. Oracle + verifiers: 에이전트는 볼 수 없으며, 해결 가능성 확인과 채점에 사용
   4. metadata: 태스크 난이도, 카테고리, 태그 등 부가 정보

3. 형식의 핵심 가치

   1. 단순해 보이지만, 이를 통해 동일한 환경에서 반복 실험을 실행할 수 있다.
   2. "벤치마크도 소프트웨어"라는 관점의 출발점.

---

4. 시뮬레이션 환경 설계

4.1. "미니 프로덕션(mini production)" 원칙

1. 프로덕션과의 유사성

   1. 데이터베이스: 실제 스키마와 데이터 분포를 반영한 스냅샷 사용
   2. API 서비스: 실제 서비스의 인터페이스와 계약(contract)을 동일하게 유지
   3. 도구: 에이전트가 실제로 사용하는 MCP 도구, CLI, 파일 시스템
   4. 정책: 접근 권한, 승인 흐름 등을 반영

2. 완전한 프로덕션을 복제하지 않는 이유

   1. 비용과 실행 속도
   2. 민감한 실제 사용자 데이터 제외
   3. 통제 가능한 초기 상태 유지

4.2. 시뮬레이션된 사용자(simulated user)

1. 필요성

   1. 실제 사용자를 시뮬레이션에 넣을 수는 없다.
   2. 하지만 많은 에이전트 과업은 사용자와의 상호작용(질문-응답, 승인 요청 등)을 포함한다.

2. 구현 방법

   1. LLM 기반 사용자: 별도의 프롬프트와 맥락을 가진 LLM이 사람 행동을 모방
   2. 행동 시나리오: 특정 질문에 대한 답변, 승인/거부 패턴, 추가 정보 제공 등
   3. 일관성 유지: 동일한 시뮬레이션 내에서 사용자 응답이 재현 가능해야 한다.

4.3. 환경 구성 패턴

1. 스냅샷(snapshot)

   1. 실제 데이터베이스의 일부를 복제하거나 합성 데이터로 생성
   2. 초기 상태를 고정해 반복 실험의 일관성 확보

2. 사이드카(sidecar) 컨테이너

   1. 에이전트가 실행되는 메인 환경 외에 API 서비스, 데이터베이스, MCP 도구 등을 별도 컨테이너로 실행
   2. 통합 테스트 구성과 유사

3. 모의 객체(mock)

   1. 외부 결제 게이트웨이, 이메일 서비스, 검색 엔진 등은 모의 응답으로 대체
   2. 인터페이스는 실제와 동일하게 유지

4.4. 장기 과업(long-horizon task) 처리

1. 다중 단계(multi-step) 시뮬레이션

   1. 시간이 오래 걸리는 업무를 여러 단계로 분할
   2. 각 단계별 별도 프롬프트와 검증기 사용

2. 조기 종료(early termination)

   1. 중간 단계에서 실패 징후가 보이면 시뮬레이션을 중단해 비용과 시간 절약
   2. 활용: 수 시간 또는 수 일에 걸친 워크플로우를 단축된 시간에 평가

---

5. 검증기(verifier) 설계

5.1. 검증기가 다루는 데이터

1. 세 가지 입력

   1. 최종 환경 상태(world state): 데이터베이스 변경, API 응답, 사용자 응답 기록
   2. 트레이스(trace): 에이전트가 호출한 도구와 추론 과정
   3. 아티팩트(artifacts): 생성된 파일, 코드, 문서 등

2. 전통적 검증과의 차이

   1. 전통: 에이전트 출력물만 검증(예: 생성된 코드를 테스트)
   2. 에이전트 시뮬레이션: 행동 과정과 환경 변화까지 포함해 검증

5.2. 검증 방법의 종류

1. 결정론적 검증(deterministic checks)

   1. 적합한 경우: 최종 출력, 특정 도구 호출, 파일 내용, 데이터베이스 상태 등
   2. 장점: 빠르고, 재현 가능하며, 해석이 명확
   3. 사례: "생성된 SQL이 정확한 row를 반환하는가?", "에이전트가 승인 API를 호출했는가?"

2. LLM-as-a-judge / Agent-as-a-judge

   1. 적합한 경우: 추론 품질, 계획 적절성, 자연어 응답 품질 등
   2. 활용: 트레이스가 논리적으로 일관적인지, 사용자 질문에 적절히 대응했는지 평가
   3. 주의: 평가자 모델 자체의 편향과 비용을 고려해야 한다.

3. 전문가(SME) 검토

   1. 활용 시점: 모든 것을 사람이 볼 필요는 없다.
   2. 필요한 경우: 에이전트 결과와 검증기 평가가 일치하지 않거나, 도메인 전문 지식이 필요한 분쟁 지점
   3. 목적: 검증기를 조율하고, 에이전트 행동을 정성적으로 평가

5.3. 검증기 선택의 실용적 기준

1. 사용 사례에 따라 다르다
   1. 단일 방법보다는 여러 방법을 조합
   2. 코드 실행 결과는 결정론적 검증, 자연어 품질은 LLM 판정, 이의 제기는 SME 처리

---

6. 벤치마크를 소프트웨어로 다루기

6.1. 벤치마크 개발에서 흔한 함정

1. 보상 해킹(reward hacking)

   1. 에이전트가 시뮬레이션 환경임을 인지하고 검증기를 속이는 행동
   2. 예: 검증기가 특정 파일 존재만 확인하면, 에이전트가 아무 내용이나 넣는다.

2. 태스크가 너무 쉬움

   1. 검증 기준이 너무 광범위하면 에이전트가 항상 통과
   2. 실제 능력 차이를 구분하지 못함

3. 검증기가 너무 엄격함

   1. 에이전트가 합법적인 해결책을 찾아도 불합격 처리
   2. 실제로는 solvable한 태스크를 실패로 착각

4. 불안정한 에이전트 성능

5. 동일한 태스크에서 성공 여부가 크게 변동

6. 평가 메트릭의 신뢰도 하락

6.2. 벤치마크 개발을 위한 CI 파이프라인

1. 기본 검사

   1. 의존성 고정(pinning): Python 패키지, Docker base image, 도구 버전 고정
   2. 누락된 fixture 확인: 데이터, 파일, 환경 변수 등
   3. 기본 이미지 정합성: Dockerfile이 의도한 환경을 만드는지 확인

2. Oracle 실행

   1. 모든 태스크는 Oracle이 통과해야 한다.
   2. Oracle이 실패하면 태스크 자체가 solvable하지 않은 것이므로 수정이나 제외 필요

3. 에이전트 샘플 실행

   1. 여러 번 실행해 실제로 해결 가능하면서도 어려운지 확인
   2. 난이도 태깅: 쉬움(easy), 중간(medium), 어려움(hard)으로 분류

4. 승인(approval) 프로세스

   1. 벤치마크에 포함하기 전에 태스크를 검토하고 승인
   2. "태스크 품질 게이트" 역할

6.3. 벤치마크 개발의 문화적 의미

1. 엔지니어링 규칙(discipline)
   1. 벤치마크는 단순한 데이터셋이 아니라 코드이며, 버전 관리와 CI가 필요한 소프트웨어 자산이다.
   2. 최근 수년간 수백 개의 벤치마크가 등장했지만, 이를 제품 팀 내에서 지속적으로 운영하는 문화가 더 중요하다.

---

7. 에이전트 개선 및 출시 루프

7.1. 기준선 수립과 반복

1. 기준선(baseline) 측정

   1. 현재 에이전트 설정으로 전체 벤치마크를 실행
   2. Arize와 같은 실험 기록 도구로 결과를 저장

2. 실패 분석

   1. 어떤 태스크 유형에서 실패하는지 분류
   2. 비용, 지연, 재시도가 높은 사례 식별

3. 변경 및 재실험

   1. 한 번에 하나씩 변경: 프롬프트, 도구, 모델, 하드니스 등
   2. 동일 환경에서 재실행: 환경과 검증기를 고정해 영향력을 명확히 측정

4. 릴리스 게이트

   1. 설정 변경 후 벤치마크가 기준을 통과하면 프로덕션 출시 허용
   2. 회귀 발생 시 출시 차단

7.2. 수정은 올바른 위치에

1. 프롬프트 스태핑(prompt stuffing) 경고

   1. "이러지 마라, 저러지 마라" 식으로 프롬프트에 규칙을 계속 쌓는 것은 한계가 있다.
   2. 컨텍스트 길이 낭비와 예측 실패 가능성 증가

2. 대안적 수정 위치

   1. 하드니스 조정: 컨텍스트 과부하를 줄이기 위해 과업 범위나 제약을 조정
   2. 스킬(skill) 추가: 누락된 절차나 도구 사용법을 별도 모듈로 분리
   3. 구조화된 출력(structured output): 특정 출력 스키마를 강제
   4. 환경/도구 수정: 에이전트가 아닌 외부 시스템의 결함을 고치는 경우도 있음

7.3. 프로덕션에서의 두 개의 루프

1. 루프 A: 벤치마크 확장

   1. Observability: Arize 등으로 프로덕션 트레이스와 실패 사례를 수집
   2. 태스크 변환: 실패한 사례를 새로운 시뮬레이션 태스크로 만든다.
   3. 벤치마크 업데이트: 승인 후 벤치마크에 추가

2. 루프 B: 시뮬레이션 기반 실험

   1. 실험 실행: 새로운 에이전트 설정으로 확장된 벤치마크를 실행
   2. 결과 기록: 성능, 비용, 회귀 여부 기록
   3. 릴리스 결정: 기준 통과 시 프로덕션 배포

3. 두 루프의 연결

   1. 관측(observability)과 실험(experimentation)은 "동전의 양면"
   2. 프로덕션 데이터가 벤치마크를 풍부하게 하고, 벤치마크가 프로덕션 출시를 안전하게 만든다.

---

8. Q&A

8.1. 학습/검증 분할(train/validation split)

1. 80/20 분할
   1. 질문: 벤치마크 예시를 얼마나 포함해야 하며, train/test로 어떻게 나누는가?
   2. 답변: 전통적인 머신러닝 관행과 유사하게 standalone 검증 세트를 둔다.
   3. 에이전트가 실험 과정에서 보지 못한 데이터로 최종 설정을 검증해야 한다.
   4. 비율은 사용 사례에 따라 조정되지만, 80/20이 일반적인 출발점이다.

8.2. 커버리지와 데이터 분포

1. 커버리지 확보 방법

   1. 질문: 프로덕션 경험이 없을 때 어떤 데이터를 포함해야 하는가?
   2. 답변: "빵과 버터" 사용 사례와 엣지 케이스를 모두 포함해야 한다.
   3. 해피 패스(happy path): 정상적으로 잘 작동해야 하는 주요 업무
   4. 엣지 케이스: 도구 실패, 데이터베이스 문제, 예외 상황 등
   5. 통합 테스트처럼 생각할 것.

2. 수작업 vs 자동화

   1. 질문: 에이전트로 시뮬레이션을 만들 것인가, 아니면 수작업으로 만들 것인가?
   2. 답변: 환경 구축과 프로덕션 맥락은 사람이 한 번 정의해야 한다.
   3. 그 이후의 태스크 생성, 코드 작성 등은 에이전트로 자동화할 수 있다.

8.3. LLM vs 인간 전문가 검증

1. 전문가 개입 시점
   1. 질문: 검증기로 LLM과 인간 전문가 중 언제 무엇을 사용하는가?
   2. 답변: 모든 것을 사람이 검토할 필요는 없다.
   3. 분쟁 지점: 에이전트 결과와 여러 검증기 평가가 일치하지 않을 때
   4. 목적: 검증기를 조율하고, 에이전트 행동을 도메인 관점에서 정성 평가

---

주요 발언 모음

"Every company needs a benchmark. It's the only way to reliably evaluate, release, and improve your agents."

"Public benchmark is useful to orient and build your prior, but your private benchmark is useful to ship."

"Offline simulation turns traces into repeatable experiments."

"In production, you don't care about the model, you care about the full system."

"Benchmark is software. It's code. It's files. You need to treat it as such."

"Observability and experimentation are two sides of the same coin."

---

핵심 데이터 & 용어

• Snorkel AI: 데이터 서비스 및 벤치마크 구축을 제공하는 회사. AI 플랫폼 팀이 월간 수백만 건의 에이전트 시뮬레이션을 운영
• Agent trace: 입력 프롬프트, 에이전트 행동, 최종 출력으로 구성된 프로덕션 기록
• Agent simulation: 트레이스를 재현 가능한 오프라인 실험으로 바꾼 평택 환경
• Harbor format: TerminalBench 팀이 제안한 벤치마크 파일 구조(instruction.md, environment, Oracle/verifiers, metadata)
• Oracle: 태스크의 해결 가능성을 확인하는 정답 솔루션
• Verifier: 최종 상태, 트레이스, 아티팩트를 분석해 메트릭을 산출하는 검증기
• Deterministic check / LLM-as-a-judge / SME review: 검증의 세 가지 주요 방법
• Arize: 실험 기록과 관측을 연결하는 데 언급된 도구
• MCP tools: Model Context Protocol 기반 에이전트 도구
• Reward hacking: 에이전트가 시뮬레이션의 검증 기준을 속이는 행동

---

결론 및 시사점

1. 벤치마크는 에이전트 조직의 핵심 인프라다.

   • 단순한 평가 도구를 넘어, 에이전트 출시와 개선의 기준이 된다.

2. 트레이스는 출발점이고 시뮬레이션은 실행 가능한 평가 환경이다.

   • 프로덕션 실패 사례를 재현 가능한 태스크로 바꿔야 비용·지연·재시도를 비교할 수 있다.

3. 사내 벤치마크는 회사의 도메인과 운영 메트릭을 반영해야 한다.

   • 공개 벤치마크는 모델 능력 파악용, 사내 벤치마크는 출시 결정용.

4. 벤치마크도 코드처럼 관리해야 한다.

   • CI, Oracle 검증, 난이도 태깅, 승인 프로세스를 갖춘 소프트웨어 자산으로 운영.

5. 수정은 프롬프트에만 의존하지 말고 올바른 위치에서 한다.

   • 하드니스, 스킬, 구조화된 출력, 환경/도구 개선 등 다양한 레버를 활용.

6. 관측과 실험이 연결된 두 개의 루프를 만든다.

   • 프로덕션 트레이스로 벤치마크를 확장하고, 벤치마크로 출시 전 위험을 줄인다.

7. 에이전트 평가는 팀의 엔지니어링 문화가 되어야 한다.

   • 도구와 형식만으로는 충분하지 않으며, 지속적인 품질 관리와 전문가 개입 문화가 필요.