
최종 확인일: 2026년 8월 22일
Make를 처음 사용할 때는 완전 자동 발행보다 실패해도 피해가 적은 내부 업무부터 시작하는 것이 안전합니다. 이 글은 이메일, 구글 시트, 알림과 블로그 초안을 연결하는 7가지 예제를 트리거·처리·결과·검수 순서로 설명합니다.
비용 주의: Make는 시나리오에서 실행되는 모듈 동작 등에 크레딧을 사용합니다. 대부분의 일반 동작은 1크레딧이지만 일부 AI 기능은 더 많은 크레딧을 사용할 수 있습니다. OpenAI 같은 외부 API 비용도 별도로 발생할 수 있으므로 활성화 전에 예상 실행량을 계산하세요.
모든 예제에 공통으로 적용할 5가지
- 실제 고객자료가 아닌 테스트 데이터 3~5개로 시작합니다.
- 원본 데이터와 자동화 결과를 서로 다른 위치에 보관합니다.
- 중복 처리 방지를 위해 메시지 ID나 행 ID를 기록합니다.
- 실패한 실행의 입력·출력과 오류 메시지를 확인합니다.
- 이메일 발송·글 공개처럼 외부에 영향을 주는 단계는 사람 승인 뒤 실행합니다.
예제 1. 이메일 첨부파일을 드라이브에 정리
흐름: Gmail 새 메일 감지 → 조건 확인 → Google Drive 폴더 저장 → Google Sheets 기록
- 청구서, 신청서처럼 정해진 발신자와 제목만 처리합니다.
- 파일명에는 날짜와 원본 메시지 ID를 포함해 중복 저장을 막습니다.
- 실행 결과에는 저장 경로, 파일명, 처리 시각과 상태를 기록합니다.
오류 복구: 지원하지 않는 확장자나 빈 파일은 별도 오류 폴더에 기록하고 담당자에게 알립니다. 첨부파일에 개인정보가 있다면 공유 폴더 권한을 최소화하세요.
예제 2. 구글 폼 신청을 시트와 알림으로 연결
흐름: Google Forms 응답 → 필수값 확인 → Sheets 저장 → 담당자 알림
- 이메일 형식, 신청 날짜와 필수 동의 여부를 먼저 확인합니다.
- 알림에는 전체 개인정보 대신 신청 번호와 확인 링크만 넣습니다.
- 승인·보류·반려 상태는 담당자가 시트에서 직접 선택합니다.
오류 복구: 필수 항목이 없으면 자동 승인하지 말고 보류 상태로 저장합니다.
예제 3. 시트 상태 변경으로 이메일 초안 만들기
흐름: 행 상태가 답변 준비로 변경 → 고객 정보 확인 → Gmail 초안 생성 → 담당자 검수
처음부터 이메일을 자동 발송하지 않고 초안으로 저장합니다. 담당자가 수신자, 가격, 일정과 첨부파일을 확인한 뒤 직접 보내면 잘못된 발송 위험을 줄일 수 있습니다.
중복 방지: 발송 초안 ID와 생성 시각을 시트에 기록하고 이미 ID가 있는 행은 다시 처리하지 않습니다.
예제 4. 블로그 주제를 글 초안으로 정리
흐름: 주제 승인 행 감지 → 참고자료 URL 확인 → AI 초안 생성 → Google Docs 또는 워드프레스 임시글 저장
- AI가 출처에 없는 숫자·경험·제품 평가를 만들지 않도록 지시합니다.
- 가격, 정책과 기능은 공식 자료를 사람이 다시 확인합니다.
- 결과는 공개 글이 아니라 임시글로 저장합니다.
- 제목, 본문, 이미지 저작권, 링크와 개인정보를 검수한 뒤 사람이 발행합니다.
주의: 검색 유입만을 목적으로 비슷한 글을 대량 생성하면 독자에게 고유한 가치를 제공하기 어렵습니다. 자동화는 자료 정리와 초안 보조에 사용하고 최종 판단과 발행은 사람이 담당하세요.
예제 5. RSS 새 글을 내부 읽기 목록에 저장
흐름: RSS 새 항목 → 제목·URL·발행일 추출 → Sheets 또는 Notion 저장 → 주간 요약 알림
외부 글 전체를 복사하거나 자동 재게시하지 말고 제목, 링크와 내부 메모만 저장합니다. 원문을 인용할 때는 필요한 범위만 사용하고 출처를 표시합니다.
오류 복구: URL을 고유값으로 사용해 같은 글이 여러 번 들어오지 않도록 필터링합니다.
예제 6. 고객 문의를 분류해 검수함에 저장
흐름: 문의 접수 → 개인정보 최소화 → 문의 유형 분류 → 답변 초안 → 사람 검수
- 영업시간·위치 같은 공개 정보는 승인된 기준표를 사용합니다.
- 환불, 계약, 불만, 결제와 안전 문제는 직원에게 바로 넘깁니다.
- AI가 기준표에서 답을 찾지 못하면 내용을 만들지 않고 확인 필요로 표시합니다.
문의 원문, 분류 결과, 검수자, 수정 내용과 처리 시각을 남기면 잘못된 분류를 개선하기 쉽습니다.
예제 7. 하루 업무 결과를 요약해 담당자에게 알림
흐름: 매일 지정 시간 → 성공·실패 실행 집계 → 요약 생성 → Slack 또는 이메일 알림
성공 건수만 알리지 말고 실패 건수, 재시도 대기, 크레딧 사용량과 사람이 확인할 항목을 함께 보냅니다. 자동화가 조용히 멈추는 상황을 막기 위해 실패가 1건이라도 있으면 경고를 표시하세요.
크레딧 사용량 계산 예시
한 번 실행할 때 Gmail 확인, 파일 저장, 시트 기록과 알림의 네 동작이 실제로 수행된다면 대략 네 개 이상의 일반 모듈 크레딧을 사용할 수 있습니다. 하지만 검색 결과 개수, 반복 처리, 번들 수와 AI 모듈에 따라 실제 사용량은 달라집니다.
- 시나리오를 테스트 데이터 5건으로 실행합니다.
- Make 실행 기록에서 실제 사용 크레딧을 확인합니다.
- 건당 사용량에 월 예상 건수를 곱합니다.
- 재시도와 오류 여유분을 추가합니다.
- 외부 API와 저장공간 비용을 별도로 더합니다.
오류 처리 구조
- 일시적 API 오류: 대기 후 제한된 횟수만 재시도합니다.
- 필수 데이터 누락: 실행을 멈추고 보류 목록에 저장합니다.
- 권한 만료: 연결 계정 담당자에게 알리고 재인증 전까지 외부 전송을 중단합니다.
- 중복 실행: 고유 ID를 대조해 이미 처리한 항목을 건너뜁니다.
- 크레딧 부족: 자동 추가 구매 설정과 예상 비용을 확인하고 중요도가 낮은 시나리오부터 중지합니다.
운영 체크리스트
- 테스트용 계정과 샘플 데이터로 검증했는가?
- 원본과 결과를 분리해 보관하는가?
- 중복 실행을 막는 고유 ID가 있는가?
- 재시도 횟수에 상한이 있는가?
- 개인정보와 계정 권한을 최소화했는가?
- 이메일 발송과 글 공개 전에 사람 승인이 있는가?
- 월 크레딧과 외부 API 비용을 기록하는가?
- 담당자가 바뀌어도 연결 계정을 복구할 수 있는가?
공식 자료
업데이트 기록: 2026년 8월 22일 반복적인 수익화 문구를 제거하고, 7개 예제를 트리거·처리·검수·오류 복구 구조로 다시 작성했습니다. 자동 발행은 임시글 저장과 사람 승인 방식으로 변경했습니다.