Make(구 Integromat)로 자동화 시나리오를 만들다 보면 반드시 마주치는 것이 바로 에러입니다. 처음에는 당황스럽고, 어디서부터 손을 대야 할지 막막하게 느껴집니다. 하지만 Make의 에러 시스템을 제대로 이해하면, 오히려 에러는 시나리오를 더 견고하게 만드는 기회가 됩니다. 이 글에서는 Make에서 발생하는 모든 유형의 에러와 그 해결법을 체계적으로 정리합니다.
Make 에러의 기본 구조 이해하기
Make에서 에러가 발생하면 시나리오 실행이 중단됩니다. 이때 Make는 에러에 대한 상세한 정보를 제공하는데, 이 정보를 제대로 읽는 것이 해결의 첫걸음입니다. 에러 메시지는 크게 세 부분으로 구성됩니다: 에러 유형(Type), 에러 메시지(Message), 그리고 발생 위치(Module)입니다.
에러 유형은 ConnectionError, DataError, RateLimitError, RuntimeError 등으로 분류됩니다. 각 유형은 문제의 원인을 대략적으로 알려줍니다. ConnectionError는 외부 서비스와의 연결 문제, DataError는 데이터 형식이나 값의 문제, RateLimitError는 API 호출 제한 초과, RuntimeError는 시나리오 로직의 문제를 의미합니다.
에러 메시지는 구체적인 원인을 설명합니다. 예를 들어 “The requested resource was not found”라는 메시지는 요청한 데이터가 존재하지 않는다는 의미입니다. 이 메시지를 정확히 읽으면 대부분의 문제를 파악할 수 있습니다.
발생 위치는 어느 모듈에서 에러가 발생했는지 보여줍니다. Make의 시나리오 화면에서 에러가 발생한 모듈은 빨간색으로 표시되며, 클릭하면 상세 정보를 확인할 수 있습니다.
ConnectionError: 연결 오류 완벽 해결
ConnectionError는 가장 흔하게 발생하는 에러 유형입니다. 외부 서비스(Google, Slack, Notion 등)와의 연결이 끊어졌거나, 인증 정보가 만료되었을 때 발생합니다.
인증 토큰 만료 문제
OAuth 방식으로 연결된 서비스는 일정 시간이 지나면 토큰이 만료됩니다. Google의 경우 액세스 토큰은 1시간, 리프레시 토큰은 6개월 정도 유효합니다. 토큰이 만료되면 “Invalid credentials” 또는 “Token has been expired or revoked” 에러가 발생합니다.
해결 방법은 간단합니다. Make의 Connections 메뉴로 이동해서 해당 연결을 찾고, “Reauthorize” 버튼을 클릭합니다. 그러면 해당 서비스의 로그인 화면이 나타나고, 다시 인증하면 새로운 토큰이 발급됩니다. 주의할 점은 반드시 원래 연결할 때 사용했던 계정으로 로그인해야 한다는 것입니다.
API 키 문제
API 키 방식의 연결에서는 키가 비활성화되거나, 권한이 변경되었을 때 에러가 발생합니다. “Invalid API key” 또는 “Unauthorized” 메시지가 나타납니다. 이 경우 해당 서비스의 관리자 페이지에서 API 키 상태를 확인하고, 필요하면 새 키를 발급받아 Make 연결 설정에서 업데이트해야 합니다.
서비스 일시 장애
외부 서비스 자체에 장애가 발생하면 Make에서도 연결 에러가 발생합니다. “Service temporarily unavailable” 또는 “Connection timed out” 메시지가 나타납니다. 이런 경우 해당 서비스의 상태 페이지(예: status.google.com, status.notion.so)를 확인하고, 서비스가 복구될 때까지 기다려야 합니다.
일시적인 장애에 대비하려면 Error Handler를 설정하는 것이 좋습니다. Break 모듈을 사용해서 에러 발생 시 일정 시간 후 재시도하도록 설정할 수 있습니다. 예를 들어 첫 번째 실패 후 1분 대기, 두 번째 실패 후 5분 대기, 세 번째 실패 후 30분 대기하는 식으로 점진적 재시도 로직을 구성할 수 있습니다.
DataError: 데이터 오류 해결법
DataError는 모듈에 전달되는 데이터의 형식이나 값이 올바르지 않을 때 발생합니다. 자동화에서 가장 까다로운 에러 유형 중 하나입니다.
필수 필드 누락
“Required field is missing” 에러는 모듈이 필수로 요구하는 필드에 값이 없을 때 발생합니다. 예를 들어 이메일 발송 모듈에서 수신자 주소가 비어있으면 이 에러가 발생합니다.
해결 방법은 데이터 흐름을 추적하는 것입니다. 해당 필드에 매핑된 값이 어디서 오는지 확인하고, 소스 데이터에 값이 있는지 검증합니다. 값이 없을 수 있는 상황이라면, Set Variable 모듈이나 IF 조건문을 사용해서 기본값을 설정하거나, 값이 없을 때 해당 작업을 건너뛰도록 분기 처리합니다.
데이터 타입 불일치
“Expected type X but got type Y” 에러는 모듈이 기대하는 데이터 타입과 실제 전달된 타입이 다를 때 발생합니다. 가장 흔한 케이스는 숫자를 기대하는 필드에 문자열이 전달되는 경우입니다.
Make에서는 데이터 타입 변환 함수를 제공합니다. parseNumber() 함수는 문자열을 숫자로, toString() 함수는 숫자를 문자열로 변환합니다. formatDate() 함수는 날짜 형식을 변환할 때 사용합니다. 예를 들어 “123”이라는 문자열을 숫자로 변환하려면 {{parseNumber(“123”)}}처럼 사용합니다.
날짜 형식 오류
날짜 관련 에러는 특히 자주 발생합니다. 각 서비스마다 요구하는 날짜 형식이 다르기 때문입니다. Google Calendar는 ISO 8601 형식(2024-01-15T10:00:00Z)을 요구하고, 일부 서비스는 Unix 타임스탬프를 요구합니다.
Make의 formatDate() 함수를 활용하면 원하는 형식으로 변환할 수 있습니다. 예를 들어 {{formatDate(now; “YYYY-MM-DD”)}}는 “2024-01-15” 형식의 날짜를, {{formatDate(now; “X”)}}는 Unix 타임스탬프를 반환합니다. parseDate() 함수는 반대로 문자열을 날짜 객체로 변환합니다.
배열 처리 오류
단일 값을 기대하는 필드에 배열이 전달되거나, 배열을 기대하는 필드에 단일 값이 전달되면 에러가 발생합니다. “Expected array but got object” 또는 “Cannot iterate over non-array value” 같은 메시지가 나타납니다.
배열을 단일 값으로 변환하려면 first() 함수로 첫 번째 요소를, last() 함수로 마지막 요소를 추출할 수 있습니다. 또는 get() 함수로 특정 인덱스의 요소를 가져올 수 있습니다. 반대로 단일 값을 배열로 만들려면 [{{value}}] 형태로 감싸면 됩니다.
RateLimitError: API 호출 제한 극복하기
모든 외부 서비스는 API 호출 횟수를 제한합니다. 이 제한을 초과하면 RateLimitError가 발생하고, “Too many requests” 또는 “Rate limit exceeded” 메시지가 나타납니다.
주요 서비스별 API 제한
Google APIs는 일반적으로 분당 60회, 일당 10,000회 정도의 제한이 있습니다. Gmail API는 일당 발송 제한이 500통(무료 계정) 또는 2,000통(Workspace)입니다. Google Sheets API는 분당 읽기 60회, 쓰기 60회로 제한됩니다.
Slack API는 Tier별로 다른 제한이 적용됩니다. Tier 1 메서드는 분당 1회, Tier 2는 분당 20회, Tier 3는 분당 50회, Tier 4는 분당 100회입니다. 메시지 발송(chat.postMessage)은 Tier 3에 해당해서 분당 50회까지 가능합니다.
Notion API는 초당 3회, 분당 90회로 제한됩니다. 대량의 데이터를 처리할 때는 이 제한을 고려해서 시나리오를 설계해야 합니다.
Rate Limit 회피 전략
첫 번째 전략은 Sleep 모듈을 활용한 호출 간격 조절입니다. 각 API 호출 사이에 Sleep 모듈을 넣어 일정 시간 대기하게 하면 제한에 걸리지 않습니다. 예를 들어 Google Sheets에서 분당 60회 제한이 있다면, 각 호출 사이에 1초씩 대기하면 안전합니다.
두 번째 전략은 배치 처리입니다. 100개의 행을 하나씩 추가하면 100번의 API 호출이 필요하지만, Google Sheets의 “Add Multiple Rows” 모듈을 사용하면 1번의 호출로 처리할 수 있습니다. 가능하면 항상 배치 처리 모듈을 활용하세요.
세 번째 전략은 Error Handler와 Retry 설정입니다. Rate Limit 에러가 발생하면 일정 시간 후 자동으로 재시도하도록 설정합니다. Make의 Break 모듈을 사용하면 에러 발생 시 지정된 시간만큼 대기 후 재시도합니다. 보통 60초 대기 후 재시도하면 대부분의 Rate Limit이 해제됩니다.
네 번째 전략은 시나리오 실행 스케줄 분산입니다. 대량 데이터를 처리하는 시나리오를 여러 개의 작은 시나리오로 나누고, 실행 시간을 분산시킵니다. 예를 들어 1,000건의 데이터를 한 번에 처리하는 대신, 200건씩 5번에 나눠서 각각 다른 시간에 실행하면 Rate Limit을 피할 수 있습니다.
RuntimeError: 실행 오류 디버깅
RuntimeError는 시나리오 로직 자체의 문제로 발생합니다. 무한 루프, 메모리 초과, 실행 시간 초과 등이 해당됩니다.
무한 루프 방지
시나리오가 무한 루프에 빠지면 “Cycle limit exceeded” 에러가 발생합니다. Make는 기본적으로 하나의 시나리오 실행에서 최대 10,000번의 반복(cycle)만 허용합니다.
무한 루프의 가장 흔한 원인은 Webhook 트리거와 해당 서비스 업데이트의 조합입니다. 예를 들어 Google Sheets의 행이 업데이트될 때 트리거되는 시나리오에서 같은 시트의 행을 업데이트하면, 그 업데이트가 다시 트리거를 발생시켜 무한 루프가 됩니다.
이를 방지하려면 업데이트 조건을 명확히 해야 합니다. 특정 컬럼 값이 변경되었을 때만 실행하도록 Filter를 추가하거나, 처리 완료를 표시하는 플래그 컬럼을 만들어서 이미 처리된 행은 건너뛰도록 합니다.
실행 시간 초과
Make의 시나리오 실행 시간은 플랜에 따라 다릅니다. Free 플랜은 5분, Pro 플랜은 40분, Teams 플랜은 2시간까지 실행할 수 있습니다. 이 시간을 초과하면 “Operation timeout” 에러가 발생합니다.
대량 데이터를 처리할 때는 실행 시간을 고려해서 설계해야 합니다. 한 번에 모든 데이터를 처리하는 대신, 배치 단위로 나누어 여러 번 실행하는 것이 안전합니다. Data Store를 활용해서 마지막으로 처리한 위치를 저장하고, 다음 실행 때 그 지점부터 이어서 처리하는 방식이 효과적입니다.
메모리 초과
시나리오에서 처리하는 데이터가 너무 크면 “Memory limit exceeded” 에러가 발생합니다. 특히 대용량 파일을 다루거나, 수만 개의 레코드를 한 번에 처리할 때 발생합니다.
해결 방법은 데이터를 청크(chunk) 단위로 나누어 처리하는 것입니다. 예를 들어 10,000행의 데이터를 처리해야 한다면, 1,000행씩 10번에 나누어 처리합니다. Iterator 모듈과 Aggregator 모듈을 활용하면 데이터를 분할하고 다시 합칠 수 있습니다.
Error Handler 완벽 설정 가이드
Make의 강력한 기능 중 하나가 Error Handler입니다. 에러가 발생했을 때 시나리오가 완전히 중단되는 대신, 지정된 로직을 실행하도록 할 수 있습니다.
Error Handler 추가하기
모듈에 Error Handler를 추가하려면 해당 모듈을 우클릭하고 “Add Error Handler”를 선택합니다. 그러면 에러 발생 시 실행될 경로가 추가됩니다. 이 경로에 원하는 모듈들을 배치할 수 있습니다.
Error Handler 유형
Ignore: 에러를 무시하고 다음 모듈로 진행합니다. 데이터가 없어도 괜찮은 경우에 사용합니다. 예를 들어 사용자 프로필 이미지를 가져오는데 이미지가 없는 사용자도 있다면, 이 에러는 무시해도 됩니다.
Resume: 에러가 발생한 모듈의 출력을 대체값으로 지정하고 계속 진행합니다. 예를 들어 환율 API 호출이 실패하면 기본 환율값을 사용하도록 설정할 수 있습니다.
Break: 현재 실행을 중단하고, 나중에 재시도합니다. 일시적인 서비스 장애나 Rate Limit에 적합합니다. 재시도 간격과 최대 재시도 횟수를 설정할 수 있습니다.
Rollback: 해당 실행에서 이전에 수행된 모든 작업을 롤백합니다. 트랜잭션 처리가 필요한 경우에 사용합니다. 단, 모든 서비스가 롤백을 지원하지는 않습니다.
Commit: 에러가 발생해도 이전까지의 작업은 유지하고, 해당 실행만 중단합니다. 부분 성공을 허용하는 경우에 사용합니다.
조건부 Error Handler
Error Handler 경로에 Router를 추가하면 에러 유형에 따라 다른 처리를 할 수 있습니다. 예를 들어 Rate Limit 에러면 1분 대기 후 재시도하고, 인증 에러면 관리자에게 알림을 보내고, 데이터 에러면 해당 데이터를 스킵하는 식으로 분기할 수 있습니다.
에러 유형은 {{error.type}} 변수로, 에러 메시지는 {{error.message}} 변수로 접근할 수 있습니다. Filter에서 이 변수들을 사용해서 조건을 설정합니다.
디버깅 실전 테크닉
Execution History 활용
Make의 Execution History는 가장 강력한 디버깅 도구입니다. 각 실행의 상세 로그를 확인할 수 있고, 모든 모듈의 입력값과 출력값을 볼 수 있습니다. 에러가 발생하면 먼저 Execution History에서 해당 실행을 찾아 어느 시점에서 문제가 발생했는지 파악합니다.
각 모듈의 입력과 출력을 순차적으로 확인하면서 예상과 다른 값이 있는지 찾습니다. 특히 null 값이나 빈 배열, 예상과 다른 데이터 타입이 문제의 원인인 경우가 많습니다.
Watch Module 활용
시나리오 시작 부분에 Watch 모듈(예: Google Sheets Watch Rows)을 사용하면 트리거 데이터를 확인할 수 있습니다. Watch 모듈은 마지막 실행 이후 변경된 데이터만 가져오므로, 테스트할 때는 “Choose where to start” 옵션을 사용해서 특정 시점부터 다시 가져오도록 설정합니다.
Set Variable로 중간값 확인
복잡한 계산이나 데이터 변환 과정을 디버깅할 때는 Set Variable 모듈을 중간에 추가해서 값을 저장합니다. 그러면 Execution History에서 각 단계의 값을 확인할 수 있습니다. 문제가 해결되면 디버깅용 모듈은 제거합니다.
Test Run 기능
시나리오 편집 화면에서 “Run once” 버튼을 클릭하면 테스트 실행을 할 수 있습니다. 이때 Watch 모듈은 가장 최근 데이터 하나만 가져오므로 빠르게 테스트할 수 있습니다. 특정 모듈만 테스트하려면 해당 모듈을 우클릭하고 “Run this module only”를 선택합니다.
자주 발생하는 에러와 해결법 모음
“Bundle A could not be mapped to bundle B”
이 에러는 Iterator와 Aggregator 사이의 데이터 흐름이 올바르지 않을 때 발생합니다. Aggregator는 반드시 Iterator와 쌍으로 사용되어야 하며, Aggregator의 Source Module 설정에서 올바른 Iterator를 선택해야 합니다.
“The requested resource was not found” (404)
요청한 리소스(파일, 문서, 레코드 등)가 존재하지 않을 때 발생합니다. 원인은 크게 세 가지입니다: 1) ID가 잘못됨, 2) 리소스가 삭제됨, 3) 접근 권한이 없음. 해당 서비스에서 직접 리소스를 확인하고, ID가 정확한지, 연결된 계정에 접근 권한이 있는지 확인합니다.
“Invalid JSON” 또는 “Unexpected token”
JSON 파싱 에러입니다. HTTP 모듈로 API를 호출했는데 응답이 JSON이 아닌 경우(예: HTML 에러 페이지)에 자주 발생합니다. API 엔드포인트와 헤더 설정이 올바른지 확인하고, 응답 내용을 직접 확인해봅니다.
“ScenarioTimeout: Maximum execution time exceeded”
시나리오 실행 시간이 플랜의 제한을 초과했습니다. 데이터를 청크로 나누어 처리하거나, 더 높은 플랜으로 업그레이드해야 합니다. 또는 시나리오를 여러 개로 분할하고 Webhook으로 연결하는 방법도 있습니다.
“Duplicate entry” 또는 “UNIQUE constraint failed”
데이터베이스나 시트에 이미 존재하는 값을 다시 추가하려고 할 때 발생합니다. Search 모듈을 먼저 실행해서 중복 여부를 확인한 후, 없는 경우에만 추가하도록 분기 처리합니다. 또는 Upsert(있으면 업데이트, 없으면 추가) 기능을 제공하는 모듈을 사용합니다.
에러 알림 자동화 구축하기
시나리오에서 에러가 발생하면 즉시 알림을 받을 수 있도록 설정하는 것이 좋습니다. Make에서 제공하는 기본 이메일 알림 외에도, 직접 알림 시나리오를 구축할 수 있습니다.
Slack 알림 설정
에러 발생 시 Slack 채널로 알림을 보내는 시나리오를 만들 수 있습니다. Error Handler에 Slack의 “Send a Message” 모듈을 연결하고, 에러 정보(시나리오 이름, 에러 유형, 에러 메시지, 발생 시간)를 포함한 메시지를 보내도록 설정합니다.
메시지 템플릿 예시:
🚨 *시나리오 에러 발생*
• 시나리오: {{scenario.name}}
• 에러 유형: {{error.type}}
• 메시지: {{error.message}}
• 발생 시간: {{formatDate(now; “YYYY-MM-DD HH:mm:ss”)}}
에러 로그 데이터베이스 구축
모든 에러를 Google Sheets나 Airtable에 기록하면 에러 패턴을 분석할 수 있습니다. Error Handler에서 에러 정보를 스프레드시트에 추가하는 모듈을 연결합니다. 시간이 지나면 어떤 에러가 자주 발생하는지, 특정 시간대에 에러가 집중되는지 등의 패턴을 파악할 수 있습니다.
예방이 최선: 에러 방지 설계 원칙
에러를 해결하는 것보다 에러를 방지하는 것이 더 중요합니다. 시나리오 설계 단계에서 몇 가지 원칙을 지키면 에러 발생을 크게 줄일 수 있습니다.
방어적 데이터 처리
외부에서 받는 모든 데이터는 예상과 다를 수 있다고 가정합니다. 필수 필드가 비어있을 수 있고, 데이터 타입이 다를 수 있고, 형식이 일관되지 않을 수 있습니다. ifempty() 함수를 사용해서 빈 값에 대한 기본값을 설정하고, 데이터 타입 변환 함수를 적극 활용합니다.
점진적 복잡도 증가
처음부터 복잡한 시나리오를 만들지 않습니다. 가장 기본적인 흐름부터 시작해서 테스트하고, 점차 기능을 추가합니다. 각 단계에서 테스트를 철저히 해서 문제가 발생하면 바로 원인을 파악할 수 있게 합니다.
모듈화 설계
하나의 거대한 시나리오보다 여러 개의 작은 시나리오가 관리하기 쉽습니다. 각 시나리오는 하나의 명확한 목적을 가지고, 시나리오 간에는 Webhook이나 Data Store로 데이터를 전달합니다. 이렇게 하면 에러가 발생해도 영향 범위가 제한되고, 디버깅도 쉬워집니다.
충분한 테스트
시나리오를 활성화하기 전에 다양한 케이스로 테스트합니다. 정상 케이스뿐만 아니라 에지 케이스(빈 데이터, 특수 문자, 대용량 데이터 등)도 테스트합니다. “Run once”로 단건 테스트를 하고, 문제가 없으면 소량의 실제 데이터로 테스트한 후, 최종적으로 전체 데이터로 테스트합니다.
마무리: 에러는 성장의 기회
Make에서 에러를 만나면 좌절하기보다 학습의 기회로 삼으세요. 각 에러를 해결하면서 시스템에 대한 이해가 깊어지고, 더 견고한 자동화를 만들 수 있게 됩니다. 이 글에서 다룬 내용을 참고해서 에러를 체계적으로 분석하고 해결하면, 어떤 에러든 두렵지 않게 될 것입니다. 자동화 전문가가 되는 길은 수많은 에러를 해결하는 과정 그 자체입니다.