요약: OpenAI는 2026년 6월 2일부터 eligible container session 과금을 기존 20분 세션 단위에서 분 단위 과금과 5분 최소 과금으로 바꿨습니다. 짧은 코드 실행, 데이터 변환, 테스트 실행을 자주 쓰는 팀이라면 에이전트 워크로드 비용 계산 방식이 달라집니다. 이 글은 컨테이너 세션을 어떻게 묶고, 언제 재사용하고, 어떤 지표로 비용을 봐야 하는지 정리합니다.
AI 에이전트가 코드를 실행하는 기능은 점점 일반적인 제품 구성요소가 되고 있습니다. 사용자가 CSV를 올리면 분석 코드를 실행하고, 데이터 품질을 검사하고, 그래프를 만들고, 테스트 코드를 돌립니다. 이런 작업은 하나하나가 길지 않습니다. 30초에서 3분 사이에 끝나는 경우가 많습니다.
OpenAI API changelog에 따르면 2026년 6월 2일부터 eligible container session은 기존처럼 전체 20분 세션 요금이 아니라 분 단위로 과금되며, 최소 5분 과금이 적용됩니다. 분당 요율 자체는 그대로지만 짧은 세션의 실효 비용이 낮아질 수 있다는 설명입니다.
이 변화는 “무조건 싸졌다”로 이해하면 안 됩니다. 5분 미만 작업은 여전히 5분으로 계산됩니다. 하지만 과거 20분 단위로 보던 비용 모델과 비교하면 짧은 실행을 많이 하는 서비스에는 의미 있는 차이가 생깁니다. 비용 최적화의 핵심도 바뀝니다. 예전에는 20분 안에 최대한 많이 몰아넣는 전략이 중요했다면, 이제는 5분 최소 과금과 세션 재사용의 균형을 봐야 합니다.
예를 들어 사용자 요청 하나가 평균 90초짜리 코드 실행을 필요로 한다고 가정해보겠습니다. 20분 단위 과금에서는 요청이 하나만 들어와도 세션 비용을 크게 부담해야 했습니다. 분 단위 과금과 5분 최소 과금에서는 같은 요청이 최소 5분으로 잡힙니다. 여전히 실제 실행 시간보다 길지만, 20분보다 훨씬 작습니다.
반대로 6분, 8분, 12분짜리 작업은 실제 사용 시간에 더 가깝게 계산됩니다. 따라서 워크로드를 세 가지로 나눠야 합니다.
비용 대시보드도 이 구간별로 봐야 합니다. 평균 실행 시간만 보면 착시가 생깁니다. 30초 작업 100개와 10분 작업 5개는 평균으로 섞으면 의미가 없습니다. 구간별 요청 수, 총 컨테이너 분, 최소 과금으로 버려지는 시간, 실패 재시도 시간을 따로 봐야 합니다.
5분 최소 과금이 있으면 짧은 작업을 같은 세션에서 묶는 전략이 여전히 유효합니다. 예를 들어 한 사용자가 파일 업로드 후 미리보기, 컬럼 추론, 간단한 통계, 차트 생성까지 연속으로 실행한다면 같은 컨테이너 세션을 재사용하는 편이 좋습니다. 초기화 비용도 줄고, 라이브러리 로딩과 임시 파일 재사용도 가능합니다.
하지만 무조건 오래 붙잡는 것은 좋지 않습니다. 세션을 재사용하려고 대기 시간을 길게 잡으면 리소스가 묶이고, 사용자 간 데이터 격리 문제가 생길 수 있습니다. 특히 멀티테넌트 서비스에서는 한 세션에 여러 사용자의 데이터를 섞지 않는 원칙이 중요합니다.
추천 기준은 사용자 단위 또는 작업 단위 재사용입니다. 같은 사용자, 같은 업로드 파일, 같은 분석 흐름 안에서는 짧게 재사용합니다. 다른 사용자나 다른 프로젝트로 넘어가면 새 세션을 쓰는 편이 안전합니다. 세션 TTL은 제품 흐름에 맞춰 3~10분 사이에서 시작하고 로그를 보며 조정합니다.
첫 번째 패턴은 사전 검증입니다. 컨테이너를 띄우기 전에 파일 크기, 확장자, 스키마, 필수 컬럼을 애플리케이션 레벨에서 확인합니다. 실행 환경을 열고 나서 “파일이 비어 있습니다”를 발견하면 최소 과금만 낭비합니다.
두 번째 패턴은 경량 작업 분리입니다. 단순한 JSON 변환, 정규식 검사, 문자열 정리는 컨테이너 코드 실행까지 갈 필요가 없습니다. 서버 함수나 애플리케이션 코드에서 처리하면 됩니다. 컨테이너는 라이브러리 실행, 샌드박스 격리, 파일 기반 계산이 필요할 때만 씁니다.
세 번째 패턴은 재시도 정책 제한입니다. 코드 실행 실패가 발생했을 때 무제한 재시도하면 비용이 빠르게 늘어납니다. 실패 유형을 나눠야 합니다. 문법 오류, 사용자 데이터 오류, 의존성 설치 실패, 시간 초과를 구분하고, 재시도 가능한 오류만 1회 재시도합니다.
네 번째 패턴은 결과 캐싱입니다. 같은 파일, 같은 파라미터, 같은 코드 버전이면 결과를 다시 쓸 수 있습니다. 데이터 분석 기능에서는 파일 해시와 작업 파라미터를 키로 캐시하면 반복 실행을 줄일 수 있습니다.
데이터 분석 SaaS라면 업로드 파일마다 세션을 만들고, 사용자가 같은 파일에서 여러 질문을 할 때만 재사용하는 방식이 적합합니다. 첫 질문에서 스키마 분석과 샘플 통계를 만들고, 후속 질문에서는 같은 세션의 중간 결과를 사용합니다. 사용자가 5분 이상 조용하면 세션을 닫습니다.
개발자 도구라면 테스트 실행과 코드 포맷팅을 분리합니다. 포맷팅이나 정적 검사처럼 가벼운 작업은 로컬 또는 서버 함수로 처리하고, 실제 테스트 실행이나 빌드 검증만 컨테이너로 보냅니다. 이렇게 해야 최소 과금 구간의 낭비를 줄일 수 있습니다.
교육 서비스라면 학생별 코드 실행 세션을 짧게 유지합니다. 같은 문제를 푸는 동안은 세션을 재사용하되, 문제를 바꾸면 새 세션을 시작합니다. 학생 코드가 무한 루프에 빠질 수 있으므로 시간 제한과 출력 크기 제한을 반드시 둬야 합니다.
과금 구조가 바뀌면 모니터링 지표도 바뀌어야 합니다. 단순 호출 수와 성공률만 보면 비용 원인을 알 수 없습니다. 최소한 다음 지표를 봐야 합니다.
이 지표를 작업 유형별로 나누면 무엇을 최적화해야 할지 보입니다. 예를 들어 5분 미만 작업이 많고 재사용률이 낮다면 세션 TTL과 작업 묶음을 조정해야 합니다. 10분 이상 작업이 많다면 코드 자체를 최적화하거나 데이터 샘플링을 도입해야 합니다.
OpenAI 컨테이너 세션 과금 변경은 짧은 코드 실행 워크로드를 운영하는 팀에 좋은 신호입니다. 하지만 비용 절감은 자동으로 오지 않습니다. 최소 5분 과금 구간을 이해하고, 세션 재사용 기준을 정하고, 실행 전 검증과 캐싱을 넣어야 효과가 납니다. 에이전트 코드 실행 기능은 모델 품질만큼이나 실행 환경의 비용 모델을 잘 설계해야 오래 버틸 수 있습니다.
