GPT-5.6 가격 책정: 더 저렴한 모델이 항상 더 저렴한 AI 워크플로우를 의미하지는 않습니다

가격표는 유용합니다.

하지만 과하게 해석하기 쉽기도 합니다.

더 명확한 계층(tiers), 더 빠른 옵션, 그리고 더 낮은 비용 경로를 가진 새로운 모델 제품군이 등장하면, 가장 먼저 드는 본능은 입력(input) 및 출력(output) 가격을 비교하는 것입니다. 이는 타당합니다. 창업자들은 특정 기능이 실제 사용 환경에서 생존 가능한지 알아야 하기 때문입니다.

하지만 백만 토큰당 가격은 AI 비용의 첫 번째 계층일 뿐입니다.

실제 제품 비용은 보통 한 단계 뒤에 나타납니다:

어떤 작업에 어떤 모델을 사용하는가?
워크플로우(workflow)가 얼마나 많은 출력을 생성하는가?
동일한 컨텍스트(context)가 얼마나 자주 반복되는가?
첫 번째 답변이 충분하지 않을 때 얼마나 많은 재시도(retries)가 발생하는가?
AI 단계 주변에 여전히 얼마나 많은 인간의 검토(human review)가 남아 있는가?
사용자들이 매일 해당 기능에 의존하게 되면 어떤 일이 발생하는가?

이것이 바로 GPT-5.6이 능력(capability) 측면뿐만 아니라 경제적 관점에서도 흥미로운 이유입니다.

모델 라인업은 팀들에게 더 많은 가격 선택권을 제공합니다. 하지만 제품에는 여전히 비용 시스템이 필요합니다.

변경된 사항

OpenAI는 세 가지 모델 계층을 가진 GPT-5.6을 도입했습니다:

Sol: 가장 강력한 모델로, 백만 토큰당 입력 $5, 출력 $30로 책정되었습니다.
Terra: 균형 잡힌 모델로, 백만 토큰당 입력 $2.50, 출력 $15로 책정되었습니다.
Luna: 더 빠르고 저렴한 모델로, 백만 토큰당 입력 $1, 출력 $6로 책정되었습니다.

OpenAI는 또한 명시적인 캐시 중단점(cache breakpoints)과 최소 30분의 캐시 수명을 포함하여, GPT-5.6 및 이후 모델을 위한 더 예측 가능한 프롬프트 캐싱(prompt caching)을 도입했습니다. 캐시 쓰기(Cache writes)는 모델의 캐싱되지 않은 입력 요율의 1.25배로 청구되는 반면, 캐시 읽기(cache reads)는 90%의 캐시 입력 할인 혜택을 받습니다.

이는 SaaS 제품에 AI를 구축하는 팀들에게 실질적인 질문을 던집니다:

비용 계획을 모델 계층부터 시작해야 할까요, 아니면 워크플로우부터 시작해야 할까요?

더 안전한 답변은 워크플로우입니다.

모델 가격이 전체 비용이 아닌 이유

저렴한 모델은 작업이 해당 모델에 적합할 때 도움이 됩니다.

하지만 그것이 자동으로 전체 제품을 더 저렴하게 만들지는 않습니다.

예를 들어, 두 가지 AI 워크플로우를 상상해 보십시오:

고객 메시지를 몇 가지 카테고리로 분류하는 지원 태깅 (support-tagging) 워크플로우.
긴 컨텍스트 (long context)를 읽고, 여러 제약 조건을 통해 추론하며, 상세한 권장 사항을 생성하는 기술 검토 (technical review) 워크플로우.

첫 번째 워크플로우는 빠르고 비용이 저렴한 모델로도 잘 작동할 수 있습니다.

두 번째 워크플로우는 더 강력한 모델이 필요하거나, 적어도 어려운 케이스만 강력한 경로로 보내는 세심한 라우팅 규칙 (routing rule)이 필요할 수 있습니다.

만약 두 워크플로우가 기본적으로 동일한 모델을 사용한다면, 보통 다음 두 가지 중 하나가 발생합니다:

단순한 워크플로우가 필요 이상으로 비싸집니다.
복잡한 워크플로우가 처음에는 더 저렴해 보이지만, 나중에 검토 작업, 재시도 (retries), 또는 사용자의 수정 작업을 유발합니다.

둘 다 비용 문제입니다.

하나는 인보이스 (invoice) 상에 명확히 드러납니다.

다른 하나는 운영 (operations) 내부에 숨겨져 있습니다.

창업자가 모델링해야 할 네 가지 비용 계층

창업자가 모든 AI 기능을 테스트하기 전에 매번 재무 스프레드시트로 만들 필요는 없습니다.

하지만 기능이 고객 대상 사용 단계로 넘어가면, 네 가지 비용 계층이 가시화되어야 합니다.

1. 모델 티어 (Model tier) 비용

이것은 가장 명백한 부분입니다.

입력 토큰 (input tokens), 출력 토큰 (output tokens), 추론 노력 (reasoning effort), 모델 티어, 그리고 제공업체 가격 책정 (provider pricing)이 모두 중요합니다.

하지만 팀은 여기서 멈춰서는 안 됩니다. 한 가지 작업에 가장 저렴한 모델이라 할지라도, 추가적인 검토, 재시도, 또는 더 긴 프롬프트 (prompts)를 요구하는 답변을 생성한다면 결과적으로 비싸질 수 있습니다.

2. 출력 형태 (Output shape)

출력 토큰은 종종 비용이 조용히 증가하는 지점입니다.

짧은 분류, 상태 라벨, 또는 구조화된 필드 (structured fields)를 반환하는 제품은 긴 설명, 초안, 권장 사항 또는 보고서를 생성하는 제품과 다른 비용 프로필을 가집니다.

만약 어떤 기능이 항상 긴 답변을 요구한다면, 사용자의 행동이 늘어날 때마다 청구 금액도 함께 늘어납니다.

더 나은 패턴은 사용자의 의사결정을 중심으로 출력을 설계하는 것입니다:

사용자가 짧은 답변을 필요로 하는가?
사용자가 초안 (draft)을 필요로 하는가?
사용자가 추론된 설명 (reasoned explanation)을 필요로 하는가?
시스템이 산문 (prose) 대신 구조화된 객체 (structured object)를 필요로 하는가?
전체 설명은 요청 시에만 나타나게 할 수 있는가?

출력 형식 (output format)은 단순히 UX의 문제가 아닙니다. 그것은 비용 설계 (cost design)입니다.

3. 반복되는 컨텍스트 (Repeated context)와 캐싱 (caching)

워크플로우가 동일한 대규모 컨텍스트 (large context)를 반복적으로 전송할 때 프롬프트 캐싱 (Prompt caching)이 가치를 발휘합니다.

여기에는 다음과 같은 것들이 포함될 수 있습니다:

시스템 지침 (System instructions).
제품 규칙 (Product rules).
정책 텍스트 (Policy text).
도구 정의 (Tool definitions).
재사용 가능한 예시 (Reusable examples).
계정 수준 설정 (Account-level configuration).
요청 전반에 걸쳐 안정적으로 유지되는 긴 문서 또는 지식 컨텍스트 (knowledge context).

캐싱은 마법이 아닙니다. 그것은 재사용 여부에 달려 있습니다.

프롬프트가 끊임없이 변한다면, 캐시 히트율 (cache hit rate)은 낮게 유지됩니다. 정적 콘텐츠 (static content)를 앞부분에 배치하고 동적인 사용자 콘텐츠 (dynamic user content)가 나중에 나타나도록 하면, 유용한 캐시 히트 (cache hit) 가능성이 높아집니다.

이는 프롬프트 설계 (prompt design)를 변화시킵니다.

프로덕션 프롬프트 (production prompt)는 하나의 커다란 텍스트 블록으로 취급되어서는 안 됩니다. 제공업체 (provider)가 지원하는 경우, 반복되는 콘텐츠가 안정적이고 측정 가능하며 캐싱 가능하도록 (cacheable) 구조화되어야 합니다.

4. 검토, 재시도 및 폴백 비용 (Review, retry, and fallback cost)

이것은 많은 초기 AI 데모들이 놓치는 계층입니다.

첫 번째 API 호출은 저렴할 수 있습니다.

하지만 전체 워크플로우 (full workflow)는 그렇지 않을 수 있습니다.

고객 대상 기능은 다음과 같은 경로를 통해 추가 비용을 발생시킬 수 있습니다:

부실한 답변 이후의 재시도 (retries),
검토 대기열 (review queues),
더 강력한 모델로의 에스컬레이션 (escalation),
폴백 경로 (fallback paths),
지원 티켓 (support tickets),
수동 수정 (manual correction),
실패한 작업의 재처리 (reprocessing failed jobs),
더 긴 지연 시간 (latency) 구간,
그리고 출력이 명확하지 않을 때 발생하는 고객의 혼란.

이러한 비용은 항상 토큰 (tokens)의 형태로만 나타나지는 않습니다.

그것은 엔지니어링 시간, 지원 부하, 제품 복잡성, 그리고 신뢰도 저하로 나타납니다.

AI 기능을 위한 더 나은 비용 모델

“어떤 모델이 가장 저렴한가?”라고 묻는 대신, 다음과 같이 물으십시오:

이 워크플로우를 위한 가장 저렴하고 신뢰할 수 있는 경로는 무엇인가?

이 질문은 더 유용한 구조로 이어집니다.

루틴 경로 (Routine path)

리스크가 낮고 반복 가능한 작업에 이 경로를 사용하십시오.

예시:

분류 (classification),
추출 (extraction),
짧은 요약 (short summaries),
단순 재작성 (simple rewriting),
의도 탐지 (intent detection),
포맷팅 (formatting),
라우팅 (routing),
그리고 가벼운 지원 보조 (lightweight support assistance).

목표는 속도와 예측 가능성입니다.

에스컬레이션 경로 (Escalation path)

더 강력한 추론 (reasoning)이 결과값을 바꾸는 작업에 이를 사용하세요.

예시:

복잡한 코드 리뷰 (complex code review),
다단계 제품 분석 (multi-step product analysis),
정책 민감 작업 (policy-sensitive work),
보안 리뷰 (security review),
기술적 계획 (technical planning),
그리고 고객이나 운영에 영향을 미치는 결정들.

목표는 기본적으로 낮은 비용을 지향하는 것이 아니라 품질입니다.

캐시된 경로 (Cached path)

긴 컨텍스트 (long context)가 반복될 때 이를 사용하세요.

예시:

문서 어시스턴트 (documentation assistant),
정책 리뷰 (policy review),
제품 온보딩 어시스턴트 (product onboarding assistant),
내부 지식 워크플로우 (internal knowledge workflows),
안정적인 비즈니스 규칙을 가진 지원 코파일럿 (support copilots),
그리고 반복되는 도구 정의 (tool definitions)를 가진 에이전트 워크플로우 (agent workflows).

목표는 동일한 컨텍스트에 대해 반복해서 전체 입력 비용을 지불하는 것을 피하는 것입니다.

인간 검토 경로 (Human-review path)

출력물이 유의미한 비즈니스 임팩트를 가질 때 이를 사용하세요.

예시:

법률 민감 초안 (legal-sensitive drafts),
금융 권고 (financial recommendations),
헬스케어 인접 콘텐츠 (healthcare-adjacent content),
보안 민감 워크플로우 (security-sensitive workflows),
고객 대면 자동화 (customer-facing automation),
그리고 고가치 계정 결정 (high-value account decisions).

목표는 자동화 그 자체를 위한 것이 아니라 신뢰성입니다.

개발자가 측정해야 할 것

프로덕션 AI 기능은 총 API 지출액만으로 측정해서는 안 됩니다.

워크플로우별로 비용을 추적해야 합니다.

유용한 지표는 다음과 같습니다:

성공적인 작업당 비용 (Cost per successful task)
API 호출당 비용이 아닙니다. 하나의 작업을 완료하는 데 여러 번의 호출이 필요할 수 있습니다.
작업 유형별 출력 토큰 (Output tokens per task type)
일부 프롬프트는 출력이 길어지기 전까지는 저렴해 보일 수 있습니다.
캐시 히트율 (Cache hit rate)
캐싱이 비용을 절감할 것으로 예상된다면, 실제로 캐시가 적중(hit)하고 있는지 측정해야 합니다.
재시도율 (Retry rate)
더 많은 재시도를 유발하는 저렴한 모델은 결과적으로 더 저렴하지 않을 수 있습니다.
에스컬레이션율 (Escalation rate)
워크플로우가 저비용 모델에서 더 높은 성능의 모델로 얼마나 자주 전환되는지 측정합니다.
인간 수정률 (Human correction rate)
수동 편집, 거부된 출력, 또는 고객 지원 후속 조치 등은 모두 비용의 일부입니다.
경로별 지연 시간 (Latency by path)
저비용 경로라 할지라도 속도가 느리게 느껴진다면 제품 경험을 해칠 수 있습니다.
고객 세그먼트별 비용 (Cost by customer segment)
헤비 유저(Heavy users)는 일반 데모 유저와 매우 다르게 행동할 수 있습니다.

이러한 지표들이 비용을 실질적으로 나타냅니다.

이 지표들이 없다면, 팀은 가격 페이지를 보고 추측만 할 뿐입니다.

창업자가 출시 전에 결정해야 할 사항

AI 워크플로우를 고객 대상의 약속으로 전환하기 전에, 창업자는 세 가지 사용 수준을 모델링해야 합니다:

1. 파일럿 사용 (Pilot usage)

소수의 사용자.

목표는 워크플로우가 유용한지, 그리고 품질이 어디에서 무너지는지를 학습하는 것입니다.

2. 일반 사용 (Normal usage)

예상되는 안정적인 제품 사용.

목표는 비용이 가격 책정, 지원 역량 및 마진에 부합하는지 확인하는 것입니다.

3. 성장 사용 (Growth usage)

기능이 인기를 얻은 후의 높은 채택률.

목표는 고객이 실제로 사용할 때도 시스템이 여전히 타당한지 확인하는 것입니다.

이 단계에서 많은 AI 기능의 실체가 명확해집니다.

20명의 사용자에게는 저렴해 보이는 워크플로우라도, 2,000명의 사용자에게 작동하려면 라우팅 (routing), 캐싱 (caching), 배치 처리 (batching) 또는 제한 사항 (limits)이 필요할 수 있습니다.

실질적인 시사점

GPT-5.6은 팀에게 성능, 속도, 비용 측면에서 더 많은 선택지를 제공합니다.

이는 유용합니다.

하지만 AI 제품의 경제성은 단순히 가장 낮은 가격의 모델을 선택한다고 해서 해결되지 않습니다.

더 나은 방법은 다음과 같은 요소를 중심으로 워크플로우를 설계하는 것입니다:

작업 복잡도 (task complexity),
출력 길이 (output length),
반복되는 컨텍스트 (repeated context),
캐시 동작 (cache behavior),
재시도율 (retry rate),
검토 요구사항 (review requirements),
폴백 경로 (fallback paths),
그리고 고객 의존성 (customer dependency).

가장 저렴한 모델이 항상 가장 저렴한 워크플로우인 것은 아닙니다.

가장 저렴하면서도 신뢰할 수 있는 워크플로우는 적절한 작업을 적절한 경로로 라우팅(routing)하고, 실행 후 발생하는 상황을 측정하며, 모든 고객의 행동을 가능한 가장 비싼 AI 호출로 전환하는 것을 방지하는 워크플로우입니다.

창업자를 위한 액션 체크리스트 (Founder action checklist)

AI 기능을 출시하기 전에 다음을 질문하십시오:

이 워크플로우의 어떤 부분이 일상적인가?
어떤 부분에 더 강력한 추론 (reasoning)이 필요한가?
어떤 컨텍스트가 캐시 (cache)할 수 있을 만큼 충분히 자주 반복되는가?
예상되는 출력 길이는 얼마인가?
답변이 충분히 좋지 않을 때는 어떤 일이 발생하는가?
사용자가 이 워크플로우를 얼마나 자주 트리거(trigger)할 것인가?
단순히 API 호출당 비용이 아니라, 성공적인 작업당 비용은 얼마인가?
사용량이 10배로 늘어나도 가격 책정이 여전히 유효한가?

이것이 바로 AI 비용 계획이 유용해지는 지점입니다.

단순히 가격표(pricing table)에서만 이루어지는 것이 아닙니다.

워크플로우에서 이루어져야 합니다.

Insights