Responses API 컴퓨터 환경, 믿으면 막히는 3가지

Published on

in

Responses API 컴퓨터 환경, 믿으면 막히는 3가지

2026.03.11 공개 기준
gpt-5.4 기준
⚠ 3.31 비용 전환

Responses API 컴퓨터 환경,
믿으면 막히는 3가지

OpenAI가 3월 11일 Responses API에 컴퓨터 환경을 붙였습니다. 셸 도구, 호스팅 컨테이너, Skills까지 한 번에 묶인 구조인데— 막상 써보면 기대와 다른 부분이 세 군데에서 나옵니다. 그리고 3월 31일부터 컨테이너 과금이 시작됩니다. 지금 구조를 제대로 이해하지 못하면 비용도, 동작도 예상과 다를 수 있습니다.

38.1%
OSWorld 컴퓨터 사용 벤치마크
(OpenAI 공식 발표)
$0.03
1GB 컨테이너 20분당
(3.31 이후 과금 단위)
20분
비활성 후 컨테이너
자동 만료 시간

이번 발표가 기존 에이전트 구조와 다른 이유

OpenAI가 2026년 3월 11일 Responses API에 컴퓨터 환경을 붙였다는 소식은 꽤 빠르게 퍼졌습니다. 그런데 정확히 무엇이 달라진 건지 공식 발표문을 직접 보면 이야기가 달라집니다.

기존 Responses API는 이미 웹 검색, 파일 검색, 컴퓨터 사용 도구를 품고 있었습니다. 이번 발표는 여기에 셸 도구(shell tool), 호스팅 컨테이너 작업공간, Skills 번들, 네이티브 컨텍스트 압축을 추가한 것입니다. 단순히 도구 하나를 얹은 게 아니라, 모델이 다단계 작업을 처음부터 끝까지 실행할 수 있는 실행 인프라를 통째로 붙인 구조입니다.

이전까지는 개발자가 실행 하네스, 파일 처리, 네트워크 통제를 직접 만들어야 했습니다. 이번 발표 후에는 OpenAI 플랫폼이 격리된 Debian 12 기반 컨테이너와 파일시스템, 선택적 SQLite 저장소, 허용 목록 기반 네트워크 접근을 기본 제공합니다. 개발자 관점에서 설계 복잡도가 크게 줄어드는 변화이긴 한데— 그렇다고 모든 게 자동으로 해결되지는 않습니다.

💡 공식 발표문과 실제 셸 가이드 문서를 같이 놓고 보니, 언론에서 쓴 “AI가 직접 컴퓨터를 쓴다”는 표현이 실제 동작 방식과 조금 다르다는 게 보였습니다.

▲ 목차로 돌아가기

모델은 명령을 ‘실행’하지 않습니다 — 구조 오해 바로잡기

솔직히 말하면, 이 부분이 가장 많이 오해되는 지점입니다. “AI가 셸 명령을 직접 실행한다”고 표현하는 글이 많은데, 공식 셸 가이드 문서에는 정반대가 적혀 있습니다.

실제 동작은 이렇습니다. 모델은 shell_call이라는 형태로 “이 명령을 실행해달라”고 제안합니다. 그 명령을 실제로 실행하는 건 플랫폼(hosted 모드)이거나 개발자가 직접 만든 하네스(local 모드)입니다. 실행 결과인 stdout, stderr, 종료 코드는 shell_call_output으로 다시 모델에 돌아오고, 모델은 그 결과를 보고 다음 명령을 제안합니다. 이 루프가 반복되는 구조입니다.

⚠ local shell 모드에서 가장 많이 겪는 함정

local shell은 API 호출 한 번으로 끝나지 않습니다. 모델이 shell_call을 내면, 개발자 쪽 코드가 실제 명령을 실행하고 결과를 다시 API로 보내야 루프가 이어집니다. 이 오케스트레이션 코드가 없으면 모델이 명령만 제안하고 끝납니다.

hosted 모드는 이 루프를 OpenAI 플랫폼이 대신 돌려줍니다. 컨테이너 위에서 명령이 실행되고 결과가 자동으로 돌아오니 개발자가 따로 하네스를 짤 필요가 없습니다. 대신 컨테이너가 소비되고, 3월 31일부터는 그 사용량이 과금됩니다.

구분 hosted shell local shell
실행 주체 OpenAI 호스팅 컨테이너 개발자 직접 실행
하네스 필요 여부 불필요 직접 구현 필수
3.31 이후 비용 20분당 $0.03~$1.92 컨테이너 비용 없음
ZDR 환경 지원 ❌ 불가 ✅ 가능
네트워크 접근 허용 목록 기반 (기본 차단) 개발자 인프라 따름

▲ 목차로 돌아가기

3월 31일부터 달라지는 비용 구조, 직접 계산해봤습니다

OpenAI 공식 가격 페이지에 이런 내용이 있습니다. “현재 가격: 1GB(기본값) $0.03/컨테이너 → 2026년 3월 31일부터: $0.03/20분당 세션”입니다. (출처: openai.com/ko-KR/api/pricing/)

지금까지는 컨테이너 하나를 만들면 얼마나 오래 쓰든 $0.03 고정이었습니다. 3월 31일 이후에는 20분 단위로 반복 과금됩니다. 컨테이너가 비활성 상태에서 20분을 넘기면 자동 만료되지만, 활성 상태라면 20분마다 비용이 붙습니다.

직접 계산해보면

데이터 분석 작업을 1GB 컨테이너로 2시간 운영한다고 가정합니다.
2시간 = 6개 단위(20분 × 6) → $0.03 × 6 = $0.18
4GB 컨테이너로 같은 작업: $0.12 × 6 = $0.72
16GB 컨테이너로 하루(8시간): $0.48 × 24 = $11.52/일

출처: openai.com/ko-KR/api/pricing/ (2026.03.29 확인)

$0.18이면 작은 금액처럼 보이지만, 이건 컨테이너 사용료만입니다. 여기에 gpt-5.4 모델의 토큰 비용($2.50/100만 입력 토큰, $15.00/100만 출력 토큰)이 별도로 붙습니다. (출처: openai.com/ko-KR/api/pricing/) 긴 에이전트 루프에서 중간 산출물과 로그가 쌓이면 토큰 소비가 급격히 늘어날 수 있습니다.

기대했던 것과 달리, 비용 전환 시점이 정확히 3일 후입니다. 지금 테스트하고 있다면 컨테이너 사용 패턴을 파악해두는 게 유리합니다.

▲ 목차로 돌아가기

보안을 강화할수록 오히려 못 쓰는 기능이 생깁니다

공식 셸 가이드에 이런 내용이 딱 나와 있습니다. “조직이나 프로젝트에서 ZDR(Zero Data Retention)을 활성화하면, OpenAI 호스팅 컨테이너를 사용할 수 없으므로 hosted shell을 ZDR 모드에서 실행할 수 없습니다.” (출처: platform.openai.com/docs/guides/tools-shell)

ZDR은 데이터 보안 요건이 높은 기업 고객이 OpenAI에 데이터 보존을 하지 말도록 설정하는 옵션입니다. 금융, 의료, 공공 분야처럼 규제 환경이 강한 곳이 주로 활성화합니다. 그런데 ZDR을 켜면 hosted container 자체가 비활성화됩니다. 컨테이너가 없으니 hosted shell도 쓸 수 없습니다.

이 경우 선택지는 local shell뿐입니다. local shell은 개발자 인프라에서 실행되니 ZDR 제약과 충돌하지 않습니다. 다만 앞서 설명한 대로 shell_call_output 루프를 직접 구현해야 하고, 컨테이너 기반 Skills 번들도 쓸 수 없습니다.

💡 공식 가이드와 ZDR 정책을 같이 보면, 에이전트 인프라의 편의성과 데이터 통제권 사이에서 선택해야 하는 지점이 분명하게 드러납니다. 보안이 중요한 환경일수록 hosted 모드 대신 local 모드 설계를 먼저 검토해야 한다는 뜻입니다.

또 한 가지, 네트워크 접근도 기본적으로 차단됩니다. hosted 컨테이너는 외부 네트워크가 기본 차단이고, 관리자가 조직 대시보드에서 허용 목록을 설정해야만 도메인 단위로 접근이 열립니다. pip install이나 외부 API 호출이 필요한 워크플로라면 이 설정을 먼저 잡아야 합니다.

▲ 목차로 돌아가기

벤치마크 수치가 실제와 다를 수 있는 이유

OpenAI 공식 발표에 따르면 컴퓨터 사용 에이전트(CUA)가 OSWorld 벤치마크에서 38.1%를 기록했습니다. Anthropic Claude Computer Use는 22.0%였습니다. (출처: openai.com/ko-KR/index/new-tools-for-building-agents/) 단순히 숫자만 보면 OpenAI가 앞서 보입니다.

그런데 독립 평가 기관인 xlang.ai가 운영하는 OSWorld 공개 리더보드를 보면 이야기가 다릅니다. 2026년 3월 기준 상위 6위가 전부 Anthropic 모델이 점유하고 있습니다. (출처: awesomeagents.ai/leaderboards/computer-use-leaderboard/) 단, 이 리더보드는 제출 방식과 평가 조건이 OpenAI 자체 평가와 다를 수 있습니다.

💡 공식 발표 수치와 독립 리더보드 순위를 나란히 놓으니, 같은 벤치마크라도 누가 평가하느냐에 따라 결과가 달라지는 상황이 보였습니다.

WebArena 벤치마크에서는 OpenAI CUA 58.1% vs Anthropic SOTA 36.2%로 OpenAI가 크게 앞섭니다. WebVoyager에서는 두 SOTA가 모두 87.0%로 동률입니다. (출처: openai.com/ko-KR/index/new-tools-for-building-agents/) 어떤 벤치마크를 기준으로 삼느냐에 따라 “더 좋은” 에이전트가 달라집니다.

실무에서 중요한 건 특정 벤치마크 순위보다 실제 워크플로 조건입니다. UI 자동화 비중이 높은지, 파일 처리가 중심인지, 외부 API 호출이 많은지에 따라 선택이 달라집니다.

▲ 목차로 돌아가기

Skills가 해결하는 것과 해결하지 못하는 것

Skills는 재사용 가능한 작업 절차를 SKILL.md와 지원 파일로 묶어 API에 올리는 구조입니다. 매번 프롬프트에 같은 절차를 반복해서 쓸 필요 없이, skill_reference만 넘기면 됩니다.

Skills가 해결하는 것은 절차의 재사용성입니다. “어떤 순서로 움직여야 하는지”, “어떤 산출물을 만들어야 하는지”를 skill 번들에 고정해두면 모델이 매번 맥락을 새로 파악할 필요가 줄어듭니다.

Skills가 해결하지 못하는 것은 실제 실행입니다. 이 부분이 가장 많이 오해됩니다. skill 번들을 붙였다고 해서 브라우저가 자동으로 열리거나 UI가 조작되지 않습니다. 브라우저 제어가 필요하면 computer tool이나 별도의 Playwright 하네스가 따로 필요합니다. 실제 실험에서도 APIConnectionError, 브라우저 세션 EPERM 같은 문제가 먼저 나왔습니다. skill 문법보다 운영 경계에서 blocker가 나온다는 게 실제 경험의 공통 패턴입니다.

Skills 쓰기 전에 확인할 것들

  • 브라우저 제어가 필요한가? → computer tool 또는 Playwright 하네스 별도 설계
  • 외부 네트워크가 필요한가? → 관리자 허용 목록 먼저 확인
  • ZDR이 켜져 있는가? → hosted shell 사용 불가, local shell로 전환
  • 컨테이너 활성 시간이 20분을 넘는가? → 3월 31일 이후 추가 과금 발생

이 부분 아쉬웠습니다. “Skills를 붙이면 에이전트가 알아서 한다”는 기대가 생기기 쉬운 네이밍인데, 실제로는 “반복 절차를 정의해두는 설정 파일”에 가깝습니다. 설계 전에 이 차이를 잡아두면 시행착오가 줄어듭니다.

▲ 목차로 돌아가기

Q&A 5가지

Q1. Responses API 컴퓨터 환경은 Chat Completions API에서도 쓸 수 있나요?
쓸 수 없습니다. 셸 도구는 Responses API 전용입니다. Chat Completions API에서는 지원하지 않는다고 공식 가이드에 나와 있습니다. (출처: platform.openai.com/docs/guides/tools-shell)
Q2. hosted shell 컨테이너에서 만든 파일은 어디서 내려받나요?
/mnt/data 경로가 기본 작업 디렉터리이자 다운로드 가능한 아티팩트 저장 경로입니다. 컨테이너 및 파일 API로 접근할 수 있습니다. 단, 컨테이너가 비활성 후 20분이 지나면 자동 만료되며 파일 복구가 불가합니다.
Q3. 3월 31일 이전에 만든 컨테이너는 어떻게 되나요?
3월 31일 이후부터 모든 컨테이너 사용이 20분 단위 과금으로 전환됩니다. OpenAI가 3월 31일 이전 생성 컨테이너에 예외 조건을 별도로 공개하지 않았습니다. 현재 기준일 이후 사용분은 새로운 과금 체계가 적용된다고 보는 게 안전합니다.
Q4. gpt-5.4 말고 다른 모델로도 셸 도구를 쓸 수 있나요?
복잡한 추론/코딩 워크플로에는 gpt-5.4가 권장됩니다. 공식 발표문에서는 GPT-5.2 이상 계열 학습 모델이 셸 명령 제안 기반으로 동작한다고 밝혔습니다. 구체적인 모델 호환 목록은 OpenAI 모델 가이드를 직접 확인해야 합니다.
Q5. 호스팅 컨테이너에서 sudo를 쓸 수 있나요?
쓸 수 없습니다. 공식 셸 가이드에 “Hosted shell commands don’t run with sudo”라고 명시돼 있습니다. (출처: platform.openai.com/docs/guides/tools-shell) 루트 권한이 필요한 작업은 설계 단계에서 제외해야 합니다.

▲ 목차로 돌아가기

마치며

Responses API 컴퓨터 환경은 에이전트 개발의 진입 문턱을 낮춘 건 맞습니다. 실행 하네스를 직접 짜야 했던 부분을 OpenAI 플랫폼이 대신해주고, Skills로 반복 절차를 묶어두면 설계가 훨씬 가벼워집니다.

다만 “AI가 알아서 다 한다”는 기대로 접근하면 세 군데에서 막힙니다. 모델이 명령을 제안할 뿐 실행은 플랫폼이나 개발자 몫이라는 구조, 3월 31일부터 시작되는 컨테이너 과금, 그리고 ZDR 환경에서는 hosted shell 자체가 닫힌다는 점입니다.

생각보다 간단하게 쓸 수 있는 부분도 있고, 생각보다 복잡한 부분도 있습니다. 공식 문서를 한 번 직접 보고 시작하는 게 결국 시간을 아끼는 방법입니다.

▲ 목차로 돌아가기

본 포스팅 참고 자료

  1. OpenAI 공식 발표: 모델에서 에이전트까지 — Responses API에 컴퓨터 환경 제공 (2026.03.11)
    https://openai.com/ko-KR/index/equip-responses-api-computer-environment/
  2. OpenAI 공식 가격 페이지 (컨테이너 비용, 3.31 전환 기준)
    https://openai.com/ko-KR/api/pricing/
  3. OpenAI 공식 셸 가이드 (ZDR 제약, sudo 불가, 네트워크 정책)
    https://platform.openai.com/docs/guides/tools-shell
  4. OpenAI 에이전트 구축 도구 발표 (OSWorld/WebArena 벤치마크 수치)
    https://openai.com/ko-KR/index/new-tools-for-building-agents/
  5. Computer Use 독립 리더보드
    https://awesomeagents.ai/leaderboards/computer-use-leaderboard/

본 포스팅은 2026년 3월 29일 기준으로 작성됐습니다. OpenAI Responses API의 기능, 가격, 정책은 업데이트로 변경될 수 있습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있으니 공식 문서에서 최신 내용을 직접 확인하세요.

댓글 남기기


최신 글


아이테크 어른경제에서 더 알아보기

지금 구독하여 계속 읽고 전체 아카이브에 액세스하세요.

계속 읽기