Make 시나리오 오류가 날 때 5가지 에러 핸들러 디렉티브를 먼저 나눠보세요

모듈을 마우스 오른쪽 단추로 누르고 Add error handler를 선택하면 오류가 났을 때만 흐르는 주황색 에러 핸들러 경로가 열려요. 이 경로의 끝에는 반드시 Make가 제공하는 5가지 디렉티브 가운데 하나를 배치해야 실행 흐름이 정리돼요. 각 디렉티브가 실패한 데이터(번들)를 어떻게 다루는지 공식 사양으로 하나씩 짚어봐요.

모듈 오류가 났을 때 어떤 디렉티브를 골라야 하나요?

기본 실행 흐름은 아래처럼 단순하지만, 에러 핸들러가 붙으면 실패 시점의 분기가 달라져요.

입력 데이터 도착 → 일반 모듈 처리 → [오류 발생 시] → 에러 핸들러 경로 진입 → 지시 디렉티브 실행

어떤 디렉티브를 붙이느냐에 따라 실패한 번들을 버릴지, 기본값을 채워 계속 달릴지, 아니면 잠시 큐에 보관하고 나중에 다시 찌를지가 갈려요. 판단 기준을 표로 한눈에 정리해요.

확인일은 2026-10-26이고 Make 공식 도움말 사양을 기준으로 정리했어요.

Resume과 Ignore는 데이터 흐름에서 무엇이 다른가요?

두 디렉티브 모두 오류가 나도 시나리오를 멈추지 않고 다음 단계로 넘긴다는 공통점이 있어요. 하지만 다음 모듈로 전달되는 데이터의 형태에서 결정적인 차이가 생겨요.

Resume은 실패한 모듈 대신 다음 모듈로 전달할 대체 데이터(Fallback Bundle)를 직접 지정할 수 있어요. 예를 들어 고객의 상세 프로필을 가져오는 CRM 모듈이 일시적인 404 오류로 실패했다고 가정해봐요. 뒤따르는 이메일 전송 모듈이 고객 이름 값을 필수로 요구한다면, Resume 설정 창에서 이름: "고객님"이라는 기본값을 지정해 줄 수 있어요. 그러면 이메일 모듈은 빈 값 오류 없이 정상적으로 발송을 완료해요.

반면에 Ignore는 대체값을 전혀 넣지 않고 오류가 난 번들을 그냥 지나쳐요. 해당 모듈의 출력값은 완전히 빈 상태(empty)가 돼요. 뒤따르는 후속 모듈이 앞선 모듈의 결과 필드를 필수로 참조하고 있다면, 다음 모듈에서 또다시 누락 오류가 터질 수 있어요. 따라서 Ignore는 결과를 아무도 참조하지 않는 부가적인 알림 전송 모듈이나 단순 로깅 모듈에만 붙이는 편이 안전해요.

Commit과 Rollback은 트랜잭션과 후속 노드를 어떻게 정리하나요?

데이터를 데이터베이스나 결제 시스템에 기록하는 작업에서는 시나리오 중간에 멈췄을 때 앞서 쓴 데이터가 어떻게 남는지가 매우 중요해요.

Commit은 오류 발생 직전까지 수행된 모든 변경사항을 공식적으로 확정(Commit) 짓고 해당 실행 경로를 그 자리에서 정상 종료해요. 전체 시나리오 상태는 실패(Error)가 아니라 성공(Success)으로 마감돼요. 예를 들어 신규 리드를 검증하는 단계에서 유효하지 않은 전화번호 형식으로 판명 났을 때, 지금까지 처리한 수집 기록만 데이터베이스에 저장해 두고 뒤쪽 알림 발송은 건너뛰고 싶다면 Commit을 연결하면 돼요.

Rollback은 정반대로 동작해요. 오류가 발생한 번들에 대해 앞서 수행했던 트랜잭션을 모두 되돌리고 실행을 즉시 중단해요. 단, 롤백은 MySQL이나 PostgreSQL처럼 ACID 트랜잭션을 지원하는 관계형 데이터베이스 모듈에서만 실제 이전 상태 취소가 작동해요. 트랜잭션을 지원하지 않는 일반 SaaS API(예: Slack 메시지 전송, Google Sheets 행 추가)는 물리적으로 이미 발송되거나 기록된 데이터를 자동으로 지워주지 못해요. 이 점을 혼동하지 않도록 주의해야 해요.

Break 디렉티브와 불완전 실행(Incomplete Executions) 큐는 언제 쓰나요?

실무에서 가장 유용하게 쓰이는 디렉티브가 바로 Break예요. 일시적인 외부 서비스 장애나 네트워크 끊김, API 호출 한도 초과(HTTP 429)를 만났을 때 시나리오를 깨뜨리지 않고 지켜주는 핵심 장치예요.

Break가 실행되면 실패한 번들은 Make의 Incomplete Executions(불완전 실행) 대기열로 즉시 이동해요. 설정 창에서 재시도 횟수(최대 5회)와 재시도 주기(예: 5분 간격)를 설정해 두면, Make 엔진이 정해진 시간 뒤에 해당 번들을 실패했던 모듈부터 자동으로 다시 실행해요. 외부 서비스가 정상으로 돌아오면 재시도 단계에서 성공하며 시나리오 전체 흐름이 자연스럽게 이어져요.

만약 지정된 재시도 횟수를 모두 채울 때까지 외부 서비스가 복구되지 않으면, 해당 번들은 자동으로 사라지지 않고 Waiting for review(검토 대기) 상태로 큐에 남아 있어요. 관리자는 나중에 원인을 고친 뒤 Make 대시보드에서 Resolve(해결) 단추를 눌러 수동으로 재실행할 수 있어요. 중요한 결제 데이터나 주문 누락을 막을 때 반드시 필요한 안전망이에요.

운영 시나리오에 에러 핸들러를 넣기 전 무엇을 먼저 확인하나요?

시나리오에 디렉티브를 달기 전에 운영자가 반드시 점검해야 할 설정 세 가지가 있어요.

1. 시나리오 설정의 불완전 실행 보관 권한을 켜요: 시나리오 설정 화면에서 Allow storing incomplete executions 옵션이 켜져 있어야 Break 디렉티브가 번들을 큐에 안전하게 저장할 수 있어요. 이 옵션이 꺼져 있으면 Break를 달아도 대기열에 저장되지 않고 일반 오류로 종료돼요.
2. 후속 모듈의 필수 변수 의존성을 살펴봐요: 앞선 모듈의 출력을 뒤쪽 노드가 쓰고 있는지 확인하고, 필수 값이 필요하다면 Ignore 대신 Resume으로 기본 대체 객체를 구성해요.
3. 루프 번들 처리 시 전체 중단 여부를 결정해요: 여러 개의 번들을 반복 처리하는 시나리오에서 한 번들이 실패했을 때, 전체 시나리오를 세울지(Rollback/기본 오류) 아니면 해당 번들만 보관하고 다음 번들을 계속 돌릴지(Break/Ignore) 업무 요구사항에 맞춰 분기해요.

이전 Make 환경에서 웹훅이나 요청 서명 검증을 설정하는 방법은 /safe-ops/make-event-subscriptions-signed-retries/ 글에서 다룬 적이 있어요. 다른 자동화 도구인 n8n에서 실패 실행을 분기하고 재시도하는 구조가 궁금하다면 /safe-ops/n8n-failed-execution-retry-workflow-choice/ 글도 함께 살펴보세요.

실제 프로덕션 시나리오에 에러 핸들러를 배포하기 전에는 의도적으로 잘못된 API 키나 형식 오류 데이터를 넣는 테스트 실행을 먼저 돌려보고, 지정한 디렉티브 경로로 번들이 안전하게 분기되는지 반드시 확인해보세요.