n8n 구글맵 리드 생성 — ZIP코드와 업종으로 영업 리스트 자동 수집하기

n8n.io 공식 템플릿 마켓플레이스에 공개된 이 워크플로우를 가져오면, 시트에 ZIP코드와 업종 카테고리 목록만 채워두는 것으로 Google 지도에서 해당 지역·업종의 업체 정보를 자동 수집해 구글시트에 영업 리드로 정리하는 자동화를 만들 수 있습니다. 다만 여기서 쓰는 Google Places API는 호출량만큼 비용이 청구되는 유료 서비스라는 점을 먼저 짚고 시작합니다.

이 템플릿 하나로 보여줄 수 있는 것

영업이나 마케팅 직군을 지망한다면 면접에서 "리드는 어떻게 모으나요?"라는 질문을 받기 쉽습니다. 이 템플릿은 그 질문에 구체적인 사례로 답할 수 있게 해줍니다. "특정 지역과 업종을 조건으로 Google 지도 데이터를 자동 수집해서 영업 리드 시트를 만드는 워크플로우를 구성해봤습니다"라고 말할 수 있습니다.

짧은 문장이지만 안에 들어간 역량은 세 가지입니다.

• 유료 외부 API 연동 — 무료 API가 아니라 호출량만큼 비용이 발생하는 서비스를 연동하고, 비용 구조를 이해한 채로 설계한 경험
• 데이터 정제 — API가 돌려주는 원시 결과에서 필요한 값만 골라 필터링하고 중복을 제거해 시트에 정리한 경험
• 실패 대응 재시도 설계 — API 호출이 rate limit 등으로 실패했을 때 무작정 다시 부르지 않고, 대기 시간을 점점 늘려가며 재시도하는 로직(exponential backoff)을 다뤄본 경험

세 번째 역량이 특히 눈에 띕니다. 이 시리즈에서 지금까지 다룬 템플릿들은 API가 한 번에 응답한다고 가정했지만, 실제 서비스 운영에서는 호출이 너무 잦으면 API가 일시적으로 거절하는 상황이 흔합니다. 이 상황을 다루는 법을 알아두면 Google Places API뿐 아니라 사용량 제한이 있는 다른 외부 API를 쓰는 워크플로우 전반에 그대로 옮겨 쓸 수 있습니다.

이 템플릿은 무엇인가

이 워크플로우는 데이터팝콘이 만든 게 아닙니다. n8n 공식 템플릿 마켓플레이스(n8n.io/workflows)에 Generate leads with Google Maps라는 이름으로 공개된 템플릿이고, 제작자는 Alex Kim입니다. 카테고리는 Lead Generation으로 등록돼 있어서, 영업팀이 신규 고객 리스트를 만드는 용도로 자주 참고되는 사례입니다.

공식 설명에 따르면 이 템플릿은 Google Maps API를 자동으로 호출해 위치 데이터를 수집하고, 그 결과를 구글시트에 정리하는 워크플로우입니다. 미리 정해둔 ZIP코드와 업종 카테고리 목록을 기준으로 특정 지역의 업체 정보를 뽑아내며, 카드 미리보기에 나온 노드 이름은 Google Sheets, HTTP Request, If 세 개와 그 외 13개, 총 16개 노드로 구성돼 있다고 표기돼 있습니다.

n8n 설치나 기본 노드 조작법은 n8n으로 반복업무 자동화 포트폴리오 만들기에 정리돼 있으니, 이 글은 이 템플릿의 구조와 유료 API를 다루는 방식에 집중합니다.

구조 — Trigger / Task / Target

공식 페이지의 FEATURES와 SETUP 항목을 데이터팝콘 방식인 Trigger/Task/Target 세 칸으로 정리하면 이렇습니다.

• Trigger — 공식 SETUP 3번 항목에 "trigger intervals(manual or scheduled)"라고 적혀 있어서, 수동 실행과 스케줄 실행 둘 다 지원하도록 만들어져 있습니다. 실습 단계에서는 수동으로 돌려보고, 결과가 안정되면 스케줄로 바꾸는 순서가 자연스럽습니다.
• Task — 시트에서 ZIP코드와 카테고리를 읽고, 그 값으로 쿼리를 만들어 Google Places API(places.searchText 엔드포인트)를 호출합니다. 호출이 실패하면 If 노드가 이를 감지해 대기 후 재시도하고, 성공하면 결과를 필터링하고 중복을 제거합니다.
• Target — 정제된 결과는 구글시트에 리드 데이터로 쌓이고, 공식 설명에 있는 대로 처리 상태도 같은 시트 체계 안에 로그로 남습니다.

여기서 재시도 로직이 왜 필요한지 짚고 넘어갈 만합니다. 외부 API는 짧은 시간에 요청이 몰리면 일시적으로 거절 응답을 돌려주는 경우가 많은데, 이때 곧바로 다시 요청하면 같은 이유로 또 거절당하기 쉽습니다. exponential backoff는 재시도할 때마다 대기 시간을 일정하게 두지 않고 점점 늘리는 방식입니다(예를 들어 1초, 2초, 4초처럼). 이렇게 하면 API가 다시 요청을 받아줄 수 있는 상태로 회복될 시간을 벌면서도, 실패할 게 뻔한 재시도로 호출 횟수만 낭비하는 걸 막을 수 있습니다. 공식 페이지 NOTES에는 "robust error handling retries failed API calls with exponential backoff"라고만 적혀 있어 이 템플릿 안에서 정확히 어떤 노드가 대기 시간을 계산하는지까지는 확인할 수 없지만, 제작자 Alex Kim이 이 재시도 패턴만 따로 뽑아 "Exponential backoff for Google APIs"라는 별도 템플릿으로도 공개해뒀을 만큼, 이 기법은 이 워크플로우 하나에 그치지 않고 사용량 제한이 있는 API 전반에 재사용되는 패턴입니다.

만들기

비용 콜아웃 — Google Places API는 무료가 아닙니다

이 템플릿이 호출하는 places.searchText 엔드포인트는 Google Maps Platform 공식 가격 페이지 기준(2026년 8월)으로 Text Search Pro SKU에 매달 5,000회 무료 호출 한도가 있고, 그 이상은 1,000회당 32.00달러부터 시작해 월 누적 호출량 구간에 따라 단가가 내려가는 사용량 기반 과금입니다. ZIP코드와 업종 조합이 몇 개인지에 따라 한 번 전체 실행에서 API를 부르는 횟수가 달라지므로, 실습 단계에서는 ZIP코드와 카테고리를 적은 수로 시작해 호출량을 눈으로 확인한 뒤 범위를 넓히는 편이 안전합니다.

공식 SETUP 단계는 총 4개입니다. 순서는 그대로 두고 각 단계에서 무엇을 확인해야 하는지를 풀어씁니다.

1. 시트 두 개 준비하기

구글시트에 ZIP코드를 담을 시트 하나(공식 예시에서는 "AZ Zips")와, 업종 카테고리를 담을 시트 하나(공식 예시에서는 "Google Maps Categories")를 따로 만듭니다. 두 목록을 한 시트에 합치지 않고 분리해두는 이유는, 워크플로우가 두 목록을 조합해 "이 ZIP코드에서 이 업종을 찾아라"는 쿼리를 하나씩 만들어내기 때문입니다. 시트를 다 만들었으면 워크플로우의 Settings 노드에 이 시트의 URL을 입력합니다.

2. API 접근 설정하기

Google Cloud 콘솔에서 Maps API와 Sheets API를 함께 활성화한 프로젝트를 준비하고, 그 프로젝트로 n8n에 Google OAuth 크리덴셜을 등록합니다. 이 단계에서 놓치기 쉬운 부분이 하나 있는데, 공식 문서는 "API 키가 places.searchText 엔드포인트에 접근 가능한지 확인하라"고 별도로 강조합니다. Maps API를 활성화했다고 해서 모든 하위 엔드포인트가 자동으로 열리는 게 아니라서, 이 확인을 건너뛰면 크리덴셜은 정상인데 요청만 거절당하는 상황을 만나게 됩니다.

3. 쿼리와 실행 주기 맞추기

GMaps API를 호출하는 노드에서 textQuery 파라미터를 자신이 찾으려는 조건에 맞게 조정합니다. 그다음 트리거를 수동으로 둘지, 일정 주기로 자동 실행할지 정합니다. 처음 몇 번은 수동 실행으로 결과와 호출량을 확인한 뒤 스케줄로 바꾸는 순서를 권합니다.

4. 실행하고 시트 확인하기

워크플로우를 실행하면 됩니다. 한 번 실행으로 끝내지 않고 주기적으로 돌려 데이터를 최신 상태로 유지하고 싶다면 3번에서 정한 스케줄을 그대로 켜두면 됩니다. 실행이 끝나면 시트에 새로 추가된 행과, 실패해서 재시도가 걸렸던 항목의 상태 로그를 함께 확인하는 습관을 들이는 게 좋습니다.

주의할 점 · 제약

공식 문서와 가격 페이지를 근거로 정리하면 이 템플릿의 제약은 세 가지입니다.

• 사용량 기반 과금 — 위 콜아웃에서 다룬 대로 무료 호출 한도를 넘으면 호출당 비용이 청구됩니다. ZIP코드나 카테고리 목록을 늘릴수록 한 번 실행에 드는 호출 수도 함께 늘어난다는 점을 감안해 범위를 정해야 합니다.
• 시트 두 개 구성이 전제 — ZIP코드 시트와 카테고리 시트를 분리해두고, 그 URL을 워크플로우 안 Settings 노드에 지정하는 구조입니다. 이 구성 없이 임의로 시트 하나에 모든 값을 몰아넣으면 워크플로우가 기대하는 입력 형태와 어긋납니다.
• API 접근 범위를 별도로 확인해야 함 — Maps API와 Sheets API를 활성화하는 것과, places.searchText 엔드포인트 접근 권한을 확인하는 것은 별개 절차입니다. 하나만 해두고 나머지를 빠뜨리기 쉬운 지점입니다.

포트폴리오·면접 포인트

포트폴리오에는 ZIP코드 몇 개와 업종 하나로 실행한 결과, 즉 시트에 새로 쌓인 리드 행과 처리 상태 로그를 캡처해두면 됩니다. 여기에 실제 호출 횟수와 그에 따른 예상 비용을 함께 적어두면, "동작한다"만 보여주는 사람과 "얼마가 드는지 알고 만들었다"를 보여주는 사람이 갈립니다.

면접에서는 "왜 재시도를 고정 간격이 아니라 점점 늘어나는 간격으로 했나요?"라는 질문이 나올 수 있습니다. 답은 이렇습니다. API가 이미 요청을 거절하고 있는 상태에서 같은 간격으로 계속 두드리면 회복할 시간을 주지 않은 채 실패만 반복하고, 그만큼 쓸데없는 호출 횟수도 쌓여 비용으로 이어집니다. 대기 시간을 늘려가며 재시도하면 API가 정상으로 돌아올 시점까지 기다리면서도 전체 재시도 횟수를 줄일 수 있습니다. 이 답을 할 수 있으면 노드를 따라 만든 사람이 아니라 API의 동작 방식을 이해하고 설계한 사람이라는 인상을 줍니다.

다음 액션

다음 편에서는 같은 마켓플레이스에 공개된, 아웃룩 이메일을 AI가 자동으로 분류해주는 템플릿을 다룹니다. 이번 편에서는 유료 API의 사용량과 재시도를 다뤘다면, 다음 편은 로컬에서 도는 LLM을 붙여 API 호출 비용 자체를 없애는 선택지를 보여줍니다. 유료와 무료, 두 방식을 한 번씩 다뤄보면 상황에 맞는 쪽을 스스로 고를 수 있게 됩니다.