오픈AI, GPT-6 프롬프트 캐싱 개선 발표

오픈AI가 9월 22일 GPT-6 계열의 프롬프트 캐싱 개선을 발표했어요. 여러 요청이 같은 앞부분을 공유할 때 이미 계산해 둔 상태를 다시 쓰는 기능인데, 이번 개선으로 기본 캐시 적중률이 올라갔고 캐시 할인이 붙는 재사용 시간 창은 30분으로 정해졌어요. 캐시 성능을 들여다보는 대시보드와 캐시가 왜 빗나갔는지 알려 주는 진단 도구도 함께 나왔어요.

배경은 몇 시간씩 도는 에이전트예요. 오픈AI에 따르면 GPT-6는 코드베이스 리팩터링이나 조사 문서·발표 자료 제작처럼 긴 작업을 몇 시간 동안 이어 가는 에이전트를 가능하게 하고, 그 에이전트를 돌리는 앱은 앞선 턴의 지시문과 도구 정의, 맥락을 그대로 싣고 API 요청을 줄줄이 보내요. 공유되는 앞부분이 캐시에 걸리면 응답이 빨라지고 캐시된 입력 토큰에는 최대 90% 할인이 붙어요. 메탈은 오픈AI가 같은 날 GPT-6 Sol과 Luna를 공개하며 캐시 할인과 새 캐싱 도구를 예고했다고 보도한 바 있으며, 이번 발표는 그 장치가 실제로 어떻게 움직이는지를 개발자 문서와 함께 풀어 놓은 후속이에요.

캐시가 저장하는 것은 글자가 아니에요. 개발자 문서에 따르면 모델은 입력 토큰을 처리하면서 키-값 상태라고 부르는 중간 계산값을 만들고, 프롬프트 캐싱은 바뀌지 않은 앞부분의 그 상태를 보관했다가 다음 요청에서 다시 써요. 오픈AI가 넣는 숨은 시스템 지시, 도구 정의와 스키마, 개발자 메시지, 대화 기록이 이 순서로 쌓이고, 앞쪽 어디 한 군데라도 바뀌면 그 뒤는 모두 새로 계산해야 해요.

규칙은 GPT-5.6부터 달라졌어요. 캐시할 수 있는 최소 길이는 눈에 보이는 입력 1,024토큰이고, 개발자가 캐시 브레이크포인트를 직접 찍는 명시적 방식이 새로 열렸어요. 조회할 때는 처음 2개와 마지막 50개의 명시적 브레이크포인트를 긴 것부터 거꾸로 훑고, 암묵적 방식에서는 여기에 최신 사용자 메시지 끝과 그 앞 최대 20개 메시지 끝이 더해져요. GPT-5.5와 GPT-5.5 Pro는 2,048토큰 간격으로 경계를 찍었고 보고되는 캐시 토큰도 128의 배수로 내림했지만, 새 방식은 정확한 경계를 그대로 보고해요.

과금 구조도 바뀌었어요. GPT-5.6 이후 모델에서 캐시를 읽을 때는 캐시하지 않은 입력 단가의 0.1배, 캐시에 쓸 때는 1.25배가 매겨지고, 캐시 수명은 마지막으로 쓰거나 재사용한 뒤 최소 30분이에요. 한 번 써 둔 앞부분을 30분 안에 다시 읽지 못하면 캐시하지 않았을 때보다 25%를 더 내는 셈이라, 적중률이 곧 비용이 돼요.

캐시가 사는 곳은 개별 머신이에요. 문서에 따르면 분당 15건이 넘는 요청이 몰리면 다른 머신으로 넘기는 오버플로 라우팅이 일어날 수 있고, 그러면 캐시를 가진 머신에 닿지 못할 수 있어요. 캐시는 조직 사이에 공유되지 않으며 지역 처리 경계를 넘어 재사용되지도 않아요.

이번에 나온 도구는 그 적중률을 눈으로 보게 해요. 프롬프트 캐싱 대시보드는 입력 가운데 캐시에서 처리된 비중을 시간 흐름에 따라 보여 주고, 입력 구성 차트로 캐시된 토큰과 그렇지 않은 토큰을 나눠 보여 줘요. 예상 밖의 미스가 나면 진단 도구로 현재 요청을 최근 응답과 비교해 모델, 도구, 설정, 입력 가운데 무엇이 달라졌는지 짚고, 영향을 받은 토큰 수를 추정할 수 있어요.

진단이 돌려주는 사유는 아홉 가지예요. 모델 변경, 캐시 키 변경, 서비스 등급 변경, 도구 변경, 출력 형식 변경, 추론 강도 변경, 답변 길이 설정 변경, 대화 압축, 입력 변경이에요. 문서 예시에서는 함수 도구 이름을 get_time에서 get_date로 바꾸기만 했는데 5,629토큰이 통째로 캐시를 놓쳤어요. 진단 기능은 추가 비용이 없고 요청 한도에도 따로 잡히지 않으며, 원문 프롬프트 대신 설정 메타데이터와 토큰 추정치, 해시만 짧은 기간 보관해 데이터 비보존 계약과도 함께 쓸 수 있어요. 한 번에 가장 먼저 분류된 사유 하나만 알려 주기 때문에, 고친 뒤 다시 비교해야 다음 원인이 보여요.

최적화 수단도 네 갈래로 정리됐어요. 명시적 브레이크포인트로 어디까지 캐시할지 고르고, GPT-6 모델에서는 요청 단위 추론 강도는 그대로 두고 configuration_update를 덧붙이는 방식으로 응답 사이에 추론 강도를 올리거나 내려도 캐시가 깨지지 않아요. 도구가 필요 없을 때는 정의를 지우는 대신 allowed_tools로 호출 가능한 도구만 좁히거나 tool_choice를 none으로 두고, 새 지시는 맥락 끝에 개발자 메시지로 덧붙여요. 사용자가 첫 질문을 하기 전에 공통 지시와 도구 정의, 참고 자료를 미리 처리해 두는 프리워밍도 들어갔어요.

메탈이 확인한 진단 문서의 사유 표에는 추론 강도 변경이 여전히 캐시 미스 사유로 올라 있어요. 추론 강도를 자유롭게 바꿀 수 있다는 발표는 요청 설정을 건드리지 않고 configuration_update를 뒤에 붙이는 새 경로에만 해당하고, 요청의 추론 강도 값 자체를 바꾸면 앞부분을 다시 계산해요.

고객 수치도 나왔어요. 마리오 로드리게스 깃허브 최고제품책임자는 "지난 몇 달 동안 OpenAI 모델에 보낸 수십억 건의 요청에서 새로 처리해야 하는 프롬프트 토큰 비중을 이전 기준보다 50% 넘게 줄였다" 라고 밝혔어요. 에이전트 브라우저를 만드는 스트로베리의 아리안 하니피 최고기술책임자는 "대시보드와 진단 도구 덕분에 캐시 적중률을 몇 %포인트 올려 비용을 20% 줄였다" 라고 말했어요. 그는 캐시가 예상치 않게 깨지면 알림을 받고 Codex 에이전트로 원인을 찾는다며, 안정된 맥락은 명시적 브레이크포인트로 캐시하고 자주 바뀌는 내용은 프롬프트 끝에 두면서 백그라운드 작업용으로 대화를 갈라 쓰는 일이 경제적으로 가능해졌다고 덧붙였어요.

에이전트 엔지니어링의 눈으로 보면 이번 발표는 할인 기능이라기보다 설계 규율이에요. 몇 시간짜리 작업에서 입력 대부분은 이미 한 번 계산한 앞부분이고, 그 앞부분을 지키느냐 깨느냐가 지연 시간과 청구서를 함께 결정해요. 지시문 맨 위에 타임스탬프를 넣거나 도구 순서를 바꾸는 사소한 습관이 수천 토큰을 다시 계산하게 만든다는 사실을, 오픈AI는 이제 사유 코드와 토큰 수로 돌려주기 시작했어요. 에이전트 앱을 만드는 팀이 먼저 할 일은 모델을 바꾸는 것이 아니라 자기 프롬프트에서 매번 바뀌는 것이 무엇인지부터 적어 보는 것이에요.