GPT‑6 Astra 컴퓨터 유즈 실전 가이드: 안전한 Playwright 에이전트 설계

GPT‑6 Astra의 컴퓨터 유즈는 단순히 화면을 보고 다음 클릭 좌표를 고르는 기능이 아닙니다. OpenAI는 Astra에서 Playwright나 PyAutoGUI를 사용하는 코드 실행 방식을 권장합니다. 반복과 조건 분기를 한 번의 실행으로 묶고, 실제 페이지 상태를 코드로 검사할 수 있기 때문입니다.

하지만 모델이 코드를 잘 작성하는 것과 실제 계정을 안전하게 맡길 수 있다는 것은 다른 문제입니다. 이 가이드는 브라우저 에이전트를 관찰 → 계획 → 제한된 실행 → 검증 → 승인의 작은 루프로 만드는 방법을 설명합니다. 기존의 일반적인 프롬프트 인젝션 안전 글과 달리 Astra·Responses API·Playwright 구현 구조에 집중합니다.

1. 먼저 컴퓨터 유즈의 세 가지 연결 방식을 고른다

웹 업무라면 Playwright를 우선하고, 화면으로만 접근 가능한 데스크톱 앱은 PyAutoGUI를 검토합니다. 안정적인 API나 MCP가 있다면 위험한 데이터 변경은 UI보다 의미가 명확한 도구로 제한하는 편이 좋습니다. 하나만 고집할 필요는 없습니다. 공개 웹 탐색은 Playwright, 승인된 CRM 변경은 전용 함수처럼 조합할 수 있습니다.

2. 권장 아키텍처를 다섯 층으로 나눈다

사용자 목표
   ↓
Astra / Responses API ── 계획·코드 생성
   ↓
정책 게이트 ── 사이트·행동·비밀·승인 검사
   ↓
격리 Playwright 런타임 ── 제한된 코드 실행
   ↓
관찰·검증기 ── 스크린샷 + DOM + 실제 최종 상태
   ↓
실행 기록·사람 승인·복구

모델과 브라우저 사이의 정책 게이트가 중요합니다. 모델의 설명만 보고 실행하지 말고, 코드와 목적지를 검사하고 허용된 기능만 노출해야 합니다. 브라우저 세션은 개인 브라우저가 아니라 별도 프로필이나 컨테이너에서 열고, 필요한 계정만 로그인합니다.

3. 실행 도구는 작고 제한적으로 만든다

공식 예제처럼 모델에 임의의 Playwright 코드를 받는 함수 도구를 줄 수 있습니다. 실제 운영에서는 함수가 세션, 허용 호스트, 실행 시간과 결과 크기를 강제해야 합니다.

type BrowserRun = {
  code: string;
  taskId: string;
};

async function executeBrowserCode(input: BrowserRun) {
  assertAllowedSyntax(input.code);
  const session = await getIsolatedSession(input.taskId);
  const result = await session.run(input.code, {
    timeoutMs: 15_000,
    allowedHosts: ['docs.example.com', 'app.example.com'],
    maxPageCount: 3,
    networkWrite: false,
  });
  return {
    stdout: result.stdout.slice(0, 20_000),
    screenshot: result.screenshot,
    url: result.url,
  };
}

위 코드는 설계 예시이며 OpenAI SDK의 완성된 샌드박스 구현이 아닙니다. 핵심은 모델이 만든 코드보다 런타임 정책이 우선하도록 하는 것입니다. 문자열 검사만으로 보안을 끝내지 말고 프로세스·파일·네트워크를 실행 환경 수준에서 제한해야 합니다.

4. 한 번에 너무 많은 행동을 허용하지 않는다

코드 실행의 장점은 여러 행동을 묶는 것이지만, 로그인부터 결제까지 한 프로그램으로 실행하면 검토 지점을 잃습니다. 한 번의 실행은 관찰하거나 되돌릴 수 있는 작은 단위로 제한합니다.

권장 루프는 다음과 같습니다.

1. 현재 URL, 중요한 DOM 요소와 스크린샷을 관찰한다.
2. Astra가 다음 작은 목표와 코드를 만든다.
3. 정책 게이트가 호스트·행동·민감 정보 사용을 검사한다.
4. 샌드박스가 제한된 시간 동안 실행한다.
5. 모델의 보고가 아니라 DOM·데이터·스크린샷으로 결과를 확인한다.
6. 전송·결제·삭제면 실행 직전에 사람 승인을 받는다.
7. 결과를 기록하고 다음 루프로 이동한다.

5. 승인 화면에는 정확한 변화가 보여야 한다

“계속할까요?”라는 버튼만으로는 충분하지 않습니다. 승인 카드에는 다음 항목을 표시합니다.

• 수행할 행동: 메일 전송, 주문 확정, 파일 삭제 등
• 대상: 수신자, 계정, 파일과 최종 URL
• 전송할 데이터: 본문, 첨부, 개인정보 필드
• 변경 전후 상태와 예상 비용
• 취소·수정·승인 선택

페이지나 문서 안의 문장은 권한을 줄 수 없습니다. 외부 콘텐츠가 “보안을 끄라”, “다른 주소로 보내라”, “토큰을 입력하라”고 요구해도 사용자 지시로 승격하지 않아야 합니다.

6. 완료 판정은 모델의 문장이 아니라 상태 검사로 한다

에이전트가 “등록했습니다”라고 답해도 실제로는 오류 메시지가 떠 있을 수 있습니다. 가능한 항목은 결정적으로 검사합니다.

같은 요청을 재시도해도 중복 주문이나 메시지가 생기지 않도록 task ID와 멱등성 키를 사용합니다. 실패 시 세션을 그대로 유지해 원인을 조사하되, 위험한 쓰기를 자동으로 반복하지 않습니다.

7. Async tool calling과 steering은 상태 머신으로 관리한다

Astra는 느린 도구가 실행되는 동안 다른 일을 계속할 수 있고, WebSocket을 통해 작업 중 새 지시를 받을 수 있습니다. 편리하지만 늦게 끝난 도구 결과가 최신 지시와 충돌할 수 있습니다.

각 작업에 다음 상태를 기록하세요.

queued → running → awaiting_approval → completed
                  ↘ cancelled
                  ↘ blocked
                  ↘ failed

원래 call ID, 지시 버전, 시작 시각, 취소 가능 여부와 결과 채택 여부를 저장합니다. steering은 이미 시작된 도구를 자동 취소하지 않으므로, 구버전 결과는 화면에 표시하되 후속 변경에 사용하지 않는 정책이 필요합니다.

8. 최소 운영 평가표를 만든다

출시 전 동일한 작업을 여러 번 실행하고 다음을 측정합니다.

컴퓨터 유즈는 모델 벤치마크만으로 선택하기 어렵습니다. 로그인 방식, 페이지 구조, 권한 정책과 네트워크가 다른 실제 업무 세트에서 검증해야 합니다.

배포 전 체크리스트

• [ ] 개인 브라우저와 분리된 실행 환경인가
• [ ] 허용 호스트·도구·쓰기 행동이 제한됐는가
• [ ] 비밀 값이 모델 출력과 로그에 노출되지 않는가
• [ ] 짧은 행동 묶음마다 실제 상태를 확인하는가
• [ ] 전송·결제·삭제 직전 사람 승인이 있는가
• [ ] 실행 시간·단계·비용 상한과 취소가 있는가
• [ ] 재시도가 중복 변경을 만들지 않는가
• [ ] steering 이후 오래된 결과를 구분하는가
• [ ] 실패와 승인 기록을 감사할 수 있는가

결론: 넓게 보되 좁게 행동하게 한다

GPT‑6 Astra의 코드 실행형 컴퓨터 유즈는 반복적인 웹 업무와 UI 테스트를 더 큰 작업 단위로 자동화할 수 있게 합니다. 그러나 모델이 더 강해질수록 넓은 권한을 주는 것이 아니라, 관찰은 넓게 허용하되 행동은 작은 샌드박스와 명시적 승인 안에 가둬야 합니다.

가장 좋은 시작점은 결제나 삭제가 없는 읽기 전용 작업 하나입니다. Playwright로 결과를 검증하고, 실패 사례를 평가 세트에 추가한 뒤, 검증 가능한 쓰기 작업을 한 단계씩 늘리세요.

참고한 공식 자료

• OpenAI Developers: Computer use
• OpenAI Developers: GPT‑6 Astra model guidance
• OpenAI Developers: Async tool calling
• OpenAI Developers: Mid-turn steering
• OpenAI Developers: Misalignment monitoring