[중급] Make 타임아웃 에러, 웹훅 재시도 로직으로 시스템 심폐소생하는 법

결론부터 말한다. ‘Scenario execution timed out’ 에러는 메이크(Make) 시스템의 버그가 아니다. 100% 당신의 설계 미스다.

이 에러 메시지 때문에 지난주에 구축해둔 자동화 파이프라인 하나가 통째로 멈췄다. 원인 파악에 꼬박 반나절을 썼다. 이 글을 읽는다면 최소 4시간은 아낄 수 있을 것.

메이크의 모든 시나리오는 정해진 실행 시간 제한이 있다. 기본 40초. 유료 플랜을 쓰면 최대 5분까지 늘어나지만, 본질은 같다. 요청을 보냈는데 상대방이 이 시간 안에 응답을 주지 않으면, 메이크는 미련 없이 연결을 끊어버린다. 성질 급한 손님이 식당에서 주문하고 40초 안에 음식이 안 나오면 그냥 나가버리는 것과 같다. 서버 자원은 한정되어 있으니 당연한 조치다.

문제는 OpenAI의 GPT-4나 클로바 스튜디오 같은 외부 API를 호출하는 무거운 작업을 시킬 때 발생한다. 텍스트를 길게 생성하거나 복잡한 데이터를 처리하는 경우, 40초는 우습게 넘어간다. 그럼 시스템은 멈춘다. 이게 현실이다.

⛔️ 직장인 열에 아홉은 여기서 막힌다. 흔한 실수 5가지.

대부분 이 문제를 해결하기 위해 시나리오 실행 시간을 억지로 늘리거나, 더 비싼 요금제로 업그레이드한다. 밑 빠진 독에 물 붓기다. 근본적인 원인을 해결해야 한다. 보통 아래 5가지 실수를 저지른다.

1. 비동기 처리 개념의 부재: 오래 걸리는 작업은 일단 ‘접수’만 받고, 즉시 ‘알겠다’는 신호를 보내줘야 한다. 이걸 ‘비동기(Asynchronous)’ 처리라고 부른다. 관공서에 서류를 제출하면 바로 그 자리에서 최종 결재까지 기다리는 게 아니라 ‘접수증’을 받고 집에 가는 것과 같다. 그런데 대부분의 초보자는 무거운 작업이 끝날 때까지 하염없이 기다리는 ‘동기(Synchronous)’ 방식으로 시나리오를 짠다. 당연히 타임아웃이 난다.
2. ‘웹훅 응답(Webhook Response)’ 모듈 미사용: 웹훅으로 다른 시나리오를 호출해놓고, ‘호출 잘 받았다’는 응답을 보내주지 않는다. 편지를 보냈는데 답장이 없으면 보낸 쪽에서는 배달 사고로 인지한다. 메이크도 마찬가지다. 웹훅을 수신하는 시나리오는 맨 마지막에 ‘Webhook Response’ 모듈을 붙여 200 상태 코드로 ‘정상 접수’ 신호를 즉시 보내줘야 한다. 이게 시스템 간의 예의다.
3. 메이크 기본 재시도 기능 맹신: 시나리오 설정에 있는 ‘실패 시 재시도’ 옵션만 믿는 경우다. 이건 그냥 상대방이 전화를 안 받을 때 같은 번호로 계속 전화 거는 것과 같다. 상대방 폰이 꺼져있거나 통화 중이면 백날 걸어봐야 소용없다. API 서버 자체가 죽었거나 요청량 초과로 응답이 느린 상황이라면, 이런 맹목적인 재시도는 자원 낭비일 뿐이다.
4. 무의미한 에러 핸들링: 에러가 발생했을 때 그저 슬랙이나 이메일로 알림만 보내고 끝낸다. 이건 화재경보기가 울리기만 하고 소화기는 없는 셈이다. 진짜 에러 핸들링은, 특정 모듈에서 오류가 발생했을 때 실행을 중단하지 않고 데이터를 구글 시트 같은 안전한 곳에 백업하거나, 대체 경로로 작업을 넘겨주는 ‘플랜 B’ 로직을 짜는 것을 의미한다.
5. 상대방 시스템의 처리 한계(Rate Limit) 무시: 내 시스템만 생각하고 호출 대상이 되는 API 서버의 입장은 전혀 고려하지 않는다. OpenAI API는 분당 요청 횟수(RPM) 제한이 있다. 이걸 무시하고 단시간에 너무 많은 요청을 보내면, 서버는 과부하를 막기 위해 연결을 강제로 끊거나 응답을 지연시킨다. 고속도로 톨게이트의 처리 용량은 생각 안 하고 차만 계속 밀어 넣으면 결국 병목 현상이 생기는 것과 같다.

🛠️ 해결책: 웹훅으로 작업을 분리하고, 에러 핸들러로 방어벽 쌓기

구조는 단순하다. 무거운 작업은 별도의 ‘하청 시나리오’로 분리하면 끝난다.

[메인 시나리오]
1. 트리거 (시작점)
2. 웹훅(Webhook) 모듈: 처리할 데이터를 담아 하청 시나리오 호출 (호출하고 바로 다음 단계로 넘어감)
3. 웹훅 응답(Webhook Response) 모듈: 호출한 쪽에 ‘접수 완료’ 신호 즉시 전송. (이걸로 메인 시나리오는 타임아웃 없이 즉시 종료됨)

[하청 시나리오]
1. 웹훅(Custom Webhook) 모듈: 메인 시나리오의 호출과 데이터를 받아서 대기.
2. 무거운 작업 모듈 (e.g., OpenAI API 호출): 여기서 실제 오래 걸리는 작업을 처리.
3. 결과 처리 모듈: 작업 완료 후 데이터베이스에 저장하거나 다음 로직 수행.

이 구조의 핵심은 메인 시나리오가 하청 시나리오의 작업이 끝날 때까지 기다리지 않는다는 점이다. 그냥 일을 던져주고 ‘접수증’만 받으면 자기 임무는 끝난다. 실제 일은 하청 시나리오가 시간을 들여 처리한다. 이렇게 하면 40초 타임아웃 제약에서 자유로워진다.

여기에 방점을 찍는 것이 에러 핸들링이다. ‘하청 시나리오’의 무거운 작업 모듈에 마우스 우클릭으로 ‘Add error handler’를 추가한다. 그리고 만약 API 서버 문제 등으로 에러가 발생하면, 데이터를 구글 시트나 데이터스토어에 기록하고 다시 시도하게 하거나, 관리자에게만 특정 알림을 보내도록 경로를 설계한다. 이렇게 하면 어지간한 돌발 상황에도 시스템 전체가 멈추는 대참사는 막을 수 있다.

결론: 깨지지 않는 시스템은 없다. 자동 복구되는 시스템을 만들 뿐.

완벽한 시스템을 만들겠다는 환상은 버리는 게 좋다. 네트워크는 불안정하고, API 서버는 언제든 죽을 수 있다. 중요한 건 시스템이 깨졌을 때 어떻게 스스로를 진단하고, 작업을 안전하게 보관했다가 다시 시도할 수 있는 ‘회복탄력성’을 설계하느냐다. 이 고민의 깊이가 당신의 자동화 시스템 수준을 결정한다.

PipeMaster-Lab 운영정책 및 제보 안내