← 블로그 AX Ops 방법론

하네스 변경은 회귀로 검증한다

golden trajectory 없이는 운영 배포가 아니다

AX LABS 2026.07.27 6분 읽기

현장에서 에이전트가 갑자기 나빠졌다는 말을 들으면, 원인은 대개 모델 하나가 아니다. 프롬프트 문장 하나, tool schema 이름 하나, MCP 서버 응답 필드 하나, retry 정책 하나가 trajectory 전체를 바꾼다. 사용자는 “답이 이상하다”고 말하지만, 운영팀이 봐야 할 것은 답변이 아니라 경로다.

OpenAI Agents SDK 문서는 agent loop, tool invocation, handoff, guardrail, tracing을 런타임의 일부로 다룬다. LangSmith도 production trace를 evaluation dataset으로 전환해 regression test로 쓰는 흐름을 공개했다. 2026년의 에이전트 운영은 모델 평가가 아니라 하네스 회귀 검증으로 이동했다. (openai.github.io)

정답 비교만으로는 에이전트 회귀를 못 잡는다

LLM 출력은 흔들린다. 그래서 최종 답변 문자열만 비교하면 잡아야 할 회귀를 놓치고, 무시해야 할 표현 차이를 실패로 본다.

에이전트 회귀 테스트의 단위는 output이 아니라 trajectory다. 어떤 tool을 어떤 순서로 불렀는지, 어떤 인자를 넣었는지, tool error 뒤에 재시도했는지, human approval을 건너뛰지 않았는지를 본다.

하네스 회귀 테스트는 “같은 답을 냈는가”가 아니라 “같은 운영 약속을 지켰는가”를 검증한다.

검증 대상	나쁜 테스트	운영 테스트
답변	문자열 exact match	핵심 조건·금지 조건 평가
tool call	호출 여부만 확인	순서, 인자, 권한, 재시도 확인
context	프롬프트 snapshot	memory·retrieval·system context 고정
장애	성공 케이스 중심	timeout, empty result, partial result 포함

golden trajectory는 성공 경로가 아니라 기준 경로다

golden trajectory는 “가장 멋진 데모”가 아니다. 운영상 받아들일 수 있는 기준 경로다. 실제 trace에서 뽑고, 사람이 검토하고, 버전으로 잠근다.

최소 단위는 네 가지다.

입력과 초기 context
기대 tool sequence와 핵심 arguments
mock된 tool response
허용 가능한 final outcome

LangChain의 2026년 자료는 문제가 된 production trace를 dataset으로 옮겨 다음 regression run에 포함시키는 방식을 설명한다. 이 원칙이 중요하다. 장애는 사후 보고서로 끝나면 비용이고, golden trajectory로 편입되면 자산이다. (langchain.com)

replay와 tool mock이 없으면 테스트가 아니라 재실행이다

에이전트 테스트를 매번 실제 SaaS, DB, 검색, 결재 API에 붙여 돌리면 결과가 흔들린다. 외부 상태가 바뀌었는지, 하네스가 깨졌는지 분리할 수 없다.

그래서 replay는 세 층으로 나눈다.

context replay: system prompt, memory, retrieved context를 고정한다.
tool replay: tool response를 fixture로 고정한다.
decision replay: tool 선택, handoff, approval 지점을 trace로 비교한다.

tool mock은 단순 stub이 아니다. 정상 응답, 빈 응답, 권한 오류, rate limit, schema drift를 모두 담아야 한다. OpenAI Agents SDK의 tracing은 LLM generation, tool call, handoff, guardrail 이벤트를 기록한다. 이런 span 구조가 있어야 replay 결과를 사람이 읽고 CI gate로 걸 수 있다. (openai.github.io)

MCP를 쓰는 조직은 더 엄격해야 한다. 2026-07-27 기준 MCP 2026-07-28 사양은 아직 release candidate이며, stateless core, extensions, Tasks, authorization hardening 같은 변화가 예고돼 있다. 하네스의 protocol adapter를 바꾸는 순간 tool 목록, cache, auth, long-running task 동작이 함께 흔들린다. (blog.modelcontextprotocol.io)

배포 게이트는 세 가지 실패를 막아야 한다

하네스 변경 PR에는 모델 품질 점수가 아니라 회귀 게이트가 붙어야 한다.

첫째, trajectory diff를 본다. 허용되지 않은 tool 순서 변경, 누락된 approval, 과도한 retry를 실패로 둔다.

둘째, mock contract를 본다. tool schema, required field, error envelope이 바뀌면 golden fixture도 함께 갱신해야 한다.

셋째, inconclusive를 인정한다. 비결정적 실행에서 한 번의 pass/fail로 판단하면 운영팀이 테스트를 믿지 않는다. 2026년 AgentAssay 논문도 비결정적 agent workflow의 regression testing에서 PASS/FAIL/INCONCLUSIVE와 trace-first offline analysis를 제안한다. (arxiv.org)

AX Ops에서 하네스 회귀 테스트는 QA 부속물이 아니다. 프롬프트, context, memory, tool orchestration, AgentOps를 하나의 변경 단위로 묶는 운영 장치다. 새 기능을 빨리 붙이는 팀보다, 망가지지 않게 바꾸는 팀이 결국 더 빨리 간다. 하네스 변경을 운영 체계로 묶는 방식은 AX Ops 방법론 →