GPT-6 삼형제 사용 설명서 — Astra·6.1 Sol·Luna, 무엇이 달라졌고 언제 무엇을 쓰나

크게 보기

들어가며: 한 달 사이 세 번의 발표

OpenAI의 9월은 바빴습니다. 3일에 최상위 모델 GPT-6 Astra를 공개했고, 22일에 그 아래 두 등급인 GPT-6 Sol과 GPT-6 Luna를 내놓았고, 29일 DevDay에서는 Sol을 크게 고친 GPT-6.1 Sol과 가장 빠른 속도 등급 Ultrafast를 발표했습니다. 이름도 바뀌었습니다. 별(Astra), 해(Sol), 달(Luna)이라는 이름이 곧 등급입니다.

이 글은 OpenAI 발표문 네 편(Astra, Sol·Luna, 6.1 Sol, DevDay 요약)과 개발자 문서(Using GPT-6 가이드, 모델 페이지, 모델 선택 가이드, 추론·캐싱·비동기 도구·스티어링·Ultrafast 문서)를 읽고 정리했습니다. 발표문의 차트는 그림만 있고 숫자가 본문에 없어서, 페이지에 내장된 차트 원자료를 직접 뽑아 다시 그렸습니다. 어제 쓴 Claude Opus 5.5 사용 설명서와 짝을 이루는 글이라, 마지막에 두 회사의 모델을 나란히 놓고 비교합니다.

1. 라인업과 가격

가격표에서 놓치기 쉬운 것이 셋 있습니다.

• 272K 입력을 넘으면 요청 전체가 비싸집니다. 입력과 캐시 단가 2배, 출력 1.5배입니다. 1M 컨텍스트를 채울수록 단가가 바뀝니다.
• 캐시가 공짜로 써지지 않습니다. GPT-5.6부터 캐시 쓰기에 입력 단가의 1.25배가 붙습니다. 대신 6.1 Sol의 캐시 읽기는 입력의 5%(0.10달러)로 다른 모델(10%)의 절반입니다. 같은 문맥을 반복해서 보내는 에이전트에 유리합니다.
• 빠를수록 비쌉니다. Fast mode는 표준의 2배 가격에 최대 2배 빠르고, Astra의 Ultrafast는 입력 60달러·출력 300달러(표준의 6배)입니다. Batch와 Flex는 절반입니다.

크게 보기

Ultrafast는 DevDay의 화제였습니다. API에서 최대 6배, Codex에서 최대 8배(초당 300토큰) 빠르고, 월 500달러의 새 Pro 요금제와 Enterprise에서 ChatGPT Work·Codex로 쓸 수 있습니다. 6.1 Sol 발표문은 "6.1 Sol Ultrafast로 기존 Astra와 거의 같은 API 비용에 Astra급 지능을 최대 8배 빠르게"라고 했지만, DevDay 요약은 6.1 Sol Ultrafast를 "곧 출시"로 적었고 9월 30일 현재 API 요금표에는 Astra만 올라 있습니다. Ultrafast는 WebSocket 연결을 강하게 권장하고(연결 비용이 속도 이득을 깎기 때문), 기본 한도가 분당 50만~500만 토큰으로 낮습니다.

2. 성능: 발표문 차트를 다시 그리면

Astra: 최상위 모델의 성적표

Astra 발표문의 표 일부입니다. 모든 수치는 OpenAI 측정이며, Claude 수치는 OpenAI가 공개 보고서에서 인용했거나 직접 잰 것입니다.

본문에는 이런 수치도 있습니다. Terminal-Bench Science 64.6%(Fable 5.1 52.6%), Agents' Last Exam 59.3%(Opus 5 55.5%, 이때 Opus 5보다 출력 토큰 약 65% 적음), GPQA Diamond 96.0%. OSWorld 2.0 지연 시뮬레이션에서는 작업당 약 40분에 72.6%로, GPT-5.6 Sol의 약 75분·65.7%보다 빠르고 정확했습니다. 수학에서는 무한히 많은 소수 쌍이 존재하는 간격의 상한을 240에서 186으로 낮추는 데 기여했다고 밝혔습니다.

비용 대비 점수 곡선

아래 차트는 Sol·Luna 발표문과 6.1 Sol 발표문에 내장된 차트 데이터를 그대로 옮긴 것입니다. 같은 모델이라도 추론 수준(낮음 → 최대)에 따라 점이 다섯 개씩 찍혀 있어, "이 점수를 얼마에 사는가"를 한눈에 볼 수 있습니다.

크게 보기

곡선을 보면 세 가지가 눈에 띕니다.

한 가지 수치 불일치도 적어 둡니다. Terminal-Bench Science에서 Astra는 Astra 발표문에서 64.6%, 6.1 Sol 발표문에서 68.1%로 보고됐습니다. 측정 시점이나 설정이 다른 것으로 보이지만 발표문에는 설명이 없습니다. 6.1 Sol 발표문 기준으로 이 과제의 작업당 비용은 6.1 Sol 최대 5.47달러, Opus 5.5 23.21달러, Astra 23.80달러였습니다.

Sol과 Luna: 이전 세대 대비

Sol·Luna 발표문의 요지는 "GPT-5.6보다 싸고 좋아졌다, 그리고 가격대가 비슷한 경쟁 모델보다 낫다"입니다.

• AutomationBench: 6 Sol 매우 높음(33.2%)이 Claude Opus 5 최대(26.9%)보다 높고 작업당 비용은 Opus 5의 9%. Luna 높음은 이전 Luna보다 5.4%p 높고 비용은 58% 낮음.
• Agents' Last Exam: 6 Sol 최대 56.4%로 Opus 5 최고점(55.9%)을 넘고 비용은 60% 낮음.
• DeepSWE: 6 Sol 최대 68.8%로 Fable 5 최고점(69.9%)과 1.1%p 차이, 비용은 약 80% 낮음. Luna 최대 66.6%로 Opus 5·Fable 5 중간 수준과 비슷하고 비용은 93~96% 낮음.
• 사실 오류: 사용자가 오류를 신고했던 대화에서 6 Sol의 오류가 이전 모델의 약 절반. Luna도 추론을 올리면 약 1/100 비용으로 GPT-5.6 Sol과 비슷.

크게 보기

Luna는 흥미로운 모델입니다. DeepSWE에서 추론 낮음은 2.4%로 거의 풀지 못하지만, 중간 44.5%, 최대 66.6%로 가파르게 오릅니다. 그래도 최대의 작업당 비용이 0.22달러라 GPT-6 Sol 낮음(0.16달러, 37.2%)과 비슷한 돈으로 훨씬 높은 점수를 냅니다. Luna는 낮은 추론으로 싸게 쓰는 모델이면서, 동시에 높은 추론으로 '싼 코딩 에이전트'가 될 수도 있는 모델입니다.

3. 이전 모델과 무엇이 다른가

API: GPT-5.6 → GPT-6

GPT-5.5 이하에서 오는 경우에는 캐싱이 크게 바뀝니다. prompt_cache_retention 대신 prompt_cache_options.ttl: "30m"을 쓰고, 캐시 수명은 마지막 쓰기·재사용 후 최소 30분입니다. 암묵적 중단점이 최신 메시지 끝으로 옮겨졌고, 캐시 접두사가 끝나는 지점을 직접 고르는 명시적 중단점이 생겼습니다. 최소 캐시 길이는 보이는 입력 1,024토큰입니다. OpenAI는 이 개선으로 GitHub Copilot이 새로 처리해야 하는 프롬프트 토큰 비율이 50% 넘게 줄었다고 소개했습니다.

행동: 공식 가이드가 꼽은 다섯 가지

OpenAI의 Using GPT-6 문서는 Astra에서 관찰한 행동 다섯 가지를 꼽고 각각에 대한 프롬프트를 줍니다. Sol과 Luna에도 출발점으로 쓰라고 합니다.

Sol·Luna 발표문은 Astra에서 개선한 소통 스타일도 두 모델에 적용했다고 밝혔습니다. 내용은 유지하면서 전문 용어와 어색한 표현, 불필요한 세부를 줄여 답이 조금 더 짧아졌다는 것입니다. 발표문이 든 예시에서 새 Sol은 "벤토 느낌"처럼 모호한 표현을 덜 쓰고, 무엇을 확인했고 무엇을 확인하지 않았는지 더 솔직하게 밝혔습니다.

4. 예시 프롬프트 14개: 원문과 한국어

[가이드]는 OpenAI의 Using GPT-6 문서, [평가]는 OpenAI가 벤치마크 실행에 실제로 쓴 개발자 메시지, [문서]는 다른 개발자 문서의 예시, [직접]은 문서의 원칙을 따라 이 글에서 쓴 예시입니다. 가이드는 이 프롬프트들이 Astra에서 관찰한 행동을 겨냥한 것이니, 고른 모델과 작업으로 평가하라고 강조합니다.

① 의도를 읽고 끝까지 가게 하기 [가이드]

크게 보기

상황. GPT-6는 이전 모델이라면 가정하고 넘어갔을 곳에서 묻습니다. 긴 작업의 일관성은 좋아졌지만, 사용자가 자리를 비운 사이 질문 하나에 멈춰 있을 수 있습니다.

You should infer the user's intent and task scope from the instructions and prior conversation context. Your job is to bias towards action and carry the user's intended task to completion.

When the user expresses intent to perform new work or fix an existing issue, persist until the user's intended goal is complete. Progress autonomously towards the user's goal (e.g. creating isolated worktrees / checkouts if needed, resolving merge conflicts, read-only actions, creating draft PRs etc.) unless they are clearly destructive or irreversible.

② "해 줄 수 있어?"는 실행 지시로 읽게 하기 [가이드]

When the user's prompt indicates a request for action, such as "can you...", "I want to...", "help me..." and similar expressions, treat these as instructions to do the work and take action. Do not stop at acknowledging capability (e.g. "Yes…"), proposing a plan, or offering to continue. Do not settle for a partial or "helpful enough" solution that does not fully satisfy the user's task to save time, effort or tokens. If a task requires sustained work, complete all the necessary work until the intended outcome is fulfilled.

한국어 사용자는 "~해 줄 수 있을까요?"처럼 공손한 의문형으로 부탁하는 일이 많습니다. 영어 원문의 예시 표현을 한국어 표현으로 바꿔 넣는 것만으로도 효과가 있을 수 있으니, 한국어 서비스라면 번역본에 자주 쓰이는 요청 표현을 더 넣어 보세요.

③ 승인은 검토할 수 있는 결과물 뒤에 [가이드]

Before asking the user clarifying questions, you should complete the work that is already authorized from context and necessary to make the proposed action concrete and reviewable. The user should be approving a concrete, reviewable result. For example, before deploying a change, writing to an external application, merging a PR or publishing a site, do all the required work first so that user approval is the final step. You don't need user permission for reversible tasks, read-only actions, reviews or fixes, or anything for which authorization is provided earlier in the session or strongly implied from the task instruction.

Do not introduce unsolicited warnings, disclaimers, approval flows, or safety/compliance checklists due to hypothetical risk.

가이드는 이렇게 하면 작업이 막히기 전에 할 수 있는 일을 다 해 두므로 더 빨리 끝나는 경우가 많다고 설명합니다. 모델은 일하는 중에 막히지 않는 질문을 던지는 경향도 있으니, 앱에 필요한 자율성 수준에 맞게 세 프롬프트를 조정하라고 합니다.

④ 사용자 지시가 스킬보다 우선 [가이드]

크게 보기

상황. GPT-6는 긴 지시를 더 잘 따르지만 그만큼 맥락 속 정보에 민감합니다. 스킬 파일의 불분명하거나 충돌하는 지시 때문에 일찍 멈출 수 있습니다.

The user's instructions take precedence over guidelines provided in a skill. If explicit user instructions conflict with a skill's instructions, prioritize the user's instructions.

⑤ 멈춘 이유가 된 스킬을 인용하게 하기 [가이드]

If a skill causes you to ask for permission or confirmation, pause, leave requested work unfinished, or diverge from the user's intent, name and link to the exact SKILL.md file you read, quote the relevant instruction, and briefly explain how it applies. Distinguish explicit skill requirements from your interpretation of guidelines.

가이드는 스킬과 AGENTS.md를 많이 싣는 앱에서 숨어 있거나 서로 충돌하는 지침을 찾아내는 도구로 이 프롬프트를 쓰라고 합니다. 실무 팁으로 옮기면, 새 모델로 바꾼 첫 주에는 이 프롬프트를 켜 두고 로그에서 인용된 스킬 문장을 모아 보세요. 그 목록이 곧 고쳐야 할 스킬 목록입니다.

⑥ 목록 대신 문단으로 쓰게 하기 [가이드]

Default to using clear, concise paragraphs, each developing one main idea. Use lists only when the information is genuinely parallel, sequential, or easier to compare, and avoid nested lists unless the hierarchy cannot be expressed clearly in prose. Use plain, simple language: familiar words, concrete examples, and precise verbs. Prefer active voice and direct statements.

Make sure to state the main point clearly and early, then develop it with the explanation and detail the reader needs. Let each sentence build on what came before. Develop the points that matter and provide enough support to be useful.

⑦ 기술적인 내용을 평이하게 [가이드]

Use plain language over jargon, and reference technical details only to the degree that it helps illustrate an idea or your work to the user. Communicate complex concepts in a clear and cohesive manner, and calibrate your writing to the level of background knowledge assumed from the user's prompt and context.

⑧ 슬롭 단어와 상투적 구조 금지 [가이드] + 한국어판 [직접]

Avoid using slop words or phrases like "Bottom Line:" in conclusions, "delve," "foster," "leverage," "it's worth noting," "importantly," "Question? Answer." or "This isn't about X. It's about Y.", "genuinely" or hyphenated compound descriptions and adjectives. Do not use concluding summary statements such as "In short:..", "The simplest mental model is:...".

State the intended action directly. Avoid adding what you won't do, what will remain unchanged, or how you'll separate or categorize results. Do not use contrastive framing such as "X, not Y" that introduces an unprompted alternative that the user didn't ask about. Avoid invented compound labels like "exact-head checks" and "editorial-row layouts", vague qualifiers, and canned transitions; use plain verbs and prepositions to state the actual relationship directly.

영어 슬롭 목록은 한국어 답변에 그대로 통하지 않습니다. 같은 원칙으로 한국어에서 자주 보이는 표현을 옮겨 본 예시입니다. Anthropic이 Opus 5.5 가이드에서 말한 것처럼 "AI 같은 문체를 피하라"는 두루뭉술한 말보다 피할 표현을 이름으로 적는 쪽이 잘 듣습니다.

⑨ 서브에이전트 위임 늘리기 [가이드]

상황. Anthropic은 Opus 5가 서브에이전트를 너무 쉽게 부른다고 경고했는데, OpenAI는 반대로 Astra가 원하는 것보다 덜 위임할 수 있다고 말합니다.

If at any point you can parallelize work by delegating tasks to another agent (no matter if you are the root or subagent), you should do so using collaboration tools if it could save time or improve quality.

⑩ 에이전트 사이의 메시지를 사람이 읽을 수 있게 [가이드]

상황. 에이전트끼리 주고받는 메시지에 문법 오류나 띄어쓰기 오류가 섞일 수 있습니다.

Messages that you send to other agents and your final answer may be read by a human, so ensure they are legible. Always put proper spaces between words and/or numbers.

⑪ 테스트 범위를 작업 크기에 맞추기 [가이드]

Do not write tests for reversible, low-impact changes that mirror the implementation. If you do choose to verify your work with tests, make sure that the tests are meaningful and necessary to verify implementation.

Run tests appropriate to the change and complete required checks. Once those pass, broaden or repeat testing only when new changes, failures, or unresolved concerns justify it; otherwise, continue toward completing the task.

⑫ OpenAI가 FrontierCode 평가에 실제로 쓴 개발자 메시지 [평가]

Astra 발표문 각주에 흥미로운 것이 있습니다. FrontierCode(바로 병합 가능한 코드인지 평가)에서 Astra를 돌릴 때, Codex가 쓰는 개발자 메시지의 한 부분과 비슷한 메시지를 넣었다는 것입니다. OpenAI는 이 프롬프트가 평가에 맞춰 최적화되지 않았다고 밝혔습니다. 한국어판 발표문에 실린 번역을 그대로 옮깁니다.

⑪과 같은 방향입니다. GPT-6로 코딩 에이전트를 만든다면, 이 문단은 AGENTS.md나 시스템 프롬프트에 거의 그대로 넣어 볼 만한 검증된 출발점입니다.

⑬ 비동기 도구를 쓰는 동안 기다리지 않게 [문서]

크게 보기

상황. 느린 조회 도구를 호출해 놓고, 그 결과와 상관없는 부분에 먼저 답하게 하고 싶을 때입니다. 비동기 도구 호출 문서의 예제에 들어 있는 지시문입니다.

Start the weather lookup and answer the independent packing question without waiting. Use the demo weather result when it arrives; never invent it.

핵심은 마지막 구절입니다. 결과를 기다리지 않고 계속 일하는 모델에게는 "도착하기 전에는 그 값을 지어내지 말라"는 선을 분명히 그어 줘야 합니다.

⑭ 첫 글자를 빨리 보여 주기 [직접]

추론 문서는 지연에 민감한 앱이라면 "깊이 추론하기 전에 짧은 머리말을 먼저 쓰게 하라"고 권합니다. 문장은 문서에 없어서 원칙을 따라 쓴 예시입니다.

Before any deeper reasoning or tool calls, reply with one short sentence that confirms what you understood and what you will do first. Then continue with the full answer.

5. 코드로 보는 새 API 기능

캐시를 지키며 추론 수준 바꾸기

요청 단위 reasoning.effort는 그대로 두고, 다음 사용자 메시지 앞에 configuration_update 항목을 넣습니다. 바뀐 수준은 다른 업데이트가 올 때까지 유지됩니다. 표준 단일 에이전트 모드에서만 되고, 바꿀 수 있는 것은 추론 수준뿐입니다.

from openai import OpenAI

client = OpenAI()
model = "gpt-6.1-sol"

first = client.responses.create(
    model=model,
    reasoning={"effort": "low"},
    input="Draft a database migration plan.",
    store=True,
)

follow_up = client.responses.create(
    model=model,
    previous_response_id=first.id,
    reasoning={"effort": "low"},          # 요청 값은 그대로 둔다 (캐시 접두사 보존)
    input=[
        {"type": "configuration_update", "reasoning": {"effort": "high"}},
        {"role": "user", "content": "Analyze the failure modes and propose rollback steps."},
    ],
)
print(follow_up.output_text)

Anthropic이 Opus 5.5에서 메시지 단위 effort 변경(베타)으로 푼 문제를 OpenAI는 이 방식으로 풀었습니다. 두 회사 모두 "대화 중에 요청 값을 바꾸면 캐시가 깨진다"는 같은 문제를 보고 같은 방향의 해법을 냈습니다.

비동기 도구 호출

도구 정의에 async: true를 붙이면 모델이 결과를 기다리지 않고 추론을 계속하거나, 다른 도구를 부르거나, 독립적인 부분에 먼저 답합니다. 도구 실행은 여전히 내 애플리케이션 몫이고, 결과가 준비되면 원래 call_id로 이후 요청에 넣어 줍니다. 백그라운드 모드(응답 생성 자체를 비동기로 돌리는 것)와는 다른 기능입니다.

tools = [{
    "type": "function",
    "name": "get_weather",
    "description": "Read a demo weather snapshot for a city.",
    "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
    "async": True,
}]

resp = client.responses.create(model="gpt-6.1-sol", tools=tools, input="Check the weather in Paris. Meanwhile, list three essentials for any city trip.")
call = next(i for i in resp.output if i.type == "function_call")   # call.async == True
# ... 도구를 백그라운드에서 실행하고, 끝나면:
client.responses.create(
    model="gpt-6.1-sol", tools=tools, previous_response_id=resp.id,
    input=[{"type": "function_call_output", "call_id": call.call_id, "output": weather_json}],
)

작업 중간에 방향 바꾸기(스티어링)

크게 보기

WebSocket 연결에서 response.create로 시작한 응답이 돌고 있을 때, 같은 연결로 response.steer 이벤트를 보내 요구 사항을 더하거나 바꿉니다. 서버는 진행 중인 출력 항목과 이미 돌던 호스팅 도구를 마무리한 뒤, 새 지시를 담은 이어 가기 응답을 자동으로 만듭니다(이때 response.create를 다시 보내면 안 됩니다). 이미 보낸 출력을 고치거나, 한 행동을 되돌리거나, 시작된 도구를 취소하지는 않습니다.

{
  "type": "response.steer",
  "previous_response_id": "resp_...",
  "input": "Keep the scope small enough for one developer to finish in two weeks."
}

Astra 발표문이 말한 행동 변화와 연결됩니다. 이전 모델은 방향 수정 메시지를 새 목표로 받아들여 원래 요청과 제약을 놓치곤 했는데, Astra는 새 요구를 반영하면서 전체 작업의 맥락을 유지한다는 것입니다.

6. 안전과 정렬

Astra는 OpenAI 준비성 평가 프레임워크의 사이버 보안 부문에서 '심각(Critical)' 임계값에 도달한 모델입니다. ExploitBench 100%, 최근 3개월 취약점으로 만든 내부 평가에서 제로데이 두 건을 찾아 활용하기까지 했습니다. 그래서 출시된 Astra는 보안 코드 검토·패치 같은 방어 작업은 하지만 개념 증명 익스플로잇 생성은 거부하고, 더 넓은 방어 워크플로는 OpenAI Daybreak로 확대할 예정입니다. 정렬 오류 모니터링 시스템이 추론과 행동을 검사해 의심스러우면 자동으로 멈추므로, ChatGPT·Codex에서는 검토 요청이 뜨고 API에서는 작업이 중단될 수 있습니다. 정상 작업이 가끔 막힐 수 있다고 OpenAI 스스로 밝혔습니다.

정렬 평가는 세대 간 차이가 큽니다.

솔직한 대목도 있습니다. Astra 발표문은 Astra의 추론이 GPT-5.6 Sol보다 모니터링하기 어려워졌다고 밝혔습니다. 모니터링을 피하라고 명시적으로 지시한 시험에서의 결과이고, OpenAI는 Astra가 단순한 작업에서 추론을 더 잘 제어하고 더 적은 서술 단계로 푸는 것을 원인으로 봅니다. 복잡한 작업의 추론을 숨기는 것은 여전히 어려워 보이지만, 이 점을 "심각하게 받아들인다"고 적었습니다.

7. 언제 무엇을 쓰나

OpenAI의 7칸 사다리

모델 선택 문서는 먼저 "비용과 지연이 상관없다면 Astra를 기본값으로"라고 말한 뒤, 비용을 줄이고 싶을 때의 사다리를 줍니다.

토큰 단가 계산

토큰 단가만 보면 오해하기 쉽습니다. Astra 발표문은 여러 평가에서 Astra가 출력 토큰을 훨씬 적게 써서, 토큰 단가가 높은데도 작업당 추정 비용은 이전 모델보다 낮았다고 말합니다. Terminal-Bench 4.0에서 Astra의 작업당 비용은 GPT-5.6 Sol보다 약 9%, Fable 5.1보다 약 63% 낮았습니다. 계산기는 "요청이 이만큼 토큰을 쓴다면"을 보여 줄 뿐이고, 같은 일을 몇 토큰에 끝내는지는 위의 비용 대비 점수 차트나 내 작업 측정으로 봐야 합니다.

GPT-6와 Claude, 두 회사의 9월 모델을 나란히

같은 날(9월 22일) 나온 GPT-6 Sol과 Claude Opus 5.5, 그리고 6.1 Sol까지 두 회사의 라인업은 가격대가 거의 겹칩니다. 두 회사의 가이드를 연달아 읽으면 모델의 버릇이 서로 반대 방향이라는 점이 흥미롭습니다.

벤치마크로는 어느 한쪽이 모든 것을 이기지 않습니다. Anthropic 발표 기준 Terminal-Bench 4.0은 Opus 5.5 66.4%가 Astra 57.9%보다 높고, OpenAI 차트 기준 AutomationBench 최고점도 Opus 5.5 최대(42.5%)입니다. 반면 OSWorld·DeepSWE·Terminal-Bench Science에서는 GPT-6 계열이 같은 비용에 더 높거나, 같은 점수를 훨씬 싸게 냅니다. 두 회사 모두 경쟁사 수치를 자기 환경에서 재거나 인용하므로, 결국 내 작업 표본으로 두 회사 모델을 같은 조건에서 재는 수밖에 없습니다. 두 회사의 문서도 그렇게 말합니다.

8. 마이그레이션 체크리스트

9. 한계와 주의점

• 모든 수치는 OpenAI 측정입니다. 경쟁 모델 수치는 공개 보고서 인용이거나 OpenAI가 더 단순한 연구 환경에서 잰 값이고, ChatGPT 실사용과는 시스템 프롬프트·도구 차이로 결과가 조금 다를 수 있다고 발표문이 밝혔습니다.
• 차트 원자료는 발표문에 내장된 값을 그대로 옮겼습니다. 같은 모델·추론 수준이 두 발표문에 모두 있으면 6.1 Sol 발표문 값을 썼습니다(OSWorld의 Astra·6 Sol 비용은 두 발표문에서 약간 다릅니다).
• 6.1 Sol은 아직 일반 ChatGPT Chat에 없습니다. ChatGPT Work와 Codex, API에서 쓸 수 있습니다.
• EU 데이터 레지던시에서는 Fast mode를 못 쓰고, Ultrafast는 미국·글로벌 처리만 됩니다. 지역 처리에는 10% 할증이 붙습니다.
• 정렬 평가는 실패를 유도한 과제입니다. 일상 사용의 실패율로 읽으면 안 됩니다.
• Astra의 모니터링 중단은 API 작업을 멈출 수 있습니다. 긴 무인 작업에는 중단을 처리하는 경로가 필요합니다.

맺으며: 더 똑똑해진 모델은 더 자주 묻는다

GPT-6 가이드의 첫 항목이 "더 자율적으로 일하게 하는 프롬프트"라는 점이 상징적입니다. 모델이 더 나은 협업자가 되도록 설계됐기 때문에, 결과를 바꿀 수 있는 모호함 앞에서 묻는 쪽으로 기울었고, 그래서 이제는 "언제 묻지 말아야 하는지"를 프롬프트로 알려 줘야 합니다. 같은 주에 나온 Claude Opus 5.5의 가이드가 "보고하고 멈추지 말라"는 문단을 준 것과 겹쳐 보면, 두 회사의 최신 모델 모두에서 끝까지 해내게 만드는 일이 프롬프트의 새 중심이 되었습니다.

다른 하나는 비용 곡선입니다. 6.1 Sol은 Astra의 1/5 가격에 Astra 곡선 바로 아래를 지나고, 추론을 끝까지 올린다고 점수가 오르지도 않습니다. 가장 좋은 모델을 가장 높은 설정으로 쓰는 것이 기본값이던 시기는 지나가고 있습니다. OpenAI 문서의 마지막 문장이 이 글의 결론이기도 합니다. 같은 입력으로 비교해서, 품질 기준을 넘는 가장 가벼운 설정을 남겨라.

참고 자료

• OpenAI, GPT-6.1 Sol 소개 (2026-09-29)
• OpenAI, GPT-6 Sol과 Luna 소개 (2026-09-22)
• OpenAI, GPT-6 Astra: 새로운 세대의 지능 (2026-09-03)
• OpenAI, DevDay 2026 주요 발표 (2026-09-29)
• OpenAI 개발자 문서, Using GPT-6 (프롬프팅 모범 사례·마이그레이션)
• OpenAI 개발자 문서, GPT-6.1 Sol · GPT-6 Astra · GPT-6 Luna 모델 페이지
• OpenAI 개발자 문서, Model selection · Reasoning · Prompt caching
• OpenAI 개발자 문서, Async tool calling · Mid-turn steering · Ultrafast mode

함께 읽으면 좋은 글: Claude Opus 5.5 사용 설명서 · 2026년형 프롬프트 질문법 · 프롬프트 캐시는 어떻게 동작하나