하나의 AI 벤더는 단일 장애 지점입니다. 이를 단일 장애 지점처럼 취급하십시오.

오늘 당신의 워크플로우(Workflow)를 구축한 데 사용된 AI 모델은 다음 분기에 경쟁 모델과 구분이 불가능할 수도 있습니다. 그것은 문제가 아닙니다. 하지만 그중 하나에만 도박을 거는 것은 문제입니다.

어떤 두 개의 프론티어 모델(Frontier models)을 골라 동일한 프롬프트(Prompt)를 실행해 보십시오. 1년 전이라면 눈에 띄게 다른 결과물을 얻었을 것입니다. 서로 다른 추론 스타일(Reasoning styles), 서로 다른 강점, 서로 다른 실패 모드(Failure modes)를 보였을 것입니다. 하지만 오늘날 그 격차는 많은 기업용 워크로드(Enterprise workloads)가 이들을 안정적으로 구분할 수 없을 정도로 좁혀졌습니다. 이러한 수렴(Convergence)은 우연이 아닙니다. 이는 산업 자체가 스스로를 잡아먹고 있는 과정에서 나타나는 예측 가능한 결과입니다.

그리고 이는 당신이 시스템을 구축하는 방식에 중대한 시사점을 던집니다.

모델들이 수렴하는 이유

그 이유는 빠르게 쌓여갑니다.

모델로 학습된 모델들. 프론티어 연구소(Frontier lab)가 강력한 모델을 출시하면, 그 모델의 출력값(Outputs)은 학습 데이터(Training data)가 됩니다. 연구자들에게, 경쟁사들에게, 그리고 거대 모델의 동작을 더 작고 저렴한 모델로 압축하는 증류 파이프라인(Distillation pipelines)에 말입니다. [1][2] GPT-4에 인코딩된 지식은 OpenAI 내부에만 머물지 않았습니다. AI가 생성한 콘텐츠를 포함하는 모든 데이터셋을 통해 전파되었으며, 현재 인터넷의 대부분이 그러합니다. 모델들은 의도했든 아니든 점점 더 서로의 출력값을 바탕으로 학습되고 있습니다. OpenAI는 DeepSeek가 정확히 이 작업을 수행했다고 비난했습니다. 즉, OpenAI API의 출력값을 사용하여 경쟁 모델을 학습시켰다는 것입니다. 이에 대해 백악관 AI 담당관은 "DeepSeek가 OpenAI 모델에서 지식을 증류(Distilled)해냈다는 상당한 증거가 있다"라고 언급했습니다. [1] 수렴은 파이프라인 자체에 내재되어 있습니다.

인재는 이동합니다. AI 산업에는 프런티어 모델 (Frontier models)을 대규모로 학습시키는 방법을 이해하는 사람이 대략 1,200명 정도뿐입니다. 이들은 순환합니다. GPT-3를 구축한 연구원들이 Anthropic을 설립하는 데 기여했습니다. Dario Amodei, Daniela Amodei, 그리고 여러 동료들이 OpenAI를 떠나 즉시 Constitutional AI와 기계론적 해석 가능성 (Mechanistic interpretability)을 개발하기 시작했습니다. [3] Fortune은 2025년에 OpenAI 엔지니어들이 반대의 경우보다 Anthropic으로 이직할 확률이 8배 더 높다고 보도했습니다. Meta는 단 한 번의 채용 스프린트(hiring sprint) 동안 OpenAI, DeepMind, Anthropic에서 최소 11명의 연구원을 영입했습니다. [4] 학습 방법론 (Training methodology)의 지적 재산은 이를 개발한 인간과 함께 이동하며, 인간은 한곳에 머물지 않습니다. 그 결과: 학습 접근 방식은 수렴합니다. 왜냐하면 이를 설계하는 사람들이 동일한 사람들이며, 단지 서로 다른 랜야드 (Lanyards)를 착용하고 있을 뿐, 동일한 이론적 토대 위에서 작업하기 때문입니다.

표준이 예상보다 빠르게 통합되고 있습니다. MCP 이야기는 산업이 공유 인프라를 중심으로 얼마나 빠르게 수렴하고 있는지를 보여주는 가장 명확한 증거이며, 잠시 멈춰서 살펴볼 가치가 있습니다. Anthropic은 2024년 11월에 모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)을 발표했습니다. [5] Anthropic의 직접적인 경쟁자인 OpenAI는 4개월 후인 2025년 3월에 이를 채택했습니다. Sam Altman의 게시물은 단순히 다음과 같았습니다: "사람들은 MCP를 좋아하며, 우리는 우리의 제품 전반에 걸쳐 지원을 추가하게 되어 기쁩니다." [6] Google의 Demis Hassabis는 몇 주 만에 공개적으로 MCP를 지지했으며, Google은 공식적인 지원을 이어갔습니다. [7] Microsoft는 Build 2025에서 일반 가용성 (General availability) 단계에 도달했습니다. [8] 2025년 12월까지 Anthropic은 MCP를 Linux Foundation에 기부했습니다. 이때 OpenAI와 Block은 Anthropic과 함께 새로운 Agentic AI Foundation의 공동 설립자로 참여했으며, Google, Microsoft, AWS가 지원 회원으로 참여했습니다. [9]

그 궤적의 속도는 내재화할 가치가 있습니다. 하나의 연구소(lab)가 만든 표준이 6개월 이내에 모든 주요 경쟁사에 의해 채택되고, 1년 이내에 중립적인 오픈 소스 거버넌스(open-source governance)로 이전됩니다. SDK 다운로드 수는 출시 당시 월간 약 100,000건에서 2025년 말까지 월간 9,700만 건으로 증가했으며, 이는 거의 1,000배에 달하는 증가입니다. [10] 현재 10,000개 이상의 활성 MCP 서버가 존재합니다. The New Stack은 "왜 모델 컨텍스트 프로토콜(Model Context Protocol)이 승리했는가"라는 제목의 기사를 게재했습니다. [11]

경쟁사들이 당신의 표준을 그토록 빠르게 채택한다는 것은 한 가지를 의미합니다. 즉, 그 표준이 해결하는 근본적인 문제가 너무나 보편적이어서 그 누구도 독점적인 대안을 통해 이득을 얻을 수 없다는 것입니다. 그것이 바로 인프라(infrastructure)의 정의입니다. 그리고 인프라는 정의상 범용 제품(commodity)입니다. 토큰 형식(Token formats) 또한 동일한 논리로 표준화되고 있으며, 이것이 바로 모델 라우터(model routers)가 하나의 제품 카테고리로 존재할 수 있는 정확한 이유입니다. 인터페이스가 동일할 때, 그 아래의 모델은 상호 교환 가능해집니다.

벤치마크 쳇바퀴 (The benchmark treadmill). 모든 주요 연구소는 MMLU, HumanEval, SWE-bench, GPQA와 같은 동일한 공개 벤치마크를 대상으로 최적화를 진행하고 있습니다. 동일한 테스트를 위해 학습하면, 동일한 역량을 구축하게 됩니다. 모델들은 동일한 방식의 동일한 요소들에 대해 더 나아집니다. 차별화는 프런티어(frontier)와 벤치마크가 측정하지 못하는 엣지 케이스(edge cases)에서 존재합니다. 기업용 유스케이스(use cases)의 방대한 중간 영역에서 모델들은 기능적으로 동등하며, 점점 더 그렇게 되어가고 있습니다.

전략을 바꾸는 통찰: 모델은 해자(moat)가 아닙니다. 모델은 범용 제품(commodity)입니다. 해자는 워크플로(workflow), 데이터, 그리고 도구를 사용하는 방법에 대한 조직적 지식(institutional knowledge)입니다. 만약 당신이 이식성(portability)을 고려하여 구축한다면, 어떤 모델이 이를 구동하든 상관없이 그것은 여전히 당신의 것입니다.

미션 크리티컬한 문제 (The Mission-Critical Problem)

이것은 모든 시스템 아키텍트(systems architect)가 반복해서 보아온 영화와 같습니다.

페일오버 (failover) 없는 단일 서버 위에서 미션 크리티컬 (mission-critical) 인프라를 운영하는 진지한 조직은 없습니다. 이는 서버가 고장 날 가능성이 높기 때문이 아니라, 계획되지 않은 다운타임 (downtime)의 비용이 충분히 높아서 오버헤드 (overhead)를 감수할 만한 보험 가치가 있기 때문입니다. 여러분은 중복성 (redundancy)을 구축하고, 페일오버 (failover)를 테스트하며, 기본 시스템이 다운되기 전에—실제로 다운되기 전에—어떤 일이 발생하는지 알고 있어야 합니다.

AI 도구들은 점점 더 많은 조직에서 미션 크리티컬 (mission-critical) 임계치를 넘어섰습니다. [12] 개발 팀의 속도 (velocity)가 AI 코딩 어시스턴트 (AI coding assistant)에 의존하고, 고객 서비스가 AI 에이전트 (AI agent)를 통해 운영되며, 분석가들이 연구 합성 (research synthesis)을 위해 AI를 사용하고 있다면, 서비스 중단은 단순한 편의성의 문제가 아닙니다. 그것은 비즈니스 문제입니다.

이것은 이론적인 위험이 아닙니다.

2026년 4월 15일, 심각한 사고로 인해 Claude.ai, Claude API, Claude Code, 그리고 플랫폼 콘솔 (platform console)이 동시에 약 3시간 동안 중단되었습니다. [13] 로그인 실패로 인해 이미 세션 (session)을 생성하지 않은 사용자들이 접속 차단되었으며, API는 복구되기 전까지 완전히 먹통이 되었습니다.

일주일도 채 되지 않은 2026년 4월 20일 (이 글을 쓰는 오늘), OpenAI는 ChatGPT, Codex, 그리고 전체 API 플랫폼을 동시에 중단시키는 2시간 이상의 장애를 겪었습니다. [14] 같은 주에 인증 오류 (authentication errors) 증가, 유럽 지역 장애, 그리고 비즈니스 워크스페이스 (business workspace) 중단이 발생했습니다. 대체 경로 (routing alternative)가 없는 AI 워크플로 (AI workflow)는 그저 속수무책으로 멈춰버렸습니다.

또한, 이 글을 쓰는 지난 4일 동안 (4월 17일부터 20일까지), Google의 Gemini API는 부분적인 장애를 보였으며, AI Studio는 4월 2일부터 4월 20일까지 지속적으로 부분적인 장애를 기록했습니다. [15] 지난 한 주 동안 고객에게 영향을 미치는 문제를 일으킨 최상위 LLM (Large Language Model)이 세 곳 모두 발생한 것입니다. 이 패턴은 사후 분석 (post-mortems)에만 활용될 것이 아니라, 아키텍처 (architecture) 설계에 반영되어야 할 만큼 일관적입니다.

AI 서비스의 장애 모드 (failure modes)는 서버 장애와 다르다는 점에 주목하는 것이 중요합니다. 서버는 작동하거나 작동하지 않거나 둘 중 하나입니다. 하지만 AI 서비스는 성능이 저하됩니다. 품질이 떨어지거나, 속도 제한 (rate limits)에 걸리거나, 새로운 가격 책정 계층 (pricing tiers)이 나타나거나, 피크 시간대에 컨텍스트 창 (context windows)이 줄어들거나, 추론 깊이 (reasoning depth)가 조용히 축소되기도 합니다. [16] 기술적으로 서비스는 여전히 이용 가능한 상태입니다. 단지 품질이 나빠졌을 뿐입니다. 이러한 종류의 성능 저하를 감지하고 대응하려면 전통적인 고가용성 (high-availability) 설계와는 다른 아키텍처 (architecture)가 필요합니다.

올바른 아키텍처는 여타 중복 시스템 (redundant system)과 동일한 형태를 가집니다. 즉, 다중 제공자 (multiple providers), 자동 장애 조치 (automatic failover), 그리고 특정 시점에 작업이 가장 잘 수행될 수 있는 곳 또는 가장 저렴한 곳으로 작업을 라우팅 (route)할 수 있는 능력을 갖추어야 합니다.

벤더 종속 (Vendor Lock-in)의 함정

대부분의 기업용 AI 배포는 단일 제공자를 기반으로 구축됩니다. 하나의 API 키, 하나의 모델, 하나의 가격 책정 계층, 하나의 지원 관계를 가집니다.

제공자 간의 역량 차이가 의존성을 정당화할 만큼 컸던 12개월에서 18개월 전에는 이것이 타당했습니다. 하지만 수렴 (convergence)이 가속화됨에 따라 지금은 그 타당성이 떨어지며, 6개월 후에는 더욱 설득력이 없어질 것입니다.

종속 (lock-in) 위험은 주로 제공자가 파산하는 문제에 관한 것이 아닙니다. 그것은 더 미묘합니다:

• 가격 결정력 (Pricing power). 귀하의 워크플로우 (workflow)를 점유하고 있는 제공자는 자신 있게 가격을 인상할 수 있습니다. 귀하는 이미 그들에게 의존하고 있음을 증명했기 때문입니다. 48시간 이내에 전환할 수 있는 조직의 협상 위치는 6개월간의 재통합 (re-integration) 작업이 필요한 조직의 위치와 근본적으로 다릅니다.
• 탈출 불가능한 품질 저하. Anthropic이 소비자 세션에 대한 추론 깊이 (reasoning depth)를 조용히 줄였을 때, Claude에 종속된 조직들은 어떠한 영향력도 행사할 수 없었습니다. Reddit에 불만을 제기할 수는 있겠지만, 귀하의 워크로드 (workload)로 투표할 수도 있습니다. 이 중 제공자의 행동을 변화시킬 수 있는 것은 단 하나뿐입니다.
• 역량의 한계 (Capability ceilings). 모든 분야에서 최고인 단일 모델은 없습니다. 코드 생성 (Code generation), 긴 문서 합성 (long-document synthesis), 구조화된 데이터 추출 (structured data extraction), 창의적 글쓰기 (creative writing), 다단계 추론 (multi-step reasoning) 등 — 순위는 작업과 모델 버전 (model version)에 따라 변동됩니다. 각 작업을 사용 가능한 최적의 도구로 라우팅 (route)할 수 있는 조직은, 재통합 비용이 너무 비싸서 모든 것을 단일 모델로 강제하는 조직보다 더 나은 결과물을 얻습니다.
• 지정학적 및 규제 노출 (Geopolitical and regulatory exposure). AI 규제가 관할 구역마다 갈라지고 AI 역량에 대한 수출 통제가 강화됨에 따라, 단일 제공자에 의존하는 조직은 해당 제공자의 모든 규제 리스크를 상속받게 됩니다. 다각화 (Diversification) 또한 리스크 관리의 일환입니다.

라우터 (Router) 구축하기

범용화 (commoditization)와 벤더 종속 (vendor lock-in)에 대한 실질적인 해답은 동일합니다: 바로 모델 라우터 (model router)입니다.

단순히 예산 통제만을 위한 것은 아닙니다 — 물론 제가 이전에 썼듯이 이는 실제적이고 중요한 문제입니다. 동일한 역량에 대해 제공자 간의 토큰 비용은 10배까지 차이가 납니다. [17] 적절한 가격에 적절한 모델로 적절한 쿼리 (query)를 전달하는 것은 진정으로 가치 있는 일입니다. 하지만 예산 문제는 라우팅 인프라를 구축해야 하는 가장 덜 흥미로운 이유입니다. 저는 현재 테스트를 시작한 modelrouter를 구축했습니다. 처음 이것을 만들었을 때는 주로 예산 통제, 즉 "월말에 가격 폭탄을 맞는 것을 어떻게 방지할 것인가?"를 위한 것이었습니다.

**장애 조치 (Failover)**를 위해 구축하십시오. 한 제공업체의 성능이 저하되거나 속도 제한 (Rate-limited)이 걸릴 때, 사람의 개입 없이 쿼리가 자동으로 다음 최적의 옵션으로 라우팅되어야 합니다. 저는 아직 이것을 구축하지는 않았지만, 사용자 전반의 결과를 모니터링하고, 상태 페이지 (Status pages)를 모니터링하며, 어쩌면 뉴스까지 모니터링하여 이러한 입력값들을 라우팅을 조정하는 점수 산정 시스템 (Scoring system)에 전달하는 시스템을 상상할 수 있습니다.

**품질 라우팅 (Quality routing)**을 위해 구축하십시오. 더 길고 복잡한 추론 (Reasoning) 작업은 해당 유형의 문제에 대해 가장 좋은 벤치마크 성능을 보이는 모델로 보내십시오. 일상적인 추출 (Extraction) 및 요약 (Summarization) 작업은 품질 기준을 통과하는 가장 저렴한 모델로 보내십시오. 실시간 상호작용은 지연 시간 (Latency)이 가장 낮은 모델로 보내십시오. 저는 이 로직을 저의 nanobot에 구축했으며, (개인적인 경험상) 품질에 영향을 주지 않으면서 즉시 토큰 사용 기간 (Token runway)을 연장할 수 있었습니다.

**적대적 검증 (Antagonistic validation)**을 위해 구축하십시오. 동일한 고위험 (High-stakes) 출력을 두 개의 서로 다른 모델을 통해 실행하고 비교하십시오. 모델들이 일치하는 지점에서는 신뢰도가 높아집니다. 모델들이 의견이 갈리는 지점에서는 사람이 검토합니다. 이것은 단일 모델 검토와는 진정으로 다른 품질 관리 아키텍처입니다. 모델들은 서로 다른 실패 모드 (Failure modes), 서로 다른 학습 편향 (Training biases), 서로 다른 사각지대 (Blindspots)를 가지고 있습니다. 모델들이 서로의 작업을 확인하게 함으로써, 어느 한 모델이 단독으로는 잡아내지 못할 오류를 드러낼 수 있습니다. 저는 이러한 동작을 허용할 수 있는 훅 (Hooks)을 저의 라우터에 구축해 두었으며, 에이전트 (Agents)를 사용할 때 이 전략을 매우 생산적으로 활용해 왔습니다. 오늘 아침 한 동료는 동일한 플러그인을 서로 다른 맥락에서 테스트하기 위해 서로 다른 에이전트가 실행되는 여러 개의 Tmux 세션을 띄운다고 공유해 주었습니다. 이는 제가 설계한 모델 라우터 (Modelrouter) 아키텍처를 통해 작동할 것입니다.

**이식성 (Portability)**을 위해 구축하십시오: 다음 세대의 모델이 등장하여 성능 순위가 재편될 때, 여러분의 워크플로 (Workflow)는 최소한의 재작업만으로 새로운 엔드포인트 (Endpoint)를 가리킬 수 있어야 합니다. 저는 모델 라우터 (Modelrouter)에 모델을 등록하고, 특정 모델에 접속할 수 없는 경우 페일오버 (Failover) 경로를 설정할 수 있는 시스템을 구축했습니다. 만약 Opus가 다운되면 Sonnet을 시도하십시오. Sonnet이 다운되면 ChatGPT를 시도하십시오. ChatGPT마저 다운되면 Gemini를 시도하십시오. 또는 선호에 따라 Ollama를 통해 로컬에 호스팅된 오픈 소스 (Open source) 모델로 전환할 수도 있습니다.

기술 이식성 증명 (The Skill Portability Proof)

수렴에 대한 논거는 단순히 이론적인 것이 아닙니다. 저는 이를 직접 테스트했습니다.

Claude Code, Gemini CLI, 그리고 Codex 전반에 걸쳐 기술 (Skill, 재사용 가능한 AI 워크플로)이 정의되는 방식의 차이는 자동화된 마이그레이션 (Migration)이 수월할 정도로 충분히 작아졌습니다. 저는 skillporter라는 도구를 만들었는데, 이는 Claude Code, Codex, Antigravity, Gemini CLI라는 네 가지 주요 플랫폼 간에 어떠한 코딩 에이전트 (Coding-agent) 기술도 단 한 번의 과정으로 이식할 수 있게 해줍니다.