에이전트 개선 루프는 trace를 기록하고, 피드백을 재현 가능한 eval로 바꾼 뒤, 같은 게이트를 다시 통과시키는 순환 구조입니다.
검증일: 2026년 9월 11일. OpenAI 공식 Cookbook의 개선 루프 예제, Agents SDK의 tracing 문서, 현재 Evals 안내를 다시 확인하고 로컬 테스트 harness를 실행했습니다. 이 글은 공식 문서의 구조와 로컬 실행 결과를 구분합니다. 계정·이메일·쿠키·고객 자료·API 키를 사용하지 않았고, OpenAI 서버로 요청을 보내거나 서버 trace를 수집하지 않는 환경에서 검증했습니다.
먼저 확인할 결론: trace만으로는 개선 루프가 완성되지 않는다
trace는 어떤 일이 일어났는지 보여주지만 무엇을 고쳐야 하는지 자동으로 결정하지는 않습니다. 개선 루프는 실행 기록, 사람의 판단, 반복 가능한 평가, 구현 담당자의 변경 제안이 연결될 때 비로소 다음 변경에 재사용할 수 있는 운영 장치가 됩니다. 따라서 “응답이 별로였다”는 감상을 남기는 데서 끝내지 말고, 실패한 입력과 기대 행동, 관찰된 결과, 다시 검사할 조건을 하나의 케이스로 만들어야 합니다.
OpenAI Cookbook의 Agent Improvement Loop 예제는 이 순서를 금융 실사 분석 에이전트에 적용합니다. 공식 예제는 실제 trace에서 시작해 human/model feedback을 추가하고, feedback을 Promptfoo eval로 전환하며, HALO가 다음 harness 변경을 순위화하고 Codex용 handoff를 만드는 흐름을 설명합니다. 예제에서 말하는 harness는 모델 지시문 하나가 아니라 지시, 도구, 라우팅, 출력 형식, 검증 규칙을 묶은 전체 계약입니다.
Trace와 span을 개선의 출발점으로 쓰는 방법
OpenAI Agents SDK tracing 문서는 하나의 trace를 논리적인 워크플로 전체 기록으로 설명하고, 그 안에 여러 span을 둡니다. 문서가 예로 드는 span 범위에는 에이전트 실행, 모델 생성, 함수 도구 호출, handoff, guardrail과 사용자 정의 이벤트가 포함됩니다. 이렇게 쪼개면 최종 답변만 저장할 때 놓치기 쉬운 도구 순서, 재시도 지점, 다른 에이전트로 판단이 넘어간 시점을 비교할 수 있습니다.
운영에서 중요한 필드는 trace ID와 workflow 이름만이 아닙니다. 입력의 민감도, 사용한 도구, 시작·종료 시각, 실패 상태, 검증 결과를 나중에 평가 케이스로 읽을 수 있는 형태로 남겨야 합니다. 특히 trace는 사실 판정기가 아닙니다. 입력 데이터가 잘못됐거나 도구 결과가 불완전하면 trace도 그 불완전한 실행을 기록할 뿐입니다. 공식 문서가 민감한 입력·출력의 수집 범위를 줄이는 설정과 Zero Data Retention 환경의 제약을 함께 설명하는 이유도 여기에 있습니다.
실무에서는 모든 원문을 무제한 저장하는 대신 사건을 재현할 수 있는 최소 필드를 먼저 정합니다. 예를 들면 case_id, 입력 요약, 사용 도구, 기대 행동, 관찰 결과, 실패 분류, 개인정보 포함 여부, 다음 평가 케이스 ID를 분리합니다. 저장한 trace를 사람이 다시 읽을 수 있어야 하며, 비밀값을 제거한 뒤에도 같은 실패 조건을 재현할 수 있어야 합니다.
Feedback을 eval 케이스로 바꾸면 무엇이 달라지나
피드백을 평가로 바꾸는 핵심은 문체 선호가 아니라 행동 계약을 고정하는 것입니다. “답이 부족하다”는 문장을 그대로 평가할 수는 없습니다. 대신 “구조화된 재무 자료와 경영진 서술이 충돌할 때 전자를 우선하고 충돌을 명시한다”처럼 입력, 기대 행동, 금지할 주장, 통과 기준을 나눕니다. 사람이 반드시 지켜야 할 업무 규칙과 모델이 제안한 개선 가설도 서로 다른 출처로 기록해야 합니다.
현재 OpenAI Evals 안내는 평가를 작업 설명, 테스트 입력 실행, 결과 분석과 반복 개선의 세 단계로 설명합니다. 같은 입력 집합을 변경 전후에 다시 돌려야 개선 여부를 비교할 수 있습니다. 케이스 수가 적더라도 정상 입력과 실패 입력, 출처 충돌, 불확실성 표시처럼 위험이 다른 사례를 함께 넣어야 합니다. 평균 점수 하나만 높아졌다는 이유로 운영 적용을 결정하면 중요한 실패 사례가 묻힐 수 있습니다.
현재 문서에는 Evals 플랫폼의 전환 일정도 명시돼 있습니다. 기존 Evals 콘텐츠는 2026년 10월 31일부터 읽기 전용으로 전환되고 2026년 11월 30일 종료 예정이며, 새로 평가를 설계하거나 반복 실험을 시작하는 경우에는 Datasets를 검토하라고 안내합니다. 따라서 기존 글에 있던 “Evals API를 장기 운영 표준으로 사용한다”는 식의 표현은 현재 상태에 맞지 않습니다. API를 검토할 때는 종료 일정, 데이터 보존, 접근 권한, 대체 경로를 함께 확인해야 합니다.
직접 실행 결과: 2026년 9월 11일 로컬 검증
환경: Windows 로컬 Python harness와 Chromium 기반 브라우저. 입력: 합성 금융 실사 케이스를 가정한 trace 5개, 각 trace의 agent·tool·validation span, feedback 2건, eval 케이스 3건. 조건: 계정·네트워크·API 키 없이 trace 구조를 만들고, feedback을 평가 케이스로 연결하고, 변경 제안을 handoff 파일로 기록하는지 확인했습니다.
실행 로그는 먼저 trace 5개를 만들고, 그중 두 trace에서 사람이 확인할 문제와 모델 보조 피드백을 각각 하나씩 구조화했습니다. 이어 세 eval 케이스를 같은 입력 계약으로 평가했습니다. 개선 전 결과는 2/3 통과였습니다. 실패한 케이스는 출처 우선순위를 지키지 못하는 상황으로 지정했습니다. 그 실패에서 “구조화된 출처 우선”과 “충돌 시 불확실성 필드 필수”라는 두 변경 제안을 만들고 동일한 세 케이스를 다시 평가했습니다.
브라우저 화면에서도 같은 순서가 보이는지 확인했습니다. 실행 버튼을 누르면 trace 5/5, feedback 2건, baseline 2/3 실패, improved 3/3 통과, Codex handoff의 세 구현 항목이 순서대로 표시됩니다. 이 화면은 제품 대시보드의 trace를 캡처한 것이 아니라, 실행 로그의 값을 보여주는 로컬 검증 UI입니다.
로컬 실행 로그의 핵심 결과는 baseline 2/3 → improved 3/3입니다. 이 숫자는 모델 정확도 점수가 아니라, 정해 둔 세 가지 계약 케이스에 대한 결정적 로컬 게이트 결과입니다. 영상의 화면 변화는 버튼 클릭, 진행 막대, 카드의 값 변경, 완료 상태를 포함하며 정지 이미지를 이어 붙인 파일이 아닙니다.
Codex handoff를 변경 승인 경계로 두기
개선 루프의 마지막 출력은 “프롬프트를 바꿔보자”가 아니라 구현 가능한 handoff여야 합니다. 이번 로컬 실행은 실패 근거가 된 trace ID와 eval 케이스 ID, 그리고 세 가지 변경 항목을 별도 Markdown 파일로 남겼습니다. 첫째 구조화된 출처 우선 규칙을 harness 계약에 넣고, 둘째 출처가 충돌할 때 불확실성 필드를 요구하고, 셋째 변경을 받아들이기 전에 같은 eval 집합을 다시 실행하는 내용입니다.
handoff는 자동 병합 명령이 아닙니다. 변경 범위, 예상 영향, 실패 조건, 되돌리는 방법을 함께 검수할 수 있는 경계입니다. 공식 Cookbook도 trace와 feedback을 Codex가 구현할 수 있는 변경 세트로 전환하는 reviewed loop를 일반적인 시작점으로 설명합니다. 운영 파이프라인에서는 Codex가 제안한 diff를 먼저 사람이 보고, 동일한 eval gate와 보안 검사를 통과한 뒤에만 반영해야 합니다.
실패 조건과 안전한 중단 기준
첫 번째 중단 조건은 trace와 eval의 입력이 서로 달라지는 경우입니다. 변경 전후 케이스가 바뀌면 점수 차이를 개선 효과로 해석할 수 없습니다. 두 번째는 feedback이 기대 행동이나 실패 조건 없이 문장 감상으로만 남는 경우입니다. 세 번째는 trace 안에 API 키, 쿠키, 고객 자료 같은 민감정보가 들어간 경우입니다. 이때는 캡처와 로그를 보관하지 말고 안전한 데이터로 세션을 다시 시작해야 합니다.
네 번째는 동일 실패가 반복되는데도 점수만 조정하는 경우입니다. 평가기가 문제를 놓치고 있을 수 있으므로 평가 케이스와 grader 자체를 먼저 검토합니다. 다섯 번째는 공식 문서의 기능 상태가 바뀐 경우입니다. 이번처럼 Evals의 수명 주기나 대체 경로가 바뀌면 예전 운영 권고를 그대로 유지하지 말고 날짜와 범위를 본문에 다시 적습니다.
이번 검증의 범위와 한계
이번 검증에서 확인한 것은 현재 공식 문서가 설명하는 trace·feedback·eval·handoff 구조와 계정 없는 로컬 harness의 데이터 흐름입니다. 확인하지 않은 것은 실제 OpenAI 모델의 답변 품질, Agents SDK의 서버 trace export, Promptfoo·HALO의 라이브 실행, 조직별 Evals 접근 권한과 비용입니다. 라이브 Cookbook 예제는 API 키와 패키지 설치가 필요하므로, 이 실행 결과를 실제 모델 성능이나 서버 기능의 증거로 해석하면 안 됩니다.
도입 전에는 실제 업무 자료를 비식별화하고, 정상·실패 케이스를 같은 버전으로 고정한 뒤, trace 저장 범위와 보존 기간을 정해야 합니다. 평가 결과가 좋아져도 사람이 확인해야 하는 위험 영역을 자동으로 없애지는 않습니다. 특히 금융·법률·보안처럼 출처 충돌 비용이 큰 업무에서는 모델의 최종 문장보다 입력·도구·검증 기록과 사람 승인 이력을 먼저 봐야 합니다.