Google Maps API 가격 계산법: 무료 범위, 과금 시작 구간, 헷갈리는 포인트 정리

Google Maps API 비용은 예전처럼 “월 200달러 크레딧이 있으니 대충 무료”라고 이해하면 바로 헷갈리기 쉽습니다. 지금은 SKU별 무료 사용량과 구간별 단가를 따로 봐야 해서, 어떤 기능을 쓰는지에 따라 체감 비용이 꽤 다르게 나옵니다.

특히 지도 표시만 하는지, 주소를 좌표로 바꾸는지, 자동완성까지 붙이는지에 따라 과금 시작 시점이 달라집니다. 실제 예산을 잡으려면 API 이름보다 “어떤 요청이 어떤 SKU로 잡히는지”부터 먼저 확인하는 편이 가장 덜 헷갈립니다.

Google Maps API 가격은 어떻게 계산될까

비용 계산은 생각보다 단순합니다. 먼저 한 달 동안 어떤 SKU가 몇 번 발생했는지 집계하고, 그 SKU의 무료 범위를 뺀 뒤, 남은 사용량에 구간별 단가를 적용하면 됩니다. 마지막으로 여러 SKU 비용을 합산하면 그 달의 총비용이 나옵니다.

계산 순서를 한 줄로 줄이면 “월간 SKU별 사용량 집계 → 무료 범위 차감 → 남은 사용량에 티어별 단가 적용 → SKU 합산”입니다. 여기서 중요한 점은 프로젝트별이 아니라 같은 결제 계정에 묶인 사용량이 합산된다는 점입니다.

가격표를 볼 때 먼저 봐야 하는 항목

가격표에서 먼저 확인할 것은 API 이름이 아니라 SKU 이름입니다. 예를 들어 지도 표시라도 Dynamic Maps인지, Maps Embed인지, Maps SDK인지에 따라 과금 방식이 달라집니다. Places 계열도 Autocomplete, Place Details, Text Search가 각각 따로 계산됩니다.

무료 범위는 SKU마다 따로 붙는다

가장 많이 쓰는 Essentials SKU는 월 10,000건 무료가 기본입니다. Pro는 5,000건, Enterprise는 1,000건이 기본이고, Map Tiles API 일부 SKU는 Essentials라도 월 100,000건 무료라서 일반 Essentials와 다르게 봐야 합니다.

위 표는 자주 비교하는 대표 예시만 추린 것입니다. 실제로는 같은 Places 계열 안에서도 어떤 필드를 요청하느냐에 따라 Essentials, Pro, Enterprise, Enterprise + Atmosphere로 나뉠 수 있어서 세부 호출 구조를 꼭 같이 봐야 합니다.

과금은 언제부터 시작될까

과금은 무료 범위를 넘는 순간부터 시작됩니다. 다만 “한 번 넘으면 전체 사용량이 전부 유료”가 아니라, 무료 범위까지는 0달러이고 초과분부터 해당 구간 단가가 붙는 방식입니다. 사용량이 더 커지면 다음 구간의 더 낮은 단가가 일부 적용됩니다.

간단한 계산 예시

예를 들어 Dynamic Maps가 한 달에 15,000 map loads 발생했다면 월 10,000건까지는 무료이고, 남은 5,000건에만 1,000건당 7달러가 붙습니다. 그러면 대략 35달러가 나옵니다. Geocoding이 20,000건이면 10,000건 무료 후 10,000건에 대해 1,000건당 5달러가 붙어 약 50달러로 계산하면 됩니다.

100,000건을 넘기면 구간 단가로 다시 나뉜다

월 사용량이 커지면 한 단가로 일괄 계산되지 않고 구간별로 쪼개서 계산됩니다. 예를 들어 Autocomplete Requests 200,000건처럼 규모가 커지면 10,000건 무료 이후 10,001~100,000 구간 단가와 100,001~500,000 구간 단가가 섞여 적용됩니다. 그래서 대형 서비스일수록 무료 범위보다 티어 구조를 먼저 보는 편이 정확합니다.

무료 범위에서 가장 헷갈리는 포인트

Google Maps API 가격이 어렵게 느껴지는 이유는 무료냐 유료냐의 이분법으로 보면 잘 안 맞기 때문입니다. 실제로는 “기능별 SKU, 무료 범위, 세션 처리, 필드 선택, 결제 계정 집계 방식”이 함께 맞물립니다. 아래 포인트만 정리해도 대부분의 혼란은 많이 줄어듭니다.

예전 월 200달러 크레딧과 지금 구조는 다르다

지금은 예전의 월 200달러 공통 크레딧 대신 SKU별 무료 사용량 구조로 이해하는 편이 맞습니다. 그래서 “대략 200달러까지 무료”처럼 계산하면 오차가 크게 날 수 있습니다. 대신 Dynamic Maps, Geocoding, Autocomplete처럼 각 SKU마다 따로 무료 사용량이 붙는다고 보는 편이 훨씬 정확합니다.

프로젝트를 여러 개 나눠도 무료 범위가 프로젝트별로 따로 늘지 않는다

가격 티어는 같은 결제 계정에 연결된 프로젝트 사용량을 합산해 계산합니다. 그래서 프로젝트를 기능별로 나눠도 비용 계산은 대개 결제 계정 기준으로 다시 합쳐집니다. 비용을 예측할 때는 프로젝트 수보다 어떤 SKU가 전체 합산으로 몇 건 나오는지를 봐야 합니다.

결제 계정이 없으면 사실상 무료 테스트도 거의 못 한다

무료 범위가 있다고 해도 결제 계정을 연결하지 않은 프로젝트는 Maps Platform API가 하루 1회 수준의 매우 낮은 제한으로 묶일 수 있습니다. 즉 “무료니까 카드 등록 없이 충분히 써보자”는 식으로 시작하면 바로 막히는 경우가 많습니다. 먼저 결제 계정 연결과 쿼터 설정을 같이 해두는 편이 안전합니다.

Autocomplete는 세션 처리 방식에 따라 체감 비용이 크게 달라진다

자동완성은 사용자가 타이핑할 때마다 요청이 쌓이기 때문에 구현 방식 차이가 비용에 크게 반영됩니다. 세션 토큰을 쓰지 않거나, 세션이 중간에 끊기거나, IDs Only로 종료하면 요청당 과금으로 돌아가기 쉽습니다. 반대로 세션을 제대로 묶고 필요한 Place Details 단계까지 연결하면 비용 구조가 훨씬 예측 가능해집니다.

Place Details는 필드 선택에 따라 SKU 등급이 올라갈 수 있다

장소 상세 정보도 단순 주소와 좌표만 받을 때와 영업시간, 평점, 리뷰, 분위기 정보까지 받을 때 비용이 달라집니다. 필요한 필드만 요청하지 않으면 Essentials로 끝낼 수 있는 호출이 Pro나 Enterprise 계열로 올라가 예산이 예상보다 커질 수 있습니다.

예산 알림은 과금을 멈춰주지 않는다

Cloud Billing 예산 알림은 “얼마쯤 썼는지 알려주는 기능”에 가깝고, 자동으로 과금을 막아주지는 않습니다. 실제로 비용을 더 강하게 통제하려면 API 쿼터 제한과 쿼터 알림을 함께 써야 합니다. 다만 쿼터를 너무 낮게 잡으면 서비스가 끊길 수 있어서 운영 상황에 맞는 선을 잡는 것이 중요합니다.

예산을 잡을 때 먼저 확인할 순서

처음 예산을 잡을 때는 “한 달 방문자 수”보다 “사용자 행동 1회당 어떤 SKU가 몇 번 호출되는지”를 먼저 적어보는 편이 정확합니다. 예를 들어 사용자가 페이지를 열 때 Dynamic Maps 1회, 주소 검색 중 Autocomplete 5회, 최종 선택 후 Place Details 1회가 발생한다면 이 흐름을 월간 사용자 수에 곱해보면 대략적인 비용 구조가 바로 보입니다.

그다음에는 무료 범위를 뺀 뒤, 월 100,000건을 넘길 가능성이 있는 SKU만 구간 단가까지 세부 계산하면 됩니다. 소규모 서비스는 무료 범위와 첫 단가만 봐도 충분한 경우가 많고, 사용량이 커질수록 구간별 blended pricing을 따져야 합니다.

지속적으로 같은 SKU를 많이 쓰는 서비스라면 고정형 구독도 검토할 만합니다. 다만 기본 구조는 여전히 SKU 중심이므로, 구독을 보더라도 먼저 어떤 SKU를 주로 쓰는지 파악해두는 것이 선행되어야 합니다.

참고자료(외부링크)

자주 묻는 질문

지도 기능을 붙일 때는 방문자 수보다 먼저 SKU 구조를 확인해두면, 무료 범위와 과금 시작 시점을 훨씬 안정적으로 읽을 수 있습니다.