주문 알림 하나가 들어왔는데 슬랙에는 메시지가 두 번 뜨고, 스프레드시트에는 똑같은 행이 두 줄 쌓입니다. 시나리오를 열어보면 에러 표시는 하나도 없습니다. 실행 기록에도 "성공"이라고 찍혀 있고요. Make 자동화를 쓰다 보면 거의 누구나 한 번쯤 만나는 상황입니다. 문제는 이게 에러가 아니라서 알림도 안 오고, 며칠 뒤 데이터를 정리하다가 뒤늦게 발견한다는 점입니다.
고장 난 시나리오는 고치면 되지만, 정상 작동하면서 같은 일을 두 번 하는 시나리오는 원인을 찾기가 훨씬 까다롭습니다. 이 글에서는 중복이 생기는 세 가지 경로를 먼저 구분하고, 데이터 스토어(Data store)로 "이미 처리한 건"을 기억시켜 중복을 구조적으로 막는 4단계 설계를 정리합니다.
왜 같은 데이터가 두 번 처리될까
먼저 알아둘 것이 있습니다. 중복은 대부분 Make 안에서 생기지 않습니다. 바깥에서 같은 신호가 두 번 들어오는 경우가 훨씬 많습니다. 원인을 나누면 크게 셋입니다.
| 원인 | 증상 | 확인할 곳 |
|---|---|---|
| 보내는 쪽의 재전송 | 같은 내용이 몇 초 간격으로 2~3번 | 웹훅 모듈의 수신 기록(payload 비교) |
| 웹훅이 여러 개 등록됨 | 항상 정확히 N배로 늘어남 | 보내는 서비스의 웹훅 설정 목록 |
| 내가 수동 실행 + 스케줄 동시 작동 | 테스트할 때만 두 번 | History 탭의 실행 시각 |
특히 첫 번째가 흔합니다. 많은 서비스는 웹훅을 보낸 뒤 정해진 시간 안에 2xx 응답을 못 받으면 실패로 간주하고 다시 보냅니다. Make의 시나리오가 무거워서 응답이 늦어지면, 보내는 쪽은 "안 갔구나" 하고 재전송하고 Make는 그걸 새 건으로 받아 또 처리합니다. 결과적으로 한 사건에 두 번의 실행이 남습니다.
실행 기록에서 두 실행의 payload를 나란히 열어보세요. 내용이 완전히 같으면 재전송이나 웹훅 중복 등록이고, 미묘하게 다르면(ID가 다르다든지) 애초에 서로 다른 사건입니다. 이 구분을 먼저 해야 엉뚱한 곳을 고치지 않습니다.
중복을 막는 핵심 도구: 데이터 스토어
보내는 쪽의 재전송은 내가 통제할 수 없습니다. 그래서 받는 쪽에서 "이 건은 이미 처리했다"고 기억하는 장치가 필요합니다. Make에서 그 역할을 하는 것이 데이터 스토어입니다.
데이터 스토어는 시나리오 실행이 끝나도 값이 남는 저장소입니다. Make 공식 도움말에 따르면 시나리오 간, 그리고 실행과 실행 사이에 데이터를 전달하는 용도로 설계되어 있습니다. 실행이 끝나면 사라지는 변수와 결정적으로 다른 점이죠.
중복 방지에 쓰는 모듈은 사실상 세 개면 충분합니다.
- Get a record — 키로 한 건을 조회합니다. "이미 처리했나?"를 묻는 질문에 해당합니다.
- Add/replace a record — 처리 완료 표시를 남깁니다. 같은 키가 이미 있으면 덮어씁니다.
- Search records — 조건으로 여러 건을 찾습니다. 뒤에서 다룰 오래된 기록 청소에 씁니다.
키를 무엇으로 잡느냐가 전부입니다
여기가 성패를 가릅니다. 키는 반드시 보내는 쪽이 부여한 고유 ID여야 합니다. 주문번호, 결제 ID, 메일의 message-id 같은 것들이요. 같은 사건이라면 몇 번을 재전송해도 이 값은 변하지 않기 때문입니다.
반대로 이런 것들을 키로 쓰면 중복 방지가 작동하지 않습니다.
- ❌ 실행 시각 / 타임스탬프 — 재전송할 때마다 달라집니다
- ❌ Make가 자동 생성한 실행 ID — 실행마다 새로 만들어집니다
- ❌ 이름, 이메일 주소 같은 속성값 — 같은 사람이 정당하게 두 번 주문하면 두 번째가 막힙니다
고유 ID가 없는 소스라면 변하지 않는 값 두세 개를 이어 붙여 키를 만드세요. 예를 들어 폼 응답이라면 제출시각+이메일처럼요. 단, 이 조합은 완벽한 고유값이 아니므로 차선책으로만 씁니다.
Make 자동화 중복 방지 4단계
1단계 — 데이터 스토어와 키 구조 만들기
시나리오와 별개로 데이터 스토어를 하나 만듭니다. 구조는 단순할수록 좋습니다. 키 외에 status(처리 상태)와 processed_at(처리 시각) 정도만 두면 충분합니다. processed_at은 4단계의 청소 작업에 쓰이니 빠뜨리지 마세요.
2단계 — 쓰기 전에 조회하고 분기하기
트리거 바로 다음에 Get a record를 놓고 키로 조회합니다. 그 뒤에 필터를 걸어 기록이 없을 때만 다음 모듈로 넘어가게 합니다. 이미 있으면 시나리오는 여기서 조용히 끝나고, 슬랙 메시지도 스프레드시트 행도 생기지 않습니다.
필터 조건은 "Get a record의 키 값이 존재하지 않음(Does not exist)"으로 잡는 게 안전합니다. 조회 결과가 비어 있을 때 어떤 필드를 참조할지 헷갈린다면, 한 번 수동 실행해 실제 출력 구조를 보고 조건을 확정하세요.
3단계 — 순서를 지켜 기록 남기기
Add/replace a record를 어디에 놓느냐로 동작이 달라집니다.
- 맨 끝에 놓으면: 작업이 성공해야 기록이 남습니다. 중간에 실패하면 기록이 없으므로 다음에 재시도됩니다. 누락은 없지만, 실패 직전까지의 작업이 이미 실행됐다면 그 부분은 두 번 돌 수 있습니다.
- 조회 직후에 놓으면: 처리를 시작하자마자 자리를 선점합니다. 거의 동시에 도착한 재전송을 확실히 막지만, 뒤에서 실패하면 그 건은 영영 처리되지 않습니다.
결제·발송처럼 두 번 실행되면 안 되는 작업은 조회 직후에 선점하고, 실패 시 알림을 받도록 에러 핸들러를 붙이는 쪽이 안전합니다. 반대로 로그 기록처럼 두 번 남아도 큰 손해가 없는 작업은 맨 끝에 두어 누락을 줄입니다.
4단계 — 오래된 기록 청소하기
데이터 스토어 용량은 요금제에 묶여 있고, 가득 차면 저장 공간이 부족하다는 오류로 시나리오가 멈춥니다. 중복 방지용 기록은 무한정 쌓일 필요가 없습니다.
별도 시나리오를 만들어 하루 한 번 Search records로 processed_at이 30일보다 오래된 건을 찾아 삭제하세요. 보관 기간은 "보내는 쪽이 재전송을 시도할 만한 최대 기간"보다 넉넉하면 됩니다. 대개 며칠이면 충분하고, 30일이면 여유 있는 편입니다.
흔히 놓치는 세 가지
체크는 한 번, 쓰기는 여러 갈래
시나리오 시작에서만 중복 검사를 하고, 그 뒤에 라우터로 여러 갈래가 각각 데이터를 쓰는 구조는 위험합니다. 한 갈래가 실패해 부분 재실행되면 나머지 갈래는 또 실행되니까요. 되돌릴 수 없는 쓰기 작업이 있는 갈래마다 별도의 가드를 두는 편이 안전합니다.
순차 처리와 미완료 실행의 조합
시나리오 설정에는 데이터를 받은 순서대로 처리하는 순차 처리 옵션과, 실패한 실행을 보관하는 미완료 실행(incomplete executions) 옵션이 있습니다. Make 시나리오 설정 문서에 따르면 순차 처리가 켜진 상태에서 미완료 실행이 생기면 순서를 지키기 위해 이후 실행이 대기 상태가 되고, 미완료 실행이 정리되어야 다시 움직입니다.
중복이 무서워 순차 처리를 켜두는 경우가 있는데, 에러 하나가 큐 전체를 세울 수 있다는 점을 알고 써야 합니다. 중복 방지는 순차 처리가 아니라 키 기반 검사로 푸는 것이 원래 방향입니다.
조회 모듈도 operations를 씁니다
Make는 모듈 실행 단위로 operations를 계산합니다. 중복 검사를 넣으면 실행마다 조회 1회, 기록 1회가 더 붙습니다. 다만 중복 실행 한 번이 만들어내는 뒷수습 비용을 생각하면 대개 남는 장사입니다. 트래픽이 많은 시나리오라면 트리거 직후 필터로 명백히 무관한 건을 먼저 걸러내고, 살아남은 건에 대해서만 조회하도록 순서를 조정하세요.
결론
중복 실행은 시나리오를 정교하게 만들어서 없애는 게 아니라, "이 건은 처리했다"는 기억을 남겨서 없앱니다. 소스의 고유 ID를 키로 삼고, 쓰기 전에 조회하고, 순서를 정해 기록하고, 오래된 것은 지운다 — 이 네 가지면 대부분의 중복은 사라집니다. 오늘 돌고 있는 시나리오 중 되돌릴 수 없는 작업을 하는 것 하나만 골라, 트리거 다음에 Get a record와 필터를 끼워 넣는 것부터 시작해보세요.
※ 본 글은 작성 시점(2026년 8월) 기준의 Make 기능과 공식 문서를 바탕으로 합니다. 요금제별 제공 범위와 모듈 구성은 변경될 수 있으니 실제 설정 전 공식 도움말에서 최신 내용을 확인하시기 바랍니다.
댓글 없음:
댓글 쓰기