OpenAI가 공개한 GPT-6 Astra 공식 활용 가이드: 자주 되묻는 모델을 끝까지 일하게 하는 프롬프팅과 마이그레이션

9bow · 9월 7, 2026, 4:00오전

GPT-6 Astra 모델 가이드 소개

OpenAI가 GPT-6 Astra 출시와 함께 개발자 문서 사이트에 Astra 전용 공식 활용 가이드(Model Guidance)를 공개했습니다. 이 문서는 gpt-6-astra 로 옮길 때 바꿔야 하는 API 파라미터, 새로 추가된 API 기능, 그리고 이전 세대와 달라진 모델의 행동 특성을 프롬프트로 조정하는 방법을 한곳에 정리한 실무 지침서입니다. GPT-5.6 Sol이나 그 이전 모델로 에이전트를 운영 중인 개발자라면 모델 이름을 바꾸기 전에 한 번은 읽어야 할 내용입니다. 문서 첫머리에서 OpenAI는 Astra를 컴퓨터 사용, 브라우징, 소프트웨어 엔지니어링, 과학, 전문 업무에서 최고 성능을 기록한 모델로 소개하고, 코드와 브라우저와 전문 소프트웨어를 오가는 여러 단계의 워크플로우를 수행하는 능력을 강점으로 꼽습니다.

이번 가이드가 앞선 세대의 가이드와 가장 다른 점은 무게 중심이 "프롬프트를 줄이라"에서 "모델의 성향을 이해하고 방향을 잡아 주라"로 옮겨 갔다는 것입니다. GPT-5.6 공식 활용 가이드의 핵심 메시지는 하네스(harness)에 쌓인 장황한 시스템 프롬프트를 걷어내고 최소 프롬프트로 시작하라는 것이었습니다. 반면 Astra 가이드는 모델이 더 협력적인 동료가 되도록 훈련된 결과로 나타나는 다섯 가지 행동 특성을 먼저 열거하고, 각 특성이 여러분의 워크플로우에 맞지 않을 때 넣을 프롬프트를 그대로 제시합니다. 가이드는 Astra를 OpenAI 모델 중 가장 정렬(alignment)이 잘 된 모델로 소개하면서, 주의를 기울이고 작업 경계를 지키며 투명하게 소통하는 점을 강점으로 꼽습니다. 지시에 해석의 여지가 있으면 맥락으로 일상적인 공백을 채우고, 답이 결과를 바꿀 수 있을 때만 초점이 잡힌 질문을 하며, 새 요구사항을 반영하거나 방향을 바꾸거나 곁가지 질문에 답하면서도 원래 작업을 놓치지 않는다는 설명입니다. 그런데 이 성향은 사용자가 모델이 적당한 가정을 세우고 계속 진행하기를 기대하는 상황에서는 작업을 멈추는 원인이 됩니다. 가이드는 이 간극을 메우는 프롬프트를 세 개 제시합니다.

또 하나의 축은 API 기능입니다. Astra에서는 도구 실행을 기다리지 않고 추론(reasoning)을 이어가는 비동기 도구 호출(Async tool calling), 응답이 진행되는 도중에 사용자 지시를 끼워 넣는 중간 조향(Mid-turn steering), 프롬프트 캐시를 유지한 채 추론 강도(reasoning effort)를 바꾸는 configuration_update 입력 항목, 그리고 Path to Astra 발표에서 예고된 비정렬 모니터링(Misalignment monitoring) 이 새로 들어왔습니다. 이 네 가지는 모두 Responses API를 전제로 하므로, 아직 Chat Completions API를 쓰고 있다면 이번 마이그레이션이 전환 시점입니다.

Astra의 벤치마크 성적, 사이버보안 Critical 등급 판정, 시스템 카드의 정렬 평가는 GPT-6 Astra 출시 정리 글에서 다룬 바 있습니다. 이 글은 그 후속으로, 가이드가 제시하는 프롬프트와 마이그레이션 항목을 실제 개발 워크플로우에 적용할 수 있는 형태로 정리합니다.

Astra에서 새로 열린 API 기능: 기다리지 않는 도구 호출과 도중에 바꾸는 방향

가이드는 Astra에서 처음 지원되는 기능 네 가지와 제한 사항을 먼저 열거합니다. 각 기능은 별도 문서와 연결되어 있어 이 글에서는 동작 원리와 도입 시 확인할 점을 중심으로 정리합니다.

비동기 도구 호출: 도구가 돌아오는 동안 모델은 다른 일을 합니다

일반적인 함수 호출(function calling)은 모델이 도구를 호출한 순간 턴이 멈추고, 애플리케이션이 결과를 돌려줄 때까지 기다립니다. 도구 하나가 수십 초 걸리는 조회라면 그 시간 동안 모델은 아무것도 하지 못합니다. 비동기 도구 호출은 함수 또는 커스텀 도구 정의에 async: true 를 붙이는 것만으로 이 제약을 풉니다. 모델은 호출을 발행한 뒤 계속 추론하고, 다른 도구를 부르고, 요청 중 도구 결과에 의존하지 않는 부분에 먼저 답할 수 있습니다.

다만 도구를 실행하는 주체는 여전히 애플리케이션입니다. 비동기 도구 호출은 실행을 OpenAI 쪽으로 옮기거나 백그라운드 작업을 대신 관리해 주지 않습니다. 응답 생성 자체를 비동기로 처리하는 백그라운드 모드와도 다릅니다. 애플리케이션은 도구 작업이 끝나면 원래의 call_id 를 붙여 function_call_output 항목으로 결과를 다음 요청에 넣어 주고, 그 사이에 다른 대화 턴이 있었다면 previous_response_id 를 가장 최근 응답으로 갱신합니다.

{
  "type": "function",
  "name": "get_weather",
  "description": "Read the demo weather snapshot for a city.",
  "async": true,
  "strict": true,
  "parameters": {
    "type": "object",
    "properties": {"city": {"type": "string"}},
    "required": ["city"],
    "additionalProperties": false
  }
}

문서는 여기서 한 단계 더 나간 대기 도구(wait tool) 패턴도 소개합니다. 각 비동기 도구에 task_handle 인자를 추가해 모델이 호출마다 고유한 핸들을 붙이게 하고, 애플리케이션은 핸들을 원래 call_id 와 실행 중인 작업에 연결해 둡니다. 여기에 wait_for_tasks 같은 일반 동기 함수를 하나 정의해 두면, 모델은 두 개의 가격 조회를 먼저 요청해 놓고 독립적인 작업을 처리한 뒤 가격을 비교해야 하는 시점에만 기다립니다. wait_for_tasks 는 내장 도구가 아니라 개발자가 정의하는 함수이며, 결과는 대기 도구가 아니라 원래 호출의 call_id 로 돌려주고 대기 호출에는 상태만 돌려줍니다. 비동기 실행은 애플리케이션이 실행하는 함수와 커스텀 도구에만 적용되고, 호스팅된 내장 도구나 프로그래매틱 도구 호출(Programmatic Tool Calling)에는 쓰지 않습니다. 멀티 에이전트 모드에서는 비동기 도구와 병렬 도구 호출을 함께 쓰지 않도록 안내합니다.

중간 조향: 응답이 끝나기를 기다리지 않고 요구사항을 추가합니다

중간 조향(Mid-turn steering) 은 모델이 작업하는 도중에 수정 사항이나 요구사항 변경을 보내는 기능입니다. WebSocket 모드로 Responses API에 연결한 상태에서만 동작하며, GPT-5.6 이하 모델은 지원하지 않습니다. 흐름은 단순합니다. response.create 로 응답을 시작하고 response.created 이벤트를 받은 뒤, 같은 연결에서 그 응답 ID를 previous_response_id 로 지정한 response.steer 이벤트를 보냅니다.

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

서버는 response.steer.accepted 로 입력이 큐에 들어갔음을 알립니다. 이 확인은 입력이 큐에 들어갔음을 알릴 뿐, 모델이 지시를 반영했음을 보장하지 않습니다. 서버는 현재 출력 항목과 이미 실행 중인 호스팅 도구 작업을 마친 뒤, 완료된 작업을 보존한 채 업데이트를 포함한 새 응답을 자동으로 만들어 이어갑니다. 원래 응답이 중단되면 response.incomplete 이벤트와 함께 incomplete_details.reason 이 "steered" 로 표시됩니다. 조향은 이미 애플리케이션에 전송된 출력을 다시 쓰거나, 앞선 행동을 되돌리거나, 시작된 도구를 취소하지는 않습니다. 원래 응답이 클라이언트 도구 결과나 승인을 기다리는 상태라면 서버는 response.steer.pending 으로 어떤 입력이 필요한지 알려 주고, 애플리케이션이 response.create 로 도구 결과를 돌려주면 그 앞에 큐에 있던 조향 입력을 자동으로 추가합니다. 큐에 있는 조향 입력은 현재 연결에만 존재하므로, 연결이 끊긴 뒤에도 살아 있다고 가정하지 말고 보낸 입력을 기록해 두었다가 응답 이력과 대조하라고 안내합니다.

캐시를 깨지 않고 추론 강도 바꾸기: configuration_update

에이전트 대화에서는 쉬운 후속 질문과 어려운 분석이 번갈아 나옵니다. 요청 단위의 reasoning.effort 를 바꾸면 프롬프트 접두 문맥(prefix)이 달라져 프롬프트 캐시를 놓치게 됩니다. Astra는 이 문제를 configuration_update 입력 항목으로 풉니다. 요청 단위 reasoning.effort 는 그대로 두고, 다음 사용자 메시지 앞에 아래 항목을 끼워 넣으면 그 응답부터 다른 업데이트가 덮어쓸 때까지 새 강도가 적용됩니다.

response = client.responses.create(
    model=model,
    previous_response_id=response.id,
    reasoning={"effort": "low"},
    input=[
        {
            "type": "configuration_update",
            "reasoning": {"effort": "high"},
        },
        {
            "role": "user",
            "content": "Analyze the failure modes and propose rollback steps.",
        },
    ],
    store=True,
)

추론 가이드가 명시한 제약도 함께 알아야 합니다. 이 기능은 표준 단일 에이전트 모드의 gpt-6-astra 에서만 지원되고, 바꿀 수 있는 것은 추론 강도뿐입니다. 응답의 reasoning.effort 필드는 업데이트로 선택된 값이 아니라 요청 단위 설정을 계속 보고합니다. 두 개의 configuration_update 를 이력에서 바로 붙여 두면 API가 거부하고, 자동 압축(compaction)이나 자동 잘라내기와 함께 쓸 수 없으며, 독립 /responses/compact 엔드포인트도 이 항목이 든 이력을 거부합니다. compaction_trigger 항목으로 명시적 압축을 한 뒤에는 다음 사용자 메시지 앞에 새 configuration_update 를 다시 넣어야 합니다.

비정렬 모니터링: 에이전트가 지시를 넘어서면 API가 멈춥니다

비정렬 모니터링(Misalignment monitoring) 은 Astra 급 모델을 위해 OpenAI가 강화한 안전장치의 일부로, 민감한 데이터 전송, 민감한 데이터 접근, 파괴적 변경처럼 결과가 큰 맥락에서 에이전트가 사용자 지시를 제대로 해석하고 있는지를 비동기로 검토합니다. 문제가 감지되면 경고를 발생시키고 대화를 멈출 수 있습니다. 모니터링 문서는 플래그가 "에이전트의 행동을 검토할 필요가 있다"는 뜻일 뿐, 사용자가 정책을 위반했거나 에이전트가 지시와 다르게 행동했음을 확정하는 것은 아니라고 명시합니다. 감지를 놓치거나 정당한 활동을 잡을 수도 있으므로, 결과가 큰 행동에는 사람 승인을 포함한 애플리케이션 자체 안전장치를 계속 유지하라는 것입니다.

동작 범위는 요청 방식에 따라 다릅니다.

요청 방식	동작
Responses API + 추론 유지(persisted reasoning), WebSocket, 또는 OpenAI 압축 사용	모니터링됨. 대화의 연속을 식별해 이후 실행을 차단할 수 있음
Responses API, 위 세 가지 중 어느 것도 사용하지 않음	모니터링됨. 설정한 웹훅으로 경고를 받지만 대화를 자동으로 멈추지는 않음
Chat Completions API	이 모니터링 시스템의 대상이 아님. 다른 안전 검사는 적용

스트리밍 시작 전에 차단되면 API는 HTTP 403 과 함께 오류 코드 misalignment_policy_violation 을 반환합니다. 문서는 메시지 텍스트가 아니라 이 코드로 매칭하고, 스트리밍 도중에도 오류를 처리해야 한다고 안내합니다. 이 오류를 받은 애플리케이션은 해당 대화의 후속 행동 디스패치를 멈추고 자동 재시도를 하지 않으며, 요청과 응답 ID와 도구 호출 기록을 보존하고, 담당자에게 오류 정보를 보여 에이전트의 행동과 의도한 작업을 비교하게 해야 합니다. 멈춘 대화를 재개하는 일반적인 방법은 제공되지 않습니다. 모니터링이 비동기이므로 문제가 감지되기 전에 행동이 이미 완료되어 있을 수 있고, 중단은 앞선 행동을 되돌리지 않습니다. 경고는 safety.alert.created 웹훅으로 받아 api.safety.alerts.read 권한이 있는 키로 조회합니다.

제한 사항과 GPT-5.6에서 이어지는 기능

Astra는 none 추론 강도를 지원하지 않습니다. reasoning.effort 를 none 으로 보내면 HTTP 400이 돌아옵니다. Fast 모드는 EU 데이터 레지던시(data residency) 환경에서는 쓸 수 없고, 그 밖의 환경에서도 지연 시간 SLA(Service Level Agreement)를 포함하지 않습니다. Fast 모드 문서에 따르면 GPT-5.6 이하 모델은 Fast 모드에서 Scale Tier와 같은 SLA 적용을 받으므로, 이 점은 Astra에서 달라진 부분입니다.

GPT-5.6에서 쓸 수 있던 기존 API 기능도 그대로 지원합니다. 컴퓨터 사용, 구조화된 출력(Structured Outputs), 스트리밍, 프로그래매틱 도구 호출, 멀티 에이전트 오케스트레이션, 프롬프트 캐싱, 추론 유지(persisted reasoning), 압축(compaction), Pro 모드를 모두 사용할 수 있습니다. 이 가운데 프로그래매틱 도구 호출, 멀티 에이전트, 프롬프트 캐싱, 추론 유지, Pro 모드의 사용 기준은 GPT-5.6 가이드 정리 글에서 다뤘습니다.

Astra의 다섯 가지 행동 특성과 프롬프트로 조정하는 방법

가이드는 Astra가 GPT-5.6 Sol보다 지능과 능력이 높아졌을 뿐 아니라, 용도에 따라 프롬프트로 최적화할 수 있는 행동 패턴을 보인다고 설명합니다. 다섯 가지 특성과 조정 방향을 먼저 표로 정리하고, 아래에서 각 특성에 대해 가이드가 제시한 프롬프트를 원문 그대로 옮깁니다.

행동 특성	기본 성향	조정 방향
주도성과 완수(Initiative and follow-through)	추가 입력이 결과를 바꿀 수 있으면 질문하고 멈춤	행동 편향, 작업 완수, 검토 가능한 결과를 만든 뒤 승인 요청을 프롬프트로 지시
지시 준수(Instruction following)	긴 지시를 잘 따르고 스킬 파일과 `AGENTS.md` 에 민감	사용자 지시와 스킬의 우선순위 명시, 스킬 파일 감사
성격과 문체(Personality and writing style)	목록, 표, Markdown을 선호하고 반복 어구 사용	산문 우선, 평이한 어휘, 상투어 금지 목록을 명시
서브에이전트 위임(Subagent delegation)	워크플로우가 기대하는 것보다 위임을 덜 함	언제, 얼마나 위임할지 명시
테스트와 검증(Testing and verification)	작업 완료 전 테스트를 철저히 함	변경 규모에 맞게 검증 범위를 조정

주도성과 완수: 질문을 줄이고 끝까지 일하게 하기

Astra는 긴 작업에서 일관성을 유지하는 능력이 GPT-5.6 Sol과 이전 모델보다 좋아졌고, 동시에 이전 모델이라면 가정을 세우고 넘어갔을 지점에서 명확화를 요청할 가능성도 높아졌습니다. 자율적인 작업을 원한다면 가이드는 다음 프롬프트로 시작하라고 권합니다.

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.

세 번째 프롬프트는 승인 요청의 시점을 옮깁니다. 가이드는 모델이 구체적이고 검토 가능한 결과를 준비한 뒤에만 승인을 묻도록 지시하라고 합니다. 할 수 있는 일을 다 하기 전에 작업을 막는 상황을 피할 수 있고, 결과적으로 작업이 더 빨리 끝나는 경우가 많다는 것입니다. 배포, 외부 애플리케이션 쓰기, PR 병합, 사이트 게시처럼 되돌리기 어려운 행동 앞에서 승인이 마지막 단계가 되도록 그 앞의 작업을 모두 끝내 두고, 되돌릴 수 있는 작업, 읽기 전용 행동, 검토와 수정, 세션 앞에서 이미 승인된 일에는 허가를 묻지 않게 합니다.

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.

가이드는 모델이 기본적으로 작업 중에도 차단하지 않는(non-blocking) 질문을 던지는 것을 좋아한다고 덧붙이며, 이 프롬프트들을 애플리케이션이 필요로 하는 자율성 수준에 맞게 조정하라고 안내합니다.

지시 준수: 스킬 파일과 AGENTS.md를 감사하기

Astra는 이전 모델보다 일반적인 지시 준수 능력이 높아 개발자가 행동을 더 세밀하게 제어할 수 있고, 긴 지시도 더 잘 따릅니다. 그만큼 컨텍스트 안의 정보에 더 민감합니다. 가이드가 든 예는 스킬 파일의 불명확하거나 상충하는 지침입니다. 이런 지침이 있으면 모델이 일찍 멈추고 작업을 막을 수 있으므로, OpenAI는 모델이 접근할 수 있는 스킬과 AGENTS.md 같은 파일을 감사해 행동에 영향을 줄 수 있는 지시를 점검하라고 강하게 권고합니다. 사용자 지시와 스킬 지침의 우선순위는 프롬프트로 명시합니다.

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.

이 항목은 Sol Advisor처럼 Codex 플러그인 형태로 하네스에 지침을 주입하는 사례가 늘어나는 상황과 맞물립니다. 모델이 지시를 잘 따를수록, 하네스 안에 누가 언제 넣었는지 잊힌 지침 한 줄이 작업 전체를 막는 원인이 됩니다.

성격과 문체: 목록 대신 산문, 상투어 금지

Astra는 응답을 훑어보기 쉽게 만들려고 목록, 표, Markdown을 즐겨 쓰고, 세션을 넘어 반복되는 어구를 사용하는 경향이 있습니다. 서식이 적은 산문이 필요하다면 그 선호를 명시합니다.

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.

세 번째 프롬프트는 LLM 특유의 상투어를 직접 금지 목록으로 나열합니다. 결론의 "Bottom Line:", "delve", "foster", "leverage", "it's worth noting", "This isn't about X. It's about Y." 같은 어구와 하이픈 합성 수식어, "In short:" 류의 요약 마무리, "X, not Y" 형태의 대비 구문, "exact-head checks" 같은 만들어 낸 합성 라벨을 피하라는 내용입니다. 모델 개발사가 자사 모델의 슬롭(slop) 어휘를 공식 문서에서 금지 목록으로 명시한 점이 눈에 띕니다.

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" or "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.

서브에이전트 위임: 병렬화 시점을 명시하기

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.

가이드에 따르면 모델은 언제 어떻게 위임할지를 지시하는 프롬프트에 잘 반응하므로, 하네스와 멀티 에이전트 구현에 맞게 이 동작을 조정하면 됩니다.

테스트와 검증: 변경 규모에 맞는 검증 범위

코딩 작업에서 Astra는 작업 완료를 선언하기 전에 철저히 테스트하는 경향이 있습니다. 큰 변경에는 바람직하지만 작은 작업에서는 필요 이상으로 넓은 테스트를 만들 수 있습니다. 가이드는 변경에 필요한 검증 수준을 프롬프트로 조정하라고 안내합니다.

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.

마이그레이션 체크리스트: 파라미터 정리와 캐시 옵션 교체

가이드는 model 을 gpt-6-astra 로 바꾼 뒤 확인할 항목을 나열합니다. GPT-5.6 이전 모델에서 옮겨오는 경우를 기준으로 표로 정리하면 다음과 같습니다.

항목	이전 설정	GPT-6 Astra에서
추론 강도	`none` 또는 `minimal` 사용	`low` 로 시작해 결과 비교. 그 외에는 현재 강도 유지
도구 호출	Chat Completions에서 가능	Responses API 필수. Chat Completions는 지원하지만 도구 호출 불가
샘플링 파라미터	`temperature`, `top_p`, `top_logprobs`	제거. Chat Completions는 `logprobs` 도, Responses는 `include` 의 `message.output_text.logprobs` 도 제거
Fast 모드	`service_tier: "fast"` 또는 `"priority"`	EU 데이터 레지던시에서는 Standard 처리 사용. 지연 시간 SLA 없음
응답 간 추론 강도 변경	요청 단위 `reasoning.effort` 변경	`configuration_update` 항목 사용, 요청 단위 값은 고정
프롬프트 캐시 수명	`prompt_cache_retention`	`prompt_cache_options.ttl` 을 `"30m"` 으로 교체
잦은 승인 요청	해당 없음	주도성과 완수 프롬프트로 자율 실행 유도

추론 강도는 Responses API에서는 reasoning.effort, Chat Completions에서는 reasoning_effort 로 지정합니다. 추론 강도 항목은 GPT-5.6 가이드의 "현재 강도와 한 단계 낮은 설정을 비교하라"는 조언과 방향이 같습니다. 따라서 Astra가 none 을 지원하지 않는 이상, 지연 시간 기준선으로 none 을 쓰던 워크로드는 low 부터 다시 측정해야 합니다. 도구 호출에 Responses API가 필수라는 점은 앞서 본 비동기 도구 호출, 중간 조향, 비정렬 모니터링의 자동 중단이 모두 Responses API의 대화 상태 관리 위에서 동작하기 때문입니다.

프롬프트 캐싱은 GPT-5.5 이하에서 옮겨올 때 특히 확인이 필요합니다. 프롬프트 캐싱 문서에 따르면 GPT-5.6 이후 모델은 캐시 쓰기에 비캐시 입력 요금의 1.25배가 과금되고, 캐시 읽기는 0.1배입니다. 접두 문맥을 한 번 쓰고 한 번 재사용하면 1.35배, 열 번의 요청에서 한 번 쓰고 아홉 번 읽으면 2.15배가 되어 캐시 없이 처리하는 10배보다 훨씬 싸지만, 재사용되지 않는 접두 문맥에 쓰기 비용만 내는 상황은 피해야 합니다. usage.input_tokens_details 의 cached_tokens 와 cache_write_tokens 를 추적해 순비용을 확인하고, 캐시 경계(boundary)가 어디에 놓이는지도 함께 검토합니다.

Codex로 마이그레이션 자동화하기

GPT-5.6 가이드와 마찬가지로 이번 가이드의 권장 변경 사항도 Codex가 대신 적용해 줄 수 있습니다. OpenAI skills 저장소의 openai-docs 스킬을 설치한 뒤 다음 한 줄을 실행합니다.

$openai-docs migrate this project to GPT-6 Astra

같은 스킬을 다른 코딩 에이전트에서도 내려받아 쓸 수 있습니다. 공식 문서를 스킬로 포장해 모델이 스스로 마이그레이션을 수행하게 하는 절차는 GPT-5.6 가이드에 이어 두 번째 등장입니다.

가격과 접근성

출시 발표문에 따르면 GPT-6 Astra는 OpenAI API에서 gpt-6-astra 로, 그리고 Microsoft Azure와 Amazon Bedrock을 통해 제공됩니다. 발표 시점에는 제한된 조직에 먼저 제공하고 며칠에 걸쳐 확대한다고 밝혔습니다.

항목	GPT-6 Astra
입력 토큰 (Standard)	1M당 $10
출력 토큰 (Standard)	1M당 $50
Fast 모드	Standard의 2배 가격, 최대 2배 속도
캐시 읽기와 쓰기	별도 요금 적용

토큰당 가격은 이전 모델보다 높지만, 가이드는 여러 평가에서 Astra가 훨씬 적은 출력 토큰으로 더 좋은 결과를 내어 작업당 추정 API 비용은 오히려 낮아졌다고 설명합니다. 발표문의 벤치마크 표에서 이 주장의 근거가 되는 비용 비교를 확인할 수 있으며, 자격이 되는 API 고객에게는 데이터 무보존(Zero Data Retention)도 지원됩니다.

시사점: 모델이 지시를 잘 따를수록 하네스 감사가 먼저다

이 가이드를 GPT-5.6 가이드와 나란히 놓고 보면 OpenAI가 개발자에게 요구하는 일의 성격이 바뀌었다는 것이 드러납니다. GPT-5.6 가이드는 프롬프트를 걷어내라고 했고, Astra 가이드는 모델의 다섯 가지 성향을 열거하고 각각을 조정하는 프롬프트를 제시합니다. 두 조언은 상충하지 않습니다. 걷어낼 것은 모델이 이미 기본으로 하는 행동을 반복하는 지시이고, 새로 넣을 것은 모델의 기본 행동이 여러분의 워크플로우와 어긋나는 지점을 짚는 지시입니다. Astra 가이드의 프롬프트가 모두 "질문하기 전에 할 수 있는 일을 끝내라", "스킬보다 사용자 지시를 우선하라", "작은 변경에는 테스트를 만들지 마라"처럼 특정 성향 하나를 겨냥한 지시인 이유입니다.

실무적으로 가장 먼저 할 일은 마이그레이션 표의 파라미터 정리가 아니라 하네스 안의 지시 파일 감사입니다. 가이드가 "강하게 권고"라는 표현을 쓴 유일한 항목이기도 합니다. 지시 준수 능력이 높아진 모델은 스킬 파일의 상충하는 한 줄에 더 충실하게 멈추고, 그 결과는 사용자 입장에서 "모델이 자꾸 물어본다"는 증상으로 나타납니다. 가이드가 제시한 스킬 지목 프롬프트를 켜 두면 어느 파일의 어느 줄이 원인인지 모델이 직접 알려 주므로, Astra 도입 초기에 상시 켜 두는 것이 감사 비용을 줄이는 방법입니다. Anthropic의 Claude Fable 5 프롬프팅 가이드가 "강력해진 모델에 맞춰 프롬프트를 다시 쓰라"고 한 것과 함께 읽으면, 프런티어 모델 개발사들이 공통으로 하네스에 쌓인 지시의 재검토를 요구하고 있음을 알 수 있습니다.

OpenAI GPT-6 Astra 모델 가이드 원문

OpenAI skills 저장소

더 읽어보기

이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임에서 이런 글들을 계속 정리하고 있습니다. 회원 가입으로 주요 글들을 이메일로, 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로 새 글 알림을 받아보세요!

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~