Chiko IT
AI 코딩 도구

ChatGPT 점유율 50% 첫 붕괴 — LLM 시장 재편과 멀티 모델 전략

Chiko
10min read

목차

LLM API 시장의 주요 플레이어 — 무엇을 비교하는 글인가

LLM API를 실제 서비스에 붙이는 방법은 사실상 세 갈래로 굳어졌다. OpenAI의 GPT 시리즈(GPT-4o, GPT-4o-mini), Anthropic의 Claude 시리즈(Sonnet 4.5, Haiku), Google의 Gemini 시리즈(2.0 Pro, 2.0 Flash)다. 이 세 가지가 상업용 폐쇄형 모델의 큰 축이고, 그 옆에 Meta Llama 3.x, Mistral, xAI Grok이 오픈소스 또는 가격 경쟁력으로 빈틈을 공략한다.

게다가, 지금까지 백엔드 입장에서 디폴트는 "일단 GPT 붙이고 본다"였다. 가장 먼저 자리잡았고, SDK 안정성이 좋았고, 문서가 두텁고, 커뮤니티 예제가 풍부했다. 프론트엔드만 만지다 백엔드로 넘어온 시각에서 보면 OpenAI SDK는 npm에서 axios 까는 정도의 진입 장벽이었다. fetch 한 번 감싸면 끝나는 수준이었으니까.

2025년 후반부터 분위기가 바뀌었다. 여러 트래픽 분석 기관 자료를 종합하면 ChatGPT의 글로벌 시장 점유율이 처음으로 50% 아래로 내려갔다는 신호가 잡혔다. 이 글은 그 데이터를 따라가면서, 백엔드 관점에서 LLM 선택 기준이 어떻게 바뀌어야 하는지, 멀티 LLM 전략이 실제로 가치 있는 시점이 언제인지를 분석한다. 결론을 먼저 말하지는 않는다. 판단 기준은 마지막 섹션에 정리되어 있다.

문제 정의 — 단일 LLM 의존이 만드는 세 가지 비용

LLM 호출이 서비스의 핵심 경로에 들어간 순간부터, 단일 벤더 의존은 그냥 비즈니스 리스크가 된다. 추상적인 위험이 아니라 청구서와 SLA에 직접 꽂히는 비용이다.

가용성 — 분기당 한두 번은 흔들린다

OpenAI 콘솔의 status 페이지를 한 달 정도 켜두고 보면 의외로 인시던트가 잦다. 전면 다운은 드물지만, 부분 장애, 특정 모델만 latency 급증, rate limit 갱신 지연, tool use 응답 누락 같은 미세 장애가 분기당 한두 번은 터진다. 폴백 모델이 없으면 사용자 체감 품질이 같이 흔들린다. 검색 기반 챗봇이나 음성 인터페이스처럼 응답 지연이 곧 이탈로 이어지는 제품에서는 이게 매출 손실이다.

가격 — 동급 모델 사이의 단가 격차

GPT-4o 가격은 한 차례 인하됐지만 여전히 동급 모델 대비 비싸다. Claude Sonnet 4.5나 Gemini 2.0 Flash와 비교하면 1M 토큰 기준 입력/출력 단가에서 의미 있는 차이가 난다. 호출이 늘어날수록 차이는 산술적이 아니라 지수적으로 커진다. 월 호출 10만 건 단위로 넘어가는 워크로드에서는 모델 한 번 바꾸는 게 인프라 비용 줄이기보다 직접적 효과를 낸다.

품질 편향 — 한 모델의 약점이 곧 서비스의 약점

반면, 한 모델만 쓰면 그 모델의 편향과 약점을 그대로 떠안는다. GPT-4o는 multimodal과 추론에서 강하지만, 긴 문서 요약에서는 Claude가 더 일관성 있다는 평가가 많고, 임베딩 보조나 분류 작업에서는 Gemini Flash가 가격 대비 품질이 안정적이다. 단일 모델 전략은 본질적으로 "이 모델의 약점은 우리 서비스의 약점이다"라는 수용을 깔고 가는 셈이다.

점유율 변화의 실제 모습 — 어떻게 읽어야 하나

그런데, 여러 트래픽 분석 기관(Similarweb, a16z 보고서, OpenRouter API 라우팅 통계 등)이 공개한 자료를 종합해 보면, 2025년 말부터 ChatGPT의 점유율 곡선이 분명하게 꺾였다. 정확한 수치는 측정 방식(웹 트래픽 기준, API 호출 기준, 기업 채택률 기준)에 따라 다르지만, 방향성은 일관된다.

시점 ChatGPT Claude Gemini 기타
2024년 초 약 70% 한 자릿수 한 자릿수 약 10%
2025년 중반 약 60% 약 15% 약 15% 약 10%
2026년 초 추정 약 48% 약 20% 약 20% 약 12%

(위 수치는 공개된 트래픽 분석 보고서들의 중간값을 기반으로 한 추정치다. 출처에 따라 ±5% 정도 편차가 있고, "사용자 수 기준"이냐 "토큰 호출 기준"이냐에 따라 다시 차이가 난다.)

흥미로운 부분은 ChatGPT의 절대 사용량이 줄어든 것이 아니라는 점이다. 전체 LLM 시장이 빠르게 커지면서, ChatGPT가 가장 빠른 성장률을 가져가지 못한 결과로 상대적 점유율이 빠진 거다. Claude와 Gemini의 증가 속도가 더 가팔랐다고 읽는 게 정확하다. 그래서 이 변화는 "ChatGPT가 망한다"의 신호가 아니라 "독과점이 풀리고 있다"의 신호로 해석해야 한다. 이 차이는 의사결정에 직접 영향을 준다. 전자라면 갈아타기 결정이고, 후자라면 다변화 결정이다. 둘은 다른 아키텍처를 요구한다.

모델별 강점 — 실무 관점에서 본 관찰

그런데, 여기서부터는 같은 입력을 세 모델에 동시에 던져보고 결과를 비교한 일상적 관찰이다. 공식 벤치마크가 아니고, 한국어 위주 백엔드 워크로드에서 체감한 분포다.

그러나, GPT-4o와 GPT-4o-mini는 범용성이 가장 균형 잡혀 있다. 한국어 자연스러움, 이미지 입력, 함수 호출(tool use), structured output의 안정성을 합쳐 봤을 때 가장 무난하다. 새 기능을 가장 먼저 SDK에 반영하는 것도 OpenAI다. 다만 추론이 길게 이어지는 질문에서 Claude에게 밀릴 때가 종종 있고, 긴 컨텍스트 끝쪽 정보를 놓치는 경향이 보인다.

그래서, Claude Sonnet 4.5는 긴 컨텍스트 처리와 코드 생성에서 일관성이 가장 높다는 평가가 많다. 200K 토큰 컨텍스트를 정말 200K처럼 쓴다는 게 자주 언급되는 강점이다. Anthropic API 문서가 깔끔해서 SDK 설계 자체가 덜 헷갈리고, system 메시지 처리 방식이 직관적이다. 다만 multimodal 지원 폭과 함수 호출 옵션 다양성은 GPT보다 늦게 따라오는 편이다.

이처럼, Gemini 2.0 Flash는 가격 경쟁력이 가장 매력적인 위치다. 토큰당 단가가 동급 모델의 절반 이하로 형성되어 있어서 단순 분류, 요약, 임베딩 보조, 로그 정리 같은 대량 호출 워크로드에 잘 맞는다. 한국어 품질은 GPT보다 한 단계 약하다는 평이 일반적이지만, 작업 난도가 낮으면 그 차이가 거의 보이지 않는다.

오픈소스 옵션, 그러니까 Llama 3.x나 Mistral 계열은 결이 다른 선택지다. 프라이빗 인프라에서 직접 돌릴 수 있다는 게 가장 큰 차별점이고, 데이터 외부 유출이 막혀야 하는 시나리오에서는 사실상 유일한 카드다. 운영 부담은 별개 문제다. GPU 확보, 모델 업데이트 추적, 추론 최적화는 그 자체로 한 팀의 풀타임 업무가 된다.

멀티 LLM 전략 — 라우팅을 어떻게 설계할 것인가

세 가지 모델을 동시에 다루려면 라우팅 레이어가 필요해진다. 단순화하면 세 가지 패턴이 있고, 각각의 트레이드오프가 다르다.

첫 번째는 폴백 라우팅이다. 주력 모델이 실패하면 보조 모델로 넘긴다. 가장 구현이 쉬워서 일주일 안에 붙일 수 있다. 단점은 보조 모델의 응답 품질이 떨어지면 사용자가 알아챈다는 점이다. 단순 인증 작업이나 분류 작업처럼 응답 품질 분산이 작은 영역에 어울린다.

두 번째는 작업별 라우팅이다. 요청 타입을 보고 적절한 모델로 분배한다. 코드 관련 작업은 Claude, multimodal은 GPT, 단순 분류와 요약은 Gemini Flash 같은 식이다. 가격과 품질 최적화에 가장 유리한 패턴이다. 단 분류 로직 자체가 또 하나의 LLM 호출이 되거나 정규식·키워드 매칭 레이어가 추가되어야 하므로, 라우팅 오버헤드 관리가 별도의 관심사가 된다.

세 번째는 병렬 호출이다. 같은 요청을 여러 모델에 동시에 보내고 첫 응답을 쓰거나, 합의 기반으로 답을 고른다. 품질은 가장 좋아지지만 비용이 곱셈 단위로 증가한다. 금융 자문, 의료 보조, 법률 문서 검토처럼 응답 한 건의 가치가 높고 오답 비용이 큰 영역에서만 의미가 있다.

게다가, 작은 SaaS 백엔드 한 곳에 작업별 라우팅을 붙여본 사례에서, 월 LLM 비용이 약 40% 정도 빠진 적이 있다. (정확한 수치는 워크로드 구성에 따라 크게 달라지니 본인 환경에서 측정해야 한다.) 가격 차이가 직접적인 효과였고, 품질은 오히려 작업별 최적 모델을 쓴 게 평균적으로 더 안정적이었다. 통합 라이브러리는 LiteLLM이나 LangChain의 모델 추상화 레이어가 가장 많이 쓰이는데, 새 모델 기능이 늦게 반영되는 트레이드오프를 감안해야 한다.

한계점 — 다변화 전략의 그늘

실제로, 멀티 LLM은 좋아 보이지만 실제로 붙여보면 부딪히는 한계가 명확하다. 도입 전에 알고 가야 운영이 덜 흔들린다.

프롬프트 일관성이 첫 번째 벽이다. 같은 프롬프트가 모델마다 다르게 동작한다. system 메시지 처리 방식, tool use 스키마, response format 옵션이 미묘하게 다르고, 같은 문장이라도 모델별 강조 방식이 다르다. 한 번 작성한 프롬프트를 그대로 옮길 수 없으니, 모델별 프롬프트 버전을 따로 관리해야 한다. 프롬프트 저장소가 사실상 또 하나의 코드베이스가 된다.

따라서, 모니터링 복잡도가 두 번째다. 여러 모델을 동시에 쓰면 어디서 품질 저하가 발생했는지 추적이 까다롭다. 모델별 latency, 토큰 사용량, 에러율, 응답 길이 분포를 따로 보는 대시보드가 필요하다. LangSmith나 Helicone, Langfuse 같은 LLM 옵저버빌리티 도구를 붙이는 게 사실상 필수 코스가 된다. 도구 자체도 무료 티어 한계가 있어서 호출량 늘면 비용 라인이 또 하나 생긴다.

반면, SDK 차이는 세 번째 벽이다. OpenAI SDK, Anthropic SDK, Google AI SDK가 모두 다른 API 스타일과 다른 응답 객체 구조를 가진다. LiteLLM 같은 통합 SDK가 격차를 줄여주지만, 새 기능이 한 박자 늦게 반영되는 경우가 잦다. 직접 추상화 레이어를 만들면 결국 라이브러리 한 개를 더 유지하는 셈이 된다. 백엔드 전환자 시각에서 보면, 이건 프론트엔드에서 멀티 프레임워크 빌드 파이프라인을 굴리는 부담과 닮아 있다. 자유는 늘었지만 운영 면적이 곱절로 늘어난다.

판단 기준 — 단일 LLM과 멀티 LLM, 무엇이 맞나

여기서 판단이 갈린다. 멀티 LLM은 좋은 디폴트가 아니다. 다음 조건 중 두 가지 이상에 해당하면 그때 도입하라.

  • 월 LLM 비용이 약 $500 이상 (가격 다변화 효과가 의미 있는 구간)
  • 코드 생성, 한국어 텍스트, 이미지 입력 등 작업 유형이 분명하게 갈린다
  • 단일 벤더 장애가 서비스 SLA를 깨뜨릴 수준이다
  • 데이터 거버넌스 이슈로 일부 작업은 온프레미스 모델이 강제된다

반대로 다음에 해당하면 단일 LLM이 맞는 선택이다.

  • 사이드 프로젝트, MVP, 월 호출량이 적은 초기 단계
  • 팀 인원이 5명 이하라 운영 여력 자체가 부족하다
  • 응답 품질 최적화보다 출시 속도가 우선이다
  • 워크로드가 거의 한 가지 작업 유형으로 수렴한다

물론, 전환자 시각에서 한 가지 덧붙이면, LLM 다변화는 프론트엔드의 라이브러리 선택과 결이 비슷하다. React 단일 스택으로 가는 게 디폴트지만, 어떤 페이지는 Astro, 어떤 위젯은 Svelte로 다변화하는 순간 빌드 파이프라인과 인지 부하가 곱절로 늘어난다. LLM도 똑같다. 다변화는 자유가 아니라 비용 결정이다.

이처럼, ChatGPT 50% 붕괴는 그래서 "어느 모델을 쓰느냐"의 문제로 환원되지 않는다. 진짜 변화는 "한 모델로 모든 것을 해결한다"는 가정이 흔들린다는 점이고, 그 가정 위에 쌓아둔 아키텍처를 다시 들여다보게 된다는 점이다. 당장 실행할 수 있는 행동은 세 가지로 좁아진다. 우선 운영 중인 서비스의 LLM 호출을 일주일 단위로 로깅해서 작업 유형별 토큰 분포를 본다. 그다음 비용 비중이 30% 이상인 작업 유형을 모델 교체 후보로 표시한다. 마지막으로 폴백 라우팅 한 단계만 먼저 붙여서 단일 벤더 가용성 리스크를 끊어둔다. 본격적 멀티 LLM 전략은 그 이후의 결정이다.

관련 글

More posts