AI 에이전트 도입 시 장애 복구 아키텍처를 요구사항 단계에서 설계해야 하는 이유

AI 에이전트 도입을 검토할 때, 팀이 가장 먼저 따지는 것은 대체로 응답 속도와 모델 품질이다. 그런데 도입 이후 실제로 팀을 괴롭히는 문제는 다른 곳에서 온다. 에이전트가 긴 작업을 실행하던 중 서버가 죽거나 프로세스가 중단되면, 진행했던 작업을 어디서부터 다시 시작해야 하는가.

이 질문에 답이 없으면 에이전트는 처음부터 다시 돌아간다. 비용이 두 배로 들거나, 같은 외부 호출이 두 번 발생하거나, 이미 완료된 작업이 의도치 않게 반복된다. 이런 상황은 아키텍처 설계가 늦어서 생기는 문제가 아니다. 애초에 요구사항 단계에서 이 문제를 다루지 않았기 때문에 생긴다.

왜 "응답 속도"는 나중 문제인가

짧고 단순한 요청에는 장애 복구 설계가 크게 중요하지 않다. 실패하면 다시 요청하면 그만이다. 하지만 AI 에이전트가 실제로 유용해지는 상황, 즉 파일을 수정하고, API를 호출하고, 여러 단계를 거쳐 결과를 만드는 작업에서는 이야기가 달라진다.

중간 단계까지 외부 효과가 발생한 상태에서 에이전트가 죽으면, 재시도는 안전하지 않다. 파일이 이미 생성됐을 수도 있고, API 호출이 이미 완료됐을 수도 있다. 다시 돌리면 같은 작업이 두 번 실행된다. 이걸 막으려면 에이전트가 "어디까지 했는지"를 어딘가에 기록해두어야 한다. 그 기록 방식이 바로 상태 유지(state persistence) 아키텍처의 핵심이다.

문제는, 이 결정이 구현 단계에서는 이미 늦다는 점이다. 작업 단위를 어떻게 나눌지, 어떤 작업을 체크포인트로 처리할지, 재시도 시 어떤 조건에서 건너뛸지. 이 세 가지는 에이전트의 실행 모델 자체를 바꾸기 때문에, 개발이 시작된 뒤에 끼워 넣기 어렵다.

요구사항 단계에서 정해야 할 세 가지 경계

작업 단위를 어떻게 나눌 것인가

에이전트의 한 "턴(turn)"이 무엇을 의미하는지 먼저 정의해야 한다. 사용자 입력부터 최종 응답까지를 하나의 단위로 볼 것인지, 그 안에서 모델 호출과 도구 호출을 각각 독립된 단위로 볼 것인지에 따라 복구 전략이 완전히 달라진다.

단위가 너무 크면 장애 발생 시 많은 작업을 다시 해야 한다. 단위가 너무 작으면 체크포인트 저장 비용이 증가하고 복잡도가 올라간다. 어느 쪽으로 설계할지는 팀의 인프라 비용, 에이전트가 다루는 작업의 평균 길이, 외부 시스템 호출 빈도에 따라 달라진다. 이 결정은 나중에 바꾸기 어려우므로 요구사항 단계에서 명시적으로 논의해야 한다.

어떤 상태를 어디에 저장할 것인가

에이전트가 대화 이력, 작업 파일, 도구 호출 결과를 어디에 저장하는지가 복구 가능 여부를 결정한다. 세 가지 저장 대상 각각에 대해 요구사항 단계에서 다음 질문에 답해야 한다.

• 대화 이력: 특정 프로세스나 서버에 묶여 있는가, 아니면 어느 실행 주체든 접근할 수 있는 공유 저장소에 있는가.
• 작업 파일: 에이전트가 편집한 파일이 다른 실행 주체에게 전달될 수 있는가. 전달 방식은 무엇인가.
• 도구 호출 결과: 호출이 완료됐는지, 시작만 됐는지, 결과가 아직 기록되지 않은 상태인지를 구별할 수 있는가.

세 번째 항목이 가장 까다롭다. 외부 호출의 결과는 "성공", "실패" 외에 "알 수 없음" 상태가 존재한다. 명령이 실행을 시작했지만 결과가 저장되기 전에 프로세스가 죽으면, 재시도 시 그 명령이 실제로 효과를 냈는지 알 방법이 없다. 이 상황을 어떻게 처리할지를 요구사항 문서에 명시해야 한다.

재시도 시 무엇을 건너뛰고 무엇을 다시 할 것인가

모든 단계를 자동으로 재시도하면 안전하지 않다. 반대로 모든 단계를 수동 승인으로 처리하면 에이전트를 쓰는 의미가 없어진다.

재시도 안전성은 해당 작업이 멱등(idempotent)한가로 판단한다. 같은 작업을 두 번 실행해도 결과가 동일하면 자동 재시도가 안전하다. 그렇지 않으면 사전에 상태를 확인하거나, 결과가 불확실하다는 신호를 에이전트에게 전달해야 한다. 이 분류 작업은 개발자가 코드를 짜면서 할 수 없다. 어떤 도구 호출이 멱등하고 어떤 것이 아닌지를 제품팀이 도메인 지식을 바탕으로 사전에 목록으로 만들어야 한다.

구현 전에 검증해야 할 조건

요구사항이 정해졌다면, 구현에 들어가기 전 다음 조건을 확인해야 한다.

장애 시나리오 테스트 계획이 있는가. 에이전트가 작업 도중 죽는 상황을 의도적으로 만들어 복구가 실제로 작동하는지 확인하는 절차가 있어야 한다. 이 테스트를 개발 후반에 추가하면 설계 변경이 필요한 문제를 뒤늦게 발견하게 된다. Temporal 팀이 pi-temporal 프로젝트에서 매 15~40초마다 실행 중인 워커를 강제로 종료하는 카오스 테스트를 도입한 것은 이 이유에서다. 실제 장애를 재현하지 않으면 복구 설계가 제대로 작동하는지 확인할 수 없다.

결과 불확실 상태를 에이전트가 처리할 수 있는가. 에이전트가 "이 작업의 결과를 알 수 없다"는 신호를 받았을 때 현재 상태를 먼저 확인하고 판단할 수 있어야 한다. 이 동작이 프롬프트 설계에 반영되어 있는지, 그리고 에이전트가 실제로 그 신호에 맞게 행동하는지를 테스트해야 한다.

공유 저장소의 동시 접근 방식이 결정됐는가. 여러 실행 주체가 같은 저장소에 접근할 때 충돌 처리 방식이 명확해야 한다. 저장소 선택은 이 동시 접근 요건을 먼저 확인하고 결정해야 한다.

운영 단계에서 추가로 확인해야 할 것

장애 복구 아키텍처는 배포로 끝나지 않는다. 운영 중에 다음 두 가지를 주기적으로 확인해야 한다.

첫째, 복구된 작업이 원래 의도한 결과를 만들었는지 추적하는 방법이 있는가. 복구는 됐지만 작업이 부분적으로 두 번 실행된 상황을 뒤늦게 발견하는 경우가 생긴다. 이를 감지하는 로그나 감사 추적이 없으면 오류를 운영 중에 인지하기 어렵다.

둘째, 재시도 횟수와 복구 지연이 비용 추정치 안에 있는가. 복구 과정에서 모델 호출이 추가로 발생한다. 이 비용이 예상 범위 안에 있는지 모니터링하지 않으면 예산 초과가 조용히 누적된다.

요구사항 문서에 지금 당장 추가해야 할 항목

AI 에이전트 도입을 탐색 중이라면, 요구사항 단계 문서에 아래 항목을 명시적으로 포함시키는 것을 권한다.

• 에이전트 작업 단위의 정의와 최대 실행 시간
• 대화 이력, 작업 파일, 도구 호출 결과 각각의 저장 위치와 접근 방식
• 멱등 도구 호출 목록과 그렇지 않은 도구 호출의 처리 방침
• 결과 불확실 상태의 정의와 에이전트 동작 명세
• 장애 시나리오 테스트 계획과 실행 시점

이 중 하나라도 "구현하면서 정하겠다"고 미루면, 나중에 그 결정이 이미 작성된 코드와 충돌하는 상황을 만나게 된다. 그 시점에서의 수정은 처음부터 다시 설계하는 것과 크게 다르지 않다.

AI 에이전트의 실질적인 신뢰성은 모델 성능이 아니라 장애 상황에서 작업 상태를 어떻게 다루느냐로 결정된다. 그 결정은 요구사항 문서에서 시작한다.