GPT 6.1 Sol Ultrafast를 어디에 써야 비용이 맞을까

대기시간에 민감한 AI 기능을 위한 새 선택지다. API 설정 한 줄보다 어떤 요청에 적용하고 절약한 시간을 어떻게 측정하느냐가 중요하다.

개정 1판 · 최근 고침: Ultrafast의 API 설정과 가격, 외부 소규모 비교, 작업 단위 평가 및 연결 복구 안내를 새로 작성했습니다. · 고침 기록 보기

API 기준의 공식 설정·가격, 외부 매체 자체 실험과 마탑의 미실행 적용 제안을 구분합니다. 코드 실행이나 유료 API 호출을 통한 자체 성능 측정은 하지 않았습니다.

사용자가 기다리는 단계부터 구분하기

코딩 도우미에게 함수를 고쳐 달라고 한 뒤 커서를 바라보는 시간과, 퇴근 후 자동으로 돌아가는 코드 점검 시간은 가치가 다르다. 결과가 같은 시각까지 나오기만 하면 되는 작업도 있고 몇 초만 줄어도 작업 흐름이 훨씬 편해지는 기능도 있다. AI 서비스의 속도 옵션을 고를 때 이 차이를 먼저 생각하면 판단이 쉬워진다.

OpenAI는 2026년 10월 8일 GPT-6.1 Sol에 Ultrafast 서비스 등급을 추가했다. Responses API에서 요청별로 선택할 수 있으며 출력 토큰 사이의 시간을 줄이는 데 초점을 둔다. 모델 ID는 그대로 두고 실행 등급을 바꾸는 방식이다. 공식 API 변경 기록에 따르면 모든 API 사용자가 이용할 수 있고 별도의 사용량 제한이 적용된다.

개발팀 입장에서는 선택지가 하나 늘었다. 사람이 바로 다음 행동을 하려고 기다리는 단계에는 빠른 실행을, 마감까지 여유가 있는 작업에는 비용을 우선하는 실행을 배치할 수 있다. 다만 Ultrafast 단가는 Standard의 여섯 배다. 무조건 기본값으로 켜기 전에 실제 서비스에서 어느 구간이 느린지부터 살펴볼 필요가 있다.

이 절의 근거 S147

무엇을 바꾸는 옵션인가

GPT-6.1 Sol은 코딩, 컴퓨터 사용, 전문 업무를 위한 모델이다. 모델 문서는 추론 노력 설정으로 low, medium, high, xhigh, max를 제공하며 기본값은 medium이라고 설명한다. 서비스 등급과 추론 노력은 서로 다른 설정이다. 더 빨리 답을 받으려는 실험에서 두 값을 동시에 바꾸면, 속도 차이가 실행 등급에서 왔는지 사고량에서 왔는지 구분하기 어렵다.

첫 비교에서는 모델, 입력, 추론 노력, 도구, 출력 요구사항을 고정하는 편이 좋다. 그래야 비용이 늘어난 만큼 기다리는 시간이 줄었는지 볼 수 있다. 이후에 작업별로 추론 노력을 조절하면 된다. 예컨대 복잡한 결제 로직을 수정하는 작업과 짧은 UI 문구를 고치는 작업에 똑같은 설정을 고집할 이유는 없다.

Ultrafast 가이드가 제시하는 설정은 간단하다. model을 gpt-6.1-sol로, service_tier를 ultrafast로 지정한다. HTTP와 WebSocket을 모두 지원하지만 도구를 연달아 호출하는 에이전트에는 WebSocket을 권장한다. GPT-6.1 Sol의 Ultrafast는 글로벌 처리뿐 아니라 미국·EU 데이터 레지던시도 지원한다. 실제 이용 자격과 조직의 데이터 정책은 별도로 확인해야 한다.

이 글의 가격과 예제는 API 기준이다. ChatGPT나 Codex 구독에서 보이는 속도 메뉴와 사용량 차감을 그대로 API 비용으로 환산하면 계산이 어긋난다.

이 절의 근거 S149 · S148

단가는 여섯 배이고 청구액은 사용한 토큰에 달려 있다

2026년 10월 10일 한국시간 아침 확인한 공식 가격표의 짧은 컨텍스트 단가는 다음과 같다. 금액은 미국 달러이며 100만 토큰 기준이다.

긴 컨텍스트에는 다른 단가가 적용된다. Ultrafast의 긴 컨텍스트 단가는 일반 입력 $24, 캐시 읽기 $1.20, 캐시 쓰기 $30, 출력 $90이다. 긴 문서를 다루는 서비스라면 짧은 컨텍스트 숫자만 예산표에 넣어서는 안 된다. 지역 처리와 FedRAMP 엔드포인트의 할증 조건도 가격표에 따로 적혀 있다.

간단한 가상 계산을 해보자. 한 요청이 캐시 없이 일반 입력 1만 토큰과 청구 대상 출력 2천 토큰을 사용한다고 가정하면 Standard는 $0.04, Fast는 $0.08, Ultrafast는 $0.24다. 캐시 쓰기와 도구 비용, 세금 등을 뺀 산술 예시다. 하루 1만 건을 모두 Ultrafast로 바꾼다면 같은 토큰 수 기준으로 Standard보다 하루 $2,000이 더 든다. 반대로 사용자가 기다리는 5%에만 적용한다면 이 예시의 추가 비용은 $100이다.

여기서 ‘출력’은 화면에 보이는 글자만 세는 개념이 아니다. 추론 모델 문서는 추론 토큰도 출력 토큰으로 과금된다고 설명한다. 답변이 짧아 보여도 내부 추론량에 따라 청구액이 달라질 수 있다. 결과 문자열의 길이 대신 API가 돌려주는 usage를 기록해야 하는 이유다.

이 절의 근거 S150 · S153

작은 공개 실험에서는 어떤 차이가 났나

독립 매체 Not an AI App의 Marvin Smit는 10월 9일 직접 진행한 API 비교를 공개했다. 세 가지 짧은 코딩 과제를 각 등급에서 세 번씩 실행한 총 27회 실험이다. 작성자가 보고한 작업 시간 중앙값은 Standard 22.0초, Fast 15.1초, Ultrafast 5.7초였고 세 설정 모두 준비한 테스트를 통과했다. 평균 요청 비용은 각각 1.25센트, 2.37센트, 7.77센트였다.

이 사례는 공급자 발표와 별개로, 비용과 시간을 함께 기록한 소규모 관찰이라는 점에서 참고할 만하다. 다만 과제가 세 개이고 비공개 테스트를 사용했다. 대형 저장소를 탐색하거나 외부 서비스를 여러 번 호출하는 에이전트도 같은 비율로 빨라진다고 일반화하기는 어렵다. 이 기사가 전달하는 숫자는 해당 매체의 보고값이며 마탑 자체 벤치마크가 아니다.

실무에서는 ‘몇 배 빠르다’는 하나의 숫자보다 서비스의 기다림을 잘라 보는 편이 유용하다. 사용자가 무엇을 기다리는지에 맞춰 지표를 선택해야 한다. 첫 문장이 표시되기까지 걸린 시간, 답변이 끝날 때까지 걸린 시간, 테스트까지 통과한 최종 결과가 나오기까지 걸린 시간은 서로 다른 지표다.

이 절의 근거 S156

우선 한 요청으로 설정을 확인한다

아래는 설정과 기록 항목을 확인하기 위한 Python 예제다. API 키는 서버 환경변수로 준비하고 최신 OpenAI SDK가 설치된 환경에서 사용한다. 실행하면 API 비용이 발생한다. 결과 시간 자체를 벤치마크로 제시하는 코드는 아니다.

from time import perf_counter
from openai import OpenAI

client = OpenAI()

started = perf_counter()
response = client.responses.create(
    model="gpt-6.1-sol",
    service_tier="ultrafast",
    reasoning={"effort": "medium"},
    input="Python에서 빈 목록의 평균을 구할 때 발생할 문제와 수정안을 짧게 설명해줘.",
)

print(response.output_text)
print("elapsed_seconds:", round(perf_counter() - started, 3))
print("served_tier:", response.service_tier)
print("usage:", response.usage)

설정 확인 뒤에는 운영 기록도 준비한다

처음에는 민감한 실제 고객 데이터보다 검토하기 쉬운 테스트 입력을 쓰는 편이 낫다. 응답이 정상적으로 오는지, 기대한 서비스 등급이 기록되는지, 출력과 추론 토큰이 얼마나 사용됐는지를 확인한다. 같은 입력을 한 번만 더 실행해 우열을 정하기보다는 대표 과제를 묶어 반복 측정할 준비를 하는 단계다.

운영 코드에서는 타임아웃, 오류 기록, 호출량 상한도 함께 둬야 한다. 특히 재시도가 붙으면 성공한 요청 한 건의 비용과 전체 작업 비용이 달라진다. OpenAI의 운영 가이드도 사용량과 비용을 감시하고 보안·확장 조건을 별도로 설계하도록 안내한다. 키를 프런트엔드에 넣거나 저장소에 커밋하지 않는 기본 원칙은 속도 설정과 관계없이 그대로 적용된다.

이 절의 근거 S155

도구를 여러 번 부른다면 연결 방식도 확인한다

에이전트가 파일을 읽고 코드를 수정하고 테스트 결과를 다시 모델에 넘기는 과정에서는 왕복 요청이 반복된다. 모델의 출력만 빨라져도 도움이 되지만 매번 연결과 맥락 전달에 드는 시간이 크면 전체 개선폭은 작아질 수 있다.

Responses API의 WebSocket 문서는 하나의 지속 연결에서 이전 response ID와 새 입력만 보내는 방식을 설명한다. 구현은 다음 순서로 이해하면 된다.

연결은 최대 60분 유지되므로 재연결 설계도 필요하다. 저장하지 않은 응답이나 ZDR 환경에서 이전 응답을 찾지 못하면 전체 입력 맥락을 다시 보내는 복구 경로를 준비해야 한다. 연결이 끊겼다고 앞서 실행한 외부 작업까지 무조건 반복해서는 안 된다. 주문 생성이나 메시지 전송처럼 중복 실행에 부작용이 있는 도구는 작업 ID로 결과를 확인한 뒤 이어가는 구조가 안전하다.

WebSocket 연결의 재사용과 프롬프트 캐시는 구분해서 관리하는 것이 좋다. 프롬프트 캐싱 문서에 따르면 캐시는 동일한 앞부분의 계산을 재사용한다. 고정 지침과 공통 자료는 안정적으로 유지하고 계속 달라지는 내용은 뒤쪽에 두는 설계가 도움이 된다. 캐시 경계와 쓰기 비용을 포함해 실제 사용량을 확인해야 한다. 다만 같은 문장이 반복된다는 이유만으로 캐시 적중을 가정해서는 안 된다.

이 절의 근거 S151 · S152

도입 여부는 완료된 작업 한 건으로 비교한다

다음은 마탑이 제안하는 적용 순서다. 제공업체의 성능 보장이나 특정 숫자를 재현하는 시험 규격은 아니다. 팀이 현재 가진 로그와 대표 업무로 작은 비교를 시작할 때 사용할 수 있다.

첫째, 대기시간이 불편한 작업을 구체적으로 고른다. ‘코딩 전반’보다 ‘사용자가 선택한 함수의 수정안 생성’, ‘고객 상담 중 답변 초안 작성’처럼 시작과 끝이 분명한 단위가 좋다. 품질 기준도 함께 적는다. 빠르게 나왔지만 사람이 대부분 다시 고쳐야 하는 결과는 절약으로 계산하기 어렵다.

둘째, 같은 작업 묶음을 Standard와 Fast, Ultrafast에 배정한다. 실행 순서를 섞고 입력과 추론 노력은 같게 맞춘다. 캐시가 준비된 경우와 처음 호출한 경우도 나눠 기록한다. 이 구분이 없으면 뒤에 실행한 설정이 우연히 더 유리할 수 있다.

셋째, 중앙값과 느린 요청의 분포를 함께 본다. 평균만 좋아지고 일부 요청이 오래 걸린다면 사용자 불만은 남을 수 있다. 전체 완료시간, 실패율, 재시도 횟수, 토큰 사용량, 최종 통과율을 한 작업 ID로 묶어 두면 원인을 찾기 쉬워진다.

넷째, 실제 비용을 성공 건수로 나눈다. 정답을 얻기 위해 두 번 호출한 작업은 두 번의 비용이 들어간다. 비교 표에는 ‘성공한 한 건의 비용’과 ‘추가로 지불한 금액당 절약한 시간’을 넣자. 품질이 허용 범위 안에 있는지 확인한 뒤에야 이 숫자가 의미를 갖는다.

마지막으로, 먼저 일부 트래픽에 적용한다. 모든 기능의 기본값을 한 번에 바꾸면 비용 변화의 원인을 좁히기 어렵다. 사용자 대기시간이 길고 업무 가치가 높은 단계부터 적용한 뒤, 지출과 오류율을 보면서 범위를 넓히면 된다.

어떤 작업에 우선 배치하면 좋을까

표의 마지막 두 항목은 특히 중요하다. 지연시간 최적화 가이드는 출력량, 요청 횟수, 병렬 처리, 스트리밍 등을 함께 다룬다. 사용자에게 필요 없는 긴 설명을 줄이거나 독립 작업을 동시에 실행하는 것만으로도 기다림을 줄일 여지가 있다. 결과를 조금씩 표시하면 실제 완료시간이 같아도 사용자가 상황을 이해하기 쉬워진다.

가령 전체 작업의 상당 부분이 재고 API 응답을 기다리는 시간이라면 모델 등급을 바꾼 뒤에도 체감은 제한적일 수 있다. 이때는 재고 조회를 중복 호출하는지, 필요한 조회를 동시에 실행할 수 있는지부터 살펴보자. 반대로 모델이 긴 코드를 생성하는 시간이 대부분이라면 빠른 출력 등급이 더 직접적인 선택지가 된다.

이 절의 근거 S154

결론

GPT-6.1 Sol Ultrafast는 대기시간이 중요한 제품 기능에 쓸 수 있는 유료 선택지다. 시작은 설정 한 줄이지만 도입 판단에는 품질, 전체 완료시간, 캐시, 재시도, 호출량이 함께 들어간다.

추천하는 첫 단계는 간단하다. 팀에서 가장 답답한 작업 하나를 골라 세 등급을 같은 조건으로 비교하고 성공한 결과 한 건당 비용을 계산해 보자. 절약한 시간이 사용자와 팀에 충분히 가치가 있을 때 그 구간에 적용하면 된다. 이 과정을 거치면 ‘가장 빠른 옵션’이라는 설명을 실제 서비스의 지출 결정으로 바꿀 수 있다.