Make 자동화 2026: 잘 돌던 시나리오가 어느 날 조용히 멈춰 있는 이유와 에러 처리로 막는 법

Photo by Stephen Dawson on Unsplash

분명히 잘 돌아가던 Make 자동화가 어느 날 들어가 보니 조용히 멈춰 있던 경험, 한 번쯤 있으실 겁니다. 며칠 동안 들어온 줄 알았던 데이터가 실은 하나도 처리되지 않았고, 시나리오는 비활성화(deactivated) 상태로 바뀌어 있죠. 더 당황스러운 건 "왜 멈췄는지"가 한눈에 보이지 않는다는 점입니다. 이 글에서는 Make 자동화가 소리 없이 멈추는 구조적인 이유와, 멈추더라도 데이터를 잃지 않고 다시 굴러가게 만드는 에러 처리 방법을 정리합니다. (본 글은 작성 시점 기준 Make 공식 문서를 토대로 합니다.)

왜 Make 자동화는 '조용히' 멈출까

가장 먼저 이해해야 할 건 Make의 기본 동작 방식입니다. 시나리오 안의 어떤 모듈 하나가 에러를 던지면, Make는 그 실행(execution) 전체를 즉시 중단합니다. 처리 중이던 번들(bundle)은 버려지고, 자동 재시도도 하지 않습니다. 즉 '한 건의 실패'가 '그 실행 전체의 실패'로 번지는 구조입니다.

여기서 끝이 아닙니다. Make에는 시나리오 설정에 연속 에러 허용 횟수(Number of consecutive errors)라는 항목이 있고, 기본값은 3입니다. 실행이 연속으로 이 횟수만큼 실패하면 Make는 해당 시나리오를 자동으로 비활성화해 버립니다. 무한 반복으로 자원이 새는 걸 막기 위한 안전장치지만, 모니터링을 안 하고 있으면 "어, 언제부터 안 돌았지?" 하는 상황이 바로 여기서 생깁니다. 이 동작은 Make 공식 도움말의 시나리오 설정 문서에서 확인할 수 있습니다.

다행히 Make는 시나리오가 중단되면 기본적으로 이메일 알림을 보냅니다. 프로필의 이메일 설정(Email preferences)에서 어떤 알림을 받을지 조정할 수 있으니, 자동화를 운영 중이라면 'Scenario stopped' 알림만큼은 반드시 켜 두는 게 좋습니다. 알림이 꺼져 있으면 며칠씩 멈춰 있어도 모를 수 있습니다.

정리하면 Make가 멈추는 과정은 이렇습니다. ① 모듈 하나가 에러를 던진다 → ② 그 실행 전체가 중단된다 → ③ 같은 일이 연속으로 반복되면(기본 3회) 시나리오가 자동 비활성화된다 → ④ 중단 알림 메일이 온다. 문제는 이 ①~③이 하루에도 여러 번, 사람이 보지 않는 사이에 일어난다는 점입니다. 그래서 '에러가 안 나게' 만드는 것보다 '에러가 나도 멈추지 않게' 설계하는 쪽이 훨씬 현실적입니다.

핵심은 '에러 핸들러' — 5가지 지시어

실패를 아예 안 나게 만들 수는 없습니다. 외부 API가 잠깐 응답을 안 하거나, 들어온 데이터에 빈 값이 있거나 하는 일은 늘 생기니까요. 그래서 Make는 에러가 났을 때 '어떻게 행동할지'를 지정하는 에러 핸들러(error handler)를 제공합니다. 문제가 생길 수 있는 모듈에 마우스 오른쪽 클릭 → Add error handler로 붙입니다. 지시어(directive)는 다섯 가지입니다.

• Ignore — 실패한 번들만 버리고 나머지 번들은 계속 처리합니다. 실패해도 전체에 영향이 없는 비핵심 작업에 적합합니다.
• Resume — 미리 정해둔 대체값(fallback)을 넣어 흐름을 이어갑니다. "값이 없으면 빈 문자열로 처리" 같은 식이죠.
• Break — 실행을 멈추되 그 건을 '미완료 실행(Incomplete executions)' 큐에 저장합니다. 설정에 따라 자동으로 재시도하거나, 사람이 고친 뒤 다시 돌릴 수 있어 데이터 손실이 없습니다.
• Rollback — 실행을 멈추고 에러로 표시하며, 그 실행에서 한 작업을 되돌리려 시도합니다. 단, 모든 모듈이 롤백을 지원하진 않습니다.
• Commit — 에러가 있었더라도 그 실행을 '성공'으로 마무리합니다.

가장 많이 쓰는 건 비핵심 작업의 Ignore와, 절대 빠뜨리면 안 되는 데이터의 Break입니다. 이 둘만 제대로 붙여도 "한 건 실패 때문에 시나리오 전체가 멈추는" 문제의 대부분이 사라집니다. Break의 진짜 강점은 재시도를 설정할 수 있다는 점인데, 시도 횟수(number of attempts)와 시도 간격(interval)을 지정해 두면 일시적인 오류는 사람 손 없이 알아서 회복되고, 끝내 실패한 건만 큐에 남습니다.

실전: 멈추지 않는 자동화 만드는 4가지 체크포인트

1) '미완료 실행 저장'을 먼저 켠다

시나리오 설정에서 Allow storing of incomplete executions 옵션을 켜야 실패한 실행이 큐에 보관됩니다. 이게 꺼져 있으면 Break 핸들러를 붙여도 저장할 곳이 없어 데이터가 그대로 사라집니다. 운영용 시나리오라면 사실상 필수 설정이니, 새 시나리오를 만들면 가장 먼저 켜 두는 습관을 들이세요.

2) 외부 연동 모듈에는 Break를 기본으로

HTTP 요청, 외부 API 호출, 결제·메일 발송처럼 '실패하면 안 되는' 모듈에는 Break를 붙여 두세요. 일시적인 네트워크 오류라면 자동 재시도로 넘어가고, 진짜 문제라면 미완료 큐에 남아 나중에 손볼 수 있습니다. 외부 서비스는 내가 통제할 수 없는 영역이라 잠깐씩 흔들리는 게 정상이라고 보고, 처음부터 흔들림을 견디게 설계하는 게 핵심입니다.

3) 부가 작업은 Ignore로 흐름을 지킨다

슬랙 알림, 로그 기록처럼 '있으면 좋지만 없어도 본 작업엔 지장 없는' 모듈은 Ignore로 처리합니다. 알림 하나 실패했다고 정작 중요한 데이터 저장까지 멈추면 본말이 전도되니까요. '이 모듈이 실패하면 전체를 멈춰야 하나?'를 모듈마다 한 번씩만 자문해 보면, Break를 쓸 곳과 Ignore를 쓸 곳이 자연스럽게 갈립니다.

4) '왜 실패했는지' 자체를 자동화한다

에러 핸들러 경로 끝에 본인에게 메시지를 보내는 모듈(메일·슬랙·텔레그램 등)을 붙이면, 어떤 모듈이 어떤 메시지로 실패했는지 즉시 받아볼 수 있습니다. 시나리오가 비활성화될 때까지 기다리지 말고, 첫 실패에서 바로 알게 만드는 겁니다. 여기에 일주일에 한 번 미완료 실행 큐를 열어 쌓인 건이 없는지 확인하는 습관까지 더하면, 자동화는 '방치해도 되는 시스템'이 아니라 '가볍게 관리하는 시스템'이 됩니다.

결론: 자동화의 완성은 '실패 처리'다

자동화를 처음 만들 때는 '잘 돌아가는 경로'에만 집중하기 쉽습니다. 하지만 오래 굴러가는 자동화와 며칠 만에 조용히 멈추는 자동화를 가르는 건 정작 실패했을 때의 설계입니다. Make의 기본 동작은 한 건 실패에 전체를 멈추고, 연속 3회 실패하면 시나리오 자체를 꺼 버린다는 점을 기억하세요. 오늘 운영 중인 시나리오 하나를 열어, 외부 연동 모듈에 Break를, 부가 모듈에 Ignore를 붙이고 '미완료 실행 저장'과 중단 알림부터 켜 보세요. 그 작은 설정 하나가 며칠치 데이터를 살립니다.