Ultrafast를 켜기 전에, 에이전트의 100초를 쪼개 보자

에이전트가 코드를 고치고 테스트 결과를 가져오는 데 100초가 걸린다고 하자. 더 빠른 모델 처리 등급을 선택하면 이 대기 시간도 같은 비율로 줄어들까? 답을 찾으려면 먼저 그 100초 중 모델이 토큰을 만드는 시간이 얼마인지 알아야 한다.

OpenAI는 9월 29일자 DevDay 발표에서 Astra Ultrafast의 API 토큰 생성 속도를 최대 6배로 소개했다. API 변경 기록이 규정한 변화는 생성되는 출력 토큰 사이의 간격을 줄이는 것이다. 검색, 테스트, 검증까지 끝내는 시간이 6분의 1이 된다는 발표는 아니다.

선택 방법은 gpt-6-astra 요청에 service_tier="ultrafast"를 지정하는 것이다. 공식 사용 가이드상 API 사용자에게 열려 있지만 별도 처리량 제한이 있다. 지원 범위는 글로벌 처리와 미국 데이터 레지던시이며, EU 등 비미국 리전 처리 엔드포인트는 제외된다. 사용자의 국적이나 거주지가 아니라 요청의 데이터 처리 경로에 관한 조건이다.

다만 현재 API 가이드 상단에는 Standard 대비 최대 8배로 적혀 있다. 9월 29일 발표의 API 6배와 다른데, 확인한 문서에는 차이를 설명할 측정 조건이 없다. 아래에서는 6배를 계산 가정으로만 쓴다.

빨라지는 구간이 짧으면, 전체 대기도 조금만 줄어든다

요청을 보내고, 입력을 처리하고, 출력을 생성하고, 도구의 결과를 기다리는 시간은 서로 다른 비용이다. OpenAI의 지연 최적화 가이드도 토큰 처리, 요청 왕복, 병렬 실행을 별개의 개선 수단으로 다룬다. 첫 토큰이 도착하는 시간과 필요한 결과가 완성되는 시간 역시 구분해야 한다.

모든 단계가 순서대로 진행되는 단순한 작업을 생각해 보자. 총 100초 중 토큰 생성이 60초라면, 그 구간만 6배 빨라졌을 때 생성은 10초가 된다. 그대로 남는 40초를 더하면 완료 시간은 50초다. 생성이 원래 10초뿐이었다면? 90초는 그대로이고 생성만 약 1.7초가 되어, 총 91.7초가 걸린다.

계산식은 ‘기존 생성 시간 ÷ 가속 배수 + 나머지 시간’이다. 다만 여러 에이전트나 도구가 동시에 움직이면 실행 시간을 모두 더해서는 안 된다. 최종 결과가 기다려야 하는 가장 늦은 의존 경로, 즉 임계 경로를 봐야 한다. 다른 긴 작업이 끝나기를 기다리는 동안 이미 마친 분기를 더 빨리 처리해도 최종 완료 시각은 달라지지 않을 수 있다.

그래서 실제 도입 판단에는 출력 토큰 속도와 함께 ‘필요한 검증까지 끝난 시각’이 필요하다. 위 계산은 작업량을 고정한 설명일 뿐이다. 실제 실행에서는 출력 길이, 도구 선택, 재시도 횟수도 달라질 수 있으므로 완료 시간과 결과 품질을 함께 비교해야 한다.

연결을 유지하는 일과 입력을 다시 계산하지 않는 일

도구를 여러 번 호출하는 에이전트는 생성과 도구 실행 사이를 계속 왕복한다. 이 때문에 Ultrafast 가이드는 HTTP도 지원하면서, 잦은 도구 호출에는 지속적인 WebSocket 연결을 권한다. 생성 구간이 짧아질수록 요청 사이의 오버헤드가 상대적으로 눈에 띈다.

WebSocket 모드에서는 연결을 열어 둔 채 새 입력과 previous_response_id를 보내 다음 턴을 이어간다. 활성 연결의 메모리에 남은 최근 응답 상태를 재사용할 수 있어 재개 비용이 줄어든다. 이는 토큰 한 개를 생성하는 속도와는 다른 부분을 개선한다.

반면 프롬프트 캐시는 입력의 앞부분인 접두부를 처리하며 계산한 KV 상태를 재사용한다. 일치하는 캐시를 찾으면 같은 입력을 다시 계산할 필요가 줄어들지만, 새로 붙은 입력은 처리해야 한다. 저장된 답변 문장을 그대로 반환하는 기능이 아니다.

이전 응답 ID를 넘겼다는 사실만으로 캐시 할인 적용을 판단할 수는 없다. 연결에 남은 응답 상태와 프롬프트의 KV 캐시는 역할이 다르다. 앞쪽 문맥을 유지하는 것은 재사용에 도움이 되지만, 실제 캐시 적중에는 접두부·설정의 일치와 사용할 수 있는 캐시가 필요하다.

Standard는 예열하고, Ultrafast는 처음 불렀다면

Standard로 같은 문맥을 여러 번 보낸 뒤 Ultrafast를 한 번 호출해 시간을 비교하면, 등급 차이에 캐시 상태 차이가 섞일 수 있다. 공식 캐시 진단 문서는 실제 처리 등급 변경을 기대한 접두부 재사용이 안 된 원인 중 하나인 service_tier_changed로 분류한다. 기존 캐시를 전부 지운다는 뜻은 아니다.

따라서 등급별 첫 요청과 반복 요청을 나누어 비교하는 편이 낫다. 모델, 추론 강도, 도구 정의와 순서, 문맥, 전송 방식은 맞추고 각 등급에서 캐시를 준비한 뒤의 결과도 모은다. 운영 환경에는 첫 요청도 있으므로, 예열 뒤의 빠른 결과만 남기지는 않는다.

요청한 값뿐 아니라 응답의 실제 service_tier를 확인하고, cached_tokens와 cache_write_tokens를 함께 기록하자. cache_hit여도 새 입력 처리분은 남을 수 있다. comparison_response_id는 원인 비교용이며 대화를 불러오거나 캐시를 바꾸지 않는다. 진단은 처음 분류한 원인만 보여주고 모든 미스를 설명하지는 못한다. 도구나 입력 변경도 살펴야 한다.

6배의 단가로 사는 것은 어떤 기다림인가

확인한 공식 가격표에서 Astra의 같은 컨텍스트 구간과 토큰 분류를 맞추면 Ultrafast 단가는 Standard의 6배다. 아래는 입력 272K 토큰 이하 요청에 해당하는 기본 단가다.

캐시 쓰기 요금은 일반 입력 요금에 덧붙는 수수료가 아니다. 캐시 문서의 과금 설명에 따르면 해당 입력 토큰에는 일반 입력·캐시 읽기·캐시 쓰기 중 해당하는 단가를 적용한다.

단가가 6배라는 사실과 성공한 작업 한 건의 총비용이 6배라는 말도 다르다. 실제 입력·출력 토큰 수, 캐시 읽기와 쓰기의 비중, 도구 사용료가 달라지기 때문이다. 속도 비교에서 캐시를 따로 본 이유가 비용 비교에서도 그대로 이어진다.

Ultrafast의 유력한 적용 대상은 사람이 결과를 기다리고 있고, 그 대기의 큰 몫을 토큰 생성이 차지하는 작업이다. 외부 검색이나 테스트가 대부분이라면 먼저 그 긴 구간을 줄이는 편이 직접적이다. 더 빠른 토큰에 얼마를 낼지가 아니라, 성공한 작업 한 건을 얼마나 일찍 끝내기 위해 얼마를 더 낼지를 비교해야 한다. 출발점은 새 등급의 배수가 아니라 우리 에이전트의 100초다.

이 글은 9월 29일 발표를 다시 살펴본 후속 해설이다. 사건 선정 기준은 한국시간 2026년 10월 6일 오전 8:03:57, 현재 문서 확인은 그 이후인 오전 8:05~8:08이다. 발표의 정확한 시각·시간대와 각 문서의 수정 시각은 확인되지 않았다. 제품 벤치마크를 실행하지 않았으며, 시간 막대는 온축이 독립적으로 구성한 가정 계산이다.