주력 모델이 19일 동안 작동을 멈췄을 때, 당신의 워크플로(workflow)는 첫 한 시간 동안 실제로 무엇을 하나요? 조용히 실패하나요? 누군가 알아차릴 때까지 멈춰 있나요? 아니면 다른 곳으로 경로를 지정하여 계속 진행하나요?

이에 답할 수 없다면, 당신에게는 회복 탄력성(resilience posture)이 없는 것입니다. 당신에게 있는 것은 운뿐이며, 그 운은 방금 공개적으로 시험을 받았습니다.

Fable 5는 19일간의 수출 통제(export-control)로 인한 서비스 중단 이후 7월 1일에 전 세계적으로 복구되었습니다. 이번 주에 사후 분석(post-mortems) 결과들이 나오고 있는데, 대부분은 "복구되었다"와 "장애로 인한 비용은 이만큼이다"라는 두 가지 범주로 나뉩니다. MarketScale은 더 날카로운 통찰을 보여주었습니다. 단일 모델을 영구적인 인프라로 취급하는 팀들은 계속해서 당황하는 반면, 라우팅 맵(routing map), 예비 자원, 그리고 지정된 백업을 갖춘 팀들은 이 상황 전체를 화재가 아닌 차익 거래(arbitrage)의 기회로 취급했습니다.

서비스가 복구된 날 아침, 저는 제 자신의 설정을 살펴보았고 빈틈을 발견했습니다. 이것은 서비스가 복구된 후 제가 구축한 런북(runbook)입니다. 다음번의 혼란 속에서 작성하지 않도록 평온한 날에 작성했습니다. 이 중 어느 것도 프로젝트 매니저(PM)의 범위 확장(scope-creep)이 아닙니다. 이는 단일 복제본(single replica)에 있는 데이터베이스에 적용할 법한 것과 동일한 신뢰성(reliability) 사고방식입니다.

파트 1: 실제로 읽을 수 있는 라우팅 정책 (routing policy)

"우리는 Claude를 사용한다"는 라우팅 정책이 아닙니다. 그것은 아무도 투표하지 않은 기본값일 뿐입니다.

A 라우팅 정책은 명시된 지도입니다: 이 유형의 작업은 이 모델로 가고, 저 유형의 작업은 더 저렴하거나 빠른 모델로 갑니다. 대량 분류(Bulk classification)에는 가장 비싼 추론(reasoning) 단계가 필요하지 않습니다. 하지만 까다로운 다단계 에이전트 실행(multi-step agent run)에는 필요합니다. 대부분의 팀은 이 지도를 엔지니어 한 명의 머릿속에 담아두고 있는데, 이는 그 사람이 일주일 휴가를 가면 지도가 사라진다는 것을 의미하며, 모델 자체가 오프라인이 되는 상황에서는 확실히 살아남을 수 없음을 의미합니다.

머릿속에서 꺼내 파일로 만드세요:

# routing.yaml - 느낌(vibe)이 아닌 지도(map)
tasks:
  bulk_classify:
...

가치는 YAML 파일 그 자체에 있는 것이 아닙니다. "무엇이 어디서 실행되는가"가 이제 누군가의 기억 속에 있는 습관이 아니라 문서화된 결정이 되었다는 데 있습니다. 특정 작업 클래스의 주력 모델이 사라지면, 라우터(router)는 이미 작업을 어디로 보낼지 알고 있습니다. 새벽 2시에 아무도 즉흥적으로 대처할 필요가 없게 됩니다.

파트 2: Plan-banking, 당신의 찬장에 있는 통조림

정말로 중단되어서는 안 되는 워크플로(workflow)가 몇 가지 있습니다. 그런 것들을 위해서는 예비분을 확보해 두어야 합니다.

Plan-banking(플랜 뱅킹)이란 모델이 정상 작동하고 비용이 저렴할 때, 핵심 워크플로를 위한 계획(plans), 스캐폴드(scaffolds), 그리고 출력물(outputs)을 미리 생성해 두었다가, 모델을 사용할 수 없을 때 그 저장소(bank)에서 꺼내 쓰는 것을 의미합니다. 여름에 채소를 통조림으로 만들어 두어 2월의 폭풍우가 닥쳐도 빈 접시가 되지 않도록 하는 것과 같습니다. 평온한 날에는 예약된 작업(scheduled job)과 약간의 저장 공간 비용만 들 뿐입니다. 하지만 19일간의 블랙아웃(blackout) 상황에서는 이것이 "예비분을 사용했다"와 "추후 통보가 있을 때까지 차단되었다" 사이의 차이를 만듭니다.

저는 아주 단순하게 유지합니다:

# nightly: 중단될 수 없는 워크플로를 위해 신선한 계획을 뱅킹함
for wf in onboarding_flow release_notes triage_playbook; do
  generate_plan "$wf" > "bank/${wf}.$(date +%F).json"
...

제가 처음에 빠졌던 함정은 모든 것을 뱅킹하는 것이었습니다. 일 년에 두 번 실행되는 워크플로를 위해 예비분을 둘 필요는 없습니다. 실제로 타격이 클 두세 가지만 뱅킹하고, 나머지는 실패를 명확히 드러내도록(fail loudly) 두십시오.

파트 3: 실제로 테스트를 마친 두 번째 소스

모든 핵심 유스케이스(use case)에 대해, 구체적인 폴백 모델(fallback model)을 지정하십시오. 그런 다음, 실제로 필요해지기 전에 해당 작업에 대해 모델이 작동함을 증명하십시오.

이 지점이 Fable의 중단 사태가 구체화된 부분입니다. 이름이 지정되고 테스트를 마친 두 번째 소스를 가진 팀들은 몇 시간 만에 경로를 재설정(rerouted)했습니다. "어떻게든 해결해 보겠다"라고 말한 팀들은 실제 몇 주를 허비했습니다. 그리고 올해는 "실행 가능한 대안이 없다"라는 말이 더 이상 정당한 변명이 되지 못했는데, 선택지(menu)가 매우 다양해졌기 때문입니다. Sonnet 5는 6월 30일에 백만 토큰당 $2/$10의 가격으로 가장 에이전트적인(agentic) Sonnet으로서 출시되었으며, 이제 백업 모델은 원래 백업하던 대상보다 더 저렴하고 더 유능합니다. Gemini 3.5 Pro도 7월 출시를 앞두고 있습니다. 대안은 이미 존재합니다.

사람들이 건너뛰는 부분은 테스트입니다. 실제 프롬프트(prompts)에 대해 한 번도 실행해 보지 않은 폴백(fallback)은 헬멧을 쓴 추측에 불과합니다. 주간 카나리(canary)를 연결하십시오:

# canary.yaml - 백업 모델이 여전히 우리의 기준을 통과하는가?
second_source_check:
  schedule: weekly
...

만약 두 번째 소스(second source)가 당신의 기준치 아래로 조용히 미끄러진다면, 당신은 그것을 장애가 발생한 한복판이 아니라 평온한 목요일에 알게 되기를 원할 것입니다.

놓치기 쉬운 부분

한 줄 정도의 가치가 있는 지정학적 변수가 있습니다. Fable의 수출 라이선스를 취소했던 바로 그 정부가, 이제는 경쟁사의 지분 5%를 제안받고 있습니다. 다음에 어떤 모델이 제한될지는 예측할 수 없지만, 헤지(hedge, 위험 분산)할 수는 있습니다. 그리고 하나 이상의 벤더(vendor)를 아우르는 라우팅 정책(routing policy)이 바로 그 헤지 수단입니다.

제 생각을 가장 많이 변화시킨 지점은 이것입니다. 이 세 가지 조치 중 어느 것도 비용이 많이 들지 않습니다. 평온한 날에는 모두 저렴하지만, 패닉 상태에서는 완전히 불가능하며, 바로 그 점 때문에 이 조치들은 생략되곤 합니다. 실제로 상황이 닥치기 전까지는, 당신에게 이를 강요하는 화재(위기)는 결코 발생하지 않습니다. 19일간의 중단 사태는 새로운 리스크를 만들어낸 것이 아닙니다. 그저 결정을 내리지 않음으로써 내렸던 결정에 대한 청구서를 모두에게 발송했을 뿐입니다.

그래서 댓글로 솔직하게 질문을 하나 던지겠습니다. 이 세 가지 파트 중, 당신의 팀은 현재 실제로 문서화해 둔 것이 무엇인가요? "준비할 수 있다"가 아니라, 오늘 당장 문서로 작성되어 있는 것 말입니다. 제가 먼저 답하겠습니다. 저의 라우팅 맵(routing map)은 탄탄했지만, 저의 두 번째 소스 카나리(second-source canary)는 지난주 전까지 존재하지 않았습니다.

Tags: #AI