Make에서 Run once를 눌렀을 때 초록색 표시가 나왔다고 해서 원하는 데이터가 정확히 저장됐다는 뜻은 아닙니다. 실행은 끝났지만 필터에서 모두 제외됐거나, 같은 값이 잘못 매핑됐을 수도 있습니다. 이 글은 실행 화면에서 입력 → 출력 → 다음 모듈의 입력을 대조하는 방법을 다룹니다.
처음부터 배포 여부를 결정하려면 자동화 배포 판단표를 보세요. 여기서는 예약 실행을 켜지 않고 수동 실행 결과를 읽는 데 집중합니다.
1. Run once도 실제 작업을 실행합니다
Run once는 미리보기나 모의 실행 버튼이 아닙니다. 시나리오에 메일 발송·행 추가·파일 변경 모듈이 연결돼 있으면 해당 작업이 실제로 수행될 수 있습니다. 이 글을 따라 볼 때는 외부 연결이 없는 샘플 시나리오를 사용하세요. 예약이 꺼져 있는지와 별개로 수동 실행의 영향 범위를 확인해야 합니다.
테스트를 시작하기 전에 시나리오 이름, 바꾼 설정 한 가지, 입력값, 기대 결과를 적습니다. 여러 설정을 동시에 바꾸면 결과가 달라진 이유를 구분하기 어렵습니다.
2. 화면의 숫자 세 가지를 구별하기
| 항목 | 읽는 뜻 | 오해하기 쉬운 부분 |
|---|---|---|
| Operation | 모듈이 실행돼 데이터를 처리하거나 확인한 횟수 | 출력 항목 수와 반드시 같지는 않음 |
| Bundle | 모듈이 주고받는 데이터 묶음 | 한 번들 안의 배열 3항목과 번들 3개는 다름 |
| Credit | 해당 실행에 표시되는 사용량 | 일부 실습의 operation과 같았다는 사실을 모든 모듈의 과금 규칙으로 일반화하면 안 됨 |
Make 공식 Operations 설명에 따르면 모듈 위 실행 표시를 열고 operation과 bundle을 펼쳐 입력·출력을 확인할 수 있습니다. 현재 실행과 과거 History의 다른 실행을 섞어 읽지 않도록 실행 시각도 함께 기록하세요.
3. 실제 배열 실습에서 읽은 결과
Flowwork HQ는 2026년 9월 13일 외부 앱을 연결하지 않은 수동 시나리오에서 샘플 3건을 분리하고 집계했습니다. 입력과 설정은 Iterator 실습의 샘플 JSON, 집계 설정과 화면은 Array Aggregator 실습에서 확인할 수 있습니다.
| 관찰한 위치 | 실제 확인값 | 이 값으로 알 수 있는 것 |
|---|---|---|
| Iterator | 1 operation / 1 credit, 출력 Bundle 1·2·3 | 실행 수 1과 출력 번들 3을 구분해야 함 |
| ready 필터 뒤 Aggregator | FW-001, FW-003 두 항목 | 입력 3건 중 FW-002(hold)가 제외됨 |
| 조건을 no-match로 변경한 실행 | 통과 0건, 집계와 후속 변수 모듈 미실행 | 이 설정에서는 결과 없음이 후속 작업 없음으로 이어짐 |
마지막 경우는 Stop processing after an empty aggregation=Yes로 시험한 결과입니다. 옵션을 끈 경우나 Group by를 사용한 경우까지 같은 결과라고 확인한 것은 아닙니다. 실습 뒤 필터는 ready로 복구했고 자동 스케줄은 켜지 않았습니다.
4. 처음 틀어진 값을 찾는 순서
- 시작 모듈 출력: 원하는 ID가 들어왔는지, 0건인지 여러 건인지 확인합니다. 새 데이터가 없었던 경우와 조건에서 제외된 경우를 구분합니다.
- 문제가 난 모듈 입력: 이전 출력의 어느 필드를 사용했는지 봅니다. 화면에 보이는 고정 문자열을 넣은 것인지, 매핑된 실제 값인지 확인합니다.
- 모듈 출력: 값과 자료형을 봅니다. 배열을 받았는데 한 항목처럼 다루지는 않았는지, 숫자와 문자열을 혼동하지 않았는지 점검합니다.
- 필터: 조건식 양쪽의 실제 값과 통과 여부를 확인합니다. 원하는 경로가 실행되지 않았다면 앞 모듈의 성공 표시만으로 정상이라고 판정하지 않습니다.
- 다음 모듈 입력: 출력이 맞아도 다음 단계가 다른 필드를 참조할 수 있으므로 한 번 더 대조합니다.
- 최종 저장 위치: 외부 앱을 연결한 경우에는 테스트 레코드 ID로 결과를 확인합니다. Make의 성공 표시와 업무상 올바른 저장은 별도 확인 항목입니다.
문제 지점이 정해지면 설정 하나만 고치고 새 실행으로 비교합니다. 과거 실행 화면의 값은 설정을 수정해도 새로운 시험 결과가 되지 않습니다.
5. 실행 결과가 달라도 원인이 같은 것은 아닙니다
| 보이는 현상 | 우선 확인 | 성급히 하지 않을 행동 |
|---|---|---|
| 실행은 끝났지만 최종 결과가 없음 | 시작 출력 0건, 필터 0건, 중간 오류 처리, 집계 옵션 | 정상 완료 표시만 보고 배포하기 |
| 같은 키가 두 번째에는 등록되지 않음 | 존재 확인 결과와 등록 전 필터 | 모든 재실행을 오류로 판단하기 |
| Duplicate key error | 기존 키와 덮어쓰기 설정, 등록 경로 | 오류를 없애려고 곧바로 덮어쓰기를 허용하기 |
| 외부 요청 시간 초과 | 외부 앱에 이미 결과가 생겼는지, 요청·결과 ID | 결과를 확인하지 않고 발송·생성을 반복하기 |
두 번째와 세 번째 상황은 Data Store 키 확인 실습에서 실제로 구분했습니다. 같은 키 재입력 때는 Exists=true여서 등록을 건너뛰었고, 등록 모듈만 직접 실행했을 때는 중복 키 오류가 났습니다. 외부 요청 시간 초과 행은 점검 지침이며 이번 실습에서 장애를 주입한 결과가 아닙니다.
6. 복사해서 쓰는 실행 기록 양식
시험 ID / 실행 시각: 시나리오와 수정한 설정: 입력 샘플 ID와 필수 값: 기대한 번들 수 / 실제 번들 수: 처음 예상과 달라진 모듈과 입력·출력: 최종 결과 ID 또는 미실행 근거: 판정(통과·실패·미확인) / 다음 수정:
예를 들어 위 배열 실습의 기록은 “ready 필터, 입력 3건, 기대 항목 FW-001·FW-003, 실제 2항목”처럼 작성할 수 있습니다. 다만 현재 자신의 계정에서도 같은 결과가 나왔다고 적으려면 직접 실행한 기록을 별도로 남겨야 합니다.
7. 수동 시험에서 아직 알 수 없는 것
Scenario settings 공식 문서는 Run once에서 한 cycle만 수행한다고 설명합니다. 따라서 수동 1회 성공은 정기 실행의 반복 수집 범위, 여러 실행의 동시성, 대량 처리와 복구를 검증하지 않습니다. 필요한 설정의 현재 화면 명칭은 계정에 따라 다를 수 있으므로 문서와 화면을 함께 확인하세요.
공식 오류 처리 개요에 있는 일부 처리 방식은 문제가 난 번들을 건너뛰거나 대체 출력으로 계속 진행합니다. 그래서 전체 실행 상태가 성공이어도 누락·대체 결과가 있는지 확인해야 합니다. 모든 외부 작업이 되돌려지는 것도 아닙니다. 단순히 오류 처리 옵션 하나를 켜면 안전해진다고 보지 마세요.
이전 실습 화면의 증거 범위
아래는 기존 글에 첨부돼 있던 3개 모듈 시나리오의 화면입니다. Basic trigger와 두 Set variable 모듈, 수동 실행 이력과 사용량 표시가 보입니다. 이 한 장에는 각 모듈의 입력·출력 상세가 없으므로 정확한 매핑이나 중복 방지 성공을 입증하는 화면으로 사용하지 않습니다. 위의 배열 실습과는 별개입니다.
다음 단계
입출력 비교가 끝나면 테스트 증거·중지·복구 기준 12가지로 운영 준비를 따로 판단하세요. 앱 연결은 Gmail → Sheets 한 건 연결 실습처럼 범위를 제한합니다.
2026-09-20 개편: 기존 실습 이미지와 9월 13~14일 수동 시험 기록을 구분해 설명했습니다. 이번 글 개편 과정에서 외부 앱 작업·발송·예약 실행을 새로 수행하지 않았습니다.