SPKE를 위해 AI로 생성한 독창적인 편집용 일러스트. 개념을 표현한 비유이며, 설계도나 실측 결과가 아니다.
도착하지 않은 확인 응답
교환 상품의 배송을 준비하는 가상의 고객 지원 어시스턴트를 생각해 보자. 애플리케이션이 승인된 배송 요청을 보냈지만, 확인 응답이 도착하기 전에 연결이 끊긴다. 복구 절차는 다른 모델로 전환해 대화 내용을 넘기고 작업을 마치라고 요청한다. 예비 모델은 성공 메시지가 없으므로 배송을 다시 요청하자고 제안한다.
첫 번째 배송은 이미 등록되어 있을 수 있다. 자연스러운 복구 메시지가 중복 작업을 가릴 수도 있다. 위험한 지점은 애플리케이션이 다시 실행하기로 결정하는 단계이지, 어느 모델이 어느 나라에서 나왔느냐가 아니다.
미국과 중국의 AI 서비스를 함께 사용하는 팀이라면, 여기서 유용한 검수 질문을 얻을 수 있다. 장애 전환 후 시스템은 실제로 무슨 일이 일어났는지 확인할 수 있는가? 두 번째 제공업체는 생성을 위한 다른 경로를 추가한다. 그러나 주변 워크플로의 상태까지 자동으로 보존해 주지는 않는다.
요청 형식뿐 아니라 동작을 비교하자
세 가지 1차 자료가 경계를 파악하는 데 도움이 된다. 현재 OpenAI Python SDK 문서는 일부 요청 실패에 대해 기본적으로 두 번 자동 재시도하며 재시도 설정을 변경할 수 있다고 설명한다. 반면, 수신 중 중단된 스트림의 처리는 자동 재시도하지 않는다. 공식 SDK
DeepSeek은 계정 단위의 동시 연결 제한과, 대기 중인 연결을 유지하기 위한 빈 줄 또는 SSE 주석을 설명한다. 문서에 명시된 10분 후 연결 종료는 추론이 아직 시작되지 않았을 때 적용되며, 모든 작업에 공통으로 적용되는 마감 시간이 아니다. 요청 제한과 격리
AWS의 멱등 API 설명은 그 바탕에 있는 분산 시스템 문제를 짚는다. 응답이 없으면 완료 여부가 불확실해질 수 있으며, 안전한 재시도에는 서비스가 보장하는 동작 규약이 필요하다. 안전한 재시도 설계
이는 2026년 10월 26일 확인한 문서상의 사실이지, 새로운 장애 보고나 신뢰성 비교 시험 결과가 아니다. 각 자료는 SDK 동작, 제공업체의 연결 처리, 업무 서비스의 처리 의미라는 서로 다른 계층을 다룬다. 어느 것도 임의의 AI 도구를 안전하게 반복 실행할 수 있다고 보장하지 않는다.
제공업체를 조합하기 전에 정확한 엔드포인트, 모델과 SDK 버전, 지원하는 입력 및 도구 형식, 재시도 설정, 타임아웃 동작, 데이터 처리 허용 범위를 기록하자. 익숙한 요청 형식만으로는 충분하지 않다. 동일한 문서를 예비 제공업체에 보내도 되는지도 확인해야 한다. 공급업체를 바꾸면서 기밀 데이터를 받는 대상이 조용히 늘어나서는 안 된다.
시도와 업무 작업을 분리하자
우리가 제안하는 복구 설계는 두 종류의 기록에서 출발한다. ‘시도’ 기록에는 개별 모델 요청의 제공업체, 모델, 시작 시각, 결과, 확보한 요청 식별자를 남긴다. ‘업무 작업’ 기록에는 사용자가 승인한 행위의 목적, 정확히 승인된 매개변수, 상태, 완료 증거를 남긴다. 여러 시도가 하나의 업무 작업을 지원할 수 있다.
가상의 배송 사례에서는 다른 모델이 인계받아도 업무 작업의 동일성이 유지되어야 한다. 새로 생성된 도구 호출 식별자를 두 번째 배송을 생성할 권한으로 취급해서는 안 된다. 반대로, 내용은 같아도 별도로 승인된 두 건의 배송은 구분할 수 있어야 한다.
업무 작업 상태는 대화 밖에서 관리하자. 모델은 기록을 요약할 수 있지만, 실행기는 행동하기 전에 기록을 확인해야 한다. 이 확인과 실행권 확보를 원자적으로 처리해, 동시에 동작하는 주 작업자와 예비 작업자가 모두 실행에 나서지 못하게 하자. 최소한의 유용한 상태로는 계획됨, 제출됨, 확인됨, 거부됨, 결과 불명을 둘 수 있다. 결과 불명은 담당자와 해결 절차가 있는 정식 상태다. 재시도 루프를 단순하게 만든다는 이유만으로 이를 실패로 바꿔서는 안 된다.
대상 서비스가 멱등성 메커니즘을 제공한다면 문서에 명시된 적용 범위, 매개변수 규칙, 보존 기간을 따라야 한다. 로컬 식별자만으로 원격 서비스의 효과를 멱등하게 만들 수는 없다. 충분한 서비스 보장이나 신뢰할 수 있는 결과 대조 절차가 없다면, 정확히 한 번 실행된다고 약속하기보다 결과가 불확실한 쓰기 작업을 보류해 검토해야 한다.
실패한 경계에 맞춰 복구하자
복구 경로를 세 가지로 나누자.
생성만 수행한 경우. 실패한 단계가 텍스트 초안 작성뿐이고 업무 작업을 아직 제출하지 않았다면, 허용된 시간과 비용 예산 안에서 다른 모델이 대체 출력을 생성할 수 있다. 부분 출력과 대체 출력은 분리해 두자. 서로 맞지 않는 두 답변을 조용히 이어 붙여 하나의 연속된 결과처럼 보여서는 안 된다.
거부가 확인된 경우. 업무 서비스가 작업을 적용하지 않고 거부했다는 사실을 신뢰할 수 있는 증거로 확인했다면, 다음에 승인된 시도를 하기 전에 원인을 해결해야 한다. 잘못된 대상이나 권한 부족은 더 순응적인 모델을 고른다고 해결되지 않는다.
쓰기 결과가 불확실한 경우. 작업은 제출했지만 확인 응답이 없다면, 이용 가능한 경우 대상 서비스의 공식 작업 기록을 조회하자. 완료가 확인되면 기록된 결과를 사용한다. 결과가 여전히 확정되지 않았다면 그 불확실성을 알리고 해당 작업의 자동 쓰기를 중단한다. 조회에 반영되기까지 지연이 있을 수 있다면, 빈 검색 결과가 반드시 미실행의 증거는 아니다.
예비 모델은 무엇이 보류 중인지 설명하거나 검토용 초안을 준비할 수 있다. 그러나 확인 사실을 꾸며 내거나, 승인의 의미를 다시 해석하거나, 결과 불명인 배송이 일어나지 않았다고 단정해서는 안 된다.
복구 전체에 하나의 예산을 적용하자
재시도는 유용할 수 있지만, 독립적인 계층들이 각각 재시도하면 횟수가 곱해질 수 있다. 가령 애플리케이션이 세 번 시도하고 각 시도마다 SDK의 세 번 시도를 허용하는 가상의 구성에서는, 추가적인 제공업체 전환 전에도 요청이 아홉 건 발생할 수 있다. 이는 명시한 구성에 대한 산술 계산이지, 실제 SDK 실행 기록이나 모든 구성에 통용되는 상한이 아니다.
전체 마감 시간, 시도 횟수 예산, 에스컬레이션 정책을 책임질 구성 요소를 하나 정하자. 최상위 작업만이 아니라 실제 하위 계층의 시도 횟수를 센다. 서비스의 재시도 지침을 따르고 적절한 대기 간격을 적용하며, 과부하가 걸린 대기열을 예비 제공업체에 즉시 그대로 다시 보내지 않도록 하자. 계정 단위 제한을 피하려고 새 인증 정보를 사용해서는 안 된다.
사용 가능한 답변을 얻는 데 걸린 시간과 실제 작업의 완료를 확인하는 데 걸린 시간을 따로 측정하자. 연결 유지 신호는 연결이 활동 중임을 보여 줄 뿐, 작업 진행을 뜻하지 않는다. 마찬가지로 사용자 화면의 타임아웃은 원격 작업이 취소되었다는 증거가 아니다. 복구 설계는 뒤늦게 도착하는 결과를 고려해, 그것이 또 다른 실행을 유발하지 않도록 해야 한다.
실제 고객에게 영향을 주기 전에 확인 응답 유실을 시험하자
외부 작업을 모의 실행하는 샌드박스를 사용하자. 시험 전에 기대 결과를 작성한다. 최소한 다음 사례를 다뤄야 한다.
- 업무 작업을 제출하기 전에 생성 요청이 실패한다.
- 대상 서비스가 작업을 적용했지만 응답이 유실된다.
- 예비 모델이 이미 답변한 뒤에 주 모델이 완료된다.
- 텍스트 일부가 표시된 뒤 스트림이 중단된다.
- 예비 모델이 이미 승인된 작업의 매개변수를 바꾸자고 제안한다.
- 대상 서비스의 조회 인터페이스에 작업이 잠시 나타나지 않는다.
- 복구 전에 대상 서비스의 중복 제거 기간이 만료된다.
각 사례에서는 어시스턴트의 마지막 문장만 볼 것이 아니라 외부에서 발생한 효과와 작업 기록을 확인하자. 확인 응답이 유실된 경우라면, 한 건의 작업 완료를 확인하거나 미해결 상태임을 명시하고 보류하는 것이 허용 가능한 결과일 수 있다. 두 번째 배송은 성공적인 복구가 아니다. 거짓 성공 메시지도 마찬가지다.
완료율과 함께 중복 효과, 미해결 작업, 복구 시간을 보고하자. 분모는 원래 사용자가 요청한 작업 수로 유지한다. 재시도는 시도이지, 추가로 성공한 작업이 아니다. 검토 업무량과 제공업체 비용도 기록해야 한다. 모든 것을 보류하는 설계가 손쉽게 자동화를 제공하는 것처럼 보여서는 안 된다.
두 번째 제공업체로 무엇을 얻어야 하나
유용한 예비 경로는 원래 작업의 제약을 유지하면서 완료할 기회를 한 번 더 제공한다. 초안 작성이라면 대체 답변이 될 수 있다. 외부 효과가 있는 워크플로라면 무엇이 확인되었고, 무엇이 아직 불명이며, 다음에 무엇을 해야 하는지 믿을 만하게 설명하는 것이 될 수 있다.
중요한 결과를 낳는 작업 하나와 통제된 확인 응답 유실 시험 하나부터 시작하자. 중복이나 꾸며 낸 확신 없이 그 상황을 복구할 수 없다면, 모델을 더 추가해도 워크플로가 믿을 만해지기 전에 경로도부터 복잡해질 뿐이다.
이 글은 링크한 1차 자료를 바탕으로 한 SPKE의 독창적인 엔지니어링 분석이다. 배송 시나리오, 제안한 상태 모델, 시험 계획은 설명을 위한 예시다. 제공업체 벤치마크, 운영 시스템에 대한 장애 주입, 신뢰성 향상 측정은 수행하지 않았다. 도입 전에 최신 문서와 실제 사용하는 도구의 보장 규약을 확인해야 한다.