Make.com 워크플로 만들기 — 모듈보다 먼저 알아야 할 건 '크레딧 계산법'입니다

자동화는 시간을 아껴 준다 — 다들 그렇게 믿지만, 초보에겐 절반만 맞는 착각입니다. "모듈 다섯 개짜리 가벼운 시나리오"라고 방심한 사람이 사흘 만에 무료 크레딧을 다 태우는 함정이 흔하거든요. AI 일꾼을 싸게 부려먹으려다 되레 삯을 더 무는, 돈 먹는 하마가 되는 순간이죠.

구독료에 예민한 1인 기업가라면, 예쁜 모듈을 끌어다 붙이기 전에 "이 시나리오가 한 달에 크레딧을 얼마나 먹을지"부터 암산할 줄 알아야 합니다. 이 글은 한 사람의 사용 후기가 아니라, Make 공식 문서와 여러 사용자 후기를 모아 비교해 초보가 실제로 밟는 지점을 정리한 큐레이션입니다. 특히 상당수 튜토리얼이 틀리게 설명하는 크레딧 계산법을, 공식 문서 기준으로 바로잡는 데 초점을 맞췄습니다.

Make가 하는 일, 한 줄로

Make의 워크플로 단위를 시나리오(scenario)라고 부릅니다. 시나리오 하나는 트리거 1개에 모듈 여러 개가 매달린 구조예요.

• 모듈(module): "새 메일 받기", "시트에 행 추가"처럼 시나리오를 이루는 개별 단계.
• 흐름은 거의 항상 같습니다 — 트리거(폼·이메일·RSS) → 데이터 가공(필터·라우터·AI 모듈) → 목적지 앱(시트·CRM·SNS·Slack).

모듈 하나하나가 잔심부름 시킬 일꾼이고, 이 일꾼들을 얼마나 굴리느냐가 곧 청구서입니다. 여기까지는 어느 소개 글이나 잘 설명해요 — 문제는 그다음, 돈이 걸린 이야기부터죠. 참고로 같은 자동화 툴인 Zapier와 뭐가 다른지는 Zapier와 Make를 비교한 글에서 따로 다뤘고, 이 글은 Make 안에서 워크플로를 짜는 실무에 집중합니다.

먼저 정리: 'operations'는 옛말, 이제 'credits'입니다

검색하면 아직도 "Make는 operations로 과금한다"는 글이 수두룩합니다. 그런데 Make는 비교적 최근 과금 단위 명칭을 operations에서 credits(크레딧)로 바꿨습니다(정확한 전환 시점은 공식 공지 기준으로 확인하세요). 전환 비율은 1:1이라 계산법은 같지만(기존 1,000 operations = 1,000 credits), 이 사실을 모르면 오래된 튜토리얼을 최신으로 착각하기 쉽습니다.

즉, operations라는 말은 지금도 실행 로그의 데이터 지표로 남아 있지만, 결제·요금제에서 쓰는 공식 단위는 credits입니다. 일꾼 삯 명세서에서 항목 이름만 operations에서 credits로 바뀐 셈이라, 월급 계산법 자체는 그대로예요.

크레딧이 실제로 닳는 계산법 — 초보가 가장 많이 틀리는 곳

공식 문서 기준으로 크레딧이 나가는 규칙은 이렇습니다.

• 기본: 모듈이 데이터 묶음(번들) 하나를 처리할 때마다 1 크레딧. 메일 5통을 보내는 모듈 = 5 크레딧.
• 트리거는 예외 — 새 데이터를 몇 개 가져오든 실행당 1 크레딧. 데이터가 0개여도 체크 1회면 1이 나갑니다.
• 검색(Search) 모듈도 결과를 여러 개 반환해도 실행당 1.
• Iterator는 배열을 낱개로 쪼개는 동작 자체가 1인데, 진짜 함정은 그 뒤 모듈들이 쪼개진 개수만큼 반복된다는 점입니다. 번들 100개면 뒤 일꾼들이 각자 100번씩 사람 몫을 갈아넣습니다.

그리고 여기가 튜토리얼 절반이 틀리는 지점입니다. 크레딧을 아예 안 먹는 것들이 따로 있어요.

크레딧을 먹는다	크레딧을 안 먹는다(공식 문서 기준)
일반 모듈(번들당 1)	필터(Filter)
트리거(실행당 1)	라우터(Router)
Iterator·Aggregator 동작	에러 핸들러(Ignore·Resume·Rollback·Break 등)
AI 모듈(가변, 토큰 기반)	(그 밖의 면제 항목은 공식 문서에서 확인)

즉 필터와 라우터로 흐름을 나누는 건 공짜입니다. 그런데 인기 있는 2차 블로그 여럿이 "필터·라우터도 크레딧을 먹는다"고 반대로 써놨어요 — Make 공식 문서(how-features-use-credits)와 정면으로 충돌합니다. 조건 분기를 아끼느라 워크플로를 이상하게 비틀 이유가 없다는 뜻이니, 이 오해부터 풀고 시작하는 게 이득입니다.

폴링이 지갑을 터는 법 — 데이터가 0개여도 돈이 나갑니다

무료 크레딧을 가장 빨리 태우는 원인은 "잘못 짠 시나리오"가 아니라 폴링(polling) 트리거를 켜놓고 잊는 것입니다. 여러 후기에서 반복해서 나오는 함정이죠.

폴링은 "몇 분마다 새 데이터 있나 확인"하는 방식인데, 앞서 봤듯 트리거는 데이터가 0개여도 체크할 때마다 1 크레딧을 씁니다. 데이터가 없어도 5분마다 출근 도장 찍는 일꾼에게 24시간 꼬박 일당이 나가는 꼴이라, 계산해 보면 살벌합니다.

• 5분 간격 폴링 = 하루 288회 × 30일 ≈ 월 8,640 크레딧 (새 데이터가 하나도 없어도)
• 15분 간격 폴링 = 하루 96회 × 30일 ≈ 월 2,880 크레딧

무료 플랜의 월 크레딧이 1,000이라는 걸 떠올리면, 5분 폴링 시나리오 하나만 켜둬도 무료 한도를 여덟 배 넘겨 태웁니다. "아무것도 안 했는데 왜 크레딧이 없지?"의 정체가 대개 이거예요. 실시간이 꼭 필요한 게 아니라면, 폴링 간격을 늘리거나 가능하면 웹훅(webhook)으로 바꾸는 게 지갑을 지키는 첫 수입니다.

요금제는 어떻게 생겼나 (2026-07 기준·변동 가능)

플랜	월요금(월 결제 기준)	기본 크레딧/월	메모
Free	$0	1,000	활성 시나리오 2개·최소 스케줄 간격 15분(2차 자료 기준)
Core	$9	10,000
Pro	$16	10,000	커스텀 변수·우선 실행
Teams	$29	10,000	팀 협업

요금제는 일꾼 삯 계약서라고 보면 됩니다. 초보가 오해하는 지점 하나 더 — Core·Pro·Teams는 기본 크레딧이 똑같이 10,000에서 시작하고, 월급 차이는 크레딧 양이 아니라 기능(우선 실행, 팀 협업 등)에서 납니다. "비싼 플랜일수록 크레딧이 많다"가 아니에요. 연간 결제는 약 15% 이상 할인으로 안내되는데, 정확한 월 환산가는 공식 페이지에서 연간 옵션을 골라야 보이니 결제 전 확인이 필요합니다.

그래서 뭘 만들 수 있나 — 실제 시나리오 예시

후기와 공식 템플릿을 모아 보면, 초보가 흔히 만드는 시나리오는 대략 이런 모양입니다.

• 폼 → 시트 → 알림: 웹폼/광고 리드 → Google Sheets에 행 추가 → 라우터로 담당자 분기 → Slack·이메일 알림.
• SNS 콘텐츠 예약 발행: 시트에 주제 입력 → OpenAI 모듈이 본문·이미지 생성 → 승인 라우팅 → Buffer/링크드인으로 예약 발행.
• AI 콘텐츠 파이프라인: RSS 새 글 감지 → 요약·재작성 → 초안을 시트에 "검토 대기"로 저장(사람이 확인 후 발행).
• 인보이스 파싱: Gmail로 PDF 수신 → 첨부 추출 → 금액·기한 파싱 → 회계 앱에 승인 대기 레코드로 등록.

이들의 공통점은 하나입니다. 잘 짠 시나리오는 AI 일꾼이 뽑아낸 결과를 곧장 내보내지 않고 '사람 검토' 한 칸을 끼워 둡니다. 일꾼을 부려먹되 최종 결재는 사장이 하는 셈이죠 — 자동화의 목적은 무인화가 아니라 잡일 제거니까요. AI 콘텐츠를 이렇게 반자동으로 굴리는 전체 그림은 AI 콘텐츠 제작 워크플로 글에서 더 넓게 다뤘습니다.

에러 핸들링 없이 돌리면 생기는 일

초급 튜토리얼 대부분이 '해피 패스'만 보여주고 넘어가는 부분입니다. 일꾼을 야근까지 시켜 놓고 감시를 안 붙이면 여기서 사고가 나요 — 실사용자들이 공통으로 꼽는 진짜 고통이 여기 있습니다.

• 조용한 실패(silent failure): 시나리오가 초록불(성공)로 뜨는데 실제 출력은 틀린 경우가 있습니다. 모듈별 입출력을 하나씩 대조하기 전엔 모르죠.
• 기본 동작은 '멈춤': 에러 핸들러를 안 붙이면 오류가 나는 순간 롤백되며 멈추고, 반복되면 시나리오 자체가 꺼지기도 합니다. 새벽에 API가 한 번 타임아웃 나서 파이프라인이 몇 시간째 죽어 있어도 아무도 모르는 상황이 흔해요.

그래서 후기들이 입을 모으는 조언이, 중요한 시나리오에는 에러 핸들러(Ignore·Resume·Rollback·Break 등)를 명시적으로 붙이라는 겁니다. 에러 핸들러는 크레딧을 먹지 않으니 아끼지 말고 다세요. (에러 핸들러의 정확한 종류·동작은 공식 문서 표기가 페이지마다 조금씩 달라, 설정 전 최신 문서를 확인하길 권합니다.)

Make를 쓰지 말아야 할 때

다만 이 일꾼을 아예 안 뽑는 게 나은 경우도 있습니다. 월급(크레딧)이 감당 안 되거나 애초에 일이 안 맞는 자리들이죠. 여러 비교 글을 모아 보면 대체로 이렇게 정리됩니다.

• 거의 실시간이 필요해 폴링을 아주 촘촘히 가져가야 하는 경우 → 크레딧이 감당 안 됨.
• 셀프 호스팅·데이터 주권이 필수인 규제 업종 → Make는 SaaS 전용이라 부적합. n8n 같은 자체 호스팅 대안이 거론됩니다.
• 복잡한 커스텀 코드·외부 라이브러리가 많이 필요한 경우 → Make의 코드 실행에는 제약이 있다는 후기가 많습니다.
• 예산이 빠듯한데 큰 반복 루프(수백~수천 번들)를 돌려야 하는 경우 → Iterator 배수 효과로 크레딧이 폭발.

후기 종합 — 사람들이 반복해서 하는 말

• 칭찬: 비주얼 드래그앤드롭 빌더로 복잡한 다단계 흐름을 코드 없이 짤 수 있다는 점. 같은 월급(예산)으로 경쟁 일꾼보다 조건 분기를 촘촘히 시킬 수 있다는 가성비 평가(리뷰 사이트 평점도 대체로 높은 편).
• 불만: 에러 메시지가 불친절하다, Iterator·Aggregator 같은 고급 기능은 처음엔 확실히 어렵다, 그리고 앞서 말한 크레딧 소진 속도.

정리 — 첫 시나리오를 켜기 전에

• 이 시나리오의 트리거가 폴링인가? 그렇다면 간격 × 30일로 월 크레딧을 먼저 암산.
• 필터·라우터는 공짜니, 조건 분기를 아끼지 말 것.
• 진짜 크레딧 먹는 곳은 Iterator 뒤 '모듈 수 × 번들 수'.
• 중요한 시나리오엔 에러 핸들러를 붙일 것(무료).
• 실시간·셀프호스팅·큰 루프가 필요하면 Make가 최선인지 다시 판단.

자동화의 성패는 모듈을 얼마나 화려하게 붙이느냐가 아니라, 한 달 크레딧을 예측할 수 있느냐에서 갈립니다. 계산이 되는 사람에게 Make는 월급 싼 일꾼이고, 안 되는 사람에게는 조용히 새는 수도꼭지예요.

참고자료

• Make 요금제 — make.com/en/pricing
• 기능별 크레딧 소모 규칙(공식) — help.make.com/how-features-use-credits
• operations → credits 전환 공지(공식) — help.make.com
• operation 정의(공식) — help.make.com/operations
• 라우터·애그리게이터 개념(공식) — help.make.com
• Make 사용자 리뷰(2차) — g2.com
• n8n·Make·Zapier 비교(2차) — digidop.com

---

이 글은 Make 공식 문서와 요금 페이지의 문면을 기준으로, 초보가 실제로 밟는 지점을 정리한 큐레이션입니다. 시네가 Make로 장기간 자동화를 운영한 1인칭 후기가 아닙니다. 작성에 AI의 도움을 받았습니다.