OpenAI API 키 만료, 서비스 중단 없이 교체하는 법

OpenAI가 2026년 9월 10일 프로젝트 API 키에 만료일 설정 기능을 추가했습니다. 이제 OpenAI API 키 교체는 일정에 맞춰 수행해야 하는 프로덕션 유지보수 업무입니다. 사람의 개입 없이 돌아가는 에이전트라면 키가 만료되기 전에 담당자와 교체 작업 시간, 검증 절차부터 정해 두어야 합니다.

OpenAI API 키 만료는 자동 로테이션이 아니라 마감일입니다

API 키는 애플리케이션이 OpenAI API 사용 권한을 증명할 때 보내는 비밀 값입니다. 많은 팀이 키 하나를 시크릿 관리자에 넣고 예약 작업이 이를 사용하도록 설정한 뒤, 문제가 생길 때까지 그대로 두곤 합니다.

이제 OpenAI에서는 프로젝트 API 키를 만들 때 만료일을 지정할 수 있습니다. 관리자는 조직 또는 프로젝트 단위의 Platform 설정에서 키의 최대 수명도 정할 수 있습니다. 이 정책이 적용되면 새로 만드는 키의 만료일은 허용된 수명 안에 있어야 합니다.

각 설정이 맡는 역할은 다음과 같이 다릅니다.

상위 정책이 우선한다는 점이 중요합니다. 프로젝트 설정으로 조직 정책보다 키 수명을 길게 만들 수 없으며, 반드시 조직이 정한 범위 안에서 설정해야 합니다.

하지만 이것이 자동 API 키 로테이션을 뜻하지는 않습니다. OpenAI의 프로덕션 운영 가이드는 만료 전에 대체 키를 만들고, 애플리케이션에 반영해 정상 작동을 확인한 다음에야 기존 키를 폐기하라고 안내합니다. 이 모든 인계 과정은 여전히 팀이 직접 책임져야 합니다.

달라지는 것은 요금이 아니라 유지보수 예산입니다

이 기능이 토큰 가격을 바꾸는 것은 아닙니다. 프로젝트 키로 인증하는 모든 예약 작업에 필요한 인력과 중단 비용의 계산법이 달라집니다.

간단한 계획 모델로 살펴보겠습니다. 아래 수치는 OpenAI의 제한이 아니라 업무량을 계산하기 위한 가정입니다.

한 프로젝트의 에이전트가 15분마다 실행돼 하루 96회 작업한다고 가정해 보겠습니다. 계획된 키 교체에는 운영자 시간 30분이 듭니다. 팀이 분기마다 교체하고 운영자의 총인건비를 시간당 $75로 잡는다면, 교체 한 번에 $37.50, 프로젝트 하나당 연간 $150가 필요합니다. 프로젝트가 열 개라면 연간 유지보수 항목만 $1,500로 늘어납니다.

이번에는 키 만료를 놓쳐 서비스가 4시간 멈췄다고 가정해 보겠습니다. 이 시간 동안 예약된 작업은 16회 시작됩니다. 누락된 작업 하나를 확인하고 다시 실행하는 데 10분씩 걸린다면 복구에 총 160분, 즉 2시간 40분이 필요합니다. 같은 시간당 $75를 적용하면 인건비만 $200입니다. 고객 업무 지연, 보고서 누락, 매출 손실은 아직 포함하지 않은 금액입니다.

핵심은 여기에 있습니다. 만료일은 방치된 자격 증명이 유효하게 남아 있는 기간을 줄여 주지만, 숨어 있던 보안 위험을 반복되는 운영 업무로 바꿉니다. 따라서 API 키 관리 예산을 확보하고, 일정표에 책임자를 명시해야 합니다.

실제 고민이 통제되지 않는 API 지출이라면 키 만료는 맞는 수단이 아닙니다. 별도의 AI 에이전트 API 예산 통제 가이드에서 그 경계를 다룹니다. 예산 상한과 자격 증명 만료 모두 작업을 중단시킬 수 있지만, 해결하는 문제가 다르므로 복구 계획도 따로 세워야 합니다.

이 API 키 교체 절차가 필요한 사람

무인 SaaS 에이전트를 혼자 운영하는 창업자

고객 지원 요약, 문서 처리, 데이터 보강 작업을 운영한다면 혼자 일하더라도 자격 증명의 담당자를 지정해야 합니다. 해당 키를 쓰는 스케줄러와 배포 환경, 시크릿 항목을 기록합니다. 기존 키가 살아 있을 때 교체를 시작하고, 새 시크릿으로 실제 예약 작업 하나가 끝까지 완료되는지 확인해야 합니다.

이렇게 하면 서비스 연속성을 지킬 수 있습니다. 어제 처리됐어야 할 작업이 오지 않았다는 고객 연락으로 문제를 알게 되는 대신, 키 교체를 계획된 소규모 릴리스로 바꿀 수 있습니다.

고객 프로젝트를 맡은 에이전시 운영 책임자

에이전시는 고객 프로젝트마다 프로젝트명, 키 담당자, 배포된 작업, 만료일, 교체 상태, 검증 결과를 담은 기록을 만들 수 있습니다. 그러면 필요한 인력을 수치로 관리할 수 있고, 누구도 건드리려 하지 않는 공유 자격 증명 안에 고객 자동화 하나가 숨어 방치되는 일도 막을 수 있습니다.

결국 마진을 지키는 방법입니다. 키 교체 시간을 납품 계획에 반영할 수 있고, 기존 시크릿이 사라지기 전에 어떤 고객 작업을 점검해야 하는지 계정 책임자도 알 수 있습니다.

조직 정책을 정하는 플랫폼 팀

백엔드 또는 플랫폼 팀은 먼저 조직 차원의 최대 수명을 결정하고, 각 프로젝트가 그 범위 안에서 제한을 적용하도록 해야 합니다. 업무 특성이나 위험도에 따라 프로젝트 정책을 더 짧게 설정할 수는 있지만, 조직 상한을 피하려고 더 긴 수명을 적용할 수는 없습니다.

그 결과 일관된 거버넌스를 갖출 수 있습니다. 수명 정책을 공개하는 팀은 같은 시점에 키 교체 절차도 함께 안내해야 합니다. 인계 방법 없는 마감일은 날짜만 정해진 미래의 장애일 뿐입니다.

오래된 자격 증명을 정리하는 보안 관리자

보안 관리자는 새 키 정책과 기존 키 목록을 별도의 두 흐름으로 다뤄야 합니다. 새로 생성되는 키에는 최대 수명을 적용하고, 기존 프로젝트 자격 증명은 따로 찾아 담당자를 지정합니다. 공개된 정책 범위만으로는 오래된 키가 저절로 만료된다고 볼 수 없습니다.

이렇게 해야 실제 상태에 맞는 정책 도입이 가능합니다. 앞으로 생성될 자격 증명은 즉시 개선하면서도, 향후 적용되는 정책을 이미 끝난 정리 작업으로 오해하지 않게 됩니다.

서비스 공백 없이 API 키 하나를 교체하는 순서

구체적인 배포 메뉴는 호스팅 환경과 시크릿 관리자마다 다르지만, 안전한 순서는 같습니다.

1. 1

   정책과 담당자를 확인합니다

   대체 키를 만들기 전에 조직의 최대 수명과 프로젝트의 최대 수명을 확인합니다. 현재 키가 속한 프로젝트, 키를 사용하는 모든 작업, 담당자, 교체 작업을 시작할 시점을 기록합니다.

2. 2

   대체 키를 미리 만듭니다

   기존 키가 아직 유효할 때 새 프로젝트 API 키를 생성합니다. 현재 정책을 준수하는 만료일을 지정하고, 소스 코드나 공개 저장소에는 절대 넣지 않습니다.

3. 3

   시크릿 저장소를 통해 배포합니다

   애플리케이션이 이미 사용하는 환경 변수 또는 시크릿 관리 경로에 대체 키를 새 버전으로 저장합니다. 먼저 통제할 수 있는 작업자 하나나 테스트 경로에만 적용합니다. 테스트와 실제 운영 환경을 더 강하게 분리해야 한다면 OpenAI에서 스테이징 프로젝트와 프로덕션 프로젝트를 따로 운영할 수도 있습니다.

4. 4

   배포된 작업을 검증합니다

   애플리케이션의 실제 인증 경로를 통해 실행합니다. 요청 결과와 작업 출력, 큐, 작업자 로그를 모두 확인합니다. 키 추적을 활성화했다면 OpenAI의 Usage 페이지도 보조 신호로 활용할 수 있지만, 대시보드 확인만으로 실제 비즈니스 결과 검증을 대신할 수는 없습니다.

5. 5

   전체에 반영한 뒤 기존 키를 폐기합니다

   기존 자격 증명을 사용하던 모든 배포 환경, 스케줄러, CI 시크릿, 장기 실행 작업자를 새 키로 바꿉니다. 새 키가 해당 작업 전부에서 정상 작동하는지 확인하고 나서야 기존 키를 폐기합니다.

만료 기능만으로 해결되지 않는 API 키 관리 업무

OpenAI의 공개 문서에는 모든 계정에 적용되는 기본 수명이나 하나의 고정된 최대 기간이 명시돼 있지 않습니다. 유예 기간, 자동 교체 방식, 만료 알림 일정에 관한 설명도 없습니다. 정책은 계정 설정에서 결정되며, 알림과 배포는 그 주변의 운영 체계가 책임져야 합니다.

또한 이 설정만으로는 시크릿이 어디에 복사됐는지 알 수 없습니다. 개발자가 키를 CI 시스템, 서버리스 환경, 로컬 컴퓨터, 백업 스크립트에 붙여 넣은 사실까지 파악해 주지는 않습니다. 대부분의 팀이 실제보다 가볍게 보는 일이 바로 이 목록 작성입니다.

검증 역시 어려운 부분입니다. 테스트 요청이 성공하면 대체 키 자체가 유효하다는 사실은 입증됩니다. 하지만 모든 예약 작업자가 새 키를 받았다는 뜻은 아닙니다. 그래서 교체 기록에 작업 목록을 넣어야 하며, 목록을 전부 확인할 때까지 기존 키를 유효하게 유지해야 합니다.

이번 주에 해야 할 일

예약형 에이전트, 배치 작업자, 고객 자동화, 백엔드 서비스가 프로젝트 API 키를 사용하고 있고 조직에서 최대 수명 정책을 적용할 계획이라면 지금 움직여야 합니다. 첫 만료일이 생기기 전에 키 로테이션 업무를 운영 예산에 반영합니다.

최대 수명 정책이 켜져 있지 않고 현재 프로젝트 키에도 만료일이 없다면 전면 도입은 미뤄도 됩니다. 그래도 지금 자격 증명과 담당자 목록은 만들어 두어야 합니다. 새 기능은 정책이 향할 방향을 분명히 보여 주며, OpenAI도 이미 정기적인 교체를 권고하고 있습니다.

기존 키에 만료일이 소급 적용된다는 설명은 없으므로 오래된 모든 배포 환경에 갑자기 9월의 마감일이 생겼다고 주장할 근거도 없습니다. 그렇다고 기존 키를 외면해도 된다는 뜻은 아닙니다. 새 정책이 과거의 문제까지 정리해 줄 것이라 믿지 말고 별도로 점검해야 한다는 의미입니다.

월요일에는 프로덕션 프로젝트 하나를 고릅니다. 자격 증명의 담당자를 지정하고, 기존 키가 작동할 때 대체 키를 배포한 뒤, 새 키로 모든 작업이 수행되는지 확인하고, 마지막으로 기존 키를 폐기합니다. 이 네 단계의 인계가 바로 API 키 교체 계획입니다.

이와 같은 실무 중심의 운영 정보를 더 받아보려면 뉴스레터를 구독하세요.