[OpenAI][Responses API] compaction item을 언제 켜야 하는지 토큰 기준으로 정리하기

IT 리서치 노트

[OpenAI][Responses API] compaction item을 언제 켜야 하는지 토큰 기준으로 정리하기

Responses API 세션이 길어지면 언젠가 context가 비싸지고 느려진다. 2026년 6월 29일 기준 OpenAI 공식 compaction 가이드를 다시 보면, server-side compaction과 standalone compact endpoint는 둘 다 장기 대화의 토큰 길이와 지연 시간을 줄이기 위한 도구지만 켜는 기준은 다르다. 이 글은 compaction을 '나중에 필요하면 켠다'가 아니라 어떤 토큰 지점과 어떤 운영 조건에서 검토해야 하는지 정리한 것이다.

목차

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

1. 개요

결론부터 말하면 compaction은 대화가 길어졌다는 감각으로 켜기보다 rendered token count, tail latency, replay 부담이 같이 커질 때 검토하는 편이 맞다. OpenAI 가이드도 compaction을 품질과 비용과 지연 시간의 균형 도구로 설명한다. previous_response_id를 쓰는 경로에서는 server-side compaction을, stateless replay를 쓰는 경로에서는 standalone compact endpoint를 우선 검토하면 된다.

또 compaction item은 사람이 읽는 요약 로그가 아니다. 문서는 이 item이 다음 창에서 필요한 prior state와 reasoning을 적은 토큰으로 carry forward하는 opaque item이라고 설명한다. 따라서 사람이 해석할 설명 데이터처럼 저장하거나 변형하면 안 된다.

이미 previous_response_id와 stateless replay 글을 봤다면, 이번 글은 그 다음 단계인 장기 세션 운영 기준이다. 또 store: false와 encrypted reasoning 글은 ZDR 경로라면, 이번 글은 그 위에 compaction을 어디서 넣을지의 문제다. compact 결과를 받은 뒤 retained items를 어느 범위까지 next-turn window에 살려야 하는지가 바로 다음 고민이라면 compact 결과에서 retained items를 어디까지 보존해야 하나를 이어서 보는 편이 좋다.

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

실무에서는 세 가지 오해가 반복된다. 첫째, previous_response_id를 쓰니 긴 세션도 자동으로 알아서 가벼워질 것이라고 생각한다. 둘째, stateless replay를 쓰면서 input array가 계속 커져도 그냥 출력 item을 더 붙이면 된다고 본다. 셋째, compaction item을 사람이 읽는 요약처럼 저장하고, 최신 compaction item 이전의 어떤 item을 버려도 되는지 기준 없이 정리한다.

하지만 compaction 가이드는 previous_response_id 경로와 stateless input-array chaining 경로를 분리해 설명한다. server-side compaction은 설정한 threshold를 넘을 때 서버가 compaction pass를 돌리고, stateless 경로는 standalone compact endpoint로 compacted window를 직접 받아 다음 창을 이어 간다. 즉 경로에 따라 compaction을 거는 위치와 책임이 다르다.

또 conversation state 가이드는 previous_response_id를 써도 이전 입력 토큰은 과금 기준으로 여전히 input tokens로 계산된다고 설명한다. 그래서 compaction은 무조건 비용을 없애는 스위치가 아니라, 긴 세션의 요청 크기와 long-tail latency를 줄이는 운영 도구로 이해하는 편이 맞다.

• 증상: 세션이 길어질수록 응답 지연이 커진다.
• 실패: previous_response_id면 context 길이 문제도 자동 해결된다고 본다.
• 막힘: stateless replay에서 input array가 계속 불어나는데 trimming 기준이 없다.
• 누락: compaction item을 opaque 상태 조각이 아니라 사람이 읽는 요약으로 취급한다.

증상	먼저 볼 곳	판단 기준
지연이 세션 후반에서 튄다	rendered token count, p95 latency	threshold 기준 compaction 도입을 검토한다
ZDR를 유지해야 한다	store=false와 replay 구조	standalone compact endpoint가 더 맞는지 본다
item을 정리하다 품질이 흔들린다	latest compaction item 보존 여부	최신 compaction item 이전과 이후를 구분해 본다

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

실무에서는 다섯 단계로 가져가면 된다. 먼저 rendered input tokens와 p95 latency를 턴별로 기록하고, 세션 후반 값이 어디서 뛰는지 바로 확인한다. 두 번째로 상태 관리 경로가 previous_response_id인지 stateless replay인지 나눈다. 세 번째로 ZDR나 외부 저장 규칙 때문에 store=false가 필요한지 확인한다. 네 번째로 threshold를 하나 정해 compaction 전후 지연 변화를 비교하고, 같은 세션 길이에서 replay 부담이 줄었는지 같이 본다. 마지막으로 compaction item이 생긴 이후 어떤 item을 계속 들고 갈지 규칙을 남긴다.

1. rendered input tokens와 p95 latency를 세션 후반까지 기록한다.
2. previous_response_id 경로면 server-side compaction부터 검토한다.
3. stateless replay와 ZDR 요구가 있으면 standalone compact endpoint를 검토한다.
4. threshold를 정하고 compaction 전후 latency 변화를 비교한다.
5. latest compaction item 보존 규칙과 trimming 기준을 문서화한다.

운영 메모에는 최소한 기록, 확인, 비교, 검증 네 가지 동작이 남아야 한다. 예를 들어 토큰 수를 기록하고, 상태 경로를 확인하고, compaction 전후 지연을 비교하고, latest compaction item 기준으로 trimming이 맞는지 검증해야 다음 배치에서도 같은 기준을 재사용할 수 있다.

threshold 숫자는 모델과 세션 구조에 따라 다르지만, 중요한 것은 같은 숫자를 팀이 공유하는 것이다. 문서 예시처럼 context_management의 compact_threshold를 명시하면 어느 세션에서 서버가 compact pass를 돌렸는지 비교가 쉬워진다. 그다음에는 지연 시간과 세션 길이를 보고 threshold를 조정한다.

운영 메모 예시

state_mode=server_side_compaction
compact_threshold=200000
store=false
latest_compaction_item_seen=true
rendered_input_tokens=228940
p95_latency_ms=2560
trim_rule=drop items before latest compaction item

또 stateless 경로에서는 compacted window에 compaction item만 들어오는 것이 아니라 retained items도 같이 올 수 있다는 점을 기억해야 한다. 그래서 compact endpoint 결과를 받았다고 무조건 앞뒤 item을 다 버리는 식으로 처리하면 안 된다.

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

첫 화면은 OpenAI compaction 가이드의 server-side compaction 구간이다. 여기서는 장기 대화에서 context를 줄이되 품질과 지연 시간을 같이 보라는 문서의 기본 방향을 먼저 확인한다.

OpenAI compaction 가이드는 장기 대화에서 server-side compaction으로 context를 줄일 수 있다고 설명한다.

이 문장을 기준으로 보면 compaction은 단순 요약 기능이 아니라 긴 세션 운영용 상태 관리 도구다. 따라서 켜는 기준도 감상적인 품질 문제가 아니라 토큰 길이, 지연 시간, replay 부담으로 잡는 편이 맞다.

두 번째 자료는 같은 문서의 ZDR note다. 여기서는 store를 끈 상태에서도 server-side compaction이 가능한 조건을 직접 적고 있다.

compaction 가이드는 store=false일 때 server-side compaction이 ZDR-friendly한 경로가 될 수 있다고 설명한다.

즉 compaction은 반드시 OpenAI 쪽 상태 보존을 길게 허용해야만 쓸 수 있는 기능으로 보면 안 된다. ZDR 요구가 있어도 어떤 경로를 택할지 다시 나눠 볼 수 있다.

세 번째 화면은 standalone compact endpoint 구간이다. 이 경로는 수동 replay를 쓰는 팀이 직접 compacted window를 받아 다음 창으로 이어 가는 흐름을 설명한다.

OpenAI는 standalone compact endpoint를 stateless long-running workflow용 경로로 따로 제공한다.

여기서 중요한 것은 compaction이 previous_response_id 전용 기능이 아니라는 점이다. stateless input array를 직접 다루는 팀도 compact endpoint를 통해 다음 창의 토큰 압박을 줄일 수 있다.

코드 기준으로는 어느 시점부터 compaction을 켤지 기준이 있어야 한다. threshold를 숫자로 남기지 않으면 팀마다 '길다'의 기준이 달라져 같은 세션을 서로 다르게 다루게 된다.

Responses create 요청에서 context_management와 compact_threshold를 설정하는 예시다.

이미 previous_response_id와 stateless replay 글을 읽었다면, 이번 글은 그 뒤에서 언제 compaction까지 넣을지 결정하는 단계다.

다섯 번째 자료는 운영 로그 예시다. compaction을 켜는 시점은 감으로 잡기보다 rendered token count와 다음 턴 지연 시간을 같이 남겨 두는 편이 빠르다.

rendered token count와 compaction 전후 지연 시간을 함께 남기는 로그 예시다.

이렇게 남기면 compaction을 켜기 전후 어느 세션 길이에서 tail latency가 커졌는지 비교하기 쉽다. 또 reasoning summary와 usage 글과 같이 보면 비용 로그와도 이어 붙이기 좋다.

마지막 자료는 켜는 기준표다. 팀마다 모델과 세션 길이가 다르더라도 어떤 숫자와 어떤 운영 조건을 같이 볼지는 먼저 합의해 두는 편이 좋다.

compaction을 켜기 전 체크할 운영 조건을 정리한 표다.

또 function_call_output과 call_id 검증 글과 같이 보면 stateless 경로에서 compaction을 넣을 때 item 보존 규칙을 어디까지 유지해야 하는지도 선명해진다.

5. 주의사항과 리스크

첫 번째 리스크는 compaction을 요약 기능처럼 오해하는 것이다. 두 번째 리스크는 previous_response_id를 쓰는데도 latency 관찰 없이 threshold를 너무 늦게 넣는 것이다. 세 번째 리스크는 stateless compact 결과를 받았다고 앞선 item을 무작정 지워 버리는 것이다.

운영 전에는 최소한 세 가지를 같이 남기는 편이 좋다. rendered token count, latest compaction item 유무, 턴별 p95 latency다. 이 셋이 없으면 compaction을 켰을 때 실제로 무엇이 좋아졌는지 설명하기 어렵다. 가능하면 배치 로그에서 compact pass 발생 시점, replay 길이, tail latency를 같이 확인하고 한 번 더 비교해 두는 편이 안전하다.

• compaction item은 opaque item이지 사람이 읽는 요약이 아니다.
• threshold는 감각이 아니라 token과 latency 기준으로 정한다.
• stateless compact 결과는 retained items까지 같이 확인한다.

6. 결론

Responses API에서 compaction은 '긴 대화라서 언젠가 켠다'가 아니라, token 길이와 지연 시간과 replay 부담이 커질 때 넣는 운영 도구다. previous_response_id 경로면 server-side compaction, stateless ZDR 경로면 standalone compact endpoint를 먼저 검토하고, latest compaction item을 중심으로 trimming 규칙을 잡아 두면 장기 세션 운영이 훨씬 덜 흔들린다. compact가 실제로 일어난 뒤 canonical next context window와 retained items를 어떻게 보존할지까지 이어서 보려면 retained items 보존 후속 글을 같이 참고하면 좋다.

• compaction은 token 길이와 latency 기준으로 켠다.
• server-side와 standalone compact는 상태 관리 경로에 따라 나눈다.
• latest compaction item 보존 규칙을 먼저 정한다.

7. 참고 링크

1. https://developers.openai.com/api/docs/guides/compaction
2. https://developers.openai.com/api/docs/guides/conversation-state
3. https://developers.openai.com/api/docs/guides/reasoning
4. https://developers.openai.com/api/reference/responses/compact