GPT-6 세대의 모델 3개가 3주 만에 출시되었습니다. 9월 3일에 플래그십인 GPT-6 Astra가, 9월 22일에는 GPT-6 Sol과 GPT-6 Luna가 공개되었습니다. 이름은 GPT-5.6 세대와 동일한 'Sol', 'Luna'를 계승하고 있지만, 모델 계층 내에서의 위치는 바뀌었습니다. 코드에서 gpt-5.6-sol을 gpt-6-sol로 수정하면 될지, 아니면 최상위 Astra로 전환해야 할지 판단하기 어려워하는 분들이 많으실 겁니다.
대상 독자는 OpenAI API를 GPT-6 계열로 전환하려는 개발자입니다.
- GPT-6 Astra / Sol / Luna의 포지셔닝과 GPT-5.6 세대 대비 계층 변화
- 3개 모델의 API 요금 및 GPT-5.6 세대 대비 변동 사항
- 실제로 API를 호출하며 확인한 마이그레이션 시의 함정 (Astra 접근 제한,
max_tokens 거부, 툴 호출과 reasoning effort・샘플링 파라미터 조합 제약)
요금, 성능, 출시 경위는 공식 발표를 보도한 이차 정보에 근거하여 정리했으며 출처를 명시합니다. API의 동작(모델 목록・오류 내용・응답 형식・파라미터 조합)만은 필자가 실제로 요청을 보내 확인한 결과입니다.
- GPT-6 세대는 **Astra (최상위) → Sol (중간) → Luna (고속/대량 처리)**의 3단계 구조입니다. GPT-5.6 세대에서 최상위였던 Sol은 중간 단계로 내려왔으며, 중간 단계였던 Terra의 후계는 준비되어 있지 않습니다. API 요금은 Astra가 입력 $10 / 출력 $50 (100만 토큰당), Sol이 $2 / $10, Luna가 $0.10 / $0.50으로 보도되었습니다. Sol과 Luna는 전 세대 대비 약 절반 수준입니다.
- 실제로 시도해 본 결과, 필자의 API 프로젝트에서는
gpt-6-astra가 모델 목록에 나타나지 않았고, 직접 호출하면 model_not_found로 거부되었습니다.
gpt-6-sol은 max_tokens를 수용하지 않아 max_completion_tokens로 수정해야 했습니다.gpt-6-sol을 Chat Completions에서 툴 호출과 함께 호출하면 기본적으로 거부되므로, reasoning_effort: "none"을 추가하거나 Responses API로 전환할 필요가 있었습니다.
GPT-6 세대의 3개 모델은 발표 시점과 역할이 구분되어 있습니다. 보도 내용을 바탕으로 정리하면 다음과 같습니다.
| 모델 | 발표 | 역할 (보도 기반) |
|---|
| GPT-6 Astra | 2026-09-03 (한정 프리뷰) → 09-04부터 순차 확대 | 세대 전체의 플래그십 |
| ... | | |
MindStudio의 해설에 따르면, Astra는 먼저 제한된 테스터와 파트너 조직에게 제공되며, 이후 ChatGPT Plus / Pro / Business / Enterprise 및 API, Amazon Bedrock, Microsoft Azure 등으로 확산될 계획이었습니다. TechCrunch는 Sol과 Luna에 대해 ChatGPT Work・Codex・API에서 대부분의 유료 계정이 사용할 수 있게 되었으며, Luna는 Free와 Go 사용자에게도 개방되었다고 보도했습니다.
이름은 같아도 내용은 다릅니다. GPT-5.6 세대는 Sol・Terra・Luna 3단계 구조였으며, Sol이 최상위였습니다. GPT-6 세대에서는 Astra가 그 위에 위치하며, Sol은 중간 단계로, Luna는 고속/대량 처리에 배치 재조정되었습니다. Aivy의 비교 기사 등의 보도에 따르면, GPT-5.6의 중간 단계였던 Terra에 상응하는 GPT-6 버전은 없는 것으로 정리됩니다. 같은 기사에 따르면 GPT-5.6의 Sol・Terra・Luna는 계속 제공되기 때문에, GPT-6의 등장으로 구형 모델이 즉시 사용 불가능해지는 것은 아닙니다.
여기서 주목해야 할 점은, gpt-6-sol은 gpt-5.6-sol
이는 개량판이라기보다는 “Astra와 동일한 방식으로 훈련된 새로운 중급 모델”이라는 점입니다. TechCrunch에 따르면, OpenAI는 GPT-6 Sol에 대해 “이전 세대보다 오류가 약 절반이며, Astra급의 신뢰성을 훨씬 낮은 비용으로 구현한다”고 설명했습니다. MacRumors 역시 전문 작업(professional task), 사실성(factuality), 코딩, 컴퓨터 조작, 정렬(alignment) 개선 사항을 저렴한 모델에 도입했다고 전하고 있습니다.
API 요금을 GPT-5.6 세대와 비교하면, 모델별로 가격 변동 방향이 서로 반대인 것을 알 수 있습니다 (모두 100만 토큰당 미국 달러 기준).
| 모델 | 입력 | 출력 | GPT-5.6 세대와의 비교 |
|---|
| GPT-6 Astra | $10 | $50 | GPT-5.6 Sol ($4 / $20)의 2.5배 |
| ... | | | |
| 출처: Astra는 eesel AI, Sol과 Luna는 MacRumors, GPT-5.6 세대는 Codersera의 정리 자료를 따릅니다. 참고로 GPT-5.6 Sol의 $4 / $20은 프로모션 가격이며, Codersera는 이 가격이 최소 2026년 11월 21일까지 지속될 것이라고 설명했습니다. | | | |
Astra는 사용 형태에 따라 단가가 크게 변동합니다. eesel AI가 정리한 내역은 다음과 같습니다.
| Astra의 사용 형태 | 입력 | 출력 |
|---|
| Standard | $10 | $50 |
| ... | | |
| 장문 컨텍스트(context) 행의 경우, 입력이 272K 토큰을 초과하는 시점부터 전체 요청에 이 단가가 적용된다고 설명되어 있습니다. 큰 문서를 통째로 전달하는 방식에서는 예상보다 훨씬 높은 청구가 발생할 수 있으니 주의가 필요합니다. | | |
이 표에서 읽어낼 수 있는 마이그레이션의 기준은 두 가지입니다. GPT-5.6 Terra ($2 / $12)를 사용하던 워크로드는 입력 단가가 같고 출력 단가가 저렴한 GPT-6 Sol이 자연스러운 마이그레이션 대상이 됩니다. 반면, GPT-5.6 Sol (프로모션 가격 $4 / $20)에서 “최상위 모델이니까”라는 이유만으로 Astra로 전환할 경우, 단가는 2.5배 급등합니다. 이전 세대의 최상위를 그대로 최상위로 대체하기보다는, 용도별로 Sol과 Astra를 재선택하는 것이 안전합니다.
여기서는 필자가 OpenAI API에 실제로 요청을 보내 확인한 결과를 공유합니다. 환경은 OPENAI_API_KEY를 환경 변수로 전달하여 클라우드상의 셸에서 curl을 이용해 Chat Completions API 및 Responses API를 호출하는 구성입니다. 확인 과정은 다음과 같았습니다.
먼저, 본인의 API 키로 사용할 수 있는 모델 목록을 가져왔습니다.
curl -s https://api.openai.com/v1/models -H "Authorization: Bearer $OPENAI_API_KEY"
반환된 목록에는 gpt-6-sol과 gpt-6-luna가 포함되어 있었지만, gpt-6-astra는 보이지 않았습니다.
목록에 없다고 해서 호출할 수 없는 것은 아니기 때문에, gpt-6-astra를 지정하여 직접 요청을 보내보았습니다.
curl -s https://api.openai.com/v1/chat/completions \
-H "Authorization: Bearer $OPENAI_API_KEY" -H "Content-Type: application/json" \
-d '{"model":"gpt-6-astra","messages":[{"role":"user","content":"hello"}],
하지만 메시지를 읽어보면 '모델이 존재하지 않는다'는 의미가 아니라 '이 프로젝트에 접근 권한이 없다'는 의미입니다. 이 요청에는 후술할 `max_tokens`도 포함되어 있지만, 파라미터 검증보다 먼저 접근 권한에서 차단되고 있습니다.
일반 제공이 시작되었다고 보도된 이후에도 적어도 필자의 프로젝트에서는 Astra가 기본적으로 사용 가능한 상태가 아니었습니다. 어떤 설정이나 조건으로 접근이 열리는지는 확인할 수 없었습니다. Astra를 전제로 마이그레이션 계획을 세울 경우, 먼저 자신의 프로젝트에서 `GET /v1/models`의 결과에 `gpt-6-astra`가 포함되어 있는지 확인하는 것이 확실합니다.
참고로 공식 문서(Latest Model Guide・GPT-6 Astra 모델 페이지)에 따르면, Astra는 reasoning effort의 `none`을 지원하지 않으며, 대신 `low`를 사용해야 한다고 합니다. 이 제약 자체는 필자의 환경에서는 Astra에 접근할 수 없어 실제 검증할 수는 없었지만, 후술할 `gpt-6-sol`의 검증 결과(reasoning effort가 `none`이 아닐 때 샘플링 파라미터를 제거해야 하는 동작)와 일치하는 내용입니다.
다음으로, `gpt-6-sol`을 기존처럼 `max_tokens`를 붙여 호출했습니다.
curl -s https://api.openai.com/v1/chat/completions
-H "Authorization: Bearer $OPENAI_API_KEY" -H "Content-Type: application/json"
-d '{"model":"gpt-6-sol","messages":[{"role":"user","content":"1문으로 자기소개해"}],"max_tokens":100}'
{"error":{"message":"Unsupported parameter: 'max_tokens' is not supported with this model. Use 'max_completion_tokens' instead.","type":"invalid_request_error","param":"max_tokens","code":"unsupported_parameter"}}
`max_tokens`는 무시되는 것이 아니라, 요청 자체가 실패합니다. 오래된 샘플 코드나 사내 래퍼에서 `max_tokens`를 고정으로 전달하고 있는 경우, 모델명만 `gpt-6-sol`로 변경하면 모든 요청이 오류가 발생합니다.
파라미터 이름만 `max_completion_tokens`로 바꾸어 재전송했습니다.
curl -s https://api.openai.com/v1/chat/completions
-H "Authorization: Bearer $OPENAI_API_KEY" -H "Content-Type: application/json"
-d '{"model":"gpt-6-sol","messages":[{"role":"user","content":"1문으로 자기소개해"}],"max_completion_tokens":200}'
이번에는 정상적으로 응답이 돌아왔습니다(주요 부분만 발췌했습니다).
{
"model": "gpt-6-sol",
"choices": [{"message": {"role": "assistant", "content": "저는, 질문에 대한 답변이나 문서 작성을 도와드리는 AI 어시스턴트입니다."}, "finish_reason": "stop"}}],
...
`usage.prompt_tokens_details`에는 `cached_tokens`와 함께 `cache_write_tokens`라는 필드가 포함되어 있었습니다. 이는 Astra의 요금표에서 캐시 쓰기(Cache write)에 별도의 단가가 설정된 것과 대응하는 항목이라고 생각됩니다. 비용 집계를 `prompt_tokens`와 `completion_tokens`
2개 항목만으로 구성할 경우, 캐시 쓰기 과금(cache write billing)이 보이지 않을 가능성이 있으므로, 집계 측에서 이 필드도 함께 가져오는 것이 안전합니다. 참고로, 이 필드가 어느 세대부터 출력되는지는 확인하지 않았습니다.
`completion_tokens_details.reasoning_tokens`
이번에는 0이었습니다. 한 문장으로 된 자기소개라는 가벼운 질문이었기 때문에, 어려운 작업에서 얼마나 증가할지는 이번 범위에서는 측정하지 못했습니다.
앞선 응답에서는 `temperature`를 지정하지 않았습니다. 기본값이 아닌 값을 명시했을 때 어떻게 되는지 확인해 보았습니다.
curl -s https://api.openai.com/v1/chat/completions
-H "Authorization: Bearer $OPENAI_API_KEY" -H "Content-Type: application/json"
-d '{"model":"gpt-6-sol","messages":[{"role":"user","content":"한 문장으로 자기소개해"}],"max_completion_tokens":100,"temperature":0.7}'
{"error":{"message":"Unsupported value: 'temperature' does not support 0.7 with this model. Only the default (1) value is supported.","type":"invalid_request_error","param":"temperature","code":"unsupported_value"}}
`gpt-6-sol`은 기본 reasoning effort(이후 확인 8에서 `medium`임을 알았습니다) 상태일 때, `temperature`에 기본값(1) 이외의 값을 전달하면 거부됩니다. GPT-5.1 이전 설정을 그대로 가져와 `temperature: 0.7` 같은 코드를 그대로 `gpt-6-sol`에 적용하면, 모델 이름만 바꿨을 뿐인데도 작동하지 않습니다.
날씨를 조회하는 함수를 하나 정의하고, `gpt-6-sol`에게 Chat Completions에서 도구 호출이 포함된 요청을 보냈습니다.
curl -s https://api.openai.com/v1/chat/completions
-H "Authorization: Bearer $OPENAI_API_KEY" -H "Content-Type: application/json"
-d '{"model":"gpt-6-sol","messages":[{"role":"user","content":"도쿄의 날씨를 조사해줘"}],"max_completion_tokens":300,"tools":[{"type":"function","function":{"name":"get_weather","description":"지정된 도시의 날씨를 가져옵니다","parameters":{"type":"object","properties":{"city":{"type":"string"}},"required":["city"]}}}]}'
{"error":{"message":"Function tools with reasoning_effort are not supported for gpt-6-sol in /v1/chat/completions. To use function tools, use /v1/responses or set reasoning_effort to 'none'.","type":"invalid_request_error","param":"reasoning_effort","code":null}}
이 에러 메시지는 드물게 해결 방법까지 적어주고 있습니다. 즉, "Responses API를 사용하거나, `reasoning_effort`를 `none`으로 설정하라"는 지시입니다.
에러 메시지의 지시에 따라 `reasoning_effort: "none"`을 추가하여 다시 전송했습니다.
tool_calls가 정상적으로 반환되었습니다. 확인 6과의 요청 차이는 `reasoning_effort: "none"` 한 줄뿐입니다. 기존의 'Chat Completions + tools' 코드를 `gpt-6-sol`로 마이그레이션하는 가장 빠른 수정 방법은 이 하나의 파라미터 추가가 됩니다.
같은 툴 정의를 이번에는 Responses API(`/v1/responses`)에 넣어 보았습니다. 이때는 `reasoning_effort`를 지정하지 않았습니다.
curl -s https://api.openai.com/v1/responses
-H "Authorization: Bearer $OPENAI_API_KEY" -H "Content-Type: application/json"
-d '{"model":"gpt-6-sol","input":"東京の天気を調べて","max_output_tokens":300,"tools":[{"type":"function","name":"get_weather","description":"指定した都市の天気を取得する","parameters":{"type":"object","properties":{"city":{"type":"string"}}},"required":["city"]}}]}'
{
"model": "gpt-6-sol",
"output": [{"type": "function_call", "arguments": "{"city":"東京"}", "name": "get_weather", "status": "completed""}],
...
`reasoning_effort`를 아무것도 지정하지 않았음에도 불구하고, Responses API에서는 툴 호출이 그대로 성공했습니다. 응답에 포함된 `reasoning.effort`를 보면, `gpt-6-sol`의 기본값은 **medium**이라는 것도 알 수 있었습니다 (공식 문서에는 기본값이 기재되어 있지 않아 이번 실측으로 확인한 값입니다). 아울러 `temperature: 1.0` / `top_p: 0.98`이 기본값으로서 응답에 명시된 점도 확인할 수 있었습니다. `top_p`의 기본값이 정확히 1.0이 아니라 0.98이라는 점은 이번 요청을 보내기 전까지는 알지 못했던 부분입니다. 즉, `gpt-6-sol`의 'Chat Completions에서는 툴이 reasoning_effort와 충돌한다'라는 제약은, reasoning effort를 명시적으로 `none`으로 설정하지 않는 한 Responses API로 전환하는 것이 더 확실하다는 의미가 됩니다. 기존 코드가 툴을 많이 사용하고 있다면, 파라미터를 하나 추가하는 임시방편보다는 Responses API로의 이전을 고려하는 것이 장기적으로 안전합니다.
실제로 시도해 본 결과, 막힌 부분은 성능이 아니라 '호출 가능 여부' 직전이었습니다. 필자가 의외였던 점은, 확인 2와 확인 3의 두 에러가 모두 `invalid_request_error`라는 같은 종류로 반환된다는 점입니다. 에러의 `type`
단순히 리트라이(retry) 판정이나 알림을 분기시키는 방식으로만 처리하면, '접근 권한 없음(설정으로 해결)'과 '매개변수 오류(코드로 해결)'가 같은 취급을 받게 됩니다. 마이그레이션 시 로그를 모니터링할 때는 `code`의 값(`model_not_found`와 `unsupported_parameter`)까지 확인하여 분기하는 것이 실무적입니다.
또 다른 장점은 오류 메시지가 수정 방법까지 알려준다는 점입니다. 예를 들어, `max_tokens` 오류는 'Use 'max_completion_tokens' instead.'라고 안내하고, 툴 호출 오류는 'use /v1/responses or set reasoning_effort to 'none''과 같이 구체적인 해결책을 제시합니다. 메시지만 읽어도 몇 줄의 수정으로 문제가 해결됩니다. 반면 Astra의 접근 거부 사유는 메시지만으로는 어떤 설정을 해야 열리는지 알기 어렵습니다. 마이그레이션 작업 견적을 낼 때는 코드로 해결할 문제와 프로젝트 또는 조직 설정 대기가 필요한 문제를 분리하여 생각하면 재작업(hand-back)을 줄일 수 있습니다.
마지막으로, 기존 코드를 GPT-6 계열로 전환하기 전에 확인해야 할 항목들을 나열합니다.
- **사용하려는 모델이 프로젝트에서 활성화되었는지** : `GET /v1/models` 결과에 `gpt-6-astra`/`gpt-6-sol`/`gpt-6-luna`가 포함되어 있는지 확인합니다. 필자의 환경에서는 Astra가 포함되어 있지 않았습니다.
- **`max_tokens` 전달 여부**: `gpt-6-sol`은 `max_tokens`를 거부합니다. SDK의 래퍼(wrapper)나 공통 설정 파일에 `max_tokens`가 남아있지 않은지 검색하여 `max_completion_tokens`로 대체해야 합니다.
- **기본 추론 노력(reasoning effort) 값**: 기본값인 `temperature`/`top_p`를 고정 값으로 전달하지 않았는지 확인합니다. `gpt-6-sol`은 기본값(`medium`) 상태에서 `temperature`에 기본값(1)이 아닌 다른 값을 전달하면 거부됩니다. 따라서 값을 제거하거나, `reasoning_effort: "none"`로 전환하는 것을 선택해야 합니다.
- **툴 호출을 Chat Completions에서 사용하지 않는지**: `gpt-6-sol`에서 Chat Completions + tools를 사용하려면 `reasoning_effort: "none"`이 필수입니다. 툴을 상시적으로 사용하는 경우 Responses API로의 전환을 고려합니다. Astra는 공식 문서에 응답(Responses) API가 툴 호출에 필수라는 제약 사항이 명기되어 있습니다 (필자는 접근 권한이 없어 미검증).
- **오류 분기 처리**: 접근 권한 부족과 매개변수 불비 문제는 모두 `code`까지 확인하는 `invalid_request_error`로 반환됩니다.
- **비용 집계가 새로운 사용량 항목을 포함했는지**: `cache_write_tokens`나 `reasoning_tokens`를 무시하고 있는지 확인해야 합니다.
- **마이그레이션 대상을 단가 기준으로 재검토했는지**: GPT-5.6 Terra의 사용분은 GPT-6 Sol로, GPT-5.6 Sol의 사용분은 GPT-6 Sol과 Astra 중 어떤 것이 용도에 더 적합한지 검토해야 합니다. Astra는 전 세대 최고 모델 대비 2.5배 높은 단가이며, 입력이 272K를 초과할 경우 전체 요청이 장문 컨텍스트 요금으로 부과된다고 알려져 있습니다.
Luna의 경우, 이번에는 응답 속도나 품질, 그리고 `reasoning_effort`의 기본값을 직접 측정하지 않았습니다. 만약 요약이나 추출 같은 대량 처리를 Luna에 의존할 계획이라면, 자신의 데이터로 품질과 레이턴시를 측정한 후 전환하는 것을 권장합니다.
- GPT-Rosalind 입문 — 신약 개발 및 게놈 연구에 특화된 OpenAI 최초의 생명과학 AI 전반
- GPT-5.4 Thinking 입문 — reasoning.effort와 OSWorld-V 75% 추론 AI를 API로 활용하기
- GPT-5.4 mini & nano 입문 — 서브 에이전트 시대의 경량 모델을 API로 활용하는 방법
- GPT-6 Astra 가격 책정, API 비용 및 출시 현황 | MindStudio (출처: 'GPT-6 라인업 전체 개요')
- GPT-6 Astra 가격 책정: 2026년 모든 API 티어 및 ChatGPT 플랜 | eesel AI (출처: '요금 비교')
- OpenAI, 더 낮은 비용과 적은 오류를 자랑하는 GPT-6 Sol 및 Luna 출시 | TechCrunch (출처: 'GPT-6 라인업 전체 개요')
- OpenAI의 새로운 GPT-6 Sol 및 Luna 모델, 더 저렴한 티어에 Astra 개선 사항 도입 | MacRumors (출처: '요금 비교')
- GPT-6 Astra 대 Sol 대 Luna: 어떤 작업에 어떤 티어가 적합한가 | Aivy (출처: 'GPT-5.6 세대부터의 계층 변화')
- GPT-5.6 Sol, Terra 및 Luna: 티어 및 가격 책정 (2026년) | Codersera (출처: '요금 비교')
- OpenAI의 GPT-6 Sol 및 GPT-6 Luna가 이제 사용 가능 | GitHub Changelog (제공 시작일 확인용)
- OpenAI API 최신 모델 가이드 (출처: '확인 2'에서 Astra의 추론 노력(reasoning effort) 제약 출처로 인용)
- GPT-6 Astra 모델 페이지 | OpenAI (출처: '확인 2'에서 Astra의 추론 노력(reasoning effort) 제약 출처로 인용)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
