Google AI Studio 키를 브라우저에 두면 안 된다…유출 막는 5단계

Google AI Studio에서 발급한 Gemini API 키를 보호하려면 운영 웹앱의 브라우저로 키를 보내지 않아야 한다. 프런트엔드는 자체 백엔드에 요청하고, 백엔드가 비밀 저장소에서 제한된 키를 읽어 Gemini API를 호출하도록 분리한다. 브라우저 코드에 포함된 키는 난독화하거나 환경변수로 주입해도 사용자가 추출할 수 있다.

배포 순서는 다섯 단계다. 기존 키가 Standard인지 Auth인지 확인하고, Gemini API와 실제 실행 환경으로 사용 범위를 제한한 뒤 브라우저의 직접 호출을 백엔드 경유 방식으로 바꾼다. 운영 키를 Secret Manager로 옮기고 저장소와 로그를 검사한 다음, 새 키의 작동을 확인하고 이전 키를 폐기한다.

1단계: Standard 키를 확인하고 Auth 키로 옮긴다

Google AI Studio의 Dashboard에서 API Keys 페이지를 열고 Key Type 열을 확인한다. 운영·스테이징·개발 환경이 하나의 키를 공유하고 있다면 환경별 키로 분리한다. 키 이름에는 서비스와 환경을 식별할 정보만 넣고 실제 키 값은 기록하지 않는다.

2026년 8월 17일 갱신된 Gemini API 키 공식 안내 에 따르면 AI Studio의 새 키는 서비스 계정에 연결된 Auth 키로 생성되고 Gemini API로 기본 제한된다. 제한 없는 Standard 키의 요청은 거부되며, 제한을 적용한 Standard 키도 2026년 9월부터 지원이 끝날 예정이지만 문서에는 정확한 시행일이 제시되지 않았다. Standard 키가 아직 작동하더라도 새 Auth 키를 만들어 애플리케이션을 이전하고 검증 후 기존 키를 취소하는 편이 안전하다.

Auth 키는 서비스 계정의 신원으로 요청을 처리하므로 공개 가능한 식별자가 아니다. 키 생성 권한을 모든 개발자에게 넓게 부여하지 말고, 연결된 서비스 계정에도 애플리케이션이 실제로 필요한 권한만 남긴다.

2단계: API와 호출 환경을 함께 제한한다

Auth 키는 Gemini API로 기본 제한되지만 설정을 직접 확인해야 한다. 기존 Standard 키가 Unrestricted로 표시된다면 AI Studio에서 Add restrictions를 선택한 뒤 Restrict to Gemini API only를 적용한다. 키가 다른 Google API에도 필요하다면 한 키에 서비스를 계속 추가하지 말고 용도별로 나눈다.

Google Cloud의 키 보안 지침 은 AI Studio용 키의 API 범위를 Gemini API로 한정하고 애플리케이션 제한도 적용하라고 권고한다. 애플리케이션 제한에는 웹사이트, IP 주소·대역, iOS 번들 ID, Android 패키지명과 인증서 지문이 있으며 한 키에는 한 종류만 선택할 수 있다. 따라서 서버, 웹, 모바일처럼 실행 조건이 다르면 키도 분리해야 사용량 추적과 사고 조사가 쉬워진다.

Gemini API를 호출하는 백엔드의 송신 IP가 고정돼 있다면 그 주소나 대역만 허용한다. 서버리스 환경처럼 송신 IP가 바뀔 수 있다면 실제 네트워크 구성을 먼저 확인해야 한다. 맞지 않는 IP를 임의로 등록하거나 전체 대역을 넓게 허용하면 제한의 효과가 사라진다.

저장 후에는 정상 호출만 시험하지 않는다. 해당 키로 허용하지 않은 API를 호출했을 때 실패하는지, 개발 환경이 운영 키에 의존하지 않는지, 허용 범위 밖의 출처에서 요청이 차단되는지도 확인한다.

3단계: 브라우저의 직접 호출을 백엔드 경유로 바꾼다

HTTP 리퍼러 제한은 브라우저에 포함된 키를 비밀로 바꾸지 않는다. 프런트엔드 소스, JavaScript 번들, 소스맵, 런타임 설정과 네트워크 요청에 들어간 값은 사용자가 살펴볼 수 있다. 빌드 과정에서 환경변수를 읽더라도 완성된 클라이언트 코드에 값이 삽입되면 노출된 것과 같다.

브라우저는 로그인 세션이나 애플리케이션용 토큰으로 자체 백엔드에 요청해야 한다. 백엔드는 사용자 권한과 입력을 검증하고 호출량을 제한한 뒤 서버에 보관된 Gemini API 키로 외부 요청을 보낸다. 브라우저에는 모델 응답과 필요한 오류 정보만 돌려주고 API 키, 인증 헤더 또는 내부 예외 전체를 반환하지 않는다.

• 프런트엔드 소스와 공개 환경변수에서 Gemini API 키를 제거한다.
• 브라우저의 네트워크 기록에서 Gemini API 엔드포인트로 직접 나가는 요청이 없는지 확인한다.
• 백엔드 엔드포인트에 인증, 사용자별 요청 한도와 최대 입력 크기를 적용한다.
• 오류 응답과 서버 로그에서 키와 인증 헤더를 마스킹한다.

4단계: 운영 키를 Secret Manager에 저장한다

운영 키는 Git 저장소, 컨테이너 이미지, Dockerfile, CI 설정 파일이나 협업 문서에 넣지 않는다. Secret Manager에 키 값을 등록하고 런타임 서비스 계정이 실행 중에 읽도록 구성한다. 배포 설정에는 실제 값 대신 비밀의 리소스 이름과 사용할 버전만 남긴다.

접근 권한은 런타임 서비스 계정에 필요한 비밀 단위로 부여한다. 개발자 전체나 프로젝트의 기본 서비스 계정에 광범위한 관리자 권한을 주면 비밀 저장소로 옮긴 효과가 줄어든다. 애플리케이션이 비밀을 읽지 못했을 때는 키 값을 오류에 출력하지 말고 안전하게 시작을 중단하도록 처리한다.

예측 가능한 배포와 롤백이 중요하다면 실행할 때마다 latest를 읽기보다 검증된 특정 비밀 버전을 배포 설정에 연결할 수 있다. 새 버전에 문제가 생겼을 때 이전 설정으로 되돌리기 쉽고, 모든 인스턴스가 검증되지 않은 값을 동시에 가져가는 위험도 줄어든다.

5단계: 노출 흔적을 찾고 새 키 검증 후 이전 키를 폐기한다

키가 브라우저, 공개 저장소, 이슈, 채팅 또는 빌드 로그에 한 번이라도 나타났다면 문자열만 삭제해서는 안 된다. 이미 복제되거나 캐시에 남았을 수 있으므로 노출된 자격 증명으로 취급한다. 현재 파일뿐 아니라 Git 이력, CI/CD 변수와 로그, 배포 산출물, 컨테이너 이미지, 소스맵과 오류 추적 서비스도 검사한다.

예방적 교체에서는 새 Auth 키에 필요한 제한을 먼저 적용하고 Secret Manager의 새 버전으로 등록한다. 일부 인스턴스에 배포해 정상 호출과 인증 오류를 확인한 뒤 전체 워크로드로 확대한다. Secret Manager의 교체 절차 도 새 비밀 버전을 배포한 뒤 모든 애플리케이션의 전환을 확인하고, 이전 버전을 비활성화해 문제가 없는지 살핀 다음 외부 시스템 등록 해제와 폐기를 진행하도록 안내한다.

1. 새 Auth 키를 만들고 필요한 API·애플리케이션 제한을 적용한다.
2. Secret Manager에 새 버전을 추가하고 백엔드 배포를 갱신한다.
3. 정상 호출, 인증 오류, 키별 사용량과 비용 변화를 확인한다.
4. 모든 인스턴스와 예약·배치 작업이 새 키를 사용하는지 확인한다.
5. 이전 키를 비활성화하고 의존성 문제가 없으면 취소하거나 삭제한다.

공개 저장소에서 키가 발견됐거나 비정상 사용이 진행 중이라면 무중단 교체보다 즉시 차단을 우선한다. 유출 키를 비활성화하거나 삭제한 뒤 새 키로 복구하고, Cloud Console에서 해당 키의 API 사용량과 비용을 조사한다. 완료 기준은 브라우저에 키가 없고 서버가 제한된 새 키만 읽으며 이전 키의 요청은 실패하는 상태다.

함께 읽기:

• Google ‘내 활동’ 자동 삭제, 브라우저 기록은 그대로 남는다
• Google AI Mode 호텔 예약 시작, 한국 이용자는 아직 기다려야 한다