OpenAI GPT-5.6가 Amazon Bedrock에 도착했고, 명시적 프롬프트 캐싱이 함께 열렸습니다

OpenAI GPT-5.6 Sol, Terra, Luna 세 모델이 Amazon Bedrock에서 정식 출시됐습니다. 세 모델 모두 토큰 단위 종량 과금으로 쓸 수 있고, AWS의 보안·거버넌스 통제 아래에서 동작하며, 사용량은 기존 AWS 약정에 그대로 반영됩니다. 이번 출시에서 함께 들어온 것이 명시적 프롬프트 캐싱(explicit prompt caching)입니다. 프롬프트의 어느 부분을 캐시에 넣고 여러 요청에 걸쳐 재사용할지 직접 지정할 수 있는 기능입니다.

세 개의 모델 티어

GPT-5.6은 용도에 따라 세 단계로 나뉩니다. Sol은 가장 복잡한 추론과 에이전트형 코딩 작업을 위한 티어입니다. Terra는 일상적인 프로덕션 워크로드를 균형 있게 처리하는 용도이고, Luna는 분류나 요약처럼 빠르고 대량으로 돌려야 하는 작업에 맞춰져 있습니다.

모델 ID는 각각 openai.gpt-5.6-sol, openai.gpt-5.6-terra, openai.gpt-5.6-luna입니다. 리전 가용성은 티어마다 다릅니다. Sol은 US East(버지니아 북부)와 US East(오하이오)에서 제공되고, Terra와 Luna는 여기에 더해 US West(오레곤)에서도 쓸 수 있습니다. 리전별 최신 지원 현황은 Amazon Bedrock 문서의 리전별 지원 모델 페이지에서 확인할 수 있습니다.

엔드포인트와 인증

GPT-5.6 모델은 OpenAI 호환 Responses API를 통해 Amazon Bedrock의 bedrock-mantle 엔드포인트에서 서빙됩니다. 인증은 AWS 자격 증명에서 생성한 단기 베어러 토큰을 쓰는 방식을 권장합니다. 토큰 생성기를 OpenAI SDK와 함께 설치합니다.

pip install openai aws-bedrock-token-generator

토큰 생성기는 표준 AWS 자격 증명 체인(IAM 역할, 환경 변수, CLI 프로파일)을 사용하므로 코드에 장기 비밀 값을 두지 않아도 됩니다.

from openai import OpenAI
from aws_bedrock_token_generator import provide_token

REGION = "us-east-2"

client = OpenAI(
    base_url=f"https://bedrock-mantle.{REGION}.api.aws/openai/v1",
    api_key=provide_token(region=REGION),
)

기본 요청은 Responses API 형식을 따릅니다.

response = client.responses.create(
    model="openai.gpt-5.6-terra",
    instructions="You are a concise technical assistant.",
    input="What is Amazon Bedrock?",
    max_output_tokens=500,
)
print(response.output_text)

스트리밍, 함수 호출, 엄격한 JSON 스키마 출력은 OpenAI 네이티브 API와 동일하게 동작합니다. 도구 정의는 Responses API의 평면(flat) 형식을 씁니다.

diagram

추론 강도 조절

GPT-5.6은 추론 강도(reasoning effort)를 none, low, medium, high, xhigh 다섯 단계로 지정할 수 있고 기본값은 medium입니다. 강도가 높을수록 어려운 문제에 더 많은 추론을 배분하고, none은 단순한 작업에서 지연을 가장 낮게 가져가는 경로입니다.

response = client.responses.create(
    model="openai.gpt-5.6-luna",
    input="Classify this ticket as bug, feature request, or question: 'App crashes on login.'",
    reasoning={"effort": "none"},
)

샘플링 파라미터인 temperature와 top_p는 reasoning.effort가 none일 때 사용할 수 있습니다. 그 외 강도에서는 모델의 추론 과정이 출력 분산을 제어합니다.

캐싱은 어떻게 동작하는가

프롬프트 캐싱은 여러 요청에 걸쳐 반복되는 프롬프트 부분을 Amazon Bedrock이 다시 계산하지 않고 넘기는 기능입니다. GPT-5.6에서 캐시 읽기는 캐시되지 않은 입력 토큰 대비 90% 할인된 요금으로 청구되고, 캐시 쓰기는 캐시되지 않은 입력 요율의 1.25배로 청구됩니다. 한 번 쓰고 여러 번 읽는 패턴에 맞춰 설계된 구조입니다. 읽기에서 아끼는 양이 쓰기에서 더해지는 양보다 훨씬 크기 때문에, 캐시를 거쳐 가는 토큰 중 캐시 읽기가 대략 20%를 차지하는 지점부터 워크로드의 순 입력 비용이 낮아집니다.

캐싱 모드는 두 가지입니다. 암묵적(implicit) 모드는 Amazon Bedrock이 캐시 분기점을 자동으로 배치하는 방식이고, 명시적(explicit) 모드는 캐시 경계를 직접 표시해 정밀하게 통제하는 방식입니다. 캐시된 프리픽스는 최소 30분 동안 재사용할 수 있습니다.

암묵적 캐싱은 기본으로 켜져 있습니다

GPT-5.6에서 프롬프트 캐싱은 기본적으로 암묵적 모드로 켜져 있습니다. 캐싱 관련 파라미터 없이 요청을 보내면 Amazon Bedrock이 캐시 분기점을 자동으로 두고 재사용할 수 있는 프리픽스를 찾습니다. 1,024 토큰 이상인 안정적 프리픽스는 코드 변경 없이 캐시되어 재사용됩니다.

response = client.responses.create(
    model="openai.gpt-5.6-terra",
    instructions=SYSTEM_INSTRUCTIONS,  # 안정적 프리픽스, 1,024 토큰 이상
    input=user_question,
)
details = response.usage.input_tokens_details
print(f"cached: {details.cached_tokens}, written: {details.cache_write_tokens}")

기존 코드도 첫날부터 캐시 읽기를 얻기 시작합니다. 다만 안정적 프리픽스 뒤의 내용이 매 요청마다 바뀌는 챗 어시스턴트나 에이전트형 도구 루프에서는, 프리픽스를 직접 표시하는 명시적 분기점을 쓰는 편이 더 예측 가능한 결과를 줍니다.

명시적 캐싱 설정

명시적 모드는 캐시 경계를 직접 통제합니다. 재사용할 프리픽스의 끝을 표시하면 그 지점까지가 캐시되고, 캐시된 프리픽스는 최소 30분 동안 유지됩니다. 세 개의 요청 파라미터가 캐싱을 제어합니다.

prompt_cache_breakpoint: 콘텐츠 블록에 두어 재사용 프리픽스의 끝을 정확히 표시합니다. 표시된 블록까지가 캐시되고 그 뒤는 자유롭게 바뀌어도 캐시된 프리픽스는 유효합니다. 각 캐시 프리픽스는 최소 1,024 토큰이어야 하고, input_text, input_image, input_file 블록에 요청당 최대 4개까지 둘 수 있습니다.
prompt_cache_key: 요청을 같은 캐시로 라우팅하는 안정적 ID입니다. 세션이나 애플리케이션 전체에서 일관되게 설정하면 반복 요청이 캐시된 프리픽스를 찾습니다.
prompt_cache_options: 캐싱 모드(암묵적/명시적)와 TTL을 제어합니다.

긴 시스템 지침이 매 호출마다 동일하고 그 뒤 사용자 질문만 바뀌는 지원 어시스턴트라면, 정적 콘텐츠 끝에 분기점을 둡니다.

response = client.responses.create(
    model="openai.gpt-5.6-terra",
    prompt_cache_key="support-app:kb-v1",
    input=[
        {
            "type": "message",
            "role": "developer",
            "content": [{
                "type": "input_text",
                "text": SYSTEM_INSTRUCTIONS,  # 길고 정적, 1,024 토큰 이상
                "prompt_cache_breakpoint": {"mode": "explicit"},
            }],
        },
        {
            "type": "message",
            "role": "user",
            "content": [{
                "type": "input_text",
                "text": user_question,  # 매 요청 변경
            }],
        },
    ],
    extra_body={"prompt_cache_options": {"mode": "explicit"}},
)

캐시 동작 확인

모든 응답은 usage.input_tokens_details 객체에 캐시가 실제로 한 일을 담아 돌려줍니다. cached_tokens는 캐시에서 읽어온 입력 토큰이고 90% 할인 요율로 청구됩니다. cache_write_tokens는 캐시에 쓴 입력 토큰이고 캐시되지 않은 요율의 1.25배로 청구됩니다.

전체 입력 토큰은 다음 관계를 따릅니다.

input_tokens = cached_tokens + cache_write_tokens + 캐시되지 않은 나머지

cached_tokens와 cache_write_tokens는 input_tokens 위에 더해지는 값이 아니라 그 일부입니다. 따라서 캐시에서 제공된 토큰은 한 번만 집계되고 캐시 읽기 요율로 한 번만 청구됩니다. 같은 토큰에 두 번 과금되지 않습니다.

동일한 3,626 토큰 시스템 프리픽스를 하나의 prompt_cache_key 아래에서 재사용하고, 사용자 질문만 매번 바꾼 경우의 수치는 다음과 같습니다.

요청	input_tokens	cached_tokens	cache_write_tokens	신규(비캐시) 입력
첫 번째(콜드)	3,682	0	3,626	56
두 번째	3,671	3,626	0	45
세 번째	3,662	3,626	0	36

첫 요청이 3,626 토큰 프리픽스를 캐시에 씁니다. 두 번째 요청부터는 그 프리픽스를 캐시 읽기 할인 요율로 읽어오고, 새 사용자 입력(여기서는 45, 36 토큰)만 표준 요율로 처리됩니다.

두 필드는 매 응답마다 옵니다. 가장 직접적인 검증 방법은 애플리케이션에서 요청 ID, prompt_cache_key와 함께 이 값을 로깅한 뒤, 프로덕션 트래픽이 캐시에 의존하기 전에 로그에서 한 번 쓰고 여러 번 읽는 패턴을 확인하는 것입니다. 집계 모니터링용으로는 bedrock-mantle 엔드포인트가 추론·토큰 지표를 AWS/BedrockMantle 네임스페이스 아래 Amazon CloudWatch로 발행합니다. 계정, 프로젝트, 모델별 전체 입력·출력 토큰 볼륨을 추적합니다. 요청 단위 캐시 내역은 각 응답의 usage 객체에서 오므로, 애플리케이션 레벨에서 두 필드를 로깅하는 것이 캐싱 관찰성의 토대가 됩니다.

에이전트 루프에서의 캐싱

명시적 캐싱이 가장 잘 맞는 곳이 에이전트형 워크로드입니다. 도구 호출 루프에서는 시스템 프롬프트와 도구 정의가 매 턴 반복되고 대화는 끝쪽에서 자라납니다. 정적 콘텐츠 뒤에 분기점을 두기에 적합한 구조입니다.

diagram

첫 턴이 시스템 프롬프트 프리픽스를 캐시에 씁니다. 이후 모든 턴은 새로 추가된 도구 호출과 결과만 처리하면서 그 프리픽스를 캐시에서 읽습니다. 30분 TTL은 수 분 단위의 에이전트 세션을 충분히 덮습니다. 예제 코드에서는 prompt_cache_options에 {"mode": "explicit", "ttl": "30m"}을 넘기고, 세션마다 일관된 prompt_cache_key(예: incident-agent:session-42)를 지정합니다. 모델이 어떤 도구를 호출할지 결정하며 루프를 이끌고, 도구 호출 대신 최종 응답을 반환하면 루프가 끝납니다.

두 모드 중 무엇을 쓸 것인가

모드는 prompt_cache_options.mode로 정합니다. 암묵적 모드가 기본값입니다. 이 모드에서는 Amazon Bedrock이 최신 메시지에 캐시 분기점을 자동으로 두고 캐시 적중률을 최대화하려 시도하며, 직접 추가한 명시적 분기점도 존중합니다. 명시적 모드에서 {"mode": "explicit"}을 설정하면 직접 배치한 분기점만 캐시 읽기·쓰기에 쓰입니다.

프롬프트가 안정적 프리픽스와 매번 바뀌는 내용으로 나뉠 때 명시적 통제가 특히 의미가 있습니다. 암묵적 모드에서는 Bedrock이 분기점을 두므로 읽기가 시작되기 전 캐시 쓰기 횟수가 요청마다 달라질 수 있습니다. 정적 콘텐츠 끝에 명시적 분기점을 하나 두면 동작이 결정적이 됩니다. 첫 요청이 프리픽스를 한 번 쓰고, 이후 모든 요청은 그것을 캐시에서 읽습니다.

워크로드	권장 모드
프롬프트가 정확히 반복됨 (반복 문서 분석, 고정 프롬프트 배치 스코어링)	암묵적(기본), 요청 변경 불필요. 명시적을 쓰면 같은 결과를 결정적으로 통제
안정적 프리픽스 + 변하는 접미부 (챗 어시스턴트, RAG, 에이전트 도구 루프)	명시적, 정적 콘텐츠 뒤에 분기점 하나
갱신 빈도가 다른 여러 섹션 (도구, 시스템 프롬프트, 긴 문서, 대화)	명시적, 세밀한 통제를 위해 최대 4개 분기점

프롬프트 캐싱을 쓰고 싶지 않다면 명시적 분기점을 제공하지 않고 명시적 모드를 쓰면 됩니다. 이 경우 프롬프트 캐시 과금에서 빠지고 캐시 쓰기 요금도 발생하지 않지만, 지연을 낮추기 위해 프롬프트 일부가 Bedrock 시스템에 여전히 캐시될 수 있습니다.

어느 모드든 프로덕션에서 두 usage 필드를 계속 모니터링하는 것이 좋습니다. 건강한 캐싱 패턴은 쓰기마다 의미 있는 읽기가 뒤따르는 모습입니다. 암묵적 모드에서 쓰기는 많은데 읽기가 적다면, 정적 콘텐츠 끝에 명시적 분기점을 추가해 프리픽스를 결정적으로 만드는 전환을 고려할 수 있습니다. 명시적 모드에서는 호출 간에 변하지 않는 부분만 덮도록 분기점을 앞으로 옮기고, 같은 캐시를 공유해야 할 요청들에서 prompt_cache_key가 일관되게 설정됐는지 확인합니다.

기존 GPT 모델에서의 마이그레이션

이미 Amazon Bedrock에서 GPT-5.5나 GPT-5.4를 쓰고 있다면 업그레이드는 모델 ID 변경 수준입니다. 엔드포인트, 인증, Responses API 요청 형태는 그대로 유지됩니다.

response = client.responses.create(
    model="openai.gpt-5.6-terra",  # 기존: openai.gpt-5.5
    instructions=SYSTEM_PROMPT,
    input=user_input,
    max_output_tokens=1000,
)

업그레이드에 두 가지를 함께 반영합니다. 하나는 캐싱 방식의 변화입니다. GPT-5.5와 GPT-5.4에서 프롬프트 캐싱은 자동이었고, 1,024 토큰 이상의 적격 프리픽스를 추가 파라미터 없이 캐시하며 캐시 쓰기에는 요금이 없었습니다. GPT-5.6은 앞에서 설명한 통제형 모델로 바뀌었고, 1.25배 캐시 쓰기 요율이 암묵적·명시적 쓰기 모두에 적용됩니다. 다른 하나는 추론 강도 조정입니다. 지금 쓰는 강도로 시작한 다음 한 단계 낮춰서 테스트하는 방법이 실무적입니다. GPT-5.6은 토큰 효율이 더 좋아, 많은 워크로드가 더 낮은 강도에서도 품질을 유지합니다.

도입 전 확인할 사실

세 모델은 정식 출시 상태이며, 리전 가용성은 티어별로 다릅니다. Sol은 US East(버지니아 북부, 오하이오), Terra와 Luna는 여기에 US West(오레곤)를 더해 제공됩니다. 캐시 읽기 90% 할인, 캐시 쓰기 1.25배, 캐시 프리픽스 최소 1,024 토큰, 요청당 최대 4개 분기점, 최소 30분 재사용 유지는 원문에 명시된 값입니다. 구체적인 요율은 Amazon Bedrock 요금 페이지, 리전별 지원 현황은 Amazon Bedrock 사용자 가이드의 리전별 지원 모델 문서, CloudWatch 지표는 AWS/BedrockMantle 네임스페이스 관련 문서에서 확인할 수 있습니다.

원문: Introducing explicit prompt caching for OpenAI GPT-5.6 models on Amazon Bedrock · 발행일 2026-07-30