Make에서 시나리오를 실행했는데 중간 모듈이 빨갛게 표시되거나, 예약 실행이 멈추거나, 크레딧이 예상보다 빨리 줄어든다면 한 번에 모든 설정을 바꾸기보다 실행 기록 → 오류 위치 → 데이터·연결 → 크레딧·재시도 순서로 원인을 좁히는 편이 빠릅니다. 이 글은 초보자가 자주 만나는 상황을 기준으로 점검 순서를 정리한 가이드입니다.
가장 먼저: 시나리오 화면이 아니라 실행 기록을 봅니다
오류가 났을 때는 먼저 해당 시나리오의 가장 최근 실행 기록을 열고, 빨간 경고가 표시된 모듈을 확인하세요. Make의 오류는 이전 모듈에서 넘어온 데이터가 예상과 다르거나, 외부 앱의 인증·API·제한 문제 때문에 생기는 경우가 많습니다.
| 실행 기록에서 보이는 모습 | 우선 확인할 것 |
|---|---|
| 첫 모듈부터 오류 | 연결 계정, 트리거 설정, 권한, 입력 데이터 |
| 특정 모듈에서만 오류 | 그 모듈에 매핑한 값과 오류 메시지 |
| 필터 뒤로 데이터가 가지 않음 | 필터 조건이 실제 값과 맞는지 |
| 실행은 됐지만 원하는 결과가 없음 | 검색 범위, 모듈 출력, 반복 처리된 묶음 수 |
중요한 점은 필터에서 데이터가 걸러진 것과 모듈이 오류를 낸 것은 다르다는 것입니다. 필터 조건이 거짓이면 다음 모듈은 실행되지 않을 수 있지만, 이것만으로는 오류가 아닙니다.
1. 오류와 경고를 구분
오류는 해당 실행을 중단시키는 문제이고, 경고는 오류 처리 설정 등에 따라 시나리오가 계속 실행될 수 있는 상태입니다. 오류가 반복되면 Make가 계속 실패하는 실행을 막기 위해 예약 실행을 비활성화할 수 있으므로, 단순히 스케줄 스위치만 다시 켜기 전에 원인을 먼저 확인해야 합니다.
가장 먼저 오류 메시지의 핵심 단어를 기록하세요. 예를 들어 connection, authentication, rate limit, data, operation limit처럼 유형을 알 수 있는 단어가 있으면 다음 조치가 달라집니다.
2. 데이터 매핑 오류: 값을 ‘보는 것’부터 시작
Make의 모듈은 이전 단계에서 받은 데이터를 필드에 매핑해 사용합니다. 그래서 화면에 필드 이름이 보인다고 해서 그 값이 모든 실행에 항상 들어오는 것은 아닙니다. 실행 기록에서 실패한 묶음(Bundle)을 열고 실제 값이 있는지 확인하세요.
- 필수 필드가 비어 있지 않은지 확인합니다.
- 텍스트·숫자·날짜 형식이 다음 모듈의 기대 형식과 맞는지 봅니다.
- 필터가 비교하는 값의 공백, 대소문자, 상태명을 다시 확인합니다.
- 처음에는 검색 결과 수와 반복 횟수를 작게 제한해 한 건으로 검증합니다.
특히 Google Sheets나 폼 데이터를 쓸 때는 열 제목 변경, 빈 행, 날짜 형식 차이로 매핑이 달라질 수 있습니다. 오류를 고친 뒤에는 실제 고객 데이터가 아니라 테스트용 행 한 건으로 다시 실행하는 편이 안전합니다.
3. 연결·권한·외부 API 오류
connection, unauthorized, forbidden처럼 인증과 관련된 오류가 보이면 시나리오 구조를 바꾸기 전에 연결 상태를 확인합니다. 비밀번호 변경, 권한 철회, 팀 이동, API 키 재발급, 외부 서비스의 장애도 원인이 될 수 있습니다.
- Make의 연결(Connection)이 현재 계정으로 정상 연결돼 있는지 확인합니다.
- 연결 계정이 대상 스프레드시트·드라이브·프로젝트에 접근할 권한이 있는지 확인합니다.
- 외부 서비스에서 API 키나 OAuth 권한을 바꿨다면 Make에서도 다시 연결합니다.
- 오류가 일시적인 연결 문제나 API 제한인지, 잘못된 설정인지 구분합니다.
429 또는 rate limit 오류는 짧은 시간에 너무 많은 요청을 보냈다는 뜻일 수 있습니다. 이 경우 모듈을 계속 수동 실행하기보다, 외부 서비스의 제한과 실행 빈도·처리량을 먼저 줄이는 방향을 검토하세요.
4. 크레딧이 빨리 줄어드는 이유
현재 Make는 사용량을 Credits로 계산하며, 사용량은 작업에서 발생한 operation·토큰 등 요소에 따라 달라질 수 있습니다. ‘시나리오 하나를 한 번 켰다’는 사실만으로는 실제 사용량을 예측하기 어렵습니다. 한 번 실행할 때 몇 개의 묶음을 처리했고, 각 묶음이 몇 개의 모듈을 통과했는지를 같이 봐야 합니다.
크레딧 소모가 예상보다 크다면 아래를 확인하세요.
- 검색 모듈이 필요 이상으로 많은 행·이메일·파일을 가져오고 있지 않은지
- 반복 처리되는 묶음 수가 예상보다 많은지
- 오류가 난 시나리오를 여러 번 수동 재실행하고 있지 않은지
- AI 모듈처럼 별도 사용량이 생기는 단계를 포함하는지
해결 방법은 무조건 모듈 수를 줄이는 것이 아니라, 한 번에 가져오는 데이터 양과 실행 빈도를 업무에 맞게 제한하는 것입니다. 실행 기록에서 실제 묶음 수를 본 뒤 조건·검색 범위를 조정하세요.
5. Incomplete Execution은 ‘나중에 복구할 수 있는 실패 기록’입니다
외부 API가 잠시 느리거나 연결이 끊긴 것처럼 일시적인 오류라면, 실패 데이터를 버리지 않고 다시 처리하는 편이 필요할 수 있습니다. Make는 Scenario settings에서 Incomplete Execution 저장을 켜면 실패한 실행을 별도 탭에 보관하고, 이후 재시도하거나 수동으로 해결할 수 있습니다. 이 기능은 기본적으로 꺼져 있으므로 중요한 시나리오에서는 미리 정책을 정해 두는 것이 좋습니다.
다만 무조건 재시도하면 중복 발송·중복 등록이 생길 수 있습니다. 이메일 발송이나 결제, CRM 생성처럼 외부에 실제 변경을 만드는 시나리오는 재시도 전에 “이미 처리됐는가?”를 확인할 수 있는 기준을 설계해야 합니다. 저장 공간에도 한도가 있으므로 Incomplete Execution을 주기적으로 점검합니다.
안전한 점검 순서
- 최근 실행 기록에서 오류 모듈과 메시지를 확인합니다.
- 필터 통과 여부와 실제 입력 데이터 한 건을 확인합니다.
- 연결 계정·권한·API 상태를 확인합니다.
- 크레딧 사용량과 처리된 묶음 수를 확인합니다.
- 일시적 오류라면 Incomplete Execution 저장·재시도 정책을 검토합니다.
- 수정 후에는 테스트 데이터 한 건으로 Run once를 실행합니다.
- 정상 동작을 확인한 뒤에만 예약 실행을 켭니다.
정리
Make 오류는 ‘모듈 하나가 빨갛다’는 현상만 보고 고치기보다, 실행 기록 속 데이터와 메시지를 기준으로 접근해야 합니다. 작은 테스트 데이터부터 확인하고, 연결·데이터·크레딧·재시도 설정을 나누어 점검하면 불필요한 재실행과 크레딧 낭비를 줄일 수 있습니다.
참고: Make 오류·경고 공식 안내, Make Credits 안내, Make Incomplete Executions 안내, Make Scenario settings