Make 자동화 사용법 완전정복 — Zapier 대신 Make를 고른 이유

목차

• Zapier에서 Make로 넘어가게 된 이유
• 처음 시나리오 빌더를 켰을 때 당황한 것
  • 시나리오 만들기 첫 단계
  • "Run once"와 "Scheduling"의 차이
• Google Sheets → Slack → Gmail 연동 실전
  • Router와 Filter 설정에서 막힌 부분
  • Slack 메시지 포매팅
  • Gmail 모듈에서 HTML 본문 다루기
• 실패했던 첫 번째 시나리오
• Make vs Zapier — 실무 관점에서 본 차이
• 디버깅과 모니터링이 의외로 강하다
• 그래서 언제 Make를 쓰고 언제 안 쓸 것인가

Make 자동화 사용법을 본격적으로 정리하기 전에, 이 도구가 뭔지부터 짚고 가자. Make(구 Integromat)는 노코드 자동화 플랫폼이다. Zapier, n8n, Power Automate와 같은 카테고리에 속하지만, 시나리오를 시각적으로 노드 그래프처럼 그리는 방식이 가장 큰 특징이다.

게다가, Google Sheets에 행이 추가되면 Slack으로 알림을 보내고, 동시에 Gmail로 요약을 발송하는 식의 분기·필터·반복이 한 화면에서 그래프로 그려진다. Zapier는 "Trigger → Action" 일직선 흐름이 기본이고 분기는 Path(유료)로 풀어야 하는데, Make는 처음부터 그래프 기반이다. 이 차이가 실무에서 생각보다 크다.

이처럼, 이 글은 Zapier를 1년쯤 쓰다가 요금 청구서를 보고 Make로 갈아탄 기록이다. 처음 Make 화면을 켰을 때 당황한 지점, 시나리오를 두 번 갈아엎은 이유, 그리고 어떤 상황에서 Make가 맞고 어떤 상황에서는 그냥 Zapier가 낫다는 판단까지 다 적었다.

Zapier에서 Make로 넘어가게 된 이유

처음에는 Zapier가 편했다. UI가 단순하고, 한 줄 흐름으로 끝나는 자동화에는 더 빨리 만들 수 있다. 문제는 자동화 수가 늘면서 시작됐다.

따라서, Zapier는 Task 단위 과금이다. Trigger 한 번에 Action이 세 개 붙으면 3 Task. 한 번 발화될 때마다 3 Task가 빠진다. Make는 다르다. 각 모듈 실행 1회당 1 Operation이긴 한데, 단가가 훨씬 낮다. 작성 시점(2026년 6월) 기준 공개된 요금제를 비교해 보자.

또한, (요금은 공식 사이트 공시 기준이며, 프로모션·환율에 따라 달라질 수 있다. 출처: Make Pricing, Zapier Pricing)

한편, 단순 비교만 보면 Make가 5배 가까이 싸 보인다. 다만 함정이 있다. Make는 모듈 하나가 1 Operation이라, 반복문 안에서 50번 도는 시나리오는 50 Operation을 먹는다. 이걸 모르고 처음 한 달을 돌렸더니, 10,000 Operation이 4일 만에 동났다. 그래서 Zapier에서 Make로 옮길 때는 "내가 자동화하려는 게 분기·반복이 많은 워크플로인가, 아니면 단순 트리거→액션인가"부터 보는 게 맞다.

처음 시나리오 빌더를 켰을 때 당황한 것

그래서, Make 시나리오 빌더를 처음 열면 화면 중앙에 시계 모양 아이콘이 하나 떠 있다. 트리거 모듈을 여기에 붙이고, 그다음 모듈을 동그라미 옆에 이어 붙이는 식이다. Zapier처럼 세로로 쌓이지 않고, 노드와 선으로 이어진다.

이처럼, 처음엔 이게 좀 거슬렸다. "왜 시각화에 신경을 이렇게 썼지? 그냥 리스트로 보여주면 안 되나" 싶었다. 그런데 Router(분기) 모듈을 하나 넣어 보면 이해가 된다. 한 트리거에서 세 갈래로 갈라지는 흐름이 한눈에 들어온다. Zapier에서 Paths로 같은 걸 만들면 탭이 세 개 생기고, 각 탭을 클릭해서 봐야 한다.

시나리오 만들기 첫 단계

기본 흐름은 이렇다.

1. 우측 상단 "Create a new scenario" 클릭
2. 가운데 시계 아이콘 클릭 → 트리거 앱 선택 (예: Google Sheets)
3. 트리거 종류 고르기 (예: "Watch Rows")
4. 인증 연결, 시트 ID·범위 지정
5. 트리거 옆 동그라미를 드래그 → 다음 모듈 선택

여기까진 어렵지 않다. 문제는 트리거의 "Maximum number of returned rows" 같은 옵션을 처음 보면 뭘 넣어야 할지 모른다는 거다. 기본값이 2다. 한 번 실행될 때 행 두 개만 가져온다는 뜻이다. 처음에 이 값을 안 건드리고 돌렸다가, 새로 추가된 행 다섯 개 중 두 개만 처리되는 걸 보고 한참 헤맸다. 결국 이 값을 100으로 바꾸고서야 정상이 됐다.

"Run once"와 "Scheduling"의 차이

그러나, 빌더 좌측 하단에 큰 버튼 두 개가 있다. "Run once"는 말 그대로 지금 한 번만 돌리는 거고, "Scheduling"을 ON으로 켜야 진짜 자동화가 시작된다. 이 토글을 안 켜고 "왜 자동으로 안 돌지?"라며 한 시간을 날린 적 있다. 공식 문서에는 이게 너무 당연한 것처럼 적혀 있어서 놓치기 쉽다 (출처: Make Help — Scheduling).

Google Sheets → Slack → Gmail 연동 실전

실제로 만들었던 시나리오 하나를 풀어 보겠다. 고객사가 Google Sheets에 신규 문의를 적으면, Slack 채널에 알림을 띄우고, 동시에 담당자에게 Gmail로 요약을 보내는 흐름이다.

반면, 구조는 이렇게 잡았다.

[Google Sheets: Watch Rows]
        ↓
   [Router 분기]
   ├─→ [Filter: 우선순위=High] → [Slack: Create a Message]
   └─→ [Filter: 항상 통과]    → [Gmail: Send an Email]

즉, 코드 한 줄도 안 쓰고 이 구조를 그래프로 그릴 수 있다는 게 Make의 가장 큰 강점이다. Zapier에서 같은 걸 만들려면 Paths(상위 요금제) + Filter를 조합해야 하고, 두 갈래 이상 분기는 시각적으로 보기 힘들어진다.

Router와 Filter 설정에서 막힌 부분

Router 모듈을 놓고 두 개의 경로를 그렸다. 각 경로 앞에 있는 렌치 아이콘을 클릭하면 Filter 조건을 걸 수 있다. 여기서 한 가지 깨달은 점이 있다. Filter는 "조건을 만족하면 통과"인데, "통과하지 못한 데이터는 그 경로에서 멈춘다." 다음 경로로 넘어가지 않는다. Router는 기본적으로 모든 경로에 같은 데이터를 복사해서 보낸다.

이게 Zapier의 Paths와 다른 지점이다. Zapier Paths는 "처음 매칭되는 경로 하나만" 실행되는데, Make Router는 "모든 경로가 병렬로 실행"된다. 같은 데이터로 두세 가지 일을 동시에 처리하고 싶을 때 Make 쪽이 훨씬 직관적이다.

Slack 메시지 포매팅

Slack 모듈에서 "Create a Message"를 선택하면 채널, 텍스트, 멘션 등을 입력하는 칸이 나온다. 텍스트 칸에서 위쪽의 이전 모듈 출력값(예: 1. Title, 1. Email)을 클릭하면 변수로 들어간다. 굳이 코드 같은 거 안 써도 된다.

다만 멘션을 제대로 넣으려면 <@USERID> 형식을 직접 써야 한다. Slack User ID를 모르면 워크스페이스에서 사용자 프로필 → "Copy member ID"로 가져와야 한다. 이 ID는 U로 시작하는 9자리 문자열이다. 처음에 이걸 모르고 @홍길동이라고 적었더니 그냥 텍스트로 들어가더라.

Gmail 모듈에서 HTML 본문 다루기

Gmail의 "Send an Email" 모듈은 본문을 텍스트로 받든 HTML로 받든 상관없다. Content Type을 HTML로 두고 <table>, <strong> 같은 태그를 직접 적으면 그대로 렌더링된다. 한 가지 주의할 게, 본문 안에 모듈 변수를 박을 때 따옴표나 특수문자가 들어가면 HTML 파싱이 깨지는 경우가 있다. 이때는 Make 내장 함수 escapeHTML()로 감싸면 된다.

<tr><td>제목</td><td>{{escapeHTML(1.title)}}</td></tr>
<tr><td>내용</td><td>{{escapeHTML(1.body)}}</td></tr>

이건 공식 문서의 입문 가이드에는 잘 안 나오는 부분이다. 처음엔 본문에 따옴표 들어간 행이 들어오면 HTML이 깨져서 한참 디버깅했다.

실패했던 첫 번째 시나리오

여기까지 읽으면 매끄러워 보이지만, 처음 만든 시나리오는 한 번에 망가졌다. 원인은 두 가지였다.

예를 들어, 첫째, Sheets 트리거의 "Limit"을 너무 작게 잡았다. 기본값 2 그대로 돌렸더니, 시트에 한 번에 다섯 행이 추가되면 두 개만 잡혔다. 나머지는 다음 실행 주기에 처리되긴 하는데, 실시간성이 떨어진다.

둘째, Slack 모듈에 Rate Limit 처리가 없었다. Slack API는 분당 메시지 수 제한이 있다. 짧은 시간에 수십 건의 알림이 폭주하면 일부가 429 에러로 실패한다. Make는 모듈별로 "Error handler"를 붙일 수 있다. 모듈 우클릭 → "Add error handler" → "Resume" 또는 "Break"를 선택하면 된다. Resume을 쓰면 에러가 나도 시나리오를 멈추지 않고 다음 모듈로 넘어간다.

이 두 가지를 고치고 나서야 안정적으로 돌아갔다. 시나리오 한 번 갈아엎는 데 반나절이 걸렸다. 빌더가 시각적이라 수정은 쉽지만, 어디서 막혔는지 추적하는 건 또 다른 문제다.

Make vs Zapier — 실무 관점에서 본 차이

반면, 같은 자동화를 두 도구로 다 만들어 본 입장에서 정리하자면, 단순 "어느 게 더 좋은가"는 답이 없다. 자동화의 성격에 따라 다르다.

즉, Zapier의 강점은 진입 장벽이 낮다는 거다. 비개발자가 30분 만에 첫 자동화를 만들 수 있다. Make는 노드 그래프, Operation 계산, Iterator/Aggregator 같은 개념이 있어서 학습에 며칠은 든다.

실제로, 대신 한 번 익숙해지면 Make의 표현력이 훨씬 강하다. JSON 파싱, 배열 매핑, 정규식 함수, HTTP 모듈로 거의 임의의 API 호출까지 코드 없이 가능하다. 개발자가 보기엔 "코드로 짤 걸 굳이 노코드로 짠다고?" 싶을 수도 있는데, 팀 내 비개발자에게 인수인계할 때는 이런 시각적 도구가 정말 유용하다 (개인적으로 인수인계 때문에 노코드를 쓴다).

디버깅과 모니터링이 의외로 강하다

Make의 진짜 매력은 실행 후 보이는 "History" 화면이다. 시나리오를 한 번 돌리면, 각 모듈마다 들어간 입력과 나간 출력이 JSON으로 다 찍힌다. 어느 모듈에서 어떤 값이 들어왔고 어떤 게 나갔는지 클릭 한 번으로 본다.

예를 들어, Zapier도 Task History가 있지만, Make 쪽이 시각적 추적이 더 직관적이다. 노드 위에 색깔로 성공/실패가 표시되고, 빨간 동그라미를 클릭하면 에러 메시지가 바로 뜬다. 야밤에 에러 추적할 때 이게 정말 큰 차이를 만든다 (한 번 새벽 2시에 시나리오가 죽어서 History 화면 켜고 5분 만에 원인 찾은 적 있다).

모니터링 측면에서 보자면, Make는 시나리오가 N회 연속 실패하면 자동으로 비활성화한다. 기본값은 5회다. 무한 루프나 잘못된 트리거로 Operation을 소진하는 걸 막아 준다. 이 안전장치는 Zapier에도 비슷하게 있지만, Make 쪽이 임계값을 더 세밀하게 조정할 수 있다 (출처: Make Help — Errors and warnings).

그래서 언제 Make를 쓰고 언제 안 쓸 것인가

그러나, 직접 1년 넘게 두 도구를 다 굴려 보고 내린 기준이다.

반면, Make가 맞는 상황

• 월 Operation이 5,000건 이상 예상되는 자동화
• 한 트리거에서 여러 갈래로 동시에 처리해야 함
• 반복(Iterator), 집계(Aggregator) 같은 데이터 가공이 필요
• 시나리오 실행 내역을 자세히 추적해야 함

Zapier가 맞는 상황

• 비개발자가 직접 만들고 유지해야 함
• 통합할 앱이 마이너한 SaaS여서 Make에 없음
• 단순 일자형 흐름이 대부분
• 처음 한두 개 자동화만 빠르게 시작하고 싶음

둘 다 안 쓰는 게 나은 상황

• 월 수만 건 이상 작업이 도는 핵심 비즈니스 로직 → 직접 코드로 짜는 게 장기적으로 싸다
• 데이터 민감도가 매우 높음 → 제3자 SaaS 거치는 게 보안상 부담

당장 실행할 수 있는 것 세 가지를 남긴다. 첫째, Make 무료 플랜으로 가입해서 시계 아이콘만 띄워 봐라. 1,000 Operation은 그냥 준다. 둘째, 지금 Zapier에서 돌리고 있는 자동화 중 분기가 두 개 이상인 시나리오를 Make로 옮겨 봐라. Router 모듈 한 번 써 보면 왜 사람들이 Make로 넘어가는지 감이 온다. 셋째, 시나리오를 만들 때 "Scheduling" 토글부터 먼저 켜는 습관을 들여라. 그래야 안 돌아가는 게 토글 때문인지 다른 문제인지 분리해서 본다.

즉, Make는 만능 도구는 아니다. 노코드의 한계도 분명하다. 그런데 적당한 복잡도의 자동화를 비개발자와 함께 굴려야 한다면, 작성 시점 기준 가장 균형 잡힌 선택지로 보인다.

관련 글

• Celery Redis 비동기 작업 큐 실전 가이드 — 설치, 태스크, 재시도, Flower까지 – 프론트엔드에서 백엔드로 넘어온 시점에 가장 먼저 마주친 게 비동기 작업 큐였다. Celery와 Redis 조합을 처음 세팅하는 사람을 위해…
• Bash 쉘 스크립트 자동화 실전 가이드 — cron·에러 핸들링·로깅 패턴 – bash 쉘 스크립트 자동화는 단순히 명령어 묶는 게 아니라 실패를 어떻게 다룰지 설계하는 일이다. cron, trap, 락 파일, 로깅까…
• 쿠버네티스 리소스 설정 — OOMKilled와 CPU Throttling 잡는 최적값 – 쿠버네티스 리소스 설정에서 requests와 limits의 역할은 다르다. 같은 값으로 두면 두 메커니즘이 충돌한다. FastAPI 서비스…