Make.com을 처음 쓰기 시작했을 때 저는 시나리오 하나에 모든 걸 다 때려 넣었습니다. Claude API 호출, WordPress 발행, Slack 알림, 에러 로깅까지 모듈 30개짜리 괴물 시나리오가 탄생했고, 이틀 만에 무너졌습니다. 원인을 찾는 데만 3시간이 걸렸고, 고치는 데 또 2시간이 걸렸습니다. 그때부터 저는 시나리오 설계를 건축처럼 접근하기 시작했습니다. 이번 칼럼에서는 제가 9주차까지 운영하면서 체득한 Make.com 시나리오 설계 패턴 세 가지를 공유합니다. 틀을 먼저 잡으면 나중에 고치는 비용이 극적으로 줄어듭니다.
단일 책임 원칙 — 시나리오 하나에 역할 하나만 줘라
소프트웨어 설계의 단일 책임 원칙(SRP)을 Make.com에 그대로 적용했을 때 가장 큰 변화가 생겼습니다. 저는 지금 블로그 자동화 파이프라인을 총 4개의 독립 시나리오로 나눠 운영합니다. 첫째, 트리거 수집 시나리오 — 외부 웹훅을 받아서 Google Sheets에 데이터를 저장하기만 합니다. 둘째, 콘텐츠 생성 시나리오 — Sheets에서 데이터를 읽어 Flask API를 호출하고 Claude 응답을 받아 Sheets에 다시 씁니다. 셋째, 발행 시나리오 — 생성 완료된 행을 감지해 WordPress REST API로 발행합니다. 넷째, 알림 시나리오 — 발행 완료 후 Slack 메시지를 보냅니다. 이렇게 분리하면 콘텐츠 생성 단계에서 Claude API가 타임아웃 나도 발행 시나리오에는 영향이 없습니다. 각 시나리오가 독립적으로 실패하고, 독립적으로 재시도됩니다. 처음에는 시나리오 수가 늘어나는 게 부담스러웠지만, 에러 발생 시 원인 파악 시간이 체감상 5분의 1로 줄었습니다. Make.com의 실행 히스토리가 시나리오별로 분리되어 있어서, 어느 단계에서 멈췄는지 바로 보입니다. 설계 원칙은 단순합니다. 시나리오 이름을 한 문장으로 설명할 수 없으면 쪼개야 합니다.
에러 핸들링 설계 — 실패를 예상하고 설계에 포함시켜라
Make.com 초보 시절 저는 에러 핸들링을 나중에 추가하면 된다고 생각했습니다. 이건 완전히 틀린 접근이었습니다. 에러는 설계 단계부터 포함시켜야 합니다. 제가 실제로 쓰는 패턴 세 가지를 소개합니다. 첫 번째는 Router + Filter 패턴입니다. Claude API 응답을 받은 뒤 Router 모듈로 분기합니다. 응답 상태코드가 200이면 정상 경로, 그 외면 에러 경로로 분기해서 Google Sheets 에러 로그 행에 타임스탬프, 에러 코드, 입력 데이터를 기록합니다. 두 번째는 Break 모듈 활용입니다. 반복 처리 중 특정 건이 실패해도 전체가 멈추지 않게 하려면 Iterator 내부에 Break 설정을 켜고, 실패한 건만 별도 Sheets 탭에 기록합니다. 나중에 수동으로 재처리하거나 별도 시나리오로 재시도합니다. 세 번째는 HTTP 모듈 타임아웃 설정입니다. Flask API 호출 시 기본 타임아웃은 40초인데, 저는 Claude API 응답이 길어질 때를 대비해 90초로 늘리고, 재시도 횟수는 2회로 설정합니다. 설정 위치는 HTTP 모듈의 Advanced Settings 탭 안에 있습니다. 에러가 나지 않는 시나리오를 만드는 것보다, 에러가 나도 데이터가 사라지지 않는 시나리오를 만드는 게 훨씬 현실적이고 중요합니다.
데이터 흐름 설계 — Google Sheets를 중간 저장소로 쓰는 이유
Make.com 시나리오끼리 데이터를 주고받는 방법은 여러 가지가 있습니다. Data Store, 웹훅, 외부 DB 등등. 저는 현재 Google Sheets를 중심 저장소로 씁니다. 이유는 세 가지입니다. 첫째, 사람이 읽을 수 있습니다. 자동화가 돌아가는 중간 상태를 제가 눈으로 확인할 수 있고, 이상한 값이 들어왔을 때 셀을 직접 수정해서 재처리할 수 있습니다. 둘째, 시나리오 간 의존성을 끊어줍니다. 생성 시나리오와 발행 시나리오는 Sheets 행의 상태값(대기중 / 생성완료 / 발행완료)만 보고 판단합니다. 서로의 실행 시점을 몰라도 됩니다. 셋째, 무료 플랜에서도 동작합니다. Make.com Data Store는 플랜에 따라 용량 제한이 있지만, Sheets는 제약이 훨씬 느슨합니다. 실제 제가 쓰는 Sheets 구조는 이렇습니다. A열: 고유 ID (타임스탬프 기반), B열: 상태값, C열: 원본 입력 데이터(JSON 문자열), D열: 생성된 콘텐츠 JSON, E열: WordPress 발행 URL, F열: 에러 메시지. Make.com에서 Search Rows 모듈로 B열 값이 ‘생성완료’인 행을 찾아 발행 시나리오가 가져가는 방식입니다. 상태값 기반 폴링이라서 직관적이고 디버깅이 쉽습니다. 복잡해 보이지만 실제로는 스프레드시트 한 장이 전체 파이프라인의 컨트롤 타워 역할을 합니다.
💬 운영자 한마디
저는 Make.com을 쓰면서 자동화란 결국 실패를 얼마나 우아하게 처리하느냐의 문제라는 걸 배웠습니다. 시나리오가 절대 안 멈추는 게 목표가 아니라, 멈춰도 데이터가 살아있고 원인을 5분 안에 찾을 수 있는 구조를 만드는 게 목표입니다. 이 세 패턴을 갖추고 나서야 주말에 시스템을 열어보지 않아도 불안하지 않게 됐습니다.
— J_River · autoprofit 운영자
✅ 이번 주 체크리스트
- 현재 시나리오 하나가 하는 일을 한 문장으로 적어보기 — 두 가지 이상이면 분리 검토
- HTTP 모듈의 Advanced Settings에서 타임아웃과 재시도 횟수 확인하기
- Router 모듈을 써서 성공/실패 경로를 명시적으로 분기하고 있는지 점검
- 에러 발생 시 데이터가 어디에 기록되는지 경로 확인하기 — 사라지면 안 됨
- 시나리오 간 공유 데이터를 Google Sheets 또는 Data Store 중 어디에 둘지 기준 정하기
- 각 시나리오 이름에 역할이 명확히 드러나는지 확인 (예: content-generate, wp-publish)
- 실행 히스토리에서 가장 최근 에러 로그를 열어 원인 파악까지 몇 분 걸리는지 재보기
설계는 처음 한 번 제대로 하면 나중에 계속 이자를 줍니다. Make.com 시나리오도 마찬가지입니다. 지금 당장 동작하는 것보다, 6개월 뒤에도 내가 알아볼 수 있는 구조를 만드는 게 더 가치 있습니다.
※ 본 콘텐츠는 운영자 개인의 경험과 연구를 바탕으로 한 정보 제공 목적이며, 특정 종목에 대한 투자 권유나 매매 시그널이 아닙니다. 암호화폐 및 자동매매는 원금 손실 가능성이 있는 고위험 활동이며, 모든 투자 판단과 그 결과에 대한 책임은 투자자 본인에게 있습니다.