AI 서비스가 특정 모델 하나에만 의존하면 그 모델의 오류나 지연이 곧 업무 중단으로 이어집니다. 예비 모델을 연결하는 것만으로는 복구가 끝나지 않습니다. 성능과 권한, 출력 형식이 다른 모델로 무엇을 계속 제공할지 먼저 정해야 합니다.
기능별로 허용되는 저하를 나눈다
문장 요약은 품질이 조금 낮아져도 계속 제공할 수 있지만 계약 조항 추출이나 자동 실행은 다른 모델에서 그대로 유지하기 어려울 수 있습니다. 기능을 정상 제공, 검토 후 제공, 읽기 전용, 중단으로 나누고 조건을 정의합니다.
장애 시 모든 요청을 가장 비싼 예비 모델로 보내면 비용과 사용량 제한이 동시에 문제가 될 수 있습니다. 우선순위가 높은 업무를 먼저 살리고 큐 대기와 제한을 사용자에게 보여 줍니다.
모델 전환은 출력 계약을 지켜야 한다
모델마다 구조화 출력, 도구 호출, 문맥 길이, 언어 성능이 다를 수 있습니다. 예비 모델의 응답을 동일한 스키마 검증과 업무 규칙 검증에 통과시킵니다. 이름만 바꿔 호출하는 방식은 조용한 데이터 오류를 만들 수 있습니다.
예비 모델에서 지원하지 않는 기능은 명확히 비활성화합니다. 프런트엔드가 정상 모드의 기능을 그대로 보여 주면 사용자가 저장할 수 없는 작업을 시작할 수 있습니다. 장애 모드도 사용자 경험의 한 상태입니다.
전환 기준을 측정한다
단일 요청의 시간 초과만으로 전체 트래픽을 즉시 전환하면 일시적인 지연이 연쇄 전환을 일으킬 수 있습니다. 오류율, 지연 분포, 지역별 장애와 회복 시간을 함께 보고 회로 차단과 재시도 정책을 정합니다.
재시도는 이미 실행된 도구 호출과 분리해야 합니다. 모델 응답을 다시 생성하는 일과 고객에게 같은 메시지를 두 번 보내는 일은 다릅니다. 외부 부작용이 있는 단계에는 멱등성을 적용합니다.
가상 사례: 분류 기능은 유지하고 발송은 멈춘다
고객 문의 분류 모델이 장애로 전환된 상황을 가정해 봅시다. 예비 모델의 분류 결과는 사람이 검토하도록 큐에 넣고, 답변 자동 발송은 잠시 멈출 수 있습니다. 업무 전체를 닫지 않으면서 잘못된 발송 위험을 줄이는 선택입니다.
복구 후 대기 중인 건을 한꺼번에 자동 처리하지 않습니다. 장애 기간의 모델과 검토 상태를 기록하고 정상 모드로 돌아갈 때 중복 처리를 확인합니다. 이 사례는 특정 서비스의 실제 운영 사례가 아닙니다.
예비 경로도 평소에 시험한다
전환 경로를 문서에만 두면 인증 키 만료나 스키마 차이를 장애 때 처음 발견합니다. 소량의 비운영 트래픽으로 주기적으로 확인하고 개인정보 전송 범위와 보관 정책도 점검합니다.
운영 지표에는 모델별 오류와 비용, 전환 원인, 기능별 저하 상태를 남깁니다. 사용자에게 약속한 품질과 실제 장애 모드의 차이도 설명해야 합니다. 좋은 복구는 모든 기능을 억지로 유지하기보다 안전하게 남길 기능을 정하는 일입니다.
현장에 적용할 때의 순서
- 기능별 정상·저하·중단 모드를 문서화한다
- 예비 모델로 실제 스키마를 검증한다
- 복구 뒤 대기 작업의 중복을 확인한다
주의할 실패: 모델만 전환하고 발송·결제 도구까지 그대로 열면 예비 경로의 낮은 품질이 외부 상태를 바꿀 수 있다.
관찰할 지표: 모델별 오류율과 기능별 저하 상태를 별도로 관찰한다.
적용 전 체크리스트
- 기능별 장애 모드가 정의돼 있는가
- 예비 모델도 스키마·권한 검증을 통과하는가
- 전환과 복구 때 외부 작업 중복을 막는가
참고 자료
NIST AI Risk Management Framework. AI 위험 관리의 상위 원칙을 참고했습니다. 모델 폴백과 기능 저하 단계는 본문에서 제안하는 시스템 설계입니다.
이미지와 도식은 이해를 돕기 위한 개념 시각화입니다. 특정 고객의 실제 설비·데이터·화면을 재현한 것이 아닙니다.
#AI운영 #모델장애 #폴백설계 #LLMOps #서비스복구 #추론API #업무연속성 #도구호출 #비용관리 #기업AI
