모델 의존성이 세션 도중 빌드를 중단시켰다

요약 (TL;DR)

• 모델 의존성 (Model dependency)은 실제 빌드 위험 요소입니다: 2026년 6월 12일, 미국의 수출 통제 명령으로 인해 Anthropic의 Fable 5가 빌드 도중 오프라인 상태가 되었습니다.
• 저는 세션 도중에 Opus 4.8로 전환하여 작업을 계속 진행했습니다. 그날 오후의 커밋(commits)들은 여전히 저장소(repo)에 남아 있습니다.
• 모델을 다른 의존성(dependency)처럼 취급하세요: 모델이 제공하는 것을 검증하고, 교체 가능하도록 유지하세요.

모델 의존성 (Model dependency)은 이론적인 위험이 아닙니다. 2026년 6월 12일, 빌드 도중 그것은 저에게 매우 실질적인 위험이 되었습니다.

실제로 무슨 일이 일어났는가?

2026년 6월 9일, Anthropic은 Fable 5를 출시했습니다. 그것은 그 주에 사용 가능한 가장 강력한 모델이었고, 저는 그것을 기반으로 saas.theautomate.io를 구축하고 있었습니다.

출시 후 며칠이 지났습니다. 빌드에 깊이 몰입해 있었습니다. 흐름(flow)을 타고 있고, 변수가 바뀌는 것을 가장 원치 않는 그런 종류의 세션이었습니다.

6월 12일, 미국의 수출 통제 (export-control) 명령으로 외국인에 대한 Fable 5 접근이 차단되었습니다. 저는 호주에 있습니다. 세션 도중에 모델이 응답을 멈췄습니다.

경고도 없었습니다. 유예 기간도 없었습니다. 그냥 사라졌습니다.

모델 의존성 (Model Dependency)의 실제 비용은 무엇인가?

제 경우에는 오후 시간 하나였습니다. 그게 전부입니다. 하지만 이는 제가 모델이 항상 존재할 것이라고 가정하지 않는 방식으로 세션을 구축했기 때문입니다.

저는 Opus 4.8로 전환하여 작업을 계속 진행했습니다. 그날 오후의 커밋(commits)들은 여전히 저장소(repo)에 남아 있습니다. 출시가 지연되지는 않았습니다.

하지만 저는 계속 이런 생각을 했습니다. 만약 제가 컨텍스트 (context), 프롬프트 (prompts), 그리고 세션에 녹아든 가정들에 대해 덜 주의 깊게 구조를 잡았다면, 훨씬 더 큰 비용이 들었을 수도 있었다는 것을 말입니다.

모델 의존성 (Model dependency)은 발생하기 전까지는 조용합니다. 그러다 발생하면 매우 시끄러워집니다.

AI 모델로 빌드하는 것에 대해 무엇을 깨달았는가?

당신이 사용하는 모델은 당신이 통제할 수 없는 의존성 (dependency)입니다. 다른 서드파티 API (third-party API)나 SaaS 도구와 마찬가지이지만, 그것이 사라졌을 때 제공되는 문서(documentation)는 훨씬 더 적습니다.

이 부분은 대부분의 빌더들이 간과하는 지점입니다. 당신은 현재 사용 가능한 가장 좋은 모델이기 때문에 특정 모델을 선택합니다. 그 모델에 맞춰 최적화(optimise)합니다. 그 모델이 어떻게 추론하는지, 예외 케이스(edge cases)를 어떻게 처리하는지, 당신의 프롬프트(prompts)에 어떻게 반응하는지에 익숙해집니다.

그러다 당신이 속하지 않은 국가의 정책 결정 하나가 모든 것을 바꿔 놓습니다.

이것은 Anthropic에 대한 비판이 아닙니다. 수출 통제법 (Export-control law)은 수출 통제법일 뿐입니다. 여기서 얻는 교훈은 정치적인 것이 아니라 구조적인 것입니다.

이는 왜 AI가 무엇을 생성하는가만큼이나 AI가 생성한 결과물을 검증하는 것이 중요한지와 직접적으로 연결됩니다. 만약 출력값 (output)을 신뢰할 수 없다면, 겉면에 적힌 모델의 이름은 중요하지 않습니다.

모델 의존성에서 살아남기 위해 어떻게 빌드해야 하는가?

모델을 교체 가능한 다른 의존성 (swappable dependency)처럼 취급하고, 첫날부터 그에 맞춰 빌드하십시오.

미국의 AI 인프라를 사용하는 해외 빌더들에게 이것은 피해망상이 아닙니다. 이는 엔지니어링 규율 (engineering discipline)입니다. 수출 통제 명령 (Export-control orders), 서비스 약관 (terms-of-service) 변경, 모델 지원 종료 (model deprecations), 지역적 제한 (regional restrictions). 이 중 어떤 것이라도 프로젝트 도중에 모델을 빼앗아 갈 수 있습니다.

Fable 5에 대한 접근을 중단시킨 미국 정부의 지침은 우리 대부분이 기반을 두고 빌드하는 AI 인프라가 역외(offshore)에서 규제된다는 사실을 상기시켜 줍니다.

실제로 도움이 되는 방법은 다음과 같습니다:

• 프롬프트를 특정 도구의 인터페이스에 내장하지 말고, 일반 텍스트 (plain text) 파일로 관리하세요
• 위기 상황이 닥친 후가 아니라, 위기가 오기 전에 평가 (evals) 체계를 구축하세요
• 모델 동작에 대한 가정을 코드와 분리하여 별도로 문서화하세요
• 개발 중에 선호하는 모델 하나만 사용하지 말고, 최소 두 개 이상의 모델로 테스트하세요
• 특정 모델의 특이점 (quirks)에 너무 과하게 최적화하여, 모델 교체가 곧 코드 재작성 (rewrite)이 되는 상황을 만들지 마세요

그리고 이전에 썼듯이, 계획 모드 (plan mode)는 이러한 규율이 가장 큰 효과를 발휘하는 지점입니다. 계획 단계에서 내리는 결정은 비용이 저렴합니다. 위기 상황 중간에 내리는 결정은 비용이 많이 듭니다.

이것이 1인 개발자만의 문제인가요?

아니요. 단일 제공자의 단일 모델에 의존하는 프로덕션 시스템 (production systems)을 출시하는 사람이라면 누구에게나 발생하는 문제입니다.

1인 개발자들은 이러한 중단을 완충해 줄 팀이 없기 때문에 그 충격을 더 날카롭게 느낍니다. 하지만 폴백 (fallback) 장치 없이 AI 엔드포인트 (endpoint)를 호출하는 모든 자동화 스택에는 동일한 모델 의존성 위험이 내재되어 있습니다.

음성 에이전트, 문서 처리, 또는 CRM 자동화 등 AI 통합 도구를 사용하는 호주의 중소기업 (SMBs)에게 문제는 '이런 일이 귀사의 벤더에게 일어날 것인가'가 아닙니다. '귀사의 벤더가 이에 대해 대비를 했는가'가 문제입니다.

대부분의 벤더가 내놓는 솔직한 답변은 이렇습니다: 아마도 명시적으로 대비하지는 않았을 것입니다.

이것이 바로 초기에 내리는 빌드 결정이 성능뿐만 아니라 회복 탄력성 (resilience) 측면에서 매우 중요한 이유입니다.

핵심 요약

• 모델 의존성은 이론적인 문제가 아니라 구조적인 빌드 위험입니다. 이는 2026년 6월 12일 빌드 도중에 실제로 발생했습니다.
• Fable 5에 대한 접근 권한을 잃었을 때, 세션이 교체 가능하도록 구축되었기 때문에 출시가 무산되는 대신 오후 시간만 소요되었습니다.
• 모델을 다른 모든 제3자 의존성 (third-party dependency)처럼 취급하세요: 출력을 검증하고, 가정을 문서화하며, 폴백 (fallback)을 준비해 두어야 합니다.

AI를 핵심으로 무언가를 구축하고 계신가요? 저에게 AUDIT이라고 DM을 보내주시면, 프로젝트 도중 주요 모델을 잃더라도 귀하의 스택이 버텨낼 수 있는지 확인할 수 있는 다섯 가지 질문을 보내드리겠습니다. 10분 정도 소요됩니다. 직접 고생하며 깨닫기 전에 확인해 볼 가치가 있습니다.

원문은 theautomate.io에 게시되었습니다.