AI 자동화에서 예외처리를 빼먹으면 생기는 문제들

AI 자동화를 처음 만들 때는 보통 "일단 돌아가게" 만드는 데 집중한다. 프롬프트를 짜고, 스크립트를 붙이고, 예약 실행까지 걸어두면 꽤 그럴듯해 보인다. 문제는 그다음부터다. 실제 운영에서는 항상 예상 밖의 상황이 생긴다. 로그인 세션이 끊기고, 외부 API가 느려지고, 파일 경로 하나가 바뀌고, 사람이 중간에 확인해야 하는 순간도 생긴다.

이때 예외처리를 빼먹은 자동화는 조용히 망가진다. 더 나쁜 경우에는 망가진 줄도 모른 채 잘못된 결과를 계속 만든다. AI 자동화를 오래 운영하려면 "정상 흐름"보다 "비정상 흐름"을 먼저 설계해야 한다.

왜 예외처리가 특히 더 중요한가

일반적인 배치 작업도 예외처리가 중요하지만, AI 자동화는 변수의 종류가 더 많다. 모델 응답 길이가 달라질 수 있고, 브라우저 UI가 바뀔 수 있고, 사람이 승인해야 하는 단계가 끼어들 수도 있다. 즉, 코드만 안정적이라고 끝나는 구조가 아니다.

특히 아래 같은 특성이 예외처리를 더 중요하게 만든다.

• 외부 서비스 상태에 자주 영향을 받는다
• 입력 형식이 매번 완전히 같지 않다
• 사람 검수나 승인 지점이 중간에 들어간다
• 한 번의 실패가 다음 작업까지 꼬이게 만들 수 있다

자동화가 많아질수록 중요한 건 "실패를 없애는 것"이 아니라 "실패했을 때 안전하게 멈추고 복구하는 것"이다.

예외처리를 빼먹으면 실제로 생기는 문제

1. 실패했는데도 성공한 것처럼 기록된다

이게 가장 위험하다. 예를 들어 글 발행 자동화가 마지막 공개 단계에서 실패했는데, 상태 파일에는 published로 저장되는 경우가 있다. 그러면 운영자는 이미 끝난 줄 알고 넘어간다. 다음 날이 되면 큐는 밀리고, 누락 원인도 뒤늦게 찾게 된다.

이 문제를 막으려면 결과 기록은 항상 마지막 확인 이후에 해야 한다. 가능하면 아래 순서가 안전하다.

• 실행 시작 기록
• 중간 단계별 체크포인트 기록
• 최종 결과 실제 확인
• 그다음에만 성공 상태 저장

"성공 처리"는 가장 마지막에 해야 한다. 이 순서를 거꾸로 잡으면 운영 로그 전체가 거짓말을 하게 된다.

2. 중간 실패 후 재실행이 더 어려워진다

예외처리가 없는 자동화는 처음부터 끝까지 한 번에 성공하는 것만 가정한다. 그런데 현실에서는 중간 단계에서 멈추는 일이 훨씬 많다. 예를 들어 초안은 생성됐는데 업로드만 실패했다면, 다음 실행에서는 어디서부터 다시 시작해야 할지 애매해진다.

이럴 때 필요한 게 중단 지점 설계다. 최소한 아래는 분리해 두는 게 좋다.

• 초안 생성 완료
• 사람 검수 완료
• 외부 서비스 로그인 확인 완료
• 발행 요청 완료
• 공개 페이지 검증 완료

이렇게 나누면 재실행할 때 불필요한 작업을 반복하지 않아도 된다. 반대로 경계가 없으면 이미 끝난 작업까지 다시 돌리다가 중복 게시나 중복 전송이 생긴다.

3. 외부 서비스 문제를 내부 버그로 착각한다

AI 자동화를 운영하다 보면 문제 원인이 코드가 아니라 외부 환경인 경우가 많다. 세션 만료, 일시적인 429, 브라우저 버튼 구조 변경, 업스트림 응답 지연 같은 것들이다. 그런데 예외처리가 없으면 이런 상황도 그냥 "작동 안 함"으로만 보인다.

그래서 예외는 묶어서 처리하면 안 된다. 원인별로 나눠야 한다.

• 인증 실패
• 권한 부족
• 네트워크 지연
• 응답 형식 이상
• 사람이 개입해야 하는 보류 상태

운영 관점에서는 "실패했다"보다 "왜 실패했는지 분류된다"가 훨씬 중요하다. 그래야 복구 속도가 빨라진다.

사람 개입 포인트를 미리 정해야 한다

AI 자동화는 전부 무인으로 굴러가야 한다고 생각하기 쉽다. 그런데 실제로는 사람 개입 지점을 일부러 남겨두는 편이 더 안정적이다. 예를 들어 아래 같은 순간은 자동화가 무리하게 끝까지 밀지 않는 게 낫다.

로그인이나 2차 인증이 필요한 순간

세션이 끊겼는데도 억지로 우회하려 하면 더 큰 문제가 생긴다. 이때는 바로 사람에게 짧게 알려주고, 로그인 복구 뒤 다시 이어가는 흐름이 좋다.

공개 전 품질 검수가 필요한 순간

AI가 쓴 초안은 구조는 빨리 만들 수 있어도 맥락과 정확성은 흔들릴 수 있다. 검색 유입용 블로그, 기술 문서, 고객 노출 페이지처럼 품질이 중요한 글은 최종 검수 지점을 분리해 두는 게 맞다.

비용이 커질 수 있는 순간

대량 API 호출, 장시간 브라우저 작업, 외부 서비스 유료 액션은 실패 재시도 규칙을 아주 보수적으로 잡아야 한다. 자동 재시도를 무한대로 걸어두면 장애보다 비용 폭주가 먼저 올 수 있다.

예외처리를 설계할 때 꼭 넣어야 할 것

복잡한 시스템이 아니어도 아래 네 가지는 거의 기본값으로 넣는 게 좋다.

1. 실패 로그를 사람이 읽을 수 있게 남기기

스택 트레이스만 저장하는 로그는 개발자에게도 피곤하다. 운영 로그에는 최소한 다음이 보여야 한다.

• 어떤 작업이었는지
• 어디 단계에서 멈췄는지
• 자동 재시도가 가능한지
• 지금 사람이 해야 할 일이 뭔지

좋은 예외 로그는 디버깅 자료이면서 운영 안내문이기도 하다.

2. 재시도 정책을 분리하기

모든 실패를 같은 방식으로 재시도하면 안 된다.

• 네트워크 타임아웃: 짧게 몇 번 재시도 가능
• 인증 실패: 재시도보다 사용자 개입 요청
• 입력 형식 오류: 즉시 중단 후 데이터 점검
• 외부 서비스 429: 지연 후 제한적으로 재시도

재시도는 많을수록 좋은 게 아니라, 원인에 맞을수록 좋다.

3. 중복 실행 방지 장치 넣기

예외처리가 허술하면 실패 후 재실행 과정에서 같은 작업이 두 번 수행되기 쉽다. 특히 게시물 발행, 메시지 전송, 파일 업로드처럼 "한 번만" 실행돼야 하는 작업은 idempotency를 의식해야 한다.

실무에서는 이런 식으로 막는다.

• 실행 전 상태 파일 확인
• 작업 단위 고유 ID 부여
• 이미 처리한 결과 URL이나 리소스 ID 저장
• 최종 성공 전까지는 큐 상태를 queued/in_progress로 유지

4. 최종 검증 단계 만들기

자동화는 요청을 보냈다고 끝나면 안 된다. 실제로 반영됐는지 확인하는 마지막 단계가 꼭 필요하다. 글 발행이면 공개 페이지 확인, 메시지 전송이면 실제 전송 결과 확인, 파일 생성이면 내용 검증까지 보는 편이 안전하다.

요청 성공과 결과 성공은 다르다. 운영에서는 이 차이를 놓치면 안 된다.

작은 자동화라도 운영 기준을 가져가야 한다

예외처리는 거대한 서비스에서만 필요한 게 아니다. 혼자 쓰는 블로그 자동화, 개인 업무 비서, 홈서버 스크립트에도 똑같이 중요하다. 오히려 소규모 자동화일수록 한 번 망가지면 한동안 아무도 모르고 지나가기 쉽다.

그래서 개인 자동화라도 최소한 아래 기준은 추천한다.

• 실패를 숨기지 말 것
• 멈출 지점을 명확히 둘 것
• 사람 호출 조건을 정해둘 것
• 성공 기록은 검증 후에만 남길 것

이 네 가지만 지켜도 자동화의 신뢰도가 눈에 띄게 올라간다.

마무리

AI 자동화는 잘 돌아갈 때보다, 예상 밖 상황에서 어떻게 행동하는지가 더 중요하다. 예외처리를 빼먹으면 자동화는 편리한 도구가 아니라 관리 부담이 된다. 반대로 실패 경로를 잘 설계해 두면, 자동화는 오래 굴릴수록 더 믿을 만한 시스템이 된다.

처음부터 완벽하게 만들 필요는 없다. 다만 최소한 "어디서 실패할 수 있는지"와 "실패하면 어떻게 멈출지"는 설계해 두는 게 맞다. 자동화의 완성도는 정상 시나리오가 아니라 예외 시나리오에서 드러난다.