#왜 모델 강등 전략을 만들어야 하는가

강등 전략이 묻는 것은 시스템이 비용, 품질, 안정성 세 가지 사이에서 통제 가능한 취사선택을 할 수 있는가이며, 모델 강등은 결코 아무 저렴한 모델로 대충 갈아 끼우는 것이 아니라 「작업 리스크 평가 → 수용 가능한 대체 경로 선택」이다.

핵심 판단 기준은 호출 사슬 기준이 아니라 리스크 기준으로 강등하는 것이다. 잡담, 카피 다듬기, 포맷 변환은 소형 모델로 폴백해도 되지만, 계약 해석·의료 조언·재무 승인 같은 고위험 작업은 차라리 「잠시 후 재시도하거나 사람으로 전환」을 안내할지언정 소형 모델이 억지로 답하게 하면 안 된다.

#주 모델을 쓸 수 없게 되는 네 가지 원인

원인	성질
레이트 리밋	할당량/속도 제한
타임아웃	지연이 예산 초과
서비스 장애	상류 이용 불가
비용 임계 도달	능동적 서킷브레이크이지 수동적 장애가 아님

#세 가지 기본 강등 방식

#	강등 유형	에서	으로
첫 번째	모델 강등	강한 모델	경량 모델
두 번째	능력 강등	자동 완료	초안이나 제안만 제공
세 번째	플로우 강등	모델이 직접 답변	자료 검색 / 템플릿 응답 / 사람 처리

#호출 사슬이 아니라 리스크 기준으로 강등

작업 유형	예시	강등 전략
저위험	잡담, 카피 다듬기, 포맷 변환	경량 모델로 폴백 가능
고위험	계약 해석, 의료 조언, 재무 승인	주 모델을 못 쓸 때 소형 모델이 억지로 답하게 하지 말고, 잠시 후 재시도나 사람 전환을 안내

#정리

대모델 애플리케이션이 강등 전략을 만드는 것은 주 모델을 쓸 수 없을 때 서비스 연속성을 유지하기 위함이지만, 강등은 반드시 작업 리스크, 출력 유형, 사용자 기대에 따라 설계해야 한다. 상용에서는 모델 강등, 능력 강등, 플로우 강등을 구분하고 강등 경로와 복구 상태를 기록해야 한다.

#핵심 통찰

1. 강등의 본질은 「통제 가능한 취사선택」이지 「가용성 사수」가 아니다 — 가용성만 말하면 그것을 이진 목표로 여기는 것이다. 비용/품질/안정성의 3자 가중치로 말해야 강등에 대가가 있고 그 대가를 설계할 수 있음을 안다는 뜻이다.
2. 「경계 없는 강등이 강등하지 않는 것보다 위험하다」가 가장 반직관적인 지점이다 — 강등하지 않으면 그냥 실패이고 사용자는 실패했음을 안다. 함부로 강등하면 정상처럼 보이는 오답을 산출하고 사용자는 그것이 신뢰할 수 없다는 것을 모른다. 조용한 품질 저하가 명시적 장애보다 처치하기 어렵다.
3. 리스크 기준 강등 vs 호출 사슬 기준 강등이 아키텍처 성숙도의 분수령이다 — 대부분 시스템의 강등은 기술 토폴로지에서 출발한다(이 서비스가 죽었으니 예비로 전환). 성숙한 방식은 업무 결과에서 출발한다(이 작업은 틀리면 배상해야 하니 차라리 답하지 않는다). 같은 장애라도 작업이 다르면 다른 강등 경로를 타야 한다.
4. 세 가지 강등이 가벼운 것에서 무거운 것으로 가는 사다리를 구성한다 — 모델 강등(실행자 교체) → 능력 강등(납품 기준 하향) → 플로우 강등(AI 경로에서 이탈). 설계 시 사다리를 따라 단계적으로 내려가야지 한 번에 맨 아래로 뛰어내리면 안 된다.
5. 「비용 임계 발동」은 강등이 장애 처리만이 아님을 드러낸다 — 레이트 리밋/타임아웃/서비스 장애는 수동적이고 비용 임계는 능동적이다. 즉 강등은 동시에 비용 거버넌스 수단이기도 하며, 예산이 소진되기 전에 능동적으로 저가 경로로 전환할 수 있다.
6. 식별 가능성이 강등의 합법성 전제다 — 사용자가 모르는 강등은 본질적으로 일종의 오도다. 「완전한 답변 / 간략 답변 / 임시 제안」을 명시적 상태로 만드는 것은 사용자를 보호하는 동시에 시스템을 만든 사람도 보호한다(「문제가 생겼을 때 설명하기 어렵다」는 것이 바로 이 얘기다).
7. 강등 경로는 관측 가능해야 최적화할 수 있다 — 「이번 요청이 어떤 강등 경로를 탔는지」 기록해야 「우리 트래픽의 몇 퍼센트가 저품질 경로에 있는가」, 「어떤 강등 분기가 가장 자주 발동되는가」 같은 질문에 답할 수 있다.
8. 복구 메커니즘이 가장 자주 누락되는 절반이다 — 서킷브레이커는 쓰기 쉽고 복구는 쓰기 어렵다. 복구 탐지와 회귀 로직이 없으면 한 번의 짧은 흔들림으로 시스템이 영구히 강등 상태에 못 박히는데, 모니터링상으로는 모든 것이 「정상」으로 보인다.
9. 고위험 작업의 올바른 강등은 「답변 거부 + 사람 전환」이지 「저품질 답변」이 아니다 — 계약, 의료, 재무 이 세 장면에는 공통점이 있다: 오답의 대가가 무답의 대가보다 훨씬 크다. 판단 기준은 이것이어야지 「답을 낼 수 있는가」가 아니다.

#엔지니어링 실전 Tips

• 작업 유형마다 「리스크 등급」 라벨을 붙이고 강등 전략이 라벨 조회에서 도출되게 할 것. 호출 사슬의 catch 분기에 하드코딩하지 말 것.
• 비용 임계를 능동 강등 발동 트리거로 만들 것: 예산 소비가 80%에 도달하면 자동으로 경량 모델로 전환하는 편이, 월말에 갑자기 전 라인이 불가용해지는 것보다 낫다.
• 강등 상태는 반드시 응답 바디에 담을 것: 예를 들어 {answer, quality_level: "degraded", degrade_path: "model_fallback"}을 반환해야 프런트엔드가 안내 배너를 표시할 근거를 갖는다.
• 프런트엔드에 시각적 구분이 있어야 한다: 간략 답변이나 임시 제안에는 명확한 표식이 있어야 하며 정상 답변과 똑같이 생기면 안 된다.
• 복구는 정시가 아니라 프로브로 할 것: 주 모델이 복구되면 먼저 소량 트래픽으로 시험하고 안정성을 확인한 뒤 전량 회귀시켜 흔들림 때문에 왔다 갔다 전환되는 것을 피할 것.
• 강등 경로에 계측을 붙여 모니터링할 것: 강등 발동률, 각 경로 비중, 강등 기간의 사용자 만족도/재시도율은 모두 장기 관측이 필요한 지표다.
• 고위험 장면은 자동 강등을 기본 차단할 것: 「강등 허용」을 블랙리스트가 아니라 화이트리스트로 만들어, 새로 접속한 고위험 기능이 기본 정책에 오폭당하지 않게 할 것.
• 강등도 훈련(drill)해야 한다: 능동적으로 주 모델 연결을 끊고 강등 경로와 복구 경로가 정말 동작하는지 검증할 것. 절대다수의 강등 코드는 한 번도 실제로 실행된 적이 없다.