Google AI Studio API 키 만들기 전, 초보자가 먼저 확인할 보안 설정

AI를 활용하여 생성한 이미지입니다.

AI · LLM · Gemini API

Google AI Studio에서 Gemini API 키를 만들기 전에 먼저 사용 목적, 프로젝트, 보관 위치, 노출 시 교체 절차를 정해 두세요. API 키는 프로그램이 Gemini API 요청을 인증하는 값이며, Google의 빠른 시작 문서도 Gemini API를 사용하려면 키가 필요하다고 설명합니다.[1] 생성 버튼을 먼저 누르는 것보다 키가 어디에서 읽히고 누가 바꿀 수 있는지 정하는 편이 안전합니다.

키를 코드, 브라우저 자바스크립트, 공개 저장소, 채팅에 붙여 넣으면 다른 사람이 사용량을 늘려 쿼터를 소진시키거나 비용을 만들 수 있습니다. Google도 API 키를 비밀번호처럼 다루고 소스 코드에 넣지 말라고 안내합니다.[2] 테스트용 키와 운영용 키를 나누면 노출 사고의 범위를 줄이고 원인을 추적하기도 쉽습니다.

키를 만들기 전에 결정할 네 가지

Google AI Studio에서 키 확인하기

1. Google AI Studio API 키 페이지를 엽니다.
2. Google 계정으로 로그인한 뒤 사용할 프로젝트가 실험용인지 운영용인지 확인합니다.
3. Create API key 또는 새 키를 만드는 항목을 선택합니다.
4. 키 이름과 연결된 프로젝트만 기록하고, 키 문자열 자체는 문서나 채팅에 저장하지 않습니다.
5. 실제 서비스에 배포하기 전에 별도의 테스트 환경에서 요청과 오류 처리를 확인합니다.

Google AI Studio는 키와 프로젝트를 관리하는 화면을 제공하며, 키는 Google Cloud 프로젝트와 연결됩니다.[2] 프로젝트가 결제·공동 작업자·권한을 나누는 단위라면 개인 실험과 서비스 운영을 같은 곳에 섞지 않는 편이 좋습니다. 프로젝트를 나눴다고 보안이 자동으로 완성되는 것은 아니므로 접근 가능한 계정과 로그도 함께 관리해야 합니다.

코드에는 환경 변수로 전달하기

Google 문서에는 클라이언트 라이브러리가 GEMINI_API_KEY 또는 GOOGLE_API_KEY 환경 변수를 읽도록 설정하는 방법이 안내되어 있습니다.[2] 두 변수가 모두 있으면 GOOGLE_API_KEY가 우선될 수 있으므로 초보자는 한 가지 이름만 정해 두는 편이 덜 헷갈립니다.

GEMINI_API_KEY=여기에_실제_키를_본문에_기록하지_마세요

위 코드는 형식만 보여 주는 예시입니다. 실제 키를 블로그, 문서, 소스 파일, 프런트엔드 코드에 복사하지 마세요. 팀 프로젝트와 배포 환경에서는 비밀 저장소를 사용하고, 디버그 로그나 오류 메시지에 환경 변수 값 전체가 찍히지 않는지도 점검해야 합니다. 브라우저에서 직접 API를 호출해야 하는 구조라면 키를 숨길 수 없다는 점을 먼저 인정하고, 서버 프록시나 공식 인증 설계를 검토해야 합니다.

표준 키와 인증 키 확인하기

Google 문서에는 표준 API 키와 Google Cloud 서비스 계정에 연결된 인증 키가 구분되어 있습니다.[2] 인증 키는 서비스 계정의 정체성과 연결되어 더 세밀한 접근 제어에 사용할 수 있습니다. 기존 문서에는 2026년 5월 28일부터 AI Studio에서 새로 만든 키가 인증 키로 생성된다는 안내와, 2026년 9월에는 표준 키 요청이 거절될 수 있다는 공지가 함께 제시되어 있습니다.[2]

따라서 예전에 만든 표준 키가 있다면 키 유형과 제한 상태를 확인하세요. 새 키를 만들었다고 기존 프로그램이 자동으로 새 키를 쓰는 것은 아닙니다. 환경 변수, 배포 비밀 값, CI 설정을 새 키로 바꾼 뒤 테스트하고, 이전 키를 언제 폐기할지도 기록해야 합니다. 문서와 콘솔의 메뉴가 바뀌었을 때는 과거 화면을 그대로 따라 하기보다 현재 안내의 인증 방식을 우선 확인하세요.

키가 노출됐을 때의 순서

1. 노출된 키를 사용하는 프로그램과 배포를 먼저 멈춥니다.
2. Google AI Studio 또는 연결된 Google Cloud 프로젝트에서 해당 키를 폐기하거나 교체합니다.
3. 새 키에 Gemini API 범위와 애플리케이션 제한을 다시 설정합니다.
4. 환경 변수·배포 비밀 값·CI 설정을 새 키로 바꿉니다.
5. 사용량과 로그에서 모르는 요청이나 갑작스러운 증가가 있었는지 확인합니다.
6. 공개 저장소 커밋 기록과 빌드 로그에 값이 남았다면 관련 복사본과 접근 권한도 정리합니다.

문자열 일부를 가리거나 저장소의 최신 파일에서만 지우는 것으로는 충분하지 않을 수 있습니다. 이미 공개된 커밋과 로그를 본 사람이 있을 수 있으므로, 노출된 키는 유출된 것으로 보고 폐기·교체하는 것이 기준입니다. 키를 교체한 뒤에도 프로그램이 계속 실패한다면 새 키의 프로젝트, 환경 변수 이름, API 범위, 배포 환경이 서로 맞는지 하나씩 확인하세요.

처음 사용하는 사람의 점검표

• 실험용과 운영용 Google Cloud 프로젝트를 분리합니다.
• 키는 환경 변수나 비밀 저장소에서만 읽습니다.
• Gemini API 외의 불필요한 사용 범위를 제한합니다.
• Git 커밋 전 비밀 값 검색과 로그 마스킹을 적용합니다.
• 키 이름, 연결 프로젝트, 교체 담당자만 기록하고 키 문자열은 남기지 않습니다.
• 노출을 발견하면 폐기·교체·사용량 확인을 같은 날 처리합니다.

로컬 실험과 실제 배포를 나누세요

개인 컴퓨터에서 환경 변수로 키를 읽는 것과 운영 서버에서 비밀을 주입하는 것은 같은 설정이 아닙니다. 로컬 파일을 저장소에 올리지 않도록 무시 규칙을 확인하고, 팀원이 필요한 경우 키 문자열 대신 비밀 저장소의 권한을 공유하세요. 운영 배포에서는 빌드 로그, 오류 추적 서비스, 쉘 기록에 키가 남지 않는지 확인해야 합니다.

작은 테스트라도 사용량과 오류를 확인할 수 있는 이름을 붙여 두면 사고 대응이 쉬워집니다. 실험용 키를 여러 프로젝트에서 재사용하면 어느 환경이 호출했는지 파악하기 어려워지므로, 목적과 프로젝트를 나누고 더 이상 사용하지 않는 키는 폐기 목록에 기록하세요. 키를 새로 만든 뒤에는 이전 키를 바로 지우기보다 배포가 새 값으로 전환되었는지 확인한 다음 교체하는 순서를 정해야 합니다.

공개 저장소에서 키를 발견했다면 커밋을 수정하는 일과 키를 폐기하는 일을 별개로 처리하세요. 기록을 지우는 작업만 먼저 하면 이미 복사된 값은 계속 유효할 수 있습니다. 반대로 키를 바꿨는데 애플리케이션이 실패한다면 환경 변수 이름의 우선순위, 연결 프로젝트, 사용 범위, 배포 환경을 차례로 확인하면 됩니다. 실제 키를 이 글의 예시에 넣어 확인하지 않는 것이 원칙입니다.

자주 묻는 질문

API 키를 프런트엔드에 넣어도 되나요?

브라우저로 전달된 값은 사용자가 볼 수 있습니다. 키를 숨겨야 하는 서비스라면 서버에서 호출하고 브라우저에는 필요한 결과만 전달하는 구조를 검토하세요. 단순히 자바스크립트 파일을 난독화하는 것은 비밀 보관 방법이 아닙니다.

환경 변수에 넣으면 무조건 안전한가요?

환경 변수는 소스 코드에 직접 쓰는 것보다 낫지만, 로그·프로세스 권한·배포 설정을 통해 노출될 수 있습니다. 비밀 저장소, 접근 권한, 로그 마스킹, 교체 절차를 함께 운영해야 합니다.

키를 만들었는데 기존 코드가 작동하지 않아요.

새 키의 연결 프로젝트, 환경 변수 이름, 실제 실행 환경, API 제한을 순서대로 확인하세요. 기존 프로그램이 자동으로 새 키로 바뀌지는 않습니다.

AI API 키를 채팅창이나 공개 코드에 넣으면 안 되는 이유와 보관 원칙은 AI API 키 안전 보관 가이드에서도 이어서 확인할 수 있습니다.

Sources

1. [1] Gemini API quickstart | Google AI for Developers
2. [2] Using Gemini API keys | Google AI for Developers