금요일 밤 Fable 5가 중단되었습니다. 토요일에 백업으로 중요한 워크플로우를 실행해 보았고, 무엇이 망가졌는지 공유합니다

금요일 오후, Anthropic에 정부 명령이 내려졌고, 토요일 아침이 되자 전 세계 모든 고객에 대해 Fable 5와 Mythos 5가 비활성화되었습니다. 지원 종료(Deprecated)가 아니었습니다. 사라진 것입니다. 이틀 후, OpenAI는 하루에 1,500만 달러를 잃고 있다는 이유로 Sora를 중단시켰습니다.

저는 정치적인 문제에 대해 강한 견해를 가지고 있지는 않습니다. 제가 토요일 오전 8시에 가졌던 질문은 더 작고 이기적인 것이었습니다. 만약 내가 저 모델들 중 하나에 실제 워크플로우를 배치해 두었다면, 지금 당장 무엇을 해야 할까?

그래서 테스트를 해보았습니다. 결과는 다음과 같습니다.

"그냥 전환하면 돼"는 계획이 아니라 희망 사항일 뿐입니다

저는 몇 달 동안 저 자신에게 중복성(Redundancy)을 갖추고 있다고 말해왔습니다. 메인 모델이 작동하지 않으면, 두 번째 벤더로 옮기면 된다고 생각했습니다. 쉬운 일이죠.

그 문장의 문제는 제가 단 한 번도 그것을 실행해 본 적이 없다는 점입니다. 한 번도 실행해 보지 않은 폴백(Fallback)은 폴백이 아닙니다. 그것은 그럴듯해 보이는 추측일 뿐입니다.

그래서 토요일에 저는 제가 매일 의존하고 있는 가장 중요한 단일 AI 의존 워크플로우인 '스펙-태스크-분해(spec-to-task-breakdown) 파이프라인'을 가져와서, 다른 벤더의 모델로 처음부터 끝까지 실행해 보았습니다. 단 한 번, 그 추측이 맞는지 확인하기 위해서 말입니다.

맞지 않았습니다.

오류 #1: 프롬프트가 특정 모델에 과적합(Overfit)됨

가장 먼저 망가진 것은 프롬프트 자체였습니다. 제 프롬프트는 제가 기준으로 삼았던 모델에서 아름답게 작동하는 형태로 변질되어 있었습니다. 간결하고, 짧으며, 모델이 스스로 채워 넣도록 학습된 많은 암시적 구조를 포함하고 있었습니다.

백업 모델은 동일한 프롬프트를 읽고는 형편없는 결과물을 내놓았습니다. 정확히 틀린 것은 아니었지만, 모호하고 구조화되지 않은, 그냥 버려야 할 수준의 출력물이었습니다.

해결책은 설정 플래그(Config flag) 하나로 해결되는 것이 아니라 실제 작업이 필요했습니다:

- 스펙을 요약하고 태스크로 분해하세요
+ 당신은 스펙을 엔지니어링 태스크로 분해하고 있습니다.
+ 다음 형태에 맞춰 JSON으로만 출력하세요:
...

모델 A는 그 모든 구조를 스스로 채웠습니다. 모델 B는 그것을 명시해 줄 필요가 있었습니다. 이는 실제 장애 상황 중에 겪기보다는 평온한 토요일에 차라리 겪고 싶은 20분간의 재구조화 작업이었습니다.

오류 #2: 조용한 도구 호출(Tool-call) 의존성

두 번째 문제는 눈에 보이지 않았기에 저를 더 겁나게 했습니다. 파이프라인의 한 단계가 도구 호출 (Tool-call) — 모델이 실시간 데이터를 가져오기 위해 호출하는 함수 — 에 의존하고 있었습니다. 백업 모델의 도구 호출 (Tool-calling) 형식이 충분히 달랐기 때문에, 해당 호출은 아무런 동작 없이 조용히 무시(no-op)되었습니다.

출력값은 여전히 그럴싸해 보였습니다. 단지 오래된 데이터를 사용했을 뿐이며, 저에게 그 사실을 알려주지 않았습니다. 이것이 바로 최악의 실패 모드입니다. 오류도 없고, 경고도 없이, 자신 있게 틀리는 것 말입니다. 제가 문제를 찾으려 노력하고 있었기에 겨우 잡아낼 수 있었습니다. 평상시였다면 그 잘못된 출력값이 하류 (downstream)로 흘러가 누군가가 그것을 바탕으로 의사결정을 내렸을 것입니다.

가용성 (Availability)은 리스크 레지스터 (risk register)에 포함되어야 합니다

제가 이번 경험을 통해 얻은 재정의는 다음과 같습니다. 우리는 이미 API가 다운 (down) 되는 상황은 다루고 있습니다. 503 오류가 발생하면, 잠시 멈췄다가 재시도하고, 그러면 다시 복구됩니다. 그것은 서비스 수준 계약 (SLA)이 있고, 결국 초록색으로 변하는 상태 페이지 (status page)가 있는 장애입니다.

하지만 이것은 모델이 사라지는 (gone) 상황입니다. SLA도 없습니다. 복구 예정 시간 (ETA)도 없습니다. 모델이 돌아오지 않을 것이기에 초록색 상태 페이지도 없습니다. 정책 명령이나 벤더의 비용 소진율 (burn-rate) 검토로 인해 하룻밤 사이에 상황이 종료될 수 있으며, 여러분은 다른 모든 사람과 마찬가지로 그 사실을 뒤늦게 알게 됩니다.

여러분이 제어할 수 없고 복구할 수도 없는 서비스라면, 그것은 여러분의 핵심 경로 (critical path) 상에 있는 단일 장애점 (single point of failure)입니다. 우리는 데이터베이스에 대해 이런 상황을 절대 배포하지 않을 것입니다. 하지만 우리 대부분은 사고의 절반을 담당하는 모델에 대해서는 이런 상황을 그대로 배포하고 있습니다.

최악의 시간을 지워버릴 원페이저 (one-pager)

가장 저렴한 조치가 가장 유용하다는 것이 밝혀졌습니다. 모델이 작동을 멈춘 후 첫 한 시간은 무엇이 방금 고장 났는지 — 어떤 워크플로우가 해당 모델을 사용했는지, 어떤 버전인지, 출력값이 어디에 있는지 — 를 파악하는 데 허비됩니다.

IBM의 조사에 따르면 기업의 88%가 실행 중인 AI와 에이전트 (agents)의 완전한 인벤토리 (inventory)를 유지하지 않는다고 합니다. 무엇이 모델에 의존하고 있는지 모른다면, 죽어버린 모델을 우회할 방법이 없습니다. 그래서 저는 파일 하나를 작성했습니다:

workflows:
  - name: spec-to-tasks
    model: primary-vendor/model-a
...

이 마지막 줄이 바로 Sora로부터 얻은 교훈입니다. 벤더가 단순히 모델뿐만 아니라 제품 (product) 자체를 없앨 때, 여러분은 여러분의 출력값이 어디로 가는지, 그리고 그것을 어떻게 추출할 수 있는지도 물어야 합니다. 열(column) 하나만 더 추가하면 됩니다.

핵심은 공포가 아닙니다

분명히 말씀드리고 싶습니다. 이 글의 게으른 버전은 "AI는 신뢰할 수 없으니 패닉에 빠져라"가 될 수도 있겠지만, 그렇지 않습니다. 그렇게 말하는 것은 도움이 되지 않습니다. 이러한 모델들에 의존하는 것은 올바른 결정입니다. 승리하는 팀은 의존성을 피한 팀이 아닙니다. 모델이 사라진 바로 다음 날 아침에도 업무를 계속 진행할 수 있는 팀입니다.

그러한 역량을 갖추는 데는 오후 시간 정도의 노력이 필요하지만, 아직 이를 구축한 사람은 거의 없습니다.

가장 중요한 워크플로우 (workflow)를 두 번째 모델로 딱 한 번만 실행해 보세요. 이 연습 자체가 전체적인 도구 (instrument)가 됩니다.
워크플로우를 '오늘 반드시 생존해야 하는 것'과 '기다려도 되는 것'으로 분류하세요. 오직 짧은 목록에 있는 것들만이 테스트된 폴백 (fallback)을 갖출 자격이 있습니다.
워크플로우와 모델 간의 관계를 정리한 한 페이지짜리 목록을 유지하세요. 그래야 첫 번째로 업무가 중단된 한 시간이 눈길 한 번으로 해결될 수 있습니다.

저는 조용한 토요일에 테스트를 진행했고, 그 대가로 20분의 시간과 약간의 자존심을 지불했습니다. 그 대안은 정말 중요한 아침에 처음으로 테스트를 실행하는 것이었습니다.

만약 내일 당신의 메인 모델이 사라진다면, 당신의 스택 (stack)에서 무엇이 가장 먼저 망가질까요? 그리고 실제로 확인해 본 적이 있습니까?