자동화가 바로 안 도는 이유 — 웹훅과 폴링 차이, Zapier·Make 플랜별 실행 주기 정리

자동화를 만들어 놓고 테스트를 눌렀는데 아무 일도 안 일어나면 제일 먼저 설정을 의심하게 되거든요. 조건을 다시 보고, 필드를 다시 맞추고, 앱 연결을 끊었다 다시 붙이고요. 그러다 몇 분 뒤에 알림이 툭 오면 허탈해져요. 고친 게 없는데 갑자기 돌았으니까요.

결론부터 말하면, 이건 고장이 아니라 실행 주기예요. 자동화 도구의 트리거는 두 종류로 나뉘어요. 하나는 도구가 주기적으로 앱에 "새 거 있어?"라고 물어보는 폴링이고, 다른 하나는 앱이 사건이 생긴 순간 도구에 알려주는 웹훅이에요. 폴링이면 다음 확인 시각이 와야 움직이니까 그만큼 늦어요. 다만 그 주기는 도구와 플랜에 따라 다르고, 내가 바꿀 수 있는 폭도 문서마다 다르게 적혀 있어요. 그래서 공식 문서에 실제로 적힌 값만 모아 정리했어요.

자동화가 바로 안 도는 이유는 대개 트리거 종류예요

Zapier 공식 도움말은 트리거를 이렇게 정의해요. 트리거는 Zap을 시작시키는 앱 안의 사건이고, Zap을 켜 두면 Zapier가 그 사건을 기다린다고요. 그리고 트리거에는 폴링과 인스턴트 두 종류가 있다고 곧바로 나눠요.

폴링 쪽 설명은 이래요. 폴링 트리거에서는 Zapier가 주기적으로 앱에 데이터를 요청하고, 앱은 최신 데이터를 돌려줘요. 도움말은 대부분의 트리거가 폴링 트리거이며 정해진 간격으로 앱을 확인한다고 적고, 그 간격이 플랜에 달려 있다고 덧붙여요.

여기서 지연이 생겨요. 앱에서 사건이 일어난 시각과 도구가 확인하러 가는 시각이 서로 무관하거든요. 새 문의가 접수된 직후에 확인이 돌면 거의 즉시처럼 보이고, 확인이 막 지나간 직후에 접수되면 다음 확인까지 통째로 기다려야 해요. 같은 자동화인데 어떤 날은 빠르고 어떤 날은 느린 이유가 이거예요.

Zapier가 따로 만들어 둔 지연 안내 문서도 같은 곳을 첫 번째 원인으로 지목해요. Zap이 폴링 트리거를 쓰고 있고 폴링 간격이 생각보다 길다는 항목이에요. 그러니 자동화가 늦다고 느껴지면 조건이나 필드를 뜯기 전에 트리거 종류부터 확인하는 순서가 맞아요.

웹훅과 폴링은 뭐가 다른가요

한 문장으로 줄이면 이래요. 폴링은 내가 물어보러 가는 방식이고, 웹훅은 상대가 알려주는 방식이에요.

Zapier 도움말은 인스턴트 트리거를 이렇게 설명해요. 인스턴트 트리거에서는 앱이 트리거 사건이 일어날 때마다 웹훅을 이용해 새 데이터를 자동으로 보내주고, 웹훅은 앱 사이에 오가는 자동 알림이라고요. 그래서 Zapier는 API에 새 데이터가 있는지 물어볼 필요가 없다고 적혀 있어요.

Make 쪽 설명도 같은 대비를 써요. 웹훅은 보통 인스턴트 트리거로 동작하며, 정해진 주기마다 서비스에 새 데이터를 물어보는 예약 트리거와 대비된다고 적어요. 그리고 웹훅 URL이 요청을 받은 직후에 시나리오가 실행된다고 덧붙이고요.

표에서 제일 중요한 칸은 마지막 두 줄이에요. 내가 만든 자동화가 어느 쪽인지 화면에서 바로 알 수 있다는 뜻이거든요. Zapier는 인스턴트 트리거를 쓰는 Zap 워크플로에 에디터에서 번개 아이콘을 띄워요. Make는 앱의 모듈 목록에서 인스턴트 트리거에 instant 라벨을 붙여 두고요.

자동화 실행 주기, 플랜에 따라 얼마나 달라지나요

자동화 실행 주기는 도구와 플랜이 함께 정해요. Zapier 공식 도움말이 싣고 있는 플랜별 폴링 간격은 Free 15분, Professional 2분, Team 1분, Enterprise 1분이에요. Make는 스케줄 패널 설명에서 시나리오가 기본으로 15분마다 실행된다고 안내하고, 최소 간격은 플랜에 따라 달라진다며 가격 페이지를 가리켜요. 그 비교표에는 예약된 시나리오 사이의 최소 간격 항목이 있고 Free 15분, Core와 Pro와 Teams와 Enterprise는 1분으로 적혀 있어요.

두 도구의 값이 같은 뜻은 아니에요. Zapier의 숫자는 도구가 앱을 확인하러 가는 주기이고, Make의 숫자는 내가 시나리오 스케줄에 넣을 수 있는 간격의 하한이에요. Zapier는 도구가 정해 주는 값이고 Make는 내가 고르되 그 아래로는 못 내려가는 값이라고 보면 이해가 빨라요.

체감으로 옮기면 이래요. Zapier 지연 안내 문서는 Free 플랜이라면 앱에 새 항목을 만들어도 그 정보가 Zap에 닿기까지 최대 15분이 걸릴 수 있다고 적어요. 상담 문의 알림처럼 몇 분이 아쉬운 자동화라면 이 15분이 그대로 응대 지연이 되는 셈이에요.

Zapier에서 폴링 간격을 직접 바꿀 수 있나요

여기가 이 글에서 제일 조심해서 읽어야 할 대목이에요. 같은 회사의 공식 문서인데 대상 플랜을 다르게 적고 있거든요.

커스텀 폴링 간격을 다루는 문서 하나는 Enterprise 플랜을 조건으로 적어요. Enterprise 플랜이라면 기본 1분 폴링 간격을 그대로 두거나, 1분 단위로 최대 15분까지 간격을 조정할 수 있다는 안내예요. 반면 트리거 개요 문서는 Pro와 Team과 Enterprise 플랜이라면 폴링 트리거가 얼마나 자주 확인하는지 바꿀 수 있다고 적고, 지연 안내 문서도 Pro와 Team과 Enterprise 사용자가 각 Zap의 폴링 트리거 실행 시점을 바꿀 수 있다고 적어요. 실행 제어 문서의 플랜 비교표 역시 Professional과 Team과 Enterprise에 표시가 들어가 있고요.

어느 쪽을 기준으로 삼을지는 문서의 성격을 보면 갈려요. Enterprise만 적은 쪽은 기능 하나를 전담해 설명하는 레퍼런스가 아니라 2023년 5월 제품 업데이트 공지예요. 문서 경로 표시가 제품 업데이트 목록 아래에 놓여 있고, 본문 첫 문장도 새 기능을 알리는 인사말로 시작해요. 게다가 문서 스스로 상단에 게시 시점 기준의 정보이니 최신 업데이트 공지를 확인하라고 적어 두었어요. 반면 트리거 개요 문서와 지연 안내 문서, 실행 제어 문서는 그런 시점 고지 없이 기능을 설명하는 쪽이고, 셋 다 유료 플랜을 조건으로 적어요. 그래서 이 글은 현행 문서 쪽, 그러니까 유료 플랜에서 바꿀 수 있다는 서술을 기준으로 잡았어요. 한국어 블로그에서 흔히 보이는 "특정 플랜부터 된다"는 식의 요약은 어느 문서를 봤는지에 따라 갈리니 그대로 믿지 마시고, 실제로 내 계정 화면에 그 설정이 보이는지로 확인하는 편이 확실해요.

Zapier에는 실행 시점을 다루는 다른 도구도 있어요. 스케줄 트리거는 매월, 매주, 매일, 매시간 단위로 Zap을 돌릴 수 있고 분기나 연 단위 같은 맞춤 간격도 지정할 수 있어요. Delay 도구는 반대로 붙잡아 두는 쪽이에요. 액션 단계를 실행하기 전에 지정한 시간만큼 Zap을 대기 상태로 두는 도구이고, 지정 시간만큼 미루기와 특정 시각까지 미루기, 그리고 순서대로 처리하며 미루기 세 가지 선택지가 있어요.

다만 이 두 도구에도 같은 조건이 붙어요. 실행 제어 문서의 플랜 표시를 보면 스케줄 트리거와 Delay 모두 Free에는 회색 X가 들어가 있고, Professional과 Team과 Enterprise 쪽에만 체크가 붙어 있어요. 앞서 폴링 간격에서 본 것과 같은 자리에 같은 표시가 있는 셈이라, 무료 플랜에서 실행 시점을 손보려는 계획은 여기서 한 번 막혀요.

자연어로 워크플로를 짜는 감각이 궁금하다면 한 문장으로 Zapier 워크플로를 만드는 5단계를 정리한 글을 이어 봐도 좋아요. 어떤 트리거를 고를지가 결국 첫 문장에서 갈리거든요.

Make 시나리오는 기본이 15분이고, 즉시 실행은 조건이 붙어요

Make의 스케줄 패널은 선택지를 여러 개 펼쳐 놔요. 정해진 간격마다, 한 번, 매일, 평일, 매주, 매월, 지정한 날짜, 요청 시 실행이에요. 정해진 간격마다를 고르면 두 번의 실행 사이 시간 간격을 분 단위로 직접 정해야 해요.

매일 옵션은 생각보다 유연해요. 도움말은 하루 스케줄에 필요한 만큼 실행 시각을 추가할 수 있다고 적어요. 새벽 한 시와 오후 두 시 사십 분과 밤 열 시처럼 하루 안에 서로 떨어진 시각을 여러 개 넣어 두는 식이에요. 반대로 요청 시 실행은 스케줄이 아예 없어요. API 호출이나 Run once 버튼을 기다리고, 직접 시작하지 않으면 돌지 않아요.

즉시 실행 옵션은 아무 데나 붙지 않아요. 도움말이 즉시 실행 옵션은 일부 트리거에서만 제공된다고 밝히고 있어요. 그리고 웹훅 문서 쪽에는 더 분명한 문장이 있어요. 앱이 웹훅을 제공하지 않으면 폴링 트리거로 주기적으로 서비스를 확인하는 수밖에 없다는 안내예요. 즉 "즉시로 바꾸기"는 내 선택이 아니라 앱이 지원하느냐에 달린 문제예요. Make 시나리오 자체를 처음 만들어 보는 단계라면 Make.com 시나리오를 3단계로 세팅하는 방법에서 화면 구조를 먼저 익히고 오시면 스케줄 패널이 훨씬 눈에 잘 들어와요.

내 자동화가 즉시 도는지 확인하는 자가진단

지금 만들어 둔 자동화를 열어 두고 아래를 한 줄씩 짚어 보세요. 여기서 걸리는 항목이 곧 지연의 정체예요.

• 에디터에서 트리거 단계에 번개 아이콘이 붙어 있나요, 아니면 아무 표시가 없나요
• Make를 쓴다면 모듈 목록에서 그 트리거에 instant 라벨이 붙어 있었나요
• 스케줄 패널이 정해진 간격마다로 되어 있나요, 즉시 실행으로 되어 있나요
• 정해진 간격마다라면 지금 몇 분으로 잡혀 있나요
• 지금 쓰는 플랜의 값이 위 표에서 어디에 해당하나요
• 테스트할 때 자동화를 켜기 전에 만들어 둔 데이터를 쓰고 있지는 않나요
• 트리거로 쓰는 앱이 웹훅을 제공하는지 확인해 봤나요
• 한꺼번에 많은 항목이 밀려 들어온 직후는 아닌가요

여섯 번째 항목은 특히 많이 걸려요. Zapier 도움말은 Zap 워크플로가 새 데이터에 대해서만 실행되고, 트리거가 지원하는 경우 갱신된 데이터까지 포함한다고 적어요. 그러면서 오래된 데이터, 그러니까 Zap을 켜기 전에 앱에서 만들어진 데이터에 대해서는 실행되지 않는다고 분명히 밝혀요. 켜자마자 조용한 게 당연한 상황인데 설정을 뜯고 있는 경우가 여기서 나와요. 다만 같은 문서는 바로 다음 줄에서 길을 하나 알려줘요. 이미 있는 데이터를 옮겨야 한다면 Transfer라는 별도 기능을 쓰라는 안내예요. 트리거가 안 잡아준다고 손으로 다시 넣을 필요는 없다는 뜻이에요.

폴링을 웹훅으로 바꿀 때 확인할 것

앱이 웹훅을 지원한다면 방향은 단순해요. Zapier 도움말은 대부분의 웹훅에는 Catch Hook 트리거가 가장 나은 선택지라고 적고, 이 트리거가 고유한 URL을 만들어 주면 트리거 쪽 앱이 그 URL로 POST 요청을 보내는 방식이라고 설명해요. URL은 에디터의 Test 탭에서 확인하고 Copy를 눌러 복사하면 돼요.

반대 방향도 있어요. Zapier가 외부 URL에 GET 요청을 보내 새 항목이 있는지 확인하게 하고 싶다면 Retrieve Poll 쪽이에요. 이 트리거는 REST API 엔드포인트에 주기적으로 GET 요청을 보내 데이터를 가져와요. Catch Hook이 다른 앱의 POST 요청을 기다리는 것과 달리, Retrieve Poll은 자기가 데이터를 요청하러 가요. 다만 응답 형식 요건이 붙어요. 엔드포인트는 JSON을 돌려주거나 XPath로 파싱할 수 있는 XML 또는 HTML을 돌려줘야 하고, 응답은 최신 항목이 앞에 오는 역순 배열이어야 해요.

이름에 웹훅이 들어 있다고 전부 즉시 도는 게 아니라는 점이 여기서 갈려요. Catch Hook은 기다리는 쪽이라 즉시에 가깝고, Retrieve Poll은 이름과 달리 확인하러 가는 쪽이라 주기의 영향을 받아요. 자동화를 서버 쪽에 직접 두는 선택지가 궁금하다면 n8n 워크플로 자동화 입문 가이드에서 트리거 구성을 비교해 보셔도 좋아요.

주기를 줄여도 안 빨라지는 경우

여기를 모르면 플랜을 올리고도 같은 답답함을 겪게 돼요.

첫째, 이미 인스턴트 트리거인 자동화에는 폴링 간격이 아무 영향을 주지 않아요. Zapier 도움말이 인스턴트 트리거에서는 Zapier가 API에 새 데이터가 있는지 물어볼 필요가 없다고 적어요. 물어보러 가지 않으니 물어보는 주기를 줄여도 달라질 게 없어요.

둘째, 커스텀 폴링 간격은 하한이 막혀 있어요. 앞서 인용한 대로 커스텀 간격의 최솟값은 내 플랜의 폴링 간격보다 짧을 수 없어요. 이 설정으로 플랜의 속도를 앞지를 수는 없다는 뜻이에요.

셋째, 웹훅으로 바꾸면 이번엔 반대 문제가 생길 수 있어요. Make 도움말은 인스턴트 트리거를 쓰는 시나리오가 짧은 시간에 지나치게 자주 도는 것을 막으라는 취지로 분당 최대 실행 수 설정을 안내하고, 기본 제한값을 100으로 적어요. 한도에 닿으면 이후 요청은 큐에 쌓였다가 한도가 허용하는 만큼 차례로 처리돼요. 제한을 넘긴 요청에는 429 too many requests 응답이 돌아가는데, 이건 시나리오에 웹훅 응답 모듈을 넣었을 때만 생기는 일이 아니에요. 응답 모듈이 없을 때의 기본 응답 목록에도 이 코드가 이미 들어 있어요. 큐가 무한한 것도 아니고요. 도움말은 웹훅 큐에 담을 수 있는 항목 수에 상한이 있고, 큐가 가득 차면 상한을 넘겨 들어오는 웹훅 데이터는 받아들여지지 않는다고 적어요.

넷째, 처리 순서도 같이 봐야 해요. Make에서 인스턴트 웹훅을 쓰는 시나리오는 기본적으로 병렬로 처리돼요. 이전 실행이 아직 끝나지 않아도 기다리지 않는다는 뜻이에요. 순서가 중요한 작업이라면 순차 처리로 바꿔서 이전 실행이 끝난 뒤에 다음 실행이 시작되게 할 수 있어요. 웹훅마다 자기 큐를 따로 갖는 구조라는 점도 함께 알아두면 흐름이 그려져요. 반대로 몰리는 요청을 모아서 처리하고 싶다면, 웹훅으로 트리거되는 시나리오에 스케줄을 걸어 두는 방법도 도움말에 적혀 있어요. 이렇게 두면 들어온 요청이 웹훅 큐에 쌓였다가 스케줄 조건이 맞을 때 큐 전체가 한 번에 처리돼요.

다섯째, 주기와 아예 무관한 보류도 있어요. Zapier 도움말은 트리거가 한 번에 아주 많은 결과를 돌려주는 경우, 예를 들어 시트를 대량으로 가져오거나 CRM을 옮기는 경우에 홍수 방지 장치가 실행을 곧바로 처리하지 않고 확인을 위해 붙잡아 둘 수 있다고 적어요. 이때는 간격을 줄이든 플랜을 올리든 달라지지 않아요. 대량 작업 직후에 자동화가 조용하다면 주기부터 의심할 자리가 아니에요.

상황별로 어떤 주기를 고르면 되나요

정답이 하나는 아니에요. 다만 판단 기준은 단순해요. 늦어서 손해가 나는 자동화인지, 늦어도 아무 일 없는 자동화인지만 나누면 돼요.

이 표를 위에서부터 읽으면 흐름이 보여요. 급한 것만 웹훅으로 올리고 나머지는 넉넉한 간격에 두는 구성이 손이 제일 덜 가요. 전부 최소 간격으로 맞춰 두면 급한 자동화와 안 급한 자동화가 같은 자리를 두고 다투게 되거든요.

지금 당장 해볼 액션

오늘은 자동화 하나만 열어 보세요. 제일 답답했던 것부터가 좋아요.

먼저 트리거 단계를 보고 번개 아이콘이나 instant 라벨이 있는지 확인하세요. 있으면 지연의 원인은 주기가 아니니 다른 곳을 봐야 해요. 없으면 폴링이고, 위 표에서 지금 플랜의 값을 찾아보세요. 그 값이 곧 최악의 경우 기다리게 되는 시간이에요.

그다음 그 앱이 웹훅을 제공하는지 확인하세요. 제공한다면 그 인스턴트 트리거로 트리거 단계를 다시 만드는 것이 가장 확실한 개선이에요. 제공하지 않는다면 주기를 손보는 것 말고는 방법이 없으니, 이 자동화가 정말 몇 분을 다투는 일인지부터 다시 따져 보세요. 대부분의 업무 자동화는 15분 뒤에 처리돼도 결과가 달라지지 않아요.

여기서 한 가지 주의할 게 있어요. Zapier 도움말은 트리거의 종류가 앱의 API로 정해져 있어서 지금 쓰는 트리거를 폴링에서 인스턴트로 바꿀 수는 없다고 적어요. 그러니 설정 어딘가에서 종류를 전환하는 스위치를 찾지 마시고, 앱이 따로 제공하는 인스턴트 트리거를 골라 트리거 단계를 갈아 끼우셔야 해요.

마지막으로 문서 확인 습관 하나만 붙이시면 좋겠어요. 커스텀 폴링 간격 문서는 스스로 게시 시점 기준의 정보라고 밝히고 있고, Make 도움말도 최소 간격은 플랜에 따라 달라진다며 가격 페이지를 가리켜요. 플랜 조건과 한도 수치는 바뀌는 항목이니, 결정을 내리기 전에 공식 페이지에서 지금 값을 한 번 더 확인하세요.

함께 보면 좋은 글

• Make.com 노코드 자동화 3단계 세팅: 시나리오 화면과 스케줄 패널이 어디에 있는지부터 익히고 싶을 때 먼저 보면 좋아요.
• Zapier AI Actions 자연어 워크플로우 빌드 5단계: 트리거를 고르는 첫 단계를 문장으로 처리하는 방식이 궁금할 때 이어 보기 좋아요.