에이전트 PoC가 데모에서는 똑똑한데 운영 플로우에 붙이면 갑자기 헐거워진다. 같은 모델, 같은 프롬프트, 같은 tool인데 두 번째 tool call 이후 판단이 바뀐다. 대부분 모델 문제가 아니다. 첫 tool call 직전에 모델이 세운 판단 근거가 다음 요청에서 사라졌거나, 반대로 보여주면 안 되는 내부 추론이 로그와 재입력 경로에 섞인 것이다.
Reasoning replay policy는 이 지점을 다룬다. reasoning span을 “보여줄 설명”으로 보지 않는다. tool call 전후에 이어지는 실행 상태로 본다. 저장할 것, 마스킹할 것, 다시 넣을 것을 분리한다.
reasoning span은 감사 로그가 아니라 실행 상태다
OpenAI의 Responses API 문서는 이전 요청의 reasoning items를 previous_response_id 또는 output item 재전달 방식으로 넘기면 모델이 관련 reasoning items를 컨텍스트에 포함한다고 설명한다. 특히 function call 응답 이후에는 최신 function call과 이전 user message 사이의 reasoning items를 포함하라고 권고한다. 그래야 모델이 tool 결과를 받은 뒤 추론을 처음부터 다시 시작하지 않는다. (platform.openai.com)
Anthropic도 같은 방향을 다른 프로토콜로 말한다. Claude extended thinking 문서는 tool use 중 thinking block을 API에 완전하고 수정 없이 되돌려 보내야 reasoning flow와 conversation integrity가 유지된다고 적고, redacted_thinking block 역시 opaque encrypted data로 그대로 반환하라고 한다. (platform.claude.com)
운영 에이전트에서 reasoning은 출력물이 아니라 상태 전이다. 상태 전이를 잃으면 tool orchestration은 재현성을 잃는다.
재생 정책은 tool call 단위로 갈라야 한다
하나의 세션 정책으로는 부족하다. CRM 조회, 가격 계산, 승인 요청, 메일 발송은 같은 tool call이 아니다. 위험도, 개인정보, 재시도 가능성, human-in-the-loop 필요성이 다르다.
| 구간 | 보존 | 마스킹 | 재주입 |
|---|---|---|---|
| 읽기 전용 조회 | tool 선택 근거, 질의 의도 | 고객 식별자, 내부 권한 단서 | 다음 조회 조건으로 재주입 |
| 계산·분류 | 중간 판단 기준, 예외 조건 | 원문 민감 데이터 | 요약된 판단 기준만 재주입 |
| 쓰기·전송 | 승인 근거, 금지 조건 | 숨은 추론 원문, credential | 승인 직전에는 정책 요약만 재주입 |
| 실패·재시도 | 실패 원인, 대체 경로 | stack trace 내 secret | 재시도 plan으로 재주입 |
핵심은 “무조건 남긴다”가 아니다. 원본 reasoning span은 가능하면 벤더가 요구하는 서명·암호화·opaque block 형태로 보존한다. 사람이 읽는 운영 로그에는 decision summary, tool input/output hash, policy tag, approval state만 남긴다. 감사 가능성과 추론 노출은 같은 말이 아니다.
마스킹은 보안 기능이 아니라 제품 기능이다
운영팀은 종종 reasoning을 더 많이 보면 품질을 더 잘 통제한다고 믿는다. 실제 현장에서는 반대가 더 자주 나온다. 내부 추론을 사람이 읽는 로그에 풀어놓으면 프롬프트 인젝션, 개인정보 재노출, 승인 우회 설명이 함께 복제된다.
Anthropic 문서는 thinking block이 수정되면 invalid request가 날 수 있고, redacted block을 필터링해 떨어뜨리는 코드가 multi-turn protocol을 깨뜨린다고 경고한다. 이는 UI 마스킹과 API round-trip 보존을 분리하라는 뜻이다. (platform.claude.com) OpenAI API reference도 reasoning item에 encrypted content가 포함될 수 있고, tool call과 tool call output을 typed item으로 다룬다. (platform.openai.com)
따라서 AX Ops에서 replay store는 세 층으로 나눈다.
- Opaque state: 모델에 되돌려 줄 encrypted reasoning, thinking, redacted block.
- Operational trace: tool name, call_id, input schema version, output digest, latency, error class.
- Human audit: 사람이 읽는 짧은 판단 요약과 승인 사유.
이 세 층을 섞는 순간 에이전트는 디버깅하기 쉬워지는 것이 아니라 운영하기 어려워진다.
참고는 정책으로 번역돼야 한다
Reasoning replay policy는 프롬프트 템플릿이 아니다. agent harness의 저장소, 마스킹 파이프라인, tool router, approval UI, eval harness가 같은 정책을 읽어야 한다. 최근 공식 문서도 방향은 분명하다. OpenAI는 reasoning items의 재전달을 권고하고, Anthropic은 tool use 중 thinking block의 완전한 round-trip을 요구한다. MCP 최신 specification도 tool call과 tool result의 구조화된 연결을 전제로 삼는다.
참고:
- OpenAI, Reasoning best practices: https://developers.openai.com/api/docs/guides/reasoning-best-practices
- OpenAI, Responses API reference: https://platform.openai.com/docs/api-reference/responses/input-items?api-mode=responses
- Anthropic, Building with extended thinking: https://platform.claude.com/docs/en/build-with-claude/extended-thinking
- Model Context Protocol, 2025-11-25 specification: https://modelcontextprotocol.io/specification/2025-11-25/schema
다음 설계 과제는 단순하다. 각 tool call에 대해 “원본 보존, 인간용 마스킹, 모델 재주입”의 세 칸을 먼저 채워라. 그 표가 없으면 에이전트는 PoC를 벗어나지 못한다. AX LABS는 이 정책을 agent harness와 운영 지표까지 연결해 설계한다. AX Ops 방법론 →