6월, Claude Fable 5가 공개된 지 불과 3일 만에 서비스가 중단되었습니다. 7월 1일에 복구되었지만, 그 3일 동안 제 생각은 바뀌었습니다. 모델의 공급 중단은 장애가 아니라 「소실」입니다. 몇 시간 내에 돌아올 것이라는 전제는 통하지 않습니다.

저는 당시 Opus와 Fable 5의 용도 구분(使い分け)을 검토하며 비용 계산까지 하고 있던 입장이었기에, 비교 대상 자체가 사라지는 것을 목격했습니다. 본격적으로 사용하기 전이었기에 실질적인 피해는 거의 제로였습니다. 하지만 만약 실제 운영 워크플로우(Workflow)가 Fable 5를 전제로 하고 있었다면 어땠을까 생각하니 소름이 돋았습니다.

그래서 제 코드와 운영 방식에서 「특정 모델 전제」를 찾아냈습니다. 발견된 NG 사례 5가지를 해결 방법과 함께 나열합니다.

• 모델 ID를 코드에 직접 작성(Hard-coding)한다
• 비용 계산을 하나의 모델 전제로만 구성한다
• 품질 판정을 「모델의 평판」에 의존한다
• 프롬프트(Prompt)를 특정 모델의 습성에 너무 맞춘다
• 롤백(Rollback) 절차를 준비해두지 않는다

가장 빈번하며, 찾아내는 데 가장 번거로운 유형입니다.

// ❌ NG: 호출 지점마다 모델 ID를 직접 작성
$response = $client->messages(['model' => 'claude-fable-5', ...]);
// 다른 파일에서도
...

// ✅ OK: 참조를 한 곳으로 모은다
// config.php
define('MYPLUGIN_MODEL_MAIN', getenv('MYPLUGIN_MODEL') ?: 'claude-opus-4-8');
...

이유: 직접 작성한 코드가 여기저기 흩어져 있으면, 모델이 사라진 날 grep으로 모든 곳을 찾아내어 수정해야 합니다. 참조를 한 곳(상수, 설정, 환경 변수)에 모아두면 교체는 단 한 줄로 끝납니다. 저의 경우, 이 정리는 수십 분 만에 끝났습니다. 일이 터지기 전에 하느냐, 터지고 나서 당황하며 하느냐의 차이일 뿐입니다.

❌ NG: 「Fable 5라면 이 구성이 최저가」라고까지 확정하여, 그것만 보유
(전제 모델이 사라지면, 계산 자체도 사라짐)

✅ OK: 제1 후보 + 롤백 대상을, 느슨한 복선(Multiple paths)으로 보유
・제1 후보: Fable 5로 월 약 X 원
・롤백 대상: Opus 4.8로 월 약 Y 원 (1.n배)
...

이유: 단가가 다른 모델로 갑자기 전환되면, 월 비용은 말도 없이 치솟습니다. 정밀하게 최적화된 단일 계획은 전제가 사라지는 순간 제로가 됩니다. 대략적인 수치라도 좋으니 롤백 대상의 숫자까지 가지고 있으면, 모델이 사라진 날 「얼마나 늘어날지」 즉시 대답할 수 있습니다. 솔직히 계산을 정밀하게 맞추는 것은 즐거운 일이라 복선(Multiple paths)을 두는 것이 조금 아쉽지만, 즐거움과 견고함은 별개의 문제입니다.

❌ NG: 「새 모델은 벤치마크가 높으니까 괜찮겠지」라며 전환
(자신의 태스크에서 동일한 수준이 나올지는 별개의 문제)

✅ OK: 자신의 태스크에 대한 합격 기준을 직접 보유
・대표적인 입력과 기대하는 출력 쌍을 몇 건, 파일로 만들어 둔다
・전환했다면, 우선 그것을 실행하여 비교한다
...

이유: 모델을 전환했을 때 가장 무서운 것은 「조용히 품질이 떨어지는 것」입니다. 세상의 평판은 자신의 태스크를 보장해주지 않습니다. 판정의 축(사양, 테스트, 샘플 쌍)을 자신 쪽에서 가지고 있으면, 모델은 교체 가능한 부품이 됩니다. 축을 모델 쪽에 두면, 전환할 때마다 감각으로 다시 측정해야 하는 상황에 빠지게 됩니다.

❌ NG: 암묵적인 동작에 의존한 생략투의 지시
이 모델은 이렇게 쓰면 알아서 이해하니까, 짧게 이것만 작성.

✅ OK: 어떤 모델에서도 통하는 명시적인 지시로 전환
・전제, 제약, 출력 형식을 생략 없이 작성한다
・「눈치껏」 처리하도록 맡겼던 부분을 조건으로 문장화한다

이유: 특정 모델의 「눈치(察し)」에 최적화된 생략형 프롬프트는, 전환하는 순간 정밀도가 무너집니다. 명시적으로 작성된 프롬프트는 모델이 바뀌어도 성능 저하가 완만합니다. 튜닝 자체는 나쁘지 않습니다. 다만, 무엇을 생략하고 무엇에 의존하고 있는지를 스스로 파악하지 못하는 상태가 위험한 것입니다. 한 번쯤 생략 없는 버전을 정석으로 남겨두면 안심할 수 있습니다.

❌ NG: 「사라지면 그때 생각하자」
(사라진 날은, 생각할 여유가 가장 없는 날입니다)

✅ OK: 롤백 절차를 평상시에 한 장 써둔다
・롤백 대상 모델: (이름)
・변경 사항: config.php의 한 줄 (NG1을 수정해 두었다면, 여기가 한 줄로 끝남)
...

이유: 1~4번을 수정해 두었다면, 롤백은 「한 줄 바꾸고, 샘플을 실행하고, 비용을 메모로 확인」하는 것으로 끝납니다. 절차서라고 해도 몇 줄 되지 않습니다. 이 절차가 있느냐 없느냐에 따라, 모델이 사라진 날의 침착함이 완전히 달라집니다.

• 모델 ID는 한 곳에. 교체 시 한 줄만 수정하면 되도록 구성한다
• 비용은 제1후보 + 롤백(Rollback) 대상의 복선 구조로. 대략적이어도 괜찮다
• 합격 기준(테스트·샘플 쌍)은 자신 측에서 보유한다
• 프롬프트는 명시적으로. 특정 모델의 '눈치(察し)'에 의존하지 않는다
• 롤백(Rollback) 절차를 평상시에 몇 줄 적어둔다

3일 만에 사라지고, 3주 만에 돌아온다. 프론티어 모델(Frontier Model)은 이러한 변동성 자체와 함께 가는 것이 되었습니다. 모델에 반하는 것은 즐거운 일이며, 앞으로도 그럴 것이라 생각합니다. 반해버린 상대에게 워크플로(Workflow)를 인질로 잡히지 않도록 준비만 해두고, 나머지는 즐겁게 사용하면 됩니다. 도움이 되었다면 저장해 두었다가, 다음 모델 소동이 일어날 때 다시 확인해 보세요.

평소에는 raplsworks.com에서 WordPress 플러그인 개발이나 Claude Code 주변의 이야기를 쓰고 있습니다.