당신의 AI 제공업체는 단일 장애점(Single Point of Failure)입니다

지난 금요일, 미국 상무부는 Anthropic에 서한을 보냈습니다. 그날 저녁, Fable 5와 Mythos 5는 사라졌습니다. 지원 중단(Deprecated)된 것도, 속도 제한(Throttled)이 걸린 것도 아니었습니다. 그냥 사라졌습니다. API 호출은 404 오류를 반환했습니다. 라이브 세션은 대화 도중 오류가 발생하며 중단되었습니다. 해당 모델에 의존하던 프로덕션 애플리케이션(Production applications)들은 단순히 작동을 멈췄습니다.

출시 3일 만에 일어난 일입니다. 사전 경고도 없었습니다. 마이그레이션(Migration) 기간도 없었습니다.

솔직히 말해서, 이번에는 운이 좋았습니다. Fable 5는 단 3일 동안만 사용 가능했습니다. 아무도 그 모델에 실제 프로덕션 의존성을 구축할 시간이 없었습니다. 만약 당신이 6개월 동안 사용해 온 모델에서 이런 일이 발생한다고 상상해 보십시오. 당신의 제품 전체가 의존하고 있는 모델 말입니다. 그것이 바로 당신이 대비책을 세워야 하는 시나리오입니다.

한 가지 묻고 싶습니다. 만약 당신의 데이터베이스(Database) 벤더가 정부의 서한 한 장으로 당신의 기본 데이터베이스를 강제로 폐쇄할 수 있다면, 당신은 페일오버(Failover) 없이 운영하시겠습니까? 당연히 아니겠죠. 하지만 대부분의 팀이 AI 제공업체를 대하는 방식이 바로 이와 같습니다.

시한폭탄

대부분의 팀은 AI 제공업체를 전기처럼 취급합니다. 스위치를 켜면 불이 들어옵니다. 전기가 어디서 오는지, 전기가 끊기면 어떻게 되는지는 생각하지 않습니다. 그저 작동하기를 기대할 뿐입니다. 모델을 선택하고, API 엔드포인트(Endpoint)를 하드코딩하며, 그 모델의 특성에 맞춰 프롬프트(Prompts)를 작성하고 배포합니다. 아주 잘 작동하죠. 그러다 작동하지 않을 때까지는 말입니다.

이해합니다. 빠르게 제품을 구축할 때는 "내 모델이 사라지면 어떻게 될까"라는 생각을 가장 마지막에 하고 싶을 것입니다. 하지만 이번 주는 그것이 더 이상 이론적인 위험이 아님을 증명했습니다. 이것은 단순히 가동 시간(Uptime)의 문제가 아닙니다.

당신의 모델은 규제상의 이유로, 정책 변경으로 인해, 혹은 당신의 애플리케이션과 전혀 상관없는 지정학적 갈등으로 인해 철수될 수 있습니다. Anthropic 상황은 버그가 아니었습니다. 인프라(Infrastructure) 장애도 아니었습니다. 그것은 규제 차단 스위치(Regulatory kill switch)였습니다. 그리고 전 세계의 모든 고객에게 영향을 미쳤습니다.

저는 내부 동작 원리를 이해하지 못한 채 AI 도구에 너무 과도하게 의존할 때 발생하는 숨겨진 비용에 대해 이전에 글을 쓴 적이 있습니다. 이것은 동일한 문제이며, 단지 스택 (stack)의 다른 계층에서 발생하고 있을 뿐입니다.

우리는 이미 이런 상황을 본 적이 있습니다

이 점이 저를 좌절하게 만듭니다. 우리는 이미 이 문제를 해결하는 방법을 알고 있습니다. 우리는 수십 년 동안 회복 탄력성 있는 시스템 (resilient systems)을 구축해 왔습니다. 우리는 복제 (replication) 없이 단일 데이터베이스를 운영하지 않습니다. 하나의 CDN에만 의존하지 않습니다. 모든 것의 앞단에 로드 밸런서 (load balancers)를 배치합니다. 우리는 결국 모든 것이 실패한다는 것을 충분히 경험했기에, 실패를 고려하여 설계 (design for failure)합니다.

하지만 웬일인지 모델 계층 (model layer)에 이르면, 우리는 그 모든 것을 잊어버립니다.

팀들은 폴백 (fallback) 장치도 없이 단일 제공업체의 API 위에 전체 제품을 구축하고 있습니다. 추상화 계층 (abstraction layer)도 없고, 대체 라우팅 (alternative routing)도 없으며, 우아한 성능 저하 (graceful degradation)도 없습니다. 그저 한 벤더의 모델에 직접적으로 의존하며, 아무 일도 일어나지 않기를 기도할 뿐입니다.

그것은 엔지니어링이 아닙니다. 그것은 희망에 기반한 아키텍처 (hope-driven architecture)입니다.

여기에 적용 가능한 회복 탄력성 패턴 (Resilience Patterns)

그렇다면 실제로 어떻게 해야 할까요? 패턴 자체는 새롭지 않습니다. 단지 다른 모든 곳에 적용하는 것과 동일한 방식으로 모델 계층에 적용하기만 하면 됩니다.

멀티 프로바이더 아키텍처 (Multi-provider architecture)

인터페이스 (interface) 뒤로 모델 호출을 추상화하십시오. 여러분의 애플리케이션은 어떤 제공업체가 응답을 제공하는지 알 필요도, 신경 쓸 필요도 없어야 합니다. 하나가 다운되거나 (또는 정부의 서한에 의해 차단될 때), 다른 곳으로 라우팅하면 됩니다.

이것이 다섯 개의 제공업체에 대해 완전히 동일한 프롬프트 (prompts)를 유지해야 한다는 뜻은 아닙니다. 제공업체를 교체하는 것이 코드 재작성이 아닌 설정 변경 (configuration change)이 되도록 시스템을 설계하라는 의미입니다. 물론 비용은 발생합니다. 해당 추상화 계층을 유지하는 것은 실제 엔지니어링 작업입니다. 여러 제공업체를 대상으로 구축 및 테스트를 수행하고, 서로 다른 응답 형식 (response formats)을 처리하며, 프롬프트 변형 (prompt variations)을 관리해야 합니다. 공짜는 아닙니다. 하지만 토요일 아침에 일어났을 때 유일한 제공업체가 사라졌고 플랜 B가 없는 상황을 맞닥뜨리는 것 또한 공짜가 아닙니다.

헤지(Hedge) 수단으로서의 오픈 웨이트 모델 (Open-weight models)

모델을 직접 실행한다면, 그 누구도 원격으로 이를 끌 수 없습니다. 그것으로 끝입니다.

오픈 웨이트 모델 (Open-weight models)이 바로 그 역할을 해줍니다. 이 모델들이 항상 최첨단 (Frontier) 옵션은 아닐 수도 있습니다. 리더보드 (Leaderboards)의 최상단에 위치하지 않을 수도 있습니다. 하지만 그것들은 당신의 것입니다. 정부의 명령도, 정책의 변화도, 비즈니스 분쟁도 그것들을 당신에게서 빼앗아 갈 수 없습니다. 전력망 (Grid)에 의존하는 것과 발전기 (Generator)를 소유하는 것의 차이라고 생각하십시오. 전력망이 더 강력한 것은 확실합니다. 하지만 전력이 끊겼을 때, 여전히 가동 중인 사람은 바로 당신입니다.

모든 것을 오픈 웨이트 모델로 실행할 필요는 없습니다. 하지만 폴백 체인 (Fallback chain)에 하나를 보유하고 있다는 것은 언제나 최저한의 보루를 갖게 된다는 것을 의미합니다. 상용 제공업체들에게 어떤 일이 일어나든 상관없이 작동하는 베이스라인 (Baseline) 말입니다.

서킷 브레이커 (Circuit breakers)

이것은 기본적인 회복 탄력성 공학 (Resilience engineering)이지만, LLM 호출에 이를 구현하는 팀이 얼마나 적은지 놀라울 따름입니다. AI 제공업체에 장애가 발생하기 시작하면, 이를 빠르게 감지하고, 트래픽 전송을 중단하며, 대안으로 라우팅 (Route)해야 합니다. 타임아웃 (Timeout)이 시스템 전체로 연쇄적으로 퍼질 때까지 기다리지 마십시오.

패턴은 간단합니다. 에러율 (Error rates)을 모니터링하고, 에러가 급증할 때 브레이커를 작동시키며, 폴백 (Fallback)으로 라우팅하고, 기본 시스템이 복구되었는지 주기적으로 확인하십시오. 우리는 모든 마이크로서비스 (Microservice)에 대해 이 작업을 수행합니다. 당신의 모델 엔드포인트 (Model endpoint)도 동일한 대우를 받을 자격이 있습니다.

우아한 성능 저하 (Graceful degradation)

Anthropic이 Fable 5와 Mythos 5를 중단했을 때, 무엇이 계속 작동했는지 아십니까? 바로 Opus 4.8이었습니다. 약간 더 오래되었고, 약간 성능이 낮은 모델이었죠. 하지만 작동했습니다.

그것이 바로 패턴입니다. 더 작거나 오래된 모델이 약간 저하된 경험을 제공하는 것이, 아무것도 제공하지 못하는 고장 난 애플리케이션보다 무한히 낫습니다. 시스템이 충돌 없이 한 단계 낮은 티어로 내려갈 수 있도록 설계하십시오. 사용자들은 에러 페이지를 보는 것보다 '충분히 괜찮은' 응답을 받는 것을 더 선호할 것입니다. 저는 이전에 LLM의 비결정론적 특성 (Non-deterministic nature of LLMs)과 우리가 그것들을 얼마나 신뢰해야 하는지 여전히 파악 중이라는 점에 대해 언급한 바 있습니다. 우아한 성능 저하 (Graceful degradation)는 그 해답의 일부입니다.

우리는 이미 이것을 알고 있습니다

저는 오랫동안 GenAI 워크로드의 Day 2 운영에 대해 이야기해 왔습니다. 그리고 핵심 메시지는 변하지 않았습니다. 여러분의 AI 구성 요소를 다른 모든 중요한 프로덕션 의존성처럼 취급해야 합니다. 관측 가능성(Observability), 장애 조치(failover), 그리고 문제가 발생했을 때 무슨 일이 일어나는지 테스트하는 것. 이 모든 것이 적용됩니다.

Werner Vogels는 수년 동안 '모든 것은 항상 실패한다'고 말해 왔습니다. 여러분의 AI 제공업체도 반드시 중단 사태를 겪을 것입니다. 그것은 서비스 중단(outage)일 수도 있습니다. 하룻밤 사이에 단위 경제학(unit economics)을 불가능하게 만드는 가격 변경일 수도 있습니다. 30일 통보와 함께 모델 사용 중단(model deprecation)일 수도 있습니다. 또는 금요일 오후의 정부 서신일 수도 있습니다.

그러니 스스로에게 물어보세요: 여러분의 아키텍처가 이런 일이 일어날 것이라고 가정하고 있습니까?

만약 대답이 '아니다'라면, 이번 주는 다가올 것에 대한 미리 보기(preview)를 제공했습니다. 그리고 다음번에는 여러분의 제공업체일 수도 있습니다.

여러분의 AI 스택에 멀티-프로바이더 폴백(multi-provider fallback)을 구축했습니까? 아니면 여전히 희망에 의존하는 아키텍처로 운영하고 있습니까? 아래 댓글에서 알려주세요.