화요일에 재미있는 발표가 나온다길래 기다렸는데, 먼저 나온 것이 긴 사용량 정책 설명이라면 기분이 묘하다.
2026년 9월 29일 Tibo의 게시물 핵심은 이렇다. 월 200달러 Pro 신규 가입을 다음 날 다시 열지만, 새 계산 방식에서는 예전 월 200달러 Pro와 비교해 API 비용 환산 기준 사용 가치가 절반 수준이 된다는 설명이었다.[1]
불꽃놀이를 기다렸는데 먼저 요금표 개정 안내가 날아온 셈이다.
다만 "모든 모델을 정확히 절반만 쓸 수 있다"는 뜻은 아니다. 같은 주 OpenAI는 GPT-6 Sol과 Luna의 API 가격을 GPT-5.6 프로모션 가격 대비 50% 낮췄다고 발표했다.[2][3]
운영사 논리는 명확하다.
API 달러 환산 한도는 줄이되 모델 비용도 낮춰, 실제로 완료할 수 있는 일은 더 늘리겠다.
문제는 사용자가 API 달러를 사는 것이 아니라 완료된 일을 산다는 점이다.
1. 정확히 무엇이 절반인가
Tibo의 게시물은 9월 30일 Pro $200 신규 가입을 재개하며, 새 usage 계산을 적용하면 이전 플랜의 API spend 기준 절반 수준이 된다고 설명했다.[1]
동시에 5시간 제한은 다시 도입하지 않고, 주간 사용량을 원하는 시점에 쓸 수 있게 하며, 모델 효율 개선과 API 가격 인하를 구독 가치에 반영하겠다고 했다. 사용량을 차감하지 않는 추가 기능도 예고했다.[1]
9월 22일 발표된 GPT-6 Sol과 Luna는 공식적으로 GPT-5.6 프로모션 가격 대비 API 가격이 50% 낮다.[2] 최신 공식 가격표에서도 현행 가격을 확인할 수 있다.[3]
수학만 보면 단순하다.
이전 사용 예산을 B, 한 작업의 API 환산 비용을 C라고 하자. 처리량은 B/C다.
새 예산이 0.5B가 되고 같은 작업의 비용도 0.5C가 되면,
0.5B ÷ 0.5C = B ÷ C
이므로 이론상 처리량은 같다.
하지만 실제 AI 작업은 균일하지 않다.
2. 사용자는 달러가 아니라 완료된 작업 수를 본다
짧은 질문 100개와 거대한 코드베이스 수정 1건은 같은 "요청"이 아니다.
긴 문맥, 깊은 추론, 도구 호출, 테스트, 재시도, 에이전트 반복은 한 작업의 소비량을 크게 만든다.
그래서 헤비 유저에게 중요한 질문은 "메시지를 보낼 수 있나?"가 아니다.
이번 주에 큰 작업을 몇 개 끝까지 끝낼 수 있나?
결국 구독의 실용 가치는 메시지 수보다
완료 작업 수 ÷ 월 구독료
에 가깝다.
아무리 똑똑한 모델이라도 작업 중간에 연료가 끊기면 완성된 결과물은 나오지 않는다.
3. "Opus의 100분의 1 같다"는 측정값은 아니지만 불만의 구조는 현실적이다
긴 에이전트 작업을 돌리면 서비스별 한도 차이가 극단적으로 느껴질 수 있다.
한쪽에서는 긴 작업을 여러 개 연속으로 돌릴 수 있는데, 다른 쪽에서는 큰 작업 하나만 넣어도 탱크가 거의 비는 느낌이 들 수 있다.
"100분의 1 같다"는 표현은 당연히 정식 벤치마크가 아니다. 작업, 플랜, 모델, 문맥 길이에 따라 달라진다.
그러나 핵심은 숫자가 아니라 작업 단위와 한도 단위가 맞는가이다.
5분짜리 작업이라면 작은 한도도 쪼개 쓰면 된다.
30분, 1시간, 여러 번의 수정과 테스트가 필요한 작업이라면 중간에 끊기는 순간 비용이 훨씬 커진다.
그래서 모델 가치는 최고 성능만으로 판단할 수 없다.
- 한 작업을 끝까지 통과할 수 있는가
- 실패 후 이어서 할 수 있는가
- 일주일에 몇 건 완료되는가
- 다른 모델로 바꿔도 시스템이 유지되는가
까지 봐야 한다.
4. 지금은 AI를 소비할 때보다 설비를 만들 때다
현재의 고성능 AI 구독이 앞으로 비싸질지, 싸질지, 한도가 바뀔지는 알 수 없다.
확실한 것은 이용 조건이 고정되어 있지 않다는 사실뿐이다.
그래서 저렴한 추론을 가장 아깝게 쓰는 방법은 유용한 대화를 수천 번 하고 결과를 채팅 기록에만 남기는 것이다.
더 강한 방법은 오늘의 추론으로 내일 필요한 추론을 줄이는 구조를 만드는 것이다.
- 반복 조사 자동화
- 반복 설명을 명시적 규칙과 계약으로 저장
- 사람 눈검사를 테스트와 평가기로 전환
- 거대한 한 번짜리 작업을 재개 가능한 단계로 분할
- 결과와 근거, 상태를 파일·DB·버전 관리에 저장
- 특정 모델 이름을 핵심 로직에 박지 않고 얇은 연결 계층을 둠
- 작업 유형별 모델 성공률을 기록
한 줄로 말하면 이렇다.
AI를 빌릴 수 있을 때, 그 AI가 비싸져도 돌아가는 공장을 만든다.
5. 사라지는 소비와 남는 자산을 구분한다
같은 10시간의 AI 사용도 결과는 다르다.
| 사라지는 사용 | 남는 자산 |
|---|---|
| 매번 같은 배경 설명 | 작업 명세와 규칙 파일 |
| 매번 모델에게 수동 검사 요청 | 자동 테스트와 평가기 |
| 거대한 단발 프롬프트 | 체크포인트가 있는 단계 |
| 답을 읽고 종료 | 결과물·근거·상태 저장 |
| 모든 일에 최고급 모델 | 저렴한 모델 우선, 필요할 때 승격 |
| 한 업체 전용 마법 프롬프트 | 공통 작업 계약 + 얇은 어댑터 |
| 한도에 닿으면 정지 | 재시도·재개·인계 |
연구에서도 모델을 작업별로 선택하는 방식이 비용 효율적일 수 있다는 결과가 있다.
FrugalGPT는 질의별로 모델을 선택하는 cascade를 통해 평가된 작업에서 최고 단일 모델에 가까운 성능을 유지하며 비용을 크게 줄일 수 있음을 보였다.[4]
2026년의 비용 인식 라우팅 연구도 저비용 모델을 먼저 쓰고 품질이 부족한 경우에만 강한 모델로 올리는 구조로, 최강 모델 정확도의 97~99%를 유지했다고 보고했다.[5]
6. 공급업체를 바꿀 수 있는 최소 구조
거창한 멀티클라우드가 필요한 것은 아니다.
다음 여섯 가지를 분리하면 된다.
- 작업 명세 — 입력, 출력, 완료 기준을 모델 이름 없이 정의한다.
- 공급업체 어댑터 — 서비스별 API 차이를 한곳에 모은다.
- 상태 저장 — 어디까지 끝났는지 기록한다.
- 결과물 저장 — 코드, 문서, 근거를 대화 밖에 둔다.
- 평가기 — "완료"라는 모델의 말을 테스트한다.
- 라우터 — 가장 저렴하게 충분한 모델부터 시작하고 필요할 때만 상위 모델로 올린다.
Microsoft의 Well-Architected 지침도 긴밀한 의존성을 줄이고 도메인 로직을 인프라 고유 기능과 분리하라고 권장한다.[6]
AI에서도 같은 원칙이 통한다.
7. 값싼 고성능 모델에게 지금 시킬 일
강한 모델이 저렴할 때 가장 가치 있는 일은 세션이 끝난 뒤에도 계속 가치를 만드는 것이다.
- 반복 조사·정리·테스트·배포·집계를 자동화한다.
- retry, resume, checkpoint, 중복 방지를 넣는다.
- "좋게 만들어줘"를 테스트 가능한 품질 기준으로 바꾼다.
- 작업 종류, 모델, 성공률, 재시도, 시간, 사용량을 기록한다.
- 나중에 공급업체를 바꿀 수 있는 입구를 만든다.
그러면 가격 변경은 재구축이 아니라 라우팅 조정이 된다.
8. 오래 못 가는 최적화
"주어진 한도를 전부 써야 이득"이라는 생각은 위험하다. 사용량은 성과가 아니다.
거대한 단발 작업에 지나치게 의존하는 것도 위험하다. 한도 변경과 장애에 취약하다.
특정 모델에서만 통하는 비밀 주문을 쌓는 것도 결국 잠금 효과를 만든다.
그리고 "어느 회사는 반드시 가격을 올릴 것" 같은 예측을 전제로 설계할 필요도 없다.
미래를 맞히는 것보다, 틀려도 괜찮은 시스템을 만드는 편이 낫다.
9. 결론 — 구독 혜택은 날씨이고 시스템은 집이다
월 200달러 플랜의 사용 경제가 바뀌면 짜증이 날 수 있다.
다른 서비스에서는 훨씬 더 많은 실제 일을 할 수 있다고 느낄 수도 있다.
하지만 생산성이 오늘의 요금표에 붙어 있으면, 공급업체의 발표 하나가 매번 운영 장애가 된다.
더 강한 전략은 지금의 저렴한 지능을 영구 자산으로 바꾸는 것이다.
코드, 테스트, 평가 기준, 데이터, 자동화, 재개 가능한 작업 흐름, 교체 가능한 모델 연결부.
오늘의 최고 모델을 영원한 전제로 두지 않는다.
오늘의 싼 가격도 영원한 전제로 두지 않는다.
저렴할 때, 저렴한 시기가 끝나도 괜찮은 구조를 만든다.
그것이 가장 오래 남는다.
- Tibo (@thsottiaux), X post, 2026-09-29, announcing the 2026-09-30 reopening of Pro $200 and the new usage calculation x.com
- OpenAI, “Introducing GPT-6 Sol and Luna”, 2026-09-22 openai.com
- OpenAI API, “Pricing”, checked 2026-09-29 developers.openai.com
- Chen, Lingjiao; Zaharia, Matei; Zou, James, “FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance”, Transactions on Machine Learning Research, 2024 openreview.net
- Moslem, Yasmin et al., “Cluster, Route, Escalate: Cascaded Framework for Cost-Aware LLM Serving”, arXiv, 2026 arxiv.org
- Microsoft Azure Well-Architected Framework, guidance on reducing tightly coupled dependencies and separating domain logic from infrastructure concerns, checked 2026-09-29 learn.microsoft.com
