GPT-6 Astra — 토큰은 비싼데 태스크는 싸다

OpenAI가 2026년 9월 3일 GPT-6 Astra를 내놓았습니다. 모델 ID는 gpt-6-astra, 컨텍스트는 1.05M 토큰이고, 브라우저와 터미널을 직접 조작하는 능력을 전면에 내세운 플래그십 추론 모델입니다.

Astra는 출시와 동시에 독립 평가에서 Claude Fable 5.1과 동점을 기록했습니다. 그런데 흥미로운 건 순위가 아니라 비용 구조입니다. 토큰 단가는 전작 GPT-5.6 Sol의 2.5배로 올랐는데, 같은 작업을 끝내는 데 드는 돈은 오히려 절반 이하로 떨어졌습니다. 이 역설이 Astra를 이해하는 열쇠입니다.

이 글에서 배우는 것

• GPT-6 Astra의 포지셔닝과 사양 — 무엇을 노린 모델인지
• 벤치마크로 보는 강점과 약점 — 어디서 이기고 어디서 지는지
• 토큰 사용량과 과금 구조 — 272K 절벽, 캐시, batch, fast 모드
• 실제 워크로드 3종의 월 비용 산식과 최적화 포인트
• reasoning.effort·MCP·computer use 등 API 동작의 실무 차이
• opaque recurrence와 Critical 분류가 남기는 도입 리스크

⚠️ 아래 사양·가격·벤치마크는 2026년 9월 기준 공개 자료입니다. 이 분야는 매우 빠르게 바뀌므로 도입 전 반드시 OpenAI 공식 문서로 최신 값을 재확인하세요. 용어가 낯설면 AI 용어집, 모델 지형 전반은 2026 AI 모델 현황을 함께 보시길 권합니다.

1. GPT-6 Astra 개요와 포지셔닝

Astra는 OpenAI가 "가장 어려운 엔드투엔드 작업"을 겨냥해 내놓은 모델입니다. 채팅 응답 품질보다는 롱호라이즌 에이전트 워크로드 — 컴퓨터·브라우저 조작, 대규모 코드베이스 분석, 다단계 리서치 — 에 초점이 맞춰져 있습니다.

• 모델 ID: gpt-6-astra
• 컨텍스트 윈도우: 1,050,000 토큰 (512K~1M 구간에서도 검색 정확도 100% 보고)
• 최대 출력: 128,000 토큰
• 지식 컷오프: 2026-04-30
• 가격: 입력 $10 / 출력 $50 (per 1M tokens)
• 추론 강도: reasoning.effort = low · medium · high · xhigh · max (none 미지원)
• 엔드포인트: Chat Completions · Responses · Batch
• 내장 툴: web search · code interpreter · computer use · file search · MCP

여기서 놓치기 쉬운 점이 하나 있습니다. Astra에는 "추론을 끄는" 옵션이 없습니다. reasoning.effort: none을 지원하지 않기 때문에, 아무리 단순한 요청이라도 최소한의 사고 토큰이 발생합니다. 단순 분류·짧은 요약처럼 추론이 필요 없는 작업에 Astra를 붙이면 구조적으로 손해라는 뜻입니다. 이 제약은 6장의 모델 티어링 논의로 그대로 이어집니다.

한 문장으로: Astra는 "한 번의 대화"가 아니라 "한 번의 작업 완수"를 단위로 설계된 모델입니다.

2. 무엇이 강한가 — 벤치마크로 보는 강점과 약점

숫자를 한자리에 놓으면 성격이 분명해집니다. 전작 GPT-5.6 Sol, 그리고 같은 체급인 Claude Fable 5.1과 비교합니다.

패턴이 보입니다. "화면과 터미널을 직접 조작하는 일"에서는 확실히 앞서고, 순수 지식·추론을 툴과 함께 겨루는 Humanity's Last Exam 같은 종합 과제에서는 Claude Fable 5.1에 밀립니다. 독립 평가기관(Artificial Analysis) 종합 지수에서도 61.2 대 65.7로 Fable 5.1이 앞섭니다.

즉 Astra는 **"가장 똑똑한 모델"이라기보다 "가장 손이 빠른 모델"**에 가깝습니다. 브라우저를 열고, 셸을 두드리고, 여러 단계를 스스로 이어가는 작업에서 값어치가 나옵니다.

벤치마크를 볼 때 주의할 점: Astra의 ARC-AGI-3 기록에는 별표가 붙습니다. 뒤에 설명할 opaque recurrence를 켠 상태에서 측정한 값이라, 같은 조건에서 잰 다른 모델 점수와 1:1 비교하기 어렵습니다.

3. 토큰 사용량과 과금 구조

이 글의 핵심입니다. Astra의 과금은 단순한 입력·출력 2단 요금제가 아니라 여러 배율이 겹치는 구조라, 모르고 쓰면 청구서가 예상의 2배로 나옵니다.

기본 단가

캐시 읽기가 입력의 10분의 1이라는 점이 중요합니다. 시스템 프롬프트·툴 정의·코드베이스 스냅샷처럼 매 요청마다 반복되는 접두부를 캐시에 태우면 입력 비용이 사실상 한 자릿수 퍼센트로 떨어집니다. 다만 캐시 쓰기는 정가보다 25% 비싸므로, 재사용 횟수가 적은 프롬프트를 습관적으로 캐시하면 오히려 손해입니다.

272K 절벽 — 가장 조심할 것

Astra 과금에서 가장 많은 사고가 나는 지점입니다.

입력이 272,000 토큰을 넘으면, 그 요청 "전체"가 롱컨텍스트 요율로 재계산됩니다. 초과분만 비싸지는 게 아닙니다.

컨텍스트가 1.05M까지 열려 있다는 말에 안심하고 대화 이력을 계속 쌓다가, 어느 턴에서 272K를 넘는 순간 그 턴부터 요금이 두 배가 됩니다. 롱호라이즌 에이전트는 턴이 진행될수록 컨텍스트가 자라기 때문에, 이 절벽을 밟는 게 예외가 아니라 기본값에 가깝습니다. 4장에서 실제 숫자로 보겠습니다.

서비스 티어 배율

그래서 왜 "태스크는 싸다"인가

여기가 반전입니다. Artificial Analysis의 측정 결과를 보면:

같은 점수를 내는 데 출력 토큰을 3분의 1만 씁니다. 토큰 단가가 동일한데 토큰을 덜 쓰니 태스크당 비용이 43% 수준으로 떨어집니다. Coding Agent Index에서도 62점 동점에 약 40% 저렴합니다.

이것이 Astra 비용 평가의 핵심 교훈입니다.

per-token 단가로 모델을 비교하지 마세요. per-task 비용으로 비교해야 합니다. 추론 모델 시대에는 "얼마나 싼 토큰인가"보다 "얼마나 적은 토큰으로 끝내는가"가 청구서를 결정합니다.

단, 이 효율은 작업이 실제로 완수되는 경우의 이야기입니다. 모델이 헤매면 토큰은 그대로 쌓이고, 272K를 넘기면 배율까지 붙습니다. 토큰 효율은 보장된 특성이 아니라 잘 설계된 프롬프트·툴 환경에서 나오는 결과라는 점을 기억하세요.

4. 비용 계산 실습

추상적인 단가표는 감이 안 오니 실제 워크로드 3종으로 계산해 보겠습니다.

시나리오 A — RAG 질의응답 (월 10만 요청)

요청당 입력 20K(그중 16K는 고정 접두부), 출력 1.5K로 가정합니다.

프롬프트 캐싱만으로 약 52% 절감입니다. RAG처럼 접두부가 고정된 워크로드에서는 캐시 설계가 곧 비용 설계입니다.

시나리오 B — 코드 에이전트 (272K 절벽 체감)

에이전트 태스크 하나에서 누적 입력 250K, 출력 27K가 발생한다고 합시다.

입력이 12% 늘었는데 비용은 98% 늘었습니다. 컨텍스트를 조금만 더 욱여넣은 대가가 요금 2배입니다. 에이전트 루프에 272K 하드 가드레일을 두고, 넘칠 것 같으면 요약·압축으로 접는 설계가 필수입니다. 컨텍스트 압축 기법은 에이전트 메모리와 컴팩션에서 자세히 다룹니다.

시나리오 C — 문서 대량 처리 (50만 건 배치)

건당 입력 8K, 출력 800 토큰 기준입니다.

지연에 둔감한 배치를 표준 티어로 돌리는 것만으로 $30,000을 버리는 셈입니다. 야간 배치·백필은 무조건 Batch 엔드포인트로 보내세요.

계산기 스니펫

팀 내부 추정용으로 쓸 수 있는 최소 계산기입니다.

RATES = {  # per 1M tokens
    "standard": {"in": 10.0, "cached": 1.0, "write": 12.50, "out": 50.0},
    "long":     {"in": 20.0, "cached": 2.0, "write": 25.00, "out": 75.0},  # 입력 > 272K
}
TIER_MULTIPLIER = {"batch": 0.5, "flex": 0.5, "standard": 1.0, "fast": 2.0}
LONG_CONTEXT_THRESHOLD = 272_000
 
 
def cost_per_request(fresh_in, cached_in, cache_write, out, tier="standard"):
    """한 요청의 비용(USD)을 계산한다. 토큰 수는 실제 개수로 넘긴다."""
    total_input = fresh_in + cached_in + cache_write
    rates = RATES["long" if total_input > LONG_CONTEXT_THRESHOLD else "standard"]
    usd = (
        fresh_in / 1e6 * rates["in"]
        + cached_in / 1e6 * rates["cached"]
        + cache_write / 1e6 * rates["write"]
        + out / 1e6 * rates["out"]
    )
    return usd * TIER_MULTIPLIER[tier]
 
 
# 시나리오 B 비교
print(cost_per_request(250_000, 0, 0, 27_000))  # 3.85
print(cost_per_request(280_000, 0, 0, 27_000))  # 7.63

5. 개발자 관점 API 동작

기존 GPT 계열 코드를 옮길 때 실제로 부딪히는 지점들입니다.

reasoning.effort 티어

Astra는 low · medium · high · xhigh · max 다섯 단계를 지원하고 none은 없습니다. 상위 티어일수록 사고 토큰이 늘어 품질은 오르지만 출력 토큰(=비용)과 지연이 함께 증가합니다. 워크로드별로 최소 티어부터 올려가며 측정하는 것이 정석입니다.

from openai import OpenAI
 
client = OpenAI()
 
resp = client.responses.create(
    model="gpt-6-astra",
    input="이 리포지터리의 테스트 실패 원인을 찾아 수정 PR을 올려줘",
    reasoning={"effort": "high"},   # low | medium | high | xhigh | max
    text={"verbosity": "low"},      # Astra는 기본이 장황하다
    tools=[{"type": "mcp", "server_label": "internal-tools"}],
)
print(resp.usage)  # 입력·캐시·출력 토큰을 반드시 로깅할 것

verbosity를 명시적으로 낮추세요

Astra는 기본적으로 길고 잘 꾸며진 답변을 냅니다. 마크다운 표와 머리말을 알아서 붙이는 편이라, 로그 한 줄·JSON 한 덩어리만 필요한 자리에 그대로 쓰면 출력 토큰이 낭비됩니다. 원하는 문체·구조·분량을 시스템 프롬프트에서 명시적으로 지정하세요.

usage를 반드시 기록하세요

과금 구조가 다층이므로 usage 필드(입력/캐시 읽기/캐시 쓰기/출력/사고 토큰)를 요청 단위로 남기지 않으면 어디서 돈이 새는지 사후에 알 수 없습니다. 특히 272K를 넘긴 요청은 별도 지표로 카운트해 알람을 거는 것을 권합니다. 에이전트 계측 전반은 AgentOps 옵저버빌리티를 참고하세요.

opaque recurrence

Astra는 요청 사이에 추론 상태를 불투명한 형태로 보존·재사용하고, 긴 대화에서는 컴팩션을 적용합니다. 이전 작업을 다시 계산하지 않으니 토큰 효율에 유리합니다.

문제는 그 상태가 사람이 읽을 수 있는 형태가 아니라는 점입니다. OpenAI 스스로 "모델 능력이 올라가면서 모니터 가능성(monitorability)이 어려워지고 있다"고 인정했습니다. 모델이 언어 토큰을 거의 쓰지 않고 작업을 수행할 수 있다는 뜻이고, 이는 사고 과정(chain of thought) 감사를 전제로 한 규제 환경에서는 그 자체가 결격 사유가 될 수 있습니다.

6. 어디에 쓰고, 어디에 쓰지 말까

잘 맞는 곳

• 브라우저·터미널 자동화 — OSWorld 72.6%, ScreenSpot-Pro 92.7%, Terminal-Bench 선두. 사람이 화면을 보며 하던 반복 업무를 위임하기에 현재 가장 나은 선택지입니다.
• 롱호라이즌 코드 에이전트 — 대규모 코드베이스 탐색, 다단계 리팩터링. 1M 컨텍스트 + 낮은 토큰 소모의 조합이 여기서 값어치를 합니다.
• SRE·운영 자동화 — SRE-Bench 88%. 런북 실행, 장애 트리아지 보조. Kafka DR 런북 같은 절차형 작업과 궁합이 좋습니다.
• 대량 문서 처리 — Batch 티어와 결합하면 단가 부담이 절반으로 내려갑니다.

다시 생각해야 할 곳

• 단순 분류·짧은 요약 — effort: none이 없어 최소 사고 토큰이 강제됩니다. 구조적으로 낭비입니다. 소형 LLM 사이징 가이드 기준으로 작은 모델을 쓰세요.
• 저지연 실시간 경로 — 추론 지연이 있고, Fast 모드는 2배 요금에 EU 레지던시에서는 아예 못 씁니다.
• CoT 감사가 의무인 규제 환경 — opaque recurrence가 정면으로 걸립니다.
• 순수 지식·추론 품질이 최우선 — Humanity's Last Exam·독립 종합 지수에서는 Claude Fable 5.1이 앞섭니다.

권장 패턴: Astra로 오케스트레이션, 잔업은 작은 모델로

현실적인 구성은 단일 모델이 아니라 티어링입니다.

프런티어 모델은 "판단"에만 쓰고 "노동"은 아래로 내리는 것이 비용·지연 양쪽에서 유리합니다.

7. 도입 전 체크리스트

Astra를 프로덕션에 올리기 전에 최소한 이만큼은 확인하세요.

• 272K 가드레일 — 에이전트 루프에 입력 토큰 상한을 걸고, 초과 시 요약·컴팩션으로 접는 경로가 있는가
• 프롬프트 캐시 설계 — 고정 접두부를 캐시에 태우고 있는가. 재사용이 적은 프롬프트를 불필요하게 캐시 쓰기하고 있지는 않은가
• Batch 라우팅 — 지연에 둔감한 작업이 표준 티어로 새고 있지 않은가
• effort 티어 측정 — 워크로드별 최소 effort를 실측으로 정했는가 (기본값 high로 방치 금지)
• verbosity 통제 — 기계가 소비하는 출력에 장황한 서식이 붙고 있지 않은가
• usage 로깅·알람 — 입력/캐시/출력/사고 토큰을 요청 단위로 남기고, 272K 초과 요청에 알람이 걸려 있는가
• CoT 감사 정책 — opaque recurrence로 사고 과정 감사가 불가능한 점을 보안·컴플라이언스 팀과 합의했는가
• Critical 분류 승인 — 사이버보안 Critical 임계 모델이라는 점(ExploitBench 100%)에 대한 사내 사용 정책이 있는가. 에이전트 보안 참고
• 리전 제약 — EU 데이터 레지던시가 필요한데 Fast 모드를 전제한 설계는 아닌가

8. 정리 — 어떻게 판단할까

Astra가 보여준 진짜 변화는 벤치마크 순위가 아니라 비용을 재는 단위가 바뀌었다는 점입니다. 토큰 단가는 올랐는데 태스크 비용은 내려갔고, 그 차이를 만든 것은 모델이 "적은 토큰으로 끝내는 능력"이었습니다. 반대로 말하면, 토큰을 낭비하게 만드는 설계(무한정 자라는 컨텍스트, 통제되지 않은 effort, 장황한 출력)는 이 모델에서 더 크게 벌을 받습니다.

결론은 늘 같은 질문으로 돌아옵니다. "이 작업에 이 정도 지능이 필요한가, 우리 예산 구조에 맞는가, 감사 요건을 통과하는가." Astra는 그중 첫 번째 질문에 가장 강력한 답을 내놓았지만, 나머지 두 개는 여전히 우리가 설계해야 할 몫입니다.

LLM 도입·비용 최적화를 검토 중이시라면 문의하기로 연락 주세요.

용어집

본문에 나온 용어를 한자리에 정리했습니다. 더 넓은 AI 용어는 AI 용어집을 참고하세요.