OpenAI / Anthropic / Google의 생성형 AI API를 사내의 여러 멤버가 이용하게 된 조직에서, API 키 관리 정책 정비가 정보시스템(情シス) 담당자의 실무 과제로 부상하고 있다. 이 기사에서는 AI API 키 관리의 유출 리스크 분류와 관리 방식의 선택 판단 플로우를 정보시스템 담당자의 관점에서 정리한다.

• ChatGPT / Claude / Gemini API를 직원이 개별적으로 취득하여 이용하고 있는 100명 규모 기업의 정보시스템 담당자
• API 키를 스프레드시트나 Slack으로 공유하고 있는 운용을 재검토하고 싶은 분
• GAS (Google Apps Script)로 사내 도구에서 AI API를 호출하고 있지만, 키의 저장 방법에 불안함이 있는 분
• AI 활용 거버넌스 정비를 이제부터 본격적으로 진행하려는 담당자

API 키를 관리 방침 없이 운용했을 경우의 리스크는 크게 3가지로 분류할 수 있다.

유출의 전형적인 경로는 "소스 코드에 직접 작성 → Git 리포지토리로 오커밋(誤commit)"이다. GitHub에는 API 키 형식을 패턴으로 탐지하여 리포지토리 소유자에게 통지하는 Secret Scanning 기능이 있지만(GitHub 공식 문서 참조), 한 번 커밋 히스토리에 들어간 문자열을 완전히 제거하려면 전문적인 조작이 필요하다. 알아차린 시점에 즉시 무효화하고, 신규 발행으로 전환하는 것이 현실적인 대처다.

Slack 채널에 직접 붙여넣는 것도 빈번하게 발생하는 경로 중 하나다. "○○님에게 우선 공유합니다"라며 키를 붙여넣은 메시지는 채널 참여자 전원이 열람할 수 있는 상태로 과거 로그에 계속 남는다. 외부 위탁 업체나 퇴직자가 동일한 채널에 남아 있을 경우의 리스크는 예상보다 크다.

유출된 키가 악의적인 제3자에게 사용될 경우, 단시간에 고액의 청구가 발생할 수 있다. OpenAI 등 주요 벤더는 하드 리미트(Hard Limit, 월간 상한액) 설정 기능을 제공하지만, 기본값으로는 설정되어 있지 않은 경우가 많다. 상한을 설정하지 않은 상태에서 키가 유출되면, 며칠 만에 수십만 엔 규모의 청구가 오는 케이스도 실제로 보고되고 있다. 비용 상한 설정은 "API 키를 만들면 즉시 해야 할 일"로서 운용 가이드에 명시해 두어야 할 항목 중 하나다.

API 키 관리와 병행하여 "직원이 AI API에 보내는 프롬프트에 고객 정보나 개인정보를 포함하지 않는다"라는 데이터 이용 규칙의 정비도 필요하다. 키 관리만 정비하고 데이터 전송 규칙이 미정비된 상태는 개인정보 보호법 · GDPR 관점에서는 불충분하며, 외부 감사 시 지적 대상이 되기 쉽다.

이 세 가지 리스크는 독립된 문제다. "비용 상한을 설정했다"는 것만으로는 유출 리스크가 사라지지 않는다. 대책의 우선순위를 정하기 전에 "지금 어떤 리스크가 가장 심각한가"를 관계 부서와 합의해 두는 것이 출발점이 된다.

AI API의 시크릿(Secret) 관리 방식은 크게 3가지 선택지가 있다. 조직의 규모와 이용 환경에 맞춰 선택할 수 있는 판단 축을 아래에 정리한다.

GAS Script Properties는 GWS를 이용하고 있는 조직이 GAS로 AI 연동 스크립트를 만들 때 가장 간편한 선택지다. 키를 스크립트 코드로부터 분리하여 저장할 수 있기 때문에, 코드를 공유해도 키 자체는 전달되지 않는다. 단, 스크립트에 편집 권한을 가진 멤버는 스크립트 에디터의 UI를 통해 값을 열람할 수 있다. 스크립트에 대한 공유 범위를 필요 최소한으로 좁히는 것이 이 방식을 사용하는 전제 조건이다.

GCP Secret Manager는 여러 서비스가 동일한 시크릿 (Secret)을 참조하는 환경에 적합하다. Google Cloud의 IAM (Identity and Access Management)과 연동되어 있어, 누가 언제 시크릿에 접근했는지에 대한 감사 로그 (Audit Log)도 취득할 수 있다. GAS 스크립트 단일 용도로는 설계 비용이 상승하지만, 이미 GCP 프로젝트를 운영 중이라면 일원 관리 관점에서 검토할 가치가 있다. Secret Manager는 키의 버전 관리 (Version Management)도 지원하므로, 로테이션 (Rotation) 중 서비스 중단을 방지하기 쉬운 구성을 취할 수 있다.

팀 패스워드 매니저 (1Password Teams, Bitwarden for Business 등)는 비엔지니어가 브라우저 확장 프로그램 등을 통해 시크릿을 참조하고자 할 때 적합하다. 이미 전사에 도입되어 있다면, 우선 그곳에 저장함으로써 'Slack 직접 붙여넣기'를 즉시 방지할 수 있다. 반면, 프로그램에서 직접 참조하려면 CLI나 Secrets Automation 기능과 같은 추가 설정이 필요하다.

판단의 분기점은 '그 시크릿을 어디에서 사용하는가'와 '누가 액세스를 관리하는가'라는 두 가지 점으로 요약된다. GAS 스크립트 내에서만 사용한다면 Script Properties, 여러 서비스에서 참조한다면 Secret Manager, 사람이 설정 화면에 복사하여 붙여넣어 사용한다면 팀 패스워드 매니저가 기본적인 기준이 된다. 현재 상황이 '아무것도 관리하고 있지 않다'라면, 어떤 방식이든 지금 바로 이행하는 것이 우선이다. 이상적인 방식에 집착하여 이행이 늦어지는 것보다, 즉시 착수할 수 있는 방식을 선택하는 것이 결과적으로 리스크를 낮출 수 있다.

GAS (Google Apps Script)의 Script Properties는 PropertiesService API를 통해 읽고 쓰는 키-값 저장소 (Key-Value Store)이다. 스크립트 프로퍼티 (Script Property)에 저장된 값은 에디터의 소스 코드상에는 표시되지 않으며, 코드 리포지토리 (Repository) 공유 시 키가 유출될 리스크를 거의 제로로 억제할 수 있다 (Google Apps Script 공식 문서 참조).

API 키를 등록하는 일시적인 함수를 작성한다. 실행 후에는 키 문자열을 비우거나, 이 함수를 코드에서 반드시 삭제해야 한다. 문자열이 남아 있는 상태라면 비닉 (Secrecy)의 의미가 없어진다.

// API 키를 Script Properties에 등록한다 (최초 1회만 수동 실행하고, 그 후 이 함수를 삭제한다)
function saveApiKey() {
const props = PropertiesService.getScriptProperties();
...

Logger.log를 통해 등록된 프로퍼티 이름 목록이 출력되는 것을 확인할 수 있다. 값 자체를 로그에 출력하지 않도록 주의해야 한다. 확인 후, 이 함수는 스크립트에서 삭제하는 것이 철칙이다.

다음은 getApiKey 헬퍼 함수와, OpenAI Chat Completions를 호출하는 함수의 구현 예시다.

// Script Properties에서 API 키를 가져오는 헬퍼 함수
function getApiKey(keyName) {
const key = PropertiesService.getScriptProperties().getProperty(keyName);
...

getApiKey 함수를 범용화해 두면, Claude나 Gemini의 키를 추가할 때도 동일한 패턴으로 대응할 수 있다. 변경이 필요한 것은 model 값과 엔드포인트 (Endpoint) URL뿐이며, 키 취득 로직은 그대로 재사용할 수 있다. 여러 AI 프로바이더 (Provider)를 구분하여 사용하는 경우에는 OPENAI_API_KEY, ANTHROPIC_API_KEY, GOOGLE_AI_API_KEY와 같이 접두사 (Prefix)를 통일해 두면 프로퍼티 목록을 보았을 때 용도를 한눈에 알 수 있다.

Script Properties는 스크립트 단위로 분리되어 있다. 스프레드시트 A의 스크립트에 저장한 키는 스프레드시트 B의 스크립트에서 읽을 수 없다. 여러 GAS 스크립트에서 동일한 API 키를 사용하는 경우, 각각의 스크립트에 키를 등록하거나 GCP Secret Manager로의 이행을 검토해야 하는 단계에 와 있다는 신호로 받아들이면 된다.

Script Properties는 스크립트 프로젝트의 소유자 변경이나 삭제 시 값이 유실될 가능성도 있다. 키의 원본은 팀 패스워드 매니저(Password Manager)나 다른 안전한 장소에 반드시 보관해야 한다. "Script Properties에 넣었으니 대장에서 제외해도 된다"라고 생각하는 상태가 가장 위험한 패턴이다.

보관 장소를 정비하는 것만큼이나 지속적인 운영 규칙이 중요하다. 다음 체크리스트를 통해 현황을 확인해 보길 바란다.

대장·발행 관리

키 대장 정비: 발행된 API 키를 용도·담당자·취득일·벤더를 포함한 대장으로 관리하고 있다 -
조직 계정으로 발행: 개인 신용카드가 아니라, 조직의 계정에 키가 연결되어 있다 -
환경 분리: 운영용 키와 개발·테스트용 키를 별도로 발행하고 있다

대장은 거창한 시스템일 필요가 없다. Google 스프레드시트의 시트 하나에 "키 ID(끝 4자리) / 용도 / 발행자 / 발행일 / 비용 상한 설정 여부 / 최종 로테이션(Rotation)일" 컬럼을 두는 것만으로도, 재고 조사와 관리의 기반이 된다.

액세스 제어와 비용 관리

소스 코드에 직접 작성 금지: 키를 코드에 임베딩(Embedding)하지 않고, Script Properties·Secret Manager·패스워드 매니저 중 하나로 관리하고 있다 -
최소 권한 부여: 키에 필요한 최소한의 스코프(Scope)만 부여하고 있다 (벤더가 제공하는 제한 기능을 활용한다) -
비용 상한 및 알림 설정: 벤더의 관리 콘솔에서 월간 이용 금액의 상한 또는 알림을 설정하고 있다

비용 상한 설정 위치는 각 벤더의 API 키 관리 화면에서 확인할 수 있다. OpenAI는 프로젝트(Project)별로 월간 하드 리미트(Hard Limit)를 설정할 수 있다. Anthropic은 이용량 알림 설정이 가능하다. 설정값의 기준은 "통상적인 달의 예상 이용액의 2배에서 알림, 3배에서 하드 스톱(Hard Stop)"을 출발점으로 삼는 것이 관리하기 쉽다.

퇴직자·이동자 대응 및 로테이션

퇴직·이동 시 절차 명문화: 담당자 변경 시 키를 무효화·재발행하는 절차를 오프보딩(Offboarding)에 포함하고 있다 -
정기 로테이션: 키를 정기적으로(최소 연 2회 권장) 갱신하고, 오래된 키를 무효화하는 운영 규칙이 정해져 있다 -
유출 의심 시 즉시 대응 절차: 키가 외부에 유출되었을 가능성이 생겼을 경우, 즉시 무효화 → 신규 발행 → 피해 확인을 수행하는 절차가 문서화되어 있다

퇴직자 대응 시 자주 간과되는 것이 "개인 계정으로 발행한 키"다. 조직의 GCP 프로젝트나 공식 API 콘솔에서 발행되었다면 일괄 관리할 수 있지만, 담당자가 개인 Google 계정으로 발행한 키는 퇴직 시 대장에서 누락될 가능성이 있다. 발행 계정을 대장에 포함해 두면 이러한 리스크를 조기에 발견할 수 있다.

한 번에 모든 항목을 충족하지 못해도 괜찮다. 우선 "키 대장 정비"와 "소스 코드에 직접 작성 금지" 이 두 가지부터 착수하면 가장 발생하기 쉬운 리스크에 대처할 수 있다. 체크리스트를 별도 문서로 새로 만들기보다는, 기존의 오프보딩 절차서에 직접 포함하는 형태가 실제로 운영될 가능성이 더 높다.

참고로, API 키 발행 후의 월간 비용 시각화와 상한 관리에 대해서는 DRASENAS의 관련 기사에서 정리하고 있으니 함께 참조하기 바란다.

정비를 뒤로 미루면 키의 개수가 늘어난 뒤에 대장화하는 데 더 많은 수고가 든다. 다음 3단계에 따라 단계적으로 진행할 것을 권장한다.

스텝 1 (오늘~이번 주 중): 현황 재고 조사

현재 사용 중인 AI 서비스의 API 키를 전수 조사하여 작성한다. OpenAI라면 API 키 관리 화면, Anthropic (Claude)라면 Console의 키 목록, Gemini API라면 Google AI Studio의 키 관리 화면에서 발행된 키를 각각 확인할 수 있다. Slack의 검색 기능으로 sk-와 같은 키 프리픽스(Prefix)를 검색하면, 과거에 직접 붙여넣기 된 키를 발견할 수도 있다. 발견했을 경우 즉시 무효화하는 것이 최선의 대응이다.

스텝 2 (1~2주 이내): 보관 장소 이행

스프레드시트나 Slack에 남아 있는 키를 Script Properties·Secret Manager·패스워드 매니저 중 하나로 이행한다. GAS 스크립트를 사용 중이라면, 앞 절의 코드 예시를 그대로 사용하여 이행할 수 있다. 이행 후에는 구 키(Old Key)를 벤더의 관리 화면에서 무효화할 것. 무효화하지 않고 단순히 "사용하지 않게 된" 상태로 방치하지 않도록 주의가 필요하다.

스텝 3 (이행 완료 후~지속): 규칙을 사내에 침투시키기

「새로운 AI API 키를 취득할 때는 XXX로 관리한다」라는 규칙을 사내 온보딩 (Onboarding) 자료나 IT 이용 가이드라인에 한 줄 추가한다. IT 부서의 공지만으로는 점차 형식적으로 변하기 때문에, 개발 및 업무 개선을 담당하는 팀의 리더와 합의를 거쳐, 입구(신규 키 발행 시)의 규칙으로서 정착시키는 것이 지속적인 운영의 핵심이다.

GAS (Google Apps Script)로 AI API를 활용하고 있는 경우에는 오늘부터라도 Script Properties로의 키 이전을 시작할 수 있다. 코드를 수십 줄만 수정하면, 유출의 가장 많은 경로인 「소스 코드에 직접 작성 (Hardcoding)」 문제를 해결할 수 있다. 관리 방식의 고도화보다 「모두가 동일한 규칙을 따를 수 있는 체계」를 갖추는 것이 AI API 키 관리 정비의 본질이다.

이 기사에서 다룬 것과 같은 업무 개선 및 자동화의 설계부터 구현까지, DRASENAS에서는 코퍼레이트 IT (Corporate IT) 현장에 밀착한 지원을 수행하고 있습니다.

「우선 상담만」이라도 대환영입니다. DRASENAS 공식 사이트를 통해 언제든 편하게 문의해 주세요.

※ 이 기사는 DRASENAS Blog의 전재물입니다. 오리지널 버전에서는 코드와 설정 절차가 수시로 업데이트되고 있습니다.