GPT-6 Astra로 컴퓨터 작업 구현하기: API 경로와 안전한 실행 루프

GPT-6 Astra에 “사이트에 로그인해 보고서를 내려받아라”라고 요청하는 것만으로 컴퓨터 자동화가 완성되지는 않습니다. 모델은 실행할 코드나 마우스·키보드 동작을 제안하고, 애플리케이션이 이를 제한된 환경에서 실행한 뒤 새 화면을 돌려줘야 합니다. 결제, 데이터 전송, 삭제처럼 되돌리기 어려운 지점에서는 실행 전에 사람이 확인하고, 마지막에는 모델의 설명이 아니라 실제 화면과 저장된 결과를 검사해야 합니다.

또 하나의 선행 조건은 접근 권한입니다. 2026년 9월 4일 기준 OpenAI는 GPT-6 Astra를 Trusted Access Program의 기업 고객부터 순차 제공 중이며, API와 Plus·Pro·Business·Enterprise 제공은 구체적인 날짜 대신 coming days로 안내합니다. 따라서 아래 통합 방식은 현재 API 계약을 설명하지만, 모든 계정에서 곧바로 호출된다는 뜻은 아닙니다. 최신 상태는 OpenAI의 GPT-6 Astra 출시 안내와 자신의 계정에서 함께 확인해야 합니다.

먼저 제품 접근과 API 접근을 따로 확인합니다

ChatGPT의 모델 선택기에 Astra가 보이는 것과 API 키로 gpt-6-astra를 호출할 수 있는 것은 별개의 권한입니다. ChatGPT 워크스페이스 관리자가 모델을 켜더라도 API 키가 속한 organization/project에 접근 권한이 자동으로 생기지 않습니다. 초기 Enterprise 제공에는 별도의 관리자 조건도 있으므로, 조직 사용자는 워크스페이스 모델 제공 범위를 먼저 확인하는 편이 안전합니다.

데스크톱의 Computer Use도 같은 이름 때문에 혼동하기 쉽습니다. 지원 지역의 macOS·Windows에서 ChatGPT Work와 Codex가 제공하는 제품 기능이며, 계정의 모델 선택기와 운영체제 권한에 따라 사용 가능성이 달라집니다. 이는 개발자가 실행 환경을 만드는 API 기능과 동일한 제공 경로가 아닙니다. 앱에서 직접 작업을 맡기려는 경우에는 ChatGPT Computer Use 안내를 확인하고, API 통합이라면 프로젝트 권한과 최소 Responses 요청을 별도로 확인해야 합니다.

API의 정확한 모델 ID는 gpt-6-astra입니다. 모델 페이지에 Responses, Chat Completions, Batch가 함께 표시되지만, Astra에서 function이나 computer 같은 도구를 호출하려면 Responses API를 사용해야 합니다. Chat Completions에서 일반 텍스트 응답을 받을 수 있다는 사실은 그 엔드포인트에서 도구 호출도 된다는 뜻이 아닙니다. 이 제한은 Astra API 마이그레이션 안내에 명시돼 있습니다.

접근 확인은 기능 플래그처럼 다루는 것이 좋습니다. 개발 환경에서 작은 Responses 요청으로 해당 API 프로젝트의 권한을 확인하고, 실패하면 사용자가 알 수 있는 대체 경로를 제시합니다. 다른 모델로 조용히 바꾸면 동작 형식과 안전 판단이 달라졌는데도 같은 실행으로 오인할 수 있습니다.

Astra가 컴퓨터를 다루는 두 가지 방식

OpenAI의 computer use 가이드는 새 Astra 통합에 code execution을 권장하고, 네이티브 computer tool도 대안으로 지원합니다. 두 방식 모두 실제 브라우저나 데스크톱은 개발자가 제공하고 운영합니다.

이미 function calling이나 remote MCP 기반 UI 도구가 있다면 그 인터페이스를 유지할 수도 있습니다. 중요한 선택 기준은 “어느 쪽이 더 자율적인가”가 아니라, 현재 시스템이 어떤 동작을 관찰하고 제한하며 재현할 수 있는가입니다.

권장 경로인 code execution을 연결하는 방법

이 방식에서 Astra는 일반 function tool을 호출해 스크립트를 전달합니다. 문서 예시에 등장하는 execute_in_sandbox 같은 실행 서비스는 OpenAI 엔드포인트가 아니라 애플리케이션이 직접 운영하는 구성 요소입니다. 브라우저 세션을 여러 호출 사이에 유지하되 API 클라이언트와 비밀 정보에서는 분리된 컨테이너나 VM에 두어야 합니다.

아래 JavaScript는 호출 관계를 보여주는 구조 예시입니다. 특정 계정에서 실행해 얻은 결과가 아니며, runInIsolatedRuntime과 verifyExpectedState는 각 서비스가 안전 정책에 맞게 구현해야 합니다.

js
import { randomUUID } from "node:crypto";
import OpenAI from "openai";

const openai = new OpenAI();
const sessionId = randomUUID();
const tools = [{
  type: "function",
  name: "exec_js",
  description: "Run an approved Playwright script in an isolated browser session",
  parameters: {
    type: "object",
    properties: { code: { type: "string" } },
    required: ["code"],
    additionalProperties: false,
  },
  strict: true,
}];

let nextInput = [{
  role: "user",
  content: "관리자 페이지에서 오늘 생성된 보고서를 찾아 이름만 확인하세요. 다운로드나 전송은 하지 마세요.",
}];
let previousResponseId;

for (let turn = 0; turn < MAX_TURNS; turn += 1) {
  const response = await openai.responses.create({
    model: "gpt-6-astra",
    tools,
    input: nextInput,
    previous_response_id: previousResponseId,
  });

  if (response.status !== "completed") {
    throw new Error(`Response stopped with status: ${response.status}`);
  }

  const calls = response.output.filter(
    (item) => item.type === "function_call",
  );

  if (calls.length === 0) {
    await verifyExpectedState();
    break;
  }

  nextInput = [];
  for (const call of calls) {
    if (call.name !== "exec_js") throw new Error(`Unexpected tool: ${call.name}`);
    const { code } = JSON.parse(call.arguments);
    const observation = await runInIsolatedRuntime(code, sessionId);
    nextInput.push({
      type: "function_call_output",
      call_id: call.call_id,
      output: JSON.stringify(observation),
    });
  }
  previousResponseId = response.id;
}

실제 구현에서는 생성된 임의 코드를 호스트 운영체제에서 바로 실행하면 안 됩니다. 실행 서비스는 허용된 브라우저 helper만 노출하고, 접속 가능한 도메인과 파일 경로를 제한하며, CPU·메모리·실행 시간과 전체 단계 수를 강제해야 합니다. 클라이언트의 요청 제한 시간은 기다림을 끝낼 뿐 멈추지 않는 프로세스를 종료하지 않을 수 있으므로 실행 환경 자체에도 마감 시간과 강제 종료가 필요합니다. Node.js vm이나 제한된 Python globals만으로는 보안 경계가 되지 않는다는 점도 실행 서비스 격리 지침에 명확히 나와 있습니다.

하나의 스크립트에는 여러 클릭과 입력, 반복문이 포함될 수 있습니다. 따라서 “스크립트 실행을 한 번 승인했다”는 식으로 포괄 동의를 받으면 중간의 결제나 업로드를 놓칠 수 있습니다. 파일 업로드, 외부 전송, 구매 확정, 삭제, 권한 변경 같은 동작은 실행 helper에서 구분하고 바로 직전에 새 확인을 요구해야 합니다.

네이티브 computer tool은 action batch를 직접 처리합니다

구조화된 마우스·키보드 실행기가 이미 있다면 tools: [{ type: "computer" }]를 사용하는 대안이 더 단순할 수 있습니다. Responses API가 computer_call을 반환하면 애플리케이션은 actions[]를 순서대로 검사하고, 허용된 동작만 실행한 뒤 갱신된 화면을 캡처합니다. 다음 요청에는 원래 call_id와 같은 ID를 사용한 computer_call_output을 보내야 합니다.

ts
const nextResponse = await openai.responses.create({
  model: "gpt-6-astra",
  tools: [{ type: "computer" }],
  previous_response_id: response.id,
  input: [{
    type: "computer_call_output",
    call_id: computerCall.call_id,
    output: {
      type: "computer_screenshot",
      image_url: `data:image/png;base64,${screenshotBase64}`,
      detail: "original",
    },
  }],
});

이 예시도 실행 순서만 나타냅니다. 각 actions[]를 실행하기 전에 정책 검사를 해야 하며, 위험한 동작이 작업 묶음 안에 있으면 그 첫 동작 직전에 멈춰 확인을 받습니다. computer_call.status: "completed"는 모델이 호출 생성을 끝냈다는 뜻이지, 애플리케이션이 클릭을 수행했거나 업무가 성공했다는 뜻이 아닙니다. API 응답이 incomplete/failed 상태이거나 동작이 일부만 생성됐거나 애플리케이션의 단계·시간 한도에 도달하면 실행을 중단해야 합니다.

스크린샷은 좌표 정확도를 위해 일반적으로 detail: "original"이 권장됩니다. 다만 큰 화면은 입력 토큰을 더 사용합니다. 이미지를 줄였다면 모델이 반환한 좌표를 원래 화면 좌표계로 다시 변환해야 하며, 이 매핑 없이 축소 화면의 좌표를 그대로 클릭하면 잘못된 대상을 누를 수 있습니다. 자세한 조건은 스크린샷 처리 지침에서 확인할 수 있습니다.

대화 상태와 브라우저 상태를 함께 이어야 합니다

previous_response_id는 모델이 앞선 대화와 tool 결과를 이어서 해석하도록 돕지만, 로그인 쿠키나 열린 탭, 다운로드 파일, JavaScript 변수까지 복원하지 않습니다. 다음 표처럼 두 상태를 별도로 저장하고 같은 작업 ID로 연결해야 합니다.

브라우저가 재시작됐는데 예전 previous_response_id만 이어 붙이면 모델은 더 이상 존재하지 않는 화면을 전제로 행동할 수 있습니다. 반대로 브라우저는 살아 있는데 call_id가 바뀌면 tool 결과가 잘못된 호출과 연결됩니다. 둘 중 하나라도 연속성을 증명할 수 없다면 자동 실행보다 재확인이 안전합니다.

확인은 모델의 문장이 아니라 실행 경계에서 시행합니다

웹페이지, 이메일, PDF, 도구 결과와 화면 문구는 모두 신뢰할 수 없는 외부 입력입니다. 화면에 “이 작업은 이미 승인됨”이라고 적혀 있어도 사용자 권한을 대신하지 못합니다. 예상하지 못한 비밀 정보 요청, 보안 경고 무시, 다른 사이트로의 전송 또는 지시문 주입이 보이면 실행을 멈추고 사용자에게 현재 화면과 예정 동작을 설명해야 합니다.

OpenAI의 확인 및 동의 지침에 따라 최소한 다음 동작은 효과가 발생하기 전에 확인합니다.

• 구매나 구독 확정, 결제 수단 사용
• 파일 업로드, 메시지 전송, 폼에 민감 정보 입력
• 데이터 삭제나 덮어쓰기
• 사용자·역할·공유 범위 같은 권한 변경
• 브라우저나 사이트의 안전 경고를 우회하려는 동작

민감한 값을 폼에 입력하는 순간도 데이터 전송입니다. 마지막 제출 버튼에서만 확인해서는 늦을 수 있습니다. 비밀번호 최종 입력이나 안전 장벽 우회처럼 자동화가 적절하지 않은 단계는 사용자가 직접 이어받도록 해야 합니다.

격리 환경은 일회성이고 최소 권한이어야 합니다. API 키와 운영 서버 자격 증명을 브라우저 실행 환경에 넣지 않고, 필요한 사이트만 허용 목록에 두며, 다운로드와 업로드 경로를 별도로 제한합니다. 전체 요청에는 단계·시간·비용 한도와 취소 기능을 둡니다. Astra의 비동기 안전 모니터링이 일부 문제를 표시하거나 대화를 중단할 수 있어도 탐지 누락과 오탐이 가능하고 이미 실행된 동작을 되돌리지 않으므로, 애플리케이션의 제어를 대체하지 못합니다.

마지막 응답 대신 관찰 가능한 결과를 검증합니다

좋은 완료 조건은 “모델이 완료했다고 말했다”가 아니라 처음 요청한 결과를 시스템에서 다시 확인할 수 있는 상태입니다. 예를 들어 보고서 다운로드 작업이라면 다음을 구분합니다.

1. 올바른 날짜와 계정의 보고서가 선택됐는가.
2. 다운로드 응답이 성공했는가.
3. 격리된 다운로드 디렉터리에 예상 형식의 파일이 생성됐는가.
4. 파일 크기와 필요한 경우 체크섬 또는 파서 검사가 통과했는가.
5. 외부 전송이나 원본 삭제처럼 요청하지 않은 부수 효과가 없었는가.

로그에는 프롬프트 전문이나 비밀 값을 남기기보다 작업 ID, 허용된 도메인, 실행한 helper/action 종류, 확인 시각과 결정, 응답 ID, 검증 결과를 구조화해 기록합니다. 실패하면 어느 경계에서 멈췄는지를 구분해야 복구 방식도 정해집니다. 접근 거부는 계정 권한 확인으로, 호출 연결 오류는 call_id/previous_response_id 점검으로, 화면 불일치는 실행 환경 상태 복원으로, 정책 차단은 사용자 확인 또는 작업 축소로 돌려보냅니다.

모델 호출이 끝났더라도 검증이 실패하면 작업은 실패입니다. 자동 재시도는 같은 잘못된 클릭이나 중복 구매를 반복할 수 있으므로, 마지막으로 확인된 안전한 화면과 멱등성 조건이 있을 때만 재개합니다. misalignment_policy_violation을 받은 경우에는 자동 재시도하지 않습니다.

computer-use-preview에서 Astra로 바로 바꾸지 않습니다

기존 computer-use-preview 통합의 공식 GA 마이그레이션 표는 Astra가 아니라 gpt-5.6-sol을 가리킵니다. 함께 바뀌는 계약은 다음과 같습니다.

• 모델: computer-use-preview → gpt-5.6-sol
• 도구 유형: computer_use_preview → computer
• 한 번의 action → 순서가 있는 actions[]
• 필수였던 truncation: "auto" → 더 이상 필요하지 않음

이 변경은 OpenAI의 computer use 통합 문서에 있는 기존 preview 마이그레이션 표를 그대로 따른 것입니다. 기존 실행기를 유지해야 한다면 먼저 이 GA 방식으로 옮기고 작업 묶음과 확인 로직을 수정합니다. 새 Astra 통합을 설계한다면 별도의 결정으로 보고, 공식 권장안인 code execution부터 적합성을 판단합니다. “모델 이름만 Astra로 교체”하는 것은 두 마이그레이션을 섞는 방식입니다.

Preview 모델은 짧은 공지 기간으로 중단될 수 있으며, 빠르게 이전할 수 없는 핵심 업무에는 권장되지 않습니다. 다만 이는 computer-use-preview의 특정 종료일이 발표됐다는 뜻은 아닙니다. 현재 공지와 실제 계정 접근을 확인하고, 모델·도구 형식·실행기 변경을 각각 검증해야 합니다.

운영에 넣기 전에는 한정된 테스트 계정과 되돌릴 수 있는 작업으로 시작하십시오. 접근 권한, Responses 호출, 실행 환경 유지, 위험 동작 확인, 중단 조건, 최종 상태 검증을 각각 통과시켜야 비로소 컴퓨터 작업 하나가 끝까지 연결된 것입니다.