AI OPERATIONS · RELIABILITY · 2026.09.04
AI 자동화, 모델보다 먼저 장애를 설계해야 합니다: 재시도·폴백·SLA 운영 가이드
AI 자동화는 데모에서는 잘 움직여도 실제 운영에서는 API 지연, 인증 만료, 데이터 누락, 모델 오류, 외부 시스템 장애를 만납니다. 그래서 운영 전환의 핵심은 AI가 잘할 때가 아니라 실패했을 때 업무가 어떻게 계속되는지를 설계하는 것입니다.
PoC에서는 잘 되는데 운영에서 멈추는 이유
PoC는 보통 정상 데이터를 넣고 한두 번 실행해 결과를 확인합니다. 하지만 실제 업무는 다릅니다. ERP API가 늦게 응답할 수 있고, CRM 토큰이 만료될 수 있고, 엑셀 파일의 열 이름이 바뀔 수 있습니다. LLM 응답이 늦거나 형식이 달라질 수도 있습니다.
이때 자동화가 하나의 긴 직선으로 연결돼 있다면 중간 한 곳의 장애가 전체 업무를 멈춥니다.
| 운영 장애 | 단순 구현 | 운영형 설계 |
|---|---|---|
| LLM API 지연 | 화면이 계속 대기 | 타임아웃 후 재시도 또는 대체 처리 |
| ERP 호출 실패 | 작업 전체 실패 | 큐에 보관하고 복구 후 재처리 |
| 같은 요청 재전송 | 발주·등록이 중복될 수 있음 | 멱등성 키로 한 번만 실행 |
| AI 판단 불확실 | 그대로 실행 | 사람 검토 큐로 전환 |
| 외부 서비스 장기 장애 | 업무 중단 | 수동 절차나 대체 시스템으로 폴백 |
운영 자동화의 기본 구조: 요청 → 판단 → 실행 → 확인
AI 프로젝트를 설계할 때 흔히 ‘프롬프트 → 모델 → 결과’만 봅니다. 비즈니스 시스템에서는 그 앞뒤가 더 중요합니다.
2. 데이터 검증 — 필수 값이 있고 최신 데이터인가
3. AI 판단 — 모델 결과와 신뢰도·규칙을 함께 확인
4. 실행 — ERP·CRM·광고·메시지 API 호출
5. 결과 확인 — 실제 시스템에 반영됐는지 검증
6. 실패 처리 — 재시도·폴백·사람 확인 중 하나로 분기
1. 타임아웃은 ‘얼마나 기다릴 것인가’를 정하는 업무 규칙입니다
외부 API가 응답하지 않을 때 무한히 기다리면 사용자는 시스템이 멈췄는지 알 수 없습니다. 반대로 너무 빨리 실패 처리하면 정상 요청도 버릴 수 있습니다.
중요한 것은 기술적으로 몇 초를 설정하느냐보다 이 업무가 언제까지 처리돼야 가치가 있는가입니다. 고객 문의 분류는 수분 내 처리돼도 되지만 실시간 결제 승인이나 재고 차감은 훨씬 짧은 기준이 필요할 수 있습니다.
2. 재시도는 횟수보다 ‘무엇을 다시 해도 안전한가’가 중요합니다
네트워크 순간 오류나 일시적인 5xx 응답은 일정 간격을 두고 다시 시도할 수 있습니다. 하지만 모든 작업을 그대로 재시도해서는 안 됩니다.
중복 실행이 특히 위험한 작업
발주 생성, 결제 요청, 쿠폰 발급, 고객 메시지 전송, 광고 예산 변경처럼 한 번만 실행돼야 하는 업무는 멱등성(idempotency)을 설계해야 합니다. 같은 요청 ID가 다시 들어오더라도 이미 처리됐다면 새 작업을 만들지 않는 방식입니다.
3. 폴백은 ‘AI가 안 되면 무엇으로 일할 것인가’입니다
폴백은 반드시 다른 AI 모델일 필요가 없습니다. 업무 위험도에 따라 세 가지 방식이 가능합니다.
| 폴백 방식 | 적합한 상황 | 예시 |
|---|---|---|
| 대체 모델 | 요약·분류처럼 결과 형식이 비슷할 때 | 주 모델 장애 시 보조 모델 사용 |
| 규칙 기반 처리 | 핵심 조건을 코드로 판단할 수 있을 때 | AI 분류 실패 시 키워드·금액 규칙 적용 |
| 사람 검토 | 고객·금액·계약에 영향이 클 때 | 자동 실행을 멈추고 담당자 큐로 전달 |
좋은 폴백은 AI를 어떻게든 계속 쓰는 것이 아니라 업무를 안전하게 계속하는 방법입니다.
4. 큐를 두면 외부 시스템 장애가 전체 업무 중단으로 번지는 것을 줄일 수 있습니다
예를 들어 AI가 고객 문의를 분류한 뒤 CRM에 티켓을 생성한다고 해보겠습니다. CRM이 20분 동안 장애라면 분류 결과를 버릴 것이 아니라 큐에 보관하고 서비스가 복구된 뒤 다시 처리해야 합니다.
이 구조에서는 AI 처리와 CRM 반영이 분리됩니다. 덕분에 한 시스템의 장애가 다른 단계까지 연쇄적으로 막는 것을 줄일 수 있습니다.
5. 모니터링은 서버가 살아 있는지만 보는 것이 아닙니다
AI 자동화는 기술 지표와 업무 지표를 함께 봐야 합니다.
| 기술 모니터링 | 업무 모니터링 |
|---|---|
| API 응답 시간 | 처리 완료까지 걸린 시간 |
| 오류율·재시도 횟수 | 사람 검토로 넘어간 비율 |
| 모델 호출량·토큰 사용량 | 자동 처리 성공 건수 |
| 큐 적체량 | 미처리 주문·문의·발주 건수 |
서버는 정상인데 큐에 고객 문의 3,000건이 쌓여 있다면 비즈니스 관점에서는 장애입니다.
6. SLA는 계약 문구가 아니라 운영 기준표로 먼저 쓰는 것이 좋습니다
SLA(Service Level Agreement)를 거창하게 시작할 필요는 없습니다. 내부 자동화라도 다음 네 가지를 정하면 운영 기준이 생깁니다.
성공 기준: 어느 단계까지 완료돼야 성공인가?
장애 기준: 실패율이나 적체가 어느 수준이면 장애인가?
대응 방식: 자동 재시도, 사람 호출, 수동 전환 중 무엇을 할 것인가?
실제 예시: AI 발주 보조 시스템
유통사의 AI가 판매 속도와 재고를 보고 발주 수량을 제안하고, 담당자가 승인하면 ERP에 발주 초안을 생성하는 시스템을 가정해보겠습니다.
정상 경로는 단순합니다. 데이터 수집 → 수요 분석 → AI 설명 → 담당자 승인 → ERP 등록입니다. 그러나 운영 설계에서는 다음 상황도 함께 정의해야 합니다.
| 상황 | 처리 |
|---|---|
| 재고 데이터가 6시간 이상 오래됨 | AI 호출 전에 중단하고 데이터 갱신 요청 |
| AI 응답 형식 오류 | 1회 재생성 후 실패하면 담당자 검토 |
| ERP API 타임아웃 | 요청 ID를 유지한 채 큐에서 재시도 |
| 같은 승인 이벤트 중복 수신 | 멱등성 키로 기존 발주 여부 확인 |
| ERP 장기 장애 | 승인된 발주 목록을 수동 등록용 파일로 제공 |
이 정도가 정의돼야 “AI 발주 데모”가 아니라 실제 업무 시스템에 가까워집니다.
외주·구축 제안서에서 확인할 질문
AI 자동화 프로젝트를 발주한다면 모델 이름이나 화면 디자인뿐 아니라 아래 질문에 답이 있는지 확인하는 것이 좋습니다.
② 중복 실행을 막는 방법이 있는가?
③ AI 결과가 기준을 못 넘으면 어디로 보내는가?
④ 처리되지 않은 작업을 어디에서 확인할 수 있는가?
⑤ 장애·비용·처리량을 어떤 지표로 모니터링하는가?
⑥ 외부 AI나 SaaS가 장기 장애일 때 수동 업무 절차가 있는가?
⑦ 운영 중 모델이나 API를 교체하기 쉬운 구조인가?
보안과 안정성은 함께 설계해야 합니다
OWASP의 생성형 AI 보안 가이드도 프롬프트 인젝션, 민감정보 노출, 과도한 권한 같은 위험을 주요 항목으로 다룹니다. 특히 AI가 외부 도구를 호출하는 구조에서는 필요한 권한만 주고, 영향이 큰 실행에는 승인과 기록을 남기는 것이 중요합니다. NIST의 Generative AI Profile 역시 생성형 AI 위험을 개발 단계 한 번이 아니라 전체 수명주기에서 관리하는 접근을 권고합니다.
참고: OWASP GenAI/LLM Top 10 · NIST AI RMF Generative AI Profile
FAQ
AI 모델 정확도가 높으면 운영 안정성도 높은가요?
아닙니다. 모델이 좋은 답을 내는 것과 시스템이 안정적으로 업무를 끝내는 것은 별개입니다. 인증, API 장애, 데이터 품질, 중복 실행, 결과 검증을 함께 설계해야 합니다.
AI API가 실패하면 무조건 재시도하면 되나요?
아닙니다. 일시적인 오류에는 재시도가 유효하지만 결제·발주·메시지처럼 중복이 위험한 작업은 멱등성과 실행 상태 확인이 먼저입니다.
SLA는 대기업 프로젝트에만 필요한가요?
작은 자동화에도 유용합니다. “몇 분 안에 처리”, “몇 번 실패하면 사람에게 전달”, “미처리 작업은 어디서 확인”처럼 간단한 내부 기준부터 만들 수 있습니다.
Voxen은 이런 ‘운영 단계’를 함께 설계합니다
Voxen은 AI 모델 연결만 하는 것이 아니라 데이터 수집과 데이터 엔지니어링, API·대시보드, AI 자동화와 맞춤 시스템 구축을 실제 업무 프로세스에 연결합니다. 특히 ERP·CRM·엑셀·외부 SaaS가 함께 움직이는 환경에서 실패 처리, 승인, 로그, 모니터링까지 포함해 운영 가능한 구조를 만드는 데 초점을 둡니다.
AI PoC가 잘 동작했지만 실제 배포 단계에서 막혀 있다면, 모델을 다시 고르기 전에 업무의 성공·실패 경로부터 점검해보는 편이 효과적입니다.
이 글도 읽어보세요
AI 도구는 샀는데, 우리 회사 일에 누가 맞춰주나요? FDE가 필요한 이유
현업 문제와 데이터·AI·업무 시스템을 실제 구현으로 연결하는 역할이 왜 필요한지 설명합니다.
AI PoC는 됐는데, 왜 현업에서 멈출까?
데모를 운영으로 넘길 때 빠지기 쉬운 데이터, 권한, 로그, 예외처리 체크포인트를 정리합니다.
AI 에이전트 구축 비용, 무엇이 견적을 바꿀까?
운영 범위와 데이터·API 연결 수준이 실제 구축 비용에 어떤 영향을 주는지 확인할 수 있습니다.