Make 자동화 2026: 첫 자동화는 따라 만들었는데 그 다음이 막히는 이유
유튜브 튜토리얼을 보며 Make 자동화 첫 시나리오를 따라 만들었습니다. 지메일에 메일이 오면 구글 시트에 한 줄 추가하기. 'ON'을 누르니 정말 동작하네요. 그런데 딱 거기까지입니다. "그래서 이제 뭘 자동화하지?"라는 질문 앞에서 멈추고, 며칠 뒤엔 만들어둔 시나리오마저 켜둔 채 방치됩니다. Make 자동화를 시작한 사람 상당수가 바로 이 지점에서 멈춥니다. 이 글에서는 첫 시나리오 다음이 막히는 이유와, 무엇을 자동화할지 고르는 법, 그리고 무료 플랜에서 의외로 빨리 닳는 크레딧을 아끼는 실전 방법을 정리합니다.
왜 첫 시나리오 다음이 막힐까
막히는 이유는 크게 두 가지입니다. 첫째는 "도구는 배웠는데 문제를 못 찾는" 상태이고, 둘째는 "한도와 비용 구조를 몰라서 불안한" 상태입니다. 튜토리얼은 보통 도구 사용법(모듈 연결, 데이터 매핑)만 알려주기 때문에, 막상 내 일상에서 반복 작업을 골라내는 감각은 따로 길러야 합니다. 도구를 한 번 더 익히는 것보다, 내 업무에서 자동화할 거리를 찾고 비용 구조를 이해하는 쪽이 다음 단계로 넘어가는 열쇠입니다.
크레딧 개념부터 짚고 가기
예전에 Make는 작업량을 'operations(작업 수)'로 셌지만, 2025년 8월 27일부터 'credits(크레딧)' 체계로 명칭과 계산 방식을 정리했습니다. 핵심 원리는 단순합니다. 시나리오 안에서 모듈 하나가 실제로 실행될 때마다 1 크레딧이 차감됩니다. 예를 들어 모듈 3개짜리 시나리오가 10개의 항목을 처리하면 대략 30 크레딧이 쓰입니다. 이 구조를 모르면 "왜 이번 달 한도가 벌써 끝났지?"라는 일이 생깁니다. 자세한 플랜·크레딧 정책은 Make 공식 요금제 페이지에서 확인할 수 있습니다(본 글 작성 시점 기준).
무료 플랜으로 어디까지 되나
본 글 작성 시점 기준, 무료 플랜의 주요 한도는 아래와 같습니다. 학습과 가벼운 개인 자동화에는 충분하지만, 시나리오를 여러 개 상시 돌리려 하면 금방 천장에 닿습니다.
| 항목 | 무료 플랜 | Core 플랜(유료 입문) |
|---|---|---|
| 월 크레딧 | 1,000 | 10,000 |
| 활성 시나리오 수 | 2개 | 다수 |
| 최소 실행 간격 | 15분 | 더 짧게 가능 |
| 대략 가격 | 무료 | 월 약 $10.59부터 |
여기서 중요한 건 '활성 시나리오 2개'와 '월 1,000 크레딧'이라는 두 제약을 어떻게 쓰느냐입니다. 무턱대고 많이 만드는 게 아니라, 효과 큰 자동화 하나를 제대로 굴리는 쪽이 무료 플랜에 맞습니다. 한도에 닿으면 그달의 자동화가 멈추기 때문에, 처음부터 '아껴 쓰는 설계'를 염두에 두는 게 좋습니다.
무엇을 자동화할지 고르는 법
막힘의 절반은 '소재 부족'입니다. 자동화 후보를 찾는 가장 쉬운 기준은 자주 + 규칙적 + 손이 가는 일입니다. 세 가지가 겹칠수록 자동화 효과가 큽니다.
- 자주 반복되는가 — 한 달에 한 번 하는 일보다 매일/매주 하는 일이 먼저입니다.
- 규칙이 명확한가 — "이게 오면 → 저걸 한다"로 한 문장에 정리되면 좋은 후보입니다.
- 판단이 거의 없는가 — 사람의 주관적 판단이 많이 들어가는 일은 자동화가 어렵습니다.
예를 들어 "문의 메일이 오면 시트에 기록하고 슬랙으로 알림", "매주 월요일 아침 정해진 보고서 양식 메일 발송", "폼 응답이 들어오면 노션 DB에 카드 생성" 같은 일이 전형적인 첫 자동화 후보입니다. 거창한 'AI 워크플로우'를 떠올리기 전에, 내가 매주 복붙하고 있는 단순 작업부터 적어보세요. 일주일만 자신의 업무를 관찰하며 "또 이걸 하고 있네" 싶은 순간을 메모해두면, 자동화 후보 목록이 금세 쌓입니다.
무료 플랜 크레딧을 아끼는 실전 팁
같은 자동화라도 설계에 따라 크레딧 소모가 몇 배 차이 납니다. 무료 1,000 크레딧을 오래 쓰려면 아래를 챙기세요.
1. 폴링 대신 웹훅(Webhook)을 쓴다
이게 가장 큰 차이를 만듭니다. '폴링(Watch) 트리거'는 새 데이터가 있는지 주기적으로 확인하는데, 확인하는 행위 자체가 크레딧을 먹습니다. 예를 들어 구글 드라이브 폴더를 5분마다 확인하도록 두면 하루 288번, 한 달이면 8,000건이 넘는 확인만으로 크레딧이 소진될 수 있습니다. 반면 웹훅은 평소 대기할 땐 크레딧을 쓰지 않고 실제 이벤트가 발생한 순간에만 차감됩니다. 폴링을 웹훅으로 바꾸는 것만으로 사용량을 크게 줄일 수 있다고 알려져 있습니다.
2. 필터로 불필요한 실행을 막는다
필터를 걸면 조건에 맞지 않는 경우 시나리오가 중간에 멈춰, 뒤따르는 모듈이 실행되지 않습니다. "제목에 [중요]가 포함된 메일만 처리" 같은 조건을 앞단에 두면, 의미 없는 실행에 크레딧을 낭비하지 않습니다. 필터는 단순히 크레딧을 아끼는 장치일 뿐 아니라, 엉뚱한 데이터가 뒤 모듈로 흘러가는 사고도 막아줍니다.
3. 처음부터 복잡하게 짜지 않는다
모듈 2~3개로 시작해 동작을 확인하고 하나씩 늘리는 편이, 15개짜리 시나리오를 한 번에 만들어 디버깅하는 것보다 빠릅니다. 복잡한 시나리오는 고장 지점을 찾기 어렵고, 잘못 돌면 크레딧도 빨리 닳습니다. 한 모듈을 추가할 때마다 실행 결과를 확인하는 습관을 들이면, 어디서 무엇이 잘못됐는지 곧바로 보입니다.
흔한 실수 체크리스트
- 여러 항목을 처리해야 하는데 이터레이터(Iterator)를 빼먹어 첫 항목만 처리되는 경우
- 다음 모듈 입력 칸에 데이터(필드)를 매핑하지 않아 결과가 빈칸으로 나오는 경우
- 저장만 하고 스위치를 'ON'으로 켜지 않아 아무 일도 일어나지 않는 경우
- 한도 경고 알림을 꺼둬, 자동화가 멈춘 뒤에야 한도 초과를 알아차리는 경우
마지막 항목은 계정 설정에서 크레딧 한도 접근 시 이메일 알림을 켜두면 예방할 수 있습니다.
크레딧 소모, 실제로 계산해 보기
감을 잡기 위해 간단한 예시를 들어보겠습니다. "새 문의 메일이 오면 → 시트에 기록 → 슬랙 알림"이라는 모듈 3개짜리 시나리오가 있다고 가정합시다. 하루에 문의가 20건 들어온다면, 한 건당 약 3 크레딧이 쓰이므로 하루 약 60 크레딧, 한 달이면 1,800 크레딧 수준입니다. 무료 한도(월 1,000)를 이미 넘어섭니다. 그런데 같은 시나리오라도 트리거를 폴링이 아닌 웹훅으로 잡고, "스팸·광고 메일은 제외"하는 필터를 앞단에 두면 실제 처리 건수가 줄어 소모가 한결 가벼워집니다. 숫자로 보면 왜 설계가 중요한지 분명해집니다.
자주 묻는 질문(FAQ)
무료 플랜에서 1분마다 실행할 수 있나요?
아니요. 무료 플랜은 예약 실행의 최소 간격이 15분입니다. 더 짧은 간격이 필요하면 유료 플랜을 검토해야 합니다. 다만 웹훅 트리거는 '간격'이 아니라 '이벤트 발생 즉시' 동작하므로, 빠른 반응이 필요할 땐 웹훅을 우선 고려하세요.
시나리오를 3개 이상 켜둘 수 있나요?
무료 플랜은 동시에 활성화할 수 있는 시나리오가 2개까지입니다. 그래서 무료 구간에서는 '많이 만들기'보다 '효과 큰 것 한두 개를 잘 굴리기'가 현실적인 전략입니다.
연동하고 싶은 앱이 목록에 없으면요?
Make는 3,000개 이상의 앱 연동을 제공하지만, 원하는 서비스가 없을 수 있습니다. 이 경우 해당 서비스가 API를 제공한다면 범용 HTTP 모듈로 직접 호출해 연결하는 방법이 있습니다. 다만 API 직접 연결은 난도가 있으니, 처음에는 기본 제공 연동부터 익히는 편이 좋습니다.
결론
Make 자동화에서 막히는 건 도구가 어려워서가 아니라, '무엇을 자동화할지'와 '크레딧을 어떻게 아낄지'를 아무도 안 알려줬기 때문입니다. 자주·규칙적·손 가는 일 하나를 골라 모듈 2~3개로 작게 시작하고, 폴링 대신 웹훅과 필터로 크레딧을 아끼면 무료 플랜만으로도 꽤 멀리 갈 수 있습니다. 오늘 당장 내가 매주 반복하는 단순 작업 하나를 적어보고, 그것부터 자동화해보세요.
※ 본 글은 일반 정보 제공 목적이며, 요금제·한도 등 시점 의존 정보는 변경될 수 있으니 Make 공식 페이지에서 최신 내용을 확인하시기 바랍니다.
댓글
댓글 쓰기