OpenAI Terraform provider 출시: API 권한 관리를 코드로 옮길 때 확인할 것

OpenAI가 2026년 7월 29일 공식 Terraform provider를 공개했다. 이제 OpenAI API Platform의 프로젝트, 사용자, 그룹, 역할, 서비스 계정, 인증서, 초대, 프로젝트별 rate limit, spend alert 같은 운영 리소스를 Terraform 코드로 관리할 수 있다. 단순한 편의 기능처럼 보이지만, 팀 단위로 AI API를 쓰는 회사에는 꽤 큰 변화다.

지금까지 많은 팀은 OpenAI 콘솔에서 프로젝트를 만들고, 사람을 초대하고, 서비스 계정 키를 발급하고, 나중에 누가 무엇을 바꿨는지 Slack 기록이나 기억에 의존했다. PoC 단계에서는 문제가 덜하다. 하지만 제품이 여러 개가 되고, 개발·스테이징·프로덕션 프로젝트가 나뉘고, 외주나 파트너가 붙으면 설정 변경 하나가 비용 사고나 권한 사고로 이어진다.

공식 문서 기준으로 provider는 OpenAI Administration API를 사용한다. 관리 대상에는 projects, users, groups, roles, service accounts, certificates, rate limits, spend alerts, project settings가 포함된다. Terraform 1.0 이상이 필요하고, import 예시는 Terraform 1.5 이상을 요구한다. Admin API key는 일반 OpenAI API 엔드포인트에는 사용할 수 없으며, 환경변수 OPENAI_ADMIN_KEY 또는 시크릿 매니저에 보관해야 한다.

왜 개발팀이 이 업데이트를 봐야 하나

AI API 비용과 권한은 더 이상 개인 카드로 실험하는 수준의 문제가 아니다. 에이전트, 음성 전사, 이미지 생성, 배치 처리, 웹 검색 도구를 프로덕션에 붙이면 비용과 권한의 변경 이력이 배포 이력만큼 중요해진다. 누가 rate limit을 올렸는지, 어떤 서비스 계정이 어떤 프로젝트에 접근하는지, 임시로 만든 키가 남아 있는지 확인할 수 있어야 한다.

Terraform provider의 핵심 장점은 변경 전 terraform plan으로 영향을 검토할 수 있다는 점이다. 예를 들어 신규 팀에 프로젝트 접근 권한을 주거나, 서비스 계정을 새로 만들거나, 프로젝트별 예산 알림을 추가할 때 콘솔에서 바로 저장하지 않고 코드 리뷰를 거친다. 변경 내용이 Git에 남고, 승인자와 이유도 PR에 남는다.

이 방식은 특히 다음 환경에서 효과가 크다. 첫째, 여러 제품이 같은 OpenAI 조직을 공유하는 회사. 둘째, 고객별 또는 환경별로 OpenAI 프로젝트를 분리하는 SaaS. 셋째, 보안 감사에서 계정·권한·비용 통제 증빙을 요구받는 B2B 팀. 넷째, AI 기능을 빠르게 실험하느라 콘솔 설정이 이미 어지러워진 조직이다.

운영 구조는 프로젝트 단위로 먼저 나누는 편이 낫다

Terraform을 도입한다고 모든 문제가 자동으로 정리되지는 않는다. 먼저 OpenAI 조직 안에서 프로젝트 경계를 정해야 한다. 일반적으로는 dev, staging, prod처럼 환경 기준으로 나누거나, search-agent, voice-pipeline, internal-tools처럼 제품·워크로드 기준으로 나눈다. 둘 중 하나를 고르는 문제가 아니라 비용 책임과 장애 격리 기준을 먼저 정하는 문제다.

예를 들어 고객 응대 챗봇과 내부 문서 요약 도구를 같은 프로젝트에 넣으면 월별 사용량이 섞인다. 비용이 튀어도 어떤 기능이 원인인지 늦게 알게 된다. 반대로 너무 잘게 나누면 권한 관리와 rate limit 설정이 많아져 운영 비용이 늘어난다. 실무 기준으로는 프로덕션 트래픽이 있고 비용 책임자가 다른 워크로드는 별도 프로젝트로 빼는 편이 안전하다.

Terraform 코드에서는 프로젝트 생성, 그룹 접근, 서비스 계정, spend alert, rate limit을 한 디렉터리에서 함께 관리하는 구조가 좋다. 그래야 특정 프로젝트의 운영 조건을 한 번에 읽을 수 있다. 서비스 계정만 별도 파일에 흩어놓으면 실제 접근 권한을 추적하기 어렵다.

Admin API key는 일반 API key처럼 다루면 안 된다

공식 문서도 Admin API key를 Terraform 설정이나 소스 코드에 커밋하지 말라고 명시한다. 이 키는 단순히 모델을 호출하는 키가 아니라 조직 리소스를 바꾸는 키다. 유출되면 토큰 비용보다 큰 문제가 생길 수 있다. 서비스 계정을 만들고, 프로젝트 설정을 바꾸고, 접근 권한을 조정할 수 있기 때문이다.

운영에서는 최소한 세 가지를 지켜야 한다. 첫째, 로컬 개발자는 개인 터미널 환경변수로만 사용하고 .env를 커밋하지 않는다. 둘째, CI에서는 GitHub Actions secrets, AWS Secrets Manager, GCP Secret Manager 같은 별도 저장소에 넣는다. 셋째, Terraform plan은 누구나 볼 수 있어도 apply는 제한된 승인자만 실행한다.

가능하면 조직 전체를 바꾸는 루트 Terraform 작업은 별도 파이프라인으로 분리해야 한다. 애플리케이션 배포 파이프라인에서 실수로 OpenAI 권한까지 변경되는 구조는 피하는 편이 좋다. Terraform 상태 파일에도 리소스 정보가 남으므로 backend 접근 권한도 따로 관리해야 한다.

도입 순서는 import와 drift 확인부터 시작하라

이미 운영 중인 OpenAI 조직이라면 처음부터 terraform apply로 새 리소스를 만들기보다 import가 먼저다. 현재 콘솔에 있는 프로젝트, 서비스 계정, 권한, rate limit, spend alert를 Terraform state로 가져오고, 코드와 실제 설정이 일치하는지 확인해야 한다.

첫 주에는 읽기와 plan만 돌리는 것이 안전하다. 목표는 바꾸는 것이 아니라 보이는 것이다. 어떤 프로젝트가 있는지, 누가 접근하는지, 오래된 서비스 계정이 남아 있는지, 프로젝트별 비용 통제가 있는지 목록화한다. 그다음 변경 빈도가 높은 리소스부터 코드화한다. 보통은 서비스 계정, 그룹 접근, rate limit, spend alert 순서가 현실적이다.

drift detection도 중요하다. 누군가 콘솔에서 직접 설정을 바꾸면 Terraform plan에 차이가 나타난다. 이때 무조건 되돌리기보다 콘솔 변경이 긴급 조치였는지 확인해야 한다. 긴급 조치였다면 코드에 반영하고, 아니면 재발 방지를 위해 콘솔 쓰기 권한을 줄인다.

실제 체크 포인트

OpenAI Terraform provider는 AI 인프라 운영이 일반 클라우드 운영과 비슷한 단계로 들어갔다는 신호다. 모델 품질만 보는 시기는 지났다. 권한, 비용, 감사, 변경 이력까지 제품 코드와 같은 수준으로 관리해야 한다.

실행 체크리스트는 다음과 같다.

• OpenAI 프로젝트를 환경별 또는 워크로드별로 분리했는가.
• Admin API key를 코드·상태 파일·로그에 남기지 않는가.
• terraform plan 결과를 PR 리뷰에서 확인하는가.
• 서비스 계정과 사람 계정을 분리했는가.
• 프로젝트별 spend alert와 hard limit 기준을 문서화했는가.
• 기존 콘솔 설정을 import한 뒤 drift를 확인했는가.
• apply 권한을 소수 운영자 또는 승인된 CI에만 줬는가.

작게 시작하려면 신규 OpenAI 프로젝트 하나를 Terraform으로 만들고, 서비스 계정 하나와 spend alert 하나만 코드화해 보라. 그 과정에서 팀의 권한 기준과 비용 통제 기준이 드러난다. 이 provider의 가치는 도구 자체보다 그 기준을 Git에 남기게 만든다는 데 있다.