1. 자동화는 왜 실패하는가
자동화는 한 번 만들어두면 계속 같은 방식으로 실행될 것처럼 보이지만, 실제 업무 환경에서는 입력값과 외부 서비스 상태가 계속 바뀝니다. 그래서 자동화 실패는 “설계를 잘못해서만” 생기는 문제가 아닙니다. 정상적인 운영 과정에서도 충분히 발생합니다.
예를 들어 고객 문의를 받아 AI가 요약하고, 스프레드시트에 기록한 뒤 담당자에게 알림을 보내는 흐름이 있다고 가정하겠습니다. 이 자동화는 다음과 같은 이유로 멈출 수 있습니다.
- 문의 내용이 비어 있음
- 이메일 주소 형식이 잘못됨
- 첨부파일 용량이 너무 큼
- Google Sheets 접근 권한이 변경됨
- Slack, Gmail, Notion 같은 외부 서비스 API가 일시적으로 응답하지 않음
- AI 응답이 예상한 형식으로 나오지 않음
- 자동화 도구의 실행 횟수 제한 또는 요금제 제한에 걸림
- 이전 단계에서 받아야 할 데이터가 누락됨
입문 단계에서 중요한 관점은 “오류가 나지 않게 완벽히 만드는 것”이 아닙니다. 오류가 났을 때 어디서, 왜, 어떤 데이터로 실패했는지 알 수 있게 만드는 것입니다. 자동화는 실패 자체보다 실패를 모르는 상태가 더 위험합니다.
2. 데이터가 비어 있을 때의 처리
가장 흔한 실패 원인은 빈 데이터입니다. 사람이 보면 “내용이 없네” 하고 넘어갈 수 있지만, 자동화 도구는 다음 단계에서 그 값을 그대로 사용하려고 합니다. 그러면 이메일 본문이 빈 채로 발송되거나, AI에게 빈 문장을 분석하라고 보내거나, 스프레드시트에 의미 없는 행이 쌓일 수 있습니다.
그래서 자동화 흐름 초반에는 필수값 확인 단계를 두는 것이 좋습니다. 예를 들어 고객 문의 자동화라면 최소한 아래 항목은 확인 대상이 됩니다.
- 문의 제목
- 문의 본문
- 고객 이메일
- 접수 시간
- 문의 채널
- 담당 분류에 필요한 최소 정보
n8n, Make, Zapier 모두 조건 분기 기능을 제공합니다. 도구마다 이름은 다르지만 구조는 비슷합니다.
- 값이 있으면 정상 흐름으로 진행
- 값이 없으면 오류 기록 후 관리자에게 알림
- 필요하면 “사람 확인 필요” 상태로 저장
예를 들어 다음과 같은 기준을 만들 수 있습니다.
문의 본문이 비어 있으면:
1. AI 요약 단계로 보내지 않는다.
2. 스프레드시트에 상태값을 "본문 없음"으로 기록한다.
3. 관리자에게 확인 요청 알림을 보낸다.Google Apps Script를 사용하는 경우에는 간단한 조건문으로도 필수값을 확인할 수 있습니다.
function validateInquiry(inquiry) {
if (!inquiry.body || inquiry.body.trim() === "") {
throw new Error("문의 본문이 비어 있습니다.");
}
if (!inquiry.email || inquiry.email.trim() === "") {
throw new Error("고객 이메일이 비어 있습니다.");
}
return true;
}여기서 핵심은 빈 값을 “대충 처리”하지 않는 것입니다. 값이 없으면 자동화가 계속 진행되지 않도록 막고, 사람이 확인할 수 있는 흔적을 남겨야 합니다.
3. API 오류가 발생했을 때의 처리
자동화는 대부분 외부 서비스와 연결됩니다. Gmail, Google Sheets, Slack, Notion, Airtable, CRM, 결제 시스템, AI API 등이 대표적입니다. 이런 서비스들은 평소에는 잘 작동하지만, 가끔 응답이 늦거나 실패할 수 있습니다.
API 오류는 크게 몇 가지로 나눠볼 수 있습니다.
- 인증 오류: 토큰 만료, 권한 변경, 계정 연결 해제
- 요청 오류: 잘못된 데이터 형식, 필수값 누락
- 제한 오류: 호출 횟수 제한, 사용량 제한
- 서버 오류: 외부 서비스의 일시적 장애
- 네트워크 오류: 응답 지연, 타임아웃
모든 오류를 같은 방식으로 처리하면 운영이 어려워집니다. 예를 들어 인증 오류는 재시도해도 해결되지 않는 경우가 많습니다. 반면 일시적인 서버 오류나 네트워크 오류는 잠시 후 다시 시도하면 성공할 수 있습니다.
기본 처리 기준은 이렇게 잡을 수 있습니다.
인증 오류:
- 즉시 관리자 알림
- 자동 재시도보다 계정 연결 상태 확인 우선
요청 오류:
- 실패 데이터 기록
- 입력값 검토
- 같은 요청을 반복 재시도하지 않음
일시적 서버 오류:
- 일정 시간 후 재시도
- 반복 실패 시 관리자 알림
사용량 제한:
- 실행 빈도 조정
- 대량 처리 흐름이면 배치 단위 축소n8n에는 노드 단위의 재시도 설정, 오류 흐름 처리 기능이 제공되는 것으로 알려져 있습니다. Make와 Zapier도 시나리오 또는 Zap 실행 실패 시 재시도, 오류 알림, 실행 기록 확인 기능을 제공합니다. 다만 세부 명칭과 제공 범위는 요금제와 버전에 따라 달라질 수 있으므로 실제 운영 전에는 사용하는 도구의 실행 기록과 오류 처리 메뉴를 확인해야 합니다.
4. AI 응답이 이상할 때의 처리
AI가 들어간 자동화에서는 일반 API 오류와 다른 문제가 생깁니다. 호출 자체는 성공했는데, 응답 내용이 업무에 쓰기 어려운 경우입니다.
예를 들어 다음과 같은 상황이 있습니다.
- 요약 결과가 너무 길거나 짧음
- 분류값이 정해진 목록에 없음
- JSON 형식으로 달라고 했는데 일반 문장으로 답함
- 고객 문의와 상관없는 답변이 포함됨
- 확신할 수 없는 내용을 사실처럼 작성함
- 민감정보를 그대로 포함함
AI 응답은 “성공 또는 실패”만으로 판단하기 어렵습니다. 그래서 AI 뒤에는 검증 단계를 두는 편이 안전합니다. 특히 자동화가 다음 액션으로 이어질수록 검증이 중요합니다.
예를 들어 문의 분류 자동화라면 AI가 아무 분류명이나 만들지 못하도록 허용 목록을 정해둡니다.
허용 분류:
- 결제
- 환불
- 계정
- 기술지원
- 제휴
- 기타AI 응답이 이 목록 밖이면 자동으로 담당자에게 보내지 않고, “분류 확인 필요” 상태로 남기는 방식이 좋습니다.
AI 분류 결과가 허용 목록에 있으면:
- 해당 담당자에게 전달
AI 분류 결과가 허용 목록에 없으면:
- 상태를 "분류 확인 필요"로 저장
- 관리자에게 확인 알림 전송JSON 응답을 기대하는 경우에는 형식 검증도 필요합니다. Apps Script에서는 다음처럼 JSON 파싱 실패를 잡을 수 있습니다.
function parseAiResponse(responseText) {
try {
const data = JSON.parse(responseText);
if (!data.category || !data.summary) {
throw new Error("AI 응답에 필수 필드가 없습니다.");
}
return data;
} catch (error) {
throw new Error("AI 응답 형식 오류: " + error.message);
}
}AI가 포함된 자동화에서는 “AI가 답을 냈다”가 완료 조건이 아닙니다. 그 답이 정해진 형식과 업무 기준을 만족해야 다음 단계로 넘어갈 수 있습니다.
5. 실패 기록을 남겨야 하는 이유
자동화가 실패했을 때 기록이 없으면 원인을 찾기 어렵습니다. 담당자는 “어제 어떤 문의가 누락된 것 같다”는 정도만 알게 되고, 어느 단계에서 멈췄는지 확인하는 데 많은 시간이 걸립니다.
실패 기록에는 최소한 다음 정보가 들어가는 것이 좋습니다.
- 실패 발생 시간
- 자동화 이름
- 실패 단계
- 오류 메시지
- 입력 데이터의 식별값
- 재시도 여부
- 담당자 확인 상태
예시는 다음과 같습니다.
{
"failed_at": "2026-07-14T10:30:00+09:00",
"workflow_name": "customer_inquiry_summary",
"failed_step": "AI classification",
"error_message": "AI 응답에 필수 필드가 없습니다.",
"source_id": "INQ-20260714-001",
"retry_count": 1,
"status": "needs_review"
}이런 기록은 Google Sheets, Airtable, Notion Database, 내부 DB 등에 남길 수 있습니다. 입문 단계에서는 별도 시스템을 만들기보다 스프레드시트에 실패 로그 탭을 하나 두는 방식이 가장 현실적입니다.
중요한 점은 성공 기록과 실패 기록을 섞지 않는 것입니다. 같은 시트에 모두 넣더라도 상태값을 명확히 구분해야 합니다.
상태값 예시:
- 성공
- 입력값 오류
- API 오류
- AI 응답 오류
- 재시도 대기
- 사람 확인 필요이렇게 남겨두면 반복해서 발생하는 오류를 찾을 수 있습니다. 예를 들어 특정 채널에서 들어온 문의만 본문이 비어 있다면, 자동화 문제가 아니라 입력 폼 설정 문제일 수 있습니다.
6. 오류 발생 시 관리자에게 알림 보내기
기록만 남기고 아무도 보지 않으면 자동화 실패는 계속 방치됩니다. 그래서 일정 수준 이상의 오류는 관리자나 담당자에게 알림이 가야 합니다.
알림 채널은 조직에서 실제로 자주 확인하는 곳을 기준으로 고르는 편이 좋습니다.
- Slack
- Microsoft Teams
- 이메일
- 카카오워크
- Discord
- Google Chat
알림 내용은 길 필요가 없습니다. 대신 바로 판단할 수 있어야 합니다.
[자동화 오류 알림]
자동화: 고객 문의 요약 및 분류
실패 단계: AI 분류
오류 내용: AI 응답에 필수 필드가 없습니다.
문의 ID: INQ-20260714-001
발생 시간: 2026-07-14 10:30
필요 조치: 실패 로그 확인 후 수동 분류알림을 너무 많이 보내면 오히려 아무도 보지 않게 됩니다. 모든 사소한 오류를 즉시 알리는 대신, 업무 영향도에 따라 나누는 방식이 좋습니다.
즉시 알림:
- 고객에게 잘못된 메시지가 발송될 수 있는 오류
- 결제, 환불, 계약 관련 오류
- 인증 오류로 자동화 전체가 멈춘 경우
- 같은 오류가 반복 발생한 경우
로그만 기록:
- 선택값 누락
- 테스트 데이터 오류
- 사람이 나중에 모아서 처리해도 되는 항목n8n이나 Make에서는 오류 전용 경로를 만들어 Slack 또는 이메일로 연결할 수 있습니다. Zapier도 Zap 실행 실패 알림과 Zap History 확인 기능을 제공하는 것으로 알려져 있습니다. 다만 실제 알림 방식은 워크스페이스 설정, 권한, 요금제에 따라 달라질 수 있습니다.
7. 자동화 안정성을 높이는 기본 원칙
처음부터 복잡한 예외 처리를 모두 넣으려고 하면 자동화 자체를 만들기 어려워집니다. 입문 단계에서는 아래 원칙만 지켜도 실패 대응 수준이 크게 올라갑니다.
첫째, 필수값 검사를 앞단에 둡니다. 비어 있는 데이터, 형식이 맞지 않는 데이터, 허용 범위를 벗어난 데이터는 다음 단계로 보내지 않는 것이 기본입니다.
둘째, 외부 서비스 오류와 데이터 오류를 구분합니다. 데이터가 잘못된 요청은 반복 재시도해도 해결되지 않습니다. 반대로 일시적인 API 오류는 짧은 간격을 두고 재시도할 수 있습니다.
셋째, AI 응답은 반드시 검증합니다. AI가 만든 요약, 분류, 답변 초안은 정해진 형식과 허용 목록을 통과해야 합니다. 특히 고객에게 직접 발송되거나 외부 시스템에 반영되는 흐름에서는 사람 확인 단계를 두는 편이 안전합니다.
넷째, 실패 로그를 남깁니다. 자동화 이름, 실패 단계, 오류 메시지, 원본 데이터 식별값만 남겨도 문제 추적이 훨씬 쉬워집니다.
다섯째, 중요한 오류는 관리자에게 알립니다. 자동화는 조용히 실패할 때 가장 위험합니다. 운영자가 바로 확인해야 하는 오류와 나중에 모아서 봐도 되는 오류를 나누면 알림 피로도 줄일 수 있습니다.
여섯째, 한 번에 완전 자동화를 목표로 하지 않습니다. 처음에는 “실패하면 멈추고 사람에게 넘기는 구조”가 더 안전합니다. 자동화가 충분히 안정적으로 돌아가고 실패 패턴이 줄어든 뒤에 일부 단계를 더 자동화하는 방식이 현실적입니다.
AI 자동화에서 예외 처리는 부가 기능이 아니라 운영 설계의 일부입니다. 정상 흐름만 만든 자동화는 데모에서는 잘 보이지만, 실제 업무에서는 금방 불안정해질 수 있습니다. 오류가 날 수 있다는 전제를 두고 알림, 기록, 재시도, 사람 확인 단계를 작게라도 넣어두면 자동화는 훨씬 오래 유지됩니다.
댓글 0