Make 시나리오를 처음 만들면 모듈은 연결했는데 다음 단계의 필드가 비어 있는 경우가 많습니다. 이때 필요한 것이 데이터 매핑입니다. 앞 모듈이 받은 정보를 다음 모듈의 입력에 넣으면, 같은 시나리오가 매번 다른 메일·폼 응답·시트 행을 처리할 수 있습니다.
Make에서는 한 번에 처리되는 관련 데이터 묶음을 번들(bundle)이라고 부릅니다. 트리거가 번들을 가져오면, 다음 모듈은 그 번들을 입력으로 받아 자기 작업을 수행합니다. 이 흐름을 이해하면 매핑 화면이 훨씬 쉬워집니다.
모듈·번들·매핑을 한 문장으로 이해하기
- 모듈: 특정 앱에서 하나의 일을 하는 단계입니다. 예: 새 행 찾기, 이메일 보내기, 데이터베이스 항목 만들기.
- 번들: 한 번 처리할 관련 정보의 묶음입니다. 예: 한 명의 문의자 이름·이메일·문의 내용.
- 매핑: 앞 모듈의 번들 안에 있는 값을 다음 모듈 필드에 넣는 작업입니다.
예를 들어 Google Sheets에서 새 행을 찾았다면, 그 행의 이름과 이메일은 하나의 번들에 들어 있습니다. 다음 Gmail 모듈의 수신자·제목·본문에 이 값을 각각 매핑하면, 행마다 다른 이메일을 만들 수 있습니다.
매핑은 이 순서로 하면 됩니다
- 먼저 트리거 또는 앞 모듈을 한 번 실행해 샘플 데이터를 만듭니다.
- 다음 모듈의 입력 필드를 클릭합니다.
- 열리는 매핑 목록에서 앞 모듈의 필요한 값을 선택합니다.
- 저장한 뒤 테스트 실행으로 입력·출력 번들을 확인합니다.
처음에는 복잡한 함수보다 제목, 이름, 이메일처럼 단순한 텍스트 하나를 옮기는 연습부터 하세요.
실전 예시: 새 문의를 내부 데이터베이스에 기록하기
| 앞 모듈의 값 | 다음 모듈의 필드 | 의도 |
|---|---|---|
| 문의 제목 | 데이터베이스 제목 | 목록에서 항목을 빠르게 구분 |
| 문의 내용 | 메모 또는 본문 | 원문을 남김 |
| 보낸 사람 이메일 | 연락처 속성 | 검토 시 출처 확인 |
| 수신 시각 | 접수 일시 | 처리 순서와 기한 판단 |
| 원본 ID | 고유 ID 속성 | 중복 기록 방지 |
여기에 상태값을 하나 더 둡니다. 예를 들어 새 항목은 ‘검토 필요’로 만들고, 사람이 확인한 뒤 ‘처리 중’이나 ‘완료’로 바꾸면 자동화와 사람이 같은 흐름을 공유할 수 있습니다.
샘플 데이터가 없으면 왜 매핑이 어렵나요?
Make는 앞 모듈이 어떤 항목을 반환하는지 알아야 매핑 목록에 보여 줄 수 있습니다. 그래서 새 시나리오에서는 먼저 Run once 또는 특정 모듈 실행으로 샘플 번들을 받아야 할 때가 있습니다.
트리거 종류에 따라 방법은 다릅니다. 즉시 실행되는 트리거는 실제 테스트 이벤트가 들어와야 할 수 있고, 주기적으로 확인하는 트리거는 과거 데이터가 있는 시점부터 시작하도록 설정해 번들을 만들 수 있습니다. 이때는 실제 고객 데이터보다 테스트용 항목을 쓰는 편이 안전합니다.
값이 보이지 않거나 비어 있을 때
- 앞 모듈을 실행했는지: 매핑 목록은 실행 결과를 기반으로 보이는 경우가 많습니다.
- 필드가 실제 출력에 있는지: 모듈의 실행 결과에서 input·output 번들을 직접 확인합니다.
- 텍스트·날짜·숫자 형식이 맞는지: 대상 필드가 기대하는 형식과 일치하는지 확인합니다.
- 선택한 값이 맞는지: 비슷한 이름의 이메일·ID·제목 필드를 혼동하지 않았는지 확인합니다.
- 여러 번들이 한꺼번에 들어오는지: 한 번들이 아닌 여러 건을 처리할 때는 다음 모듈도 건별로 실행될 수 있습니다.
번들이 많아지면 실행 횟수도 늘어납니다
트리거가 한 번 실행돼도 여러 번들을 반환할 수 있습니다. 그 뒤 모듈은 각 번들을 처리하면서 여러 번 실행될 수 있으므로, 테스트할 때는 몇 건이 들어왔는지와 어떤 순서로 처리됐는지 확인하는 습관이 중요합니다.
처음에는 한 건의 테스트 데이터로 흐름을 확인하고, 다음에 3~5건을 넣어 중복·누락·형식 문제를 살펴보세요. 한꺼번에 많은 실제 데이터를 처리하는 것은 나중 단계입니다.
매핑 전에 필드 이름을 정리하면 좋습니다
여러 서비스를 연결할수록 제목·이름·상태 같은 공통 필드 이름을 정해 두는 편이 좋습니다. 예를 들어 어느 앱에서 왔든 title, source, status, original_id로 정리하면 이후 필터와 데이터베이스 기록을 반복해서 만들기 쉬워집니다.
Make에서 좋은 매핑은 값을 많이 옮기는 것이 아니라, 다음 단계에 정말 필요한 값을 정확히 옮기는 것입니다. 한 필드씩 실행 결과를 확인하며 늘려 가면 오류를 빨리 찾을 수 있습니다.
참고: Make Help Center — Mapping, Scenario execution flow