OpenAI API 키 거버넌스: 생성 규칙, 소유권, 만료와 무중단 로테이션

OpenAI API 키에 만료 규칙을 적용하고 싶지만, 새 정책 때문에 애플리케이션이 멈추거나 다음 로테이션에서 필요한 대체 키를 만들 수 없게 되는 상황은 피해야 합니다. 운영 서비스는 서비스 계정 키를 쓰고 개인 개발은 사용자 소유 키를 유지할지도 결정해야 합니다.

이 글은 바로 실행할 수 있는 순서를 제시합니다. 워크로드에 따라 소유 유형을 고르고, 팀이 실제로 로테이션할 수 있는 유효기간을 정한 뒤, 중첩 기간을 두고 기존 키를 교체합니다. 먼저 두 가지를 기억하세요. 새 생성 규칙은 기존 키를 바꾸지 않으며, 조직 제한은 프로젝트 설정보다 우선합니다.

먼저 결론: 새 제어는 앞으로 만들 키를 관리하며 기존 키는 자동 처리하지 않는다

9월 업데이트는 두 가지 제어로 이해하면 됩니다. 어떤 새 키 유형을 발급할 수 있는지, 그리고 새 프로젝트 키를 최대 얼마나 오래 유효하게 둘지를 정합니다.

날짜	OpenAI 업데이트	운영상 의미
2026년 9월 10일	프로젝트 API 키 생성 시 만료일을 설정할 수 있고, 관리자는 조직 또는 프로젝트 수준에서 최대 키 유효기간을 강제할 수 있음	새 키를 무기한 대신 만료형으로 운영할 수 있지만, 짧은 기간을 강제하기 전에 반복 가능한 로테이션 절차가 필요함
2026년 9월 15일	조직과 프로젝트가 새 키 생성을 service-account keys만, user-owned project keys만 허용하거나 모든 새 API 키 생성을 비활성화할 수 있음	운영 서비스, 개인 개발, 동결 프로젝트에 서로 다른 발급 규칙을 적용할 수 있음
2026년 9월 15일	조직 제한이 프로젝트 설정보다 우선함	프로젝트는 조직 정책보다 더 엄격할 수 있지만 더 느슨하게 만들 수 없음
2026년 9월 15일	기존 API 키는 새 생성 제어의 영향을 받지 않음	규칙을 켠다고 기존 키가 폐기되거나 레거시 이전이 자동 완료되지는 않음

두 가지 경계를 기억해야 합니다. “새 키 생성 비활성화”는 “현재 키 전체 폐기”와 같지 않습니다. 또 9월 10일의 최대 유효기간은 새로 생성되는 키에 대한 요구로 설명됩니다. 실제 프로젝트에서 확인하기 전에는 기존 키에 소급 만료일이 붙는다고 가정하지 마십시오.

세 가지를 나눠 결정하기: 누가 만들고, 얼마나 쓰며, 어떻게 폐기할까

이 세 가지는 따로 설계해야 합니다. Platform의 스위치 하나로 전체 키 수명주기를 관리할 수는 없습니다.

발급 정책은 서비스 계정 키, 사용자 소유 프로젝트 키, 또는 어떤 새 키도 허용하지 않을지를 정합니다.

만료 정책은 새 키가 반드시 만료되어야 하는지, 조직과 프로젝트가 허용하는 최대 기간이 얼마인지를 정합니다.

수명주기 실행은 누가 대체 키를 만들고, 어디에 저장하며, 애플리케이션에 어떻게 전달하고, 어떤 증거로 전환을 확인하고, 언제 이전 키를 폐기하고, 실패 시 어떻게 되돌릴지를 정합니다.

앞의 두 계층은 OpenAI Platform에서 제약할 수 있습니다. 세 번째는 여전히 시크릿 관리자, 배포 방식, 관찰 가능성, 책임 배정, 장애 대응 절차에 달려 있습니다. 최대 기간만 지정하고 로테이션 담당자와 충분한 작업 시간을 준비하지 않으면 보안 제어가 예정된 장애가 됩니다.

용도별 선택: 운영은 서비스 계정, 개인 개발은 사용자 소유 키

운영·공유 워크로드에는 service-account key, 로컬·단기 작업에는 user-owned project key를 우선하고, 새 발급 중지는 실제로 동결하거나 종료하는 프로젝트에만 적용하세요.

용도	일반적으로 적합한 유형	이유	관리할 위험
운영 서비스, 공유 백엔드, 정기 작업, 팀이 운영하는 Agent	service-account key	자격 증명이 특정 직원이 아니라 워크로드에 속하므로 인력 변경이 연속성에 미치는 영향을 줄이기 쉬움	하나의 서비스 계정을 많은 무관한 앱에서 공유하면 영향 범위가 커짐. 프로젝트 또는 워크로드별로 분리해야 함
로컬 개발, 단기 디버깅, 탐색용 스크립트	user-owned project key	소유자와 개인 책임이 분명하고, 퇴사 처리에 해당 사용자의 키를 포함할 수 있음	개인 키가 조용히 공유 운영 환경의 의존성이 되지 않도록 해야 함
보관, 종료 예정 또는 일시 동결 프로젝트	새 키 생성 비활성화	종료나 조사 중 자격 증명 수가 늘어나는 것을 막음	너무 일찍 동결하면 로테이션이나 복구에 필요한 대체 키도 만들 수 없음

판단에 유용한 질문은 특정 직원이 팀을 떠난 뒤에도 이 애플리케이션이 계속 실행되어야 하는가입니다. 그렇다면 운영 자격 증명은 일반적으로 그 직원의 개인 계정에 의존하지 않아야 합니다. 반대로 모든 개발자 노트북에 같은 서비스 계정 키를 배포하면 행위 귀속이 약해지고 시크릿 사본이 늘어납니다.

키 유형만으로 안전성이 정해지지는 않습니다. 실제 위험은 범위, 저장 위치, 접근 권한, 유효기간, 로테이션, 폐기 절차가 결정합니다. 수십 개 애플리케이션에 복사된 장기 서비스 계정 키도 큰 단일 노출 지점입니다.

조직 정책이 상한선: 프로젝트는 더 엄격하게만 설정할 수 있다

조직 제한은 모든 프로젝트의 상한선이므로, 넓게 적용하기 전에 다음 로테이션을 먼저 시험해야 합니다.

예를 들어 조직이 서비스 계정 키만 허용하면 개발 프로젝트가 자체 설정으로 사용자 소유 키를 다시 허용할 수 없습니다. 프로젝트는 조직이 허용한 범위 안에서 더 엄격하게 만들 수 있지만 완화할 수는 없습니다.

조직 수준 설정을 바꾸기 전에 다음 순서로 점검하십시오.

1. 모든 프로젝트를 나열하고 운영, 스테이징, 개발, 테스트, 임시, 보관, 종료 예정으로 분류합니다.
2. 현재 보유 유형만 보지 말고 각 프로젝트가 다음 로테이션에서 필요로 하는 키 유형을 기록합니다.
3. 모든 활성 워크로드의 대체 자격 증명을 정하고 계획한 조직 규칙이 그 생성을 허용하는지 확인합니다.
4. 위험이 낮은 프로젝트에서 생성, 배포, 검증, 폐기를 리허설합니다.
5. 정상 로테이션이 가능하다는 것을 입증한 뒤 조직 제한을 적용합니다.

기존 키가 계속 작동하므로 지나치게 엄격한 정책도 켠 당일에는 문제가 없어 보일 수 있습니다. 몇 주 뒤 만료가 다가왔을 때 올바른 대체 키를 만들 수 없다는 사실이 드러납니다. 현재 트래픽 성공 여부만 확인하지 말고 다음 로테이션을 시험하십시오.

모든 환경에 같은 기간을 쓰지 말고 실제 로테이션 시간부터 계산한다

최대 유효기간은 승인, 발급, 배포, 관찰, 롤백에 필요한 전체 시간보다 길어야 합니다.

프로젝트 유형마다 최소한 다음을 정의하십시오.

항목	답해야 할 질문
최대 유효기간 N	새 키가 생성부터 만료까지 최대로 존재할 수 있는 기간은 얼마인가?
로테이션 선행 시간 R	만료 얼마 전부터 교체를 시작해야 하는가?
주 담당자와 대체 담당자	누가 책임지고, 부재 시 누가 맡는가?
배포 방식	애플리케이션이 새 시크릿 버전을 읽을 수 있는가, 재시작/재배포가 필요한가?
검증 증거	어떤 요청, 로그, 오류, 사용량으로 새 키가 트래픽을 받는다고 증명할 것인가?
롤백 기간	전환 뒤 이전 키를 얼마나 유지할 것인가?
예외 절차	누가 얼마 동안 연장을 승인하며 어떤 보완 통제를 둘 것인가?

R은 전체 과정을 포함해야 합니다. 수동 복사, 시간대가 다른 승인, 대체 담당자 부재와 결합된 극단적으로 짧은 기간은 자동 알림과 연습된 runbook을 가진 조금 더 긴 기간보다 신뢰성이 낮습니다.

조직의 최대값을 공통 상한으로 사용하십시오. 위험이 높은 프로젝트는 더 짧은 프로젝트 제한을 둘 수 있지만 더 길게 할 수 없습니다. 운영, 개인 개발, 임시 테스트, 종료 예정 프로젝트는 책임자와 영향, 복구 속도가 다르므로 같은 숫자를 기계적으로 적용할 필요는 없습니다.

7단계 중첩 로테이션으로 서비스 중단을 피한다

가장 안전한 방식은 새 키와 이전 키를 잠시 함께 운영하고, 실제 트래픽으로 전환을 확인한 뒤 이전 키를 폐기하는 것입니다.

1. 현재 키 인벤토리 만들기

프로젝트, 소유 유형, 워크로드, 애플리케이션, 환경, 책임자, 시크릿 저장 위치, 배포 방식, 생성일, 알려진 만료일, 마지막 확인 사용량을 기록합니다. 용도나 소유자를 모르는 키는 무작정 일괄 폐기하지 말고 우선 조사 대상으로 둡니다.

OpenAI는 2026년 8월 4일 업데이트에서 Usage 및 Costs 대시보드, Usage API, Costs API가 API 키 기준 필터링과 그룹화를 지원한다고 밝혔습니다. 이 차원은 키가 아직 요청을 만드는지 판단하는 증거가 될 수 있습니다. 다만 월간 배치나 재해 복구 경로는 오래 조용할 수 있으므로 이것만으로 삭제 가능하다고 결론 내리면 안 됩니다.

2. 정책에 맞는 대체 키 만들기

대상 프로젝트에서 현재 조직·프로젝트 정책이 허용하는 소유 유형으로 새 키를 만듭니다. 만료일은 적용되는 상한을 넘지 않게 합니다. 배포 창에 들어간 뒤 충돌을 발견하지 않도록 미리 생성 가능 여부를 확인합니다.

3. 새 시크릿 버전으로 저장하기

이전 값을 즉시 덮어쓰지 마십시오. 통제된 전환 동안 이전 버전과 새 버전을 함께 유지하고 “현재 운영”, “로테이션 후보”, “폐기 대기”처럼 상태를 명확히 표시합니다. 키를 소스 코드, 컨테이너 이미지, 작업 티켓, 로그, 채팅 본문에 넣지 마십시오.

4. 트래픽을 단계적으로 전환하기

한 인스턴스, 저위험 작업 또는 소량 트래픽부터 시작합니다. 인증, 프로젝트 귀속, 권한, 요청 동작을 확인한 뒤 확장합니다. 애플리케이션이 시작 시점에만 키를 읽는다면 재시작과 용량 계획을 포함해야 합니다.

5. 애플리케이션 상태와 키별 사용량을 함께 관찰하기

성공 요청, 인증 오류, 제한, 지연, 비즈니스 결과를 확인합니다. 동시에 새 키에서 예상 사용량이 발생하고 이전 키 사용량이 줄어드는지 봅니다. 배포가 성공 표시되었다고 실제 트래픽이 이동했다는 뜻은 아닙니다.

6. 롤백 기간을 시간으로 제한하기

새 키가 안정된 뒤 미리 정한 기간만 이전 키를 보관하고 폐기합니다. 기간은 지연 worker, 여러 리전, 저빈도 작업을 포함해야 하지만 무기한 열어두면 안 됩니다. 영구적인 이중 키 운영은 유효한 시크릿 수만 늘립니다.

7. 폐기하고 확인한 뒤 다음 로테이션 예약하기

폐기 후 이전 키 요청이 실패하고 새 키는 계속 성공하는지 확인합니다. 인벤토리, 온콜 문서, 담당자, 만료일, 다음 로테이션 날짜를 업데이트합니다.

기존 키는 자동으로 준수 상태가 되지 않는다: 위험 순서로 이전한다

새 규칙을 켠 뒤에도 기존 키는 소유자와 유효기간이 그대로이므로 별도의 이전 큐가 필요합니다.

별도의 이전 큐를 만들고 다음 순서로 우선순위를 정하십시오.

1. 코드, 티켓, 로그, 채팅에 노출된 적이 있는 키.
2. 소유자나 용도를 식별할 수 없는 키.
3. 퇴사하거나 역할이 바뀐 사람이 소유한 사용자 키.
4. 여러 운영 애플리케이션에서 공유되어 개별 폐기가 어려운 키.
5. 범위가 넓거나 영향이 큰 키.
6. 명확한 소유자, 단일 워크로드, 검증된 교체 경로가 있는 키.

모든 과거 키를 같은 날 폐기하는 것을 성공 기준으로 삼지 마십시오. 각 키에 의존성 지도, 승인된 대체 키, 전환 증거, 폐기 기한이 있는 상태가 더 안전한 완료 기준입니다. 당장 이전할 수 없다면 정확한 장애물, 책임자, 보완 통제, 예외 종료일을 기록하십시오. “레거시 시스템”은 영구 예외 사유가 아닙니다.

내부 정책에 최소한 필요한 11개 항목

실행 가능한 정책에는 기간뿐 아니라 담당자, 검증 증거, 롤백 기간, 폐기 조건까지 들어가야 합니다.

정책 항목	기록할 내용
범위	조직, 프로젝트, 환경, 워크로드 분류
허용할 새 키 유형	서비스 계정만, 사용자 소유만, 또는 새 키 없음
이유	업무 연속성, 개인 책임, 프로젝트 동결 등
최대 유효기간	조직 상한과 더 엄격한 프로젝트 상한
선행 시간	만료 전 알림 또는 작업을 언제 생성할지
저장	승인된 시크릿 관리자와 접근 역할
배포	Canary/단계 배포, 재시작, 롤백 방법
검증	성공 요청, 오류 지표, 키별 사용량, 이전 키 트래픽 0
폐기 조건	새 키 안정, 저빈도 작업 검증, 롤백 기간 종료
예외	승인자, 이유, 보완 통제, 예외 만료
감사	생성, 정책 변경, 배포, 폐기, 소유자 변경

장기 책임은 워크로드나 팀 역할에 연결하되, 현재 로테이션의 실행자도 지정하십시오. “플랫폼 팀 담당”만으로는 온콜 경로, 기한, 에스컬레이션이 없어 운영할 수 없습니다.

규칙을 적용하기 전에 다음 로테이션을 리허설한다

아래 항목을 모두 확인하고 저위험 프로젝트에서 리허설을 마친 뒤에만 조직·프로젝트 제한을 적용하세요.

• 모든 활성 애플리케이션이 구체적인 프로젝트와 키에 매핑되어 있다.
• 각 프로젝트가 다음 로테이션에서 필요로 하는 유형을 알고 있다.
• 조직 규칙이 중요한 대체 키 생성을 막지 않는다.
• 운영 환경이 한 직원의 개인 키에 의존하지 않는다.
• 시크릿 저장소가 버전 관리 또는 신뢰할 수 있는 롤백을 지원한다.
• 새 시크릿을 읽는 방식과 재시작 필요 여부를 시험했다.
• 키별 사용량 또는 비용을 관찰할 수 있고 저빈도 작업도 고려했다.
• 주 담당자와 대체 담당자가 있다.
• 만료 알림이 충분히 일찍 도착한다.
• 폐기 기준이 중첩 기간을 영구화하지 않는다.
• 해결되지 않은 각 레거시 키에 장애물, 담당자, 기한이 있다.

자주 묻는 질문

새 생성 제한이 기존 애플리케이션을 즉시 중단시키는가

2026년 9월 15일 OpenAI 업데이트에 따르면 기존 API 키는 새 생성 제어의 영향을 받지 않습니다. 새로 만들 수 있는 유형을 바꿔도 현재 키가 자동 폐기되지는 않습니다. 하지만 다음 로테이션은 영향을 받을 수 있으므로 대체 키 생성을 미리 리허설해야 합니다.

최대 유효기간이 과거 키에도 소급 적용되는가

9월 10일 업데이트는 새 키에 대한 요구로 설명됩니다. 기존 자격 증명에 자동으로 소급 만료가 붙는다고 가정하지 말고, 실제 키 상세를 확인한 뒤 별도 이전을 진행하십시오.

프로젝트 관리자가 조직 제한을 완화할 수 있는가

할 수 없습니다. 공식 설명상 조직 제한이 프로젝트 설정보다 우선합니다.

조직 전체에서 서비스 계정 키만 써야 하는가

운영 서비스, 공유 백엔드, 정기 작업, 팀 운영 Agent에는 서비스 계정 키를 우선하세요. 로컬 개발과 단기 탐색에는 사용자 소유 프로젝트 키를 우선하세요. 조직 전체를 서비스 계정 키로 제한하는 것은 거의 모든 프로젝트가 첫 번째 범주에 속하고 개발 프로젝트에도 실용적인 대안이 있을 때만 적절합니다.

모든 새 키 생성을 언제 막아야 하는가

보관 또는 종료 예정 프로젝트, 또는 보안 조사 중 임시 동결이 대표적입니다. 로테이션이나 복구를 위해 대체 키가 필요하지 않은지 먼저 확인하십시오.

이전 키를 폐기해도 된다는 것을 어떻게 증명하는가

롤아웃 상태, 새 키 성공 요청, 오류 모니터링, 키별 사용량, 저빈도 작업 실행, 롤백 기간 종료를 함께 확인합니다. 짧은 기간 동안 트래픽이 없다는 사실만으로는 보통 충분하지 않습니다.

지금 먼저 해야 할 세 가지

먼저 세 가지를 하세요. 각 프로젝트가 다음 로테이션에서 필요로 하는 키 유형을 기록하고, 저위험 프로젝트에서 중첩 로테이션을 한 번 완료한 뒤, 마지막으로 조직·프로젝트 제한을 적용합니다.

순서가 중요합니다. 상한선을 먼저 설정하면 현재 애플리케이션은 계속 작동해도 나중에 필요한 대체 키가 정책에 막힐 수 있습니다. 규칙을 강화하기 전에 다음 로테이션이 실제로 가능하다는 것을 증명하세요.

공식 출처:

• OpenAI API Changelog: 2026년 9월 10일 및 15일 업데이트