제휴 및 광고 고지: 이 글은 자동화 도구를 비교하고 선택하는 독자를 위한 정보성 글입니다. 일부 링크에는 제휴 또는 광고 성격이 포함될 수 있으며, 최종 도입 전 공식 요금제와 약관을 확인해야 합니다.
Make 시나리오에서 중요한 것은 연결한 앱 개수보다 ‘한 건의 입력이 어디로 가는가’입니다. 입력값을 다음 모듈의 어느 칸에 넣는지, 어떤 조건에서 통과하는지, 실패한 뒤 무엇을 다시 실행하는지 설명할 수 있어야 수정도 할 수 있습니다.
이 글은 2026년 9월 27일 확인한 공식 문서 기반 안내입니다. 가상 문의 데이터를 예시로 사용하며, 실제 계정의 연결·시나리오 실행·고객 발송을 수행한 기록은 아닙니다.
첫 시나리오는 한 건의 처리 경로로 그립니다
예를 들어 ‘문의 자료를 받아 유형에 따라 내부 검토 목록에 기록한다’는 흐름을 연습한다고 가정하겠습니다. 고객에게 보내는 메일이나 견적 확정은 포함하지 않습니다. 먼저 종이에 다음처럼 적습니다.
문의 입력 → 필요한 값 확인 → 유형별 분기 → 시험용 목록에 기록
사용할 입력 예시는 아래와 같습니다. 제품이 제공하는 표준 필드가 아니라 학습용으로 정한 데이터입니다.
| 필드 | 가상 값 | 처리 목적 |
|---|---|---|
| request_id | DEMO-001 | 동일한 문의인지 대조 |
| kind | 자료요청 | 어느 검토 목록으로 보낼지 결정 |
| subject | 서비스 소개 자료 문의 | 담당자가 내용을 알아보도록 표시 |
| received_at | 시험 시각을 직접 기록 | 누락·지연 비교 |
실제로 선택한 앱의 모듈이 이 정보를 반환하는지는 별도 확인해야 합니다. 앱 이름만 같다고 서로 다른 트리거가 같은 필드를 제공하지는 않습니다.
bundle과 mapping은 값이 지나가는 단위입니다
Make 도움말은 bundle을 모듈이 다루는 데이터 묶음으로 설명합니다. Mapping은 앞 모듈에서 얻은 정보를 뒤 모듈의 필드에 연결하는 작업입니다. 모듈의 출력 bundle을 열어 실제 반환값을 확인한 다음 필요한 항목을 연결하세요. Mapping 공식 안내
예시에서는 request_id를 대상 목록의 문의 ID 칸에, subject를 제목 칸에 넣는다고 생각할 수 있습니다. 화면에 표시되는 제목이 비슷하더라도 내부 ID와 표시 이름을 혼동하지 않도록 실제 값을 확인합니다. 날짜·숫자·텍스트도 대상 필드가 기대하는 형식과 맞아야 합니다.
한 번의 실행이 항상 문의 한 건과 같다고 가정하지 마세요. 출력이 여러 bundle이면 다음 단계가 여러 번 처리될 수 있습니다. 따라서 ‘실행 버튼을 한 번 눌렀다’보다 각 모듈에 몇 개의 데이터가 들어가고 나왔는지를 봅니다.
필터는 통과 조건이고, 라우터는 경로를 나눕니다
필터는 모듈 사이에서 조건을 검사해 맞는 bundle만 다음 단계로 보냅니다. Exists로 값 존재 여부를 확인하는 등 여러 연산자를 사용할 수 있습니다. 조건에 맞지 않아 통과하지 않은 경우와 앱 호출이 실패한 경우는 다릅니다. 필터 공식 안내
Router는 여러 경로를 만들며 경로는 순차 처리됩니다. 어느 일반 경로의 조건에도 맞지 않는 데이터를 처리하는 fallback 경로도 둘 수 있습니다. Router 공식 안내
가상 문의를 분류한다면 다음처럼 서로 겹치지 않는 조건을 제안합니다.
| 경로 | 조건 제안 | 결과 제안 |
|---|---|---|
| 자료 안내 검토 | kind가 자료요청 | 자료 검토 목록에 기록 |
| 일정 상담 검토 | kind가 일정상담 | 일정 검토 목록에 기록 |
| 나머지 | fallback | 유형 확인 필요 목록에 기록 |
라우터를 ‘첫 조건에 맞으면 나머지 경로는 무조건 생략하는 문장’으로 생각하지 마세요. 같은 데이터가 여러 조건을 만족할 수 있도록 설계하면 여러 경로에서 처리될 가능성을 고려해야 합니다. 원치 않는 중복 기록이 생기지 않도록 조건을 겹치지 않게 하고, 하나의 입력으로 어떤 경로가 실행되었는지 확인합니다.
수동 시험과 예약 실행을 분리합니다
On demand 스케줄에서는 수동 실행이나 API 호출로 시작하며 정기 스케줄로 돌지 않습니다. 정기 실행 간격의 최솟값은 플랜에 따라 다르고 Immediately 선택지는 일부 트리거에만 있습니다. 따라서 ‘자동화니까 즉시 실행’이라고 설명할 수 없습니다. 시나리오 스케줄
처음에는 실제 고객과 분리한 시험용 입력·대상을 사용합니다. 정상 문의, kind 누락, 알 수 없는 유형, 같은 request_id 재입력을 각각 확인하세요. 중복 방지는 고유한 값이 있다는 이유만으로 완성되지 않습니다. 대상을 조회하거나 기존 처리 기록과 대조하는 규칙이 필요할 수 있으며, 구체적인 구현은 선택한 저장 앱에 따라 달라집니다.
실패했을 때는 전체를 다시 누르기 전에 이력을 봅니다
History의 실행 상세에서 모듈 출력과 처리된 bundle을 볼 수 있습니다. 완료 상태만 보지 말고 예상한 대상에 예상한 값이 기록되었는지도 확인하세요. 실행 이력 공식 안내
| 증상 | 우선 확인 | 복구 판단 |
|---|---|---|
| 제목이 비어 있음 | 원본 출력과 mapping | 값을 고친 뒤 시험 입력으로 재확인 |
| 모든 문의가 빠짐 | 필터 값·형식·공백 | 실제 bundle과 조건을 대조 |
| 두 목록에 중복 기록 | 겹치는 분기 조건 | 조건을 정리하고 중복 결과는 별도 확인 |
| 뒤 모듈에서 실패 | 앞 모듈이 이미 기록했는지 | 전체 재실행 전에 부수 효과 확인 |
| 예약했는데 안 돎 | 활성화 상태·스케줄·트리거 유형 | 수동 성공과 예약 동작을 따로 검증 |
Incomplete executions는 중단된 실행을 저장해 검토·재처리하는 기능이며 기본적으로 꺼져 있습니다. 설정에서 저장을 켤 수 있지만, 모든 오류가 자동 해결되거나 외부 앱의 변경이 되돌아간다는 뜻은 아닙니다. 미완료 실행 공식 안내
첫 시나리오의 완료 기준은 모듈이 많이 연결된 화면이 아닙니다. 정상·누락·분류 불가·중복 입력에서 어느 경로로 갔는지 설명할 수 있고, 실패 후 어디서 재개할지 정해져 있어야 합니다. 여기의 점검표는 독자가 실행할 절차이며 본 원고에서 통과한 시험으로 제시하지 않습니다.
