Google Maps API를 처음 붙인 뒤 가장 먼저 막아야 하는 문제는 두 가지입니다. 하나는 브라우저 콘솔이나 깃 저장소, 배포 설정에서 키가 노출되어 제3자가 무단으로 호출하는 경우이고, 다른 하나는 정상 트래픽이 늘었는데도 알림과 한도가 없어 과금이 뒤늦게 커지는 경우입니다.
안전한 기본값은 키를 애플리케이션별로 나누고, 사용 위치에 맞는 제한을 걸고, 예산 알림과 쿼터를 따로 설정하는 순서입니다. 웹사이트에서 쓰는 키와 서버에서 쓰는 키를 한 개로 섞어 두면 제한을 제대로 걸기 어려워지고, 문제가 생겼을 때 어디서 비용이 났는지도 추적하기 힘들어집니다.
먼저 정리할 원칙: 키 하나로 모든 곳을 처리하지 않기
Google은 API 키에 애플리케이션 제한과 API 제한을 함께 거는 방식을 권장합니다. 실무에서는 여기에 한 단계 더해 웹 프론트엔드, 서버 백엔드, Android, iOS를 각각 다른 키로 분리해 두는 편이 안전합니다. 키가 하나만 유출돼도 전체 서비스가 같이 흔들리지 않고, 환경별 사용량과 장애 원인을 따로 볼 수 있기 때문입니다.
가장 먼저 나눌 기준
- 브라우저에서 지도를 띄우는 웹사이트용 키
- 서버에서 Geocoding·Places·Routes 같은 요청을 보내는 백엔드용 키
- Android 앱용 키
- iOS 앱용 키
- 개발용과 운영용을 구분한 환경별 키
기존 운영 키를 바로 잠그기 전에 확인할 것
이미 서비스 중인 키라면 먼저 Metrics와 사용 현황을 확인해 현재 어떤 API와 어떤 호출 위치에서 쓰이고 있는지 본 뒤 제한을 적용하는 편이 안전합니다. 사용 중인 키에 제한을 바로 걸면 정상 요청까지 함께 막혀 지도나 검색 기능이 갑자기 끊길 수 있습니다.
도메인 제한과 IP 제한은 언제 다르게 써야 할까
핵심은 호출이 시작되는 위치입니다. 브라우저에서 직접 호출하면 웹사이트 제한을, 서버에서 REST 요청을 보내면 IP 제한을 거는 방식이 기본입니다. 여기에 반드시 API 제한까지 더해 필요한 제품만 허용해야 무단 사용 범위를 줄일 수 있습니다.
웹사이트에서 직접 쓰는 경우: HTTP referrer 기반 웹사이트 제한
Maps JavaScript API, Maps Embed API, 브라우저에서 호출되는 일부 웹 기능은 웹사이트 제한이 맞습니다. 보통 운영 도메인, 서브도메인, 필요하면 스테이징 도메인까지 등록합니다. 예를 들어 example.com만 운영 중인데 와일드카드를 과하게 열어 두면 예상하지 못한 하위 도메인에서도 키가 살아 있을 수 있어 범위가 넓어집니다.
권장 방식은 운영 도메인과 테스트 도메인을 분리하고, 실제로 필요한 도메인만 정확히 등록하는 것입니다. 웹사이트 제한을 건 뒤에는 API 제한에서 Maps JavaScript API처럼 현재 화면에 꼭 필요한 API만 선택해 두는 편이 안전합니다.
서버나 백엔드에서 쓰는 경우: IP 주소 제한
Geocoding API, Places API, Routes API 같은 웹 서비스 요청을 서버에서 보내는 구조라면 IP 제한이 기본입니다. 이때는 프론트엔드에 서버 키를 노출하지 않고, 고정 공인 IP 또는 허용된 CIDR 대역만 등록해야 합니다. 서버리스나 오토스케일 환경처럼 나가는 IP가 자주 바뀌는 구조라면 NAT나 고정 egress IP를 먼저 정리한 뒤 제한을 거는 편이 현실적입니다.
모바일 앱은 패키지명·번들 ID 제한
Android는 패키지명과 SHA-1 인증서 지문, iOS는 번들 ID 기반 제한을 사용합니다. 모바일 키를 웹이나 서버에서 재사용하지 말고 플랫폼별로 분리해 두면 배포와 회수, 문제 추적이 훨씬 쉬워집니다.
정적 지도 이미지나 Street View 이미지를 많이 쓰는 경우
Maps Static API와 Street View Static API는 키 제한만으로 끝내지 말고 디지털 서명까지 함께 검토하는 편이 좋습니다. 정적 이미지 URL이 외부에 공유되기 쉬운 구조라면 키와 서명을 함께 관리하는 방식이 노출 범위를 줄이는 데 도움이 됩니다.
과금 사고를 막는 설정: 예산 알림과 쿼터 보호는 역할이 다릅니다
비용 통제에서 가장 자주 생기는 오해는 예산 알림만 켜 두면 요금이 자동으로 멈춘다고 생각하는 경우입니다. 예산 알림은 비용 추세를 알려 주는 장치이고, 쿼터 제한은 요청량 상한을 정하는 장치입니다. 둘은 같이 써야 효과가 납니다.
출처: Google Maps Platform 비용 관리
예산 알림: 비용이 커지는 흐름을 빠르게 알아차리기
Cloud Billing의 Budgets & alerts에서는 월간 기준 금액을 정하고, 실제 비용이나 예측 비용이 특정 비율에 도달했을 때 이메일 알림을 받을 수 있습니다. 다만 예산을 만들었다고 해서 Maps 호출이나 청구가 자동으로 중단되지는 않습니다. 그래서 비용 감시는 예산 알림으로, 실제 차단은 쿼터나 호출 구조 변경으로 나눠 생각하는 편이 정확합니다.
쿼터 제한: 요청량 상한을 걸어 폭주를 멈추기
Google Maps Platform의 Quotas 화면에서는 API별 요청 한도를 조정하고 사용량 알림을 만들 수 있습니다. 쿼터를 너무 낮게 잡으면 정상 사용자도 에러를 보게 되지만, 한도가 전혀 없으면 스크립트 오작동이나 무단 사용이 발생했을 때 비용이 빠르게 늘 수 있습니다. 운영 초반에는 평소 사용량보다 약간 여유 있는 수준으로 시작하고, 트래픽 패턴을 보면서 단계적으로 조정하는 편이 무난합니다.
추천 순서: 처음 연결한 날 바로 해두면 좋은 설정
- 웹용 키와 서버용 키를 분리합니다.
- 각 키에 애플리케이션 제한을 먼저 겁니다.
- 각 키에 실제로 쓰는 API만 API 제한으로 허용합니다.
- Cloud Billing에서 월 예산과 알림 임계값을 설정합니다.
- Quotas에서 핵심 API의 사용량 알림과 상한을 확인합니다.
- Metrics와 Billing 보고서에서 하루 단위 변화가 이상한지 점검합니다.
설정 후 꼭 확인해야 하는 점검 포인트
제한을 저장한 뒤 바로 끝내기보다 실제 페이지와 서버 로그를 함께 확인하는 과정이 중요합니다. 웹은 운영 도메인과 비운영 도메인에서 각각 정상 동작하는지, 서버는 허용 IP에서만 요청이 성공하는지, 모바일은 빌드 서명 정보가 맞는지 확인해야 합니다. 그리고 예상보다 호출이 빨리 늘어나면 API 종류별 사용량, 배포 시점, 마케팅 유입 시점이 맞물렸는지 함께 보는 편이 원인 파악에 유리합니다.
자주 막히는 실수
- 브라우저용 키와 서버용 키를 같은 값으로 사용하기
- API 제한 없이 애플리케이션 제한만 걸어 두기
- 운영 키를 깃 저장소, 클라이언트 코드, 테스트 페이지에 오래 남겨 두기
- 예산 알림만 만들고 쿼터 상한은 비워 두기
- 기존 운영 키의 사용처를 보지 않고 제한부터 걸어 정상 트래픽까지 끊기게 만들기
웹에서 한 단계 더 보강하고 싶을 때
Maps JavaScript API나 Places API를 웹 환경에서 쓴다면 App Check 같은 추가 보호 수단도 검토할 만합니다. 키 제한만으로는 막기 어려운 비정상 호출을 줄이는 데 도움이 될 수 있어, 공개 웹앱이나 트래픽 변동이 큰 서비스에서 특히 유용합니다.
무엇부터 하면 좋을까
지금 바로 하나만 먼저 해야 한다면, 현재 쓰는 키를 웹용과 서버용으로 나누고 각 키에 애플리케이션 제한과 API 제한을 함께 거는 일부터 시작하는 편이 좋습니다. 그 다음 단계로 예산 알림을 만들고, 마지막으로 핵심 API의 쿼터와 사용량 알림을 조정하면 보안과 비용 통제를 한 번에 정리하기 쉽습니다.
참고자료(외부링크)
자주 묻는 질문
키 제한은 보안 설정이고, 예산 알림과 쿼터는 비용 설정입니다. 이 둘을 같이 묶어 두면 Google Maps API를 훨씬 오래 안정적으로 운영하기 쉽습니다.
댓글