Zapier·Make, 단계별 과금으로 비용 비교하기

Zapier와 Make 중 어느 쪽이 유리한지는 월 구독료만으로 결정하기 어렵다. Zapier의 task 산정 규칙은 트리거와 조건 분기를 제외한 성공 작업을 세고, Make 요금 안내는 일반 모듈의 데이터 수신·처리·전송을 credit 사용으로 설명한다. 따라서 같은 리드를 등록하고 이메일을 보내더라도 두 제품의 사용량 숫자는 일대일로 바꿔 읽을 수 없다.

Zapier 요금표에는 무료 플랜의 월 100 task와 두 단계 Zap 제한이 명시돼 있다. Make 무료 플랜은 월 1,000 credit을 제공한다. 무료 한도는 출발점일 뿐이다. 리드 한 건이 어느 경로를 거치는지, 필요한 연결 앱과 분기 기능을 해당 플랜에서 쓸 수 있는지까지 따져야 실제 선택이 가능하다.

task와 credit이 잡히는 지점

Zapier에서 트리거는 자동화를 시작하지만 task를 소모하지 않는다. 이후 CRM에 연락처를 만들거나 이메일을 보내는 앱 작업이 성공하면 각각 사용량에 잡힌다. 조건을 평가하는 Filters와 Paths도 task를 쓰지 않으며, 조건에 걸려 실행되지 않은 뒤쪽 작업 역시 차감되지 않는다.

화면에 단계가 많다고 그 수를 그대로 리드 건수에 곱하면 Zapier 사용량을 과대 계산할 수 있다. 반면 성공한 작업을 나중에 전체 Zap 재실행으로 다시 수행하면 그 작업은 다시 task에 잡힌다. 검색 작업이나 AI·코드 기능에는 별도 규칙이 적용될 수 있으므로, 아래 예시는 일반 앱 작업만으로 범위를 좁힌다.

Make에서는 시나리오의 모듈이 데이터를 확인하거나 처리할 때 사용량이 생긴다. 일반적인 비AI 앱 모듈은 실행 한 번에 1 credit을 쓰며, 데이터를 읽는 수신 모듈도 계산 대상이다. 라우터와 기본 오류 처리 모듈에는 별도 credit이 붙지 않지만, 라우터 뒤에서 실제로 실행되는 앱 모듈은 차감된다.

이 차이는 특히 시작 단계에서 드러난다. Zapier의 리드 감지 트리거는 task가 아니지만, Make의 리드 수신 모듈은 보통 credit을 쓴다. 다만 Make에서도 AI 기능 등은 실행 횟수 외의 사용량에 따라 credit이 달라질 수 있다. 두 단위를 비교할 때는 먼저 같은 업무 결과와 같은 종류의 모듈을 전제로 놓아야 한다.

같은 리드 한 건을 처리하면

다음은 서비스에서 측정한 결과가 아니라 조건을 고정한 계산 예시다. 웹 양식에서 리드 한 건을 받으면 CRM에 연락처를 등록하고, 우선순위에 따라 담당자용 또는 일반 안내용 이메일 중 하나를 보낸다고 가정한다. 어느 분기를 타든 성공한 결과는 CRM 등록 한 번과 이메일 발송 한 번이다.

Zapier: 리드 발생 트리거 0 task → CRM 등록 1 task → Paths 조건 분기 0 task → 선택된 이메일 발송 1 task. 합계 2 task.
Make: 리드 수신 모듈 1 credit → CRM 등록 모듈 1 credit → 라우터·필터 0 credit → 선택된 이메일 발송 모듈 1 credit. 합계 3 credit.

Make의 사용량 숫자가 하나 더 큰 이유는 이 구성에서 리드 수신까지 세기 때문이다. 3 credit이 2 task보다 비싸다는 의미는 아니다. 제품마다 제공량과 단가가 달라, 사용량의 숫자만 비교해서 청구액을 정할 수 없다. 이 예시에서 중요한 것은 어느 단계가 실제 차감 대상인지다.

담당자에게 별도 알림을 한 통 더 보내는 분기를 추가하면 그 분기를 통과한 리드에는 두 제품 모두 추가 이메일 작업의 사용량이 붙는다. 반대로 부적합한 리드를 CRM 등록 전에 걸러내면 뒤쪽 등록과 발송 작업은 실행되지 않는다. 조건 분기 자체의 비용보다 조건을 놓은 위치와 그 뒤에 있는 작업 수가 총량을 바꾼다.

분기별 작업이 항상 하나만 실행된다는 전제도 분명히 해야 한다. Make 라우터의 여러 경로가 같은 리드에 대해 각각 조건을 충족하면 뒤쪽 모듈이 여러 번 실행될 수 있다. Zapier에서도 선택한 경로 밖의 작업은 세지 않지만, 실제 구성에서 어떤 경로와 작업이 실행되는지에 따라 리드 한 건의 task 수가 달라진다.

월간 물량과 수신 방식까지 넣은 계산

앞의 조건으로 월 100건의 리드가 모두 등록되고 이메일 한 통씩 발송된다면 Zapier는 200 task, Make는 300 credit이다. Zapier 무료 플랜은 이 사용량을 감당하지 못하며, CRM 등록과 이메일 발송이 이어지는 다단계 Zap 구성도 무료 플랜의 두 단계 제한에 맞지 않는다. Make의 계산상 사용량은 무료 credit 한도 안에 들어간다.

이번에는 월 100건 중 40건만 등록 대상으로 통과하도록 CRM 앞에 필터를 둔다고 가정하자. Zapier는 통과한 리드의 등록 40회와 발송 40회로 80 task를 쓴다. Make는 수신 100회에 등록 40회, 발송 40회를 더해 180 credit이다. Zapier의 숫자가 무료 사용량 한도 안으로 내려와도 이 자동화에 필요한 다단계 기능의 플랜 조건은 별도로 남는다.

이 계산은 Make가 리드를 한 건씩 받는 수신 구성을 전제로 한다. 정해진 간격마다 외부 앱의 새 데이터를 확인하는 방식이라면 새 리드가 없는 확인 실행도 사용량에 들어갈 수 있다. 한 번에 여러 데이터 묶음이 넘어오면 뒤쪽 모듈은 처리한 묶음 수만큼 실행될 수 있어, 월 리드 수만으로 credit을 예측하기 어렵다.

그래서 같은 업무라도 웹훅으로 건별 수신하는지, 일정 간격으로 조회하는지에 따라 Make 견적이 달라진다. Zapier에서는 트리거의 정기 확인이 task로 잡히지 않는다는 점도 차이를 만든다. 수신 방식은 단순한 설정 항목이 아니라 두 서비스의 사용량을 비교할 때 고정해야 할 조건이다.

이메일 발송이 실패하고 재시도하면

오류가 나면 원래 흐름의 모든 단계를 다시 더하는 계산은 정확하지 않다. Zapier에서 CRM 등록이 성공하고 이메일 발송이 실패했다면 등록 작업은 이미 task에 포함되지만 실패한 이메일 작업은 성공 task로 세지 않는다. 이메일 작업만 다시 실행해 성공하는 조건이라면 이 리드의 최종 성공 작업은 등록과 발송으로 남는다.

Make의 미완료 실행 안내는 재시도가 오류를 일으킨 모듈부터 시작한다고 설명한다. 앞의 수신과 CRM 등록을 다시 실행하지 않고 이메일 모듈에서 복구한다면, 정상 경로의 기본 계산은 수신·등록·성공한 발송의 3 credit이다. 최초 실패한 이메일 실행에도 credit이 기록됐다면 그만큼을 추가해야 하므로, 실패 유형별 총 차감량을 하나의 고정값으로 제시할 수는 없다.

전체 흐름을 처음부터 재실행하는 방식에는 사용량 외의 문제도 있다. 이미 생성된 CRM 연락처가 중복 등록되거나 이메일이 다시 발송될 수 있다. 재시도 기능의 유무만 볼 것이 아니라 실패한 지점에서 이어서 처리할 수 있는지, 같은 리드를 다시 받을 때 중복 작업을 막을 수 있는지가 운영 결과를 좌우한다.

Make의 미완료 실행은 설정과 오류 유형에 따라 자동 또는 수동으로 처리된다. 재시도 중 오류가 다른 모듈로 옮겨가면 그 지점의 작업도 새로 계산해야 한다. Zapier 역시 전체 실행을 다시 돌릴 때 이미 성공했던 작업이 재실행되면 사용량이 늘 수 있어, 두 제품 모두 정상 경로의 건당 계산만으로 오류 비용을 설명할 수 없다.

연결 앱과 학습 난도는 어떻게 고를까

필요한 CRM이나 메일 서비스가 연결 목록에 있어도 원하는 트리거와 작업이 없으면 예시대로 자동화를 만들 수 없다. 연락처 생성은 되지만 중복 조회나 기존 레코드 수정이 빠져 있을 수도 있다. 한국 팀이 쓰는 실제 양식·CRM·메일 조합에서 필요한 동작을 확인해야 앱 목록의 규모가 의미를 갖는다.

G2의 사용 비교는 Zapier의 폭넓은 연동과 쉬운 시작, Make의 유연한 분기와 데이터 처리를 각각 강점으로 평가한다. Make의 시각적 시나리오는 여러 갈래의 흐름을 표현하기 좋지만 익혀야 할 개념도 더 많다는 평가다. 이는 일반적인 사용성 비교이며 특정 팀의 구축 시간이나 청구액을 보장하지 않는다.

양식 입력 뒤 몇 가지 앱 작업을 연결하고 운영 담당자가 직접 수정해야 하는 팀에는 Zapier가 편할 수 있다. 리드 조건이 많고 경로마다 데이터를 다르게 처리해야 하는 팀에는 Make의 라우터와 모듈 구성이 맞을 수 있다. 다만 Zapier가 시작하기 쉽다는 평가와 Make의 조건 분기가 강하다는 평가는 각 팀의 필수 앱 작업을 대신 확인해 주지는 않는다.

도입 판단에서는 먼저 결과가 같은 경로를 놓고 정상 처리, 필터 제외, 추가 알림, 실패 후 복구의 건수를 나눠 합산하면 된다. 그 총량에 필요한 플랜 기능과 연결 앱의 실제 작업 범위를 대입해야 한다. 앞의 리드 예시처럼 무료 사용량 안에 들어와도 필요한 자동화 구조가 무료 플랜에서 허용되지 않을 수 있으므로, 월 요금은 이 조건들을 확인한 뒤 비교하는 편이 정확하다.

함께 읽기: