요약: OpenAI가 Workload Identity Federation을 제공하면서 GitHub Actions, Kubernetes, AWS IAM, SPIFFE 같은 외부 OIDC 신원을 짧은 수명의 OpenAI access token으로 교환할 수 있게 됐습니다. 핵심은 서버·CI·배치 작업에 장기 API 키를 저장하지 않는 것입니다. 실무에서는 secret 유출 리스크, 키 회전 비용, 환경별 권한 분리를 한 번에 다시 설계할 기회입니다.
초기 AI 제품은 .env 파일에 OPENAI_API_KEY를 넣고 배포해도 큰 문제가 없어 보였습니다. 하지만 사용량이 커지고, 여러 팀이 같은 조직에서 프로젝트를 나누고, CI/CD와 에이전트가 자동으로 API를 호출하기 시작하면 상황이 달라집니다. 장기 API 키는 복사되기 쉽고, 로그에 남기 쉽고, 퇴사자 노트북이나 오래된 GitHub secret에 방치되기 쉽습니다.
특히 AI API는 비용 폭주 위험이 큽니다. 데이터베이스 비밀번호가 유출되면 데이터 접근 사고가 납니다. AI API 키가 유출되면 비용 사고와 데이터 사고가 동시에 날 수 있습니다. 공격자는 키 하나로 고가 모델을 대량 호출하거나, 조직 정책 밖에서 데이터를 처리할 수 있습니다. 그래서 키 자체를 오래 보관하지 않는 구조가 필요했습니다.
OpenAI Workload Identity Federation은 이 문제를 직접 겨냥합니다. 신뢰된 외부 workload가 발급한 OIDC JWT subject token을 OpenAI가 검증하고, 짧은 수명의 OpenAI access token으로 교환합니다. 배포 환경에는 영구 키가 아니라 외부 신원과 매핑 규칙만 남습니다.
문서 기준으로 Workload Identity Federation은 네 부분으로 구성됩니다. 첫째, workload identity provider입니다. 이 provider는 신뢰할 OIDC issuer, audience, JWKS 같은 검증 정보를 담습니다. 둘째, service account mapping입니다. 외부 토큰의 claim이나 변환된 attribute가 어떤 OpenAI service account를 사용할 수 있는지 정합니다.
셋째는 token exchange입니다. workload가 외부 subject token을 OpenAI에 보내고, OpenAI가 검증한 뒤 짧은 수명의 access token을 반환합니다. 넷째는 실제 API 호출입니다. workload는 받은 OpenAI access token을 bearer credential로 사용합니다.
이 구조에서 중요한 점은 mapping이 권한의 중심이라는 것입니다. 예를 들어 GitHub Actions 토큰에는 iss, aud, sub, repository, ref 같은 claim이 들어갑니다. OpenAI는 CEL(Common Expression Language) 기반 attribute transformation을 지원하므로 repository와 ref를 조합해 openai.repository_ref 같은 attribute를 만들 수 있습니다. 그런 다음 “my-org/my-repo@refs/heads/main일 때만 production service account를 mint할 수 있다”는 식으로 제한할 수 있습니다.
가장 먼저 적용할 만한 곳은 CI/CD입니다. GitHub Actions는 이미 OIDC 토큰을 발급할 수 있습니다. 기존 방식은 GitHub secret에 OpenAI API 키를 저장하는 것입니다. 새 방식은 GitHub가 발급한 OIDC 토큰을 OpenAI에 교환하고, 그 결과로 받은 짧은 수명 토큰을 배포 작업에서 사용합니다.
실무적으로는 production과 staging을 분리해야 합니다. staging 브랜치나 pull request에는 저비용 모델만 허용된 service account를 연결합니다. main 브랜치 배포에는 운영 service account를 연결하되, 필요한 API 권한만 부여합니다. OpenAI 문서도 broad pattern보다 exact claim matching을 권장합니다. sub에 repo:my-org/my-repo:* 같은 trailing wildcard는 가능하지만, * 단독이나 중간 wildcard는 허용되지 않습니다.
이 규칙은 사고 범위를 줄입니다. PR에서 실행되는 테스트가 실수로 production service account를 쓰지 못하게 막고, forked workflow에서 토큰이 mint되지 않도록 할 수 있습니다. AI 테스트 자동화가 늘어날수록 이 분리는 비용 통제에 직접 연결됩니다.
Kubernetes 운영팀에는 SPIFFE JWT-SVID나 클러스터 OIDC issuer 기반 구성이 더 자연스럽습니다. 서비스마다 OpenAI key를 secret으로 주입하는 대신, workload identity provider를 만들고 서비스 계정별 mapping을 구성합니다. 예를 들어 summarizer 서비스는 요약 모델만, image-worker는 이미지 모델만, eval-runner는 Batch API만 쓰게 나눌 수 있습니다.
이 접근의 장점은 키 회전 작업이 줄어든다는 것입니다. 장기 키를 주기적으로 바꾸고 배포하는 대신, 외부 identity provider의 토큰 발급과 OpenAI mapping을 관리합니다. 키가 짧은 수명으로 발급되기 때문에 유출 시 영향 시간이 제한됩니다. 물론 완전한 보안은 아닙니다. 공격자가 workload 자체를 장악하면 토큰 교환을 계속 시도할 수 있습니다. 그래서 네트워크 정책, 런타임 격리, audit log 모니터링이 함께 필요합니다.
Workload Identity Federation의 장애 포인트는 토큰 검증입니다. OpenAI는 OIDC discovery를 통해 issuer의 .well-known/openid-configuration과 JWKS를 가져올 수 있고, 문서상 discovery 문서와 remote JWKS payload는 600초 동안 캐시됩니다. token kid가 캐시에 없으면 JWKS를 새로 가져와 한 번 더 확인합니다.
업로드 JWKS 모드를 쓰는 경우에는 더 조심해야 합니다. 새 signing key로 토큰을 발급하기 전에 OpenAI provider에 새 public key를 먼저 등록해야 합니다. 그렇지 않으면 새 kid로 서명된 토큰이 거절됩니다. 운영 절차는 명확해야 합니다. rotation window 동안 old key와 new key를 모두 JWKS에 게시하고, 모든 workload가 새 키로 넘어간 뒤 old key를 제거합니다.
이 부분은 보안팀과 플랫폼팀이 함께 runbook을 만들어야 합니다. “토큰 교환 실패율 증가”, “특정 issuer kid mismatch”, “mapping 중복으로 exchange reject” 같은 알림을 준비하지 않으면 배포 파이프라인이 갑자기 멈춰도 원인을 찾기 어렵습니다.
가장 좋은 도입 순서는 새 자동화부터입니다. 신규 GitHub Actions, 신규 배치 작업, 신규 agent worker에는 장기 API 키를 만들지 않는 원칙을 적용합니다. 기존 서비스는 호출량과 권한 위험이 큰 순서로 이전합니다. 비용이 큰 모델을 쓰는 서비스, 외부 contributor가 건드리는 CI, 여러 팀이 공유하는 배치 계정이 1순위입니다.
반대로 로컬 개발 환경은 바로 없애기 어렵습니다. 개발자 경험을 해치지 않으려면 로컬에서는 짧은 수명의 developer token을 발급하거나, 별도 저권한 project key를 제한적으로 유지하는 방식을 병행할 수 있습니다. 핵심은 production과 automation에서 영구 키 의존도를 먼저 줄이는 것입니다.
출처: OpenAI API changelog 2026년 5월 26일, OpenAI Workload Identity Federation 문서.
