Make 시나리오가 한 번은 잘 작동했는데, 같은 메일·폼 응답·주문이 두 번 기록되면 자동화에 대한 신뢰가 빠르게 떨어집니다. 중복은 단순히 보기 싫은 문제가 아닙니다. 같은 고객에게 알림이 두 번 가거나, 같은 업무가 두 번 생성되고, 처리 비용도 늘어날 수 있습니다.
핵심은 “이 입력을 이미 처리했는가?”를 판단할 고유 키를 정하고, 그 키를 기준으로 다음 단계를 통과시키는 것입니다. 이 글은 Make Data Store에서 키를 확인하고 재등록을 막은 실제 실습과, 운영 자동화에 적용하기 전에 남는 한계를 설명합니다.
먼저 중복을 구분할 값을 정합니다
제목, 이름, 수신 시간처럼 겹칠 수 있는 값만으로는 중복을 막기 어렵습니다. 가능한 한 서비스가 제공하는 고유 ID를 쓰는 편이 안전합니다.
| 입력 종류 | 우선 검토할 키 | 피해야 할 값 |
|---|---|---|
| 이메일 | 메일 메시지 ID | 제목, 발신자 이름 |
| 폼 응답 | 응답 ID | 이름, 제출 시각만 사용 |
| 스프레드시트 행 | 행의 고유 ID 또는 별도 관리 번호 | 행 번호만 사용 |
| 외부 주문·문의 | 주문 번호·문의 ID | 상품명, 고객명 |
여러 출처의 ID가 겹칠 수 있다면 원본 서비스 + 원본 ID처럼 출처를 함께 기록합니다. 원본 ID 자체가 없다면 이 조합만으로 해결되지 않습니다. 최초 입력 때 안정적인 관리 번호를 부여하고, 같은 사건의 재전송에서는 그 번호를 유지하도록 입력 규칙을 먼저 정하세요. 실행할 때마다 새 번호를 만들면 중복을 구분할 수 없습니다.
검증 범위: 2026년 9월 13~14일 Make에서 샘플 키만 사용하는 수동 시나리오를 직접 실행했습니다. 새 키 등록, 같은 키 재입력 차단, 공백 문자열 차단, 덮어쓰기 금지 시 중복 키 오류를 확인했습니다. 실제 이메일 발송·시트 기록, 동시 실행, 외부 작업 성공 후 장애 복구는 검증하지 않았습니다. 아래 실습은 “정확히 한 번” 처리 보장 템플릿이 아닙니다.
실습: 외부 앱 없이 키 하나로 확인하기
고객 메일이나 주문 대신 FW-DEDUPE-001이라는 가짜 키를 사용합니다. 먼저 Data Store의 조회·등록이 어떻게 이어지는지 확인하고, 외부 작업 연결은 별도로 검증하는 순서입니다. 실습 중에는 스케줄을 켜지 말고 Run once로만 실행하세요.
Basic trigger [1] → 공백 차단 Filter → Check the existence of a record [2] → Exists가 false인 경우만 통과 → Add/replace a record [3]
1. 실습 전용 저장소와 입력 만들기
이번에는 Flowwork Lab - dedupe keys only라는 1MB Data Store를 만들었습니다. 존재 여부만 확인하므로 Data structure 없이 기본 키만 저장했습니다. 1MB는 이번 실습에서 선택한 크기이지 모든 계정의 필수 조건은 아닙니다. 기존 업무용 저장소는 사용하지 마세요.
Tools → Basic trigger의 Bundles에 한 항목을 추가하고 그 안의 Items에서 Name은 dedupe_key, Value는 FW-DEDUPE-001로 입력합니다. 이 키는 같은 입력을 재시험할 때 그대로 유지합니다.
2. 조회 전에 공백 문자열 막기
첫 연결선에 Filter를 추가합니다. 왼쪽 값은 Basic trigger의 dedupe_key를 매핑하고, 연산자는 Text operators → Matches pattern, 오른쪽 패턴은 \S로 설정합니다. 패턴에는 역슬래시 하나와 대문자 S를 입력합니다. 이번 조건은 공백이 아닌 문자가 있는 문자열을 통과시키기 위한 것입니다.
이번에 실제로 시험한 값은 스페이스 3개만 있는 문자열입니다. 그 값은 조회 전에 차단됐습니다. 필드 누락, null, 길이 0인 문자열은 이번 시험에 포함하지 않았으므로 입력 앱을 연결할 때 각각 추가 확인해야 합니다. 이 필터는 키 양끝의 공백을 제거하거나 잘못된 형식을 정정하지도 않습니다.
3. 존재 여부를 Boolean으로 비교하기
Data store → Check the existence of a record에서 실습 저장소를 선택하고 Key에 1.dedupe_key를 매핑합니다. 새 키를 조회했을 때 OUTPUT의 Bundle 1에 Exists: false가 반환됐습니다. 결과가 없어서 번들 자체가 사라진 것이 아닙니다.
두 번째 연결선 Filter의 왼쪽에는 모듈 [2]의 Exists를 매핑합니다. 연산자는 Boolean operators → Is false를 선택합니다. 문자열 “false”를 직접 입력해 비교하는 방식과 구분하세요.
4. 없는 키만 등록하기
Data store → Add/replace a record에서 같은 저장소를 고르고 Key에 1.dedupe_key를 매핑합니다. Overwrite an existing record는 No로 둡니다. 모듈 설정 안내상 Key를 비우면 새 키가 생성되므로, 재입력을 구별하려면 원래 키를 정확히 매핑해야 합니다.
이 실습에서는 등록 자체가 마지막 작업입니다. 이 위치를 그대로 고객 발송이나 결제로 바꿔도 안전하다는 뜻은 아닙니다. 외부 작업과 완료 기록 사이의 실패 문제는 뒤에서 따로 설명합니다.
직접 실행한 결과
| 시험 | 실제 관찰 | 의미 |
|---|---|---|
| 처음 보는 FW-DEDUPE-001 | Exists=false, 등록 전 필터 1건 통과, Add/replace 성공. 전체 3 operations / 3 credits. | 없는 키의 조회 결과가 다음 단계로 전달되고 키가 등록됨 |
| 같은 키로 다시 Run once | Exists=true, 등록 전 필터 0건 통과, Add/replace 미실행. 전체 2 operations / 2 credits. | 순서대로 재입력한 동일 키는 다시 등록되지 않음 |
| 스페이스 3개만 입력 | 첫 필터 0건 통과. 조회·등록 미실행. Basic trigger만 1 operation / 1 credit. | 공백 문자열이 저장소까지 가지 않음 |
| 같은 키로 등록 모듈만 단독 실행 | Overwrite=false에서 DataError / Duplicate key error. 1 operation / 1 credit. | 존재 확인 필터를 우회해 같은 키를 넣으면 덮어쓰기 대신 오류가 발생함 |
위 사용량은 이 단순 시나리오의 실행 기록입니다. 다른 앱·모듈이나 AI 작업을 추가한 경우의 요금 예측값으로 사용하지 마세요. 마지막 단독 실행은 중복 오류를 확인하기 위한 의도적인 시험이며, 병렬 실행이나 외부 작업 장애를 재현한 것은 아닙니다.
따라 했는데 결과가 다르면
- 재실행할 때 계속 false: 조회와 등록이 같은 Data Store를 쓰는지, 두 Key가 모두 같은 입력을 가리키는지 확인합니다. 새 키를 매번 생성하지 마세요.
- true인데 등록이 실행됨: 등록 전 Filter가 Exists를 Boolean의 Is false로 검사하는지 확인합니다.
- 공백 키가 조회까지 도착함: 첫 Filter가 조회 앞에 있는지, 패턴이 역슬래시 하나와 대문자 S인지 확인합니다.
- 원치 않는 Duplicate key error: 중복 필터를 거치지 않은 단독 실행인지, 다른 실행이 먼저 등록했는지 점검합니다. 바로 덮어쓰기를 허용하거나 오류를 무시하지 마세요.
실습이 끝나면 입력을 정상 샘플 키로 돌리고 시나리오를 저장합니다. 이번 환경은 정상 키로 복구한 뒤 다시 수동 실행했으며, 자동 스케줄은 비활성 상태로 두었습니다. 같은 실습을 새 키로 시작하려면 기존 기록을 지우기보다 별도의 테스트 키를 사용하세요.
외부 작업을 연결할 때 남는 한계
상태를 적는 것만으로 동시 실행이 막히지는 않습니다
두 실행 A·B가 같은 키를 동시에 조회하면 둘 다 “없음”을 보고 외부 작업을 수행할 수 있습니다. 처리 중과 완료 필드는 복구 판단에 유용하지만, 상태 필드 자체는 잠금 장치가 아닙니다.
| 실패 지점 | 잘못된 재시도의 위험 | 먼저 확인할 것 |
|---|---|---|
| 외부 작업 전 실패 | 완료로 기록했다면 실제 작업이 영영 생략될 수 있음 | 외부 결과가 정말 없는지 |
| 외부 작업은 성공, 완료 기록만 실패 | 전체 재실행하면 행·알림이 다시 만들어질 수 있음 | 원본 ID로 외부 결과를 대조 |
| 같은 키가 동시에 도착 | 존재 확인만으로 두 실행 모두 통과 가능 | 같은 키의 작업을 하나만 허용하는 원자적 선점 또는 수신 API의 멱등 키 지원 여부 |
원자적 선점은 “아직 없는지 확인하고 내 처리 대상으로 예약하는 것”을 분리할 수 없는 한 동작으로 수행하는 설계입니다. 여러 모듈을 연결한 것만으로 이 보장이 생기지 않습니다. 서버·저장소와 수신 API가 실제로 지원하는 방식을 확인해야 하며, 이 글에서는 특정 잠금 구현을 실행 검증하지 않았습니다. 금전·고객 발송처럼 중복 피해가 큰 작업은 이 검증 전 자동 운영하지 마세요.
Gmail → Google Sheets 예시
테스트용 메일을 시트에 기록하는 흐름이라면 다음처럼 생각할 수 있습니다.
Gmail 새 메일 감지 → 메시지 ID 추출 → 기존 시트 또는 Data Store에서 ID 검색 → 없을 때만 Google Sheets에 행 추가 → ID와 처리 시각 기록
시트에는 제목·보낸 사람·수신 시각과 함께 메시지 ID 열을 남겨 두세요. 나중에 “이 행이 어느 원본 메일에서 왔는가?”를 확인할 수 있고, 동일한 메일을 다시 받았을 때 검색 기준도 분명해집니다.
시트 검색 0건과 존재 여부 false는 다릅니다
Search Rows가 번들을 내보내지 않으면 뒤의 Filter도 실행할 입력을 받지 못할 수 있습니다. Data Store의 존재 여부 false와 같은 출력으로 가정하면 안 됩니다. 없는 ID를 넣고 조회 모듈의 OUTPUT 및 후속 실행 여부를 먼저 확인하세요. Gmail→Sheets 연결 실습의 검색 0건 점검에서 이 함정을 구분합니다.
자동 실행 전에 이 다섯 가지를 테스트하세요
- 새 키 1개: 행·알림·데이터베이스 항목이 정확히 한 번 만들어지는지 봅니다.
- 같은 키 재입력: 새 작업이 추가되지 않거나, 정해 둔 중복 경로로 빠지는지 확인합니다.
- 키가 비어 있는 입력: 임의로 처리하지 않고 검토 대상으로 남기는지 확인합니다.
- 실패 후 재시도: 외부 작업 전 실패와 외부 작업 성공 후 완료 기록 실패를 나눠 검사합니다. 실제 결과를 조회하지 않고 무조건 다시 실행하지 않습니다.
- 동일 키의 동시 입력: 두 실행이 겹칠 때도 외부 결과가 하나만 생기는지 확인합니다. 순서대로 두 번 실행한 테스트와는 다릅니다.
테스트는 반드시 가짜 데이터나 전용 라벨·전용 시트에서 시작하세요. 고객 정보나 실제 주문을 여러 건 넣고 바로 반복 실행하는 방식은 피하는 편이 안전합니다.
기록을 너무 많이 남기지 마세요
중복 방지의 목적은 필요한 작업을 한 번만 처리하는 것입니다. 원문 전체, 첨부 파일, 민감한 내용까지 모두 Data Store에 복사할 필요는 없습니다. 고유 키, 상태, 처리 시각처럼 운영에 필요한 최소 정보만 남기면 확인도 쉬워지고 보안 부담도 줄어듭니다.
다음에 읽으면 좋은 글
- Make 데이터 매핑 기초: 이전 모듈의 값을 다음 단계에 쓰는 법
- Make 시나리오 테스트: 자동 실행 전에 확인할 7가지
- Make 시나리오 오류 해결: 실행 기록·크레딧·Incomplete Execution 점검법
기능과 메뉴는 변경될 수 있습니다. 설정 전에는 Make 공식 Data Store 도움말과 오류 처리 도움말을 함께 확인하세요. 메뉴 표기는 2026년 9월 13~14일 직접 실행한 환경을 기준으로 작성했습니다.
2026-09-15 보완: 테스트 키를 사용한 4가지 실행 결과와 실제 화면 2장을 추가했습니다. 순차 재입력 차단과 동시 실행·외부 작업 장애 복구를 구분했습니다. 후자의 운영 검증은 아직 완료하지 않았습니다.