두 개의 청구서가 같은 날 도착했습니다. 첫 번째는 gpt-4o에 대한 것입니다. 팀은 입력 토큰 100만 개당 $2.50, 출력 토큰 100만 개당 $10를 지불하며, 컨텍스트 윈도우 (Context Window)는 128,000 토큰입니다. 두 번째는 구형인 gpt-4-0613에 대한 것입니다. 어떤 개발자가 여전히 예전 습관대로 호출하고 있는 이 모델은 입력당 $30, 출력당 $60를 지불하며, 윈도우는 고작 8,192 토큰에 불과합니다. 차이는 몇 배가 아니라 수십 배에 달하며, 이는 단일 요청의 가격만 봐서는 보이지 않습니다.

이 글은 모델 리뷰가 아니라 측정 가능한 실험입니다. 팀의 부하 모델을 단일화하여, 단순한 수치 하나가 아닌 명확한 가정을 바탕으로 한 비용 범위를 도출하는 것입니다. 계산기에는 역할, 요청 빈도, 컨텍스트 길이, 응답 길이 및 반복 횟수가 포함됩니다. 이 중 그 어떤 것도 가격표만 보고 판단할 수 없으며, 팀의 작업 큐 (Task Queue)에서 직접 가져와야 합니다.

실험의 결과는 다음과 같은 선택의 실무 규칙입니다. 만약 계산된 비용 범위가 팀의 합의된 임계값을 초과한다면, 단일 요청 비용이 아무리 저렴하더라도 해당 모델은 선택에서 탈락합니다. 이제 범위가 어떻게 계산되는지, 그리고 그 안에서 돈이 어디로 새어나가는지 보여드리겠습니다.

GPT-4 API 가격이 단독으로 문제를 해결할 수 없는 이유

이 글이 반박하고자 하는 논쟁적인 암묵적 전제는 단순합니다. 단일 요청의 가격만으로 팀이 모델을 선택하기에 충분하다는 것입니다. 이는 가격은 즉시 보이지만 부하 (Load)는 보이지 않기 때문에 편리한 생각입니다. 하지만 모델을 선택하는 것은 가격표를 읽는 한 명의 개발자가 아니라, 웹사이트의 봇, 내부 어시스턴트, 에이전트, 이미지 생성, 음성 합성 등 팀의 미래 전체 워크플로우입니다. 각 시나리오는 기본 가격에 고유한 승수를 곱하며, 긴 대화에는 별도의 함정이 있습니다. gpt-4-0613의 8,192 토큰 윈도우와 gpt-4o의 128,000 토큰 윈도우를 비교하면, 구형 모델은 대화 기록 전체를 담지 못하거나 기록을 잘라내어 재확인을 유도하게 됩니다. 재확인은 또 다른 유료 호출이며, 이는 계산기에서 별도의 승수로 포함됩니다.

여기서 흔히 발생하는 구매 오류의 원인을 짚고 넘어가야 합니다. 제공업체의 총 잔액(balance) 자체가 특정 모델의 가격을 증명하지는 않습니다. 잔액은 결제를 간편하게 만들 뿐 부하(load)를 계산하지는 않습니다. 이는 여전히 기술 리드(tech lead)와 재무 책임자의 과제이며, 가격표(price list)가 아닌 부하 모델(load model)을 통해 해결해야 합니다.

계산일 기준 확인된 가격

이 방법론의 첫 번째 규칙은 기억에 의존해 예산을 세우지 말고, 오래된 북마크를 신뢰하지 않는 것입니다. 여기에는 구체적인 함정이 있습니다. 현재 OpenAI 웹사이트의 gpt api pricing 개요 페이지에는 최신 라인업인 gpt-5.x만 표시되며, gpt-4, gpt-4o, gpt-4.1의 가격은 각 모델 페이지에서 별도로 확인해야 합니다. 가격표 탭 하나만 보고 예산을 짜는 사람은 잘못된 수치를 책정할 위험이 있습니다.

다음은 2026년 7월 18일 접속 기준, OpenAI 모델 페이지에서 확인된 내용입니다. "query" 열은 개발자들이 티켓(ticket)에서 모델을 검색할 때 사용하는 명칭이며, 괄호 안은 기술적 이름(technical name)입니다.

표에서 예산 책정에 중요한 점은 다음과 같습니다: OpenAI 데이터에 따르면 gpt 4.1 api는 입력과 출력 모두에서 gpt 4o api보다 저렴하지만, 컨텍스트 창(context window)은 약 1,047,576 토큰이며 지식 컷오프는 2024년 6월입니다. gpt 4 mini api는 좁은 범위의 작업을 위한 기본 저가형 모델로 유지됩니다. 한편, gpt 4 api와 gpt-4-turbo는 OpenAI의 지원 종료(deprecation) 일정에 따라 구형(deprecated)으로 표시되어 있으며, 중단 예정일은 2026년 10월 23일이고 권장 대체 모델은 gpt 5.5 api입니다. 즉, 여전히 gpt-4 가격에 묶여 있는 예산은 정적인 수치가 아니라, 해당 기간 내의 마이그레이션(migration) 결정이 필요함을 의미합니다.

캐시 입력 토큰(cache input tokens)에 대해 별도로 언급하자면, 이는 반복적인 호출(repeated turns)에 직접적인 영향을 미칩니다. gpt-4o의 경우 캐시된 접두사(cached prefix)에 대한 입력 비용이 1M당 $2.50에서 $1.25로 감소하며, gpt-4.1은 $2.00에서 $0.50로 감소합니다. 이것이 반복 모델을 위한 유일하고 정직한 "할인" 레버리지이며, 아래 계산기(calculator)에 반영될 것입니다.

부하 모델(Load Model) 구성 요소

단일 부하 모델(Load Model)은 다섯 가지 사항, 즉 역할(Role), 빈도(Frequency), 컨텍스트(Context), 응답 길이(Response Length), 그리고 반복(Repeats)을 명확히 합니다. 역할(Role)은 단순한 '모델'이 아니라 요청을 생성하는 시나리오를 의미하며, 일반적으로 한 팀에는 이러한 시나리오가 여러 개 존재합니다.

다음은 제품 팀의 전형적인 역할 목록과 각 역할에서 비용을 증가시키는 요인들입니다:

• 1차 지원용 GPT-4o 지원 봇: 높은 빈도, 짧은 응답, 그러나 점진적으로 증가하는 대화 컨텍스트(Context).
• 랜딩 페이지용 GPT-4o 챗봇 (요청 시 이 역할은 종종 "GPT 사이트 챗봇"으로 불림): 트래픽 피크(Peak), 많은 수의 짧은 세션, 환영 메시지 캐싱(Cache) 시 저렴한 진입 비용.
• 내부 요청용 GPT Telegram 봇: 중간 빈도, 컨텍스트 내 대화 내용의 긴 인용문.
• CRM 보조 GPT 봇: 빈도는 낮지만, 큰 시스템 프롬프트(System Prompt)를 포함하는 무거운 요청(이 경우 캐싱이 비용을 상쇄함).
• 도구 사용 GPT 에이전트 봇: 단일 사용자 요청이 모델 호출(Model Call)의 여러 단계 체인(Chain)을 생성함.
• 아이디어 및 일러스트 생성 GPT 에이전트: 텍스트 브리프(Brief)와 GPT Image 2 API와 같은 이미지 모델 호출의 결합 — 디자이너들의 요청에서는 상품 카드를 위해 "사진으로 그림을 그리는 온라인 GPT API"와 같은 형태로 나타남.
• GPT-4 mini-TTS를 통한 응답 음성 변환: 텍스트 토큰 예산에 포함되지 않고 별도로 계산되는 별도의 문자 스트림(Stream).

여기서 비대칭성(Asymmetry)에 주목하십시오. 도구를 사용하는 에이전트는 동일한 사용자 수임에도 불구하고 한 번의 요청에 대해 여러 번의 통과(Pass) 비용을 지불하는 반면, CRM 보조 봇은 매 요청마다 거대하고 변하지 않는 시스템 프롬프트(System Prompt)에 대한 비용을 지불합니다. 모델의 이름표보다 역할(Role)이 더 중요하며, 동일한 GPT-4o를 사용하더라도 두 시나리오 간의 청구 금액 차이는 몇 배에 달할 수 있습니다.

역할(Role)은 머릿속에서 임의로 만들어지는 것이 아니라, 이미 테크 리드(Tech Lead)에게 전달된 작업 큐(Task Queue)에서 가져옵니다. 기존 지원 스크립트 대신 gpt 3 챗봇을 도입해 달라는 요청 또한 하나의 역할을 설명하지만, 이는 매우 초기 단계의 역할입니다. 빈도(Frequency)와 컨텍스트(Context)가 아직 정의되지 않았기 때문에, 이는 예산안(Estimate)이 아닌 보류(Deferred) 항목으로 즉시 분류됩니다. 디자이너들은 gpt image 2를 별도의 독립적인 액세스로 구매해 달라고 따로 요청하기도 하지만, 전체 모델 부하 관점에서는 입력값의 역할만 다를 뿐 동일한 이미지 생성 라인(Image line)입니다. 각 역할 후보에게는 정확히 두 가지 필수 필드가 있습니다: 부하 승수(Load Multipliers)와 확인된 가격(Confirmed Price)입니다. 승수가 없으면 역할은 아예 고려되지 않습니다. 가격이 없으면 역할은 'gpt-4o와 대략 비슷할 것'이라는 낙관적인 계산이 아닌 보류 항목으로 넘어갑니다.

Python을 이용한 범위 계산기

OpenAI에는 "하루에 X개의 요청을 처리하는 N명의 팀은 얼마가 든다"와 같은 공식적인 표가 없습니다. 따라서 토큰당 확인된 가격을 바탕으로 직접 계산기를 구축해야 하며, 이 계산기는 단일 지점이 아닌, 절약형 시나리오부터 비관적 시나리오까지의 범위를 출력해야 합니다. 아래는 간결한 gpt api python 초안입니다: 가격 딕셔너리(Dictionary), 단일 역할 비용 함수, 그리고 반복을 고려한 합계 계산입니다.

from openai import OpenAI

client = OpenAI(
...

호출 시 사용되는 모든 숫자들, 즉 req_per_day(일일 요청 수), ctx_in(입력 컨텍스트), cached_share(캐시 공유 비율), resp_out(출력 응답), retries(재시도 횟수)는 측정된 사실이 아니라 가정(Assumption)입니다. PRICES 딕셔너리에 있는 가격은 특정 날짜 기준의 외부 확인 사실입니다. low(최저)와 high(최고) 사이의 범위는 이러한 가정들로부터 도출된 파생 결과입니다. 이 세 가지 계층을 혼동해서는 안 됩니다. 가정이 사실로 둔갑하는 순간, 예산안은 아주 확신에 찬 얼굴로 거짓말을 하게 됩니다.

승수 (1 + retries)는 코드 형태의 검증 가능한 가설입니다: 재시도와 컨텍스트 증가가 개별 모델의 가격표보다 전체 비용에 더 큰 영향을 미칩니다. OpenAI의 사실 기반 캐시 메커니즘이 이를 뒷받침하지만, 팀이 재시도 횟수에 대한 정확한 측정값을 가지고 있는 경우는 드뭅니다. 따라서 이를 직접 대입하고 정직하게 가정(Assumption)이라고 표시해야 합니다.

토큰, 키, 그리고 한도(Limits)가 비용 산정에 미치는 영향

토큰(Token), 키(Key), 한도(Limit)는 서로 다른 개념임에도 불구하고 구매 시 종종 하나로 묶여 취급되곤 합니다. GPT API 토큰은 텍스트 과금의 단위이며, 위 표의 모든 계산은 이를 기준으로 이루어집니다. 별도의 GPT API 키는 단순히 접근을 위해 필요할 뿐 그 자체로 가격을 변화시키지는 않습니다. 개발자들은 모델의 공식 가격표가 확정되기 전에도 테스트를 위해 키 생성을 요청하곤 합니다. 키는 오늘 발행할 수 있지만, 예산 항목에 반영되는 모델 가격은 공지사항이 아닌 모델 상세 페이지에 가격이 표시될 때 비로소 확정됩니다. 한도(Limit)는 처리량(Throughput)의 상한선이며, 세 번째 독립 변수입니다.

한도와 관련하여 팀이 트래픽 증가 전에 반드시 고려해야 할 확인된 사실이 있습니다. 2026년 7월 18일 기준 OpenAI 문서에 따르면, Free부터 Tier 5까지의 사용 수준은 누적 결제 금액에 따라 한도가 제한(Gating)됩니다. Free 및 Tier 1의 경우 월 최대 $100에서, 총 결제 금액이 $1,000를 넘어서면 열리는 Tier 5의 경우 월 최대 $200,000까지 확장됩니다. RPM(분당 요청 수), TPM(분당 토큰 수), RPD(일일 요청 수), TPD(일일 토큰 수) 한도는 특정 개발자가 아닌 조직(Organization) 또는 프로젝트 단위로 적용됩니다. 성장하는 팀에게 이는 트래픽 피크 시점에 비용이 문제가 아니라 처리량(Throughput)에 부딪히게 된다는 것을 의미하며, 이는 요청 비용과는 별개의 리스크 항목으로 예산안에 포함되어야 합니다.

여기서 GPT API의 균형을 찾는 이들을 위한 실질적인 결론이 도출됩니다. 처리량과 토큰당 가격은 서로 다른 축이며, 하나를 통해 다른 하나를 유도할 수 없습니다. TPM 한도에 걸려버린 저렴한 모델은 트래픽의 일부가 통과하지 못하기 때문에 팀에게 예상보다 더 큰 비용을 초래합니다. 만약 기존 예산안이 여전히 GPT 3.5 Turbo API를 기준으로 작성되어 있거나, 여전히 GPT 3.5 Turbo API 키라고 불리고 있다면 가격을 다시 산정해야 합니다. 제가 2026년 7월 18일에 확인한 모델 페이지에는 이 모델이 존재하지 않으므로, 예산안의 수치는 이미 유효하지 않을 수 있습니다.

팀들이 버전 선택에서 돈을 낭비하는 지점

가장 비싼 실수는 3개월 뒤에 중단될 모델의 가격을 연간 예산에 책정하는 것입니다. snapshot 상의 gpt-4-0613 및 gpt-4-turbo 기반 GPT-4 API는 이 계산 날짜로부터 약 3개월 후인 2026년 10월 23일에 중단될 예정임이 확인되었습니다. 이는 고정된 수치를 사용할 것이 아니라, "중단 전 재확인"이라는 명확한 표시를 남기고 gpt 5.5 API로의 계획된 마이그레이션 (migration)을 준비해야 하는 이유입니다.

두 번째 함정은 환경 (contours)의 혼동입니다. 2026년 2월 13일, OpenAI는 ChatGPT 인터페이스에서 GPT-4o, GPT-4.1, GPT-4.1 mini 및 o4-mini를 제거했지만, 자체 발표에서는 "현재 API에는 변경 사항이 없다"라고 명시했습니다. ChatGPT 측의 리타이어먼트 (retirement)가 팀의 API 예산에는 영향을 주지 않지만, 이 두 환경은 끊임없이 혼동됩니다. 어떤 이들은 이로 인해 조기에 불안해하고, 어떤 이들은 경계가 필요한 시점에 방심하게 됩니다.

확인된 가격보다 빠르게 성장하는 카탈로그

현재 GPT API 모델 (gpt api models) 카탈로그를 열어보면, 라인업은 어제와 이미 달라져 있으며 그 모든 것이 이 글의 검증된 출처에 포함되어 있지는 않습니다.

개발자들은 이미 GPT 5 API에 대해 문의하고 있으며, 동시에 테스트를 위한 GPT 5 API 키 (gpt 5 api key)를 생성하고 있습니다. 여기서 액세스 (access)와 가격은 별개의 문제이며, 예산에는 모델 페이지에서 확인된 내용만 포함됩니다.

매우 좁은 목적의 작업을 위해 카탈로그에는 gpt-4.1 nano 및 gpt 5.4 mini API와 같은 소형 옵션들이 등장합니다. gpt-4o mini와 동일한 논리로, 특정 시나리오에 맞춘 최소한의 가격을 제공하지만, 2026년 7월 18일 기준 출처에 자체적인 확인 항목이 없으므로 이들은 예산 항목이 아닌 후보군으로 남아 있습니다.

반대편에는 티켓(tickets) 상에서 이미 플래그십의 후계자로 불리는 gpt 5.4 API 및 gpt 5.5 pro API가 있습니다. 연간 예산에 gpt 5.5 API 가격 (gpt 5.5 api price)을 책정하기 전에, 계산 당일에 이를 다시 확인해야 합니다. 이 글이 근거로 삼는 검증된 모델 페이지에는 아직 해당 모델이 존재하지 않습니다.

표기법상의 별도 혼란: 개발자에게 chatgpt 5 api와 chat gpt 5 api는 모델에 대한 동일한 호출을 의미하지만, 티켓 트래커(ticket-tracker)에서는 이 두 가지가 서로 다른 검색어이며, 두 경우 모두 gpt 5 api라는 상위 명칭과 마찬가지로 동일한 가격 확인 절차가 필요합니다.