Iterator는 배열 하나를 항목별 번들로 나누는 Make 모듈입니다. 이 글에서는 외부 계정 연결 없이 샘플 업무 3건을 분리해 봅니다. 실행 화면에 표시되는 1 operation과 실제 출력인 3 bundles가 왜 다른지도 확인합니다.
직접 실행 확인: 2026년 9월 13일. Make EU 환경의 Free 계정에서 Basic trigger → Parse JSON → Iterator → Array aggregator → Set variable을 수동 실행했습니다. 고객 정보, 메일 발송, 파일 업로드는 사용하지 않았고 예약 실행은 꺼두었습니다. 이 기록은 아래 샘플 흐름에 한정되며, Gmail·Drive 등 외부 앱 연결까지 검증한 것은 아닙니다.
이 실습으로 확인할 결과
- 입력:
tasks배열 안의 업무 3건 - Iterator 출력:
FW-001,FW-002,FW-003번들 3개 - 확장 실습:
status = ready조건을 통과한 2건을 배열 하나로 다시 묶기
1. 먼저 배열인지, 이미 여러 번들인지 구분하기
| 원본 출력 형태 | 판단 |
|---|---|
Bundle 1 안에 tasks[]가 있고 그 안에 3건이 있음 | Iterator의 Array에 tasks[]를 연결 |
| 검색 모듈이 Bundle 1, Bundle 2, Bundle 3을 이미 출력함 | 보통 Iterator 없이 후속 모듈로 연결 |
| 목록처럼 보이지만 실제로는 긴 문자열임 | 먼저 JSON 구조로 해석할 수 있는지 확인 |
Google Sheets에서 여러 행을 찾았다고 항상 Iterator가 필요한 것은 아닙니다. 먼저 실행 결과의 Bundle 수와 그 안의 필드를 보세요. 배열과 번들이 낯설다면 Make 첫 시나리오 가이드를 먼저 읽어도 좋습니다.
2. 그대로 복사할 테스트 데이터
새 테스트 시나리오에서 Tools → Basic trigger를 시작 모듈로 선택합니다. Bundles에 항목 하나를 만들고 그 안의 Items에 Name source, Value flowwork-lab을 넣습니다. 다음에 JSON → Parse JSON을 연결하고 JSON string에 아래 내용을 붙여 넣으세요.
{
"tasks": [
{
"id": "FW-001",
"title": "문의 분류",
"team": "sales",
"status": "ready"
},
{
"id": "FW-002",
"title": "견적 확인",
"team": "sales",
"status": "hold"
},
{
"id": "FW-003",
"title": "자료 정리",
"team": "ops",
"status": "ready"
}
]
}중괄호로 시작하는 객체 안에 tasks 배열을 넣은 이유가 있습니다. 이 형태에서는 Parse JSON이 배열을 담은 번들 하나를 내보냅니다. 반대로 JSON 전체를 [{...},{...}]처럼 최상위 배열로 넣으면 Parse JSON 자체가 항목별 번들을 출력할 수 있어 이번 실습 구조와 달라집니다.
Data structure를 따로 만들지 않았다면 Parse JSON을 우클릭해 Run this module로 한 번 실행하세요. 이번 확인 화면에서는 Output의 Bundle 1 아래에 tasks 배열과 항목 1·2·3이 나타났습니다. Make JSON 공식 문서에서도 샘플 실행을 통한 구조 인식과 최상위 객체·배열의 차이를 설명합니다.
3. Iterator에는 배열 전체를 연결하기
- Parse JSON 오른쪽의 연결 지점에서 Flow Control → Iterator를 추가합니다.
- Array 입력칸을 열고 Parse JSON 출력의 tasks[]를 선택합니다.
id나title한 칸만 선택하지 않습니다. 나눌 대상은 배열 전체입니다.- 저장한 뒤 실행 전에 연결선을 확인합니다. 모듈을 화면에 놓기만 하고 시작 모듈과 연결하지 않으면 의도한 경로가 실행되지 않을 수 있습니다.
화면의 모듈 번호는 생성 순서에 따라 달라집니다. 테스트에서는 Parse JSON이 2번, Iterator가 3번이었지만 번호를 그대로 입력할 필요는 없습니다. 각자의 매핑 패널에서 모듈 이름과 필드를 골라 연결하세요.
4. 실제 출력: operation 1회, 번들 3개
테스트에서는 결과를 확인하기 위해 뒤에 Array aggregator와 Tools의 Set variable을 연결했습니다. 전체를 Run once로 실행한 뒤 Iterator 위의 실행 결과 표시 → Operation 1 → Output을 열었습니다.
| 출력 | id | title | team | status |
|---|---|---|---|---|
| Bundle 1 | FW-001 | 문의 분류 | sales | ready |
| Bundle 2 | FW-002 | 견적 확인 | sales | hold |
| Bundle 3 | FW-003 | 자료 정리 | ops | ready |
세 번들 모두 Total number of bundles = 3이었고 Bundle order position은 각각 1, 2, 3이었습니다. Iterator의 Summary에는 1 operation, 1 credit used가 표시됐습니다. 이 수치는 이번 입력에서 관찰한 값이지 모든 시나리오의 비용 공식은 아닙니다. 모듈 위의 숫자만 보고 ‘한 건밖에 처리되지 않았다’고 판단하지 마세요.
5. 조건에 맞는 업무만 남기기
Iterator 뒤 연결선에 필터를 놓고 왼쪽에는 Iterator의 status, 비교 방식에는 Text operators: Equal to, 오른쪽에는 직접 입력한 ready를 넣었습니다. 실제로 FW-001과 FW-003 두 건이 통과하고 FW-002는 제외됐습니다.
여기서 원본 Parse JSON의 tasks 전체가 아니라 현재 Iterator 번들의 status를 골라야 합니다. 또한 왼쪽의 매핑 토큰 옆에 ready를 붙여 쓰는 것이 아니라 오른쪽 비교값 칸에 넣습니다.
통과한 두 건을 한 목록으로 다시 묶는 설정과 실제 결과 화면은 Array Aggregator 실습에서 이어집니다. 두 모듈을 함께 사용하더라도 ‘나누기’와 ‘묶기’의 출력 개수는 따로 확인해야 합니다.
결과가 다를 때 확인할 것
| 증상 | 확인 순서 |
|---|---|
| 매핑 패널에 tasks나 id가 없음 | Parse JSON을 샘플로 먼저 실행하고 매핑 창을 다시 열기 |
| Array에 배열이 아닌 텍스트가 들어감 | JSON string 자체가 아니라 파싱 결과의 tasks[]를 선택했는지 확인 |
| 실행 완료인데 데이터가 없음 | 시작 모듈과 연결선, Iterator의 실제 Output, 필터 통과 수를 차례로 확인 |
| 원하지 않는 항목까지 처리됨 | 필터가 Iterator 뒤에 있는지, 현재 번들의 status와 비교하는지 확인 |
| 운영 중 같은 항목이 중복 처리됨 | Iterator가 중복을 제거해 주는 것은 아님. 별도의 처리 이력과 고유 ID 정책 필요 |
실제 메일 발송이나 업로드로 확장할 때는 이 샘플 결과가 맞는지 먼저 확인한 뒤 대상과 권한을 좁혀 연결하세요. 재실행 시 부작용을 막는 방법은 Make 중복 실행 방지에서 다룹니다.
근거: 직접 수동 실행 기록(2026-09-13), Make Iterator 도움말, Make JSON 문서. 직접 확인한 범위와 외부 서비스 연동 예시는 구분했습니다.