Make.com 시나리오 에러 모니터링·자동 복구 5가지 패턴 2026 (Break·Resume·Retry)

‘Make.com 자동화 잘 돌아가다가 한 달 후 갑자기 멈췄어요’가 1인 운영 자동화의 가장 흔한 사고 패턴이에요. 원인을 파고들면 대부분 에러 핸들러를 안 박았거나, 박았어도 retry 설정이 잘못된 경우로 모입니다. 결국 운영 신뢰성은 툴의 기본 동작에 기대는 게 아니라 직접 설계해야 하는 영역이에요. 이 글에선 Make.com 시나리오 에러 모니터링·자동 복구 5가지 표준 패턴을 정리합니다.

1. 5가지 에러 핸들러 — 언제 무엇을 쓰나

Make.com이 제공하는 5가지 핸들러의 동작과 적합 시나리오를 정리하면:

선택 결정 트리는 단순해요. ‘이 모듈 실패하면 전체 시나리오를 멈춰야 하나?’ — yes면 Break, no면 Resume. ‘DB·트랜잭션 묶음 작업인가?’ — yes면 Commit/Rollback. ‘로그·알림·통계처럼 실패해도 본질에 영향 없나?’ — yes면 Ignore. 이 세 질문으로 90% 이상 결정됩니다.

2. 재시도 정책 — 기본 동작에 기대지 말 것

가장 많이 하는 오해가 ‘일시적인 에러는 알아서 다시 시도되겠지’예요. 어떤 에러가 어떤 조건에서 재시도되는지는 모듈과 연결 서비스마다 다르고, 정책도 시점에 따라 바뀝니다. 그래서 재시도가 필요한 모듈에는 재시도를 직접 설정한다가 안전한 전제예요.

재시도를 설계할 때 기준은 두 가지입니다. 첫째, 다시 시도해서 풀릴 성격의 에러인가. 네트워크 지연이나 호출량 제한처럼 시간이 지나면 해소되는 에러는 재시도가 통해요. 반면 인증 만료나 데이터 형식 오류는 백 번 시도해도 같은 결과라 사람이 손대야 합니다. 둘째, 재시도 간격을 점점 늘리는 지수 백오프를 쓸 것. 같은 간격으로 몰아치면 상대 API에 부담을 주고, 호출량 제한 에러라면 오히려 상황을 악화시켜요.

그리고 재시도는 공짜가 아니에요. 시도할 때마다 Operation이 추가로 소모되기 때문에, 대량 처리 시나리오에서 재시도를 넉넉히 잡아두면 월 한도가 예상보다 빨리 닳습니다. 한도 초과로 시나리오가 정지되는 사고가 원래 막으려던 에러보다 더 큰 피해로 돌아오는 게 흔한 함정이에요. 처리량이 많은 시나리오라면 ‘일정 시간 후 일괄 재시도 + 사람 검토 큐’ 패턴이 더 안전합니다.

3. Break 핸들러 — 운영 시나리오 표준

운영 자동화에서 가장 손이 자주 가는 게 Break 핸들러예요. 표준 설정은 다음과 같아요:

• Number of attempts: 짧게 (간격은 지수 백오프로 점점 늘려서)
• Allow storing of incomplete executions: ON (재시도 실패 시 incomplete execution에 저장)
• Maximum number of attempts: 자동 시도보다 조금 넉넉하게 (수동 재시도 포함 총 한도)
• 다음 모듈: ‘Add to Notion DB’ 또는 ‘Slack 알림’ 액션

핵심은 ‘자동으로 몇 번 시도 + 사람이 판단해서 몇 번 더’ 구조예요. 자동 시도로 안 풀리면 incomplete execution에 저장하고 사람에게 알림을 보냅니다. 사람이 검토해서 수동으로 다시 돌리거나, 영구 에러로 판단하면 폐기하는 흐름이죠. 이 구조가 없는 시나리오는 일시 에러가 영구 에러처럼 묻혀버립니다.

4. 멱등성 확보 — 재시도가 안전하려면

재시도 패턴이 무서운 함정 한 가지가 ‘중복 처리’예요. ‘리드 1명 등록’ 모듈이 에러로 재시도됐는데, 1차 시도가 사실 성공했지만 응답이 안 온 거였다면 재시도로 같은 리드가 두 번 등록되거든요. CRM에 중복 레코드 누적 → 수동 정리 작업 필요 → 부업 자동화의 의미가 사라져요.

멱등성(idempotency) 확보 표준 패턴 세 가지:

1. 외부 키 기반 upsert: 이메일·전화번호·고객 ID를 unique 키로 지정, ‘있으면 update, 없으면 insert’.
2. 사전 검색 모듈: 재시도 가능 모듈 앞에 ‘이미 존재하면 skip’ 로직 추가. Notion·Airtable에서 ‘Search Records’ 모듈 → Router로 분기.
3. 트랜잭션 ID 부여: 자체 생성한 UUID를 외부 시스템에 함께 전달, 동일 ID 두 번째 처리는 차단.

셋 중에서는 1번(upsert)이 가장 손이 덜 가요. CRM·DB 도구 상당수가 upsert를 지원하기 때문에 모듈 설정에서 unique 키만 지정하면 끝나거든요. 연결 서비스가 upsert를 지원하지 않는다면 2번(사전 검색)으로, 외부 API를 직접 호출하는 구조라면 3번(트랜잭션 ID)으로 가면 됩니다. 멱등성 없는 자동화에 재시도 박는 건 ‘사고 가속화’예요.

5. 에러 로그 적재 — 추세가 보여야 근본 원인이 잡힌다

앞의 네 가지를 다 해놔도 마지막 한 조각이 빠지면 같은 사고가 반복돼요. 바로 에러를 쌓아서 보는 습관입니다. Make 안에서는 시나리오별 실행 기록과 incomplete execution 목록으로 개별 실패를 확인할 수 있지만, 이건 ‘어제 저 모듈이 실패했다’는 점 하나만 알려줘요. 정작 필요한 건 ‘이 실패가 처음인지, 매주 같은 시간대에 반복되는지’거든요.

그래서 Break 핸들러 다음에 로그 적재 모듈을 하나 더 붙이는 패턴을 권합니다. Notion DB나 Airtable에 아래 네 가지를 함께 기록해두세요.

1. 발생 시각: 특정 시간대에 몰리는지 보려면 필수예요.
2. 시나리오명·모듈명: 어디가 약한 고리인지 바로 드러납니다.
3. 에러 유형: 연결 문제인지, 인증 문제인지, 데이터 문제인지 나눠 담아야 대응이 갈려요.
4. 관련 데이터: 어떤 입력에서 터졌는지 있어야 재현하고 고칠 수 있어요.

이렇게 쌓이면 대응 방향이 명확해져요. 연결·타임아웃 계열이 대부분이면 재시도 설정을 손보면 되고, 인증 실패가 반복되면 토큰 갱신 자동화를 따로 만들어야 합니다. 특정 시간대에 몰린다면 스케줄을 그 시간대에서 비켜 잡는 것만으로 해결되는 경우도 많아요. ‘잘 돌아가던 자동화가 어느 날 멈춤’ 사고가 났다면, 개별 실행 기록을 뒤지기 전에 쌓아둔 로그부터 훑는 게 훨씬 빠른 트러블슈팅 절차예요.

마치며 — 에러 핸들러가 자동화 수익의 결정 변수

결론을 정리하면 — ‘잘 만든 자동화’보다 ‘잘 무너지지 않는 자동화’가 부업·1인 운영에 결정적이에요. 한 달 후 무너지는 시나리오는 부업이 아니라 부담이 됩니다. 5가지 핸들러 + 재시도 설계 + 멱등성 + 에러 로그 적재가 운영 신뢰성의 네 기둥이에요.

지금 당장 할 액션은 — 본인 운영 중인 시나리오 한 개 열어보기 → Break 핸들러 박혀 있는지 확인 → 안 박혀 있으면 즉시 추가(재시도 + Notion 알림) → 멱등성 확보 모듈(upsert 또는 사전 검색) 확인. 30분이면 끝나는 점검이지만, ‘갑자기 자동화 멈춤’ 사고를 줄이는 데는 이만한 투자가 없어요.

부록 — 전형적인 사고 흐름과 대응

실제로 터지는 사고는 대개 비슷한 모양이에요. 가장 자주 보는 흐름을 따라가 보면 이렇습니다.

새벽에 ‘인스타그램 자동 게시 + 댓글 응답’ 같은 스케줄 시나리오가 돌다가, 외부 API의 일시적인 연결 에러를 만납니다. 여기까지는 흔한 일이에요. 문제는 그다음이에요. Break 핸들러의 ‘Allow storing of incomplete executions’가 꺼져 있으면 재시도 후에도 실패한 번들이 저장되지 않고, 시나리오 자체가 중단됩니다. 게다가 알림 모듈이 같은 외부 서비스에 의존하고 있었다면 ‘에러가 났다’는 알림조차 나가지 않아요. 아침에 일어나서야 밤사이 작업이 거의 처리되지 않은 걸 발견하게 되죠.

이 흐름을 끊는 조치는 네 가지예요.

1. Allow storing of incomplete executions를 ON: 실패한 번들이 남아야 나중에 이어서 처리할 수 있어요.
2. 수동 재시도 여지를 남기는 한도 설정: 자동 시도가 끝나도 사람이 다시 돌릴 수 있게 총 한도를 조금 넉넉히 잡습니다.
3. Break 다음에 Resume 중첩: 에러 처리 모듈이 또 실패해도 흐름이 끊기지 않게 하는 이중 안전망이에요.
4. 알림 채널 다중화: 서로 다른 경로 두 곳 이상으로 알림을 보냅니다.

여기서 놓치기 쉬운 게 4번이에요. 알림 채널을 하나만 두면, 그 채널이 영향받는 사고에서는 알림이 통째로 사라집니다. 슬랙·텔레그램·이메일처럼 성격이 다른 경로로 나눠두면 추가 비용 없이 인지 실패를 크게 줄일 수 있어요.

정리하면 ‘에러 핸들러를 박았다’와 ‘제대로 박았다’는 완전히 다른 얘기예요. 핸들러를 추가한 것만으로 안심하지 말고 위 네 가지 설정까지 확인해야 실제로 작동하는 안전망이 됩니다.

흔한 함정 7가지

커뮤니티나 포럼에서 반복적으로 올라오는 ‘다들 한 번씩 겪는 함정’을 정리했어요.

1. ‘잘 돌아가니까 모니터링 안 봤다’: 몇 주 동안 시나리오 페이지를 안 들어가다가 incomplete execution이 잔뜩 쌓인 뒤에야 발견하는 경우예요. 한도 초과로 시나리오가 자동 정지되는 게 흔한 결말입니다.
2. ‘에러 알림을 본인 카톡으로만’: 본인 카카오톡이 1주일간 무음으로 묻히면 사고 인지가 늦어요. 슬랙·텔레그램·이메일 중 적어도 2채널 분산이 표준.
3. ‘Webhook 트리거 idempotency 없음’: 외부 시스템이 webhook을 2번 호출하면 같은 작업이 2번 처리됨. 트리거 모듈 첫 단계에 ‘중복 webhook ID 필터’가 필수예요.
4. ‘Router 분기 조건 누락’: 조건문에 매칭 안 되는 데이터가 들어오면 시나리오 중단. ‘이외 모든 경우’ default 분기 필수.
5. ‘API 키 만료 미감지’: 인증 토큰 갱신 자동화 없으면 90일~1년 주기로 인증 실패. 갱신 전 30일 알림 자동화 권장.
6. ‘Operation 한도 모니터링 누락’: 월 한도 80% 도달 시 알림 자동화 권장. 한도 초과 시 시나리오 정지하면 부업 매출 즉시 끊어져요.
7. ‘백업 없음’: Make 시나리오 자체 백업이 없으면 실수로 모듈 삭제 시 복구 어려움. 매주 ‘Export Blueprint’ 다운받아 Google Drive에 자동 백업 권장.

7가지 모두 자동화를 조금만 오래 굴리면 한 번씩 마주치는 함정이에요. 사고가 난 뒤에 대응하면 손이 몇 배로 들지만, 미리 대비책을 박아두면 대부분 알림 한 번 받고 넘어가는 수준으로 끝납니다.

운영 신뢰성 등급표 — 본인 시나리오 점검

본인 운영 시나리오가 어느 등급인지 자가 점검할 수 있는 표예요. 처음 만든 자동화는 대부분 C나 D에서 출발하니 낙담할 필요는 없고, A로 끌어올리는 걸 목표로 잡으면 됩니다.

등급 상승 순서는 단순해요. C→B는 핸들러를 일괄 추가하는 작업이라 한 번에 끝나고, B→A는 멱등성 모듈 정비와 백업 자동화가 붙어서 반나절 정도 잡으면 됩니다. 한 번 투자해두면 이후에는 주간 점검만으로 유지되는 구조라 가성비가 좋아요.

5가지 핸들러 패턴 — 실전 적용 예제 5개

이론보다 실전 예제가 빠르게 이해돼요. 자주 만들게 되는 시나리오 유형 5개에 앞의 패턴을 대입해 보면 이렇습니다.

1. 고객 문의 메일 자동 응대 시나리오: Webhook 트리거 → AI 답변 생성 → 메일 발송. Break 핸들러에 짧은 재시도를 붙이고 Notion 검토 큐로 연결. AI 답변 생성 모듈에는 Resume를 중첩해 ‘이중 안전망’.
2. 인스타그램 자동 게시 시나리오: Schedule 트리거 → 이미지 가공 → Graph API 게시. 외부 소셜 API는 일시 에러가 잦은 편이라 재시도를 조금 더 여유 있게 잡고, Slack 알림에 Telegram 백업 알림을 더해 채널을 이중화.
3. 네이버 스마트스토어 주문 처리: Webhook 트리거 → 주문 DB 저장 → 송장 발행. Commit/Rollback 트랜잭션 패턴 + idempotency를 주문번호 unique 키로 확보.
4. 유튜브 댓글 모니터링·자동 응답: Schedule 트리거 → 새 댓글 검색 → AI 답변 → 게시. Resume 핸들러로 ‘일부 댓글 처리 실패해도 다음 댓글 계속’ + 실패 댓글 Notion DB 저장.
5. 블로그 자동 발행 시나리오: Schedule 트리거 → AI 글 생성 → 워드프레스 발행 → 인스타 알림. Break + 짧은 재시도 + 발행 실패 시 ‘초안 저장만 하고 사람 검토 요청’ 패턴.

5개 모두 Break 핸들러를 기본으로 깔고 시나리오 특성에 맞춰 추가 패턴을 조합한 구조예요. 정리하면 ‘Break + 짧은 재시도 + 사람 검토 큐’가 대부분의 운영 시나리오에서 통하는 안전 베이스라인이고, 트랜잭션이 걸린 주문·결제 계열만 Commit/Rollback으로 갈아타면 됩니다. 재시도 횟수는 시나리오마다 다르니 실행 기록을 며칠 보면서 ‘몇 번째 시도에서 대개 풀리는지’를 확인하고 거기에 맞춰 조정하는 게 정확해요.

운영자 시간 관리 — 모니터링 주간 루틴

자동화 시나리오 5~10개 운영 중인 1인 운영자의 표준 주간 점검 루틴이에요. 총 주당 1시간 안에 끝나는 구조입니다.

주당 약 60분이 표준이에요. 자동화 운영에 ‘완전 손 떼고’는 없고 ‘주당 1시간 점검’이 합리적 운영 비용입니다. 이 시간이 ‘부업 매출이 그만큼 자동으로 흘러오는 인프라 유지비’라고 인식하면 부담이 줄어요. 점검 시간을 안 박아두면 결국 사고를 뒤늦게 발견하게 되고, 그때는 밀린 데이터를 되짚어 복구하는 작업까지 붙어서 손이 훨씬 많이 들어요. 짧게 자주 보는 쪽이 결과적으로 시간이 덜 듭니다.