OpenAI API 지원 종료는 모델·기능별 종료일과 대체안을 확인하고, 실제 호출 없이 의존성을 찾아 마이그레이션 순서를 정해야 합니다.
2026년 10월 6일 기준으로 OpenAI API 공식 deprecations 문서에는 2027년에 종료될 모델과 기능이 함께 올라와 있습니다. 이 글은 “새 모델로 바꾸면 된다”는 식의 단순한 교체 안내가 아니라, 어떤 문자열과 기능 플래그를 어디서 찾고, 무엇을 로컬에서 확인했으며, 무엇은 실제 계정·API 환경 없이는 확인할 수 없는지를 나누는 점검표입니다. 공식 문서의 일정은 운영 판단의 출발점이고, 로컬 실습은 그 일정과 설정 문자열을 대조하는 안전한 보조 증거입니다.
먼저 읽어야 할 종료 일정의 구조
OpenAI는 deprecation과 shutdown을 구분합니다. deprecation은 해당 모델이나 엔드포인트가 더 이상 장기 방향이 아니라는 공지가 시작되는 시점이고, shutdown date가 되면 API에서 접근할 수 없게 된다고 설명합니다. 따라서 “아직 응답이 온다”는 사실만으로 안전하다고 판단하면 안 됩니다. 사용 중인 모델 ID가 deprecation 표에 있는지, 실제 종료일이 언제인지, 권장 대체 모델이 무엇인지 세 칸으로 옮겨 적어야 합니다.
이번 점검에서 가장 가까운 일정은 2026년 10월 1일 공지된 모델 묶음입니다. gpt-5.3-codex, gpt-5.4-nano, gpt-5.1은 2027년 4월 1일 API에서 제거될 예정이며 각각 gpt-6-sol, gpt-6-luna, gpt-6-sol이 권장 대체안으로 표시됩니다. 이 날짜는 “그날까지 교체를 시작하라”가 아니라, 그날 이후 기존 ID가 접근되지 않을 수 있으므로 그 전에 호환성 검증과 배포를 끝내야 한다는 운영 경계입니다.
같은 페이지에는 텍스트 음성 모델의 2027년 1월 6일 종료 일정도 별도로 적혀 있습니다. tts-1, tts-1-hd, 특정 날짜가 붙은 gpt-4o-mini-tts 계열은 gpt-realtime-2.1-mini로 옮기라는 안내가 있습니다. 모델 종류가 다르면 입력·출력 형식, 지연시간, 비용, SDK 호출 방식이 달라질 수 있으므로 한 번의 문자열 치환으로 마이그레이션이 끝난다고 가정하지 않는 것이 안전합니다.
모델·기능·엔드포인트를 분리해 목록화하기
첫 번째 실무 단계는 저장소 전체에서 모델 ID만 찾는 것이 아니라 세 종류의 의존성을 따로 세는 것입니다. 모델 의존성은 환경 변수, YAML·JSON 설정, SDK 호출, 테스트 픽스처에 남습니다. 기능 의존성은 Evals나 Agent Builder처럼 모델명이 아닌 제품·대시보드·파이프라인 이름으로 남을 수 있습니다. 엔드포인트 의존성은 URL, SDK 메서드, 배치 작업, 웹훅과 함께 나타나므로 별도 목록이 필요합니다.
예를 들어 model: gpt-5.3-codex 한 줄만 바꿔도 충분한지 먼저 묻습니다. 해당 모델이 Responses API와 Chat Completions 중 어디에서 사용되는지, 구조화 출력·도구 호출·reasoning 설정을 사용하는지, 결과를 파싱하는 코드가 있는지 확인해야 합니다. 대체 모델의 이름이 공식 표에 있다고 해서 응답 스키마와 허용 파라미터가 자동으로 같다는 의미는 아닙니다. 이 차이를 “문서상 대체안”과 “우리 앱에서 호환됨” 사이에 두어야 합니다.
기능도 같은 방식으로 분리합니다. OpenAI 문서는 Evals가 2026년 10월 31일부터 읽기 전용으로 전환되고 11월 30일에 대시보드와 API가 종료될 예정이라고 안내합니다. Agent Builder는 2026년 11월 30일 종료 예정이며 Agents SDK나 ChatGPT Workspace Agents로 옮기는 경로가 제시됩니다. 따라서 저장소 검색에서 evals, grader, agent builder, 워크플로 ID, 대시보드 URL을 각각 찾아 소유자와 대체 경로를 붙여야 합니다.
직접 실행 결과: 계정 없이 만든 로컬 점검
이번 실행에서는 API 키를 넣거나 OpenAI 엔드포인트를 호출하지 않았습니다. 대신 공개 문서에서 확인한 날짜·대체안과 동일한 형태의 무해한 설정 픽스처를 브라우저 안에 두고, 로컬 JavaScript가 모델 1개와 기능 플래그 2개를 발견해 점검 결과로 정리하는지 확인했습니다. 이 실습이 증명하는 것은 “지원 종료 문서의 필드를 코드 검색 결과와 연결하는 로컬 분기”뿐이며, 실제 모델 접근성이나 계정별 권한을 증명하지 않습니다.
검증일은 2026년 10월 6일, 환경은 Windows에서 실행한 독립 Chromium 1200×675입니다. 시작 화면에는 gpt-5.3-codex, evals: enabled, agent_builder: enabled라는 예제 설정과 실행 버튼이 보였습니다. 버튼을 클릭한 뒤 결과 화면에는 “3개 의존성 발견”, 모델의 2027-04-01 종료일과 대체 모델, Evals·Agent Builder의 2026-11-30 일정을 표시했습니다. 캡처 2장과 같은 세션의 시작→결과 WebM을 저장하고 재생 가능 여부와 SHA-256을 확인했습니다.


저장소에서 찾을 검색어와 안전한 분류법
코드 검색은 실제 비밀값을 출력하지 않는 읽기 전용 검색으로 시작합니다. 모델 ID는 정확한 문자열과 환경 변수 이름을 함께 검색하고, 기능은 대소문자·공백·대시 변형을 포함합니다. 결과를 바로 수정하지 말고 파일, 라인, 실행 경로, 소유 팀, 테스트 유무를 표로 기록해야 합니다.
rg -n "gpt-5\.3-codex|gpt-5\.4-nano|gpt-5\.1|tts-1|gpt-4o-mini-tts" .
rg -n "evals|grader|agent[ _-]?builder|workflow[ _-]?id" src config scripts tests
rg -n "responses|chat/completions|audio|realtime|model\s*[:=]" src config .github
첫 번째 그룹은 지원 종료 표에 등장하는 모델 문자열을 찾기 위한 후보 검색입니다. 두 번째 그룹은 제품·기능 의존성을 놓치지 않기 위한 검색입니다. 세 번째 그룹은 모델 교체가 어느 호출 경로에 영향을 주는지 확인하는 교차 검색입니다. 검색 결과에 실제 API 키나 토큰이 포함되어 있다면 값을 복사하거나 화면에 남기지 않고, 파일 위치와 마스킹된 식별자만 기록합니다.
정적 검색은 누락과 오탐을 모두 가집니다. 문자열을 동적으로 조립하거나 별도 비밀 저장소에서 주입하면 검색에 걸리지 않을 수 있고, 문서 예제나 테스트 픽스처가 실제 운영 의존성처럼 보일 수도 있습니다. 따라서 검색 결과는 소유자 인터뷰나 배포 설정 확인으로 분류해야 하며, 로컬 데모의 “3개 발견”을 저장소 전체 감사 완료로 표현하면 안 됩니다.
대체 모델을 선택할 때 남겨야 할 회귀 질문
권장 대체 모델을 적은 다음에는 최소한 네 층의 회귀 질문을 남깁니다. 입력층에서는 프롬프트, 파일, 이미지, 오디오 입력의 허용 범위가 같은지 확인합니다. 출력층에서는 JSON 구조, 도구 호출 인자, 스트리밍 이벤트, 종료 사유가 기존 파서와 맞는지 확인합니다. 운영층에서는 비용·지연시간·rate limit·지역 가용성을 비교합니다. 안전층에서는 모델이 수행할 수 있는 도구와 승인 경계를 재검토합니다.
특히 gpt-5.3-codex에서 다른 계열로 옮기는 경우 “응답이 한 번 성공했다”는 단일 샘플보다 실제 업무의 대표 케이스를 고정된 입력으로 반복하는 편이 낫습니다. 테스트는 비밀값과 개인정보를 제거한 재현용 fixture로 만들고, 결과에는 원문 대신 스키마 검증 여부·도구 호출 개수·오류 분류·처리 시간처럼 필요한 메타데이터만 남깁니다. 새 대체 모델의 동작이 더 좋다는 홍보 문장보다, 기존 기능이 깨지지 않았는지 확인하는 실패 조건이 더 중요합니다.
음성 모델이나 기능 제품은 더 조심해야 합니다. 텍스트 모델의 회귀 테스트를 음성·에이전트 기능의 가용성 증거로 바꿀 수 없습니다. 실제 계정 권한과 조직 플랜이 필요한 기능은 승인된 테스트 환경에서 별도 확인해야 하며, 이번 로컬 실습처럼 API 호출 없이 준비한 결과는 그 경계를 본문에 명시해야 합니다.
일정 관리표: 발견·검증·배포를 나누기
| 단계 | 확인할 것 | 완료 증거 |
|---|---|---|
| 발견 | 모델 ID·기능명·엔드포인트 위치 | 파일·라인·소유자 목록 |
| 해석 | shutdown date와 권장 대체안 | 공식 문서 URL·검증일 |
| 호환성 | 입력·출력·도구·비용·지연 회귀 | 비밀값 없는 테스트 로그 |
| 배포 | 단계적 롤아웃·되돌리기·모니터링 | 승인 기록·릴리스 링크 |
이 표에서 공식 문서의 종료일과 우리 팀의 내부 완료일을 분리하는 것이 핵심입니다. 예를 들어 2027년 4월 1일 종료라면 2027년 3월 31일까지 개발을 끝내겠다는 뜻이 아니라, 회귀·승인·점진 배포·롤백까지 그보다 훨씬 전에 완료할 여지를 두어야 한다는 뜻입니다. 조직마다 릴리스 주기와 심사 시간이 다르므로 내부 날짜는 팀이 정하고, 공식 날짜는 원문 그대로 보존합니다.
한계와 실패 조건
이번 실습은 실제 OpenAI 계정으로 모델을 호출하지 않았고 API 키, 조직 권한, 청구, rate limit, 응답 호환성을 확인하지 않았습니다. 또한 공개 문서에 있는 권장 대체 모델이 모든 계정에서 같은 시점에 사용 가능하다고 가정하지 않습니다. 공식 표의 날짜가 바뀌거나 새 공지가 추가될 수 있으므로 배포 전에는 원문을 다시 읽어야 합니다.
로컬 결과가 “검사 완료”여도 다음 조건이면 배포를 멈춥니다. 모델 ID가 문자열로 검색되지 않고 동적으로 생성되는 경우, 대체 모델의 응답 구조를 검증하지 못한 경우, Evals·Agent Builder 의존성의 실제 소유자가 불명확한 경우, 비용·권한·데이터 보존 정책을 확인하지 못한 경우, 또는 테스트가 실제 운영 비밀값을 요구하는 경우입니다. 일정이 임박했다는 이유로 이 조건을 생략하면 마이그레이션이 아니라 장애를 앞당기는 일이 됩니다.
배포 전 체크리스트
- deprecations 표의 모델·기능·엔드포인트를 각각 목록화했는가?
- 각 항목에 공식 shutdown date, 권장 대체안, 확인일을 붙였는가?
- 코드·설정·CI·대시보드에서 문자열과 기능 플래그를 읽기 전용 검색했는가?
- 대체 모델에 대해 입력·출력·도구 호출·비용·지연 회귀 테스트가 있는가?
- Evals와 Agent Builder의 종료일 및 대체 경로를 담당자와 일정에 연결했는가?
- 실제 계정 테스트가 필요한 항목과 계정 없이 가능한 로컬 검사를 구분했는가?
- 비밀값과 개인정보가 캡처·영상·로그·분석 도구에 남지 않는가?
- 단계적 배포와 롤백 조건을 공식 종료일보다 충분히 앞서 승인했는가?
마이그레이션의 첫 산출물은 새 모델을 호출한 성공 화면이 아니라, 어떤 의존성을 언제까지 어떤 근거로 바꿀지 설명하는 원장입니다. 이 사이트의 npm stage-only 토큰과 사람 승인 글도 외부 계약이 바뀔 때 토큰과 운영 승인 경계를 분리하는 같은 접근을 보여 줍니다.
공식 출처와 검증일
공식 사실은 2026년 10월 6일 OpenAI API 공식 deprecations와 changelog를 대조해 확인했습니다. deprecations 페이지는 모델과 기능의 종료 일정·권장 대체안을 설명하고, changelog는 예정된 deprecation이 해당 페이지에서 관리된다는 연결과 현재 API 변경 이력을 제공합니다. 본문과 로컬 데모는 공개 문서의 내용을 계정 실행 결과로 포장하지 않았습니다.