목차
시작 전 가정과 기본 구조
이 글은 Make 계정을 만들고 자동화할 서비스의 로그인 정보나 API 연결 권한을 준비했다고 가정합니다. Make는 여러 서비스를 하나의 시나리오로 연결하며, 시나리오 안의 모듈은 트리거, 데이터 변환, 전송처럼 하나의 역할을 수행하는 작업 단위입니다.
예를 들어 새 폼 응답을 받으면 스프레드시트에 저장하고, 담당자에게 알림을 보내는 흐름을 만들 수 있습니다. 이 흐름 전체가 시나리오이며, 새 폼 응답 감지·스프레드시트 저장·알림 전송은 각각 모듈로 구성합니다. 시작점과 최종 결과를 먼저 정한 뒤 그 사이의 작업까지 같은 기준으로 나누면 설계가 쉬워집니다.
Make는 Zapier·n8n과 함께 대표적인 자동화 도구로 꼽힙니다. Make·Zapier는 클라우드형이라 서버 없이 바로 시작할 수 있지만 실행 횟수(오퍼레이션) 기준으로 과금되고, n8n은 셀프호스팅이 가능해 서버 운영 부담은 있지만 실행량에 따른 추가 과금이 없습니다 — Briefold의 NAS 자동화 구축 사례는 n8n을 셀프호스팅으로 운영하는 쪽을 선택한 경우입니다. 반복 실행량이 많고 서버를 이미 운영 중이라면 n8n, 빠르게 검증만 하고 싶다면 Make·Zapier 쪽이 초기 진입 부담이 적습니다.
시나리오와 모듈 만들기
Make의 시나리오는 자동화 전체 흐름이며, 모듈은 그 흐름을 이루는 개별 작업입니다. 따라서 새 행 감지 같은 트리거, 데이터 변환, 이메일 전송처럼 시작점·중간 작업·최종 결과에 해당하는 모듈을 연결해 업무 과정을 구성합니다.
처음에는 모듈을 많이 추가하기보다 “입력 확인 → 필요한 값 추출 → 결과 전송”처럼 3단계 안팎으로 시작하는 편이 좋습니다. 각 모듈을 실행해 입력과 출력 데이터를 확인하면서 다음 모듈을 연결하면 오류 원인을 찾기 쉽습니다.
트리거와 스케줄 설정
트리거는 시나리오를 시작시키는 이벤트입니다. 새 이메일, 새 데이터, 웹훅 요청처럼 변화가 발생했을 때 실행할 수 있고, 일정한 간격으로 확인하는 방식도 선택할 수 있습니다.
스케줄은 실행 빈도와 실행 시간을 정하는 설정입니다. 실시간성이 중요하지 않은 보고서 생성은 간격 실행으로 충분하지만, 주문이나 문의 알림은 즉시 실행 방식이 적합합니다. 너무 짧은 간격은 작업량과 서비스 사용량을 늘릴 수 있으므로 실제 처리 주기에 맞춰야 합니다.
필드 매핑과 데이터 연결
필드 매핑은 앞 모듈의 값을 뒤 모듈의 입력 칸에 연결하는 과정입니다. 예를 들어 폼의 이름 필드를 이메일 본문의 수신자 이름에 매핑하고, 제출 시간을 기록 필드에 넣을 수 있습니다.
실행 결과에서 값이 비어 있다면 필드 이름만 보고 판단하지 말고 실제 출력 구조를 확인하세요. 테스트 데이터에 해당 값이 없거나, 여러 항목 중 배열(같은 형식의 데이터 묶음) 안에 값이 들어 있으면 잘못된 경로를 선택한 것일 수 있습니다.
필터와 라우터, 웹훅 트리거
필터는 조건에 맞는 데이터만 다음 단계로 통과시킵니다. 예를 들어 금액이 일정 기준 이상일 때만 알림을 보내도록 조건을 걸 수 있으며, 조건식의 필드와 비교값을 먼저 테스트해야 합니다.
라우터는 하나의 흐름을 여러 경로로 나눕니다. 문의 유형에 따라 담당자를 다르게 지정할 때 유용하지만, 경로마다 필터 조건이 겹치면 같은 데이터가 여러 곳에서 처리될 수 있습니다.
웹훅 트리거는 외부 서비스가 Make의 특정 주소로 데이터를 보내 실행하는 방식입니다. 주소를 공개하면 누구나 요청할 가능성이 있으므로 인증용 값이나 검증 조건을 함께 두는 편이 안전합니다. 요청은 들어왔지만 다음 모듈이 실행되지 않는다면 웹훅 수신 기록, 필터 통과 여부, 필드 경로를 차례로 확인하세요.
결론
Make 자동화는 데이터 흐름을 작게 설계하고 각 모듈의 실행 결과를 확인하는 방식으로 구성할 수 있습니다. 간단한 트리거부터 시작해 매핑, 필터, 라우터, 웹훅을 순서대로 확장해 보세요.