실제 작업으로 에이전트를 테스트하는 방법 (Harbor 사용법) - 젠더 송, 아리즈 AI

하이라이트

• 하버(Harbor)는 격리된 도커 컨테이너 환경에서 실제 데이터와 자연어 지시사항을 통해 에이전트를 테스트하고 평가하는 오픈소스 프레임워크다.

• 검증기(verifier)는 에이전트의 내부 실행 과정과 독립적으로 작동하며, 환경 내 부수 효과와 파일 시스템 변경 사항만을 확인해 0 또는 1의 보상을 산출한다.

• 오라클(Oracle)은 작업을 완벽히 해결하는 정답 스크립트로, 에이전트 토큰 비용을 소모하기 전에 환경 설정과 검증기의 정상 작동 여부를 사전에 검증한다.

• 각 작업과 시행(trial)은 독립된 컨테이너에서 격리되어 실행되므로, Daytona와 같은 플랫폼에서 약 200개의 동시 워커를 활용해 수평적으로 병렬 확장할 수 있다.

• 에이전트의 다단계 실행 과정은 ATIF(Agent Trajectory Interchange Format) 규격의 JSON 추적으로 기록되며, OpenTelemetry 기반 OpenInference 형식으로 변환되어 Phoenix에서 시각화된다.

• 집계 쿼리 시 GraphQL 대신 SQL 도구를 우선 사용하도록 프롬프트를 수정하자 전반적인 도구 호출 횟수와 실행 턴 수가 감소했다.

타임라인

1. 00:00 - 03:15

   하버 프레임워크의 개념과 핵심 평가 구조

   감에 의존한 배포 대신 객관적인 증거를 바탕으로 에이전트 시스템을 배포하는 방법론을 다룬다. 자연어로 정의된 현실적 작업과 데이터를 격리된 환경에 주입하고, 에이전트 완료 후 검증기 스크립트를 통해 성공(1) 또는 실패(0)의 보상을 산출한다. 여러 작업을 묶어 데이터셋을 구성하면 에이전트 하네스나 프롬프트를 수정할 때마다 성능 변화를 신속하게 추적할 수 있다.

   • 하버는 실제 데이터와 자연어 작업 지시사항을 에이전트에 전달하는 격리된 샌드박스 평가 도구다.
   • 각 작업마다 고유하게 정의되는 검증기는 환경 내 의도한 부수 효과를 확인하고 이진 보상을 출력한다.
   • 에이전트 구현 방식이 달라져도 작업 정의와 검증기는 동일하게 유지되어 지속적인 피드백 루프를 형성한다.
2. 03:15 - 07:56

   하버의 아키텍처와 오라클 솔루션의 역할

   하버의 작업 실행 파이프라인과 내부 규격을 설명한다. LLM의 확률적 특성을 감안해 각 작업마다 복수의 독립 시행(trial)을 설정할 수 있으며, 매 시행마다 신규 도커 컨테이너가 배포된다. 정답 코드 역할을 하는 오라클을 사전에 투입해 데이터 정합성과 검증기 오류를 먼저 해결함으로써 불필요한 LLM API 비용 지출을 방지한다. 실행 중 발생하는 모든 도구 호출과 세부 단계는 ATIF 포맷의 궤적으로 수집되어 잡(Job) 단위로 관리된다.

   • 작업 명세는 마크다운 파일로 작성되며, 실행 환경은 관련 데이터가 시드된 도커파일로 정의된다.
   • 오라클은 작업을 완벽히 해결하는 정답 스크립트로, 에이전트 토큰을 소비하기 전에 파이프라인의 무결성을 검증한다.
   • 에이전트의 내부 실행 단계는 JSON 기반 ATIF 규격으로 기록되어 디버깅과 로깅에 활용된다.
3. 07:56 - 14:19

   검증 도구의 블랙박스 평가 원칙과 구현 격리

   실패한 데이터베이스 마이그레이션 복구 작업을 예시로 들어 검증기의 구체적인 동작 방식을 설명한다. 에이전트가 코드를 수정하고 작업을 마치면, 검증 스크립트가 실행되어 마이그레이션의 종료 코드(상태 코드 0)와 테이블 컬럼, 인덱스 생성 여부를 직접 검사한다. 인터페이스 통합 테스트처럼 에이전트를 블랙박스로 취급하므로, CLI나 MCP 서버 등 에이전트 접근 방식을 전면 개편해도 테스트 코드를 수정할 필요가 없다.

   • 검증기는 에이전트의 실행이 완료된 후 도커 컨테이너에 마운트되어 부정행위를 차단한다.
   • 표준 검증기는 내부 구현 과정을 보지 않고 환경에 남겨진 최종 부수 효과만을 확인한다.
   • 구현과 테스트가 결합하지 않아야 내부 도구나 프롬프트를 교체해도 테스트 스위트가 깨지지 않는다.
4. 14:19 - 20:37

   병렬 확장을 통한 대규모 평가와 Phoenix 연동

   독립된 도커 환경을 바탕으로 대규모 테스트를 신속하게 병렬 처리하는 구조를 설명한다. Daytona 환경에서 약 200개의 동시 워커를 실행해 Claude Code나 Codex 같은 복수 에이전트 모델의 성능을 여러 차례 시도(k회)하여 종합 메트릭으로 산출한다. 또한 ATIF 규격 추적 데이터를 오픈 표준인 OpenInference로 변환해 Phoenix UI에 연결함으로써 데이터셋 버전 관리, 궤적 시각화, 보상 추적 워크플로를 구축할 수 있다.

   • 각 시행이 독립된 컨테이너에서 구동되므로 Daytona 같은 플랫폼에서 200개의 워커로 병렬 확장이 가능하다.
   • 복수 시행 결과를 바탕으로 pass@k 같은 집계 지표를 데이터셋 전반에 걸쳐 도출한다.
   • 하버의 ATIF 궤적은 OpenInference 형식으로 변환되어 Phoenix에서 실험 추적 및 시각화가 이뤄진다.
5. 20:37 - 33:15

   단일 노드 아키텍처 환경 패키징과 하버 CLI 구동 원리

   복합 시스템을 도커 컨테이너로 캡슐화해 하버에 연동하는 구조적 특성을 다룬다. Phoenix 서버, SQLite 파일, 에이전트용 스킬 파일, CLI 및 MCP 서버 전체를 단일 컨테이너에 패키징하여 실제 사용 환경과 동일한 테스트 베드를 구성한다. 하버 CLI는 외부 호스트 환경에서 컨테이너 내부의 사전 정의된 스크립트들을 순차적으로 호출하며 작업을 조율하고, 성공 여부는 컨테이너 내부의 SQLite 테이블 레코드나 REST 응답을 직접 조회해 판정한다.

   • Phoenix 서버는 단일 노드 기반으로 SQLite 데이터와 함께 통째로 도커 컨테이너화된다.
   • 하버 자체는 도커 내부가 아니라 호스트 머신이나 GitHub Actions 러너에서 실행되는 오케스트레이션 CLI다.
   • 하버와 컨테이너 간의 계약은 작업 시작, 오라클, 검증기 스크립트가 정해진 디렉터리 경로에 존재하는지 여부로 성립된다.
6. 33:15 - 44:11

   SQL 도구 추가 및 프롬프트 개선을 통한 도구 호출 최적화

   최근 발생한 도구 호출 비효율 문제를 해결하고 이를 하버로 검증한 실제 사례를 소개한다. 사용자 집계 요청에 대해 에이전트가 수많은 페이지네이션 API를 호출하던 문제를 해결하기 위해 읽기 전용 SQL 도구를 추가하고 프롬프트 지침을 수정했다. Claude를 이용해 도메인별 질문과 정답 SQL 쿼리를 생성하여 데이터셋을 마련한 뒤, 프롬프트 수정 전후의 지표를 비교해 정답률을 유지하면서 도구 호출 수를 줄이는 최적화를 검증했다.

   • 집계 쿼리 처리 시 REST나 GraphQL 페이지네이션으로 인한 과도한 도구 호출을 막기 위해 읽기 전용 SQL 도구를 도입했다.
   • 집계 작업에 SQL을 먼저 사용하도록 프롬프트를 수정한 결과 도구 호출 횟수와 작업 턴 수가 감소했다.
   • Claude를 활용해 집계 및 비집계 가상 질의와 오라클 정답 세트를 합성하여 테스트 데이터셋을 구축했다.
7. 44:11 - 55:52

   Phoenix 비교 데모와 스킬 중심 회귀 테스트 전략

   Phoenix 대시보드 시연과 스킬 기반 회귀 테스트 구현 현황을 다룬다. 모델 변경 전후의 실행 궤적을 비교해 Bash 에뮬레이터 경유 GraphQL 호출이 직접 SQL 실행으로 전환되었음을 확인한다. 평가의 최종 목적은 상용 파운데이션 모델 자체가 아니라, 모델에 연결된 사내 전용 MCP 서버, CLI 도구, 프롬프트, 도메인 스킬 전체를 하나의 통합 시스템으로 묶어 프로덕션 환경에서의 실효성을 증명하는 데 있다.

   • Phoenix 비교 뷰를 통해 프롬프트 변경 전후의 GraphQL 호출 감소와 SQL 호출 증가를 단일 화면에서 대조한다.
   • 스킬 워크플로의 해피 패스(happy path)를 구축해 Playwright와 유사한 방식의 E2E 회귀 테스트를 수행한다.
   • 단일 모델 자체가 아닌 코딩 에이전트와 맞춤형 MCP 서버, 스킬 인프라가 결합된 통합 엔티티 전체를 평가 단위로 삼는다.