[JJ의 LLM Insight 1편] 프론티어 모델의 시대, 그리고 오픈웨이트 모델이 제공하는 차별점들

Written in

by

이 글은 JJ의 LLM Insight 시리즈의 첫 번째 글입니다. 이 시리즈에서는 LLM 시장의 경험을 기반으로 그와 관련된 트렌디한 기술적인 것들을 다룰 것이며, 앞으로 이어질 글들에서는 지금 다루는 시장 흐름 위에서 Kimchi가 어떤 장점을 제공하는지 하나씩 짚어보겠습니다.


그런데 말입니다.. 프론티어 모델 전쟁, 과연 승자가 있을까요?

2026년 9월 1일부터 3일까지, 딱 72시간 사이에 프론티어 모델 네 개가 연달아 쏟아졌습니다. Anthropic의 Claude Fable 5.1(9월 1일), Meta의 Muse Spark 1.3과 Google의 Gemini 3.8 Flash(9월 2일), OpenAI의 GPT-6 Astra(9월 3일)까지 출시됐습니다. 업계에서도 “이렇게 밀집된 릴리스 사이클은 처음 (positive crazy!)”이라는 반응이 나올 정도였습니다.

 

모델 개발사 컨텍스트 입력가격/1M 토큰 출력가격/1M 토큰 AA Intelligence Index
Claude Fable 5.1 Anthropic 1M $10 $50 약 66
GPT-6 Astra OpenAI 1.05M $10 $50 약 61
Muse Spark 1.3 Meta 1M $1.25 $4.25 약 61~62
Gemini 3.8 Flash Google 1.05M $0.75 $3.75 약 59

(Artificial Analysis Intelligence Index 기준, 2026년 9월 발표 시점 수치입니다.)

 

이 표에서 주목할 부분은 순위가 아니라 흩어져 있는 정도입니다. 실제로 벤치마크 항목별 1위를 정리하면 다음과 같습니다.

벤치마크 (측정 대상) 1위 모델 점수 2위 이하 비교 출처 성격
종합 지능 (Artificial Analysis Intelligence Index) Claude Fable 5.1 65.7 GPT-6 Astra 61.2, GPT-5.6 Sol 60.9, Claude Opus 5 63.1 독립 3자 검증
코딩 (Artificial Analysis Coding Agent Index) Claude Fable 5.1 70.4 GPT-6 Astra 67.0, Muse Spark 1.3 64.2 독립 3자 검증
수학 (FrontierMath Tier 4 v2) GPT-6 Astra 97.6% Claude Fable 5.1 87.8%, GPT-5.6 Sol 83.0%, Claude Opus 5 73.2% OpenAI 자체 발표
사이버보안 (ExploitBench) GPT-6 Astra 100% GPT-5.6 Sol 78.5%, Claude Opus 5 70% OpenAI 자체 발표
컴퓨터 사용 (OSWorld 2.0) GPT-6 Astra 72.6% Claude Opus 5 70.2%, GPT-5.6 Sol 65.7% OpenAI 자체 발표
GPQA Diamond (대학원 수준 과학 지식) GPT-6 Astra 95.8% Gemini 3.8 Flash 95.4%, GPT-5.4 Pro 94.6% BenchLeader 독립 검증(2026-09-18 기준)

 

정리하면, Claude Fable 5.1은 종합 지능, 코딩에서 앞서고, GPT-6 Astra는 수학, 사이버보안, 컴퓨터 사용(UX 활용)에서 우위를 가져갑니다. GPQA Diamond는 Astra와 Gemini 3.8 Flash가 95%대에서 근소한 차이로 경합하는, 사실상 포화(saturation)에 가까운 지표입니다. 여기서 짚어야 할 점은 수학, 사이버보안, 컴퓨터 사용 수치는 OpenAI가 자체 발표한 값이라는 것입니다. 반면 종합 지능, 코딩 지수와 GPQA Diamond는 Artificial Analysis, BenchLeader 같은 독립 기관이 별도로 측정한 값이라, 신뢰도 측면에서 성격이 다릅니다.
즉 Gemini 3.8 Flash는 Fable 가격의 13분의 1 수준인데도 GPQA Diamond에서 Astra와 근소한 차이로 2위를 유지한다는 점에서, 가격 대비 성능이 특히 두드러집니다. 어떤 벤치마크를 기준으로 삼느냐에 따라 1위가 계속 바뀌는 셈입니다.

 

그래서 업계가 도달한 결론은 대체로 비슷합니다. “어떤 모델이 최고냐”가 아니라 “어떤 작업에 어떤 모델을 배치할 것이냐”로 질문이 바뀌었습니다. 여러 분석 매체들이 공통적으로 워크로드별로 모델을 나눠 쓰는 전략(workload segmentation)을 권장합니다.

그런데 이 라우팅 논의에서 자주 빠지는 질문이 하나 있습니다. 그 모델들에 도대체 무엇을 입력하고 있고, 그 데이터는 어디로 흘러가는가입니다.


오픈웨이트란 무엇인가? “다운로드할 수 있다”와 “완전히 투명하다”는 완벽하게 다른 뉘앙스입니다.

AI 모델을 나누는 기준으로 흔히 “오픈소스냐 클로즈드냐”를 이야기하지만, 실제로는 세 단계로 나뉩니다.

구성요소 클로즈드 (GPT, Claude, Gemini) 오픈웨이트 (Kimi, DeepSeek, GLM 등) 오픈소스 (OSAID 1.0 기준)
가중치 비공개, API로만 접근 가능 공개, 다운로드 가능 공개
학습 코드 비공개 비공개 공개
학습 데이터 비공개 비공개 공개 또는 재현 가능한 수준의 상세 정보 공개
자체 호스팅 불가능 가능 가능

 

오픈소스 이니셔티브(OSI)가 2024년 10월에 발표한 Open Source AI Definition(OSAID 1.0)은 가중치, 학습 코드, 학습 데이터 정보 세 가지를 모두 요구합니다. 그런데 이 기준을 온전히 만족하는 LLM은 사실상 거의 없습니다. Meta의 Llama조차 학습 데이터셋을 공개하지 않아서 “오픈소스”로 인정받지 못했고, Meta 스스로도 OSAID 승인을 거부했습니다. 다시 말해, 시장에서 흔히 “오픈”이라고 부르는 모델들 대부분은 정확히는 오픈웨이트입니다. 가중치는 받을 수 있지만, 그 가중치가 어떤 과정으로 만들어졌는지는 대부분 블랙박스로 남아 있습니다.

 

여기서 한 가지 더 구분해야 할 지점이 있습니다. 무엇을 공개했는가공개된 것으로 무엇을 할 수 있는가는 서로 다른 문제입니다. 예를 들어 Llama는 가중치를 공개하지만, 라이선스에는 월간활성사용자(MAU) 7억 명이 넘는 기업은 쓸 수 없다는 제한이 걸려 있습니다. 반면 DeepSeek이나 GLM은 가중치 공개는 물론이고 라이선스도 MIT라서 사실상 제약이 거의 없습니다. “오픈”이라는 한 단어로 뭉뚱그리기에는, 모델마다 실제 조건이 상당히 다릅니다.

그럼에도 오픈웨이트가 공통적으로 갖는 실질적 의미는 분명합니다. 가중치를 손에 쥐고 있으면, 그 모델을 내 인프라 안에서 직접 돌릴 수 있다는 것입니다. 이 한 줄이 다음 단락의 핵심입니다.


프론티어 모델의 구조적 약점, 기업에서 LLM을 활용할 때는 성능보다 중요한 것이 보안일 수도 있습니다.

프론티어 모델을 API로 쓴다는 것은, 정의상 모든 프롬프트와 응답이 벤더의 서버를 거쳐 간다는 뜻입니다. 이는 모델 성능이 얼마나 좋은지와는 별개로, 특정 산업이나 조직에서는 그 자체로 구조적인 문제가 됩니다.

 

첫째, 데이터가 외부 인프라를 거친다는 사실 자체가 리스크입니다. API를 호출할 때마다 사내 코드, 고객 데이터, 내부 문서가 제3자의 서버로 전송됩니다. 심지어는 이 서버가 데이터가 활용되는 국가에 없을 수도 있습니다. 벤더가 약관에 “로그를 학습에 쓰지 않는다”고 명시하더라도, 그 데이터가 물리적으로 벤더의 클라우드를 통과했다는 사실 자체는 되돌릴 수 없습니다. 금융, 의료, 국방, 공공 부문처럼 데이터 반출 자체를 규제로 금지하는 산업에서는 바로 이 지점에서 도입이 막히는 경우가 많습니다.

둘째, 벤더의 정책은 사용자가 통제할 수 없는 변수입니다. 데이터 보존 기간, 로그 접근 권한, 약관 내용은 벤더가 언제든 바꿀 수 있고, 사용자는 그 변경을 사후에 통지받는 입장일 뿐입니다. 게다가 벤더가 속한 법역의 법적 요구(수사기관의 데이터 제출 명령 등)는 계약서상의 개인정보 조항과 무관하게 작동할 수 있습니다. 이는 계약의 문제가 아니라 관할권의 문제입니다.

셋째, 공급망에 단일 장애점이 생깁니다. API 기반 워크플로우는 결국 벤더의 가동률에 종속됩니다. 벤더 장애, 요금 정책 변경, 특정 국가에 대한 서비스 제한은 모두 사용자가 아니라 벤더가 내리는 결정입니다. 장시간 실행되는 에이전틱 워크플로우일수록 이 종속성의 대가가 커집니다.

넷째, 감사가 불가능합니다. 클로즈드 모델은 내부적으로 무엇을 참조하고 어떻게 응답을 만들어냈는지 검증할 방법이 없습니다. 규제 산업의 컴플라이언스 감사는 종종 “이 결정이 어떤 데이터와 어떤 로직으로 나온 것인가”를 요구하는데, API 뒤에 숨은 모델로는 이런 요구를 근본적으로 충족시키기 어렵습니다.


오픈웨이트 모델이 내세우는 프론티어와는 상반되는 특성은, “데이터가 애초에 나갈 필요가 없습니다”

오픈웨이트 모델이 제공하는 것은 단순히 “무료”나 “저렴함”이 아닙니다. 구조적으로 다른 보안 모델을 제공한다는 표현이 더 정확합니다.

 

  • 자체 호스팅을 하면 데이터 반출 자체가 발생하지 않습니다. 프롬프트도, 응답도, 사내 코드도 회사 인프라 밖으로 나가지 않습니다. “벤더를 얼마나 신뢰할 것인가”라는 질문 자체가 “데이터를 처음부터 외부로 보내지 않는다”는 구조적인 해결책으로 바뀌는 셈입니다. 특정 오픈웨이트 모델은 특정 국가에서 보안적인 이슈로 사용을 금하는 경우도 있는데, 자체 호스팅을 통해 LLM을 사용하면 보안적인 이슈 자체가 발생할 가능성이 낮아집니다.
  • 에어갭(인터넷이 차단된 폐쇄망) 환경에서도 구동할 수 있습니다. 오픈웨이트 모델을 다운로드해 온프레미스에 배치하면, 외부 네트워크 연결 없이도 서비스를 운영할 수 있습니다. 금융, 국방, 공공기관처럼 인터넷 접근 자체가 규제 대상인 환경에서는 이 조건이 “쓸 수 있느냐 없느냐”를 가르는 유일한 기준이 되기도 합니다. (이 주제는 시리즈 뒷부분에서 따로 자세히 다루겠습니다.)
  • 라이선스가 허용적이라면 벤더 종속에서 완전히 벗어날 수 있습니다. MIT나 Apache 2.0 라이선스로 풀린 모델(GLM, DeepSeek, 초기 MiniMax M2 등)은 가격 정책 변경이나 서비스 중단의 영향을 받지 않습니다. 인프라를 스스로 통제하기 때문입니다.
  • 감사와 재현이 가능합니다. 가중치를 갖고 있으면 특정 입력에 대해 모델이 왜 그런 출력을 냈는지 직접 재현할 수 있고, 필요하면 내부 감사팀이 직접 검증할 수도 있습니다. NVIDIA의 Nemotron처럼 학습 데이터와 레시피까지 함께 공개한 경우(OpenMDW-1.1 라이선스)라면 이 투명성은 한층 더 확보됩니다.
  • 도메인 데이터를 외부에 노출하지 않고도 파인튜닝으로 특화할 수 있습니다. 클로즈드 모델의 파인튜닝은 결국 벤더의 파인튜닝 API에 우리 도메인 데이터를 업로드하는 과정이지만, 오픈웨이트 모델은 그 학습 과정 자체가 사내 인프라 안에서 끝납니다.

 

물론 이 모든 장점은 트레이드오프이기도 합니다. 오픈웨이트 모델을 자체 호스팅하려면 GPU 인프라와 운영 역량이 필요하고, 최상위 프론티어 모델과의 절대적인 성능 격차가 일부 작업에서는 여전히 존재합니다. 다만 “성능”과 “데이터 주권”은 서로 다른 축의 질문이고, 규제 산업이나 보안이 최우선인 조직에게는 후자가 전자를 압도하는 경우가 적지 않습니다.


지금(26년 9월) 눈여겨볼 오픈웨이트 5종

아래 다섯 개 모델은 모두 가중치가 공개돼 있어서 자체 호스팅이 가능하고, 각자 다른 전략으로 “프론티어급 성능을 오픈웨이트로 구현”하는 문제에 접근하고 있습니다.

 

모델 개발사 아키텍처 라이선스 핵심 전략
Kimi (K2 계열) Moonshot AI MoE, 1T 총/32B 활성 Modified MIT (K2 Thinking 기준, 월매출 2000만 달러 또는 MAU 1억 초과 시 귀속 표시 의무) 초장기 에이전틱 툴콜(200~300회 연속 실행)에 특화
MiniMax (M2 계열) MiniMax MoE, 230B 총/약 10B 활성 MIT, M2.7부터 상업 이용에 제한 강화 활성 파라미터를 최소화해 단일 서버급 자체 호스팅을 실현
GLM (4.x/5.x 계열) Zhipu AI MoE, 약 355B 총/32B 활성 MIT – 가장 일관되게 허용적 코딩·툴 사용에 특화, 무료 Flash 티어로 진입 장벽을 낮춤
DeepSeek (V3.2/V4) DeepSeek Sparse Attention(DSA), Causal Encoder-Decoder MIT 세대마다 KV 캐시를 급격히 압축(토큰당 약 389KB -> 890B)해 서빙 비용을 절감
Nemotron (3 Ultra/3.5) NVIDIA Mamba-Attention 하이브리드, 550B 총/55B 활성 OpenMDW-1.1 – 가중치, 데이터, 레시피까지 공개 장문맥에서도 고정 크기 KV 캐시를 유지, 조사한 모델 중 가장 개방적인 라이선스

 

각 모델의 아키텍처와 벤치마크, 라이선스 세부 조건은 다음 편들에서 하나씩 다루겠습니다.


CAST AI의 Kimchi는 이 흐름에서 무엇을 제공하는가

지금까지 살펴본 것처럼, 시장은 “어떤 모델이 최고인가”에서 “어떤 작업에 어떤 모델을, 어떤 보안 조건 위에서 쓸 것인가”로 질문이 옮겨가고 있습니다. Kimchi는 이 질문에 정면으로 대응하는 AI 코딩 에이전트입니다. 하나의 모델에 묶이지 않고 작업별로 여러 모델을 골라 쓸 수 있는 멀티모델 오케스트레이션, 탐색, 계획, 구현, 리뷰를 서로 다른 에이전트로 분리해 컨텍스트 오염을 막는 서브에이전트 구조, 그리고 오픈웨이트 모델과 자체 호스팅 환경까지 아우르는 배포 유연성을 갖추고 있습니다. 자세한 소개는 공식 문서(https://docs.kimchi.dev/)에서 확인하실 수 있습니다.


다음 편에서는

이번 편에서 “오픈웨이트가 왜 구조적으로 유리한 선택지가 될 수 있는가”를 다뤘다면, 다음 편에서는 이 오픈웨이트 모델들이 실제 AI 코딩 에이전트 시장(Cursor, Copilot, Claude Code 등)에서 어떻게 쓰이고 있는지, 그리고 그 도구들이 아직 풀지 못한 문제가 무엇인지를 살펴보겠습니다.


(참고: 본문의 벤치마크 수치는 대부분 각 개발사가 직접 발표한 자료를 기준으로 한 것이며, 독립된 제3자 검증 결과와는 차이가 있을 수 있습니다. 라이선스 조건은 조사 시점(2026년 9월) 기준의 공개 문서를 바탕으로 했으며, 이후 변경될 수 있으니 실제 도입을 검토할 경우 최신 라이선스 원문을 다시 확인하시기 바랍니다.)

Tags

Categories

댓글 남기기

JJ's technical blog

A blog about the messy, fascinating intersection of Kubernetes and AI – where infrastructure decisions increasingly shape whether AI initiatives actually succeed. Drawing on hands-on experience with enterprise customers across Korea and APAC, this space covers everything from cluster optimization to the evolving demands AI workloads place on cloud-native systems.

Seoul,
South Korea

JJ's technical blog에서 더 알아보기

지금 구독하여 계속 읽고 전체 아카이브에 액세스하세요.

계속 읽기