사용자의 애플리케이션은 정상입니다. 데이터베이스도 응답하고 있습니다. 대시보드는 초록색입니다. 사용자가 AI 비서에게 질문을 던지지만, 아무런 답변이 돌아오지 않습니다.
이는 시스템의 다른 부분이 완벽하게 작동할 수 있기 때문에 어색한 종류의 서비스 중단입니다. 모델 서비스가 느리거나, 속도 제한(rate limited)에 걸렸거나, 이용 불가능하거나, 아니면 그럴듯하게 들리지만 틀린 답변을 반환할 수도 있습니다. 사용자 관점에서 볼 때, 기능은 어느 쪽이든 실패한 것입니다.
저는 재고 및 이행 운영(inventory and fulfillment operations)을 지원하는 시스템의 신뢰성(reliability) 작업을 합니다. 한 AI 지원 조사 프로젝트에서 목표는 사용자가 모든 쿼리를 엔지니어가 작성하는 것에 의존하기보다 자연어를 통해 불일치점을 탐색할 수 있도록 돕는 것이었습니다. 그러한 인터페이스는 복잡한 데이터를 훨씬 쉽게 사용할 수 있게 만듭니다. 또한 질문을 하는 사람과 그들이 봐야 할 증거 사이에 의존성을 추가합니다.
따라서 복원력에 대한 질문은 단순히 '모델이 다운되면 어떻게 될까?'보다 더 큽니다. 그것은 모델이 도움을 줄 수 없을 때 사용자가 여전히 안전하게 무엇을 할 수 있는가입니다.
LLM은 오프라인 상태가 아니어도 실패할 수 있습니다.
전통적인 서비스 장애는 종종 상당히 명확합니다. 요청이 시간 초과되거나, 연결이 끊기거나, 서버가 오류를 반환하는 식입니다. LLM의 실패에는 이러한 사례들이 포함되며, 발견하기 더 어려운 몇 가지 사례들도 포함됩니다.
요청은 성공할 수 있지만 유용해지기까지 너무 오래 걸릴 수도 있습니다. 속도 제한은 여러 팀이 동시에 바쁠 때만 나타날 수도 있습니다. 모델 변경은 비서가 도구를 선택하거나 익숙한 질문을 해석하는 방식을 바꿀 수 있습니다. 그리고 답변은 원본 데이터가 보여주는 것을 잘못 진술하면서 유창할 수 있습니다.
마지막 사례는 비즈니스 워크플로우에서 가장 중요합니다. 누군가가 재고 수가 두 위치에 걸쳐 왜 다른지 묻는 상황을 상상해 보십시오. 만약 비서가 필요한 데이터 소스에 접근할 수 없다면, 세련된 설명은 조사가 불완전하다는 명확한 진술보다 더 나쁠 수 있습니다. 사용자는 그것에 따라 행동할 수 있기 때문입니다.
따라서 시스템은 여러 가지 결과를 구별할 필요가 있습니다. AI가 사용 불가능한 경우, AI의 응답이 느린 경우, 필요한 데이터가 사용 불가능한 경우, 그리고 AI가 생성했지만 검증할 수 없는 답변을 내놓은 경우입니다. 이 네 가지를 모두 일반적인 '다시 시도' 오류로 처리하면 사용자들은 혼란스러워합니다.
모델에게 허용되는 행동 결정하기
첫 번째 복원력(resilience) 결정은 장애가 발생하기 전에 이루어집니다. 이는 모델과 애플리케이션의 나머지 부분 사이의 경계입니다.
좁은 조사 워크플로우의 경우, 저는 어시스턴트에게 무제한적인 쿼리를 생성하도록 허용하는 것보다 승인된 소수의 작업(operations)을 부여하는 것이 더 낫다고 생각합니다. 한 작업은 항목의 이동 경로를 추적할 수 있습니다. 다른 작업은 불일치 요약 정보를 검색할 수 있습니다. 각각은 정의된 입력, 접근 권한, 그리고 제한 사항을 가질 수 있습니다.
이것은 정상적인 작동 중에도 도움이 되지만, 실패가 발생했을 때 격리하기 더 쉽게 만듭니다. 모델이 요청을 오해하더라도 애플리케이션이 허용하는 작업 중에서만 선택할 수 있습니다. 도구(tool)에 문제가 생기면, 애플리케이션은 어떤 부분이 조사에서 누락되었는지 알게 됩니다. 모델은 데이터를 임의로 만들거나 더 강력한 도구를 호출하여 보상할 수 없어야 합니다.
같은 원칙이 행동(actions)에도 적용됩니다. 기록을 읽는 것과 하나를 변경하는 것은 위험도가 다른 수준입니다. 어시스턴트는 이상 징후를 설명하는 데 도움을 줄 수 있지만, 무언가를 변경해야 하는지 여부는 별도의 규칙이나 인간의 승인이 결정해야 합니다. 제공업체(provider) 장애가 시스템이 이 경계를 건너뛰게 해서는 안 됩니다.
각 실패에 의도적인 폴백(fallback) 마련하기
'다른 모델 사용'은 복원력 전략처럼 들리지만, 그것은 가능한 폴백 중 하나일 뿐입니다. 두 번째 제공업체는 다른 동작 방식, 권한, 데이터 처리 요구 사항 및 비용을 가질 수 있습니다. 자동으로 전환하는 것은 아무도 결과적인 답변들을 테스트하지 않았다면 새로운 실패 모드를 만들 수 있습니다.
사용자의 작업부터 고려해야 합니다. AI가 일반적으로 검증된 질의 결과를 요약하는 기능을 수행하는데 모델이 사용 불가능할 경우, 애플리케이션은 해당 결과를 구조화된 뷰로 여전히 표시할 수 있어야 합니다. 만약 AI가 질문을 몇 가지 알려진 조사 중 하나로 라우팅(route)하는 역할을 한다면, 인터페이스는 사용자에게 직접 조사를 선택하도록 할 수 있습니다.
두 옵션 모두 불가능한 경우, 가장 적절한 폴백(fallback)은 명확하게 멈추는 것일 수 있습니다. 예를 들어, “분석 서비스가 사용 불가능하여 이 조사를 완료할 수 없습니다. 결론이 도출되지 않았습니다.”와 같이 표시하는 것입니다. 요청을 보존하여 사용자에게 재시도할 기회를 줄 수는 있지만, 이전 답변을 새로운 것처럼 제시해서는 안 됩니다.
규칙은 간단합니다. 진실(truth)을 훼손하기 전에 경험(experience)을 저하시키세요. 검증된 데이터에 도달하는 과정이 불편하더라도 유용합니다. 지원되지 않는 결론에 이르기까지 매끄러운 경로는 그렇지 않습니다.
전체 요청에 시간 예산(time budget)을 설정하세요.
타임아웃(Timeouts)은 한 서비스씩 추가하기는 쉽지만, 전체 워크플로우(workflow)에 걸쳐 잘못 구현하기는 놀라울 정도로 쉽습니다.
예를 들어, 어떤 조사가 데이터를 검색하고, 모델에게 해석을 요청하며, 결과를 형식화해야 한다고 가정해 봅시다. 만약 모든 단계가 관대한 타임아웃 시간을 갖게 된다면, 사용자는 제품이 합리적으로 지원할 수 있는 시간보다 훨씬 오래 기다릴 수도 있습니다. 재시도는 특히 모델 제공업체(model provider)가 이미 과부하 상태일 때 그 지연을 더욱 늘릴 수 있습니다.
먼저 전체 요청 마감 기한(overall request deadline)을 설정하세요. 그런 다음 데이터 검색, 모델 처리, 응답에 걸쳐 시간을 할당합니다. 재시도는 남은 예산 내에서 이루어져야 하며, 백오프(backoff)를 사용하고, 실패가 일시적일 가능성이 있을 때만 발생해야 합니다. 마감 기한이 도달하면 인터페이스가 계속 로딩 상태로 남아 있게 하는 대신, 가장 안전하게 이용 가능한 결과를 반환하세요.
헬스 체크(Health checks) 역시 비슷한 주의가 필요합니다. 실행 중인 애플리케이션 컨테이너는 모델 의존적인 조사가 완료될 수 있는지에 대해 거의 알려주지 못합니다. 사용자 작업에 중요한 종속성(dependencies)을 모니터링하고, 느리거나 속도 제한이 걸린(rate-limited) 모델과 실패하는 데이터 소스를 구별해야 합니다. 이 두 조건은 서로 다른 대응책을 요구하기 때문입니다.
단순히 최종 결과만 보는 것이 아니라 조사 과정 자체를 관찰해야 합니다.
'요청 실패(request failed)'라는 단일 지표로는 엔지니어가 모델이 시간 초과되었는지, 잘못된 도구를 선택했는지, 불완전한 데이터를 받았는지, 아니면 애플리케이션에서 거부하는 답변을 반환했는지를 알 수 없습니다.
AI 지원 조사의 경우, 유용한 추적(trace)은 요청의 경로를 기록할 수 있습니다. 어떤 유형의 조사가 선택되었는지, 승인된 도구 중 어떤 것이 실행되었는지, 그것들이 성공했는지 여부, 각 단계가 얼마나 오래 걸렸는지, 그리고 최종 답변에 충분한 증거가 있었는지를 알 수 있습니다. 이러한 원격 측정(telemetry) 데이터에 대한 접근은 통제되어야 하며, 특히 요청에 민감한 비즈니스 데이터를 포함할 수 있는 경우 더욱 그렇습니다.
또한 시스템이 폴백(fallback)을 사용하는 비율도 관찰해야 합니다. 모델 호출 실패로 인해 구조화된 결과가 갑자기 더 자주 나타난다면, 애플리케이션은 사용 가능한 것처럼 보일지라도 핵심 경험은 저하되었을 수 있습니다. 사용자들은 단순한 가동 시간 차트보다 먼저 이를 알아차릴 것입니다.
이것이 AI의 신뢰성이 성공적인 HTTP 응답만으로는 측정될 수 없는 이유 중 하나입니다. 기술적으로 성공했지만 지원되지 않는 답변을 제공하는 요청은 실제 임무에 실패한 것입니다.
출시 전에 최악의 날을 테스트하세요
디자인 문서에만 존재하는 폴백은 폴백이 아닙니다. 이는 공급자가 느리거나, 속도 제한(rate limit)이 소진되거나, 도구가 불완전한 데이터를 반환할 때 작동해야 합니다.
AI 기능을 비즈니스 중요 워크플로우로 확장하기 전에, 의도적으로 그러한 조건을 만드는 테스트를 실행해야 합니다. 모델 응답을 지연시키고, 공급자 오류를 강제하고, 허용된 도구 중 하나의 접근을 제거합니다. 어시스턴트에게 모호한 결과를 제공하여 불확실성을 인정하는지 확인하세요. 테스트 환경에서 모델 버전을 변경하고 고정된 대표 질문 세트에 대한 도구 선택과 답변을 비교해 보세요.
이러한 테스트는 애플리케이션이 작동하는지 여부뿐만 아니라 사용자가 무엇을 보는지까지 검토해야 합니다. 그들은 조사가 불완전하다는 것을 알 수 있습니까? 여전히 검증된 데이터에 도달할 수 있습니까? 지원 증거가 누락되었을 때 어떤 행동이 차단됩니까?
제가 작업한 인벤토리 조사 프로젝트에 대한 공식적인 평가와 거버넌스는 여전히 성숙시켜야 할 영역입니다. 그 구분이 중요합니다. 더 안전한 워크플로우를 설계하는 것은 유용한 시작점이지만, 그것의 신뢰성에 대해 주장할 수 있는 내용은 실제로 테스트한 내용과 일치해야 합니다.
복원력 설계를 적절하게 유지하세요
추가적인 프로바이더(provider), 캐시(cache), 재시도 경로(retry path), 그리고 폴백 인터페이스(fallback interface)는 비용과 복잡성을 추가합니다. 움직이는 부품이 많을수록 팀이 그것들을 자신 있게 운영할 수 없다면 더 많은 사고를 유발할 수 있습니다.
올바른 설계는 실패의 결과에 달려 있습니다. 선택적인 작성 제안은 짧은 타임아웃(timeout)과 친근한 오류 메시지만 필요할 수 있습니다. 운영 조사(operational investigation)를 지원하는 어시스턴트는 데이터 접근, 증거, 불확실성 주변에 더 강력한 통제가 필요합니다. 프로덕션 리소스(production resources)를 변경할 수 있는 시스템은 여전히 더 엄격한 제한이 필요합니다.
저는 복잡성 예산(complexity budget)을 가장 중요한 실패 모드에 사용해야 한다고 생각합니다: 검증된 데이터 접근성을 유지하고, 지원되지 않는 결론을 방지하며, AI가 안전하지 않은 행동을 취하는 것을 보장하는 것입니다. 테스트를 통해 그것이 운영상의 부담을 정당화할 만큼 결과 개선을 보여줄 때만 두 번째 모델 프로바이더를 추가하세요.
목표는 LLM 의존성을 눈에 띄지 않게 만드는 것이 아닙니다. 사용자는 AI 기능이 일시적으로 사용할 수 없다는 솔직한 메시지를 처리할 수 있습니다. 그들이 안전하게 처리할 수 없는 것은 증거, 도구 또는 모델에 실패했을 때 확실해 보이는 시스템입니다.