점심시간에 뉴스를 쫓다 보니, Claude Fable 5가 복구되었다는 소식이 흘러나왔습니다.

"고성능 모델이 부활했다"로 끝내고 싶지만, 업무에서 AI를 사용하는 입장에서 유효한 것은 그 부분이 아닙니다. 제가 주목해야 한다고 생각한 점은, 6월 12일에 중단되었다가 7월 1일에 복구되었으며, 심지어 7월 7일까지는 일부 플랜에서 주간 상한(weekly limit)의 최대 50%까지라는 조건이 붙었다는 점입니다.

즉, AI 모델은 기능표뿐만 아니라 "오늘 사용할 수 있는가", "상한이 있는가", "대체 수단이 있는가"까지 확인하지 않으면 현장의 자동화(automation)에組み込む(組み込む, 포함시킬) 수 없습니다.

이 기사에서는 API를 호출하기 전 단계에 두는 작은 대장 체크를 Python으로 만듭니다. 모델이 갑자기 중단되거나, 상한이 있는 상태로 복구되었을 때 어떤 업무가 위험한지를 미리 찾아내기 위한 것입니다.

Guardian은 Fable 5가 2주 이상의 중단 후에 고객용 액세스를 복구했다고 보도했습니다. Business Insider는 Pro / Max / Team / 일부 Enterprise에서는 7월 7일까지 주간 상한의 최대 50%까지 사용할 수 있으며, 그 이후에는 usage credit 방식으로 전환된다고 설명하고 있습니다.

이 뉴스에서 가져와야 할 실무 포인트는 모델의 우열이 아닙니다.

"어제까지 사용할 수 없었던 모델이 오늘부터 조건부로 복구된다"는 점입니다. 바로 이 부분입니다.

예를 들어 경쟁사 조사 요약, 상담 메모 정형화, 문의 답장 초안 작성 등. 이런 업무들은 모델명을 코드에 직접 작성(hard-coding)해 두면 상류의 상황을 그대로 받게 됩니다. 사람의 눈에는 "평소의 자동화가 갑자기 느려짐", "상한에 걸림", "품질이 변함"으로 보입니다.

이것이 은근히 큰 영향을 미칩니다. 장애 대응처럼 거창한 시스템을 만들지 않더라도, 업무별로 주 모델(primary model), 대체 모델(alternative model), 상한 조건을 하나의 표로 만들어 두는 것만으로도 당황하는 정도가 상당히 달라집니다.

처음부터 거창한 관리 화면은 필요 없습니다. CSV로 충분합니다.

모델 측 대장에는 최소한 다음과 같은 열(column)을 갖춥니다.

열	예	확인 이유
model	Fable 5	코드나 절차서와 대조한다
...

업무 측 대장에는 주 모델과 대체 모델을 갖춥니다.

열	예
workflow	경쟁사 요금 페이지 차이 요약
...

이 그림으로 보면, 해야 할 일은 "뉴스를 읽는 것"이 아니라 "업무별 분기(branching)를 결정하는 것"입니다.

아래 코드는 두 개의 CSV를 읽어 오늘 시점에서 위험한 업무를 WARN으로 표시합니다. 외부 라이브러리는 사용하지 않습니다.

import csv
from io import StringIO
from datetime import date, datetime
...

직접 실행해 보니 다음과 같이 나왔습니다.

| 업무 | 판정 | 메모 |
| --- | --- | --- |
| 경쟁사 요금 페이지 차이 요약 | WARN | 2026-07-07까지 주간 상한 50%枠(枠, 범위). 초과 시 Sonnet 5로 전환 |
...

오늘 이것을 실행해 보며 생각보다 중요했던 것은 disabled만 보는 것이 아니었습니다. 복구되었음에도 WARN이 되는 케이스가 있습니다. Fable 5처럼 "복구되었지만 상한이 있는" 상태는 현장에서 오히려 놓치기 쉽습니다.

이 체크는 모델을 사용할 수 있는지 여부만을 보고 있습니다. 실운용에서는 한 단계 더 나아갑니다.

첫 번째는 대체 모델로 전환했을 때의 품질 차이입니다. 경쟁사 요금 페이지 차이 요약이라면 조금 짧아지는 정도로 끝날지도 모릅니다. 계약 문구 리뷰나 장애 보고 요약이라면, 대체 모델로 넘기기 전에 사람의 확인을 거치는 것이 좋습니다. 그래서 criticality(중요도)를 넣어둡니다.

두 번째는 상한 소비가 업무 단위로는 보이지 않는다는 점입니다. 주간 상한 50%라고 적혀 있어도, 영업부 전원이 동일한 범위를 사용하는지, 사용자별인지, 계약별인지에 따라 대책이 달라집니다. 이 부분은 각사의 계약 조건을 확인하여 자사의 대장에 "누구의 범위인가"라는 열을 하나 추가하는 것이 현실적입니다.

저라면 처음에는 스프레드시트(Spreadsheet)로 관리하겠습니다. 정보 시스템(IT) 부서나 개발 부서만 보는 대장으로 만들면, 영업 기획 측에서 "어떤 작업을 중단해도 되는지" 판단할 수 없기 때문입니다. WARN이 나온 업무만 아침 회의(morning meeting)에서 확인합니다. 그 정도의 가벼움이면 충분히 운영 가능합니다.

Fable 5 복구 뉴스는 AI의 성능 경쟁으로 읽기보다, 상류 모델의 가용성(availability)이 업무 플로우(workflow)에 들어온 사례로 읽는 것이 실무에 도움이 됩니다. 강력한 모델을 사용할수록 중단, 상한, 라우팅(routing) 변경의 영향도 커집니다.

우선 모델 이름을 코드에 직접 작성(hard-coding)하고 있는 업무를 3가지만 골라내어, 주 모델(primary model)과 대체 모델(alternative model)을 작성합니다. 그다음, 사용량 제한이 있는 모델을 WARN 상태로 설정합니다. 여기까지는 30분이면 할 수 있습니다. 고기능 모니터링을 구축하기에 앞서, 이 작은 대장을 마련해 두세요. 모델이 복구된 날 당황하지 않기 위한 가장 저렴한 보험입니다.