오픈 소스 vs 폐쇄형 AI: 실제 구축 시 정말 중요한 것

지난달 저는 API 지연 시간(latency)이 호출당 4.2초까지 늘어나 사용자들이 이탈하기 시작하자, 프로덕션 워크플로우(production workflow)에서 GPT-4o를 Llama 3.3 70B로 교체하는 데 3일을 보냈습니다. 오픈 모델은 로컬에서 실행되어 빠릿빠릿하게 느껴졌고 비용도 거의 들지 않았습니다. 하지만 곧 벽에 부딪혔습니다. 구조화된 JSON 출력(structured JSON output)이 불안정했고, 함수 호출(function calling) 시 응답의 약 8%에서 스키마 키(schema keys)를 환각(hallucination)했고, 새벽 1시에 직접 작성한 취약한 재시도 장치(retry harness)로 전체를 감싸지 않고서는 출력 형식을 강제할 신뢰할 만한 방법이 없었습니다. 결국 저는 다시 돌아왔습니다. 그 한 주는 저에게 실제 비용을 치르게 했고, 어떤 벤치마크 리더보드(benchmark leaderboard)도 알려주지 않을 사실을 가르쳐 주었습니다. 오픈 소스 대 폐쇄형의 문제는 이데올로기의 문제가 아닙니다. 그것은 매우, 짜증 날 정도로 상황에 따른 문제입니다.

성능 격차는 실재하지만, 당신이 생각하는 지점이 아닙니다

모든 사람이 벤치마크 점수에 대해 이야기합니다. MMLU가 어떻고, HumanEval이 어떻고 말이죠. 벤치마크가 측정하지 못하는 것은 바로 _프로덕션 환경에서의 일관성(consistency under production conditions)_입니다. 즉, 지저분하고 실제적인 프롬프트(prompts)가 포함된 수천 번의 실제 호출 과정에서 나타나는 출력 품질의 변동성입니다.

Anthropic, OpenAI, Google의 폐쇄형 모델들은 추론 안정성(inference stability)을 위해 엄청난 엔지니어링 노력을 기울여 왔습니다. Claude Sonnet이나 GPT-4o가 구조화된 출력을 반환할 때, 해당 기업의 네이티브 도구(native tools)를 사용한다면 스키마 준수(schema adherence)는 거의 결정론적(deterministic)입니다. 다운스트림 코드(downstream code)가 이에 의존할 때, 그 신뢰성은 돈만큼의 가치를 합니다.

오픈 모델들 — Mistral, Llama, Qwen, DeepSeek — 은 다른 문제를 안고 있습니다. 기본 능력(base capability)은 종종 인상적이며 때로는 진정으로 경쟁력이 있습니다. 하지만 배포(deployment)는 당신의 몫입니다. 양자화(Quantization) 선택은 당신의 특정 프롬프트를 테스트하지 않고서는 예측하기 어려운 방식으로 추론 품질에 영향을 미칩니다. 벤치마크에서 85점을 기록한 모델의 4-bit GGUF 버전이 당신의 데이터가 포함된 당신의 벤치마크에서는 71점을 기록할 수도 있습니다. 이는 그것을 기반으로 구축을 마친 후에야 알게 됩니다.

솔직한 프레임워크를 제시하자면 이렇습니다: 폐쇄형 모델은 안정성을 빌려 쓰는 것이고, 오픈 모델은 가공되지 않은 능력을 구매한 뒤 안정성을 직접 엔지니어링하는 것입니다.

비용은 함정 계산이다

저 자신을 포함하여 많은 이들이 저지르는 실수를 여러 번 목격했습니다. 누군가는 GPT-4o의 토큰당 가격을 계산한 뒤, 이를 시간당 0.80달러인 GPU에서 Llama를 호스팅하는 비용과 비교하고는 오픈 모델이 10배 더 저렴하다고 결론을 내립니다. 그 계산 자체는 고립된 상태에서는 맞을지 모르나, 실제 상황에서는 거의 항상 틀립니다.

그 계산에서 놓치고 있는 것들은 다음과 같습니다:

• 신뢰할 수 있는 추론 (Inference) 환경을 구축하기 위한 엔지니어링 시간 (vLLM, Ollama, TGI — 이들은 모두 다루기 까다로운 지점들이 있습니다)
• 새로운 모델 버전이 출시되어 업그레이드하고자 할 때 발생하는 유지보수 부담
• 운영 오버헤드 (Ops overhead) — 콜드 스타트 (Cold starts), 오토스케일링 (Autoscaling), 스팟 인스턴스 (Spot instance) 중단, 지연 시간 (Latency) 모니터링
• 모델이 가끔씩 대본을 벗어날 때를 대비해 직접 구축해야 하는 출력 검증 (Output validation) 레이어

1인 개발자나 소규모 팀에게 이러한 엔지니어링 시간은 기회비용을 발생시킵니다. 동시 부하 상황에서 자체 호스팅 중인 추론 서버가 왜 500 에러를 반환하는지 디버깅하고 있을 때는 실제 제품을 만들고 있는 것이 아닙니다.

오픈 모델이 비용 측면에서 진정으로 승리하는 시나리오는 다음과 같습니다: 한 달에 수백만 번 동일한 프롬프트 구조를 실행하며, 인프라를 전담할 수 있는 인력이 있는, 대량의 안정적이고 범위가 명확한 작업들입니다. 요약 파이프라인 (Summarization pipelines), 분류 (Classification), 임베딩 생성 (Embedding generation) 등이 훌륭한 후보입니다. 분기 로직과 도구 사용 (Tool use)이 포함된 복잡한 에이전트 워크플로우 (Agentic workflows)인가요? 그렇다면 계산은 빠르게 불투명해집니다.

데이터 프라이버시는 다른 모든 것을 진정으로 압도하는 단 하나의 논거이다

협상이 불가능한 트레이드오프 (Tradeoff)는 바로 이것입니다: 만약 데이터가 귀하의 인프라를 벗어날 수 없다면, 선택의 여지는 없습니다. 의료, 법률, 금융, 정부 분야에서는 규제 및 계약 요구 사항으로 인해 모델의 성능이나 비용에 관계없이 폐쇄형 호스팅 모델을 사용하는 것이 불가능한 경우가 많습니다.

하지만 규제 산업 외의 분야에서도 대부분의 빌더(builders)들이 과소평가하고 있는 실질적인 우려 사항이 있습니다. 바로 경쟁 민감도(competitive sensitivity)입니다. 만약 여러분이 프롬프트(prompts)에 인코딩된 독점적 로직 — 즉, 핵심 지식재산권(IP)을 나타내는 맞춤형 추론 체인(reasoning chains), 도메인 특화 분류 루브릭(classification rubrics), 의사결정 프레임워크(decision frameworks) — 을 사용하여 제품을 구축하고 있다면, 여러분은 모든 API 호출 시마다 해당 로직을 제3자의 서버로 전송하고 있는 것입니다. 대부분의 제공업체는 학습 데이터 관련 우려를 다루는 기업용 계약(enterprise agreements)을 체결하고 있지만, 여러분의 프롬프트가 향후 모델의 동작에 영향을 미치는지에 대한 문제는 업계 전반에 걸쳐 여전히 완전히 해결되지 않은 상태입니다.

자체 인프라에서 오픈 모델(open model)을 실행하면 이러한 노출 영역을 완전히 제거할 수 있습니다. 여러분의 프롬프트, 출력값, 데이터 중 그 어느 것도 제3자 API를 통과하지 않습니다. 특정 비즈니스 모델의 경우, 이는 단순히 있으면 좋은 기능(nice-to-have)이 아닙니다. 논쟁이 시작되기도 전에 결론을 내릴 수 있는 필수 요구 사항입니다.

모델 전환 비용은 만성적으로 과소평가됩니다

첫날부터 여러분의 아키텍처 결정에 참고해야 할 사항이 있습니다. 여러분은 모델을 교체하게 될 것입니다. 아마도 여러 번 말이죠. 더 나은 모델이 출시되거나, 가격 정책이 변경되거나, 모델이 지원 중단(deprecated)되거나(실제로 일어나는 일입니다), 혹은 선택한 모델이 여러분의 사용 사례에 결정적인 무언가에 대해 미묘하게 성능이 떨어진다는 것을 발견했기 때문일 수 있습니다.

폐쇄형 API(Closed APIs)는 적어도 안정적인 인터페이스를 제공합니다. 만약 OpenAI를 사용 중이라면, GPT-4o에서 o3로 전환하는 것은 대부분 파라미터(parameter) 변경에 불과합니다. Anthropic을 사용 중이라면, Claude 모델 버전들은 일관된 API 동작을 보여줍니다. 전환 비용이 낮습니다.

오픈 모델(Open models)은 이야기가 다릅니다. Llama 3.3에서 Qwen 2.5로 전환하는 것은 서로 다른 프롬프트 포맷팅 컨벤션(prompt formatting conventions), 서로 다른 특수 토큰(special tokens), 시스템 프롬프트(system prompts)에 대한 서로 다른 동작, 그리고 여러분의 특정 작업에 대한 서로 다른 성능 특성을 의미할 수 있습니다. 여러분은 단순히 모델을 바꾸는 것이 아니라, 잠재적으로 프롬프트 레이어(prompt layer) 전체를 다시 튜닝해야 할 수도 있습니다.

이에 대한 아키텍처적 대응은 추상화(abstraction)입니다. 즉, 비즈니스 로직을 모델별 구현(model-specific implementation)으로부터 분리하는 모델 인터페이스 레이어(model interface layer)를 구축하는 것입니다. 하지만 이 레이어를 올바르게 구축하는 데는 시간이 걸리며, 대부분의 팀은 이미 한 번 전환 비용(switching cost)을 지불하고 나서야 이를 구축하곤 합니다.

의사결정 프레임워크: 선택하기 전 던져야 할 다섯 가지 질문

철학에 기반하여 오픈 소스 또는 폐쇄형을 선택하지 마십시오. 다음 질문들에 대한 답변을 바탕으로 선택하십시오.

1. 데이터가 귀사의 인프라를 벗어날 수 있습니까?
만약 불가능하다면 — 오픈 모델(open models)을 사용하거나 프라이빗 클라우드 기업용 계약(private cloud enterprise agreement)을 체결해야 합니다. 5번 질문으로 넘어가십시오.

2. 목표 규모에서의 월간 토큰 사용량은 어느 정도입니까?
월 5,000만(50M) 토큰 미만: 폐쇄형 API 가격이 아마 감당할 만한 수준일 것입니다. 월 5억(500M) 토큰 초과: 운영 역량(ops capacity)이 있다면 계산상 자체 호스팅(self-hosted)이 유리해지기 시작합니다.

3. 복잡한 스키마(schema)에 대해 결정론적인 구조화된 출력(deterministic structured output)이 필요합니까?
만약 그렇다면: 네이티브 도구 호출(native tool calling) 기능이 있는 폐쇄형 모델이 현재로서는 훨씬 덜 고통스럽습니다. 오픈 모델의 툴링(tooling)이 따라잡고는 있지만, 높은 신뢰도가 요구되는 프로덕션(production) 환경에서 사용하기에는 아직 부족합니다.

4. 자체 호스팅에 드는 완전 비용(fully-loaded engineering cost)은 얼마입니까?
솔직한 답변을 드리자면: 신뢰성을 확보하려면 최소 한 명의 엔지니어가 모델 인프라에 업무 시간의 20~30%를 할애해야 합니다. 팀이 이를 수용할 수 없다면, 비용 절감 효과는 사라집니다.

5. 프롬프트 로직이 얼마나 자주 변경됩니까?
반복 속도(iteration velocity)가 높다면 폐쇄형 모델이 유리합니다. 빠른 API 업데이트가 가능하고 재배포 주기(redeployment cycle)가 필요 없기 때문입니다. 안정적이고 잘 정의된 작업이라면 오픈 모델이 유리합니다. 한 번 설정해 두면 그대로 실행되기 때문입니다.

스스로 점수를 매겨보십시오: 세 개 이상의 답변이 폐쇄형을 가리킨다면 폐쇄형을 사용하십시오. 세 개 이상의 답변이 오픈형을 가리킨다면 자체 호스팅을 하십시오. 신호가 섞여 있다면 폐쇄형으로 시작하되, 언제든 전환할 수 있도록 추상화 레이어(abstraction layer)를 구축하십시오.

AI Handler는 이 문제에 어떻게 접근하는가

제가 AI Handler를 구축하기 시작했을 때, 저는 후회하지 않을 초기 결정을 내렸습니다. 바로 모든 모델을 통합 인터페이스(unified interface) 뒤에서 교체 가능한 백엔드(swappable backend)로 취급하는 것이었습니다. 이 제품을 사용하면 워크플로 로직(workflow logic)을 매번 다시 작성할 필요 없이, 구조적 추론(structured reasoning)을 위한 Claude, 대량 분류(high-volume classification)를 위한 로컬 Llama 인스턴스, 비용 민감형 요약(cost-sensitive summarization)을 위한 Gemini Flash 등 서로 다른 모델로 작업을 라우팅(route)할 수 있습니다.

이러한 통찰을 이끄는 핵심은 워크플로 수준에서 오픈 소스(open) 대 폐쇄형(closed) 논쟁은 잘못되었다는 점입니다. 진정한 AI 기반 제품은 "오픈" 또는 "폐쇄"된 것이 아닙니다. 위에서 언급한 다섯 가지 질문을 바탕으로 서로 다른 모델이 파이프라인(pipeline)의 각기 다른 부분을 처리하는 혼합 형태입니다. 전환 비용(switching cost) 문제는 실재하기 때문에 AI Handler가 이를 추상화(abstract)합니다. 데이터 프라이버시(data privacy) 문제는 실재하기 때문에 AI Handler는 민감한 데이터를 위한 로컬 모델 라우팅을 지원합니다. 일관성(consistency) 문제는 실재하기 때문에 AI Handler는 모델 백엔드 전반에서 작동하는 출력 검증 레이어(output validation layer)를 포함합니다.

저는 오픈 소스 대 폐쇄형 논쟁에서 승자를 선택하려는 것이 아닙니다. 저는 승자가 없다는 사실, 즉 모델 환경이 계속 변화함에 따라 작업별로, 그리고 매달 지능적으로 헤쳐 나가야 하는 일련의 트레이드오프(tradeoffs)가 존재한다는 사실을 위한 인프라(infrastructure)를 구축하고 있는 것입니다.

AI Handler는 제가 구축하고 있는 통합 AI 워크플로 도구입니다. 2026년 6월 출시 예정입니다. 베타 액세스(beta access)를 원하시면 ceo@eternalsix.com으로 이메일을 보내주세요.