GPT-6 Astra 도입, Responses API 마이그레이션이 필요한 이유

실무에서 판단할 핵심은 마이그레이션에 어느 정도의 엔지니어링 공수를 배정할지, 그리고 새 제어 기능으로 에이전트 실행을 기다리고 수정하고 다시 시작하는 비용을 줄일 수 있는지입니다.

Responses API 마이그레이션에서 실제로 달라지는 것

출시 전 Astra 분석에서 이 모델은 제한된 환경 안에 있던 연구 모델이었습니다. 9월 출시와 함께 공개 모델 ID인 gpt-6-astra가 생겼고, 가격이 공개됐으며, Chat Completions와 Responses 모두에서 사용할 수 있게 됐습니다. 우선 OpenAI의 Trusted Access Program에 참여한 기업에 제공되며, API와 더 넓은 플랜으로의 접근 권한은 며칠에 걸쳐 순차적으로 열립니다.

어떤 엔드포인트를 선택할지는 애플리케이션의 동작 방식에 달려 있습니다. 텍스트만 처리하는 Chat Completions 연동이라면 Astra를 사용할 수 있습니다. 반면 Astra가 자체 함수나 OpenAI 호스팅 툴을 호출하는 연동은 반드시 Responses API를 사용해야 합니다.

Responses는 애플리케이션과 맺는 계약 자체가 다릅니다. Chat Completions가 메시지 목록을 받아 선택지 목록을 반환한다면, Responses는 타입이 지정된 Item을 주고받습니다. 메시지 하나가 하나의 Item이고, function_call도 별도의 Item입니다. 툴 실행 결과는 function_call_output으로 반환하며, 여기에 원래의 call_id가 담깁니다.

마이그레이션에서 특히 놓치기 쉬운 부분은 두 가지입니다. 최상위 instructions는 previous_response_id로 응답을 이어도 자동 승계되지 않으므로 매번 다시 보내야 합니다. Structured Outputs의 위치도 response_format에서 text.format으로 바뀝니다. 파서, 상태, 툴, 스트리밍에서 달라지는 전체 항목은 마이그레이션 가이드에서 확인할 수 있습니다.

왜 중요한가: 이제 두 가지 예산을 잡아야 합니다

첫 번째는 엔지니어링 시간입니다. 프로덕션 툴 루프를 옮기려면 엔드포인트부터 요청 스키마, 출력 파서, 함수 정의, 결과 연결, 상태 관리, 스트리밍 이벤트, 로그, 재시도, 평가까지 손봐야 합니다. 모델 이름만 바꾸면 이 작업의 대부분이 그대로 남습니다.

두 번째는 완료된 작업 한 건당 비용입니다. GPT-6 Astra의 Standard 단기 컨텍스트 요금은 입력 토큰 100만 개당 $10.00, 캐시 입력 $1.00, 캐시 쓰기 $12.50, 출력 $50.00입니다. GPT-5.6 Sol의 현재 프로모션 요금은 같은 네 항목 기준으로 각각 $4.00, $0.40, $5.00, $20.00입니다. 토큰 사용량이 같다면 모든 항목에서 Astra가 2.5배 비쌉니다.

엔드포인트 자체에 별도 요금은 없습니다. 실제 청구액은 모델 토큰, 유료 빌트인 툴, 자체 툴 인프라, 재시도, 중도 폐기된 작업에서 발생합니다. 입력 토큰이 272,000개를 넘는 프롬프트는 Astra 요청 전체의 입력 및 캐시 요금을 2배, 출력 요금을 1.5배로 끌어올립니다. 파일럿 예산에는 현재 요금 페이지의 이 수치를 반영해야 합니다.

비용을 상쇄할 가능성은 있지만, 자체 데이터로 검증해야 합니다. OpenAI는 내부 테스트에서 Responses의 캐시 활용률이 Chat Completions보다 40%에서 80% 높았다고 밝혔습니다. 또한 여러 평가에서 Astra가 높은 토큰 단가에도 출력 토큰을 더 적게 사용해 작업당 추정 API 비용이 낮았다고 보고했습니다. 어느 쪽도 모든 워크로드에 통하는 절감 효과를 보장하지는 않습니다.

대신 다음 지표를 측정해야 합니다.

cost per completed job = model tokens + built-in tool fees + your tool costs + retries + operator time

핵심은 분모인 완료된 작업 수입니다. 저렴한 실행이라도 막바지 수정 때문에 처음부터 다시 돌려야 한다면, 진행 중인 작업을 살려내는 고가 실행보다 최종 결과 한 건당 비용이 더 클 수 있습니다.

비동기 툴 호출이 대기 방식을 바꿉니다

일반적인 함수 호출에서는 애플리케이션이 결과를 반환할 때까지 모델이 멈춥니다. Astra에서는 애플리케이션이 실행하는 함수 또는 커스텀 툴에 async: true를 지정할 수 있습니다. 그러면 모델은 호출을 보낸 뒤 추론을 계속하거나, 서로 독립적인 다른 툴을 호출하거나, 애플리케이션이 작업을 처리하는 동안 요청의 독립적인 부분부터 답할 수 있습니다.

작업 실행 책임은 여전히 서버에 있습니다. 서버가 작업을 시작하고 레지스트리를 유지하며 원래의 call_id를 저장한 뒤, 이후 Responses 요청에서 결과를 전달해야 합니다. 결과가 오기 전에 다른 턴이 진행됐다면, 툴 출력은 원래 호출 ID를 계속 가리키되 이어지는 요청에는 가장 최신 응답 ID를 사용해야 합니다.

리서치 제품이라면 느린 데이터 제공업체 요청을 처리하는 동안 Astra가 이미 확보한 출처를 정리할 수 있습니다. 내부 운영 에이전트라면 서로 독립적인 계정 조회 두 건을 먼저 시작하고, 그 결과가 필요 없는 보고서 부분을 모델이 작성할 수 있습니다. 얻는 것은 무료 실행이 아니라 유휴 시간의 단축입니다.

미드턴 스티어링이 재시작 방식을 바꿉니다

미드턴 스티어링을 사용하면 Astra가 작업하는 도중에도 사용자가 방향을 바로잡을 수 있습니다. 애플리케이션은 같은 Responses WebSocket에서 response.steer 이벤트를 보내고, previous_response_id로 진행 중인 응답을 지정한 뒤 새 지시를 전달합니다. 서버는 현재 출력 Item과 이미 실행 중인 호스팅 툴 작업을 마친 다음, 업데이트를 반영한 후속 응답을 생성합니다.

보고서의 대상 시장이 잘못됐음을 발견한 에이전시 운영자나, 진행 중인 마이그레이션 계획의 범위를 줄여야 하는 엔지니어링 리드에게 유용한 기능입니다. 전체 턴이 끝나기 전에 방향을 수정할 수 있습니다.

이미 소비된 작업은 되돌아오지 않습니다. 스티어링은 전달이 끝난 출력을 다시 쓰거나, 이전 동작을 취소하거나, 시작된 툴을 중단하지 않습니다. 토큰 한도와 툴 호출 한도도 원래 응답과 후속 응답에 각각 적용됩니다. 늦게 들어온 수정 때문에 전체 작업을 다시 시작하는 횟수를 줄이는 것이 사업적 가치이며, 그런 상황이 실제로 충분히 자주 발생하는지는 별도로 측정해야 합니다.

스티어링은 Astra 전용이며 Responses WebSocket이 필요합니다. 대기 중인 스티어링 정보는 해당 연결에만 남기 때문에, 애플리케이션은 수락된 업데이트를 모두 기록하고 연결이 끊겼을 때 신중하게 복구해야 합니다. OpenAI의 WebSocket 연결 상한은 60분입니다. 툴 호출이 20회 이상인 WebSocket 도입 사례에 대해 WebSocket 가이드는 엔드투엔드 실행 시간이 최대 약 40% 빨라진다고 설명합니다. 다만 이는 전송 방식의 결과이지, 스티어링 자체가 보장하는 절감 효과는 아닙니다.

바로 실행할 수 있는 마이그레이션 절차

위험이 낮은 함수 흐름 하나부터 시작합니다. 프로덕션에서 가장 바쁜 에이전트를 첫 대상으로 삼을 필요는 없습니다.

OpenAI 빠른 시작 가이드에 나온 대로 최신 Python SDK를 설치하고 환경 변수를 설정합니다.

pip install openai
export OPENAI_API_KEY="your_api_key_here"

아래는 데모 날씨 데이터를 사용하는 OpenAI의 실행 가능한 비동기 툴 예제입니다. API 프로젝트에 Astra 접근 권한이 생기면 실행할 수 있습니다.

import json
from concurrent.futures import ThreadPoolExecutor

from openai import OpenAI
from openai.types.responses import FunctionToolParam

def get_weather(city):
    # Demo data. Replace this function with your weather service.
    weather = {
        "Paris": {
            "city": "Paris",
            "temperature_c": 22,
            "condition": "Clear",
            "source": "demo weather snapshot",
        }
    }
    return weather[city]

worker = ThreadPoolExecutor()

def main():
    client = OpenAI()
    model = "gpt-6-astra"
    tools: list[FunctionToolParam] = [
        {
            "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,
            },
        },
    ]

    instructions = (
        "Start the weather lookup and answer the independent packing "
        "question without waiting. Use the actual tool result when it "
        "arrives; never invent it. Identify the weather as demo data."
    )
    response = client.responses.create(
        model=model,
        tools=tools,
        instructions=instructions,
        input=(
            "Check the demo weather in Paris. Meanwhile, "
            "list three essentials for any city trip."
        ),
    )

    call = next(item for item in response.output if item.type == "function_call")
    arguments = json.loads(call.arguments)
    if call.name != "get_weather" or arguments != {"city": "Paris"}:
        raise ValueError("Expected a weather lookup for Paris")

    latest_response_id = response.id
    if call.async_:
        job = worker.submit(get_weather, **arguments)
        print(response.output_text)
        # Independent work or conversation turns can happen here.
        # Update latest_response_id after each continuation.
        result = job.result()
    else:
        result = get_weather(**arguments)

    response = client.responses.create(
        model=model,
        tools=tools,
        instructions=instructions,
        previous_response_id=latest_response_id,
        input=[
            {
                "type": "function_call_output",
                "call_id": call.call_id,
                "output": json.dumps(result),
            },
        ],
    )
    print(response.output_text)

if __name__ == "__main__":
    try:
        main()
    finally:
        worker.shutdown(wait=True)

대부분 놓치기 쉬운 줄은 call_id: call.call_id입니다. 그사이 새로운 대화 턴으로 최신 응답 ID가 바뀌었더라도, 나중에 도착한 결과는 원래 툴 호출에 속합니다.

기능별 권장 대상

함수 호출을 이미 사용하는 백엔드 팀

해당 경로에 Astra를 도입하기 전에 Responses 마이그레이션 예산부터 확보해야 합니다. 엔드포인트, 파서, 모델을 한꺼번에 바꾼 뒤 디버깅하는 대신, 로그와 평가 결과를 비교하면서 통제된 전환을 진행할 수 있습니다.

느린 서비스를 기다리는 SaaS 에이전트

정말로 독립적인 작업에만 비동기를 사용해야 합니다. CRM 조회, 내부 검색, 문서 내보내기는 Astra가 다른 분기를 처리하는 동안 먼저 시작할 수 있습니다. 다음 결정을 가로막는 의존 작업이라면 동기 방식을 유지하거나 명시적인 대기 툴을 사용하는 편이 낫습니다.

장시간 작업을 감독하는 운영팀 또는 에이전시

취소 후 재시작으로 이어질 만한 수정에는 스티어링을 제공할 수 있습니다. 실제로 막아낸 재시작 횟수와 수정할 때 보존된 완료 작업량을 추적해야 합니다. 그래야 기능 데모가 아닌 사업적 근거를 얻을 수 있습니다.

Zero Data Retention을 사용하는 규제 대상 기업

Responses WebSocket mode는 store: false 및 Zero Data Retention과 함께 작동하지만, 상태 관리는 애플리케이션의 몫이 됩니다. 필요한 경우 암호화된 reasoning Item을 보존하고, 응답 ID를 더 이상 사용할 수 없을 때 전체 컨텍스트를 재전송하며, 스티어링을 사용자에게 제공하기 전에 복구 경로부터 설계해야 합니다.

솔직히 짚어야 할 점

Astra 접근 권한은 아직 순차적으로 제공되고 있습니다. 마이그레이션 준비는 지금 시작할 수 있지만, 프로덕션의 전면 전환은 프로젝트 접근 권한과 워크로드별 평가 결과가 준비될 때까지 기다려야 합니다.

비동기 툴에는 작업 레지스트리와 순서가 뒤바뀔 수 있는 결과 처리가 추가됩니다. 스티어링에는 연결 상태, 후속 응답 처리, 복구 로직이 더해집니다. 둘 다 불필요한 대기나 재시작을 줄일 수 있지만, 동시에 실패할 수 있는 코드도 늘립니다.

자체 텔레메트리가 쌓이기 전까지 비용성은 확정할 수 없습니다. 같은 토큰 양이라면 Astra 요금은 GPT-5.6 Sol의 프로모션 요금보다 2.5배 높습니다. 캐시 효율 개선, 출력 토큰 감소, 재시작 감소로 일부 작업에서는 격차를 메울 수 있습니다. 파일럿에는 강제 지출 한도를 설정하고, 완료된 작업당 비용과 운영자 시간으로 Astra를 평가해야 합니다.

이번 주 월요일에 할 일

• 애플리케이션이 Chat Completions 툴 호출을 사용하고 Astra를 도입하려 한다면, 이번 주에 프로덕션 흐름 하나를 목록화하고 Responses 섀도 경로 예산을 확보합니다.
• 애플리케이션이 텍스트만 처리한다면 접근 권한이 확대되는 동안 현재 구성을 안정적으로 유지합니다. 이 경로에는 엔드포인트를 반드시 옮겨야 할 이유가 없습니다.
• 느린 툴이 전체 소요 시간을 좌우한다면 비동기 함수 하나를 시험하고, 유휴 시간, 실패, 완료된 작업당 비용을 측정합니다.
• 늦은 사람의 수정이 재시작을 일으킨다면 WebSocket 재연결 및 재전송 테스트를 통과한 뒤에만 스티어링 프로토타입을 만듭니다.
• 측정으로 확인된 상쇄 효과가 없는 상태에서 Astra의 2.5배 토큰 요금이 단위 경제성을 무너뜨린다면, 해당 워크로드는 GPT-5.6 Sol, Terra 또는 Luna에 유지합니다.

다음 플랫폼 변화를 실제 워크플로와 예산 결정으로 연결한 분석을 받아보려면 뉴스레터를 구독하세요.