[OpenAI][Responses API] trace를 남길 때 reasoning item 로그 범위를 어디까지 저장해야 하나

IT 리서치 노트

[OpenAI][Responses API] trace를 남길 때 reasoning item 로그 범위를 어디까지 저장해야 하나

Responses API 운영 로그를 설계할 때 가장 자주 헷갈리는 지점은 reasoning item을 trace에 어디까지 남길지다. 2026년 7월 6일 기준 OpenAI 공식 문서를 다시 보면 reasoning item은 다음 turn 품질을 위한 replay 대상이고, message만 남기도록 축약하면 필요한 항목이 빠질 수 있다. 이 글은 trace를 켰을 때 reasoning item을 active handoff 용도로 얼마만큼 잡아 두고, 운영자용 요약과 장기 감사 로그는 어디서 분리해야 하는지 정리한 것이다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 reasoning item은 사람이 읽는 trace 메모보다 replay 창구에 가깝게 다뤄야 한다. replay가 필요한 동안은 reasoning item, tool-call item, output item 또는 reasoning.encrypted_content를 끊지 말고 들고 가고, 운영자가 읽는 summary와 usage는 별도 trace로 분리하는 편이 맞다. 장기 감사 로그는 그보다 더 좁은 메타데이터만 남기는 쪽이 안전하다.

이미 retained items 글이 compact 이후 canonical window를 다뤘다면, 이번 글은 compact 이전을 포함한 trace 저장 경계선이다. 또 ZDR background mode 글은 background polling과 감사 로그 분리를 다뤘고, 오늘은 reasoning item 자체를 어느 층위에서 저장할지의 문제다.

2. 어디서 실제로 막히는가

현장에서 먼저 꼬이는 지점은 네 가지다. 첫째, trace를 사람이 읽기 쉽게 만들겠다며 response.output에서 message만 남긴다. 둘째, reasoning summary와 usage는 남기면서 실제 replay에 필요한 reasoning item이나 tool-call item을 버린다. 셋째, ZDR 요구가 있는데도 장기 trace에 raw output item을 그대로 들고 간다. 넷째, 플랫폼 기본 로그와 자체 trace를 같은 목적으로 중복 저장한다.

OpenAI 문서는 reasoning model과 function calling을 쓸 때 마지막 함수 호출 이후의 reasoning item을 다시 넘기라고 적고, TypeScript reference는 message만 필터링하면 다음 요청이 실패할 수 있다고 경고한다. 이 두 문장을 합치면 공식 문서가 직접 trace 보관 기간을 숫자로 정하지는 않아도, 최소한 replay 창구는 축약하면 안 된다는 결론은 분명하다.

또 data controls 문서는 플랫폼 쪽 abuse monitoring logs가 기본적으로 최대 30일까지 유지될 수 있다고 설명한다. 이 값이 곧바로 애플리케이션 trace 정책이 되지는 않지만, 자체 trace를 설계할 때 플랫폼 기본 로그와 같은 목적의 raw 기록을 오래 중복 보관할 이유가 줄어든다는 뜻으로 읽는 편이 맞다.

• 증상: summary와 usage는 있는데 다음 turn 재현이 안 된다.
• 실패: response.output에서 message만 남긴다.
• 막힘: operator trace와 replay payload를 같은 JSON으로 쓴다.
• 누락: ZDR 경로에서 reasoning.encrypted_content handoff를 별도 층위로 나누지 않는다.

상황	먼저 볼 곳	판단 기준
다음 turn 품질이 흔들린다	replay payload	reasoning item과 tool-call item이 빠졌는지 본다
디버깅용 설명이 부족하다	reasoning summary, usage	operator trace가 너무 얇은지 본다
장기 보관이 부담스럽다	audit scope	replay payload를 장기 감사 로그로 재사용하는지 본다

3. 실무에서 적용하는 순서

실무에서는 세 층으로 나누는 방식이 가장 덜 꼬인다. 먼저 active handoff용 replay window에는 reasoning item, tool-call item, output item 또는 encrypted handoff를 그대로 둔다. 두 번째로 operator trace에는 reasoning summary, usage, trace id, 모델명, 지연 시간처럼 사람이 읽어야 하는 값을 남긴다. 마지막으로 장기 감사 로그에는 정책상 필요한 최소 메타데이터와 해시, 상태 코드만 남긴다.

1. replay 창구를 message-only 로그와 분리한다.
2. reasoning summary와 usage를 같은 trace id로 묶는다.
3. ZDR 경로는 reasoning.encrypted_content handoff를 별도 필드로 둔다.
4. 장기 감사 로그는 raw item 대신 최소 메타데이터 중심으로 남긴다.
5. 플랫폼 기본 보관과 자체 trace 보관 목적이 겹치는지 점검한다.

여기서 중요한 점은 공식 문서가 'reasoning item을 며칠 보관하라'고 말하는 것이 아니라, round-trip이 필요한 동안은 reasoning item을 잃지 말라고 말한다는 것이다. 그래서 보관 기간은 제품의 handoff 길이와 디버깅 SLA로 정하고, 그보다 긴 보관은 summary와 usage 위주로 줄이는 쪽이 합리적이다. 이 판단은 문서 기반 해석이지만, 실제 운영 설계에서는 가장 보수적인 기준으로 작동한다.

운영 메모 예시

replay_scope=reasoning_items+tool_calls+output_items
operator_scope=summary+usage+latency+model
audit_scope=trace_id+status+policy_hash
zdr_handoff=reasoning.encrypted_content
drop_point=after_handoff_complete

이렇게 해 두면 trace가 길어질수록 replay payload는 짧게 유지하고 operator trace는 설명력을 유지할 수 있다. 반대로 장기 감사 로그까지 raw reasoning item을 통째로 들고 가기 시작하면 replay 목적과 감사 목적이 섞여 운영 통제가 어려워진다.

4. 공식 문서와 예시 화면으로 확인하기

첫 자료는 reasoning guide에서 function calling과 reasoning item을 어떻게 다시 넘기라고 쓰는지 보여 주는 구간이다. 여기서는 reasoning item이 사람이 읽는 참고 메모가 아니라 다음 turn 품질을 지키는 replay 대상이라는 점을 먼저 확인해야 한다.

OpenAI reasoning guide는 마지막 함수 호출에서 받은 reasoning items를 다시 넘기라고 안내한다.

즉 trace를 남길 때도 reasoning item을 로그용 설명과 같은 층위로 다루면 안 된다. 이미 function_call_output과 call_id 글이 replay 기본 구조를 다뤘다면, 이번 글은 그 replay 항목을 로그에 어디까지 들고 갈지의 경계선이다.

두 번째 화면은 TypeScript reference의 multi-turn 설명이다. 문서는 output에서 message만 뽑아 저장하면 필요한 reasoning item과 tool-call item이 빠질 수 있다고 경고한다.

OpenAI TypeScript reference는 output을 message만 남기도록 필터링하면 다음 요청이 실패할 수 있다고 적고 있다.

이 경고는 trace 저장 범위를 정할 때 핵심이다. 운영자가 읽기 쉬운 요약을 따로 만들 수는 있어도, replay용 기록을 message 중심으로 축약하면 다음 turn 재현성이 깨진다.

세 번째 자료는 deployment checklist다. 여기서는 reasoning item을 항상 round-trip하라고 적고, ZDR 요구가 있으면 reasoning.encrypted_content를 쓰라고 이어서 설명한다.

OpenAI deployment checklist는 reasoning items를 항상 round-trip하고, ZDR 경로에서는 reasoning.encrypted_content를 쓰라고 안내한다.

공식 문서가 애플리케이션 trace의 정확한 보관 일수를 숫자로 정해 주지는 않지만, 이 문장은 최소 경계는 분명하게 만든다. replay가 필요한 동안은 reasoning item 또는 encrypted_content handoff가 살아 있어야 하고, 사람이 읽는 장기 감사 로그는 그보다 좁게 분리하는 편이 맞다.

네 번째 화면은 OpenAI data controls 문서의 기본 보관 설명이다. 여기서는 abuse monitoring logs가 기본적으로 최대 30일까지 유지될 수 있다고 적혀 있다.

OpenAI data controls 문서는 abuse monitoring logs가 기본적으로 최대 30일까지 유지될 수 있다고 설명한다.

이 값은 곧바로 우리 애플리케이션 trace 보관 규칙이 되지는 않지만, 기본 플랫폼 로그와 별도 운영 로그를 같은 목적으로 쌓을 필요가 없다는 판단 근거는 준다. 이미 ZDR background mode 글을 읽었다면 이번 글은 background mode가 아니라 reasoning item 저장 경계를 더 좁히는 후속편이다.

trace 설계에서 가장 자주 섞이는 것은 replay 창구와 운영자용 요약과 장기 감사 로그다. 이 세 층을 같은 저장소나 같은 JSON 구조로 뭉개면 보안과 재현성 둘 다 흔들린다.

Responses 운영에서 replay window, operator trace, long-term audit을 분리해 보는 비교표다.

이 표처럼 경계를 미리 나눠 두면 reasoning item은 active handoff 용도, operator trace는 디버깅 용도, 장기 감사 로그는 최소 메타데이터 용도로 정리된다. store=true와 자체 로그 글도 같은 경계선 위에 있다.

마지막 자료는 trace 로그를 실제로 어떻게 분리해 남길지 보여 주는 예시다. 사람에게 보이는 메모와 replay payload를 한 줄로 합치지 않는 것이 핵심이다.

reasoning item trace를 로그에 남길 때 replay payload와 운영 메모를 분리한 예시다.

이런 형태면 ZDR와 non-ZDR 경로를 같은 관점으로 비교하기 쉽다. 필요한 동안만 replay payload를 들고 가고, 장기 로그는 summary와 usage 중심으로 남기면 된다.

5. 주의사항과 리스크

첫 번째 리스크는 trace 단순화를 위해 replay payload를 먼저 덜어내는 것이다. 두 번째 리스크는 반대로 감사 목적이라는 이유로 raw reasoning item을 장기 보관하는 것이다. 세 번째 리스크는 summary가 있으니 reasoning item은 버려도 된다고 오해하는 것이다. summary는 설명용이고, replay payload는 continuation용이다.

운영 전에 확인할 때는 최소한 active handoff가 끝나기 전까지 reasoning item을 잃지 않는지, operator trace가 usage와 summary를 함께 담는지, 장기 감사 로그가 raw payload를 중복 저장하지 않는지를 같이 점검하는 편이 좋다.

• replay payload는 handoff 완료 전까지 줄이지 않는다.
• operator trace는 summary와 usage를 같은 사건으로 묶는다.
• 장기 감사 로그는 정책상 필요한 최소 범위로 줄인다.

6. 결론

Responses API에서 trace를 남길 때 reasoning item은 우선 replay 창구로 보고, operator trace와 장기 감사 로그는 그 바깥으로 분리하는 편이 맞다. 공식 문서는 reasoning item을 round-trip하라고 말하고, message-only 필터링이 실패를 부를 수 있다고 경고한다. 따라서 active handoff 동안은 reasoning item 또는 encrypted handoff를 유지하고, 더 긴 보관은 summary와 usage 중심으로 좁히는 설계가 가장 덜 위험하다.

• reasoning item은 설명 메모보다 replay payload에 가깝다.
• operator trace와 장기 audit은 별도 층으로 나눈다.
• ZDR 경로는 encrypted handoff를 기준으로 저장 범위를 다시 잡는다.

7. 참고 링크

1. https://developers.openai.com/api/docs/guides/reasoning
2. https://developers.openai.com/api/reference/typescript/
3. https://developers.openai.com/api/docs/guides/deployment-checklist
4. https://developers.openai.com/api/docs/guides/your-data