많은 이들이 늪지 위에 대성당을 짓고 있다

AI 개발의 토대는 매 분기 변화합니다. 이것은 급격한 변화 속에서도 살아남을 수 있는 아키텍처 (Architectural) 선택에 관한 이야기입니다.

중세의 대성당들은 건축가들보다 더 오래 살아남도록 설계되었습니다. 노트르담 (Notre-Dame)의 첫 초석을 놓았던 건축가들은 자신들이 완공된 모습을 결코 보지 못할 것임을 알고 있었습니다. 그들은 수 세기 단위로 계획을 세웠습니다.

우리는 정반대로 하고 있습니다. 우리는 매 분기 변화하는 토대 위에 소프트웨어를 구축하고 있으며, 진정으로 경쟁력 있는 상업적 제공업체를 중립적인 인프라 (Infrastructure)로 취급하는 벤더 관계 (Vendor relationships)를 맺고 있으며, 다음 스프린트 (Sprint) 주기 이전에 폐기될 동작들을 코드에 하드코딩 (Hard-codes)하고 있습니다.

GPT-4는 2023년 초에 최첨단 (State of the art) 기술이었습니다. 2024년 말에는 중간 수준에 머물렀습니다 [1]. 특정 모델의 동작에 기반하여 구축된 전체 스타트업들이 자신들의 핵심 가정이 사라졌음을 깨달으며 깨어났습니다. 틀린 것도 아니었고, 마이그레이션 가이드 (Migration guide)와 함께 폐기된 것도 아니었습니다. 그저 사라졌거나, 조용히 변경되었거나, 혹은 기존의 프롬프트 (Prompts)가 더 이상 작동하지 않을 정도로 너무나 다른 무언가에 의해 대체되었을 뿐입니다.

이것이 리더로서 우리가 지나가고 있는 지형입니다.

질문은 지면이 변할 것인가가 아닙니다. 지면이 변했을 때 당신의 아키텍처 (Architecture)가 이를 감당할 수 있는가입니다.

아직 부어지고 있는 토대에 베팅하는 것의 문제점

제가 있는 위치에서 바라본 지난 몇 년간의 모습은 다음과 같습니다:

• 2022: GPT-3가 명백한 선택지였습니다. 그 위에 구축하십시오.
• 2023: GPT-4가 모든 것을 바꿉니다. 다시 구축하거나 뒤처지거나 둘 중 하나입니다.
• 2023 (하반기): Claude 2, 오픈 소스 모델 (open-source models), 로컬 추론 (local inference). 갑자기 정답이 명확하지 않게 되었습니다.
• 2024: GPT-4o, Claude 3 Opus, Gemini Ultra, Llama 3. 모두 경쟁력이 있습니다. 모두 다릅니다.
• 2025: 추론 모델 (Reasoning models), 멀티모달 (multimodal), 에이전트 (agents). 아키텍처 (architecture)에 대한 질문이 훨씬 더 어려워집니다.
• 2026: 도구와 하네스 (tools and harnesses)가 성숙해지고, 워크플로우 (workflows)가 안정화되며, 스웜 (swarms)은 작업을 병렬화하는 데 더 능숙해지고, 팀들은 토크노믹스 (tokenomics)를 고민하기 시작합니다. 모델은 범용화 (commodity)되고 있습니다. 로컬 오픈 소스 모델이 프런티어 모델 (frontier model)의 성능에 훨씬 더 가까워집니다. 중국의 AI 생태계 전반에 걸친 조율 능력은 미국 AI 생태계에 맞서 실질적인 이득을 보여주고 있습니다.

이러한 모든 전환기에는 승자와 패자가 발생했으며, 패자는 거의 항상 특정 모델의 API에 가장 밀접하게 결합된 (tightly-coupled) 솔루션을 구축했던 팀들이었습니다.

그 팀들이 형편없는 엔지니어였기 때문이 아닙니다. 잘못된 것을 위해 최적화했기 때문입니다. 그들은 기반의 변화 (foundation-change)를 위해 구축하는 대신, 오늘의 기반 (foundation)을 위해 구축하고 있었습니다.

지원 종료 (deprecation) 공지들이 그 이야기를 증명합니다. Anthropic이 모델을 은퇴시키기 전에 명시한 최소 공지 기간은 60일이며, 최근 몇몇 모델이 정확히 그 하한선에 도달했습니다 [2]. Claude Sonnet 4와 Claude Opus 4는 출시 후 1년도 채 되지 않아 완전히 은퇴했습니다. 많은 팀이 기반으로 삼았던 구조적 토대인 OpenAI의 Assistants API 제품 전체가 2026년 8월에 제거될 예정이며, 이에 따라 Responses API로의 완전한 마이그레이션 (migration)이 필요합니다 [3]. 이것은 단순한 지원 종료가 아닙니다. 마감 기한이 정해진 철거입니다.

출시 속도가 이를 가중시킵니다. 프런티어 모델의 출시는 2023년에 대략 37일마다 한 번꼴로 이루어졌습니다. 2026년에 이르러 그 간격은 대략 11일마다 한 번꼴로 압축되었습니다 [4]. 지면은 단순히 움직이는 것이 아닙니다. 매년, 매 분기, 매월, 매주 더 빠르게 움직이고 있습니다.

클라우드 네이티브 (cloud-native) 운동은 10년 전 이 사실을 혹독한 경험을 통해 깨달았습니다. 승리한 팀들은 AWS만을 영원히 사용할 것이라고 가정하는 코드를 작성하지 않았습니다. 그들은 AWS를 유틸리티 (utility)로 취급하고, 자신들이 제어하는 인터페이스 (interface) 뒤로 추상화하며, 하이브리드 클라우드 (hybrid cloud) 환경을 수용할 수 있는 API를 사용했습니다. 제가 목격하는 인수 합병 (M&A) 거래에서, 인수 대상 기업을 구매자와 동일한 클라우드 제공업체를 사용하는 회사로만 제한하는 것은 수용 가능한 제약 조건인 경우가 거의 없습니다. 이는 가능한 경우 컨테이너화된 애플리케이션 (containerized applications), 데이터베이스 추상화 계층 (database abstraction layers), 그리고 벤더 중립적인 코드형 인프라 (vendor-agnostic infrastructure-as-code)를 사용해야 함을 의미합니다.

같은 교훈입니다. 시대만 다를 뿐입니다. 왠지 우리는 이것을 다시 처음부터 배우고 있습니다. 오래된 것이 다시 새로운 것이 됩니다.

실제로 변하는 것 vs. 안정적으로 유지되는 것

여기서 유용하고 (또한 단순한) 사고 모델은 다음과 같습니다:

AI(또는 모든 광범위한 기술 카테고리)의 일부 개념은 안정적입니다. 일부는 그렇지 않습니다. 여러분의 아키텍처 (architecture)는 안정적인 것들만을 하드코딩 (hard-code)해야 합니다.

안정적인 것: 토큰 (tokens), 어텐션 메커니즘 (attention mechanisms), 개념으로서의 컨텍스트 윈도우 (context windows), 개념으로서의 임베딩 (embeddings), 기본적인 프롬프트-완성 (prompt-completion) 패턴, 프롬프트 증강을 위한 접근 방식으로서의 검색 증강 생성 (RAG, retrieval-augmented generation).

불안정한 것: 특정 API 파라미터 (parameters), 모델별 프롬프트 형식 (prompt formats), 컨텍스트 윈도우 크기 (계속 커지고 있지만, 예측 가능한 결과를 위한 최대 사용 가능 윈도우는 아직 크게 늘어나지 않았습니다... 아직은 말이죠), 가격 구조, 속도 제한 (rate limits), 보장된 사항으로 문서화되지 않은 특정 모델의 동작, 파인튜닝 (fine-tuning) API, 함수 호출 (function-calling) 구문.

엔지니어들이 모델별 동작을 비즈니스 로직 (business logic)에 하드코딩할 때, 그들은 알 수 없는 (하지만 거의 확실히 발생할) 만료 날짜를 가진 코드를 작성하고 있는 것입니다. 하지만 만약 그들이 팀이 제어하는 인터페이스 뒤로 이러한 동작들을 추상화한다면, 그들은 자신들에게 선택권 (optionality)을 부여하는 것입니다.

모델 중립적인 (model-agnostic) 인프라를 구축할 때 여러분이 실제로 만들고 있는 제품은 바로 선택권 (optionality)입니다.

한 가지 구체적인 예로 프롬프트 템플릿 (prompt templates)이 있습니다. 프롬프트를 애플리케이션 코드에 직접 작성하여 GPT-4가 선호하는 패턴에 맞춰 특화된 형식을 사용한 팀들은, 모델을 전환해야 할 때 실제로 막대한 마이그레이션 (migration) 작업을 수행해야 했습니다. 반면, 프롬프트를 설정 (configuration)으로 외부화하고 모델별로 형식을 재구성할 수 있는 얇은 계층 (thin layer)을 둔 팀들은 훨씬 수월하게 대처했습니다. 근본적인 로직은 동일하지만, 운영 태세 (operational posture)는 매우 달랐습니다.

벤더 락인 (Vendor Lock-In) 문제 (다시 한번)

OpenAI, Anthropic, 그리고 Google은 중립적인 인프라 제공업체가 아닙니다.

이들을 비판하기 위해 이런 말을 하는 것이 아닙니다. 그들은 놀라운 기술을 구축하고 있습니다. 하지만 그들에게는 여러분이 필요로 하는 안정적이고 예측 가능한 인프라와는 일치하지 않는 상업적 이익, 경쟁 압박, 그리고 전략적 우선순위가 있습니다. 그들을 AWS S3처럼 취급하는 것은 전략적으로 순진한 생각입니다.

AWS S3는 2006년 출시 이후 20년 동안 완전한 API 하위 호환성 (backward compatibility)을 유지해 왔습니다. AWS의 자체 20주년 게시물에서도 이를 명확히 밝히고 있습니다: "2006년에 S3를 위해 작성한 코드는 오늘날에도 변경 없이 그대로 작동합니다" [5]. 이는 AWS가 S3를 내구성이 있는 유틸리티 인프라 (utility infrastructure)로 구축했으며, 그들의 비즈니스 모델이 여러분의 데이터가 그곳에 머무는 것에 달려 있기 때문입니다.

프런티어 모델 (frontier model) 제공업체들은 경주 중입니다. 그들은 반드시 그래야만 하기 때문에 빠르게 반복 (iterating)하고 있습니다. 그들은 여러분의 배포 안정성이 아니라, 자신들의 경쟁적 지위에 도움이 되는 일정에 맞춰 동작을 변경하고, 모델을 지원 종료 (deprecating)하며, 가격을 조정하고, 새로운 기능을 출시합니다.

AI 제공업체를 유틸리티로 취급하는 팀들은 자신들이 통제할 수 있는 추상화 계층 (abstraction layers)을 구축하고 있는 것입니다. 이는 다음과 같은 것을 의미합니다:

• 애플리케이션과 모델 제공업체 사이에 위치하는 LLM 게이트웨이 (gateway) 또는 라우터 (router).
• 비즈니스 로직을 건드리지 않고도 기반 모델을 교체할 수 있게 해주는 모델 불가지론적 (model-agnostic) 인터페이스.
• 직관이 아닌 증거를 바탕으로 전환 결정을 내릴 수 있도록 여러 모델에 걸쳐 작동하는 평가 프레임워크 (evaluation frameworks).

개인/팀/프로젝트를 위한 예산 제어 기능, 내장된 OTEL 관측성 (observability), 훅 (hooks, DLP, 평가(evals) 또는 기타 검사 추가용), 그리고 자동화나 통합을 위한 완전한 명령줄 관리 (command-line admin) 기능을 갖추고 Claude와 제가 Rust로 작성한 모델 불가지론적 (model-agnostic) 인터페이스의 라우터에 대해서는 https://github.com/keithmackay/modelrouter를 참조하세요.

MCP (Model Context Protocol)의 등장은 업계가 독립적으로 이러한 결론에 도달했다는 증거 그 자체입니다. Anthropic은 2024년 11월에 MCP를 도입했고, 2025년 12월에는 벤더 중립적인 거버넌스를 위해 이를 Linux Foundation에 기부했습니다. 이 시점에 MCP는 월간 SDK 다운로드 수가 9,700만 회에 달했으며 OpenAI, Google DeepMind, Microsoft에 의해 채택되었습니다 [6]. MCP는 AI 모델이 외부 도구 및 데이터 소스에 연결하는 방식을 표준화합니다. 이는 실제적이고 유용합니다. 하지만 이것이 무엇을 해결할까요? MCP는 도구 통합의 이식성 (portability) 문제를 다룹니다. MCP는 프롬프트 동작, 컨텍스트 처리 (context handling), 추론 모델 API (reasoning model APIs), 또는 지원 종료 일정 (deprecation schedules)을 표준화하지는 않습니다. 여러분의 애플리케이션과 요청을 처리하는 모델 사이에 위치하는 추상화 계층 (abstraction layer)은 여전히 여러분의 팀이 구축해야 합니다.

아직 이 문제를 파악하지 못한 팀들은 제공업체를 전환하는 것이 수개월이 걸리는 엔지니어링 프로젝트가 되는 곳들입니다. 이것은 기술적인 문제가 아닙니다. 이는 시간이 갈수록 심화될 아키텍처 설계의 선택 (architectural choice) 문제입니다.

깊게 머물러야 하는 이유

추상화 계층을 구축하기 전에, 여러분이 무엇을 포기하게 되는지 알아야 합니다.

Claude는 XML 구조화된 프롬프트에 더 잘 반응합니다. GPT-4.x는 JSON 구분 기호가 있는 지침에 더 잘 반응합니다. Gemini는 컨텍스트를 다르게 처리합니다. 모델 간의 최소 공통 분모에 맞춰 프롬프트를 작성하거나, 모델별 변형을 유지한다면 (이는 숨겨진 결합 (hidden coupling)일 뿐입니다), 여러분은 이식성을 위해 최적화의 여유 공간 (optimization headroom)을 맞바꾸는 것입니다.

각 게이트웨이 홉 (gateway hop)은 지연 시간 (latency)을 추가합니다. 실시간 음성 인터페이스나 200ms 미만의 UX 목표를 위해서는, 그 오버헤드는 이론적인 것이 아니라 실제적인 엔지니어링 제약 사항입니다 [7].

또한 가격 책정의 역사에서 비롯된 역설적인 논거도 있습니다. GPT-4 토큰 가격은 별도의 마이그레이션 (migration) 없이도 출시 당시 100만 입력 토큰당 30달러에서 2024년 말 기준 약 3달러로 17개월 만에 약 9배 하락했습니다 [8]. 이 기간 동안 GPT-4를 깊게 사용해 온 팀들은 전환 비용(switching cost) 없이 이러한 비용 압축을 누릴 수 있었습니다. 문제는 다음 가격 변동이 당신에게 유리하게 작용할지, 그리고 당신이 기다릴 여유가 있는지 여부입니다.

모델 불가지론적 (model-agnostic) 논거는 "추상화 계층 (abstraction layers)에 비용이 들지 않는다"는 것이 아닙니다. 비용은 발생합니다. 핵심 논거는 그러한 계층이 없을 때 발생하는 계획되지 않은 마이그레이션의 비용이 더 높으며, 마이그레이션 이벤트는 _피할 수 없다_는 것입니다. 당신은 단지 그 상황에 맞이할 준비가 되었는지를 선택하고 있을 뿐입니다. Anthropic의 최소 지원 종료 (deprecation) 통보 기간이 60일이고 OpenAI의 Assistants API가 완전히 사라지고 있다는 점을 고려할 때, "필요할 때 처리하겠다"는 계획은 이미 많은 팀에게 실패로 돌아갔습니다.

모델 불가지론적 아키텍처의 모습

이를 위해 과도한 엔지니어링 (over-engineer)을 할 필요는 없습니다. 목표는 추상화 그 자체를 위한 추상화가 아니라, 적절한 추상화 계층을 구축하는 것입니다.

LLM 게이트웨이 계층 (LLM gateway layer). 모든 AI 호출이 통과하는 단일 내부 서비스입니다. 이 계층은 라우팅 (routing), 속도 제한 (rate limiting), 비용 추적 (cost tracking), 모델 선택 (model selection), 그리고 장애 조치 (failover)를 처리합니다. 애플리케이션 코드는 자신이 GPT-4o와 통신하고 있는지, Claude 3.5와 통신하고 있는지, 혹은 로컬 Llama 배포본과 통신하고 있는지 알 필요도 없고 신경 쓸 필요도 없습니다. 그것이 게이트웨이의 역할입니다. 이를 조기에 구축한 팀들은 현재 유의미한 운영상의 이점을 누리고 있습니다. 시장은 이를 빠르게 인식했습니다. 가장 널리 배포된 오픈 소스 LLM 프록시 (proxy)인 LiteLLM은 10억 건 이상의 요청을 프록시했으며, 2026년 중반 기준 GitHub 스타가 거의 48,000개에 달합니다 [9]. Gartner는 2028년까지 멀티 LLM 애플리케이션을 구축하는 조직의 70%가 AI 게이트웨이 기능을 사용할 것이라고 예측하며, 이는 2024년의 5% 미만에서 크게 증가한 수치입니다 [10].

프롬프트 이식성 (Prompt portability). 프롬프트를 외부화하세요. 애플리케이션 코드와 별도로 버전 관리 (Version control)를 수행하세요. 서로 다른 모델 제품군 (Model families)에 맞춰 프롬프트 형식을 재구성할 수 있는 얇은 번역 계층 (Translation layer)을 구축하세요. 이는 마이그레이션 (Migration)이 필요한 날이 오기 전까지는 오버헤드 (Overhead)처럼 들리겠지만, 그날이 되면 그것은 선견지명처럼 느껴질 것입니다 [11].

모델 불가지론적 평가 (Model-agnostic evaluation). 새로운 모델이 귀하의 사용 사례 (Use case)에 더 나은지 어떻게 알 수 있을까요? 특정 모델의 출력 형식 (Output format)을 가정하고 작성되지 않은 평가 (Evals)가 필요합니다. GPT-4가 우연히 생성한 결과물이 아니라, 귀하가 실제로 중요하게 생각하는 동작을 기준으로 품질 벤치마크 (Quality benchmarks)를 구축하세요 [12].

모델 특정적 기능의 함정 피하기. 모든 프론티어 모델 (Frontier model)에는 매력적으로 보이지만 해당 모델에서만 사용할 수 있는 기능들이 있습니다. 그중 일부는 사용할 가치가 있습니다. 하지만 단 하나의 제공업체에서만 사용할 수 있는 기능 위에 핵심 비즈니스 역량을 구축할 때마다, 귀하는 스스로에게 몸값 요구서 (Ransom note)를 쓰고 있는 것과 같습니다.

테스트 방법: 만약 내일 Anthropic이나 OpenAI가 가격을 5배 인상한다면, 전환하는 데 얼마나 걸리겠습니까? 만약 그 대답이 몇 주 이상이라면, 귀하는 조용히 쌓여가고 있는 아키텍처 부채 (Architectural debt)를 안고 있는 것입니다.

이를 제대로 수행하고 있는 조직들

그들에게는 몇 가지 공통점이 있습니다.