Make 예제를 여러 개 외우는 것보다 감지 → 검사 → 처리 → 저장 → 알림 → 복구 패턴을 이해하면 다른 업무에도 적용하기 쉽습니다. 아래 예시는 실제 고객 데이터가 아닌 가상 업무 흐름이며, 처음에는 외부 발송이나 공개 없이 내부 저장까지만 시험합니다.
모든 시나리오에 공통인 여섯 블록
| 블록 | 질문 | 실패 시 처리 |
|---|---|---|
| 감지 | 언제 시작하는가 | 중복 이벤트 식별 |
| 검사 | 필수값과 허용 형식이 맞는가 | 오류함으로 이동 |
| 처리 | 한 번에 어떤 변환을 하는가 | 원본 보존 |
| 저장 | 결과와 작업 ID를 어디에 남기는가 | 중복 저장 조회 |
| 알림 | 누가 무엇을 확인해야 하는가 | 민감정보 제외 |
| 복구 | 재시도와 수동 전환 기준은 무엇인가 | 실행 기록 확인 |
패턴 A: 이메일 첨부파일을 검수함에 저장
흐름: 새 이메일 감지 → 발신 도메인과 확장자 검사 → 지정 폴더 저장 → 파일명·메일 ID 기록 → 담당자 알림
실행 전에 최대 파일 크기, 허용 확장자와 중복 판정 기준을 정합니다. 같은 메일 ID가 기록돼 있으면 다시 저장하지 않습니다.
패턴 B: 구글 폼 응답을 담당자에게 배정
흐름: 새 응답 → 필수값 검사 → 문의 유형 분류 → 시트 저장 → 담당자 알림
AI 분류가 애매하면 자동 배정하지 않고 ‘사람 확인’ 상태로 보냅니다. 연락처 전체를 알림 채널에 복사하지 말고 접수 번호와 확인 링크만 전달하세요.
패턴 C: 시트 행에서 답변 초안 만들기
흐름: 상태가 ‘초안 요청’인 행 조회 → 개인정보 제거 여부 검사 → AI 초안 생성 → 결과 열 저장 → 검수 상태를 ‘대기’로 기록
답변을 고객에게 자동 발송하지 않습니다. 가격, 예약, 환불과 안전 관련 문의는 승인된 기준표와 담당자의 확인이 필요합니다.
패턴 D: WordPress 임시글 생성
흐름: 승인된 주제 조회 → 작업 ID 중복 검사 → 본문 초안 → WordPress draft 생성 → 글 ID 저장
공개 상태는 입력 데이터가 아니라 시나리오의 고정값으로 설정합니다. 필드 매핑과 승인 흐름은 ChatGPT·Make WordPress 임시글 가이드에서 확인할 수 있습니다.
패턴 C 실습 설계: 영업시간 문의 한 건을 검수함에 저장
가상 매장의 설계 예시이며 실제 Make 실행 기록이 아닙니다. 고객 발송 모듈 없이 입력 시트와 검수 시트만 사용합니다. 연결 화면의 모듈 이름·권한은 현재 계정에서 확인하세요.
| 입력 열 | 예시 값 | 검사 |
|---|---|---|
| 작업 ID | DEMO-INQ-001 | 빈 값·기처리 여부 확인 |
| 상태 | 초안 요청 | 이 값인 행만 처리 |
| 문의 | 토요일 몇 시에 여나요? | 개인정보 없는 연습 문장 |
| 승인 기준 | 토요일 10:00~18:00 / 임시휴무 미확인 | 변경 여부는 담당자 확인 |
흐름은 시트 행 조회 → 작업 ID 및 필수값 검사 → 이미 처리된 ID 조회 → AI 초안 생성 → 검수 시트 저장 → 원본 상태 갱신입니다. 원본 상태를 바꾸기 전에 검수 시트에 같은 작업 ID가 저장됐는지 확인합니다.
AI 요청문: “승인 기준만 사용해 두 문장 이내 답변 초안을 작성하라. 문의에 없는 예약·가격을 추가하지 말라. 임시휴무 여부는 확인되지 않았음을 표시하라. 출력은 답변 초안과 확인할 항목으로 나누고 고객에게 발송하지 말라.”
기대 출력의 한 예: “안내 기준상 토요일 영업시간은 10:00~18:00입니다. 임시휴무 여부는 담당자 확인이 필요합니다.” 확인할 항목은 ‘해당 토요일의 임시휴무’입니다. 같은 문장 출력 여부보다 기준 밖의 사실을 만들지 않았는지 검사합니다.
| 시험 입력 | 기대 결과 | 저장 상태 |
|---|---|---|
| 정상 1건 | 답변 초안과 확인 항목 저장 | 검수 대기 |
| 같은 ID 재입력 | 기존 결과 조회, 새 행 생성 안 함 | 기처리 |
| 승인 기준 빈 값 | AI 호출 전 중단 | 자료 보완 |
| 기준에 없는 환불 질문 | 정책을 만들지 않음 | 사람 확인 |
| AI 호출 실패 | 원문 보존, 제한 재시도 또는 수동 처리 | 오류 |
검수 시트에는 작업 ID, 답변 초안, 확인할 항목, 처리 상태, 처리 시각, 오류 사유를 기록합니다. 정상 입력 1건을 두 번 실행했을 때 결과 행이 하나인지 확인하세요. 동시 실행에서는 단순 사전 조회만으로 중복을 보장할 수 없으므로, 한 건씩 순차 처리하거나 원자적 ID 예약 구조를 별도로 검증해야 합니다. 초안 저장 뒤 상태 갱신이 실패해도 저장된 ID를 먼저 조회해야 합니다.
통과 기준은 ‘실행 성공’ 표시가 아니라 새 결과 한 행, 외부 발송 0건, 근거 없는 정책 0건, 실패 건 재조회 가능입니다. 실제 검수 기록에는 실행일·입력 ID·기대 결과·관찰 결과를 함께 남기세요.
크레딧을 예상하는 방법
한 업무가 몇 개 모듈을 지나가는지와 처리되는 번들 수를 따로 기록하세요. AI 모듈과 일부 기능의 과금 방식은 연결·모델·처리량에 따라 달라질 수 있으므로 고정된 ‘한 실행=한 크레딧’으로 단정하지 말고 현재 Make 사용량 화면과 공식 요금 문서를 확인합니다.
오류를 세 종류로 나누기
| 오류 | 예 | 대응 |
|---|---|---|
| 입력 오류 | 필수값 없음, 날짜 형식 불일치 | 재시도하지 않고 원본 수정 |
| 연결 오류 | 401·403, 서비스 일시 중단 | 인증·상태 확인 후 제한 재시도 |
| 중복 오류 | 같은 행·파일·글 재처리 | 작업 ID로 기존 결과 조회 |
Make는 Retry·Resume·Skip·Rollback 등 오류 처리기를 제공합니다. 각 처리기가 데이터를 버리는지, 대체값으로 계속하는지, 전체를 중지하는지 확인한 뒤 사용하세요. Make 오류 처리기 공식 안내
공개 전이 아닌 ‘운영 전’ 체크
- 원본 데이터가 별도로 보존되는가
- 중복 실행을 판별할 작업 ID가 있는가
- 오류 실행을 사람이 다시 찾을 수 있는가
- 개인정보가 로그와 알림에 남지 않는가
- 외부 발송·공개 전에 승인 단계가 있는가