LLM API가 멈췄을 때, 이미 접수한 고객 업무는 어떻게 이어갈까

접수, 답변 생성, 외부 실행, 완료를 구분한다

가상의 온라인 판매사에서 고객이 배송지 변경을 문의합니다. 접수 시스템에 문의 번호가 생겼지만 LLM API는 응답하지 않습니다. 이때 화면에서 응답이 없었다며 다시 접수하도록 안내하면, 같은 문의가 AI와 상담원에게 함께 배정될 수 있습니다. 이미 문의를 저장했다면 접수번호와 다음 확인 시점을 보여주고, 해당 기록으로 사람이 이어받을 수 있게 해야 합니다.

접수 단계는 요청을 영속적으로 저장하고 고객이 다시 찾을 수 있는 번호를 발급합니다. 생성 단계는 근거 조회와 답변·조치 초안 준비까지만 진행합니다. 실행 단계는 승인·발송·상태 변경처럼 외부에 효과가 생기는 작업입니다. 완료 단계에서는 업무 기준을 충족한 실제 결과를 확인합니다. 외부 변경이 필요한 업무라면 답변 생성에 성공해도 아직 완료로 셀 수 없습니다.

같은 ‘AI 오류’ 화면이라도 접수 전에 저장이 실패했는지, 접수 후 응답 생성이 실패했는지에 따라 다음 행동이 달라집니다. 고객은 다시 접수해야 하는지, 이미 받은 번호로 진행 상황을 확인할 수 있는지 알아야 합니다. 지원팀에는 실패 시 고객이 다시 진입할 수 있는 경로가 필요합니다. Google PAIR의 오류와 실패 이후 사용자 경로^[1]

장애 중에도 이어갈 업무를 정한다

업무 책임자는 고객이 이미 약속받은 기한, 지연 피해, 확인할 데이터와 실행 효과를 기준으로 경로를 나눕니다. 공지의 공개 내용 문의는 검증된 정적 링크를 제공할 수 있습니다. 개인 주문의 상태는 권한 확인과 주문 원장 조회가 필요합니다. 배송지 변경은 물류 마감 시간을 확인하고 현재 주문 변경 가능 여부를 승인된 시스템에서 판정해야 합니다. 앱이 내부 조회와 LLM 호출을 반드시 한 요청으로 거쳐야 하는 구조라면, 모델이 멈출 때 살릴 수 있는 업무부터 설계를 바꿉니다.

사람이 받을 수 있는 업무량도 기록합니다. AI 경로 전체를 상담원에게 넘겨 업무를 계속하는 방안은 사람에게 남은 시간과 일감이 있어야 작동합니다. 기한이 임박한 변경과 계정 피해 가능성이 있는 요청을 먼저 배정하고 가벼운 안내는 검증된 자료로 유도합니다. 큐에 넣은 접수는 담당자가 운영 좌석에서 그 기록을 찾을 수 있어야 합니다.

실패 유형별 대기·재시도·대체·이관 결정표

아래는 하나의 업무 처리기가 사용할 수 있는 예시입니다. 실제 오류 번호와 재시도 조건은 이용하는 API 계약을 대조합니다. 응답 코드만으로 실행이 확정됐는지 판단하기 어려운 외부 변경에는 해당 서비스의 상태 조회 및 대사 경로가 필요합니다.

RFC 6585의 429는 일정 기간에 요청이 너무 많다는 의미이며 서버가 재요청까지의 시간 안내를 제공할 수 있습니다. RFC 9110은 Retry-After 값 형식을 설명합니다. 운영자는 공급자의 한도 범위와 오류 본문을 확인해 일시적 속도 제한, 장기간 할당량 소진, 별도 과금 설정 문제를 구분합니다. 안내 구현을 점검하면서 업무 만료 시각을 넘긴 재시도는 예약하지 않습니다. IETF RFC 6585^[2] · IETF RFC 9110^[3]

제한된 재시도와 관찰 가능한 대기열

재시도에는 작업당 시도 수, 시도별 타임아웃, 전체 만료를 둡니다. 애플리케이션, SDK, 프록시, 워커가 각각 재시도하면 한 요청이 예상보다 많은 공급자 호출로 늘어납니다. 예를 들어 두 계층이 최초 호출을 포함해 각자 최대 세 번 시도하면, 조건에 따라 최대 아홉 번의 호출이 생길 수 있습니다. 재시도를 맡는 계층을 정하고 간격을 점차 늘리면서 분산해 동시 재호출을 줄입니다. AWS의 타임아웃과 백오프 설명^[4]

대기열에서는 전체 길이와 함께 가장 오래된 적격 업무의 나이, 기한이 임박한 건, 재시도 예약, 재배정되지 않은 담당자 없음 상태를 봅니다. 새로운 접수를 무제한 받는 대신 서비스가 감당할 수 있는 양과 지연에 맞춰 입구에서 대기 또는 추후 이용을 안내할 수 있습니다. 이때 이미 접수한 요청을 새로 들어오는 요청과 분리합니다. 큐에서 뺄 때 현재 주문·승인 상태와 만료 조건을 다시 읽습니다. 접수 당시 유효했던 배송지 변경 정책이 시간이 흐른 뒤에도 그대로 적용된다고 가정하면 이미 출발한 상품에 변경을 요청할 수도 있습니다.

대체 모델도 품질과 데이터 처리를 시험한다

대체 모델에는 허용 데이터 등급과 지역, 보관 조건, 계약 범위, 사용할 도구 권한을 미리 정합니다. 주 모델의 장애가 확인됐다는 이유만으로 원래 승인 범위를 넘겨 다른 제공자에게 상담 원문을 보내서는 안 됩니다. 두 공급자 모두 같은 지역을 제공하는지 묻는 것에 그치지 않고, 실제 사용하는 기능의 입력·로그·첨부 처리 범위를 확인합니다. 경쟁 공급자가 같은 상위 인프라 또는 신원 공급자를 사용한다면 공통 장애경로도 있을 수 있습니다.

출력과 업무 결과는 대표 사례로 검증합니다. 대체 모델이 동일한 JSON 모양을 만들더라도 배송 날짜에 조건을 붙이는지, 권한 없는 주문을 거부하는지, 요청을 완료할 수 없을 때 인계하는지 시험해야 합니다. 검색 도구와 프롬프트를 같이 바꾸는 경우에는 어떤 조합을 검증했는지 보존합니다. 환경의 응답 품질과 시스템 상태를 꾸준히 관측하는 접근은 Google Cloud의 생성형 AI 운영 가이드^[5]에서도 설명합니다.

검증 범위가 제한된 대체 모델은 공개 안내 요약이나 담당자 초안처럼 승인된 일만 맡길 수 있습니다. 민감 업무를 사람에게 넘길 경우에는 모델이 이전에 제안한 조치와 실제 실행한 조치를 분리하여 전달합니다. 주 모델에서 외부 작업을 이미 실행했다면 대체 모델의 처음부터 재생이 중복을 일으킬 수 있습니다. 외부 쓰기의 재시도는 실행 계약에 따라 결과 확인과 별도로 결정합니다. AWS의 멱등 API 설계^[6]

상담원에게 접수번호와 작업 소유권을 넘긴다

앞의 가상 배송지 변경 문의에서 화면은 ‘접수됐습니다. 접수번호 CS-014로 확인할 수도 있습니다’라고 알려줍니다. 고객이 약속된 시간 전까지 AI 답변을 못 받으면 동일한 문의가 상담원 큐에 올라갑니다. 상담원에게 기존 접수번호, 고객이 요청한 범위, 확인된 주문 상태, 마지막 생성 또는 실행 상태, 남은 기한을 전달합니다. 상담원은 마감 시간 전인지 확인하고 적절한 절차를 이어갑니다.

AI 워커가 다시 활성화될 때도 상담원이 인수한 작업에 새 답변을 보내지 않도록 소유권이나 처리가 끝났는지 확인합니다. 가상의 시험에서는 상담원이 배정을 받기 직전과 직후에 모델 응답을 전달해 화면과 외부 실행이 한 경로에서만 완료되는지 봅니다. 배송 변경 승인이 필요한 작동 경로는 조건이 충족됐다는 증거를 별도로 남깁니다.

공급자 복구 뒤에는 쌓인 업무를 대사한다

공급자 상태 페이지가 회복돼도 우리 시스템의 접수·생성·실행 기록을 다시 확인합니다. 대기 중인 문의는 업무 기한과 위험을 확인해 다시 배정합니다. 상담원이 이미 끝낸 요청은 완료로 연결하고 다시 실행하지 않습니다. 외부 작업 결과가 불명인 요청은 성공 증거, 거절 증거 또는 담당자 이관을 정리합니다. 이전 모델을 다시 쓰기 전에 대표 입력과 오류 경로에서 현재 배포 설정이 맞는지 점검합니다.

복구에서는 이용 가능한 한도를 먼저 확인하고 일정 물량을 단계적으로 흘리며 지연과 오류를 관찰합니다. 새 문의를 처리할 여력을 남겨야 기존 대기가 해소되는 동안 새로운 장애를 만들지 않습니다. 보고서에는 장애 시간 외에 접수된 업무 수, 기한 내 완료율, 대기열의 최대 나이, 상담원에게 넘겼다가 완료된 수, 외부 결과 미확인과 중복을 기록합니다. 사용자 결과 중심의 운영 판단에는 SLO와 에러 버짓 정책의 기간·분모 기준을 가져올 수 있습니다.

공통 장애 운영 흐름은 장애 대응 런북에, 공급자·운영 대행·제품팀의 작업별 책임은 MSP 장애 대응 책임에 정리돼 있습니다. LLM 장애를 훈련할 때에는 고객 접수번호로 누가 어디서 이어가며 어떤 결과를 증명할지까지 확인합니다.