Codex Day 16 상세 분석: 12시간 프롬프트 캐시와 Work의 장기 재사용, 요금/구현/손익분기점

OpenAI 및 Codex의 28일 업데이트 내용을 매일, 일차 정보에 기반하여 자세히 설명하고 있습니다. Day 17 이후의 신규 기능이나 리셋 사항을 놓치고 싶지 않으신 분들은 꼭 팔로우해 주세요.

2026년 10월 20일(미국 시간), OpenAI의 28일 업데이트 Day 16이 공개되었습니다. 이번 발표는 크게 API의 12시간 프롬프트 캐시와, Codex / ChatGPT Work에서 과거 대화를 재개할 때의 장기 캐시 재사용 두 가지로 나뉩니다.

Tibo Sottiaux 씨는 API에서 12시간 동안 캐시를 선택할 수 있게 되었으며, 로그인된 Codex / Work 사용자에게는 과거 대화를 몇 시간 후에 다시 시작해도 캐시가 히트하여 재처리로 인한 페널티가 사라진다고 안내했습니다.

또한 OpenAI API 공식 변경 이력에도 2026년 10월 20일자로 Responses API의 12시간 캐시 대응이 게재되었습니다.

다만, API의 캐시 히트가 모든 요청에서 보장되는 것은 아닙니다. 또한, API에서는 12시간 동안 쓰기(write) 비용이 일반 입력 대비 2.5배로 설정되어 있습니다.

본 기사에서는 KV 캐시의 메커니즘, API 설정 및 구현, 캐시의 최소 유지 기간, 요금의 손익분기점, 측정 방법, 긴 대화에서의 동작 방식, 데이터 보호 주의사항, Day 12와의 차이점을 상세히 설명합니다.

조사 시점: 2026년 10월 21일(한국 시간). 공식 공지/API 변경 이력/Prompt caching 가이드/요금표를 대조했습니다. Codex / Work 내부의 캐시 저장 방식, 삭제 정책, 모델이나 플랜별 효과 측정값은 공개되지 않았습니다. '영구'를 무기한 GPU 메모리 점유나 삭제 불가능과 동일시하지 마십시오.

1. Day 16 변경점 비교

같은 '캐시'라는 단어라도, API의 명시적인 TTL(Time To Live) 설정과 Codex / Work가 내부적으로 수행하는 재사용은 별개의 서비스 사양입니다.

2. 애초에 프롬프트 캐시란 무엇인가?

LLM은 긴 입력을 매번 처리한다

대규모 언어 모델(LLM)은 입력을 **토큰(token)**이라는 단위로 나누고, 각 토큰을 처리하여 답변을 생성합니다.

예를 들어, Java 백엔드 개발에서 다음과 같은 공통 정보를 매번 입력한다고 가정해 봅시다.

• 프로젝트의 공통 규칙
• API와 DB의 사양
• 리포지토리 파일 구성
• 과거 대화 이력
• 활용 가능한 도구 정의

이러한 내용이 변하지 않는다면, 같은 부분을 반복 계산하는 것은 낭비가 될 수 있습니다.

여기서 사용하는 것이 **Prompt caching (프롬프트 캐시)**입니다.

KV캐시란 무엇인가?

OpenAI의 공식 문서에서는 모델이 입력을 처리할 때의 중간 상태를 Key-Value (KV) 상태라고 설명합니다.

이를 재사용 가능한 형태로 유지함으로써, 후속 요청에서는 같은 입력 부분을 다시 처리해야 하는 비용을 줄일 수 있습니다.

1회차
[ 공통 지시 ][ 도구 정의 ][ 긴 사양서 ][ 질문 A ]
↓
...

**prefix(프리픽스)**란, 입력의 처음부터 연속적으로 일치하는 부분을 말합니다.

도중에 바뀐 지시나 날짜가 들어가면, 그 이후의 prefix가 일치하지 않아 재사용할 수 있는 범위가 짧아질 수 있습니다.

캐시하는 것은 과거의 답변 자체가 아니라 재사용 가능한 모델의 중간 계산 상태입니다. 같은 질문을 보내더라도 답변이 고정되는 것은 아닙니다.

3. Responses API의 12시간 캐시: 설정은 하나

이전에는 보통 30분, 이번에는 12시간 선택 가능

GPT-5.6 이후 대응 모델에서는 Responses API의 기본 최소 유지 기간(minimum retention period)은 30분입니다.

Day 16부터는 12시간을 선택할 수 있게 되었습니다.

여기서 중요한 포인트가 세 가지 있습니다.

① 12시간은 '최소 유지 기간'입니다
반드시 정확히 12시간 후에 파기된다는 의미는 아닙니다. OpenAI가 그 이상 보관할 수도 있습니다.

② 2.5배는 추가 과금이 아니라 쓰기 자체의 단가입니다
일반 입력 요금의 1배에 2.5배를 가산하여 3.5배가 되는 것이 아닙니다.

③ 유지 기간이 길다고 해서 반드시 히트(hit)하는 것은 아닙니다
캐시가 사용 가능하더라도, 공통 접두사(common prefix)가 바뀌거나 모델의 조건이 바뀌면 히트하지 않을 수 있습니다.

4. Responses API 구현 예시

최소 구성 (JSON)

Day 16의 12시간 캐시를 사용하기 위한 주요 설정은 다음과 같습니다.

{
"model": "gpt-6.1-sol",
"prompt_cache_options": {
...
}

이 짧은 샘플을 그대로 보내도 캐시 대상이 될 것이라고 보장할 수 없습니다. GPT-5.6 이후에서는 캐시 가능한 접두사(prefix)가 최소 1,024 토큰 필요합니다. 실제로는 긴 공통 사양이나 툴 정의 등을 전달하는 상황에서 효과를 볼 수 있습니다.

JavaScript (Node.js) 호출 예시

Node.js 18 이상에 내장된 fetch를 사용하는 예시입니다.

const apiKey = process.env.OPENAI_API_KEY;
if (!apiKey) {
throw new Error("OPENAI_API_KEY를 설정해 주세요");
...

이 예시에서는 매번 내용이 바뀌는 질문을 마지막에 배치하고, 동일한 sharedSpec을 계속 사용하려는 의도를 담고 있습니다.

운영 환경에서는 인증 정보를 코드에 직접 작성하지 말고, 입력 길이와 비용을 측정해야 합니다.

또한, ttl(Time-to-Live)이 설정 가능한 것은 Responses API를 지원하는 모델입니다. 모든 구형 모델이나 Chat Completions API에 그대로 적용될 수 있는 것은 아닙니다.

실제로 캐시되었는지 확인하는 방법

응답의 usage에서 캐시 관련 정보를 확인할 수 있습니다.

{
"usage": {
"input_tokens": 12000,
...
}

위 수치는 공식 가이드의 요금 계산을 설명하는 예시일 뿐, 실제 실행 결과의 측정값은 아닙니다.

cached_tokens: 캐시에서 읽어와 과금된 입력 토큰 -
cache_write_tokens: 새로 작성한 토큰 수 -
ttl_30m_tokens: 30분 쓰기로 청구된 토큰 -
ttl_12h_tokens: 12시간 쓰기로 청구된 토큰

일반 입력 토큰 수는 input_tokens - cached_tokens - cache_write_tokens으로 계산할 수 있습니다. 내역 중 12h/30m 쓰기를 합산한 후, cache_write_tokens를 다시 더하지 않도록 주의해야 합니다.

5. 12시간 캐시는 정말 저렴할까? 손익분기점

12시간 캐시는 장기간 보관이 가능하지만, 최초 쓰기 비용이 높기 때문에 사용 방식에 따라 비쌀 수 있습니다.

예를 들어, GPT-6.1 Sol의 캐시 읽기 요금은 일반 입력의 0.05배입니다.

여기서는 동일한 긴 prefix를 완전히 재사용한다는 단순화된 가정 하에 상대 비용을 계산합니다. 요금은 입력 부분만을 기준으로 하며, 답변 출력 비용은 포함하지 않습니다.

2시간마다 공통 prefix를 사용할 경우

09:00 공통 사양 로드
11:00 동일한 사양으로 질문
13:00 동일한 사양으로 질문
...

2시간 간격이므로, 기본 30분 캐시는 매번 만료된다고 가정합니다.

세부 내역은 다음과 같습니다.

12시간 캐시:
최초 쓰기 2.50
2차 읽기 0.05
...

2.65라는 값은 공식적인 실측값이 아니며, 요금 배율을 통해 계산한 예시입니다.

실제 모델 실행에서는 prefix의 일치 범위, 새로운 질문 토큰, 출력, 중간 추가 컨텍스트, 캐시 히트 여부 등에 따라 변동됩니다.

몇 번 사용해야 12시간이 유리할까?

가정을 '30분마다 캐시가 만료되고, 그 때마다 1.25배로 재작성한다'와 '12시간 쪽은 한 번 작성한 후 모두 0.05배로 읽을 수 있다'로 단순화했을 경우,

1회 이용: 12h 쓰기 비용 2.50은, 30m 쓰기 비용 1.25보다 높음 -
2회 이용: 12h의 2.55는, 30m 쓰기 비용 2회의 2.50보다 약간 높음 -
3회 이용: 12h의 2.60은, 30m 쓰기 비용 3회의 3.75보다 낮음

이 조건에서는 3회 이상 이용 시 12시간 캐시가 유리합니다.

다만, 30분 이내에 고빈도로 사용한다면 기본 30분 캐시에서도 읽기 비용이 발생합니다. 그 경우, 12시간 보관으로 전환할 메리트는 작아질 수 있습니다.

6. 요금 설정에서 오해하기 쉬운 점

캐시 읽기도 완전 무료는 아니다

GPT-5.6 이후의 API에서는 캐시 읽기에 모델별 할인 단가가 적용됩니다.

12시간 캐시를 사용하더라도, 읽기 단가 자체는 30분 캐시와 동일합니다.

쓰기 배율은 이중 청구되지 않는다

일부 오해로는 일반 입력 1배에 추가로 캐시 쓰기 2.5배를 더하는 설명이 있지만, 공식 사양은 2.5배가 총 쓰기 단가입니다.

API의 레이트 제한(Rate Limit)은 사라지지 않는다

캐시된 입력 토큰도 **TPM (Tokens Per Minute: 분당 토큰 제한)**에는 계속 합산됩니다.

Prompt caching을 통해 API의 Rate Limit이 무제한이 되는 것은 아닙니다.

비용은 가격표와 모델에 의존한다

실제 USD 요금은 모델, Standard / Fast / Ultrafast, 입력 길이, 리전 등에 따라 달라집니다. 최신 구체적인 금액은 OpenAI 공식 API 요금표를 참조해 주십시오. 위의 표의 '2.5배', '0.05배'는 설정 비교에 사용하기 위한 배율입니다.

7. 캐시 위치를 직접 지정하기: Explicit breakpoint

Day 16의 API 사양에서는 GPT-5.6 이후 모델을 사용하여 자동(implicit) 및 명시적(explicit) 캐시 경계를 사용할 수 있습니다.

Implicit: 자동으로 prefix의 종단을 결정

{
"model": "gpt-6.1-sol",
"prompt_cache_options": {
...
}

이 방식에서는 모델 측에서 캐시 가능한 메시지 경계에 대해 자동으로 후보를 결정합니다.

Explicit: 길게 사용할 부분만 12시간으로 지정

공통 프로젝트 사양은 12시간, 세션 고유 정보는 30분으로 유지하고 싶을 때가 있습니다.

{
"model": "gpt-6.1-sol",
"prompt_cache_options": {
...
}

이 예시의 의도는 다음과 같습니다:

• 첫 번째 긴 공통 사양은 12시간 유지하고,
• 세션 고유 컨텍스트는 30분 유지하며,
• 마지막 매번 바뀌는 질문에는 불필요한 캐시 쓰기를 수행하지 않는 것입니다.

다만 브레이크포인트(breakpoint)는 직전 입력뿐 아니라 해당 위치까지의 전체 접두사(prefix)를 대상으로 합니다. 또한, 나중에 긴 TTL을 가진 쓰기가 이전의 짧은 TTL을 덮어쓰는 경우, 과금 방식에 영향을 미칩니다.

30분짜리 기존 캐시를 12시간으로 업데이트한다고 해서 이전에 지불했던 쓰기 비용이 차감되지는 않습니다. 공식 가이드에는 TTL 혼재 시의 과금 예시가 게재되어 있습니다.

8. Codex / Work의 '만료 없는 캐시'는 무엇을 의미하는가?

Tibo 씨의 Day 16 게시물에서는 로그인된 Codex / Work 사용자에게 과거 대화를 재개해도 캐시가 히트할 것이 보장된다고 명확히 밝히고 있습니다.

예를 들어,

09:00 기존 Java 백엔드 조사 시작
↓
긴 코드나 테스트 결과를 읽음
...

여기서는 긴 기존 컨텍스트(context)를 다룰수록, 처음부터 계산을 다시 해야 하는 낭비를 줄일 수 있다는 기대가 있습니다.

Day 16의 '캐시 히트 보장(guaranteed to hit the cache)'은 이 스레드 복귀 시점의 제품 경험에 대해 언급한 것입니다.

'영구적'이라는 것이 GPU 메모리의 영구 점유를 의미하는가?

내부 구현 방식은 공개되지 않았습니다.

따라서, 예를 들어,

• 모든 대화의 KV 텐서(KV tensor)를 영원히 GPU에 배치한다.
• 대화를 삭제해도 캐시가 계속 남아있다.
• 몇 년 후에도 오래된 스레드가 동일한 모델과 동일한 컨텍스트로 이용 가능하다.
• 모든 모델 및 모든 클라이언트에서 동일한 보장이 적용된다.

와 같은 주장은 Day 16의 짧은 발표만으로는 도출할 수 없습니다.

'만료 없음(期限なく)'이라는 것은, 사용자가 과거 대화로 돌아갈 때 캐시 만료로 인한 이용상의 페널티를 피할 수 있도록 서비스 측에서 제공하는 보장으로 이해하는 것이 적절합니다.

컨텍스트 창이 무한대가 되는 것은 아니다

컨텍스트 창(Context Window)은 모델이 단일 처리 과정에서 다룰 수 있는 정보량의 상한선입니다. 이는 캐시 유지 기간과는 별개의 개념입니다.

Day 7: GPT-6.1 Sol의 표준 컨텍스트 용량을 272K에서 500K로 확대 -
Day 12: 서브 에이전트 간의 컨텍스트 재사용 및 라우팅 개선 -
Day 16: 시간이 지나도 동일한 대화의 컨텍스트 캐시를 사용하기 쉽게 함

Day 16에서 컨텍스트 창이 무한대가 된 것은 아닙니다.

AI가 과거의 모든 것을 반드시 기억한다는 의미인가?

이 또한 아닙니다.

프롬프트 캐시는 처리 효율을 높이는 기능입니다. 사용자의 장기 기억, 대화 검색, 과거 로그 저장, 정보의 정확한 회상과 같은 것과는 다릅니다.

9. API의 '보장되지 않음'과 Codex의 '보장'이 공존하는 이유

API 공식 Prompt caching 가이드에는 다음 취지의 주의사항이 있습니다.

캐시 유지 설정은 재사용 기회를 제공하지만, 개별 API 요청의 캐시 히트나 낮은 지연 시간을 무조건적으로 보장하는 것은 아니다.

반면, Day 16의 Codex / Work용 발표는 오래된 대화로 돌아갈 때의 캐시 재사용을 제품 경험으로서 보장한다고 언급하고 있습니다.

이는 모순이 아닙니다. API의 일반적인 계약과 Codex / Work의 내부 서비스 동작에 대해 대상 범위가 다르기 때문입니다.

prompt_cache_retention

과의 차이점

10. 구형 모델의 API를 이미 사용하고 있다면, 이전부터 prompt_cache_retention라는 파라미터를 사용했을 수 있습니다.

하지만 GPT-5.6 이후의 새로운 메커니즘은 다음과 같이 변경되었습니다.

항목별 비교

이전부터 구 모델용으로 **최대 24시간의 확장 유지 기간(extended retention)**이 존재했던 경우도 있었습니다.

따라서, "OpenAI API에서 장시간 캐싱이 처음 가능해졌다"는 설명은 오류입니다. 이번에 새로 추가된 것은 GPT-5.6 이후 Responses API를 위해 **과금 및 유지 시간을 명시하여 선택할 수 있는 12시간 TTL(Time-To-Live)**이라는 점입니다.

설정 값인 "12h"을 구 모델의 prompt_cache_retention에 그대로 전달할 수는 없습니다.

11. 보안 및 데이터 유지 시 주의사항

12시간은 삭제 기한이 아니다

ttl: "12h"는 최소 유지 기간일 뿐이며, 데이터 삭제 기한이나 로그 보존 정책을 변경하는 설정이 아닙니다.

컴플라이언스 상 "반드시 12시간 이내에 캐시를 삭제해야 한다"는 경우, 이번 TTL을 삭제 보장으로 사용할 수 없습니다.

Zero Data Retention (ZDR)도 확인

OpenAI API에는 조직별 데이터 유지 설정이 있습니다.

캐시는 암호화된 KV 상태가 일시적으로 GPU 근처의 저장 영역 등에 유지될 수 있으며, 대상 모델이나 조직의 데이터 유지 조건에 따라 선택 가능한 캐싱 방식이 다릅니다.

특히 ZDR을 이용하는 경우에는 사용 가능한 유지 모드와 조직의 계약 조건을 최신 공식 자료로 대조해야 합니다.

"12시간 캐시를 활성화하면 모든 기업의 보존 정책을 반드시 충족할 수 있다"고 말할 수 없습니다.

고객 간에 캐싱해도 괜찮을까?

고객별 권한 경계를 유지하는 것이 최우선입니다.

공통 prefix라 하더라도, 타사의 기밀 정보나 권한이 다른 정보를 의도치 않게 섞지 않도록 주의해야 합니다.

신규 방식에서는 prompt_cache_key가 선택 사항이며, 고객/사용자/워크스페이스 단위의 캐시 회계를 분리하는 목적으로 사용할 수 있습니다. 다만, 이 키만을 접근 제어의 대용품으로 사용해서는 안 됩니다.

12. 실제 운영에서 효율을 측정하는 방법

Day 16의 이점이 있는지 여부는 캐시 적중률(cache hit rate)・쓰기 비용・응답 시간을 종합적으로 측정해야 합니다.

예를 들어, 동일한 API 설계 자료를 사용하는 작업을 짧은 간격과 긴 간격으로 비교해 볼 수 있습니다.

group A: 30분 TTL
- 같은 긴 prefix
- 10분 후와 몇 시간 후에 재사용
...

시간이 지나도 캐시가 사용 가능하다는 것이 항상 가장 저렴하고 빠르다는 것을 의미하지 않습니다.

모델, 입력, 출력 길이를 맞추고 여러 번 측정하는 것이 중요합니다.

JavaScript로 입력 비용을 계산하는 예시

function inputCostUSD(usage, inputPricePerMillion, cachedReadMultiplier = 0.1) {
const d = usage.input_tokens_details;
const readTokens = d.cached_tokens ?? 0;
// ... (생략)
}

이 계산식은 GPT-5.6 이후 양쪽 TTL(Time-To-Live) 내역이 있는 응답을 대상입니다. 실제로는 모델의 입력 요금, 사용 모드, 리전, 출력 요금 등도 더해 총액을 평가해야 합니다.

13. 자주 묻는 질문 (FAQ)

Q. Day 16은 완전 초기화(full reset)였나요?

아닙니다. 2026년 10월 21일자 공식 Day 16은 캐시 개선 발표였으며, 추가적인 전체 초기화는 확인되지 않았습니다. 전날인 Day 15에는 라이브 스트리밍 이후에 추가 리셋이 발표되었습니다.

Q. API의 캐시는 영구적으로 되나요?

아닙니다. API에서는 Responses API를 통해 최소 12시간의 보존 기간을 선택할 수 있는 사양입니다. Codex/Work용 '기한 없음'이라는 표현과 혼동하지 마십시오.

Q. GPT-6.1 Sol의 12시간 캐시 요금은 비싼가요?

최초 작성 시에는 일반 입력의 2.5배이지만, 동일한 prefix를 재사용할 때는 0.05배입니다. 오랜 간격을 두고 여러 번 사용하는 경우에 유리해질 가능성이 있습니다.

Q. 12시간 후에 캐시가 사라지나요?

반드시 사라지는 것은 아닙니다. 12시간은 최소 보존 기간입니다.

Q. 5분 후나 30분 후에도 12시간을 지정해야 하나요?

필수 사항은 아닙니다. 고빈도의 연속 사용의 경우 기본값인 30분 TTL(Time To Live)이 작성 요금이 더 저렴할 수 있습니다.

Q. Codex에서 과거 스레드로 돌아가면 사용량이 무료가 되나요?

무료가 된다는 발표는 아닙니다. 이는 재처리 낭비나 캐시 만료 페널티를 피하기 위한 개선이며, 작업의 새로운 처리나 출력 이용량은 계속해서 요금이 발생할 수 있습니다.

Q. 캐시가 영구적이라면 몇 년 전의 대화도 완벽하게 기억하나요?

모델이 무한한 컨텍스트(Context)를 이해할 수는 없습니다. 캐시, 대화 기록 저장, 장기 기억(Long-term memory), 컨텍스트 상한을 구분하여 생각해야 합니다.

Day 1~16: 최근 변경 사항과의 관계

Day 12는 캐시 효율성 개선에 관한 것이고, Day 16은 시간이 지난 후의 재사용과 API의 보존 기간을 다루는 변경점이라는 차이가 있습니다.

요약

Day 16의 핵심은 **'오랜 간격을 두고 다시 시작하는 작업에서도 공통 컨텍스트를 효율적으로 처리할 수 있다'**는 것입니다.

API에서는 Responses API에 prompt_cache_options.ttl: "12h"
이 추가되었으며, 12시간은 최소 보존 기간일 뿐 삭제 기한이 아닙니다. GPT-5.6 이후 대응 모델에서는 30분 작성 시 1.25배, 12시간 작성 시 2.5배의 요금이 부과됩니다. 캐시 읽기는 많은 모델에서 0.1배, GPT-6.1 Sol에서는 0.05배입니다. 같은 prefix를 오랜 간격으로 재사용할수록 12시간이 유리해질 가능성이 있습니다. API 요청의 캐시 히트(Cache hit)는 무조건 보장되지 않습니다. 로그인된 Codex/Work에서는 과거 스레드 재개 시 캐시 히트를 공식적으로 보장합니다. Codex의 장기 캐시는 API의 12시간 설정이나 모델의 무한 기억과는 다릅니다. Day 16에 추가된 전체 리셋은 공식 트래커(official tracker)에 기록되어 있지 않습니다.

긴 사양서, 레포지토리 조사, 여러 에이전트의 병렬 작업, 몇 시간 중단하는 작업 등에서는 캐시를 재사용할 수 있는지 여부가 속도와 실질 이용량에 영향을 줍니다.

API를 사용할 경우에는 먼저 30m과 12h 두 경우 모두에서 cached_tokens와 실제 청구액을 비교하는 것이 확실합니다.

참고 자료・일차 정보

• OpenAI Developer Community: 28 days of Shipping at OpenAI (Day 16)
• Tibo Sottiaux 씨: Day 16의 Codex/Work 캐시 개선
• OpenAI Developers: API의 12시간 캐시에 관한 공식 게시물
• OpenAI API: Changelog (2026년 10월 20일)
• OpenAI API: Prompt caching 가이드 (TTL・breakpoint・과금・usage)
• OpenAI API: 모델별 캐시 요금표

Day 17 이후에도 OpenAI/Codex의 28일간 업데이트와 추가 리셋을 매일 조사하여 기사로 정리해 배포하겠습니다. 향후 업데이트를 추적하고 싶으신 분은 꼭 팔로우해 주십시오.

Discussion