당신의 AI 모델은 하룻밤 사이에 사라질 수 있습니다. 이에 대비하여 구축하세요.

어젯밤 제가 작업하던 모델이 존재하지 않게 되었습니다. 속도가 느려진 것도, 속도 제한(rate-limited)이 걸린 것도 아니었습니다. 도구에 일상적인 작업을 요청하자, 모델이 "존재하지 않거나, 접근 권한이 없을 수 있습니다"라고 답변했습니다. 몇 분 후 소식이 전해졌습니다. Anthropic이 미국 정부의 지침에 따라 같은 날 저녁, Claude Fable 5와 Mythos 5의 전 세계 사용을 중단했다는 뉴스였습니다.

작업은 중단되지 않았습니다. 저는 Claude Opus 4.8로 전환하여 작업을 계속했습니다. 왜냐하면 중요한 모든 것은 Fable 안에 들어있지 않았기 때문입니다. 그것은 메모리 레이어(memory layer)와 어떤 유능한 모델이라도 이어받을 수 있는 git 히스토리(git history)에 존재했습니다. "모델이 사라졌다"와 "작업이 일시 중지되었다" 사이의 그 간극이 바로 이 포스트의 핵심 주제입니다. 오늘날 단일 AI 모델로 운영되는 대부분의 팀에게 그 간극은 제로(0)입니다. 모델이 사라지면, 작업도 함께 사라집니다.

실제로 일어난 일

2026년 6월 12일 동부 표준시 오후 5시 21분, Anthropic은 "미국 내외를 불문한 모든 외국인"에 대해 Fable 5 및 Mythos 5에 대한 접근을 중단하라는 수출 통제 지침(export-control directive)을 받았습니다. 해당 범위는 회사의 외국인 직원들을 포함하여 선택적으로 집행하는 것이 불가능하기 때문에, Anthropic은 모든 사용자에 대해 두 모델을 비활성화했습니다. 명시된 명분은 국가 안보였습니다. Anthropic의 설명에 따르면, 해당 서신은 "구체적인 세부 사항을 제공하지 않았으며", 우려 사항은 모델에게 코드베이스를 읽고 소프트웨어 결함을 식별하도록 요청하는 것과 관련된, 회사가 "좁은 범위의 잠재적 탈옥(narrow potential jailbreak)"이라고 부르는 문제에서 비롯되었습니다.

Anthropic은 이례적으로 공개적인 반박을 했습니다. 이 회사는 "좁은 범위의 잠재적 탈옥(narrow potential jailbreak) 발견이 수억 명에게 배포된 상용 모델을 회수해야 할 원인이 되어야 한다는 점"에 동의하지 않는다고 밝혔으며, 동일한 기준이 적용된다면 "본질적으로 모든 프런티어 모델(frontier model) 제공업체의 모든 새로운 모델 배포가 중단될 것"이라고 경고했습니다. 또한 Opus 4.8을 포함한 다른 모든 Claude 모델은 영향을 받지 않았으며, "가능한 한 빨리 액세스를 복구하기 위해 노력하고 있다"고 덧붙였습니다.

저는 그 마지막 문장을 Fable이 돌아온다는 신호로 읽었습니다. 논쟁은 국한된 것으로 보이며 회사 측도 공개적으로 싸우고 있습니다. 하지만 복귀 날짜를 결정할 권한이 Anthropic에게 없다는 점에 주목하십시오. 바로 그 지점이 깊이 고민해 볼 만한 부분입니다. 여러분이 구축한 모델은 이제 제3자에 의해 예고도 없이, 아무런 일정 계획도 없이 차단될 수 있으며, 벤더(vendor) 또한 이것이 불합리하다는 점에는 동의하면서도 당장 오늘 밤에는 아무것도 할 수 없는 상황입니다.

이것은 일회성 사건이 아닙니다

정부 지침을 일시적인 돌발 사건(freak event)으로 치부하고 싶은 유혹이 생길 수 있습니다. 이번 중단 사태는 이례적이었습니다. 하지만 모델의 사라짐은 이례적이지 않았습니다.

이제 모델들은 정해진 일정에 따라 은퇴합니다. OpenAI는 2026년 4월 3일에 GPT-4o를 철수시켰으며, 이 발표는 약 80만 명의 주간 사용자에게 영향을 미쳤고, 8월에는 Assistants API가 그 뒤를 이었습니다. Anthropic은 2025년 11월에 Claude 3.7 Sonnet의 지원을 중단(deprecated)했으며 2026년 5월 11일에 서비스를 종료했습니다. Claude 3 Haiku 역시 8월에 같은 경로를 밟을 예정입니다. 업계 전반에 걸쳐 특정 모델에 대한 지원 기간은 18개월에서 24개월 사이에서 6개월에서 12개월 사이로 압축되었습니다. 작년 말에는 단 한 번의 할당량(quota) 변경으로 인해 일부 Google API 사용자의 이용량이 약 80% 감소했으며, 이로 인해 정상 작동하던 운영 시스템들이 하룻밤 사이에 "리소스 고갈(resource exhausted)" 에러 루프에 빠지기도 했습니다.

따라서 모델이 당신의 스택(stack)에서 사라지는 것은 예외적인 일이 아닙니다. 그것은 당신이 통제할 수 없는 시간표에 따라 발생하는 기본값이며, Fable 사례는 그것이 더 빠르고 예측 불가능한 방식으로 발생할 수 있는 경로를 추가했을 뿐입니다. 사람들은 이를 기존에 알고 있던 느린 '락인(lock-in)'과 구분하기 위해 '벤더 락아웃(vendor lock-out)'이라고 부르기 시작했습니다. 락인은 떠날 때 발생하는 비용인 반면, 락아웃은 떠나는 결정 자체를 (벤더가) 대신 내리는 것입니다.

만약 당신의 제품, 내부 도구, 또는 고객 업무가 특정 모델 이름을 호출했을 때 반드시 응답할 것이라고 가정한다면, 당신은 지난 6개월 동안 신뢰할 수 없다는 것이 반복적으로 증명된 단일 장애점(single point of failure)을 가지고 있는 것입니다.

회복탄력성(Resilience)은 모델 선택이 아닌 아키텍처의 문제입니다

서비스 중단 이후에 드는 본능적인 생각은 어떤 모델에 거는 것이 가장 안전할지 묻는 것입니다. 그것은 잘못된 질문입니다. 안전한 단일 베팅이란 존재하지 않습니다. 왜냐하면 리스크는 모델에 있는 것이 아니라 의존성(dependency)에 있기 때문입니다. 어젯밤의 사태를 대수롭지 않게 넘긴 팀들은 모델을 올바르게 선택한 팀들이 아닙니다. 그들은 선택이 크게 중요하지 않도록 구축한 팀들이었습니다.

모델이 사라졌을 때 함께 꺼져버리는 스택과 살아남는 스택을 가르는 세 가지 요소가 있습니다.

추상화 계층(An abstraction layer). 당신의 애플리케이션 로직은 특정 벤더의 SDK에 직접 연결되는 것이 아니라, 얇은 내부 인터페이스(internal interface)와 통신해야 합니다. 모델이 사라지면 코드베이스가 아닌 설정값(configuration value)만 변경하면 됩니다. 처음부터 이를 구축한 팀들은 하나의 API에 직접 연결된 팀들에 비해 아주 적은 마이그레이션 노력만으로 제공업체를 추가하거나 교체할 수 있었다고 보고합니다. 이것은 화려하지 않은 배관 작업(plumbing)과 같지만, 당신이 내릴 수 있는 결정 중 가장 레버리지가 높은 결정입니다.

이동 가능한 메모리 계층 (A portable memory layer). 이것은 어젯밤 저를 구한 것입니다. AI 어시스턴트를 유용하게 만드는 컨텍스트, 즉 프로젝트가 무엇인지, 지난주에 무엇이 결정되었는지, 고객이 무엇을 선호하는지 등은 모델 외부, 즉 어떤 모델이든 읽을 수 있는 저장소에 존재해야 합니다. 만약 당신이 축적한 컨텍스트가 벤더(vendor)의 채팅 기록이나 독점적인 파인튜닝 (fine-tune) 내에만 존재한다면, 모델을 잃는 것은 그와 함께 조직의 기억(institutional memory)을 잃는 것을 의미합니다. 상태(state)를 이동 가능한 무언가에 보관하십시오. 그러면 모델은 금고(vault)가 아닌 교체 가능한 엔진이 됩니다.

테스트된 폴백 (A tested fallback). 단순히 작동할 것이라고 가정하는 모델이 아니라, 실제 워크로드 (workload)를 실제로 실행해 본 두 번째 모델입니다. "전환할 수 있다"와 "전환했다" 사이에는 큰 차이가 있습니다. 전자는 희망이고, 후자는 런북 (runbook)입니다. 폴백은 기본 모델만큼 강력할 필요는 없지만, 기본 모델의 문제를 해결하는 동안 서비스가 중단되지 않도록 유지해 주어야 합니다.

이 중 어느 것도 생소한 것이 아닙니다. 이는 모든 기업이 결제 처리업체, 호스팅 제공업체, 공급업체에 대해 결국 배우게 되는 것과 동일한 규율입니다. 당신은 예고 없이 전화를 받지 않을 수도 있는 단 한 곳의 채소 도매상에게만 의존하여 레스토랑을 운영하지 않습니다. AI는 도구가 새롭고, 락인 (lock-in) 현상이 누구에게나 인지되기 전 12개월에서 18개월 사이에 보이지 않게 형성되기 때문에 다르게 느껴졌을 뿐입니다. Fable의 종료는 단 하룻밤 동안 그 보이지 않던 것을 가시화했을 뿐입니다.

소규모 비즈니스를 운영하는 경우의 의미

대기업들은 괜찮을 것입니다. 그들에게는 조달 팀과 보조 계약이 있으며, 두 개의 제공업체를 병행하여 운영할 예산이 있습니다. 위험 노출은 소규모 운영자들에게 있습니다. 클라이언트의 전체 지원 흐름을 하나의 모델에 연결한 에이전시, 제품이 단일 API를 감싸는 래퍼 (wrapper)인 창업자, 그리고 전체 서비스 제공이 하나의 구독 서비스가 유지되는 것에 달려 있는 컨설턴트가 그 대상입니다.

회복 탄력성 (resilience)을 갖추기 위해 기업 수준의 예산이 필요한 것은 아닙니다. 당신에게 필요한 것은 세 가지 습관입니다. 프롬프트 (prompt)와 로직 (logic)을 당신이 제어할 수 있는 인터페이스 (interface) 뒤에 두십시오. 데이터와 컨텍스트 (context)를 당신이 소유하고 지금 당장 내보낼 수 있는 형식으로 유지하십시오. 그리고 당신의 주력 모델이 사라진 직후 한 시간 동안 구체적으로 무엇을 할 것인지 알고 있어야 합니다. 올해 어느 시점에 당신은 자신이 정말 알고 있었는지, 아니면 단지 추측만 하고 있었는지 확인하게 될 것이기 때문입니다.

우리는 정부의 지침을 예측했기 때문이 아니라, 서비스 중단 (deprecation) 일정만 보더라도 명백했기에 우리 자신의 시스템과 고객들을 위해 이런 방식으로 구축합니다. 어젯밤은 하나의 설계 원칙을 실시간 테스트로 바꾸어 놓았고, 그 테스트는 다소 지루한 이유로 통과되었습니다. 즉, 떠나버린 모델 안에 중요한 것이 아무것도 갇혀 있지 않았기 때문입니다.

Fable이 돌아온 후에도 변하지 않는 부분

Fable 5는 아마도 이 글이 올라온 지 일주일이 채 되기 전에 돌아올 것입니다. Fable이 돌아오면, 어젯밤의 일을 스스로 해결된 기이한 중단 사건으로 취급하고 넘어가고 싶은 유혹이 생길 것입니다. 그것은 피하기에는 너무나 값비싼 교훈이 될 것입니다.

구체적인 원인은 이례적이었습니다. 하지만 그 형태는 이례적이지 않았으며, 바로 그 형태가 반복됩니다. 당신의 업무가 의존하는 기능이 당신이 참여하지 않은 결정에 의해, 당신이 볼 수 없는 일정에 따라, 심지어 당신에게 동의하면서도 당장에는 도움을 줄 수 없는 벤더 (vendor)에 의해 제거될 수 있습니다. 이것은 이제 프런티어 AI (frontier AI)를 기반으로 구축할 때 발생하는 일시적인 오류가 아니라, 영구적인 특징입니다.

올바른 대응은 특정 제공자를 불신하는 것이 아닙니다. 단일 모델을 당신이 무게를 실어 의지할 수 있는 인프라 (infrastructure)로 취급하는 것을 멈추는 것입니다. 모델을 현재의 모습 그대로, 즉 빠르게 변화하고 강력하며 일시적인 것으로 취급하십시오. 그리고 당신이 실제로 소유하고 있는 모델 아래의 계층에서 내구성이 있는 부분을 직접 구축하십시오. 그렇게 한다면 다음에 모델이 사라지더라도, 당신에게는 단 한 시간의 시간과 약간 짜증 나는 오후 정도의 비용만 발생할 것입니다. 만약 이를 무시한다면, 당신은 항상 응답할 것이라고 믿었던 비즈니스의 핵심 부분을 잃게 될 것입니다.

뉴스 사이클이 다음 주제로 넘어가기 전에, 이번 주에 반드시 실행해 볼 가치가 있는 테스트를 소개하겠습니다. 만약 오늘 밤, 아무런 예고 없이 당신의 주력 모델을 교체하더라도 약간의 시간만 손해 볼 뿐 아무것도 잃지 않을 수 있습니까? 만약 대답이 '예'라면, 어젯밤의 일은 다른 누군가의 비상사태였을 뿐입니다. 만약 대답이 '아니오'라면, 당신은 이제 무엇을 해야 할지(어디에 집중해야 할지)를 방금 배운 것입니다.