Make 자동화 2026: 앱은 연결했는데 원하는 값이 안 넘어가는 이유 — 모듈 매핑과 데이터 구조

Photo by Growtika on Unsplash

앱 두 개를 선으로 이어놓고 실행 버튼을 눌렀는데, 다음 모듈로 원하는 값이 안 넘어갑니다. 어떤 칸은 비어 있고, 어떤 값은 엉뚱한 자리에 들어갑니다. Make 자동화를 처음 붙여볼 때 가장 자주 부딪히는 벽은 사실 '앱을 연결하는 일'이 아니라 '연결한 뒤 데이터를 옮기는 일', 즉 매핑(mapping)입니다. 연결은 클릭 몇 번으로 끝나지만, 앞 모듈이 뱉은 데이터가 어떤 모양인지 이해하지 못하면 그다음부터는 계속 헛돕니다.

이 글에서는 왜 "연결했는데 값이 안 넘어가는지", 그리고 목록(배열)이 끼어들면 왜 갑자기 어려워지는지를 번들과 데이터 구조 관점에서 풀어봅니다. (본 글은 작성 시점 기준 Make의 동작 방식을 기준으로 합니다.)

왜 연결했는데 값이 안 넘어갈까

Make의 시나리오는 모듈이 왼쪽에서 오른쪽으로 순서대로 실행됩니다. 각 모듈은 실행되면 결과를 번들(bundle)이라는 묶음으로 내보냅니다. 매핑이란 앞 모듈이 내보낸 번들 안의 값을 골라 뒷 모듈의 입력 칸에 끼워 넣는 작업입니다. 즉 뒷 모듈은 스스로 데이터를 만들어내지 않고, 앞에서 넘어온 번들에서 필요한 조각을 가져다 씁니다. 이 구조를 모르면 "왜 이 칸엔 아무것도 못 넣지?"라는 벽에 계속 부딪힙니다.

초보자가 가장 많이 놓치는 지점이 여기 있습니다. 모듈을 한 번도 실행하지 않으면, 그 모듈이 어떤 필드를 내보내는지 매핑 목록에 나타나지 않을 수 있습니다. 그래서 "분명 이메일 주소가 있을 텐데 고를 항목이 안 보인다"는 상황이 생깁니다. 앞 모듈을 한 번 실행(또는 시나리오를 한 번 돌려)해서 실제 출력 구조를 잡아줘야, 그 뒤부터 매핑 패널에 필드가 뜨는 경우가 많습니다.

번들과 데이터 구조를 눈으로 확인하기

Make에서는 각 모듈을 실행한 뒤 모듈 위에 뜨는 말풍선(실행 결과)을 열어 실제로 어떤 값이 나왔는지 확인할 수 있습니다. 매핑이 자꾸 어긋난다면, 머릿속으로 짐작하지 말고 앞 모듈의 출력 번들을 먼저 펼쳐 보는 것이 가장 빠른 진단입니다. 내가 기대한 필드 이름과 실제 출력된 필드 이름이 다르거나, 값이 한 겹 더 깊은 곳(컬렉션 안)에 들어 있는 경우가 흔합니다.

목록이 끼면 달라진다 — Iterator와 Array Aggregator

값 하나를 하나로 옮길 때는 매핑이 직관적입니다. 문제는 앞 모듈이 여러 개짜리 목록(배열)을 내보낼 때입니다. 예를 들어 "메일에 첨부된 파일 목록", "스프레드시트에서 읽은 여러 행", "API가 돌려준 항목 배열"처럼요. 이때 배열을 통째로 다음 모듈에 꽂으면 원하는 대로 동작하지 않기 쉽습니다. 배열은 '여러 개'인데 뒷 모듈은 보통 '한 개씩'을 기대하기 때문입니다.

Iterator: 배열을 개별 번들로 쪼갠다

Iterator는 배열 하나를 받아서, 항목 개수만큼의 번들로 나눠 내보내는 모듈입니다. 항목이 5개인 배열을 넣으면 Iterator 뒤쪽 모듈은 5번 실행되고, 매번 항목 하나씩을 다룹니다. "목록의 각 항목마다 무언가를 하고 싶다"면 Iterator가 출발점입니다. 예를 들어 첨부파일 목록을 하나씩 클라우드에 저장하는 식이죠.

Array Aggregator: 흩어진 번들을 하나로 모은다

반대 방향도 있습니다. 여러 번 실행되며 흩어진 번들들을 다시 하나의 배열로 합치고 싶을 때 쓰는 것이 Array Aggregator입니다. 항목별로 처리한 결과를 한 번에 묶어 다음 단계로 넘기거나, 여러 조각을 모아 한 번의 요청으로 보내 호출 횟수를 줄일 때 유용합니다. Iterator로 쪼갠 뒤 필요한 처리를 하고 Array Aggregator로 다시 모으는 흐름은, 배열을 다루는 자동화의 가장 기본적인 골격입니다.

정리하면 Iterator는 '펼치기', Array Aggregator는 '모으기'입니다. 배열이 등장하는 순간 이 둘 중 무엇이 필요한지부터 생각하면, 매핑이 훨씬 명확해집니다.

실전 예시: 시트의 여러 행을 하나씩 처리하기

흐름을 예시로 그려보면 이해가 빨라집니다. 스프레드시트에서 "주문 목록"을 한꺼번에 읽어와, 각 주문마다 확인 메일을 보내고 싶다고 해봅시다. 시트를 읽는 모듈은 여러 행을 하나의 배열로 내보냅니다. 이걸 바로 메일 모듈에 연결하면 "어느 행의 주소로 보내야 하는지"가 모호해집니다. 여기서 배열을 Iterator에 넣어 한 행씩 펼치면, 뒤따르는 메일 모듈이 주문 건수만큼 반복 실행되며 각 행의 이메일과 이름을 정확히 집어 씁니다. 반대로 "모든 주문을 요약해 한 통의 리포트로" 보내고 싶다면, Iterator로 펼친 결과를 Array Aggregator로 다시 모아 하나의 표로 만든 뒤 한 번만 전송하면 됩니다. 같은 데이터라도 목적에 따라 펼칠지 모을지가 갈리는 셈입니다.

매핑이 깨질 때 점검하는 4가지

실전에서 값이 안 넘어가거나 실행이 실패할 때, 다음 순서로 점검하면 대부분 원인을 좁힐 수 있습니다.

• ① 데이터 타입이 맞는가 — 숫자를 기대하는 칸에 텍스트가 들어가면 오류가 나거나 계산이 어긋납니다. 날짜·숫자·텍스트는 서로 다른 타입으로 취급되므로, 필요하면 변환 함수를 거쳐 넣습니다.
• ② 빈 값·null이 섞여 있지 않은가 — 앞 모듈에서 값이 비어 나오면 그 자리에 아무것도 안 들어갑니다. 특정 실행에서만 실패한다면 그 실행의 입력이 비어 있었을 가능성이 큽니다.
• ③ 값이 한 겹 더 깊은 곳에 있지 않은가 — 배열이나 컬렉션 안쪽 값이라면 바로 꺼낼 수 없고, Iterator로 펼치거나 배열 인덱스로 접근해야 합니다.
• ④ 데이터 구조가 옛날 그대로가 아닌가 — 연결한 서비스의 출력 형식이 바뀌면, 예전에 잡아둔 필드가 '없는 필드'로 표시될 수 있습니다. 모듈을 다시 실행해 구조를 새로 잡아주면 해결되는 경우가 많습니다.

이 네 가지는 서로 얽혀 있어서, 하나씩 배제하듯 확인하는 습관을 들이면 "왜 안 되지?"로 낭비하는 시간이 크게 줄어듭니다. 매핑과 데이터 구조의 자세한 동작은 Make 공식 도움말에서 확인할 수 있습니다.

결론

Make 자동화가 막히는 대부분의 순간은 앱을 잘못 연결해서가 아니라, 앞 모듈이 내보낸 데이터의 '모양'을 이해하지 못해서입니다. 모듈은 번들을 내보내고, 매핑은 그 번들에서 값을 골라 다음으로 넘기는 일이며, 배열이 끼면 Iterator와 Array Aggregator로 펼치고 모으면 됩니다. 원리를 한 번 잡아두면 새로운 앱을 연결할 때도 같은 방식으로 접근할 수 있습니다.

지금 만들다 멈춘 시나리오가 있다면, 오늘은 딱 하나만 해보세요. 막히는 모듈 바로 앞 모듈을 실행해, 출력 번들을 눈으로 펼쳐 보는 것부터 시작하면 됩니다. 대부분의 답은 이미 거기에 나와 있습니다.