운영 10주차가 됐을 때 저는 Make.com 대시보드를 열고 잠깐 멈칫했습니다. 한 달 오퍼레이션 사용량이 예상의 3배를 넘어 있었습니다. 블로그 자동 발행, 시황 리포트 생성, 웹훅 수신까지 파이프라인이 늘어나면서 모듈 하나하나가 쌓인 결과였습니다. 처음엔 단순히 시나리오를 더 만들면 된다고 생각했는데, 문제는 설계 방식에 있었습니다. 이번 칼럼은 그 과정에서 직접 겪고 고친 Make.com 비용 폭증 방지 전략을 솔직하게 공유합니다.
왜 오퍼레이션이 예상보다 많이 쓰이는가: 구조적 원인부터 파악하기
Make.com은 각 모듈 실행 1회를 오퍼레이션 1회로 카운트합니다. 단순해 보이지만, 실제 운영에서는 이 계산이 생각보다 훨씬 빠르게 쌓입니다. 제가 처음 만든 블로그 자동 발행 시나리오는 웹훅 수신 → 데이터 파싱 → Claude API 호출 → 워드프레스 포스팅 → 슬랙 알림 순서로 구성했습니다. 모듈 수로는 5개인데, 하루 10회 트리거되면 하루 50 오퍼레이션입니다. 여기에 에러 핸들링용 분기, 필드 매핑용 Set Variable 모듈 등을 추가하면 실제 오퍼레이션은 모듈 수의 1.5~2배가 됩니다. 더 큰 문제는 트리거 방식이었습니다. 처음에 Scheduled(5분 간격) 트리거를 쓰면서 데이터가 없어도 매 5분마다 시나리오가 실행됐습니다. 하루 288회 실행, 모듈 5개면 하루 1,440 오퍼레이션이 그냥 소모됩니다. 자동화 흐름이 복잡할수록 이 낭비가 기하급수적으로 늘어납니다. 구조적 원인을 파악하려면 Make.com의 시나리오 히스토리에서 각 실행의 오퍼레이션 수를 확인하고, 실제로 의미 있는 데이터를 처리한 실행과 빈 실행을 구분해야 합니다. 저는 이 분석에서 전체 실행의 약 60%가 처리할 데이터가 없는 상태에서 실행된 것을 발견했습니다.
핵심 절약 전략 3가지: 필터, 라우터, 웹훅 전환
원인을 파악하고 나서 실제로 적용한 전략은 크게 세 가지입니다. 첫 번째는 Scheduled 트리거를 가능한 한 웹훅 트리거로 교체하는 것입니다. 웹훅은 외부에서 신호가 들어올 때만 시나리오를 실행합니다. 저는 TradingView 알림, Flask API 이벤트, 워드프레스 훅을 모두 웹훅으로 연결해 불필요한 폴링 실행을 완전히 제거했습니다. 두 번째는 시나리오 맨 앞에 필터 모듈을 추가하는 것입니다. Make.com의 Filter는 오퍼레이션을 소모하지 않습니다. 조건이 맞지 않으면 이후 모든 모듈 실행을 건너뜁니다. 예를 들어 ‘수신 데이터의 type 필드가 blog_publish일 때만 진행’ 조건을 넣으면, 다른 종류의 웹훅 요청이 들어와도 오퍼레이션 낭비 없이 차단됩니다. 세 번째는 라우터(Router)로 시나리오를 분기할 때 각 경로에 필터를 먼저 달아두는 것입니다. 라우터 자체는 1 오퍼레이션이지만, 각 경로의 조건이 맞지 않으면 그 경로의 모듈들은 실행되지 않습니다. 라우터 하나로 블로그 발행, 시황 리포트, 슬랙 알림을 분기하면 시나리오 수를 줄이면서도 오퍼레이션 낭비를 막을 수 있습니다. 이 세 가지만 적용해도 저는 월간 오퍼레이션 사용량을 기존 대비 약 절반 수준으로 줄일 수 있었습니다. 정확한 수치는 검증 중이지만, 체감 차이는 꽤 명확했습니다.
실전 적용: 블로그 자동 발행 파이프라인 재설계 사례
가장 오퍼레이션을 많이 쓰던 블로그 자동 발행 시나리오를 실제로 어떻게 바꿨는지 공유합니다. 기존 구조는 Scheduled(10분 간격) → HTTP GET(새 데이터 확인) → JSON Parse → Claude API → WordPress → Slack 알림 순서였습니다. 10분 간격이고 모듈 6개니까 하루 최대 864 오퍼레이션이 기본으로 쌓였습니다. 재설계 후 구조는 Custom Webhook 트리거 → Filter(type=blog_post인지 확인) → Claude API → WordPress → Slack 알림입니다. 이제 Flask API 서버에서 블로그 발행이 필요할 때만 Make.com 웹훅을 호출합니다. 호출 1회당 모듈 4개 실행(Filter는 카운트 제외), 하루 발행 건수가 5개면 하루 20 오퍼레이션입니다. 데이터 확인용 HTTP 모듈을 Flask 서버 측으로 옮긴 것도 중요한 변화입니다. Make.com에서 외부 API를 주기적으로 폴링하는 대신, 파이썬 스크립트가 조건을 판단하고 필요할 때만 웹훅을 쏘는 구조입니다. Make.com은 실행 엔진으로만 쓰고, 판단 로직은 Flask/파이썬 쪽에서 처리하는 역할 분리가 핵심입니다. 이 방식은 Make.com 비용 절감뿐 아니라 디버깅도 훨씬 쉬워집니다. 파이썬 로그로 어디서 웹훅을 쏘는지 추적할 수 있고, Make.com 히스토리에는 실제 처리된 건만 남습니다. 시나리오가 복잡해질수록 이 구조 분리의 이점이 더 커집니다.
💬 운영자 한마디
저는 Make.com을 처음 쓸 때 오퍼레이션 개념을 너무 단순하게 생각했습니다. 모듈 수 곱하기 실행 횟수라는 공식은 알았지만, 빈 실행과 폴링 낭비를 고려하지 않았습니다. 지금은 새 시나리오를 만들 때 항상 먼저 묻습니다. 이 트리거가 정말 필요할 때만 실행되는가, 필터가 가장 앞에 있는가, 판단 로직이 Make.com 안에 있어야 하는가. 이 세 가지 질문이 비용 설계의 시작이라고 생각합니다.
— J_River · autoprofit 운영자
✅ 이번 주 체크리스트
- Make.com 시나리오 히스토리에서 빈 실행(Empty run) 비율을 먼저 확인한다
- Scheduled 트리거를 Custom Webhook 트리거로 교체할 수 있는지 검토한다
- 각 시나리오 맨 앞에 Filter 모듈을 추가해 조건 불일치 시 즉시 종료되도록 설정한다
- 라우터 분기 각 경로에 Filter 조건을 달아 불필요한 모듈 실행을 차단한다
- 외부 API 폴링 로직은 Flask/파이썬 서버로 옮기고 Make.com은 실행 엔진으로만 사용한다
- 월간 오퍼레이션 사용량을 Make.com 대시보드에서 주 1회 이상 점검하는 루틴을 만든다
- 시나리오별 평균 오퍼레이션 수를 기록해두고 리팩터링 전후 비교를 남긴다
자동화 비용은 설계 단계에서 대부분 결정됩니다. 나중에 줄이려면 구조를 뜯어야 하지만, 처음부터 웹훅과 필터 중심으로 만들면 비용도 유지보수도 훨씬 가볍습니다. 이번 주 시나리오 히스토리 한 번만 열어보시길 권합니다.
※ 본 콘텐츠는 운영자 개인의 경험과 연구를 바탕으로 한 정보 제공 목적이며, 특정 종목에 대한 투자 권유나 매매 시그널이 아닙니다. 암호화폐 및 자동매매는 원금 손실 가능성이 있는 고위험 활동이며, 모든 투자 판단과 그 결과에 대한 책임은 투자자 본인에게 있습니다.