데이터 중력: API-퍼스트 AI의 실제 비용

AI 스택이 매월 더욱 강하게 고정되는 이유

Page content

모든 API 호출은 단순한 거래처럼 느껴집니다. 하지만 그 수가 쌓이면, 파인튜닝 데이터, 평가 하네스, 도구 스키마가 모두 하나의 벤더 주위에 형성되어, 벤더 전환이 더 이상 단순한 라우팅 변경이 아닌 상황이 됩니다.

이것이 데이터 중력입니다. AI가 출현하기 훨씬 전부터 AWS S3에서 데이터를 끌어오는 데 큰 비용이 드는 원인인 동일한 힘이, 지금은 LLM 호스팅 스택 한 단계 위에서 작용하고 있습니다. 이는 나쁜 계약이나 악의적인 벤더를 요구하지 않습니다. 이는 복리로 쌓이는 통합 부채입니다 - 파인튜닝된 체크포인트, 캐싱된 임베딩, 특정 제공자의 출력 형식에 맞춰 조율된 평가 하네스까지 모두 다음 요소를 추가하는 비용은 줄이면서 전체를 이전하는 비용은 더 비싸게 만듭니다.

data gravity pulling ai workflows toward one provider

이 메커니즘에는 네 가지 단계가 있으며, 어느 것도 스스로를 알리지 않습니다. 대부분의 팀이 의존성이 되고 싶어서 의식적으로 결정하지는 않습니다. 탐색(Exploration)에서 통합(Integration)으로, 그리고 최적화(Optimization)로, 최종적으로 의존성(Dependency)에 이르렀을 때 그것은 선택이 아니라 아키텍처의 당연한 사실처럼 느껴집니다. 자신이 현재 어떤 단계에 있는지, 그리고 그것을 되돌리는 데 드는 비용이 얼마인지를 인식하는 것이 이 글의 핵심 목적입니다.

메커니즘: 잠금(Lock-In)의 네 가지 단계

graph LR A[Exploration
swap a base URL] --> B[Integration
workflows assume
the API's shape] B --> C[Optimization
fine-tunes, caches,
vector stores] C --> D[Dependency
product quality =
vendor's model] style A fill:#e8f4fd style B fill:#cfe8fb style C fill:#a8d4f5 style D fill:#6fb3ea

탐색 (Exploration). API를 호출하고, 프로토타입을 만들고, 반복합니다. 전환 비용은 낮습니다 - 베이스 URL과 키를 변경하는 것이 대부분의 전환 비용을 커버합니다.

통합 (Integration). API의 형태에 맞춰 워크플로우를 구축합니다. 오류 처리는 해당 API의 레이트리밋 헤더를 가정합니다. 재시도 로직은 해당 API의 백오프 곡선을 따릅니다. 평가 하네스는 해당 API의 출력 형식에 맞게 조정됩니다. 지금 전환한다는 것은 라우팅 변경이 아니라 리팩토링을 의미합니다.

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

의존성 (Dependency). 제품 성능이 해당 제공자의 모델 품질에 의존합니다. 셀프호스트드 대안으로 하위 호환(Downgrade)하는 것은 더 낮은 능력을 수용하는 것을 의미합니다. 트레이드오프가 아키텍처 수준에서 제품 수준으로 변합니다.

각 단계는 이전 단계를 복리로 증폭시킵니다. 탐색에서 의존성으로의 전환은 거의 결정처럼 느껴지지 않습니다 - 벤더가 조건을 변경하는 그 순간까지, 그것은 그저 진전처럼 느껴집니다.

왜 지금 이것이 중요한가

세 가지 힘이 데이터 중력을 이론적 개념이 아닌 시급한 문제로 만들고 있습니다.

오픈웨이트 모델들이 능력 격차를 줄이고 있습니다. 2026년 7월에 출시된 2.8조 파라미터의 희소 혼합 전문가(sparse mixture-of-experts) 모델인 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에서 네이티브 지원을 제공합니다. 특히 코딩 및 인프라 작업의 경우, 오픈웨이트 모델은 프론티어 API 품질의 5~15% 이내에 있는 것이 일반적입니다 - 즉, 능력을 결정하는 요인이 능력 격차가 아니라 잠금(lock-in) 비용이 되는 수준까지 근접했습니다.

지정학이 데이터 흐름을 파편화시키고 있습니다. 2026년 7월, 보안 연구자들은 Claude Code가 2.1.91 버전(2026년 4월 2일)부터 사용자의 시스템 타임존을 Asia/Shanghai와 Asia/Urumqi와 대조하고, 알리바바, 바이두, 바이트댄스, Moonshot AI를 포함한 중국 기업 및 AI 연구소 도메인 목록과 프록시 호스트명을 스캔하는 은밀한 탐지 코드를 배포하고 있음을 발견했습니다. 그리고 매치를 해당 도구의 자체 시스템 프롬프트에 눈에 띄지 않게 인코딩했습니다. Anthropic은 이를 오틸레이션 방지(anti-distillation) 실험이라 불렀으며, 알리바바는 2026년 7월 10일부터 직원들의 Claude Code 사용을 금지하고 회사 인프라에서 Claude 모델 삭제 명령을 내리는 것으로 대응했습니다. 의도가 무엇이든, 이 사건은 국경을 넘는 AI 데이터 흐름이 계약적 리스크를 넘어 프로토콜 수준의 리스크를 수반하는 세계의 예고편입니다. 만약 당신의 데이터와 도구의 행동이 다른 사람의 런타임에 존재한다면, 당신은 감사할 수 없는 결정의 대상이 됩니다 - 이는 여기서 다루는 전환 비용 측면이 아닌, 정책과 관할권 측면에서 동일한 결론에 도달한 LLM 셀프호스팅과 AI 주권의 관점과 일치합니다.

메모리 경제가 조여지고 있습니다. SK하이닉스 대표이사 곽노종은 2026년 7월 로이터와의 인터뷰에서 2027년이 메모리 산업史上最의 공급 부족이 될 것이며, 고객 수요는 “2030년 이후에도” 생산 용량을 초과할 것으로 예상한다고 말했습니다. 같은 달 SambaNova는 추론 하드웨어 제조를 확장하기 위해 $110억 밸류에이션으로 $10억 시리즈 F 첫 번째 트랜치를 마무리했습니다. API 비용이 무한정 하락한다는 서사는 이미 불안정했습니다. 수년에 걸친 하드웨어 부족은 추론 스택 소유를 취미적인 선호가 아닌 전략적 헤지로 만듭니다.

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

가격 비교는 틀린 프레임입니다. “입력 토큰 1K당 $0.01 대 셀프호스트드 $0.002"가 아닙니다. 그것은 아키텍처적 의존성이며, 가장 명확한 최근의 증거는 OpenClaw의 붕괴입니다.

OpenClaw는 계량된 API 과금 대신 정액제 Pro 및 Max 구독을 통해 Claude를 실행하는 강점으로 약 247,000개의 GitHub 스타를 획득했습니다. 2026년 4월 4일, Anthropic은 제3자 도구에서 해당 구독 OAuth 토큰을 사용할 수 있는 권한을 철회했습니다. Claude를 사용하여 OpenClaw를 계속 실행하고 싶은 사용자는 이전 플랜의 유효 비용의 10~50배가 되는 사용량 과금(pay-as-you-go)으로 전환해야 했습니다. 이것이 바로 4단계인 의존성(Dependency)이 거의 하룻밤 사이에 가시화된 것입니다: 거대한 커뮤니티가 특정 벤더의 특정 과금 메커니즘 주위로 전체 워크플로우를 최적화했고, 그 메커니즘이 사라졌을 때 워크플로우의 경제학은 점진적으로 저하되지 않고 깨졌습니다. OpenClaw 대 Hermes 사용량 데이터는 그 직후 몇 달간 상당한 양의 트래픽이 셀프호스트드 및 오픈웨이트 대안으로 이동했음을 보여줍니다.

동일한 패턴은 개별 기업 내부에서도 조용히 나타납니다. 특정 벤더의 API에 맞서 코드 리뷰 에이전트를 구축하는 팀은 해당 벤더의 형식으로 파인튜닝 데이터를 축적하고, 해당 벤더의 출력 형태에 맞게 조율된 평가 하네스와, 해당 벤더의 스키마 주위에 구축된 도구 호출 통합을 축적합니다. 그 중 어느 것도 토큰으로 측정되지 않습니다. 떠나는 날에 필요한 엔지니어링 주(week) 단위로 측정됩니다 - 호스팅 위쪽의 라우팅, 비용, 가드레일 레이어에서 다루는 LLM 아키텍처 클러스터와 동일한 아키텍처적 의존성 문제입니다.

나의 잠금(Lock-In) 수준을 어떻게 점수화하나요

특정 벤더에 대해 팀이 축적한 아래 항목의 수를 세어보세요:

의존성 항목 이 항목을 가지고 있나요?
벤더 전용 형식으로 저장된 파인튜닝 데이터셋
벤더의 임베딩 공간에 묶인 캐싱된 임베딩
벤더의 출력 형태에 맞게 조율된 평가 하네스
벤더의 도구 호출 API 주위에 구축된 커스텀 도구 스키마
특정 벤더의 장애 모드와 우회 방안 주위에서 형성된 팀 지식
특정 모델의 능력 한계를 가정하는 제품 기능
벤더 전용 플랜(구독 대 계량)에 묶인 과금 또는 사용 패턴

02개 체크: 탐색(Exploration) - 전환 비용은 여전히 거의 0에 가깝습니다. 35개: 통합(Integration) - 실질적인 리팩토링을 예상하세요. 6개 이상: 최적화(Optimization) 또는 의존성(Dependency) - 이제 당신은 AI 제공자를 선택하는 것이 아니라, 그들에게 아키텍처를 임대하는 것입니다. 그 수 자체가 경고 신호이며, 계산하는 데 비용이 들지 않습니다.

셀프호스팅의 실제 비용 - 그리고 비용이 되지 않는 것

경제학적 측면은 실재하지만, 잠금(lock-in) 문제 다음으로 중요합니다. LLM 시스템 비용 최적화는 하드웨어 손익분기점 계산을 상세히 다룹니다 - 하루 1시간 이상의 로컬 사용량이면, RTX 4090과 같은 컨슈머 GPU는 동등한 API 지출에 대해 일반적으로 4~8개월 내 투자비를 회수합니다. 그 분석이 $/토큰 비교에 맞는 장소입니다; 여기서 반복할 가치가 있는 점은 손익분기점 계산이 포터빌리티(이동성)를 최적화할 가치가 있다고 결정한 후에만 의미가 있다는 것입니다. 의존성(Dependency) 단계에 깊숙이 들어간 팀들은 종종 마이그레이션 비용이 어떤 하드웨어 절약 효과보다 훨씬 크다는 것을 발견하는데, 이것이 바로 이 글이 다루고 있는 함정입니다.

항독제: 포터빌리티를 전략으로

목적은 API를 피하는 것이 아닙니다. 선택하지 않은 단계로 표류하는 대신 의도적인 선택을 할 수 있도록 데이터 레이어를 충분히 긴 기간 동안 이동 가능한 상태로 유지하는 것입니다.

로컬에서 시작하고, 의도적으로 원격으로 이동하세요. 셀프호스트드 모델로 프로토타입을 만드세요 - llama.cpp, GGUF 양자화, 또는 로컬 호스팅 도구의 완전한 비교를 통해 스택을 선택하세요. 작업이 진정으로 프론티어 능력이 필요할 때, 그 특정 작업을 위해 API를 사용하세요 - 하지만 데이터 레이어는 어떤 모델이 응답했는지와 분리하여 유지하세요.

품질 격차가 작을 때 폐쇄형 API보다 오픈웨이트를 선호하세요. 모델이 오픈웨이트로 출시될 때 - Kimi K3, Qwen, Gemma, DeepSeek - 여러분은 이를 실행하고, 파인튜닝하고, 양자화하고, 관계를 끝까지 소유할 수 있습니다. 능력 격차는 알려진, 축소되는, 작업에 의존하는 트레이드오프입니다. 반면, 잠금(lock-in) 격차는 떠나기 전까지는 크기를 알리지 않는 느리게 움직이는 함정입니다.

실제로 중요한 곳에 추상화를 구축하세요. “모든 것을 인터페이스 뒤에 감싸라"는 규칙이 아닙니다 - 그것은 문제를 해결하지 않고 지연시키는 규칙입니다. 데이터 형식, 평가 로직, 도구 스키마 주위로 구체적으로 추상화를 구축하세요: 프레임워크 독립적 형식(JSONL, parquet)의 파인튜닝 데이터셋, 특정 API의 응답 형태가 아닌 모델 출력을 평가하는 평가 하네스, 특정 벤더의 스키마에 직접 작성된 것이 아니라 벤더 특정 스키마로 변환하고 변환되는 도구 호출 로직.

하나의 벤더에 매달리는 것이 아니라 의도적으로 라우팅하세요. 모델 라우팅 전략 - 능력 기반, 비용 인지, 지연 시간 인지 - 은 일상적인 트래픽을 로컬 모델로 보내고 경계 사례를 프론티어 API로 보내게 하여, 단일 벤더 주위로 최적화(Optimization) 단계로 표류하는 것이 아니라 통합(Integration) 단계 내에 무한정 머물 수 있게 합니다.

일정 간격으로 잠금(Lock-In)을 정량화하세요. 벤더별로 분기에 한 번씩 위의 스코어링 테이블을 다시 실행하세요. 수치가 상승할 때, 그것은 누가 명시적인 결정을 했든 그렇지 않든 데이터 중력이 작동하고 있다는 것을 의미합니다.

실제로 어떻게 보이는가

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

  • 추론 (Inference): 로컬, 단일 머신 서빙은 llama.cpp; 프로덕션 등급 셀프호스트드 처리량은 vLLM 또는 SGLang. 세 가지 모두 OpenAI 호환 API를 노출하므로, 애플리케이션 코드는 그 뒤에 무엇이 있는지 알 필요가 없습니다.
  • 파인튜닝 (Fine-tuning): 데이터셋은 표준 형식 - JSONL, parquet - 으로 저장하며, 결코 벤더의 독점적 파인튜닝 잡(job) 형식으로 저장하지 않습니다.
  • 평가 (Evaluation): 프레임워크 독립적 하네스는 API 응답 봉투가 아닌 출력을 평가하므로, 모델이 로컬이든 원격이든 동일한 평가 스위트가 실행됩니다.
  • 도구 호출 (Tool calling): 특정 벤더의 형태에 직접 작성된 애플리케이션 로직이 아니라, 각 벤더의 도구 호출 형식으로 변환되고 변환되는 벤더 독립적 JSON 스키마.
  • 벡터 스토어 (Vector stores): Qdrant, Milvus, 또는 Chroma와 같은 로컬 우선 옵션이며, 임베딩은 특정 벤더의 임베딩 엔드포인트에 묶인 것이 아니라 이동 가능한 라이브러리를 통해 계산됩니다 - 이는 검색 레이어에 어떻게 통합되는지에 대해서는 RAG에서의 청킹 전략을 참고하세요.

이것은 셀프호스팅 강령이 아닙니다. 상당한 워크로드가 영구적으로 프론티어 API에 머무는 것이 맞습니다. 이는 벤더가 가격을 변경하는 그날 발견하는 것이 아니라, 데이터 중력을 측정하고 관리할 수 있는 엔지니어가 더 적은 선택지가 아니라 더 많은 선택지를 가지게 된다는 것을 인식하는 것입니다.

결론

데이터 중력은 단일 벤치마크 점수보다 오픈웨이트 능력이 왜 더 중요한지를 설명합니다. 프론티어 모델 품질의 85~95%로 로컬에서 실행되는 모델은 데이터 관계를 유지하기 때문에 종종 더 나은 아키텍처적 선택입니다. 현재 어떤 오픈웨이트가 그 밴드에 위치해 있는지, 그리고 이를 상주시키는 데 드는 비용은 무엇인지는 2026년 오픈 모델의 효율적 프론티어가 다룹니다. GPT-5.6 Sol, Fable 5, Kimi K3, Qwen 간의 프론티어 경쟁은 진정한 관심사입니다만, 그 밑의 인프라 레이어 - 누가 파인튜닝 데이터를 소유하고, 도구가 누구의 스키마를 말하는지, 워크플로우가 누구의 과금 모델을 가정하는지 - 에서는 3년 후 어떤 팀이 선택지를 가지는지, 어떤 팀이 누군가의 아키텍처를 임대하는지를 실제로 결정합니다.

벤더의 가격 페이지가 당신에게 그 질문을 강제하기 전에, 당신의 잠금(Lock-In) 수준을 평가해 보세요.

출처

구독하기

시스템, 인프라, AI 엔지니어링에 관한 새 글을 받아보세요.