6 분 소요

에이전트 자동화에서 실패 복구를 먼저 설계해야 하는 이유

AI 에이전트 자동화를 처음 붙일 때는 보통 잘 되는 장면부터 떠올리게 된다. 메시지를 보내면 초안이 생성되고, 코딩 작업을 던지면 수정이 끝나고, 검토를 요청하면 결과가 돌아오는 흐름 말이다. 데모에서는 이런 장면이 가장 인상적이고, 실제로도 처음 자동화를 붙이는 계기가 되기 쉽다.

그런데 운영 단계에 들어가면 체감이 조금 달라진다. 자동화 품질을 가르는 건 “한 번 멋지게 성공하는가”보다 실패했을 때 어디서 멈췄는지 드러나는가, 다시 이어갈 수 있는가, 사용자가 상황을 이해할 수 있는가 쪽에 더 가깝다.

특히 Telegram 같은 메신저 기반 진입점, 백그라운드 작업, 하위 작업 위임, 외부 네트워크, 장시간 실행이 섞이기 시작하면 실패는 거의 피할 수 없다. 문제는 실패 자체가 아니라, 실패했을 때 전체 흐름이 같이 무너지느냐다. 이 글에서는 운영 경험을 기준으로 실패 복구를 먼저 설계해야 하는 이유를 정리해 본다.

먼저 실제 운영 장면 두 개

실제로는 이런 식의 실패가 자주 나온다.

사례 1. 요청은 들어왔는데 실제 작업은 시작되지 않는 경우

Telegram으로 “오늘 올릴 글 초안 써줘” 같은 요청은 정상적으로 들어왔다. 사용자도 요청이 접수된 걸 봤다. 그런데 실제로는 뒤에서 세션 생성이나 작업 프로세스 시작이 실패해서 초안 작성은 아예 시작되지 않았다.

사용자 입장에서는 “분명 시켰는데 왜 아무 일도 안 일어나지?”가 된다. 이때 요청 수신과 실행 시작이 분리 기록되지 않으면, 운영자는 문제 지점을 바로 좁히기 어렵다.

사례 2. 작업은 끝났는데 사용자는 실패로 느끼는 경우

반대로 실제 초안 생성까지는 완료됐는데, 완료 메시지 송신이 실패해서 사용자는 결과를 받지 못하는 경우도 있다. 시스템 내부에서는 어느 정도 성공한 작업인데, 사용자 경험 기준으로는 실패다.

이럴 때 결과 생성과 결과 전달을 같은 단계로 취급하면, 나중에 장애를 복구할 때도 어디부터 다시 살려야 할지 헷갈리기 쉽다.

자동화는 잘될 때보다 실패할 때 본모습이 드러난다

데모 단계에서는 성공 경로만 봐도 된다. 입력이 들어오고, 모델이 잘 답하고, 툴이 문제 없이 실행되면 자동화는 꽤 그럴듯해 보인다.

하지만 실제 운영에서는 아래 같은 일이 자주 생긴다.

  • Telegram 메시지는 도착했는데 실제 작업이 시작되지 않음
  • 응답은 왔지만 백그라운드 프로세스가 중간에 죽음
  • 긴 작업이 끝나기 전에 세션이 꼬임
  • 외부 API 또는 네트워크 문제로 일부 단계만 실패함
  • 결과는 있었는데 사용자에게 전달되지 않음

이런 순간에는 모델의 답변 품질보다 복구 경로가 있는지가 훨씬 중요해진다.

실제로 자주 만나는 실패 유형

실무에서 많이 부딪히는 실패는 대체로 몇 가지 패턴으로 묶인다.

1. 입력은 받았는데 실행이 안 되는 경우

증상

  • 사용자는 요청을 보냈다
  • 시스템도 살아 있는 것처럼 보인다
  • 그런데 실제 작업은 시작되지 않는다

실제 원인 후보

  • 작업 라우팅 문제
  • 세션 생성 실패
  • 실행 프로세스 시작 실패
  • 권한/승인 단계 누락

복구 설계 포인트

  • 요청 수신과 실제 실행 시작을 분리해서 기록하기
  • “받음”과 “실행 중”을 같은 상태로 취급하지 않기
  • 어디 단계에서 멈췄는지 사용자에게 남기기

2. 중간까지는 갔는데 끝까지 못 가는 경우

증상

  • 파일 탐색이나 분석은 됨
  • 초안 생성이나 수정도 일부 진행됨
  • 그런데 최종 단계까지 못 감

실제 원인 후보

  • 하위 작업 중단
  • 세션 문맥 손실
  • 툴 실행 실패
  • 장시간 작업 중간 종료

복구 설계 포인트

  • 마지막 성공 단계가 남아 있어야 함
  • 부분 성공과 전체 성공을 구분해야 함
  • 실패 후 재시작 지점을 찾을 수 있어야 함

예를 들어 “초안 작성 완료 / 리뷰 미실행 / 커밋 미완료” 정도만 보여도 다음 액션이 훨씬 선명해진다.

3. 결과는 있었는데 전달이 안 되는 경우

증상

  • 내부 작업은 끝났다
  • 그런데 사용자는 결과를 받지 못했다
  • 겉으로는 실패처럼 보인다

실제 원인 후보

  • 메시지 송신 실패
  • 응답 타이밍 누락
  • 알림 채널 일시 장애
  • 완료 보고 전에 세션 종료

이건 모델 문제가 아니라 통신/전달 계층 문제다.

복구 설계 포인트

  • 결과물과 결과 전달을 분리해서 생각하기
  • 전달 실패 시 재시도 경로가 있어야 함
  • 사용자가 다시 확인할 수 있는 상태 경로가 있어야 함

4. 자동화가 조용히 멈추는 경우

증상

  • 큰 에러 메시지는 안 보인다
  • 어느 순간부터 그냥 아무 일도 일어나지 않는다
  • 사람이 직접 보기 전까지 멈춘 걸 모른다

실제 원인 후보

  • polling stall
  • 장시간 백그라운드 작업 중단
  • 내부 스케줄러 미동작
  • 네트워크 문제로 일부 기능만 정지

복구 설계 포인트

  • 외부 헬스체크
  • 재시작 전략
  • 마지막 정상 동작 시점 기록
  • 조용한 실패를 감지하는 watchdog

즉, “죽으면 로그에 남겠지” 수준으로는 부족하다.

실패 복구는 사후 대응이 아니라 설계 요소다

실패 복구를 보통은 나중 문제로 미루기 쉽다. 일단 돌아가게 만든 뒤, 나중에 장애가 생기면 그때 고치자는 식이다.

그런데 에이전트 자동화는 구조상 그 접근이 잘 안 맞는다. 이유는 실패 지점이 너무 다양하기 때문이다.

  • 모델 응답 실패
  • 툴 실행 실패
  • 파일 시스템 문제
  • 브라우저/네트워크 문제
  • 세션 꼬임
  • 메시지 전달 실패
  • 장시간 작업 중단

이 중 하나라도 복구 경로가 없으면 전체 체감 품질이 급격히 떨어진다. 그래서 실패 복구는 옵션이 아니라 처음부터 포함해야 하는 설계 항목에 가깝다.

상태를 남기라는 말은 이렇게 구체화할 수 있다

“상태를 남겨야 한다”는 말은 맞지만, 조금 더 내려가야 실제로 쓸 수 있다. 예를 들어 아래처럼 최소한의 상태 모델만 있어도 복구가 쉬워진다.

  • received: 요청 수신
  • accepted: 실행 가능 판단 완료
  • started: 실제 작업 시작
  • step_completed: 특정 단계 완료
  • result_ready: 결과 생성 완료
  • delivered: 사용자 전달 완료
  • delivery_failed: 결과는 있으나 전달 실패

이런 식으로 두면 같은 실패라도 해석이 달라진다.

예를 들어:

  • received에서 멈췄다면 라우팅이나 승인 문제를 먼저 보면 되고
  • started 이후 멈췄다면 실행기나 툴 문제를 보면 되고
  • result_ready인데 delivered가 아니라면 메시지 전달 계층을 먼저 보면 된다

즉, 실패 복구는 로그를 많이 남기는 문제가 아니라 어떤 단위로 상태를 남길지 설계하는 문제에 가깝다.

내가 보기엔 최소한 이 4가지는 있어야 한다

1. 상태를 단계별로 남겨야 한다

최소한 아래 정도는 남는 편이 좋다.

  • 요청 수신
  • 작업 시작
  • 마지막 성공 단계
  • 최종 완료 또는 실패

그래야 실패했을 때 “아예 안 됐는지”, “중간까지는 됐는지”, “결과만 전달이 안 됐는지”를 구분할 수 있다.

2. 긴 작업은 짧은 대화와 분리해야 한다

메신저 한 채팅창에서 긴 작업까지 다 처리하려고 하면 상태가 금방 흐려진다. 긴 작업은 별도 세션이나 하위 작업기로 분리하는 편이 낫다.

그래야:

  • 진행 상태를 따로 추적할 수 있고
  • 실패 원인도 좁히기 쉽고
  • 다시 시작할 지점도 찾기 쉽다

3. 결과 전달 실패를 별도로 다뤄야 한다

많은 자동화가 실행 자체만 성공하면 끝난 것으로 취급한다. 하지만 사용자는 결과를 받아야 성공으로 느낀다. 그래서 실행 성공과 전달 성공을 분리해서 봐야 한다.

예를 들어:

  • 작업 완료
  • 전달 대기
  • 전달 성공
  • 전달 실패 후 재시도

이렇게 나눠 보는 편이 실제 운영에서는 훨씬 낫다.

4. 외부 감시 경로가 필요하다

자동화 내부에서만 자신을 감시하게 두면, 핵심 프로세스가 멈췄을 때 같이 멈출 수 있다. 그래서 중요한 경로는 외부에서 한 번 더 보는 편이 안전하다.

예:

  • user-level systemd timer
  • healthcheck script
  • 마지막 응답 시간 확인
  • 송신 실패 누적 감지

이런 건 화려해 보이지 않지만 실제 운영 안정성에는 큰 차이를 만든다.

최소 운영 기준이 있어야 한다

개인 프로젝트라도 아래 정도는 있어야 장애가 났을 때 원인 파악이 너무 늦어지지 않는다.

  • 마지막 성공 단계가 남는다
  • 긴 작업은 별도 세션으로 분리된다
  • 결과 생성과 전달 성공이 구분된다
  • 내부 감시가 멈췄을 때 외부에서 한 번 더 잡아준다

이 정도만 있어도 “왜 안 됐는지 모르겠다”는 시간이 꽤 줄어든다.

실패 복구를 먼저 설계하면 좋아지는 것

이걸 넣는다고 자동화가 더 똑똑해지는 건 아니다. 대신 아래가 좋아진다.

  • 사용자가 시스템을 덜 불신하게 됨
  • “왜 안 됐는지 모르겠다” 시간이 줄어듦
  • 동일한 장애를 반복해서 겪을 확률이 줄어듦
  • 사람이 개입해야 할 시점을 더 빨리 알 수 있음
  • 긴 작업을 맡겨도 불안이 줄어듦

결국 사용자는 “가끔 똑똑한 시스템”보다 실패해도 상태를 알 수 있는 시스템을 더 신뢰하게 된다.

도입 전에 확인할 체크리스트

에이전트 자동화를 붙이기 전에 아래를 먼저 보면 좋다.

  1. 요청 수신과 실제 실행 시작을 구분해서 기록하는가
  2. 마지막 성공 단계가 남는가
  3. 긴 작업은 별도 세션이나 작업기로 분리되는가
  4. 실행 성공과 결과 전달 성공을 구분하는가
  5. 실패 시 사용자가 다시 확인할 상태 경로가 있는가
  6. 내부 감시가 멈췄을 때 외부에서 잡아줄 장치가 있는가
  7. 재시작 후에도 어디서부터 이어야 할지 판단할 수 있는가

이 중 몇 개만 빠져도 자동화는 잘 될 때만 그럴듯하고, 조금만 흔들리면 전체 신뢰가 무너지기 쉽다.

바로 적용할 최소 실천 3가지

처음부터 완벽한 장애 대응 체계를 만들 필요는 없다. 대신 아래 세 가지는 빨리 넣는 편이 좋다.

  1. 요청 수신과 실행 시작을 분리 기록하기
  2. 긴 작업은 채팅 응답 흐름과 분리하기
  3. 결과 생성과 전달 성공을 별도 상태로 관리하기

이 세 가지만 해도 실패가 났을 때 다음 액션이 훨씬 선명해진다.

마무리

에이전트 자동화에서 중요한 건 성공 장면을 예쁘게 만드는 것만이 아니다. 실패했을 때 어디서 멈췄는지 보이고, 다시 이어갈 수 있고, 사용자가 상황을 이해할 수 있어야 한다.

정리하면:

  • 실패는 피하기 어렵다
  • 문제는 실패 자체보다 복구 불가능한 실패다
  • 자동화 품질은 성공률만이 아니라 복구력으로도 평가해야 한다
  • 그래서 실패 복구는 나중 작업이 아니라 처음부터 설계에 포함해야 한다

AI 자동화를 붙일 생각이라면 “무엇을 자동화할까?” 다음 질문은 꼭 이것이어야 한다.

“실패하면 어디서부터 다시 살릴 건가?”

댓글남기기