tracks
개발자를 위한 AI 엔지니어 보조
26
GPT-6 Astra API란?
GPT-6 Astra API는 2026년 9월 3일에 공개된 OpenAI의 최신 플래그십 모델을 Responses API를 통해 사용하는 방법입니다. 이 튜토리얼에서 중요한 것은 인터페이스입니다: gpt-6-astra는 텍스트와 이미지 입력을 OpenAI의 Responses API로 받습니다. 이 모델의 추론 노력은 low부터 max까지이며 none 옵션은 없습니다.
이 튜토리얼의 예시는 client.responses.create를 client.chat.completions.create 대신 사용하지만, 마이그레이션에는 요청, 출력, 도구 결과 형식 변경도 필요합니다. 또한 Astra는 지원하지 않으므로 사용자 지정 temperature, top_p, 로그 확률 설정을 제거하세요. 첫 호출 전, 가격을 살펴보겠습니다.
GPT-6 Astra 요금은 얼마인가요?
입력 토큰이 최대 272,000개인 요청에 대해, 표준 요금은 일반 입력 토큰 백만 개당 $10, 출력 토큰 백만 개당 $50입니다. 캐시된 입력은 백만 개당 $1, 캐시 쓰기는 백만 개당 $12.50입니다.
요청이 해당 임계값을 넘으면, OpenAI는 입력 및 캐시 요금에 2배, 출력 요금에 1.5배의 승수를 적용합니다. 더 높은 요금은 임계값 초과분만이 아니라 요청 전체에 적용됩니다. 이 튜토리얼의 어떤 실행도 임계값에 근접하지는 않았습니다.
GPT-6 Astra API로 무엇을 만들까요?
스테이징 앱은 작은 Flask 작업 보드입니다: 홈 페이지, 작업 추가 폼, 완료 표시 버튼, 그리고 /health 엔드포인트가 있습니다. 완전한 코드는 스테이징 앱을 포함해 GitHub 리포지토리에 있습니다.
테스트 전에 세 개의 시드 작업이 표시됩니다. 이미지: 작성자.
앱에는 의도적인 결함이 하나 있습니다. 에이전트는 세 가지 체크를 갖지만, 그중 오직 테스트 스위트만이 이를 잡도록 설계되어 있습니다.
왜 앱이 빈 작업 제목을 허용하나요?
작업 생성 엔드포인트가 빈 제목을 거부하지 않습니다. 프롬프트로 이 문제를 드러내지 않고 에이전트가 찾아낼 수 있도록 해당 동작을 그대로 두었습니다.
에이전트가 실행할 수 있는 릴리스 체크는 무엇인가요?
에이전트는 세 가지 도구를 호출할 수 있습니다:
-
run_test_suite는 pytest를 실행하며, 약 250개의 HTTP 요청이 포함된 대량 가져오기 테스트도 포함합니다. -
check_ui_flow는 Playwright를 사용해 작업을 추가하고 표시되는지 확인합니다. -
check_staging_health는/health로 GET 요청을 보냅니다.
세 가지 모두 모의 객체 없이 스테이징에서 실행합니다. 브라우저 체크는 고정 코드로 수행하며, 모델 작성 컴퓨터 사용 데모는 뒤에서 다룹니다.
Python에서 GPT-6 Astra API 설정 방법
gpt-6-astra에 접근 가능한 OpenAI API 키가 필요합니다. platform.openai.com/api-keys에서 키를 만들고, 프로젝트에 gpt-6-astra가 활성화되어 있는지 확인하세요. 엔터프라이즈 워크스페이스는 출시 시 기본값이 비활성입니다.
아래 명령은 Windows PowerShell을 사용하며, 스티어링 데모를 위한 OpenAI의 realtime을 포함해 이 튜토리얼에 필요한 모든 패키지를 설치합니다.
python -m venv .venv
.venv\Scripts\Activate.ps1
Copy-Item .env.example .env
pip install "openai[realtime]" flask pytest playwright pydantic matplotlib python-dotenv streamlit
playwright install chromiummacOS 또는 Linux에서는 활성화 명령을 source .venv/bin/activate로, 복사 명령을 cp .env.example .env로 바꾸세요.
그런 다음 새 .env 파일에 API 키를 추가합니다: 방금 복사한 .env 파일을 열고 OPENAI_API_KEY=sk-...를 추가하세요. 그러면 python-dotenv가 이를 불러오고 SDK가 자동으로 인식해 코드에서 키를 직접 전달할 필요가 없습니다.
프로젝트별 의존성이나 .env 파일이 낯설다면, 우리의 가상 환경 및 환경 변수 가이드가 설명합니다. 키가 정상 동작하는지 확인한 뒤 진행하세요.
이미 Responses API로 API 키가 잘 동작한다면, 다음 하위 섹션은 건너뛰고 동기 도구 루프부터 시작하세요. 첫 요청은 설정 확인용입니다.
첫 번째 GPT-6 Astra API 호출 만들기
키를 준비했다면, dotenv로 로드해야 합니다. 이후 OpenAI 클라이언트를 만들고 client.responses.create() 함수로 첫 요청을 보낼 수 있습니다. 가능한 최소 요청은 다음과 같습니다:
from dotenv import load_dotenv
from openai import OpenAI
load_dotenv()
client = OpenAI()
response = client.responses.create(
model="gpt-6-astra",
reasoning={"effort": "low"},
input="In one sentence, what is a staging environment used for?",
)
print(response.output_text)응답의 usage 필드는 이후 비용 계산에 필요한 토큰 수를 제공합니다.
동기 GPT-6 Astra 도구 루프 구축
아래 스니펫은 발췌본이며, 실행 가능한 버전은 함께 제공된 GitHub 리포지토리에 있습니다.
비동기를 건드리기 전에 일반 버전을 먼저 만들었습니다:
-
모델 호출
-
function_call항목 확인 -
일치하는 도구 실행
-
previous_response_id와 함께 결과 반환 -
모델이 도구 요청을 멈출 때까지 반복
이 블로킹 루프가 비동기 비교의 기준선입니다.
for turn in range(max_turns):
response = client.responses.create(
model="gpt-6-astra",
reasoning={"effort": "low"},
tools=TOOLS,
input=next_input,
previous_response_id=previous_response_id,
)
calls = [item for item in response.output if item.type == "function_call"]
if not calls:
final_text = response.output_text
break
outputs = [
{"type": "function_call_output", "call_id": call.call_id, "output": run_tool(call)}
for call in calls
]
next_input, previous_response_id = outputs, response.id기준선 실행의 결과
기준선 실행에서 모델은 각 도구를 차례대로 호출했습니다. 알려진 검증 실패를 찾아 no-go 결정을 반환했습니다. 세 번의 실행에서 총 경과 시간 평균은 23.40초였습니다. 이 평균은 개별 도구 시간 대신 전체 실행 시간을 의미합니다.
GPT-6 Astra 비동기 도구 호출은 어떻게 동작하나요?
도구 스키마에 "async": true를 표시하면, 모델이 계속 작업하거나 대기하는 동안 앱이 해당 결과를 연기할 수 있습니다. 애플리케이션은 여전히 도구를 실행하고 백그라운드 작업을 관리합니다.
독립적인 체크를 동시에 실행하는 방법
저는 run_test_suite 와 check_ui_flow 를 비동기로 표시하고, 이 데모에서는 한 번에 대기 중인 작업 배치가 하나뿐이므로 인자가 없는 앱 정의 wait_for_tasks 도구를 추가했습니다. 인자 없는 대기는 예제를 간단하게 유지합니다.
프로덕션 러너에서는 작업 핸들로 잡을 식별하고 각 핸들을 원래 call_id에 바인딩한 다음, 다음 단계가 대기 중 결과에 의존할 때만 대기하세요.
완료된 각 결과는 원래 call_id로 반환하고, 대기 상태는 대기 도구 자체의 call_id로 반환합니다.
TOOLS = [
{"type": "function", "name": "run_test_suite", "async": True, ...},
{"type": "function", "name": "check_ui_flow", "async": True, ...},
{"type": "function", "name": "check_staging_health", ...},
{"type": "function", "name": "wait_for_tasks", ...},
]이번 실행에서는 앱이 표시된 각 호출을 스레드 풀에 제출했습니다. 백그라운드 체크가 실행되는 동안 빠른 동기 헬스 체크를 수행했습니다. 그런 다음 보류 중인 체크가 완료될 때까지 wait_for_tasks에서 블로킹했습니다.
비동기 도구 호출이 경과 시간을 줄이나요?
세 번의 실행에서, 비동기는 평균 경과 시간을 23.40초에서 18.94초로 19.1% 줄였습니다. 평균은 단순해 보였지만, 개별 실행값은 꽤 변동했습니다. 아래 차트는 실제 변동 폭을 보여줍니다. 세 번의 실행은 여기서 일어난 일을 보여주기에는 충분하지만, 프로덕션 지연을 예측하기에는 부족합니다.
두 모드 모두에서 실행 시간이 변동했습니다. 이미지: 작성자.
왜 동시 체크가 경쟁 상태를 유발했나요?
브라우저 체크와 대량 가져오기 테스트를 동시에 실행하면, 두 체크가 같은 인메모리 작업 목록을 수정했기 때문에 대량 가져오기의 단언이 실패하는 경우가 있었습니다. 테스트가 독점적 접근을 전제한 가정이 깨진 것입니다. 러너나 테스트 중 어느 한쪽에서 데이터를 격리하면 경쟁 상태를 피할 수 있습니다.
UI 테스트를 위한 경계가 있는 GPT-6 Astra 컴퓨터 사용
컴퓨터 사용의 경우, GPT-6 Astra 문서는 코드 실행을 권장하며, 대안으로 구조화된 computer 도구도 계속 지원됩니다. 코드 실행을 사용하면 한 번의 호출로 여러 동작, 루프, 조건 로직을 결합할 수 있는 반면, computer 도구는 애플리케이션이 번역 및 재생할 단일 구조화된 마우스/키보드 동작을 한 번에 하나씩 반환합니다.
컴퓨터 사용 러너를 제한하는 방법
클래스 이름을 BrowserSandbox라 했지만, 그 이름이 주는 보호 수준을 과대평가했습니다. 모델 작성 코드는 Playwright의 page, log() 함수, expect_text() 헬퍼를 받습니다. Python은 여전히 exec()에 내장 객체를 주입할 수 있고, 페이지는 다른 오리진으로 이동할 수 있습니다.
sandbox_globals = {"page": self.page, "log": log, "expect_text": expect_text}
exec(code, sandbox_globals)이를 보안 경계가 아닌 데모 러너로 취급하세요. 모델 작성 코드는 파일시스템, 프로세스, 네트워크, 오리진 제한이 있는 격리된 프로세스나 컨테이너가 필요합니다.
UI 체크에서 무슨 일이 있었나?
경계가 있는 체크에는 하드 스톱이 필요하므로 루프를 8턴으로 제한했습니다. 모델은 페이지를 검사하고 폼 입력을 찾은 다음, "UI flow check, cobalt otter 73921" 제목을 생성해 작업을 제출하고 제목이 나타남을 확인했습니다. 소요 시간은 13초였습니다. 우리의 GPT-5.4 컴퓨터 사용 튜토리얼은 Astra의 전임 모델로 자세한 예시를 다룹니다.
GPT-6 Astra 턴 중 스티어링은 어떻게 동작하나요?
턴 중 스티어링은 WebSocket 연결을 통한 gpt-6-astra 전용 기능입니다.
연결을 열고 응답을 생성한 다음, 응답 생성 중에 새 지시로 response.steer 이벤트를 보냅니다. response.steer.accepted 이벤트는 업데이트가 적용된 것이 아니라 대기열에 들어갔음을 의미합니다. 서버는 자동 연속 응답을 만들기 전에 현재 출력 항목과 이미 실행 중인 호스팅 도구 작업을 마칩니다.
클라이언트 도구 결과나 승인이 여전히 필요하면, response.steer.pending가 누락된 입력을 알려 줍니다.
async with client.responses.connect() as connection:
await connection.response.create(model="gpt-6-astra", input=TASK)
async for event in connection:
if event.type == "response.created" and initial_response_id is None:
initial_response_id = event.response.id
await asyncio.sleep(1.0)
await connection.response.steer(
previous_response_id=initial_response_id,
input="Also add a rollback plan, but skip mobile.",
)1초 지연은 실험 코드와 동일하며 첫 번째 응답이 시작할 시간을 줍니다. 지연이 없으면 응답 수명 주기의 다른 시점을 테스트하게 됩니다.
턴 중 스티어링으로 바뀌지 않는 것은?
스티어링은 원래 응답을 다시 쓰지 않습니다. 업데이트가 이를 중단하면, 그 응답은 status: "incomplete" 와 incomplete_details.reason: "steered"로 종료됩니다. 후속 응답이 새로운 지시로 계속됩니다.
첫 응답이 업데이트 적용 전 완료되면, 완료 상태로 유지됩니다. 스티어링은 이미 시작된 클라이언트 측 동작을 되돌리거나 취소하지 않습니다. 해당 동작은 여전히 애플리케이션 책임입니다. 대기 중인 스티어링은 현재 WebSocket 연결에만 존재하므로, 재연결을 시도하기 전에 업데이트를 기록하세요.
비교 경로는 첫 응답을 끝까지 보내고, 결합된 지시로 새 요청을 보냅니다. 두 번의 실행에서, 스티어링은 평균 26.91초, 완료-재시작 경로는 50.02초였습니다. 이 비교는 취소-재시작 정책을 다루지 않으며 최종 텍스트의 정확도도 점수화하지 않습니다.
시간과 비용의 두 번 실행 평균. 이미지: 작성자.
재시작 경로는 일부가 중복되는 두 개의 전체 응답을 생성합니다. 이 설정이 시간 격차의 일부를 설명하므로, 이 두 실행을 스티어링의 일반 벤치마크로 보지는 않겠습니다.
대화 중 GPT-6 Astra 추론 노력 변경 방법
gpt-6-astra 는 low 부터 max까지 추론 노력을 지원합니다. 더 높은 노력은 추론 토큰 사용을 늘릴 수 있지만, 다른 답을 보장하지는 않습니다. configuration_update 는 다음 및 이후 응답을 변경하며, 또 다른 업데이트가 이를 덮어쓸 때까지 유지됩니다. 요청 수준 설정은 변하지 않습니다.
이 파이프라인에서는 보고서가 대화를 종료하므로, 업데이트는 최종 단계에만 영향을 줍니다.
response = client.responses.create(
model="gpt-6-astra",
previous_response_id=previous_id,
reasoning={"effort": "low"}, # default remains low
input=[
{"type": "configuration_update", "reasoning": {"effort": "high"}},
{"role": "user", "content": "Diagnose the root cause and recommend a fix."},
],
)두 노력 수준에서 동일한 실패 트레이스를 사용해 진단과 토큰 사용량을 비교했습니다.
한 가지 미묘한 점: 응답의 reasoning.effort 필드는 여전히 요청 수준 설정을 보고하며, configuration_update로 선택된 노력 수준을 반영하지 않습니다. 업데이트 적용 여부를 확인하는 데 이 필드를 사용하지 마세요.
높은 추론 노력이 진단을 바꿨나요?
전체 결합 실행에서, 상향된 단계는 108개의 추론 토큰을 사용했습니다. low 수준의 다른 모든 단계는 0개를 사용했습니다. 더 긴 실패 트레이스로 수행한 이전의 개별 테스트에서도 low는 0개, high는 318개 추론 토큰을 사용했습니다. 두 버전 모두 검증 버그를 식별했습니다. 즉, 더 높은 노력 변경은 토큰 사용량을 바꿨지만 진단은 바꾸지 않았습니다.
구성 업데이트는 표준 단일 에이전트 요청에서만 동작합니다. API는 연속 업데이트를 거부하며, 자동 압축이나 자동 절단과 함께 사용할 수 없습니다.
GPT-6 Astra 구조화된 출력 사용 방법
파이프라인의 마지막 단계는 client.responses.parse를 호출해 자유 텍스트를 검증된 Pydantic 모델로 대체합니다.
class GoNoGoReport(BaseModel):
decision: str
summary: str
checks_completed: list[str]
failures: list[str]
risks: list[str]
follow_up_actions: list[str]
confidence: float
response = client.responses.parse(
model="gpt-6-astra",
previous_response_id=previous_id,
text_format=GoNoGoReport,
input=[...],
)Pydantic은 여기 선언한 필드 타입을 검사합니다. 보고서가 증거와 일치함을 보장하지는 않으며, 이 버전은 decision 을 두 값으로 제한하거나 confidence를 범위로 제한하지도 않습니다.
승인/보류 보고서는 무엇을 포착했나요?
보고서는 decision: "no_go"를 반환했습니다. 앞서 언급한 검증 실패를 failures에, 동시성 문제를 risks에 분류했습니다. 후자에 대해서는 "공유 스테이징 데이터에 대한 동시 UI 체크로 인한 간섭 가능성"이라고 기술했습니다. 프롬프트는 해당 위험을 명시하지 않았습니다.
지연 시간과 비용은 이 스키마 밖에서 유지하고 코드에서 계산하세요. 모델은 도구 증거에서 보고서 필드를 채웁니다.
Streamlit 인터페이스는 명령줄 러너와 동일한 제너레이터를 사용합니다. 도착하는 대로 각 도구 이벤트를 렌더링하고, 이후 Report 및 JSON 탭에 파싱된 보고서를 표시합니다.