Make 시나리오가 외부 서비스와 연결되어 있으면 언젠가는 오류가 납니다. API 요청 제한, 일시적인 연결 실패, 누락된 필수값, 예상과 다른 데이터 형식처럼 원인은 다양합니다. 문제는 오류 하나 때문에 나머지 작업까지 멈추거나 중요한 데이터가 사라지는 것입니다.
Make의 Error Handler는 특정 모듈에서 오류가 발생했을 때 정해 둔 별도 경로로 처리하게 해 주는 기능입니다. 오류를 무조건 무시하는 장치가 아니라, 오류 유형과 데이터 중요도에 따라 재시도·대체값·기록·중단을 선택하는 안전장치입니다.
Error Handler가 필요한 순간
기본 설정에서는 모듈 오류가 시나리오 실행을 멈추게 할 수 있습니다. Error Handler를 연결하면 실패한 지점에서 별도 처리 경로를 실행하고, 나머지 번들을 계속 처리하거나 이후 복구 작업을 준비할 수 있습니다.
Make 공식 도움말은 Error Handler를 반복되는 오류를 수동으로 고치지 않고, 미리 정한 로직으로 복구하기 위한 기능으로 설명합니다. 오류 처리 전략 전체는 Make Error Handling 공식 문서에서 확인할 수 있습니다.
먼저 선택할 5가지 처리 방식
| 처리 방식 | 언제 쓰나 | 주의할 점 |
|---|---|---|
| Retry | 일시적 연결 오류·서버 지연 | Incomplete Executions 설정이 필요함 |
| Resume | 대체값을 넣어 다음 단계로 진행 가능할 때 | 대체값이 업무상 안전한지 확인 |
| Skip | 가끔 들어오는 불완전한 데이터는 버려도 될 때 | 해당 번들은 처리되지 않음 |
| Commit | 앞 단계의 변경은 유지하고 현재 실행만 멈출 때 | 이미 반영된 데이터 확인 필요 |
| Rollback | 트랜잭션 지원 서비스의 변경을 되돌려야 할 때 | 지원 여부와 영향 범위를 확인 |
처음에는 Retry와 Resume, Skip의 차이부터 확인하세요. Commit과 Rollback을 사용할 때는 모듈의 트랜잭션 지원 여부와 Auto commit 설정이 중요합니다. Rollback은 이미 발송된 이메일 같은 일반 외부 작업을 취소하지 못합니다. Rollback 공식 문서에서 복구 범위를 확인하세요.
1. Retry: 잠깐의 장애는 다시 시도하기
외부 API의 일시적 장애라면 시간을 두고 다시 시도해 복구할 수 있습니다. 다만 Make가 ConnectionError·RateLimitError로 분류한 오류는 Incomplete Executions를 활성화하면 기본 재시도 기능을 이용할 수 있습니다. 개별 모듈의 복구 방식을 직접 정해야 할 때 Retry Handler를 검토하세요.
Retry는 실패한 번들의 오류 내용과 남은 처리 흐름을 Incomplete Execution으로 보관하고, 설정에 따라 자동 또는 수동으로 다시 실행할 수 있게 합니다. Make의 Retry Handler를 사용하려면 시나리오 설정에서 Incomplete Executions 저장을 활성화해야 합니다.
자동 재시도 횟수와 간격은 무조건 크게 잡지 마세요. 예를 들어 이미 잘못된 인증키로 실패했다면 10번을 재시도해도 해결되지 않습니다. 연결 오류나 일시적 제한처럼 재시도 가능성이 있는 오류에만 사용하세요.
Make Retry Error Handler 공식 문서에 설정 예시가 있습니다. 요청 제한이 반복된다면 API 429 오류 해결과 처리량 조절 가이드를 참고해 실행 빈도와 요청량도 함께 조정하세요. 외부 서비스에 이미 반영된 작업이 있는지 확인한 뒤 재시도하면 중복 등록을 줄일 수 있습니다.
2. Resume: 대체값으로 흐름을 이어가기
Resume은 실패한 모듈의 출력값을 지정한 값으로 대신하고 다음 모듈을 실행합니다. 실패한 CRM 등록이나 이메일 발송이 실제로 완료됐다는 뜻은 아닙니다. 입력값을 고쳐 같은 작업을 다시 수행해야 한다면 원인을 수정한 후 재시도해야 합니다.
예를 들어 내부 보고서에 넣을 선택 정보의 조회가 실패했을 때, 출력 필드에 ‘조회 실패 — 검토 필요’라는 대체값을 넣는 방식으로 사용할 수 있습니다. 이 예시는 설계 방법이며, 실제 매핑 필드는 연결한 모듈의 출력 구조에 맞춰야 합니다. 후속 모듈이 대체값을 정상 조회 결과로 처리하지 않도록 검토 표시도 함께 전달하세요.
CRM 등록에 필수 전화번호가 없다면 등록 전에 누락 여부를 검사하고 해당 건을 보류하는 편이 명확합니다. 상세 동작은 Make Resume 공식 문서에서 확인할 수 있습니다.
3. Skip: 버려도 되는 항목만 건너뛰기
목록 100건 중 형식이 잘못된 한 건만 제외하고 나머지는 처리하고 싶을 수 있습니다. 이때 Skip을 사용하면 문제가 된 번들을 건너뛰고 이후 항목을 계속 처리할 수 있습니다.
그러나 주문·결제·고객 문의처럼 빠지면 안 되는 데이터에는 Skip을 기본값으로 쓰면 안 됩니다. 반드시 오류 알림이나 별도 기록을 남겨 누락된 항목을 나중에 찾을 수 있게 하세요.
오류 알림과 함께 쓰는 기본 구조
가장 실용적인 시작 구조는 다음과 같습니다.
문제 모듈 → 점선 오류 처리 경로 → 오류 기록·운영자 알림 → Retry / Resume / Skip 등 마지막 처리 지시
오류 처리 경로의 끝에 원하는 처리 지시를 둡니다. 알림 모듈만 연결하고 그 경로가 정상 종료되면 원래 오류가 건너뛰어질 수 있으므로, 중요한 데이터는 알림 뒤의 복구 방식을 명시적으로 정하세요.
알림에는 워크플로우 이름, 실패한 모듈, 오류 메시지, 원본 데이터의 식별자만 넣으세요. 비밀번호·API 키·민감한 고객 정보가 포함되지 않도록 주의해야 합니다. n8n과 Make의 공통 오류 알림 원칙은 자동화 실패 알림 설정법에서 이어서 볼 수 있습니다.
설정 순서
- 오류가 자주 나는 모듈을 하나 고릅니다.
- 모듈을 마우스 오른쪽 버튼으로 클릭하고 Add error handler를 선택합니다.
- 오류의 성격에 맞춰 Retry, Resume, Skip 등의 처리 방식을 고릅니다.
- Retry라면 시나리오 설정의 Store incomplete executions를 Yes로 켭니다. Handler의 Automatically complete execution을 Yes로 정하면 시도 횟수와 간격을 설정하고, No라면 Incomplete Executions 목록에서 수동으로 해결합니다.
- 테스트 데이터 한 건으로 의도적인 오류를 만들고, 알림·기록·복구 경로가 모두 동작하는지 확인합니다.
실행 전 점검표
- 이 오류는 재시도하면 해결될 가능성이 있는가
- 건너뛰어도 되는 데이터인지, 반드시 복구해야 하는 데이터인지 구분했는가
- 대체값이 실제 업무에 오해를 만들지 않는가
- 오류가 났을 때 운영자가 확인할 알림 또는 기록이 남는가
- 같은 오류가 반복될 때 원본 시나리오를 개선할 계획이 있는가
Error Handler는 자동화를 멈추지 않게 만드는 기능이 아니라, 멈춰야 할 때와 복구해도 될 때를 구분하게 해 주는 기능입니다. 우선 연결 오류가 가끔 나는 모듈 하나에 Retry와 알림을 붙이는 작은 시나리오부터 시작해 보세요.