초고속 AI 코딩의 황홀과 비용 폭탄

URL: https://www.youtube.com/watch?v=pJljViiUEPw 날짜: 2026-10-07 채널: t3dotgg 원문 제목: I love Ultrafast (it's unusable) 영상 길이: 28분 17초

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==GPT-6 Astra의 Ultrafast는 개발자가 모델의 답을 기다리는 대신 실시간으로 함께 조종하는 새로운 작업 감각을 열지만, 현재의 가격과 사용량 제한은 일반적인 개발 작업에 정당화될 수 없을 만큼 가혹하다.==

• Astra의 표준 출력 가격은 100만 토큰당 50달러지만 Ultrafast에서는 300달러, 긴 컨텍스트에서는 450달러로 뛴다.
• 100줄 미만의 작은 풀 리퀘스트 두 개를 검토하는 데 600달러의 사용량이 발생했고, 월 500달러 플랜도 실제 작업에서는 약 2.1시간 만에 소진될 수 있다.
• 그럼에도 짧은 응답 간격은 사용자가 모델의 결과를 즉시 보고 작은 변경을 계속 지시하게 하며, 느린 모델로는 시작하지 않았거나 끝내지 않았을 UI 작업을 완성하게 만든다.

핵심은 단순한 시간 절약이 아니다. 느린 모델을 기다리는 동안 사용자는 무엇을 바꾸려 했는지, 방금 본 결과에서 무엇이 마음에 들지 않았는지를 잊고 다시 맥락을 세워야 한다. Ultrafast는 그 맥락을 유지한 채 사람과 모델이 화면을 보며 짧은 지시를 반복하는 흐름을 만든다. 이 흐름은 디자인과 탐색적 프로토타이핑에는 실제 가치가 있지만, 그 가치를 돈으로 환산하면 현재 가격은 대부분의 사용자에게 손해다. 따라서 Ultrafast는 기본 모드나 업그레이드 사유가 아니라, 잃어도 되는 사용량을 태우거나 정말 급한 장애를 처리할 때만 제한적으로 써야 한다.

1. 초고속 생성이 만드는 첫인상과 실시간 개발 루프

Ultrafast의 매력은 벤치마크 점수가 아니라 결과가 눈앞에서 계속 바뀌는 감각에 있다.

1.1. 화면 위에서 진행되는 실시간 변경

1. 초반 실험의 설정

   1. Lakebase로 만든 앱: 이미 만들어 둔 앱에 “라이트 모드로 바꾸고 더 재미있게 만들어 달라”고 요청하고, 결과가 완성 후 한 번에 나타나는 것이 아니라 실행 중인 화면에 실시간으로 반영되는 모습을 지켜본다.
   2. 편집 없는 시연: 페이지 스냅샷을 찍는 작업조차 거의 즉시 끝난다. 보통의 녹화처럼 결과 사이를 잘라내지 않고, 모델이 생성하는 동안 화면이 계속 갱신되는 상태를 그대로 보여준다.
   3. 말실수의 비용: 모든 것이 실시간으로 진행되기 때문에 말하는 도중 단어를 틀리면 후반 편집에서 고치기 어렵다는 농담이 나온다. 실시간 상호작용 자체가 데모의 핵심이기 때문이다.

2. 실시간 속도가 열어 주는 사용 사례

   1. 라이브 프로토타이핑: 아이디어를 설명하고 기다리는 대신, 모델이 바꾸는 결과를 보면서 다음 요구를 바로 정한다.
   2. 인 더 루프 작업: 모델에게 전부 맡긴 뒤 나중에 검수하는 배치형 작업에서 벗어나, 사람의 판단이 매 단계에 들어간다.
   3. 즉각적인 사용자 경험: 사용자의 요청에 맞춰 화면이나 기능이 바로 바뀌는 제품을 만들 수 있다.
   4. 컴퓨터 사용(computer use): 에이전트가 마우스와 도구를 사용하는 과정을 지켜보는 경험이 실제 사람이 컴퓨터를 쓰는 것보다 빠르게 느껴질 수 있다.

1.2. 속도가 단순한 생산성 수치가 아닌 이유

1. 기다림의 구조가 바뀐다

   1. 일반적인 코딩 에이전트는 “작업을 맡긴다 → 스레드가 사라진다 → 나중에 결과를 확인한다”는 흐름을 만든다.
   2. Ultrafast에서는 앱과 모델을 화면 분할해 함께 본다. 결과가 나오는 즉시 다음 변경을 보내므로, 모델의 산출물을 해석하는 사람의 주의력이 끊기지 않는다.

2. 새로운 작업 감각

   1. 예전에는 코드를 직접 쓰면서 코드와 실행 결과 사이를 빠르게 오갔다. Ultrafast는 모델을 사이에 둔 채 그 감각을 되살린다.
   2. 모델이 단순히 “완성된 기능”을 반환하는 것이 아니라, 사람이 보고 느낀 불편을 곧바로 다음 지시로 바꿀 수 있게 한다.
   3. 다만 이 감각은 모델의 지능이 압도적으로 좋아서가 아니라, 사람이 계속 관찰하고 조종하기 때문에 성립한다. 따라서 속도가 낮아지면 이 작업 방식 자체가 무너진다.

2. 가격 구조와 사용량 제한이 만드는 비현실성

Ultrafast의 속도는 인상적이지만, 토큰과 캐시 가격은 그 속도를 일반적인 개발 도구로 쓰기 어렵게 만든다.

2.1. Astra의 가격 사다리

1. 출력 토큰 가격

   1. 표준 Astra: 출력 100만 토큰당 50달러다.
   2. Astra Ultrafast: 같은 출력량이 100만 토큰당 300달러로 올라가 표준 대비 6배다.
   3. 긴 컨텍스트 작업: 긴 입력이나 대화 이력이 포함되면 출력 가격이 100만 토큰당 450달러까지 오른다.

2. 캐시 가격

   1. 캐시 읽기(cache read): 100만 토큰당 6달러다. 다른 모델에서 일반 읽기를 하는 것보다 캐시를 재사용하는 일이 오히려 비싸질 수 있다.
   2. 캐시 쓰기(cache write): 100만 토큰당 75달러다. 빠른 추론을 위해 컨텍스트를 저장하는 비용이 너무 커서, 긴 작업일수록 비용 구조가 더 불리해진다.
   3. 핵심 문제: 비용 상승은 출력 생성에만 국한되지 않는다. 컨텍스트와 캐시가 큰 에이전트 작업에서는 모든 주변 비용이 함께 커진다.

2.2. 작은 코드 리뷰가 600달러가 된 사례

1. 실험 대상

   1. 실제 일상 작업으로 열어 둔 작은 풀 리퀘스트 두 개를 검토했다.
   2. 두 변경 사항 모두 100줄 미만이었다. 대규모 저장소를 장시간 분석한 사례가 아니라, 개발자가 흔히 할 법한 짧은 코드 리뷰였다.

2. 결과와 반응

   1. 시청자에게 두 PR의 비용을 먼저 추측하게 했다. 채팅에서는 PR 하나당 100달러 정도라는 예상이 나왔다.
   2. 실제 사용량은 두 개 합쳐 600달러였다. 0이 두 개 더 붙은 금액이라는 점을 반복해서 확인할 정도로 비정상적인 결과였다.
   3. 이 수치는 “빠른 모델이 시간을 아껴 주면 그만큼 비싸도 된다”는 단순한 계산이 성립하지 않음을 보여준다. 작은 작업 하나의 가격이 개발자의 월간 도구 예산을 압도할 수 있다.

2.3. 월 500달러 플랜과 소진 속도

1. 플랜의 명목상 혜택

   1. 월 500달러 Ultrafast 플랜은 주당 약 1,000달러어치의 사용량을 보조금 형태로 제공한다.
   2. 그러나 Ultrafast 속도로 실제 작업을 하면 그 주간 한도를 약 2.1시간 만에 태울 수 있다.
   3. 높은 한도처럼 보이는 숫자도 초당 생성량이 커지면 짧은 실험 몇 번으로 사라진다.

2. 사용량 표시로 확인한 소진

   1. 작업 시작 직전 Codex 계정에 38%가 남아 있었다.
   2. 빠른 빌드 요청은 38초, 라이트 모드와 재미있는 카피를 만드는 요청은 16초가 걸렸다.
   3. 합쳐 1분이 채 되지 않는 작업 후 잔여량은 38%에서 37%로 떨어졌다. 1분 미만의 작업이 월 500달러 플랜의 1%를 태운 셈이다.
   4. 이어서 칸반 앱과 실시간 채팅으로 확장하고, 기능을 한 번에 하나씩 표시하도록 지시했다. 로컬 개발 서버와 자동 배포가 함께 갱신되는지 확인하는 작업도 이어졌다.

3. 초고속 모드에 맞춰 에이전트 작업 방식을 바꾸기

생성 시간이 분 단위에서 초 단위로 줄어들면, 지금까지 무시했던 도구 호출과 빌드 대기 시간이 전체 작업을 지배하기 시작한다.

3.1. 토큰 시간과 도구 시간의 비율 역전

1. 기존 비율

   1. 일반 모드에서 토큰 생성에 약 10분이 걸리고 Git 명령이나 빌드가 30초 이내라면, 사용자는 도구 시간을 최적화할 이유가 거의 없었다.
   2. 전체 대기 시간에서 모델의 추론이 압도적으로 컸기 때문에 30초의 도구 호출은 작은 부수 비용에 불과했다.

2. Ultrafast 이후의 비율

   1. 추론이 수십 초로 줄어들면 30초짜리 브라우저 확인, 빌드, Git 명령이 전체 런타임을 두 배로 만들 수 있다.
   2. 따라서 같은 모델이라도 Ultrafast를 쓸 때는 시스템 프롬프트와 작업 지시를 별도로 설계해야 한다.
   3. 모델이 미리보기 브라우저를 직접 조작하지 말고 요청받았을 때만 코드를 바꾸게 하면, 불필요한 도구 호출을 줄이고 실시간 코드 변경에 집중할 수 있다.

3.2. 실제 라이브 수정과 도구 최소화

1. 화면 정리 작업

   1. 앱 상단에 불필요한 자막과 정보가 너무 많아 세로 공간을 낭비하고 있었다.
   2. 상단 내비게이션을 정리하고 불필요한 요소를 삭제하라는 요청을 보냈다.
   3. 변경은 11초 만에 끝났다. 이 정도의 짧은 피드백 주기가 Ultrafast의 가장 설득력 있는 사용 장면이다.

2. 동시에 여러 요구를 보내는 조종

   1. 다크 모드를 기본값으로 만들고 게스트 채팅을 막는 요청은 약 5초 만에 반영됐다.
   2. “작동한다고만 말하는 카피는 별로다”라며 문구를 더 좋게 만들라고 이어서 지시했다.
   3. 새 티켓과 채팅에서 이미지 첨부를 허용하되 로그인 사용자만 가능하게 하고, 새 작업 생성도 로그인 사용자에게만 열도록 요구했다.
   4. 모델이 앞선 작업을 처리하는 중에도 이런 요구를 연달아 보내며, 모델이 서로 다른 변경을 함께 조정하는지 확인했다.

3.3. 37%에서 34%로 떨어진 사용량

1. 짧은 상호작용의 누적 비용

   1. 앞서 37%가 남아 있던 플랜에서 다크 모드 전환과 기능 두 가지 비활성화 등 몇 가지 작은 변경을 추가했다.
   2. 그 결과 잔여 사용량은 34%가 됐다. 짧은 피드백 루프가 개발 감각을 좋게 만들지만, 동시에 플랜의 3%를 소모했다.

2. 비용 비교

   1. 같은 스레드를 표준 API 요금의 Astra로 처리했다면 7.72달러였을 작업이 Ultrafast에서는 46.32달러였다.
   2. GPT-6.1 Sol 표준 속도로 같은 작업을 수행하면 약 1.10달러 수준으로 추정됐다.
   3. Sol은 같은 작업을 수행할 수 있었지만, Ultrafast Astra의 비용은 그 기준보다 40배 이상 높았다.
   4. OpenAI 직원조차 Ultrafast 작업마다 승인을 받아야 한다는 이야기가 나왔다. 내부 사용자도 컴퓨트 제한에 걸릴 만큼 비용이 크다는 점이 일반 사용자에게는 작은 위안이자 가격 구조의 경고다.

4. Slopalytics가 보여 준 유일한 강한 사용 사례

Ultrafast는 비용 대비 성능만 보면 실패에 가깝지만, 즉각적인 디자인 피드백이 중요한 작업에서는 사람이 더 나은 결과를 만드는 과정을 가능하게 한다.

4.1. 첫 초안의 속도와 품질 차이

1. 동일 작업의 비교

   1. Slopalytics는 Artificial Analysis 데이터를 시각화하는 앱이다. 모델별 토큰 효율과 비용, 지능 점수를 비교하는 사이트로, 정보가 명확하고 탐색하기 쉬운 결과물을 목표로 했다.
   2. Opus 5.5와 Astra Ultrafast를 동시에 사용해 첫 작업 초안을 비교했다.
   3. Opus는 첫 작동 초안까지 약 15분에서 20분이 걸렸고, Astra Ultrafast는 약 1분 30초 만에 첫 초안을 만들었다.
   4. Astra의 첫 결과는 예상대로 못생겼고, 초기 디자인만 보면 Opus 쪽이 의미 있게 나았다.

2. 짧은 피드백이 초안의 열세를 뒤집은 과정

   1. Opus 버전이 나올 때까지 기다리는 동안 Astra 버전에 “이 부분이 문제다”라고 바로 지시할 수 있었다.
   2. 브라우저에서 결과가 즉시 업데이트되자 “이 두 가지는 아직 별로니 다른 방식으로 시도하라”, “방금 방향은 싫으니 되돌리고 다른 방법을 시도하라”처럼 짧은 요구를 계속 보냈다.
   3. 첫 초안의 품질이 아니라, 초안을 본 뒤의 반복 횟수와 피드백 속도가 최종 품질을 결정했다.
   4. 이 작업 방식이 없었다면 Slopalytics를 끝까지 만들지 않았을 가능성이 크다고 평가했다. Ultrafast는 개발 결과뿐 아니라 만드는 과정 자체를 더 재미있게 만들었다.

4.2. Slopalytics의 구현 및 오류 수정 흐름

1. 실행 환경 바로잡기

   1. 에이전트가 원격 개발 서버를 Tailscale로 호스팅하는 TS dev 스킬을 사용하려 했다.
   2. 작업은 자신의 컴퓨터에서 진행 중이었으므로 원격 서버가 필요하지 않았다. 이를 즉시 지적하고 localhost를 사용하게 했다.
   3. 약 30초 뒤 스냅샷에는 688개 변형이 반영됐다.

2. 데이터와 UI의 초기 구성

   1. 에이전트가 페이지를 만들며 URL을 출력했지만, 그 URL로 이동했을 때 로드가 제대로 되지 않았다.
   2. 그래도 전체 작업 약 2분 만에 Artificial Analysis 데이터가 들어 있고 쓸 만한 UI를 가진 localhost 버전을 얻었다.
   3. 가로 막대 그래프는 원하는 비교에 맞지 않아 세로 막대 그래프로 바꾸고, 일반적인 화면에 모두 들어오도록 요청했다.

3. 오류·스타일·브랜딩 수정

   1. 스크린샷을 보낸 뒤 41초 후 무작위 오류가 나타났다. 결과는 여전히 조잡했고, “acceptable하지 않다”고 판단했다.
   2. 오래된 CSS 문제를 고치고, 각 연구소의 로고와 색을 더 사용하며 Artificial Analysis를 디자인 참고로 삼으라고 했다.
   3. 약 1분 뒤 결과가 갱신됐다. 응답과 다음 지시가 거의 같은 시각에 이어질 정도로 루프가 짧았다.

4.3. 데이터 시각화의 구조를 다시 설계한 이유

1. Artificial Analysis 대시보드의 문제

   1. 기존 화면은 Opus 5.5와 Fable 5.1의 수치를 포함해 모든 모델을 최고 추론 수준(max reasoning) 기준으로 보여줬다.
   2. 출력 토큰 수는 Sonnet 200,000, Opus 120,000, Astra 27K로 표시됐지만, 이런 숫자만으로는 모델 계열 안의 관계를 이해하기 어려웠다.
   3. Opus 5.5의 high 설정을 켜면 max 설정과 화면에서 멀리 떨어진 위치에 나타나 같은 모델 계열의 관계가 더 흐려졌다.

2. Slopalytics의 해결 방식

   1. 모델을 개별 점으로 흩어 놓는 대신 모델 계열별로 묶었다.
   2. 각 계열의 정렬은 최고값을 기준으로 정했다. 그 결과 max reasoning에서 비효율적인 모델과 낮은 추론 수준에서 합리적인 모델을 구분할 수 있게 됐다.
   3. low, mid, high, max 토글을 두어 추론 수준을 끌 수 있게 했다.
   4. max를 끄면 Sonnet은 가장 비효율적인 위치에서 벗어나고, high에서는 사용 토큰량이 Opus보다 낮아지는 등 실제 비교에 더 맞는 위치로 이동했다.

4.4. 짧은 지시가 만들어 낸 세부 UX

1. 분 단위가 아닌 초 단위의 설계 반복

   1. 평균값은 쓸모없으니 최고값으로 정렬하라는 요구를 보냈다.
   2. 평균선을 없애고, 불필요한 제목과 부제목을 삭제하라고 했다.
   3. 기본 화면에서는 URL hash를 만들지 말고 사용자가 변경했을 때만 유지하게 했다.
   4. 정렬 순서가 잘못됐으니 기본값은 최고값이 마지막에 오도록 바꾸라고 했다.
   5. 다른 모델이 잘리는 지점을 표시하는 선을 추가하고, 클릭한 상태가 유지되도록 했다.

2. 모델 비교 인터랙션

   1. 한 모델을 가리키면 2D 차트의 해당 선을 더 선명하게 하고 나머지는 투명하게 만들었다.
   2. 예를 들어 Sonnet 5의 X high 설정과 Fable 5.1을 비교하면 왼쪽 위 카드에 비용, 토큰 수, 지능 점수의 배수 차이가 나타나도록 했다.
   3. 이 UX는 사전에 설계한 기능 목록에서 나온 것이 아니라, 작업 중인 화면을 계속 바라보며 모델과 즉시 주고받는 과정에서 떠올랐다.

3. 패널 배치와 되돌리기

   1. 첫 비교 카드는 정보를 가려서 마음에 들지 않았다. 카드를 어디에 둘지 세 번이나 마음을 바꿨다.
   2. 세 개의 열로 패널을 구성하게 했고, 마우스 오버가 깜빡거려 지연을 넣어 보게 했다.
   3. 지연 변경은 25초 걸렸지만 마음에 들지 않아 10초 만에 되돌렸다.
   4. 패널은 오른쪽이 아니라 왼쪽 위에 놓으라고 했다. 오른쪽 위는 촬영할 때 얼굴을 배치해야 하는 금지 영역이기 때문이다.
   5. 사이드바를 오른쪽으로 옮기되 보기 싫지 않게 만들라고 했고, 32초 뒤 변경이 끝났다.

4. 브랜드 이름과 서브 에이전트의 한계

   1. 결과가 여전히 못생겼다고 판단해 브랜딩 작업을 별도 서브 에이전트에 맡겼다.
   2. 여러 이름을 제안받았지만 모두 마음에 들지 않았고, 다른 스레드에서도 이름을 만들어 보게 했지만 결과는 또 쓸모없었다.
   3. 모델은 빠르더라도 이름 짓기에는 여전히 약했다.
   4. 최종 이름 Slopalytics는 모델이 아니라 사람이 지었다.

4.5. 프롬프트 습관과 작업량의 변화

1. 평소와 달라진 지시 크기

   1. 일반적인 Opus 작업에서는 결과를 보고 바꿀 항목 20개를 한 번에 적어 보내고, 5분에서 2시간을 기다린다.
   2. Ultrafast에서는 “사진을 보니 안 된다”, “연구소 색과 로고를 더 써라”, “평균은 무의미하니 최고값으로 정렬하라”처럼 작은 지시를 즉시 보냈다.
   3. 4분 안에 약 5개의 프롬프트를 보냈고, 각 응답은 1분 이내였다. 정렬 변경은 18초 만에 끝났고, 어떤 응답은 20초였다.
   4. 다음 요구를 생각할 시간이 생기지 않을 정도로 빠르기 때문에 주의가 흩어지지 않았다.

2. 직접 만든 개선점의 수

   1. 스레드에 50개가 넘는 메시지를 보냈다. 평소 한 스레드에서 그렇게 많은 메시지를 보내지 않는다.
   2. 자동으로 실행 중인 스레드를 숨기도록 T3 코드를 바꿨다. 모델이 완전히 끝날 때까지는 무엇을 하는지 신경 쓰지 않기 위해서다.
   3. 다만 모델이 사람과 빠르게 함께 작업하는 모드라면 실행 중인 스레드를 숨기면 안 된다. 이 두 사용 패턴은 서로 다른 UI가 필요하다.

5. 토큰 처리량과 총비용이 보여 주는 냉정한 결론

실시간 개발의 심리적 가치는 진짜지만, 동일한 산출물을 비용과 시간만으로 비교하면 Ultrafast는 명백히 불리하다.

5.1. 실제 처리량

1. 측정된 초당 토큰 수(TPS)

   1. 일반 모드는 약 30 TPS였다.
   2. Fast 모드는 약 60 TPS였다.
   3. Ultrafast는 320~340 TPS, 즉 300 TPS를 넘었다.
   4. 30 TPS에서 320~340 TPS로 뛰는 차이는 단순히 체감이 조금 빨라지는 수준이 아니라, 사용자가 프롬프트 전략 자체를 바꾸게 하는 수준이다.

2. 작업 처리량과 비용의 분리

   1. 처리량은 확실히 압도적이지만, 더 많은 짧은 지시를 보내게 되면서 총 토큰 소비도 빠르게 늘어난다.
   2. 속도가 생산성을 높이는 동시에 사용자가 계속 수정하도록 유도해 비용을 가속하는 양면성이 있다.

5.2. Slopalytics 전체 비용 비교

1. 실제 Ultrafast 비용

   1. 메인 작업 스레드는 306달러였다.
   2. 추가 작업을 진행한 후속 스레드는 250달러였다.
   3. 두 스레드 합계는 약 556달러다.

2. 다른 선택지와의 비교

   1. 일반 Astra로 같은 작업을 했다면 비용은 약 90달러였을 것으로 추정했다.
   2. GPT-6.1 Sol을 사용했다면 약 12달러였다.
   3. Astra Ultrafast는 Sol 6.1보다 약 540달러 더 들었다.
   4. 순수한 시간당 비용 계산이라면 540달러를 내고 기다림을 줄이는 선택은 거의 정당화되지 않는다. 이 기준으로 비교하면 Ultrafast는 절대 사용하지 말아야 한다는 결론이 나온다.

5.3. 그런데도 단순 비용 비교가 완전하지 않은 이유

1. 완성 여부의 차이

   1. “500달러를 더 내고 같은 결과를 빨리 얻었다”가 정확한 비교가 아니다.
   2. 느린 모델을 단계마다 기다렸다면 만들고 있던 UI의 맥락을 잃고, 다음에 무엇을 바꾸려 했는지 다시 떠올려야 했을 가능성이 크다.
   3. 그 결과 Slopalytics는 애초에 끝까지 만들지 않았을 수도 있다.

2. 디자인 품질의 역설

   1. Astra는 Anthropic 모델보다 디자인 능력이 객관적으로 떨어진다.
   2. 그러나 디자인은 최종 코드의 품질만이 아니라 사용자가 보고 느끼는 것을 빠르게 평가하는 과정이다.
   3. 결과를 즉시 보고 더 나은 방향을 요청할 수 있으면, 디자인 능력이 낮은 모델로도 사람이 더 좋은 UI를 만들 수 있다.
   4. 느린 모델로 한 번에 20개 요구를 보내는 방식보다, 빠른 모델로 한 번에 한두 개씩 작은 요청을 보내는 방식이 탐색적 UI 설계에 더 잘 맞는다.

6. 미래의 가격 구조와 제한적인 사용처

Ultrafast의 현재 가격은 방어하기 어렵지만, 같은 속도가 더 저렴한 모델에 적용되면 상황은 달라질 수 있다.

6.1. GPT-6.1 Sol Ultrafast에 대한 기대

1. 현재의 기본 선택

   1. 6.1 Sol에는 아직 Ultrafast 모드가 없다.
   2. 일반 속도의 6.1 Sol은 작업을 잘 수행하지만, 음식이 오븐에 있는 동안 자리를 비웠다가 돌아와도 작업이 계속 진행 중일 정도로 느렸다.
   3. 다시 Ultrafast Astra로 전환하자 즉시 날아가는 듯한 감각을 되찾았다.

2. 가격 배수 가정

   1. Sol 6.1의 표준 작업 비용을 약 12.03달러, Astra의 비교 비용을 약 90달러로 놓고 같은 6배 속도 배수가 적용된다고 가정했다.
   2. 그러면 Sol 6.1 Ultrafast는 Astra Ultrafast보다 약 10배 저렴해지고, Astra 표준 가격과 비슷하거나 더 저렴해질 수 있다.
   3. 이 조합이라면 6.1 Sol Ultrafast가 기본 모델이 될 가능성이 있다.

3. 공개된 출시 암시

   1. Tibo가 6.1 출시를 암시했을 때 많은 사람은 6.1 Astra라고 생각했다.
   2. 실제로는 Ultrafast에 관한 문맥이 잘린 답글이었고, 6.1 Sol Ultrafast가 곧 나올 것이라는 공개적인 확인으로 해석됐다.
   3. 구현 방식은 Cerebras일 수도 있고, NVIDIA에서 진행하는 특수한 최적화일 수도 있어 아직 확정되지 않았다.
   4. 더 저렴한 모델에 같은 속도가 적용되면 월 500달러 플랜은 과도한 가격에서 놀라운 가치로 바뀔 수 있다.

6.2. 지금 당장 정당화 가능한 사용처

1. 고우선순위 장애 대응

   1. 현시점에서 가장 그럴듯한 사용처는 심각도가 높은 장애를 즉시 해결해야 하는 사고 대응(incident response)이다.
   2. 다만 일반 회사에서도 장애 대응에 이 가격을 쓰기 어렵고, 비용이 사실상 중요하지 않은 환경이나 OpenAI 내부처럼 컴퓨트 예산이 별도로 있는 경우에나 가능하다.

2. 사라질 사용량을 태우는 경우

   1. 계정에는 수동 리셋 9개가 있었고, 행사에서 받은 6개와 기존에 지급된 리셋이 합쳐진 상태였다.
   2. 그중 하나가 한 시간 뒤 만료될 예정이어서, 한 시간 안에 계정 사용량의 34%를 태워야 했다.
   3. 이런 식으로 곧 리셋될 사용량이나 잃어도 업무에 영향이 없는 사용량이 있을 때는 Ultrafast를 시험해 볼 수 있다.

3. 리셋 전 소진 전략

   1. Tibo는 앞으로 28일 동안 매일 대부분의 Codex 및 업무 사용자에게 의미 있는 개선 하나를 배포하거나 전체 리셋을 제공하겠다고 예고했다.
   2. 실제 배포는 약속한 시각보다 늦어지는 경우가 많으므로, 리셋 조짐이 보이면 계정의 Ultrafast 사용량을 먼저 소진하는 전략을 쓴다.
   3. 때로는 사용량을 0으로 만들기 전에 리셋되고, 때로는 0이 된 뒤 한두 시간 후 또는 다음 날 리셋된다.
   4. 진지한 작업은 Opus로 처리하고 있었기 때문에 Codex 계정이 0이 되어도 업무가 크게 막히지 않았다.

6.3. 구독 플랜에 대한 최종 판단

1. 월 500달러 플랜

   1. Ultrafast만을 위해 월 500달러 플랜으로 업그레이드해서는 안 된다.
   2. 이 플랜은 경고 없이 클릭 한 번으로 켤 수 있게 제공하기에는 위험하다. 사용자는 선택지가 있으면 max reasoning처럼 가장 높은 다이얼을 돌리는 경향이 있고, 공급자도 그 선택을 너무 쉽게 만들었다.
   3. GPT-6.1 Sol Ultrafast가 출시되면 판단이 바뀔 수 있지만, 현재는 피하는 것이 맞다.

2. 월 200달러 플랜

   1. 200달러 플랜에는 Ultrafast가 없지만 6.1 Sol, Astra, Fast 모드, 여러 리셋이 포함된다.
   2. 이 플랜이 여전히 가치 있는지는 별도의 후속 분석으로 남겼다.
   3. 결론을 내리기 전에 다른 맥주와 다음 영상을 약속하며 마무리한다.

주요 발언 모음

“두 개를 검토하는 데 600달러의 사용량이 들었다. 말도 안 된다. 이걸로 돈을 얼마나 빨리 태울 수 있는지 미쳤다.”

“월 500달러 Ultrafast 플랜은 약 1,000달러어치 사용량을 주지만, 그걸 태우는 데 고작 2.1시간이 걸린다.”

“표준 API 가격이었다면 7.72달러였을 Astra 작업이 Ultrafast에서는 46.32달러였다.”

“Ultrafast가 아니었다면 Slopalytics를 끝내지 않았을지도 모른다.”

“차이는 500달러를 아끼고 더 참을 수 있었다는 것이 아니다. 애초에 만들지 않았을 것이라는 점이다.”

“Astra가 디자인을 더 잘해서가 아니다. 객관적으로는 더 못하지만, 내가 루프 안에 있었기 때문에 더 나은 디자인을 만들었다.”

“Ultrafast는 잃어도 상관없을 때 사용하라.”

핵심 데이터 & 수치

• Astra 표준 출력 가격: 100만 토큰당 50달러다.
• Astra Ultrafast 출력 가격: 100만 토큰당 300달러로 표준 대비 6배다.
• 긴 컨텍스트 출력 가격: 100만 토큰당 450달러다.
• 캐시 읽기 가격: 100만 토큰당 6달러다.
• 캐시 쓰기 가격: 100만 토큰당 75달러다.
• 작은 PR 리뷰 비용: 100줄 미만의 PR 두 개에 총 600달러의 사용량이 발생했다.
• 월 500달러 플랜의 주간 사용량: 약 1,000달러어치이며 Ultrafast로 약 2.1시간 만에 소진된다.
• 초기 라이브 빌드: 38초와 16초짜리 두 요청으로 잔여량이 38%에서 37%로 줄었다.
• 추가 실시간 수정: 소수의 변경만으로 잔여량이 37%에서 34%로 줄었다.
• 동일 스레드 비용 비교: 표준 Astra 7.72달러, Astra Ultrafast 46.32달러, 6.1 Sol 약 1.10달러로 추정됐다.
• Slopalytics 첫 작동 초안: Opus 5.5는 약 15~20분, Astra Ultrafast는 약 1분 30초가 걸렸다.
• Slopalytics 데이터: 첫 localhost 버전은 약 2분의 작업 후 Artificial Analysis 데이터와 쓸 만한 UI를 갖췄고, 스냅샷에는 688개 변형이 반영됐다.
• Slopalytics 전체 비용: 메인 스레드 306달러, 후속 스레드 250달러, 합계 약 556달러였다.
• 대안 비용: 일반 Astra는 약 90달러, 6.1 Sol은 약 12달러로 추정됐다.
• 토큰 처리량: 일반 약 30 TPS, Fast 약 60 TPS, Ultrafast 약 320~340 TPS다.
• 프롬프트 빈도: 약 4분 동안 5개 프롬프트를 보냈고 대부분의 응답은 1분 이내, 정렬 변경은 18초였다.
• 향후 6.1 Sol Ultrafast 가정: 6배 가격 배수가 적용돼도 Astra Ultrafast보다 약 10배 저렴할 수 있다.

결론 및 시사점

1. 현재 기본값으로 쓰지 않는다: Astra Ultrafast의 300달러/100만 출력 토큰과 빠른 한도 소진은 일반 코딩·리뷰·프로토타이핑의 비용 대비 이점을 무너뜨린다.
2. 가치는 ‘시간’보다 ‘맥락 보존’에 있다: 진짜 이점은 몇 분을 절약하는 것이 아니라, 사용자가 결과를 보며 계속 생각하고 수정하는 정신적 흐름을 잃지 않는 데 있다.
3. UI 탐색에는 예외적으로 강하다: 디자인처럼 정답을 미리 목록화하기 어렵고, 화면을 보며 여러 번 마음을 바꿔야 하는 작업에서는 낮은 모델 지능을 사람의 빠른 피드백으로 보완할 수 있다.
4. 프롬프트와 도구 호출을 Ultrafast 전용으로 바꿔야 한다: 브라우저 미리보기, 빌드, Git 작업이 토큰 생성보다 오래 걸릴 수 있으므로 불필요한 도구 호출을 제한해야 한다.
5. 플랜 사용자는 사용량의 성격을 구분해야 한다: 업무를 막을 수 있는 계정의 한도를 실험에 태우지 말고, 리셋 직전이거나 잃어도 되는 사용량에만 적용해야 한다.
6. 긴급 장애 대응 외에는 가격을 설명하기 어렵다: 정말 높은 우선순위의 incident response조차 일반 조직에서는 비용이 과하며, 현재 정당화 가능한 사용처는 매우 제한적이다.
7. 더 싼 모델의 초고속 모드가 핵심 변수다: 6.1 Sol Ultrafast처럼 같은 속도를 훨씬 낮은 가격으로 제공하는 모델이 나오면 실시간 인 더 루프 개발이 실험이 아니라 기본 작업 방식이 될 수 있다.
8. 최종 판정: 현재 Ultrafast는 놀랍도록 빠르고 창작 흐름을 바꾸지만, 월 500달러 플랜을 새로 살 이유는 없다. 잃어도 되는 사용량을 태우거나 실험할 때만 사용하고, 6.1 Sol Ultrafast 출시 이후 다시 평가해야 한다.

핵심 요약 (20줄)

1. GPT-6 Astra의 Ultrafast는 토큰 생성 속도로 실시간 개발 루프를 열지만 사용량과 비용도 같은 속도로 태운다.
2. Astra의 표준 출력 가격은 100만 토큰당 50달러이고 Ultrafast는 300달러까지 오른다.
3. 긴 컨텍스트 작업에서는 Astra Ultrafast의 출력 가격이 100만 토큰당 450달러가 된다.
4. 캐시 읽기는 100만 토큰당 6달러이고 캐시 쓰기는 75달러라서 긴 에이전트 작업의 비용이 더 커진다.
5. 100줄 미만의 작은 풀 리퀘스트 두 개를 검토하는 데 총 600달러의 사용량이 발생했다.
6. Greptile의 T-Rex는 코드 리뷰 에이전트가 실제 컴퓨터에서 변경 사항을 실행해 회귀를 증명하게 만든다.
7. 월 500달러 Ultrafast 플랜은 주당 약 1,000달러어치 사용량을 주지만 실제 작업으로 약 2.1시간 만에 소진될 수 있다.
8. 38초짜리 빌드와 16초짜리 스타일 변경만으로 Codex 계정 잔여량이 38%에서 37%로 떨어졌다.
9. 다크 모드와 로그인 제한 등 작은 변경을 더하자 잔여량은 37%에서 34%로 줄었다.
10. 생성이 10분에서 수십 초로 줄면 브라우저 확인과 빌드 같은 도구 호출이 전체 시간을 두 배로 만들 수 있다.
11. 모델에 불필요한 미리보기 조작을 막고 코드만 바꾸게 하면 상단 UI 정리가 11초 만에 끝난다.
12. 실시간 피드백은 다크 모드, 채팅 권한, 이미지 첨부, 로그인 제한을 동시에 조정하는 흐름을 가능하게 한다.
13. 같은 Astra 작업의 표준 API 비용은 7.72달러였지만 Ultrafast에서는 46.32달러였다.
14. GPT-6.1 Sol은 같은 작업을 약 1.10달러로 수행할 수 있어 Astra Ultrafast보다 40배 이상 저렴했다.
15. Slopalytics의 첫 초안은 Opus 5.5가 15~20분, Astra Ultrafast가 약 1분 30초 만에 만들었다.
16. Astra의 첫 디자인은 더 못생겼지만 즉각적인 반복 수정으로 Opus 초안을 따라잡았다.
17. Slopalytics는 약 4분 동안 5개 프롬프트를 받고 대부분 1분 이내에 응답하며 50개가 넘는 반복 지시를 소화했다.
18. 측정된 처리량은 일반 30 TPS, Fast 60 TPS, Ultrafast 320~340 TPS였고 전체 비용은 약 556달러였다.
19. Ultrafast의 진짜 가치는 비용 절감이 아니라 기다리는 동안 잃을 맥락을 보존해 끝내지 않았을 작업을 끝내게 하는 데 있다.
20. 현재는 리셋 직전이나 고심각도 장애 대응처럼 잃어도 되는 상황에만 쓰고 6.1 Sol Ultrafast 출시 후 다시 판단해야 한다.