AI 자동화 런북, 실패했을 때 멈추고 복구하는 설계
AI 자동화가 실패했을 때 알림·중단·재시도·사람 승인까지 어떻게 운영 런북으로 설계해야 하는지 실무 체크리스트로 정리했습니다.
핵심은 “성공했을 때 자동화”가 아니라 “실패했을 때 안전하게 멈추는 자동화”입니다. AI Agent가 일을 맡을수록 런북은 선택이 아니라 운영 설계의 일부가 됩니다.
반복 업무를 AI 자동화로 넘기면 처음에는 “정확히 실행되는가”에 시선이 갑니다. 그런데 운영 단계에서 더 자주 문제가 되는 건 실패 순간입니다.
API가 늦게 응답하거나, 입력 데이터가 평소와 다르거나, AI가 확신 없는 답을 냈을 때 자동화가 계속 달리면 사람이 직접 처리할 때보다 피해 범위가 커질 수 있습니다.
그래서 HeyRatty가 AI 자동화를 설계할 때는 프롬프트와 기능만 보지 않습니다. 실패 감지, 중단 조건, 재시도, 담당자 알림, 복구 기록까지 하나의 런북으로 묶어 봅니다.
핵심 요약
- AI 자동화 런북은 “무엇을 할지”보다 “언제 멈추고 누구에게 넘길지”를 먼저 정리해야 합니다.
- 실패 조건은 기술 오류뿐 아니라 낮은 신뢰도, 권한 부족, 데이터 누락, 고객 영향 가능성까지 포함합니다.
- 재시도는 횟수·간격·중복 방지 기준이 있어야 하고, 무한 반복은 금지해야 합니다.
- 사람 승인 루프는 모든 단계가 아니라 비용·고객·보안 영향이 큰 지점에 배치하는 것이 현실적입니다.
- 운영 로그는 나중에 원인 분석과 개선이 가능할 정도로 남기되, 민감정보 원문을 그대로 저장하지 않는 원칙이 필요합니다.
1. 먼저 “정상 상태”를 문장으로 정의합니다
런북을 만들기 전에는 자동화가 정상적으로 끝난 상태를 한 문장으로 써야 합니다. 예를 들어 “문의 내용을 분류하고, 담당 채널에 요약을 남기고, 고객에게는 접수 안내만 보낸다”처럼 결과가 명확해야 합니다.
정상 상태가 흐리면 실패 조건도 흐려집니다. “대충 요약했다”, “아마 맞을 것이다” 같은 표현이 운영에 들어가면 담당자는 장애인지 정상인지 판단하기 어렵습니다.
2. 실패 조건을 5가지 층으로 나눕니다
AI 자동화의 실패는 단순한 서버 오류만이 아닙니다. 다음 다섯 가지를 따로 적어두면 런북이 훨씬 현실적으로 바뀝니다.
- 입력 실패: 파일 없음, 필수 필드 누락, OCR 품질 저하, 고객 메시지 맥락 부족
- 모델 판단 실패: 낮은 confidence, 서로 모순되는 답변, 정책상 답하면 안 되는 요청
- 도구 실행 실패: API timeout, 권한 없음, 외부 SaaS 장애, 저장 실패
- 비즈니스 위험: 금액 변경, 계약 조건, 고객에게 바로 전송되는 답변, 환불·해지 처리
- 보안 위험: 개인정보·계정 정보·내부 문서가 로그나 알림에 과다 노출되는 상황
실무 팁: 실패 조건은 개발자가 혼자 정하기보다 실제 담당자와 함께 “이 상황이면 사람이 봐야 한다”는 장면을 먼저 모으는 편이 빠릅니다.
3. 자동 재시도는 “짧고 제한적으로” 둡니다
자동화가 실패할 때 가장 위험한 패턴은 무한 재시도입니다. 같은 고객에게 알림이 여러 번 가거나, 같은 주문을 중복 처리하거나, 외부 API 제한에 걸릴 수 있습니다.
재시도 규칙에는 최소한 네 가지가 있어야 합니다. 몇 번까지 재시도할지, 간격은 어떻게 늘릴지, 같은 작업인지 식별하는 키는 무엇인지, 마지막 실패 후 누구에게 알릴지입니다.
예를 들어 “2분 뒤 1회, 10분 뒤 1회만 재시도하고 같은 주문번호는 한 번만 처리한다. 두 번 실패하면 운영 채널에 요약을 남긴다”처럼 적어야 실제 운영자가 이해할 수 있습니다.
4. 사람 승인 지점은 비용·고객·보안 영향 기준으로 고릅니다
모든 작업에 사람 승인을 넣으면 자동화의 속도가 사라집니다. 반대로 모든 작업을 자동으로 보내면 작은 오류가 외부 고객 경험으로 번질 수 있습니다.
승인이 필요한 지점은 보통 세 가지입니다. 돈이 움직이는 처리, 고객에게 바로 보이는 메시지, 권한이나 개인정보가 걸린 작업입니다. 이 세 영역은 AI가 초안을 만들더라도 최종 실행 전에 사람이 확인하는 구조가 안전합니다.
5. 알림은 “상태”가 아니라 “다음 행동”을 알려야 합니다
운영 알림이 “자동화 실패” 한 줄로 끝나면 담당자는 다시 로그를 뒤져야 합니다. 좋은 알림은 다음 행동을 바로 알려줍니다.
- 무슨 작업이 실패했는지: 예) 신규 문의 분류 후 CRM 등록
- 어느 단계에서 멈췄는지: 예) CRM 저장 API timeout
- 고객 영향이 있는지: 예) 고객에게 아직 발송된 메시지 없음
- 담당자가 할 일: 예) CRM에 수동 등록 후 티켓을 완료 처리
- 재시도 여부: 예) 자동 재시도 2회 완료, 추가 재시도 중단
운영 전 체크리스트
- 정상 완료 기준을 담당자가 이해할 수 있는 문장으로 적었는가
- 입력·모델·도구·비즈니스·보안 실패 조건을 분리해 정의했는가
- 재시도 횟수, 간격, 중복 방지 키를 정했는가
- 사람 승인 지점을 비용·고객·보안 영향 기준으로 골랐는가
- 알림에 원인, 영향, 다음 행동, 담당자가 함께 들어가는가
- 로그에 민감정보 원문이 과도하게 남지 않도록 마스킹 기준을 정했는가
- 장애 후 회고에서 런북을 업데이트하는 담당자와 주기를 정했는가
FAQ
Q. 작은 자동화에도 런북이 필요할까요?
고객에게 보이지 않는 개인 생산성 자동화라면 간단한 메모로도 충분할 수 있습니다. 다만 고객 응대, 주문, 내부 승인, 데이터 변경처럼 영향 범위가 있는 업무라면 작게라도 런북을 두는 편이 안전합니다.
Q. Slack이나 카카오워크 알림만 붙이면 런북이라고 볼 수 있나요?
알림은 런북의 일부입니다. 런북에는 어떤 조건에서 멈추는지, 누가 확인하는지, 수동 복구는 어떻게 하는지, 다시 자동화를 켜는 기준은 무엇인지가 함께 있어야 합니다.
Q. AI가 판단한 confidence를 그대로 믿어도 되나요?
confidence는 참고 신호로 쓰되 단독 기준으로 두지 않는 편이 좋습니다. 입력 품질, 업무 영향도, 금액·권한·개인정보 여부 같은 규칙 기반 조건과 함께 묶어야 운영 리스크가 줄어듭니다.
HeyRatty는 이렇게 도와드립니다
HeyRatty는 AI Agent와 업무자동화를 만들 때 실행 플로우만 구현하지 않습니다. 실패 조건, 승인 루프, 운영 로그, 담당자 알림까지 함께 설계해 실제 팀이 안심하고 쓰는 자동화를 목표로 합니다.
이미 반복 업무를 자동화하고 있지만 “실패했을 때 누가 어떻게 처리하지?”가 불분명하다면, 현재 업무 흐름을 기준으로 런북부터 정리해보는 것이 좋습니다.
참고 및 이미지 출처
- NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide — 사고 대응 절차를 운영 관점에서 참고했습니다.
- Atlassian: What is an incident runbook? — 런북의 기본 개념과 운영 문서 관점을 참고했습니다.
- Automation workflow map — Resolve Systems, Inc., Wikimedia Commons, CC BY-SA 4.0. 본문 이미지와 썸네일로 사용했습니다.