프롬프트 캐싱, 켜기만 하면 느려질 수 있다…경계가 비용을 가른다

OpenAI와 Claude의 프롬프트 캐싱을 비교할 때 먼저 볼 것은 캐싱 사용 여부보다 어느 지점까지 다시 읽을 수 있는가다. 여러 요청에서 같은 지시문은 앞에 두고, 요청마다 달라지는 질문과 도구 결과는 그 뒤에 놓는 것이 출발점이다. 변동하는 내용을 저장 구간에 계속 포함하면 쓰기 요금이 늘고, 일부 작업에서는 첫 토큰이 나오는 시간도 길어질 수 있다.

두 API는 같은 접두부를 재사용한다는 원리는 공유하지만 경계 설정과 보존 시간은 다르다. OpenAI의 캐싱 안내에 따르면 GPT-5.6 이상은 명시적 경계 뒤의 입력을 캐시 쓰기에서 제외할 수 있고, 쓰기는 일반 입력의 1.25배, 읽기는 대부분의 해당 모델에서 0.1배이며 기본 유효시간은 마지막 쓰기 또는 재사용 뒤 30분이다. Claude의 캐싱 안내는 기본 5분 쓰기 1.25배, 1시간 쓰기 2배, 대부분의 모델에서 읽기 0.1배를 제시한다. 실제 청구액은 이 배율에 선택한 모델의 입력 단가와 적중한 토큰 수를 적용해야 나온다.

고정 지시문 뒤에 경계를 두는 이유

프롬프트 캐시는 비슷한 문장을 찾아내는 방식이 아니다. 요청의 시작부터 캐시 경계까지 이어지는 내용이 기존 항목과 일치해야 저장된 계산을 재사용한다. 같은 문장이 뒤쪽에 다시 나타나더라도 앞에서 도구 정의나 설정이 달라졌다면 그 뒤의 접두부는 일치하지 않는다. 따라서 반복되는 도구 정의, 시스템 지시문, 예시는 앞에 모으고 사용자별 내용과 새 검색 결과는 뒤로 보내는 배열이 유리하다.

동일한 1만 토큰 지시문을 여러 요청에 보내는 상황을 가정해 보자. 지시문 끝에 경계를 두면 요청별 질문이 달라져도 앞의 긴 구간은 재사용 후보로 남는다. 반대로 현재 시각이나 고객 식별자를 지시문 중간에 넣으면 그 지점부터 접두부가 달라진다. 고정 콘텐츠의 길이만 보는 계산은 이 순서 차이를 놓치므로, 입력을 구성하는 순서 자체가 비용 변수다.

도구 결과는 재사용 범위에 따라 다르게 다뤄야 한다. 서로 다른 사용자의 요청마다 새로 생성되는 검색 결과를 공통 지시문과 한 경계로 묶으면 새 캐시 항목을 반복해서 쓸 가능성이 높다. 한 세션의 후속 턴이 앞선 도구 결과를 내용과 순서를 바꾸지 않고 계속 포함한다면 그 결과까지 재사용할 여지가 있다. 공통 지시문을 여러 사용자 사이에서 재사용하는 경우와 대화 기록을 한 세션 안에서 재사용하는 경우에는 적합한 경계가 다르다.

자동 설정과 명시적 경계의 차이

OpenAI의 지원 모델에서는 기본적으로 암묵적 경계가 선택된다. GPT-5.6 이상에서 변동 구간의 캐시 쓰기를 피하려면 명시적 모드를 선택하고 재사용할 콘텐츠 블록 끝에 경계를 지정할 수 있다. 이때 마지막 경계 뒤의 입력은 일반 입력 요율로 처리된다. 최상위 instructions 필드에는 명시적 경계를 넣을 수 없으므로, 해당 지시문을 캐시하려면 개발자 메시지 안의 지원되는 텍스트 블록으로 구성해야 한다.

Claude는 요청 최상위에 cache_control을 두면 마지막으로 캐시할 수 있는 블록까지 자동으로 경계를 옮긴다. 대화가 이어질 때 공통 기록을 늘려 가며 저장하기에는 편리하지만, 마지막 블록이 매번 다른 도구 결과라면 쓰기 대상도 계속 달라진다. 고정된 지시문 끝에 블록 단위 경계를 두면 그 구간만 반복해서 읽을 수 있다. 자동 캐싱과 명시적 경계를 함께 사용할 수도 있으므로, 공통 지시문과 세션 기록을 서로 다른 재사용 구간으로 나눌 수 있다.

두 서비스 모두 경계 앞 내용에 영향을 주는 설정을 일정하게 유지해야 한다. OpenAI에서는 도구의 이름·설명·순서나 출력 형식 설정의 변경이 일치를 깰 수 있다. Claude에서도 도구와 시스템 메시지, 대화 메시지가 정해진 순서로 접두부를 이루며 사고 설정이나 도구 사용 설정의 변화가 영향을 줄 수 있다. 캐시가 아직 유효한 시간 안에 있어도 동일한 접두부가 만들어지지 않으면 읽기 요금을 적용받지 못한다.

1만 토큰을 반복할 때 쓰기 요금은 얼마인가

비용 차이를 보기 위해 앞의 1만 토큰 지시문만 계산하고, 경계 뒤의 변동 입력과 출력 토큰은 제외하자. 일반 입력으로 한 번 처리하는 비용을 1로 놓는다. 첫 요청에서 지시문을 쓰고 뒤의 요청이 모두 같은 지시문에 적중하며, 읽기 요율이 0.1배인 모델을 쓴다는 조건부 예시다. 따라서 다음 값은 두 회사의 실제 달러 요금을 비교한 표가 아니라 각 모델의 일반 입력 가격에 곱할 배율이다.

• 캐시 없이 세 번 처리하면 1 + 1 + 1 = 3이다.
• GPT-5.6 이상 OpenAI 모델의 해당 요율에서는 1.25 + 0.1 + 0.1 = 1.45다.
• Claude의 5분 캐시에서도 1.25 + 0.1 + 0.1 = 1.45다.
• Claude의 1시간 캐시에서는 2 + 0.1 + 0.1 = 2.2다.

이 조건에서 짧은 유효시간의 쓰기 한 번은 첫 재사용부터 이득이다. 쓰기와 읽기 한 번의 합계가 1.35로, 캐시 없이 두 번 처리한 비용 2보다 낮다. Claude의 1시간 캐시는 같은 비교에서 첫 재사용까지의 합계가 2.1이어서 캐시 없는 두 번보다 비싸다. 두 번째 재사용까지 성공하면 2.2가 캐시 없는 세 번의 비용 3보다 낮아진다.

이 계산이 성립하려면 캐시된 지시문 전체가 실제로 읽혀야 한다. 중간에 접두부가 바뀌거나 항목을 찾지 못하면 예상했던 읽기 토큰은 일반 입력 또는 새 쓰기로 바뀐다. 또한 경계 뒤의 질문과 도구 결과, 출력 토큰은 여기서 제외했을 뿐 실제 청구에서는 사라지지 않는다. 같은 배율의 결과가 나와도 모델별 기본 입력 단가가 다르면 제공업체 간 청구액은 같지 않다.

유효시간과 첫 토큰 지연시간은 따로 판단한다

유효시간 선택에는 요청이 시작되는 간격이 중요하다. Claude의 기본 캐시는 적중할 때마다 수명이 갱신되지만, 시간은 응답이 끝난 시점이 아니라 쓰거나 읽는 요청이 시작된 시점부터 계산된다. 응답 생성에 시간이 오래 걸리면 다음 요청이 사용할 수 있는 시간이 그만큼 줄어든다. 호출이 촘촘하게 이어진다면 기본 유효시간으로도 충분할 수 있고, 긴 공백 뒤에 같은 접두부를 다시 보내는 흐름이라면 1시간 쓰기의 추가 비용을 재사용 횟수와 비교해야 한다.

OpenAI의 앞선 30분 조건은 GPT-5.6 이상에 관한 것이다. 그보다 이전 모델은 보존 방식과 쓰기 과금 구조가 달라, 같은 OpenAI API라는 이유로 앞의 계산식을 그대로 적용할 수 없다. 유효시간이 길어도 저장 항목의 가용성과 접두부 일치가 필요하다. 긴 유효시간은 적중할 기회를 넓히지만, 매번 바뀌는 결과를 같은 경계 앞에 넣는 문제를 해결하지는 않는다.

지연시간에는 별도의 근거가 있다. 에이전트 캐싱 비교 연구는 1만 토큰 시스템 지시문을 사용하는 500개가 넘는 세션에서 OpenAI·Anthropic·Google의 전략을 비교해 API 비용 41~80% 절감과 첫 토큰까지의 시간 13~31% 개선을 보고했고, 변동 도구 결과를 포함한 단순 전체 캐싱에서는 오히려 지연시간이 늘 수 있다고 분석했다. 이 수치는 연구에 사용된 모델과 웹 검색 중심 작업의 결과로, 앞서 계산한 최신 모델별 요금 배율의 실측 결과는 아니다.

비용과 첫 토큰 지연시간이 같은 방향으로 움직인다고 가정해서도 안 된다. 도구 결과 뒤에 새 경계를 계속 만들면 긴 입력을 저장하는 작업이 늘지만, 뒤이은 요청에서 그 결과를 다시 읽지 못할 수 있다. 반면 대화 기록이 변형 없이 이어지는 세션에서는 더 긴 접두부를 읽는 이익이 생길 수 있다. 도구 결과를 일률적으로 포함하거나 제외하기보다, 다음 호출에서 같은 위치에 그대로 남는 결과인지가 판단 기준이다.

어느 경계가 맞는지 결정하는 순서

경계 선택은 재사용 범위와 요청 간격을 함께 놓고 판단하면 된다. 공통 지시문은 서비스 전체에서 반복될 수 있지만, 사용자 질문과 도구 결과는 대개 특정 요청이나 세션에 속한다. 저장 비용이 큰 선택일수록 적중 횟수에 대한 가정이 더 중요하다.

1. 다음 요청에서도 완전히 같은 접두부로 남는 구간을 찾는다. 여러 사용자에게 공통인 지시문과 한 세션에서 이어지는 기록을 구분하고, 변화가 시작되는 블록 앞에 안정적인 경계를 둔다.
2. 그 구간이 유효시간 안에 몇 번 다시 읽힐지 따진다. 재사용이 한 번에 그칠 가능성이 크다면 Claude의 1시간 쓰기는 앞의 조건부 계산에서 비용상 이득이 없다.
3. 응답의 캐시 쓰기·읽기 토큰과 첫 토큰까지의 시간을 함께 본다. 쓰기 토큰만 늘고 읽기 토큰이 늘지 않는다면 경계 앞에 변동 내용이 들어갔는지 확인할 근거가 된다.

이 판단에서 가장 중요한 단위는 프롬프트 전체의 길이가 아니라 동일하게 반복되는 접두부의 길이다. 길고 안정적인 지시문 뒤에 경계를 두면 바뀌는 입력은 새 요청으로 처리하면서 앞부분의 할인은 유지할 수 있다. 세션 안에서 결과가 계속 보존된다면 그때 추가 경계를 고려할 수 있다. 경계를 넓힐 이유는 저장할 내용이 많다는 사실이 아니라, 저장한 내용을 유효시간 안에 다시 읽을 가능성이다.

함께 읽기:

• AI 시대 핵심 역량은 프롬프트가 아니었다…판단과 검수가 앞선다
• Stripe냐 Paddle이냐…수수료보다 ‘판매자 책임’이 비용을 가른다
• SQLite vs PostgreSQL: 데이터 크기보다 동시 쓰기가 경계를 만든다