n8n Calendly 링크 자동생성 — 웹훅 요청 하나로 1회용 예약 링크 만들기

n8n.io 공식 템플릿 마켓플레이스에 공개된 워크플로우를 가져오면, 이름과 이메일을 담은 웹훅 요청 하나만 보내도 1회용 Calendly 예약 링크가 자동으로 만들어지고 구글시트에 기록되고 슬랙 알림까지 옵니다. 세일즈팀이 잠재고객마다 Calendly에서 직접 링크를 만들고 누구에게 보냈는지 따로 기록하던 수작업이, 다른 도구에서 API 하나 호출하는 일로 줄어듭니다.

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

면접에서 "n8n으로 뭘 만들어봤어요?"라는 질문에, 이 템플릿은 흔한 대답과는 다른 방향으로 답할 수 있게 해줍니다. "저는 n8n 워크플로우를 다른 서비스가 호출할 수 있는 API처럼 설계해봤습니다"라고 말할 수 있습니다.

n8n을 처음 배우면 대부분 구글시트를 읽어서 슬랙으로 보내는 것처럼, n8n 안에서 시작하고 n8n 안에서 끝나는 흐름을 만듭니다. 이 템플릿은 반대입니다. 시작점이 n8n 캔버스가 아니라 웹훅(Webhook Trigger)이고, 이 웹훅은 CRM이든 랜딩페이지 폼이든 curl 명령이든 상관없이 정해진 형식의 POST 요청만 오면 반응합니다. n8n 워크플로우 하나가 "이름과 이메일을 보내면 예약 링크를 돌려주는 마이크로서비스"로 동작하는 셈입니다. 이 설계 패턴 자체가 이 템플릿에서 가장 배울 만한 부분입니다.

여기에 딸려오는 역량은 두 가지 더 있습니다.

• 외부 API 체이닝 — Calendly API를 한 번이 아니라 세 번(현재 사용자 조회 → 이벤트 타입 조회 → 스케줄링 링크 생성) 순서대로 호출해 하나의 결과로 조합해본 경험
• 선택적 로직 설계 — 구글시트 기록과 슬랙 알림처럼 없어도 핵심 기능은 동작하지만 있으면 운영에 도움이 되는 단계를, 본 흐름과 분리해 선택적으로 붙여본 경험

이 세 가지는 Calendly뿐 아니라 다른 시스템에서 요청이 오면 n8n이 처리해서 결과를 돌려주는 유형의 자동화 전부에 그대로 쓰입니다. 웹훅으로 시작하는 워크플로우를 한 번 설계해보면, 그다음부터는 트리거가 무엇으로 바뀌든 구조를 그대로 재사용할 수 있습니다.

이 템플릿은 무엇인가

이 워크플로우는 데이터팝콘이 만든 게 아닙니다. n8n 공식 템플릿 마켓플레이스(n8n.io/workflows)에 Generate single-use personalized Calendly links with Google Sheets tracking & Slack alerts라는 이름으로 공개된 템플릿이고, 제작자는 Omer Fayyaz입니다. 카테고리는 CRM으로 등록돼 있습니다.

공식 설명에 따르면 이 템플릿은 "Calendly Booking Link Generator"로, 1회용 개인화 예약 링크를 만들고 구글시트에 로그를 남기고 원하면 슬랙으로도 알리는 워크플로우입니다. 공식 문서는 이 템플릿이 세일즈·SDR팀(잠재고객마다 다른 링크), 고객성공·서포트팀(리스케줄이나 후속 콜용 프리필 링크), 마케팅·그로스팀(UTM이 붙은 캠페인 링크), Ops·RevOps팀(모든 링크의 중앙 기록)에게 쓸모 있다고 소개합니다.

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

구조 — Trigger / Task / Target

공식 문서의 "How it works"를 데이터팝콘 방식인 Trigger/Task/Target 세 칸으로 정리하면 이렇습니다.

• Trigger — 외부에서 오는 POST 요청 하나입니다. 필수 값은 이름과 이메일이고, event_type_uri와 utm_source는 선택 값입니다. Set Configuration 노드가 비어 있는 값에 기본값(utm_source는 "n8n")을 채워 넣습니다.
• Task — Calendly API로 현재 사용자 정보를 조회하고, 그 사용자의 활성 이벤트 타입 목록을 가져옵니다. 요청에 event_type_uri가 있으면 그 타입을 쓰고, 없으면 목록의 첫 번째 활성 타입을 그대로 씁니다. 이렇게 정해진 이벤트 타입으로 max_event_count=1인 스케줄링 링크를 만든 다음, 기본 예약 URL에 이름·이메일·UTM 파라미터를 쿼리스트링으로 붙여 개인화된 링크를 완성합니다.
• Target — 하나의 실행이 세 갈래로 갈라집니다. 완성된 링크와 수신자·이벤트 정보를 구글시트 "Generated Links" 탭에 한 행으로 남기고(선택), 포맷된 메시지를 슬랙 채널로 보내고(선택), 마지막으로 요청을 보낸 쪽에 JSON 응답을 돌려줍니다(필수).

만들기

공식 문서가 정리한 준비물은 세 가지입니다. 활성 이벤트 타입이 최소 1개 있는 Calendly 계정, 퍼블릭 웹훅에 접근 가능한 n8n 인스턴스, 그리고 Calendly OAuth2 인증정보입니다. 구글시트와 슬랙은 선택 사항입니다. 공식 Setup은 5단계로 나뉘어 있고, 순서는 그대로 두고 각 단계에서 무엇을 확인해야 하는지를 풀어씁니다.

1. Calendly OAuth2 앱 만들기

calendly.com/integrations 또는 developer.calendly.com에서 OAuth2 앱을 만듭니다. 여기서 발급되는 client ID, client secret, redirect URL 세 가지를 n8n의 Calendly OAuth2 인증정보에 등록하면, 뒤에 나오는 API 호출 노드들이 이 인증정보를 함께 씁니다.

2. Webhook Trigger 설정

Webhook Trigger 노드에서 Method는 POST, Path는 generate-calendly-link로 둡니다. Response Mode는 Respond to Webhook 노드가 응답을 대신 만들도록 Response Node로 설정합니다. 워크플로우를 Active로 켜면 그때 나오는 Production URL이 실제로 호출할 주소입니다. 테스트 요청 바디는 아래 형태입니다.

{
  "name": "John Doe",
  "email": "[email protected]",
  "event_type_uri": "optional",
  "utm_source": "optional"
}

name과 email만 있으면 요청은 성립하고, event_type_uri와 utm_source는 비워도 됩니다.

3. 구글시트 연결 (선택)

구글시트에 "Generated Links"라는 이름의 시트나 탭을 만들고, 헤더 행에 Recipient Name, Recipient Email, Event Type, Duration (min), Booking URL, Created At, Status 7개 컬럼을 넣습니다. Google Sheets OAuth2 인증정보를 등록한 뒤, 로그를 남기는 노드에 documentId와 sheetName을 이 시트로 지정합니다.

4. 슬랙 연결 (선택)

슬랙 앱을 하나 만들고 chat:write 스코프와 channels:read 또는 groups:read 스코프를 봇에 부여한 다음 워크스페이스에 설치해 봇 토큰을 발급받습니다. 알림을 보내는 노드에 채널 ID를 지정하면, 세일즈팀 채널로 링크 생성 알림이 옵니다.

5. 엔드투엔드 테스트

워크플로우를 Active로 켜고, Postman이나 curl로 2번 단계의 테스트 바디를 Production URL에 POST해봅니다. 응답으로 booking_url이 돌아오는지, 구글시트에 행이 추가됐는지, 슬랙 채널에 메시지가 왔는지 세 가지를 확인하면 설정이 끝납니다.

공식 문서는 이 5단계와 별도로 커스터마이징 여지도 안내합니다. 웹훅 바로 뒤에 IF 노드를 붙여 입력값을 검증하는 방법, 이벤트 타입이 여러 개일 때 가장 길거나 짧은 시간을 기준으로 고르는 폴백 로직, UTM 파라미터를 더 추가하는 방법, 구글시트에 담당 세일즈나 캠페인, 파이프라인 단계 같은 컬럼을 늘리는 방법을 예로 듭니다.

주의할 점 · 제약

공식 문서 기준으로 이 템플릿을 그대로 쓸 때 알아둬야 할 점은 다음과 같습니다.

• 활성 이벤트 타입이 필수 — Calendly 계정에 활성 이벤트 타입이 최소 1개는 있어야 합니다. 없으면 이벤트 타입 조회 단계에서 가져올 목록 자체가 비어, 뒤의 링크 생성 단계가 진행되지 않습니다.
• 퍼블릭 웹훅 접근이 요구사항 — 공식 Requirements에 "n8n instance with public webhook access"가 명시돼 있습니다. 외부에서 호출 가능한 주소가 아니면 이 워크플로우 자체가 성립하지 않습니다.
• 이벤트 타입 미지정 시 첫 번째 활성 타입 자동 선택 — 요청에 event_type_uri를 안 넣으면 목록의 첫 번째 활성 이벤트 타입이 그대로 선택됩니다. 이벤트 타입이 여러 개인 계정이라면 의도와 다른 타입으로 링크가 만들어질 수 있어, 확실히 하려면 요청에 event_type_uri를 직접 넣는 편이 안전합니다.
• 기본 입력 검증은 안내 대상 — 공식 문서는 커스터마이징 항목으로 웹훅 바로 뒤에 IF 노드를 붙여 입력값을 검증하라고 권장합니다. 이 권장이 별도로 있다는 것은, 기본 구성에는 이름·이메일 형식을 확인하는 단계가 끼어 있지 않다는 뜻으로 읽힙니다.
• 에러가 나도 흐름은 끊기지 않음 — 공식 문서는 HTTP 요청 노드들이 continueRegularOutput 옵션으로 설정돼 있어, API 호출 중 하나가 실패해도 워크플로우 전체가 하드 실패로 끝나지 않는다고 설명합니다. 다만 이는 실패가 조용히 넘어갈 수도 있다는 뜻이라, 실행 로그를 확인하는 습관이 필요합니다.
• 링크 만료 안내 — 응답 JSON에는 "Single-use or 90 days"라는 만료 안내가 담겨 있다고 공식 문서에 되어 있습니다. 정확한 만료 정책은 계정별 Calendly 설정에 달려 있으므로, 실제 값은 자신의 계정에서 직접 확인하는 편이 정확합니다.

포트폴리오·면접 포인트

공식 문서는 이 템플릿의 활용 예시로 세 가지 시나리오를 듭니다. 이 중 두 개를 포트폴리오 설명에 그대로 가져다 쓸 수 있습니다.

첫째는 세일즈 아웃리치입니다. CRM에서 리드 단계가 "미팅 요청됨"으로 바뀌는 순간 이 웹훅을 호출해 링크를 만들고, CRM이 그 링크를 리드에게 메일로 보내는 구조입니다. 영업 프로세스의 한 단계를 자동화 트리거로 연결해봤다는 설명이 가능해집니다.

둘째는 캠페인 트래킹입니다. 마케팅 도구가 연락처마다 utm_source를 붙여 이 웹훅을 호출하면, 나중에 구글시트에 쌓인 기록으로 어떤 캠페인이 실제 예약으로 이어졌는지 분석할 수 있습니다. 이 시나리오는 자동화를 만들었다는 데서 그치지 않고, 그 자동화로 마케팅 성과를 측정할 수 있게 했다는 한 단계 더 나아간 이야기가 됩니다.

포트폴리오에는 curl 명령으로 웹훅을 호출하는 화면, 응답으로 돌아온 booking_url, 구글시트에 쌓인 행, 슬랙에 도착한 알림까지 네 장이면 충분합니다.

면접에서는 "Calendly에서 그냥 링크 만들면 되는데 왜 n8n을 거쳤나요?"라는 질문이 나올 수 있습니다. 답은 명확합니다. Calendly 화면에서는 잠재고객마다 다른 1회용 링크를 만들고, 누구에게 보냈는지 기록하고, 팀에 알리는 과정을 전부 손으로 반복해야 합니다. 이 워크플로우는 그 세 가지를 요청 한 번으로 묶었고, 무엇보다 다른 도구가 API처럼 호출할 수 있게 만들었다는 점이 핵심입니다. 이런 답을 할 수 있으면, 노드 연결법이 아니라 시스템 사이의 인터페이스를 설계했다는 인상을 줍니다.

다음 액션

다음 편은 Jamf Pro로 관리하는 기업 기기의 패치 현황을 슬랙으로 요약해 보고하는 템플릿으로 넘어갑니다. 이번 편이 웹훅으로 요청을 받아 즉시 응답하는 구조였다면, 다음 편은 반대로 예약된 시간마다 외부 시스템의 상태를 조회해 사람에게 보고하는 구조라 트리거의 방향 자체가 달라집니다.