오픈웨이트 vs 클로즈드 AI 2026: 벤치마크 격차가 좁혀진 지금, 선택의 기준이 바뀌었다
솔직히 말하면, 1년 전까지만 해도 저는 클로즈드 모델이 한동안은 압도적 우위를 유지할 거라 생각했습니다. GPT-4급 성능을 내려면 OpenAI API 키를 꽂는 게 당연한 수순이었고, 오픈웨이트 진영은 "쓸 만은 하지만 아직..." 수준에 머물렀으니까요. 그런데 그 확신이 흔들리기 시작한 건 팀의 월 API 비용이 특정 임계점을 넘어섰을 때였습니다. 클로즈드 API에 묶여 있는 동안, 비슷한 성능을 1/10 가격에 쓰는 팀이 생겨나고 있다는 걸 실감한 순간이었죠.
그 직감이 맞았습니다. MMLU 기준으로 클로즈드 최상위 모델과 오픈웨이트 최상위 모델 사이에는 2023년 말 기준 17.5%p의 격차가 있었는데(Digital Applied, 2026), 2026년 상반기에는 지식 벤치마크에서 사실상 소멸했고 코딩 분야에서는 오히려 역전된 케이스도 나왔습니다. DeepSeek V4 Pro가 BenchLM.ai 오픈소스 리더보드 1위(87점)를 차지하고, GLM-5.1이 SWE-Bench Pro에서 GPT-5.4와 Claude Opus 4.6을 앞서는 일이 현실이 됐습니다.
이 글을 읽고 나면, "우리 팀 워크로드에는 오픈웨이트와 클로즈드 중 무엇이 맞는가"를 30분 안에 판단할 수 있는 기준이 생깁니다. 단순한 성능 비교가 아니라, 실제 프로덕션 결정을 내릴 때 고려해야 할 비용·데이터 주권·운영 부담을 구체적인 코드와 숫자로 풀어봅니다.
목차
핵심 개념
오픈웨이트 ≠ 오픈소스: 실무에서 중요한 이유
저도 처음엔 이 둘을 혼용했는데, 프로덕션에서 라이선스 문제가 불거지고 나서야 차이를 제대로 챙기게 됐습니다.
| 구분 | 가중치 공개 | 학습 데이터 공개 | 학습 코드 공개 |
|---|---|---|---|
| 완전한 오픈소스 | ✅ | ✅ | ✅ |
| 오픈웨이트 | ✅ | ❌ (대부분) | ❌ (대부분) |
| 클로즈드 | ❌ | ❌ | ❌ |
오픈웨이트(Open-weight): 학습된 가중치 파일을 외부에 공개하지만, 학습 데이터나 전체 소스코드는 포함하지 않는 모델. Meta Llama, DeepSeek, Qwen, GLM 계열이 대표적입니다. 직접 다운로드해 파인튜닝하거나 로컬 추론이 가능하다는 게 핵심입니다.
"오픈이니까 상업적으로 써도 되겠지"라는 가정이 생각보다 자주 발목을 잡습니다. Llama 계열은 Meta LLAMA 상업 라이선스, DeepSeek은 별도 약관, Qwen은 Apache 2.0 등 모델마다 조건이 다릅니다. 실제로 저는 배포 직전에 라이선스 검토가 빠진 걸 컴플라이언스팀에서 잡아낸 적이 있습니다. 서비스에 붙이기 전에 라이선스 원문을 읽어보시면 좋습니다.
2026년 주요 모델 현황과 VRAM 요구사항
오픈웨이트 진영에서 주목할 모델들은 대부분 중국 공급자에서 나왔습니다. OpenRouter 트래픽에서 중국 오픈웨이트 공급자 비중이 1년 전 2% 미만에서 45% 이상으로 올라섰다는 통계(BenchLM.ai, 2026)는 꽤 충격적입니다.
| 모델 | 제공사 | 주목할 점 | 권장 VRAM |
|---|---|---|---|
| DeepSeek V4 Pro | DeepSeek | BenchLM.ai 오픈소스 1위 (87점), SWE-Bench Pro 선두 | A100 4장 이상 (FP16) |
| GLM-5.1 | Zhipu AI | GPT-5.4·Claude Opus 4.6 대비 코딩 벤치마크 우위 | A100 4장 이상 |
| Qwen 3.5 397B | Alibaba | 추론 분야 강세 | A100 8장 이상 |
| Kimi K2.6 | Moonshot | BenchLM.ai 2위 (84점) | A100 4장 이상 |
| Qwen 2.5 72B (양자화) | Alibaba | Mac M-series에서도 동작 | 48GB (4-bit 양자화) |
| Claude Opus 4.6 | Anthropic | GPQA Diamond·고급 수학에서 리드 | API only |
| GPT-5.4 Pro | OpenAI | 고복잡도 추론, 멀티모달 성숙도 | API only |
GPQA Diamond: 박사급 과학 추론 능력을 측정하는 벤치마크입니다. SWE-Bench Pro: 실제 GitHub 이슈를 자율적으로 해결하는 능력을 평가합니다. 두 벤치마크 모두 단순 지식보다 복잡한 추론과 실전 능력을 측정한다는 점에서 다른 벤치마크보다 프로덕션 성능에 가깝다고 볼 수 있습니다.
A100 4장 이상이 필요한 대형 모델을 GPU 없이 써야 한다면, Together.ai나 DeepInfra 같은 관리형 API를 통해 인프라 없이 동일 모델을 호출할 수 있습니다. 아래 예시 2에서 구체적으로 다룹니다.
추론 엔진 핵심 개념
PagedAttention: vLLM이 사용하는 메모리 관리 기법으로, GPU VRAM의 단편화를 50% 줄이고 동시 요청 처리량을 2~4배 높입니다. 여러 사용자가 동시에 API를 호출하는 팀 서빙 환경에서 특히 효과적입니다.
LoRA (Low-Rank Adaptation): 전체 모델 가중치를 재학습하지 않고 소규모 어댑터 레이어만 학습해 파인튜닝하는 기법입니다. 7B 이하 모델이라면 소비자용 GPU(RTX 3090, M2 Max 등) 한 장으로 몇 시간 내에 가능하지만, 70B 이상 대형 모델은 A100 2~4장 이상이 필요합니다. "파인튜닝은 어렵다"는 인식과 달리, 소규모 도메인 데이터셋으로 시작한다면 생각보다 접근하기 쉬운 편입니다.
실전 적용
예시 1: 규제 산업 내부 배포 — VPC 안에서 LLM 직접 운영하기
헬스케어나 금융 도메인에서 일하고 계신 분들이라면 공감하실 겁니다. 원시 환자 데이터나 금융 거래 기록을 외부 API로 보내는 순간 컴플라이언스팀이 뛰어옵니다. 이 경우 오픈웨이트 모델을 VPC 내부에서 직접 서빙하는 게 사실상 유일한 선택지입니다.
vLLM을 사용하면 프로덕션 수준의 추론 서버를 비교적 빠르게 올릴 수 있습니다.
# vLLM 설치 및 DeepSeek-V3 서빙
pip install vllm
# GPU 4장 환경에서 분산 추론 (A100/H100 기준)
python -m vllm.entrypoints.openai.api_server \
--model deepseek-ai/DeepSeek-V3 \
--tensor-parallel-size 4 \
--max-model-len 32768 \
--port 8000# OpenAI 호환 클라이언트로 내부 엔드포인트 호출
import os
from openai import OpenAI
# OpenAI 클라이언트는 api_key가 비어있으면 환경변수를 뒤지다가 예외를 던집니다
# 임의 문자열을 넣고, 실제 인증(Bearer 토큰, mTLS 등)은 reverse proxy 레이어에서 처리합니다
client = OpenAI(
base_url="http://your-internal-host:8000/v1",
api_key=os.getenv("INTERNAL_API_KEY", "EMPTY")
)
try:
response = client.chat.completions.create(
model="deepseek-ai/DeepSeek-V3",
messages=[
{"role": "user", "content": "환자 기록 요약: ..."}
],
timeout=30
)
print(response.choices[0].message.content)
except Exception as e:
print(f"추론 서버 오류: {e}")
raise| 선택 포인트 | 이유 |
|---|---|
--tensor-parallel-size 4 |
GPU 4장으로 대형 모델 분산 추론. GPU가 1~2장이라면 4-bit 양자화 버전(GGUF)이나 더 소형 모델을 고려할 수 있습니다 |
| OpenAI 호환 엔드포인트 | 기존 클라이언트 코드 교체 없이 base_url만 변경하면 전환 가능 |
| 내부 VPC 서빙 | 데이터가 외부로 나가지 않아 HIPAA·SOC2 준수에 유리 |
| 인증은 별도 레이어 | vLLM 자체 인증보다 Nginx·API Gateway에서 처리하는 게 일반적 |
예시 2: 고볼륨 자동화 — 비용이 결정적인 배치 워크로드
내부 문서 RAG, 코드 리뷰 봇, 회의록 자동 요약처럼 하루에도 수천~수만 번 LLM을 호출하는 워크로드라면 비용 계산을 먼저 해보시는 게 좋습니다. 처음엔 GPT-4 계열로 프로토타입을 만들다가 월말 청구서에 깜짝 놀라는 패턴, 저도 경험했고 주변에서도 자주 봅니다.
동일 프로덕션 워크로드 기준으로 GPT-5.2는 월 $2,275인 반면 DeepSeek V3는 월 $168입니다(Let's Data Science, 2026). 10배 이상 차이가 납니다.
# LiteLLM으로 클로즈드↔오픈웨이트 스위칭 — 코드 변경 최소화
import litellm
def call_llm(prompt: str, use_open_weight: bool = False) -> str:
try:
if use_open_weight:
# 고볼륨 자동화용: Together.ai 경유 오픈웨이트
response = litellm.completion(
model="together_ai/deepseek-ai/DeepSeek-V3",
messages=[{"role": "user", "content": prompt}],
timeout=30
)
else:
# 고복잡도 추론용: 클로즈드 모델
response = litellm.completion(
model="gpt-5.4",
messages=[{"role": "user", "content": prompt}],
timeout=30
)
return response.choices[0].message.content
except litellm.Timeout:
raise RuntimeError("LLM 응답 타임아웃")
except litellm.APIError as e:
raise RuntimeError(f"API 오류: {e}")Together.ai나 DeepInfra 같은 관리형 오픈웨이트 API를 쓰면 GPU 인프라 없이도 이 가격대를 누릴 수 있습니다. 모델을 바꿀 때는 model 문자열 하나만 교체하면 됩니다.
예시 3: 로컬 개발 환경 — Ollama로 빠르게 실험하기
개인 프로젝트나 빠른 실험이 필요할 때 Ollama는 정말 Docker처럼 편합니다. API 비용 없이 로컬에서 돌릴 수 있어서 실험 속도가 확실히 빨라집니다.
# Ollama 설치
# macOS는 Homebrew 권장 (신뢰할 수 있는 패키지 매니저 경로)
brew install ollama
# Linux는 공식 설치 스크립트 사용 가능
# curl -fsSL https://ollama.ai/install.sh | sh
# Mac M-series에서도 잘 동작하는 코딩 특화 모델 실행
ollama pull qwen2.5-coder:7b
ollama run qwen2.5-coder:7b
# OpenAI 호환 API 서버도 함께 뜸 (기본 포트 11434)# Ollama를 OpenAI 클라이언트로 호출
from openai import OpenAI
# Ollama는 인증 불필요하지만, 클라이언트 예외를 막기 위해 임의 문자열을 넣습니다
client = OpenAI(
base_url="http://localhost:11434/v1",
api_key="EMPTY"
)
try:
response = client.chat.completions.create(
model="qwen2.5-coder:7b",
messages=[{"role": "user", "content": "Hello!"}],
timeout=60 # 로컬 모델은 첫 응답이 느릴 수 있음
)
print(response.choices[0].message.content)
except Exception as e:
print(f"오류: {e}")단, 7B 이하 모델은 복잡한 추론 품질이 많이 떨어지므로 프로토타이핑 용도로 보시면 좋습니다. 로컬에서 품질 확인을 마쳤다면 base_url과 model만 바꿔 DeepInfra나 Together.ai의 더 큰 모델로 그대로 전환할 수 있습니다.
장단점 분석
오픈웨이트의 강점
비용 항목은 단순한 "저렴함"이 아닙니다. 고볼륨 워크로드에서 월 수천 달러의 차이가 나는 상황이라면 팀의 기술 선택 자체가 달라지는 수준이 됩니다.
| 항목 | 내용 |
|---|---|
| 비용 | 동일 성능 대비 클로즈드의 1/10~1/13 수준, 온프레미스 운영 시 전기세만 |
| 데이터 프라이버시 | 서드파티 전송 없음, HIPAA·SOC2 등 규제 준수 용이 |
| 커스터마이징 | 파인튜닝, LoRA 등 자유로운 모델 수정 가능 |
| 코딩·지식 벤치마크 | 클로즈드와 동등하거나 일부 분야(코딩, RAG)에서 우위 |
| 벤더 종속 탈출 | API 정책 변경·서비스 종료 리스크 없음 |
클로즈드의 강점
고난도 추론과 멀티모달 쪽은 아직 클로즈드가 유의미한 리드를 갖고 있습니다. 저도 클로즈드 모델이 여전히 합리적인 선택인 상황이 분명히 있다고 생각합니다.
| 항목 | 내용 |
|---|---|
| 고난도 추론·수학 | GPQA Diamond 등 복잡한 추론 벤치마크에서 여전히 3~8%p 리드 |
| 멀티모달 | 이미지·영상·오디오 처리 성숙도에서 명확한 우위 |
| 운영 단순성 | 인프라 없이 API 키 하나로 즉시 사용 |
| 안전성·필터링 | RLHF 기반 콘텐츠 안전 필터가 더 성숙 |
| 엔터프라이즈 SLA | 고가용성 보장, 제로 데이터 보존 계약 가능 |
단점 및 주의사항
| 항목 | 내용 | 대응 방안 |
|---|---|---|
| [오픈웨이트] GPU 인프라 부담 | 모델 업데이트·보안 패치를 직접 관리해야 함 | Together.ai·DeepInfra 관리형 API로 먼저 시작 |
| [오픈웨이트] 라이선스 복잡성 | 모델마다 상업 이용 조건이 다름 | 배포 전 라이선스 원문 반드시 확인 |
| [오픈웨이트] Instruction-following | 특정 출력 형식 엄수, 제약 조건 준수 등 세밀한 지시 이행 수준에서 클로즈드 대비 격차 존재 | 도메인 파인튜닝 또는 시스템 프롬프트를 공들여 작성 |
| [클로즈드] 고볼륨 비용 | 트래픽 증가 시 비용 급증 | 볼륨 구간별 오픈웨이트 혼용 전략 |
| [클로즈드] 벤더 의존성 | 서비스 약관 변경·단종 리스크 | LiteLLM 같은 추상화 레이어로 전환 비용 최소화 |
| [클로즈드] 지정학적 위험 | 특정 국가·지역 서비스 제한 가능성 | 오픈웨이트 폴백 플랜 병행 준비 |
실무에서 가장 흔한 실수
이 세 가지는 팀에서 LLM을 도입할 때 실제로 가장 자주 걸리는 함정들입니다. 저도 직접 경험하거나 가까이서 지켜본 케이스들이라 별도로 정리해봤습니다.
-
"오픈이니까 상업적으로 써도 되겠지" 가정하기 — Llama 4는 일정 규모(월 활성 사용자 7억 명) 이상의 서비스에서 Meta 별도 라이선스가 필요합니다. 스타트업 단계에선 해당되지 않아도, 스케일이 커지면 소급 적용 이슈가 생길 수 있습니다. 저도 초반에 이 부분을 대충 넘겼다가 배포 직전에 법무팀 검토를 다시 받게 된 적이 있어서, 처음부터 라이선스 원문을 확인해두시면 좋습니다.
-
벤치마크 숫자만 보고 선택하기 — MMLU에서 동등하다고 해서 실제 프로덕션 태스크에서도 동등한 건 아닙니다. 벤치마크는 일반 능력을 측정하지만, 여러분의 도메인 데이터와 프롬프트 패턴에서 어떻게 동작하는지는 직접 평가해보기 전까지 알 수 없습니다. 본인 도메인 케이스 50~100개를 직접 돌려보는 게 벤치마크 표보다 훨씬 신뢰도 높은 판단 근거가 됩니다.
-
처음부터 온프레미스로 시작하기 — GPU 클러스터 구축은 진입 비용이 상당합니다. Together.ai나 DeepInfra 같은 관리형 오픈웨이트 API로 먼저 검증한 뒤 내재화 여부를 결정하는 흐름이 리스크가 훨씬 적습니다. 관리형 API에서도 DeepSeek-V3 기준 입력 $0.14/M 토큰(2026년 6월 기준, 최신 가격은 DeepInfra 공식 페이지 확인) 수준이라, 대부분의 팀에선 직접 운영보다 관리형이 더 효율적입니다.
마치며
이 글을 쓰면서 한 가지 생각이 바뀌었습니다. 처음엔 "오픈웨이트가 충분히 좋아졌나?"가 핵심 질문이라고 생각했는데, 실제로는 선택의 축이 이미 "성능"에서 "비용·데이터 주권·운영 복잡도"로 이동해 있었습니다. 성능만으로 클로즈드를 정당화하기 어려운 워크로드가 2026년 현재 상당히 늘어났고, 많은 팀이 이미 두 가지를 상황에 따라 조합하는 하이브리드 전략으로 가고 있습니다.
지금 바로 시작해볼 수 있는 3단계를 상황에 맞게 제안합니다.
처음 LLM을 도입하는 팀이라면 1단계부터, 이미 클로즈드 API를 쓰고 있다면 2단계부터 시작해보시면 됩니다.
-
로컬 환경에서 오픈웨이트 체험해보기 — macOS라면
brew install ollama, Linux라면 공식 스크립트로 Ollama를 설치하고ollama run qwen2.5-coder:7b를 실행해볼 수 있습니다. 본인이 자주 쓰는 프롬프트 몇 가지를 넣어보면 체감 품질을 빠르게 파악할 수 있습니다. -
현재 워크로드의 월 API 비용 계산해보기 — OpenAI 대시보드에서 지난달 토큰 사용량을 확인하고, 같은 볼륨을 DeepInfra(DeepSeek-V3 기준 입력 $0.14/M 토큰, 2026년 6월 기준)로 돌렸을 때 비용을 비교해볼 수 있습니다. 차이가 크다면 고볼륨 배치 워크로드부터 전환을 검토해보시면 좋습니다.
-
LiteLLM으로 추상화 레이어 도입 검토하기 — 지금 당장 전환하지 않더라도
litellm.completion(model="...")한 줄로 100개 이상의 모델을 동일 인터페이스로 호출할 수 있게 감싸두면, 나중에 모델을 바꿀 때model문자열 하나만 교체하면 됩니다.
참고 자료
- Open-Weight vs Closed-Source AI Models 2026: Gap Analysis | Digital Applied
- Best AI Models May 2026: Closed vs Open-Weight Tested | Local AI Master
- Open-Source vs Closed-Source AI in 2026: Enterprise Strategy | StratosAlly
- Open Source vs Closed LLMs: The 2026 Decision Framework | Let's Data Science
- Best Open Source LLM in 2026: Rankings, Benchmarks | BenchLM.ai
- Open-Weight Models H1 2026: DeepSeek, Qwen, Llama Recap | Digital Applied
- Open-Weight AI Models Are Catching Up: Enterprise Automation | MindStudio
- How to Run Open-Weight AI Models Locally with Ollama and LM Studio | MindStudio
- vLLM vs Ollama vs LM Studio: The 2026 Production Self-Host Benchmark | Codersera
- 개방형 AI 모델도 급이 있다…'오픈소스'와 '오픈웨이트' 차이는? | ZDNet Korea
- Open vs Closed Source AI Models: Intelligence, Price & Speed | DeepInfra