데이터 중력: API 우선 AI의 진정한 비용

왜 당신의 AI 스택은 매월 더 끈적해지나요?

Page content

모든 API 호출은 단순한 트랜잭션처럼 느껴집니다. 하지만 그 호출들이 누적되면, 파인튜닝 데이터, 평가 시스템, 그리고 도메인 스키마가 모두 특정 벤더에 맞춰지게 되며, 이때부터 플랫폼 전환은 단순한 라우팅 변경을 넘어선다는 것을 깨닫게 됩니다.

이것이 바로 데이터 중력(Data Gravity)입니다. AI가 존재하기 훨씬 전부터 AWS S3에서 데이터를 빼내는 데 막대한 비용이 들어갔던 그 원동력과 동일한 힘은 이제 LLM 호스팅 스택의 한 단계 위, 즉 애플리케이션 레이어에서 작동하고 있습니다. 이는 악의적인 계약이나 나쁜 의도의 벤더가 필요하지 않습니다. 이는 복리의 원리로 작용하는 통합 부채입니다. 특정 제공자의 출력 형식에 맞춰 조정된 각 파인튜닝 체크포인트, 캐시된 임베딩, 그리고 평가 시스템은 다음 추가 비용을 낮추지만, 전체 시스템의 이주 비용을 더 비싸게 만듭니다.

data gravity pulling ai workflows toward one provider

이 메커니즘에는 4단계가 있으며, 어느 단계에서도 스스로를 고의적으로 알리지 않습니다. 대부분의 팀은 의도적으로 종속성을 선택하지 않습니다. 그들은 ‘탐색(Exploration)‘에서 ‘통합(Integration)’, 그리고 ‘최적화(Optimization)‘로 자연스럽게 이동하다가, 결국 ‘종속(Dependency)’ 단계에 도달하게 됩니다. 이때 종속성은 선택보다는 아키텍처의 당연한 현실처럼 느껴집니다. 현재 자신이 어느 단계에 있으며, 이를 되돌리는 데 어떤 비용이 발생하는지를 인지하는 것이 이 글의 목적입니다.

메커니즘: 잠금(Lock-In)의 4단계

graph LR A[탐색
Base URL 변경] --> B[통합
워크플로우가
API 구조를 가정함] B --> C[최적화
파인튜닝, 캐시,
벡터 저장소] C --> D[종속
제품 품질 =
벤더의 모델] style A fill:#e8f4fd style B fill:#cfe8fb style C fill:#a8d4f5 style D fill:#6fb3ea

탐색(Exploration). API를 호출하고, 프로토타입을 만들며, 반복합니다. 전환 비용은 낮습니다. Base URL과 키만 변경하면 대부분의 작업이 해결됩니다.

통합(Integration). API의 구조를 기반으로 워크플로우를 구축합니다. 에러 핸들링은 해당 API의 속도 제한 헤더를 가정하며, 재시도 로직은 해당 백오프 커브(Backoff Curves)와 일치합니다. 평가 시스템은 해당 출력 형식에 맞춰 조정됩니다. 이제 전환은 라우팅 변경이 아닌 리팩토링을 의미합니다.

최적화(Optimization). 파인튜닝을 수행하고, 캐시를 구축하며, 해당 제공자의 임베딩 공간, 토큰화 방식, 또는 도메인 호출 스키마에 의존하는 벡터 저장소와 커스텀 파이프라인을 구축합니다. 데이터는 그들의 생태계에 내장됩니다. 이제 전환은 리팩토링이 아닌 재구축을 의미합니다.

종속(Dependency). 제품의 성능은 해당 제공자의 모델 품질에 의존합니다. 자체 호스팅 대안으로 다운그레이드한다는 것은 더 낮은 성능을 수용하겠다는 뜻입니다. 이때 트레이드오프는 아키텍처 차원을 넘어 제품 차원의 문제가 됩니다.

각 단계는 이전 단계를 복리처럼 증폭시킵니다. 탐색 단계에서 종속 단계로의 전환은 드물게 결정처럼 느껴지지 않습니다. 그것은 벤더가 조건을 변경하는 순간까지 ‘진보’처럼 느껴집니다.

왜 지금 중요한가

세 가지 힘이 데이터 중력을 이론적인 개념에서 긴급한 현실로 만들고 있습니다.

오픈웨이트 모델이 성능 격차를 좁히고 있습니다. 2026년 7월 출시된 2.8트릴리온 파라미터의 희소 혼합 전문가(Sparse Mixture-of-Experts) 모델인 문샷 AI(Moonshot AI)의 Kimi K3는 인공지능 분석 지수(Artificial Analysis Intelligence Index)에서 57점을 기록하며 전체 3위를 차지했습니다. 이는 Claude Opus 4.8 및 GPT-5.5와 비견되며, Claude Fable 5 및 GPT-5.6 Sol에는 조금 뒤지지만, 격차는 이제 강요된 타협이 아닌 의도적인 트레이드오프 수준으로 좁혀졌습니다. Qwen과 DeepSeek는 vLLM 및 SGLang 전반에 걸쳐 네이티브 지원을 제공하는 허용적 라이선스 아래 배포됩니다. 특히 코딩 및 인프라 작업의 경우, 오픈웨이트 모델은 프론티어(Frontier) API 품질의 5~15% 이내에서 루틴하게 성능을 발휘합니다. 이는 잠금 비용이 성능 격차보다 결정적인 요인이 될 정도로 충분합니다.

지정학이 데이터 흐름을 분절화하고 있습니다. 2026년 7월, 보안 연구원들은 Claude Code가 2.1.91 버전(2026년 4월 2일)부터 사용자의 시스템 시간대를 Asia/Shanghai 및 Asia/Urumqi와 비교하고, 프록시 호스트명을 알리바바, 바이두, 바이트댄스, 문샷 AI 등 중국 기업 및 AI 연구소 도메인 목록과 스캔한 후, 매칭 결과를 도메인 자체의 시스템 프롬프트에 보이지 않게 인코딩하는 숨겨진 감지 코드를 배포했음을 발견했습니다. Anthropic은 이를 반증류(anti-distillation) 실험이라고 부르며, 알리바바는 2026년 7월 10일부터 직원들에게 Claude Code 사용을 금지하고 회사 인프라에서 Claude 모델 삭제를 지시했습니다. 의도와 상관없이, 이 사건은 국경 간 AI 데이터 흐름이 계약적 위험을 넘어 프로토콜 수준의 위험을 수반하는 세계의 예시입니다. 만약 당신의 데이터와 도메인의 동작이 타인의 런타임에 있다면, 당신은 감사할 수 없는 결정의 대상이 됩니다. 이는 여기서 다루는 전환 비용의 관점이 아닌, 정책 및 관할권 측면에서 LLM 자체 호스팅과 AI 주권이 도달하는 결론과 동일합니다.

메모리 경제가 타이트해지고 있습니다. SK하이닉스 곽노준 회장은 2026년 7월 로이터 통신에 2027년이 메모리 산업 역사상 최악의 공급 부족이 될 것이며, 고객 수요는 “2030년 이후에도” 생산 능력을 초과할 것이라고 밝혔습니다. 같은 달 SambaNova는 추론 하드웨어 제조 규모 확대를 명시적으로 목표로 삼아 110억 달러의 기업 가치로 10억 달러 규모의 시리즈 F 투자 첫 번째 단계를 완료했습니다. API 비용이 무한정 하락한다는 서사는 이미 흔들리고 있었으며, 수년에 걸친 하드웨어 부족은 자체 추론 스택 소유를 취미성 선호가 아닌 전략적 헤지(hedge)로 만듭니다.

진정한 비용은 토큰이 아닙니다

가격 비교는 틀린 프레임입니다. “$0.01(1K 입력 토큰 기준) 대 $0.002(자체 호스팅)“의 문제가 아니라 아키텍처적 종속성의 문제이며, 그 명확한 최근 증거는 OpenClaw의 붕괴입니다.

OpenClaw는 미터법 기반 API 과금이 아닌 고정 요금제인 Pro 및 Max 구독을 통해 Claude를 실행한다는 강점으로 GitHub 스타 수 약 247,000개까지 성장했습니다. 그러나 2026년 4월 4일, Anthropic은 서드파티 도메인에서 이러한 구독 OAuth 토큰을 사용하는 권한을 폐지했습니다. OpenClaw를 계속 사용하려는 사용자는 기존 요금제의 10~50배에 달하는 종량제 billing으로 전환해야 했습니다. 이는 단 4단계인 ‘종속’이 하룻밤 사이에 가시화된 것입니다. 거대한 커뮤니티가 특정 제공자의 고유한 가격 메커니즘을 중심으로 워크플로우를 최적화했기 때문에, 해당 메커니즘이 사라질 때 워크플로우의 경제성은 우아하게 저하되지 않고 파탄났습니다. OpenClaw 대 Hermes 사용 데이터는 이후 몇 달간 상당 부분의 트래픽이 자체 호스팅 및 오픈웨이트 대안으로 이동했음을 보여줍니다.

동일한 패턴은 개별 기업 내부에서도 조용히 발생합니다. 한 제공자의 API를 대상으로 코드 리뷰 에이전트를 구축하는 팀은 해당 제공자 형식의 파인튜닝 데이터, 해당 제공자의 출력 형식에 맞춰 조정된 평가 시스템, 그리고 해당 제공자의 스키마를 기반으로 구축된 도메인 호출 통합 기능을 축적하게 됩니다. 이러한 것들은 토큰 수로 측정되지 않습니다. 이는 당신이 떠날 날에 측정되는 엔지니어링 주(weeks)이며, LLM 아키텍처 클러스터가 호스팅 위의 라우팅, 비용, 가드레일 레이어에서 다루는 것과 동일한 아키텍처적 종속성 문제입니다.

당신의 잠금(Lock-In) 점수 매기기

특정 제공자에 대해 팀이 얼마나 많은 항목을 축적했는지 세어보세요:

종속 요소	해당 항목이 있나요?
제공자 고유의 형식으로 저장된 파인튜닝 데이터셋
제공자의 임베딩 공간에 종속된 캐시된 임베딩
제공자의 출력 형식에 맞춰 조정된 평가 시스템
제공자의 도메인 호출 API를 중심으로 구축된 커스텀 도메인 스키마
제공자의 실패 모드 및 우회 방법에 대한 팀의 고유 지식
특정 모델의 성능 상한선을 가정하는 제품 기능
제공자 고유의 요금제(구독형 대 미터법형)에 종속된 청구 또는 사용 패턴

0-2개 체크: 탐색 - 전환 비용은 여전히 거의 0입니다. 3-5개: 통합 - 실제 리팩토링을 예상하세요. 6개 이상: 최적화 또는 종속 - 이제 당신은 AI 제공자를 선택하는 것이 아니라, 그들에게 아키텍처를 임대하고 있습니다. 이 수치 자체가 경고 신호이며, 이를 계산하는 데는 아무런 비용이 들지 않습니다.

자체 호스팅의 실제 비용과 비비용

경제적 요인은 실제적이지만 잠금 문제보다 부차적입니다. LLM 시스템 비용 최적화는 하드웨어 분기점(Break-even) 산술을 상세히 설명합니다. 하루 1시간 이상의 로컬 사용 시, RTX 4090과 같은 소비자용 GPU는 일반적으로 4~8개월 내에 동등한 API 사용 비용 대비 자체 투자 비용을 회수합니다. $/토큰 비교에 대한 분석은 그곳이 적절한 곳입니다. 여기서 반복할 점은 분기점 계산은 포트빌리티(이동성)를 최적화할 가치가 있다고 결정한 후에야 의미가 있다는 것입니다. 종속 단계에 깊게 빠진 팀은 종종 마이그레이션 비용이 하드웨어 절감액보다 훨씬 큼을 발견하는데, 이는 바로 이 글이 다루는 함정입니다.

해독제: 전략으로서의 포트빌리티

목표는 API를 피하는 것이 아닙니다. 선택하지 않은 단계로 표류하는 대신, 의식적인 선택을 할 수 있도록 데이터 레이어를 충분히 오래 포트빌(이동 가능)하게 유지하는 것입니다.

로컬에서 시작하고, 의도적으로 원격으로 확장하세요. 자체 호스팅 모델로 프로토타이핑을 하세요 - llama.cpp, GGUF 양자화, 또는 로컬 호스팅 도구의 전체 비교를 통해 스택을 선택하세요. 작업이 진정으로 프론티어 성능이 필요할 경우, 그 특정 작업에 API를 사용하되 데이터 레이어가 어떤 모델이 답변했는지와 분리되어 있도록 유지하세요.

품질 격차가 좁을 경우, 폐쇄형 API보다 오픈웨이트를 선호하세요. Kimi K3, Qwen, Gemma, DeepSeek와 같이 오픈웨이트로 배포되는 모델의 경우, 실행, 파인튜닝, 양자화를 수행하고 엔드투엔드 관계를 소유할 수 있습니다. 성능 격차는 알려진, 축소되고 있는, 작업 의존적인 트레이드오프입니다. 반면 잠금 격차는 떠날 때까지 그 크기를 알리지 않는 느리게 움직이는 함정입니다.

실제로 중요한 곳에 추상화를 구축하세요. “모든 것을 인터페이스 뒤로 감싸라"는 규칙은 문제를 해결하지 않고 단지 지연시킵니다. 데이터 형식, 평가 로직, 도메인 스키마를 중심으로 추상화를 구축하세요: 프레임워크 독립적인 형식(JSONL, parquet)의 파인튜닝 데이터셋, 특정 API의 응답 형식이 아닌 모델 출력을 점수화하는 평가 시스템, 그리고 하나에 맞춰 작성된 것이 아닌 각 제공자의 스키마로 번역되는 도메인 호출 로직을 구축하세요.

단일 제공자에 커밋하는 대신 의도적으로 라우팅하세요. [모델 라우팅 전략](https://www.glukhov.org/ko/llm-architecture/model-routing/model-routing-strategies/ “모델 라우팅: 모든 것에 하나의 모델을 사용하지 마세요”}) - 성능 기반, 비용 인식, 지연 시간 인식 - 은 루틴 트래픽을 로컬 모델로, 모호한 사례를 프론티어 API로 보내도록 하여 단일 벤더 주변의 최적화 단계로 표류하는 대신 통합 단계에 무한정 머물게 합니다.

정기적으로 잠금 수준을 정량화하세요. 제공자별로 분기마다 위의 점수 매기기 표를 다시 실행하세요. 수치가 상승할 때, 그것은 누군가 명시적인 결정을 했는지와 상관없이 데이터 중력이 작동하고 있다는 증거입니다.

실제 사례

설계상 데이터 중력에 저항하는 실용적인 스택:

추론: 로컬 단일 머신 서빙을 위한 llama.cpp; 프로덕션 등급 자체 호스팅 처리량을 위한 vLLM 또는 SGLang. 이 세 가지 모두 OpenAI 호환 API를 노출하므로 애플리케이션 코드는 그 뒤에 무엇이 있는지 알 필요가 없습니다.
파인튜닝: 표준 형식(JSONL, parquet)으로 저장된 데이터셋 - 제공자의 독점적 파인튜닝 작업 형식이 아님.
평가: API 응답 포장이 아닌 출력을 점수화하는 프레임워크 독립적 평가 시스템, 따라서 모델이 로컬이거나 원격이더라도 동일한 평가 스위트가 실행됨.
도메인 호출: 특정 제공자의 형식에 직접 작성된 애플리케이션 로직이 아닌, 각 벤더의 도메인 호출 형식으로 번역되는 제공자 독립적 JSON 스키마.
벡터 저장소: Qdrant, Milvus, Chroma와 같은 로컬 우선 옵션, 단일 제공자의 임베딩 엔드포인트에 종속되지 않고 포트빌 라이브러리를 통해 계산된 임베딩 - RAG의 청킹 전략에서 이것이 검색 레이어에 어떻게 부합하는지 참조.

이는 자체 호스팅 선언문이 아닙니다. 많은 워크로드가 영구적으로 프론티어 API에 속해야 합니다. 이는 데이터 중력을 측정하고 관리할 수 있는 엔지니어들이 - 벤더가 가격표를 변경하는 날에 이를 발견하는 대신 - 더 적은 옵션이 아닌 더 많은 옵션을 가진다는 것을 인식하는 것입니다.

결론

데이터 중력이 오픈웨이트 성능이 단일 벤치마크 점수보다 중요한 이유입니다. 프론티어 모델의 85~95% 품질로 로컬에서 실행되는 모델은 종종 더 나은 아키텍처적 선택입니다. 왜냐하면 당신은 데이터 관계를 유지하기 때문입니다. GPT-5.6 Sol, Fable 5, Kimi K3, Qwen 간의 프론티어 경쟁은 진정으로 흥미롭지만, 그 아래의 인프라 레이어 - 누가 파인튜닝 데이터를 소유하는지, 도메인이 어떤 스키마로 말하는지, 워크플로우가 어떤 가격 모델을 가정하는지 - 가 3년 후 어떤 팀이 옵션을 가지고 있고, 어떤 팀이 아키텍처를 타인에게 임대하고 있는지를 실제로 결정합니다.

벤더의 가격표가 당신에게 그 질문을 강요하기 전에 당신의 잠금 수준을 점수 매기세요.