OpenAI Responses API
컨테이너 / Code Interpreter
OpenAI 컨테이너 요금, 오늘부터 이렇게 바뀝니다
오늘(2026년 3월 31일)부터 OpenAI Responses API의 컨테이너 요금 청구 방식이 바뀌었습니다. 단가 숫자는 그대로입니다. 그런데 청구 방식이 달라지면 실제로 내는 돈이 달라집니다. 특히 Code Interpreter나 Hosted Shell을 쓰는 분들은 오늘 반드시 확인해야 합니다.
바뀐 것은 단가가 아니라 ‘청구 단위’입니다
OpenAI 공식 가격 페이지를 직접 보면 이렇게 나와 있습니다. “현재: 컨테이너당 1GB $0.03 / 64GB $1.92. 2026년 3월 31일부터: 컨테이너당 20분 세션 기준 1GB $0.03 / 64GB $1.92.” (출처: openai.com/ko-KR/api/pricing/, 2026.03.31 기준)
숫자가 같으니 같은 거 아닐까요? 막상 비교해보면 다릅니다. 기존 방식은 컨테이너 1개를 생성하면 그 컨테이너 자체에 $0.03이 한 번 붙었습니다. 새 방식은 그 컨테이너가 활성 상태로 유지되는 동안 20분마다 $0.03씩 반복해서 청구됩니다. 컨테이너 하나를 2시간 동안 쓰면 기존엔 $0.03, 이제는 $0.18입니다.
OpenAI가 개발자들에게 보낸 공식 이메일(2026년 2월 11일)에는 변경 이유가 딱 이렇게 나옵니다. “컨테이너가 인터넷에서 라이브러리 설치, 복수 언어 코드 실행, 복잡한 에이전트 워크플로를 지원하는 등 더 정교한 작업을 할 수 있게 됐다. 이 확장된 기능을 반영해 요금 방식이 변경된다.” 성능 향상을 이유로 과금 단위를 바꾼 것입니다.
20분 세션이 정확히 무엇인지 공식 문서로 확인했습니다
’20분 세션’이라는 단어가 막연하게 느껴질 수 있습니다. 공식 개발자 문서에는 이렇게 나옵니다. “컨테이너는 마지막으로 사용된 지 20분이 지나면 만료됩니다(expires_after: last_active_at 기준 20분).” (출처: developers.openai.com/api/docs/guides/tools-code-interpreter, 2026.03.31 기준)
다시 말해, 새 방식에서 ‘세션’은 컨테이너가 마지막으로 활성화된 시점부터 20분입니다. 이 20분 안에 또 활동이 생기면 카운터가 리셋됩니다. 결국 컨테이너 활성 시간 전체를 20분 단위로 나눠서 청구하는 구조입니다.
💡 공식 문서와 실제 결제 데이터를 같이 놓고 보니 이런 차이가 보였습니다.
컨테이너 API 응답 객체 안에는 last_active_at 필드가 있습니다. 이 값이 갱신될 때마다 새 20분 세션이 시작됩니다. 그런데 이 값을 갱신하는 동작에는 코드 실행뿐 아니라 컨테이너 상태 조회, 파일 추가, 파일 삭제도 포함됩니다. 관리 목적으로 API를 한 번 호출하는 것만으로도 세션이 연장되는 셈입니다.
64GB 컨테이너를 켜두면 한 달에 얼마가 나오는지 계산해봤습니다
OpenAI 커뮤니티 포럼(2026.02 게시글)에서 한 개발자가 직접 계산한 결과가 있습니다. “$64.80/월이면 64GB 컨테이너를 상시 유지했을 때 나오는 비용이다.” 이 수치를 직접 검증해봤습니다.
📊 64GB 컨테이너 상시 운영 시 월간 비용 계산
| 항목 | 수치 |
|---|---|
| 20분 세션 / 시간 | 3회 |
| 세션 / 일 | 72회 (3×24) |
| 세션 / 월 | 2,160회 (72×30) |
| 64GB 세션 단가 | $1.92 / 세션 |
| 월 총비용 | $4,147.20 |
(출처: openai.com/ko-KR/api/pricing/ 단가 기준, 직접 계산)
잠깐, 커뮤니티 글에서 “$64.80″이라고 했는데 계산이 다릅니다. 차이가 나는 이유는 64GB가 아니라 1GB 컨테이너 기준으로 계산했기 때문입니다. 1GB 세션 단가($0.03) × 2,160세션 = $64.80입니다. 이 수치는 1GB 컨테이너를 한 달 내내 쉬지 않고 돌렸을 때 나오는 수치입니다. 한 달을 30일로 계산하면 1GB만 써도 월 $64.80이 청구됩니다. 기존 방식에서는 컨테이너 하나를 만들면 $0.03이었습니다. 약 2,160배 차이입니다.
물론 컨테이너를 상시 켜두는 케이스는 드뭅니다. 그러나 세션이 끊기지 않도록 주기적으로 헬스체크를 하는 코드, 파일 관리 자동화, 에이전트 루프를 돌리는 환경에서는 의도치 않게 컨테이너가 계속 활성 상태로 유지될 수 있습니다.
파일 조회만 해도 카운터가 다시 시작되는 구조입니다
공식 개발자 문서에는 이런 문장이 있습니다. “컨테이너 조회, 파일 추가, 파일 삭제 등 모든 컨테이너 작업은 자동으로 last_active_at 시간을 갱신합니다.” (출처: developers.openai.com/api/docs/guides/tools-code-interpreter, 2026.03.31 기준)
즉, GET /v1/containers/{container_id}로 상태만 확인해도 20분 카운터가 초기화됩니다. 컨테이너가 처리 중인지 확인하기 위해 폴링(polling)하는 코드가 있다면, 폴링 자체가 컨테이너를 살아있게 유지하면서 비용을 계속 쌓는 구조가 됩니다.
💡 공식 발표문과 실제 커뮤니티 이슈를 같이 놓고 보니 이런 구조가 보였습니다.
OpenAI 커뮤니티의 한 개발자는 2026년 2월에 이렇게 썼습니다. “컨테이너를 한 번만 건드려도 last_active_at가 갱신돼서 20분이 추가된다. 20분을 넘기면 자동으로 새 세션이 시작된다. 30일 내내 활성 상태면 요금이 기존 대비 3배까지 올라간다.” (출처: community.openai.com/t/responses-api-container-duration-metrics/1374010, 2026.02.11 게시글)
실제로 한 개발자는 같은 게시글에서 “컨테이너 엔드포인트 테스트만 했을 뿐인데 $50가 청구됐다”고 직접 밝혔습니다. 개발 환경에서 테스트 코드를 작성할 때 흔히 쓰는 폴링 패턴이 그대로 비용 폭탄으로 이어진 케이스입니다.
Auto 모드가 오히려 비용을 늘리는 상황이 있습니다
Code Interpreter를 쓸 때 컨테이너를 직접 만들지 않고 "container": {"type": "auto"}를 설정하면 OpenAI가 알아서 컨테이너를 만들거나 기존 활성 컨테이너를 재사용합니다. 편리해 보이지만 이게 함정입니다.
공식 문서에는 “Auto 모드는 새 컨테이너를 생성하거나, 이전 code_interpreter_call 항목에서 사용된 활성 컨테이너를 재사용합니다”라고 나옵니다. (출처: developers.openai.com/api/docs/guides/tools-code-interpreter) 재사용이 발생하는 순간 그 컨테이너의 last_active_at이 갱신되고, 이미 진행 중이던 세션에 새 20분이 추가됩니다.
짧은 요청을 연속으로 10번 보내는 상황을 예로 들어봅니다. 각 요청 간격이 15분이고, Auto 모드라면 1~10번 요청이 모두 같은 컨테이너를 재사용합니다. 컨테이너는 첫 요청부터 마지막 요청 후 20분까지 활성 상태를 유지합니다. 요청 10개 × 15분 간격 + 20분 여유 = 총 활성 시간 약 170분 → 약 9개 세션 청구(20분 단위로 절상). 1GB 기준이면 $0.27입니다. 명시적으로 컨테이너를 만들고 쓰고 바로 삭제하면 10개 × $0.03 = $0.30인데 차이가 없거나 오히려 더 비쌀 수도 있습니다.
솔직히 말하면 이 부분은 사용 패턴에 따라 Auto 모드가 유리한 경우도 있습니다. 간격이 짧고 요청이 많을수록 컨테이너 재생성 오버헤드를 줄이는 Auto 모드가 효율적이고, 요청이 드문드문 있을수록 명시적으로 컨테이너를 제어하는 게 낫습니다.
비용 폭증을 막는 3가지 실전 대응법
쓰고 나면 바로 삭제하는 습관이 필요합니다
작업이 끝나면 DELETE /v1/containers/{id}를 명시적으로 호출하세요. 컨테이너를 만료 타이머에 맡기면 최대 20분을 더 기다려야 합니다. 처리 후 즉시 삭제하면 불필요한 세션 1개를 줄일 수 있습니다. 단기 작업이라면 세션 1개 절감이 전체 비용의 절반 이상이 될 수 있습니다.
컨테이너 상태를 주기적으로 조회하는 코드를 점검하세요
GET /v1/containers/{id}를 자동으로 호출하는 스크립트나 헬스체크 로직이 있다면 오늘 당장 확인해야 합니다. 조회 자체가 last_active_at을 갱신합니다. 대안은 Background 모드를 쓰거나 작업 완료 이벤트를 웹훅으로 받는 구조로 바꾸는 것입니다.
메모리 크기는 작업에 딱 맞게만 잡는 게 맞습니다
기본값인 1GB로 충분한 작업에 4GB나 16GB 컨테이너를 설정하면 단가 자체가 4배, 16배로 늘어납니다. 공식 문서에 나온 대로 memory_limit을 명시하지 않으면 자동으로 1GB 기본값이 적용됩니다. (출처: developers.openai.com/api/docs/guides/tools-code-interpreter) 코드 분석, 간단한 계산, 소규모 CSV 처리 정도라면 1GB로 충분합니다.
자주 묻는 질문
마치며
솔직히 말하면 이번 변경이 불합리하다고 느끼는 개발자들의 반응은 충분히 이해됩니다. 단가는 그대로라고 했지만 실제로는 청구 빈도가 달라지는 구조이기 때문입니다. OpenAI는 이유를 “컨테이너 기능이 강화됐기 때문”이라고 밝혔는데, 커뮤니티 반응은 냉소적입니다.
다만 짧게 쓰고 바로 삭제하는 패턴으로 운영한다면 기존 대비 비용이 크게 달라지지 않습니다. 이 변경에서 가장 타격을 받는 것은 컨테이너를 장기 세션으로 유지하거나, 자동화된 파이프라인에서 컨테이너 상태를 주기적으로 확인하는 구조입니다. 지금 사용 중인 코드를 한 번 점검해볼 타이밍입니다.
이 글을 쓰는 시점에 OpenAI가 컨테이너 세션 지속 시간을 측정하는 별도 API나 대시보드 기능을 추가할 계획인지는 공개되지 않았습니다. 비용 가시성을 높이는 업데이트가 나온다면 당연히 추적할 가치가 있는 변화입니다.
📎 본 포스팅 참고 자료
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 본문의 모든 수치는 2026년 3월 31일 기준 OpenAI 공식 자료를 근거로 작성됐습니다. API 요금 및 과금 방식은 OpenAI 정책에 따라 예고 없이 변경될 수 있으므로 중요한 의사결정 전 반드시 공식 페이지를 직접 확인하세요.
댓글 남기기