자사 LLM 구축 스택 비교 — Claude·OpenAI·오픈소스(Llama)·온프레

측정 프레임을 짰다면, 다음 관문은 스택입니다

"KPI 표는 다 그렸어요. 그런데 정작 이걸 어떤 모델로 돌릴지에서 3주째 회의만 반복입니다." 지난달 어느 제조 계열사의 DX 담당 임원이 미팅에서 한 말입니다. 저는 그 자리에서 곧바로 답을 드리지 못했습니다. 사실 이 질문에 30분짜리 정답은 없기 때문입니다.

효과 측정 프레임을 앞서 정리했지만(3회에서 다룬 ROI·KPI 설계), 그 KPI를 어떤 스택으로 달성하느냐에 따라 난이도와 비용이 두세 배씩 벌어집니다. 스택 결정은 기술 결정이 아니라 결재 결정입니다. CIO·CFO·법무·정보보안이 같은 표를 보고 의견을 맞춰야 하는 문서죠.

상용 API — Claude, OpenAI 계열

가장 빠르게 시작할 수 있는 길입니다. 계정 하나, API 키 하나로 몇 시간 안에 프로토타입이 뜹니다. Claude 3.5 Sonnet은 HumanEval 92%, 도구 호출 정확도 98% 수준의 벤치 결과를 유지하고 있고, 긴 문서 요약과 복잡한 추론에서 특히 강점을 보입니다. GPT-4o/5 계열은 다국어와 속도, Microsoft 스택과의 통합이 편해 오피스·팀즈 기반 워크플로에 잘 붙습니다.

결재자 관점에서 보면 상용 API의 진짜 가치는 성능보다 운영 부담 이관에 있습니다. 모델 업데이트, GPU 이슈, 스케일링 — 내부 팀이 신경 쓸 일이 거의 없습니다. 대신 두 가지가 발목을 잡습니다. 데이터가 외부로 나가는 사실 자체(법무·정보보안 검토가 길어짐), 그리고 트래픽이 커질수록 비용이 계단식으로 오른다는 점입니다.

솔직히 말하면, 월 토큰 사용량이 아직 작다면 이 선택이 거의 대부분의 경우 정답에 가깝습니다. Claude·OpenAI 상위 프론티어 모델의 zero-data-retention 계약과 프라이빗 엔드포인트를 확보할 수 있다면, 금융·법무 영역에서도 실무 배포 사례가 늘고 있습니다.

오픈소스 — Llama, Mistral 계열

Llama 3 70B, Mistral 계열의 오픈 웨이트 모델은 HumanEval 81% 대, 도구 호출 82% 대로 상용 프론티어 대비 5~10% 정도의 성능 갭이 있습니다. 2년 전엔 20% 갭이었으니 매년 좁혀지는 추세입니다. 문서 요약, 사내 FAQ, RAG 기반 지식 검색 같은 대부분의 실무 태스크에서는 체감 차이가 크지 않습니다.

가장 큰 매력은 두 가지입니다. 첫째, 데이터가 회사 밖으로 한 발짝도 나가지 않게 설계할 수 있습니다. 둘째, 상용 대비 5~50배 저렴한 토큰 단가(호스티드 프로바이더 기준)로 대량 트래픽을 감당합니다. 자체 GPU를 쓰면 실질적으로는 운영비만 듭니다.

다만 오픈소스는 "공짜"가 아닙니다. 파인튜닝(LoRA 기준 7~14B 모델)에 회당 50만~300만원, 70B 풀 파인튜닝은 3천만원 이상이 들어갑니다. 여기에 모델 서빙 인프라, 모니터링, 프롬프트 관리, 버전 롤백 체계까지 붙이면 사내에 최소 한 명의 MLOps 인력이 필요합니다. 이 인건비가 견적서에서 자주 빠집니다.

온프레미스 자체 호스팅 — 손익분기 감각

완전 폐쇄망, 규제 산업, 국방·공공 등에서는 온프레미스 외의 선택지가 없습니다. 초기 GPU 서버 구축은 규모에 따라 억 단위입니다. 모델 서빙 인프라 자체의 월 운영 비용은 100만~500만원 선에서 시작하지만, 여기에 24x7 운영과 DevOps 인건비가 붙습니다. 미국 리서치 기준으로도 인프라 운영에만 월 $5,000~$30,000+ 가 흔한 수준입니다.

결재 관점의 손익분기점은 대략 이렇습니다. 월 사용 토큰이 500만~2B 토큰 구간을 넘어가면 자체 호스팅이 상용 API보다 저렴해지기 시작합니다. 그 미만이라면 자체 호스팅은 대체로 총비용에서 손해입니다. 처음엔 "우리는 데이터가 민감하니 무조건 온프레"라고 시작했다가, 실제 트래픽 시뮬레이션을 해보면 상용 API의 프라이빗 엔드포인트가 더 합리적이었던 사례가 저희 컨설팅에서 반복적으로 나옵니다.

데이터 민감도별 권장 스택

실무에서 저희가 결재 문서에 자주 넣는 매트릭스를 정리하면 이렇습니다.

2026년, 결국 답은 하이브리드입니다

지금 시장의 컨센서스는 하이브리드 라우팅입니다. 저비용·고빈도 트래픽(FAQ, 분류, 요약)은 오픈소스나 저비용 상용 모델로 흘리고, 프론티어 추론이 필요한 5~25%의 트래픽만 Claude·GPT 상위 모델로 라우팅하는 구조입니다. 전체 비용은 절반 이하로 줄고, 사용자가 체감하는 품질은 거의 그대로 유지됩니다.

이 구조가 가능해진 이유는 오픈소스 성능이 실무 수준에 올라왔기 때문입니다. 30%라고 하면 작아 보이지만, 트래픽의 75%를 5배 싼 모델로 돌리면 총비용의 60% 이상이 사라진다는 얘기입니다. 결재 문서에서 이 숫자는 힘이 셉니다.

다만 하이브리드는 스택이 하나 더 붙는 대신 라우팅 로직·모니터링·비용 대시보드가 필요합니다. 이 관리 부담을 감내할 만큼의 트래픽이 나오는가 — 이것이 하이브리드 도입의 실질적인 기준선입니다.

정리 — 그리고 다음 관문

스택 선택은 앞선 회차에서 다룬 RAG/파인튜닝 방식 결정과 붙어 있습니다. RAG 중심이라면 상용 API로도 충분히 가고, 도메인 특화 파인튜닝이 필요하다면 오픈소스 자체 호스팅의 근거가 강해집니다. 처음부터 완벽한 스택을 고를 필요는 없습니다. 6개월 후 트래픽·품질 데이터를 보고 재조정한다는 전제로, 지금은 가장 빨리 검증할 수 있는 스택부터 시작하는 편이 결과적으로 총비용이 낮았습니다.

다음 5회에서는 이 스택별로 실제 규모별 견적이 어떻게 나오는지 — 자사 LLM 구축 비용과 예산 수립 — 규모별 견적 가이드 2026 편을 다룰 예정입니다. 오늘 다룬 스택 매트릭스가 실제 숫자로 어떻게 번역되는지 보실 수 있습니다.

저희 5years+는 한국·일본 중견·중소기업의 자사 LLM 도입을 지원하면서 이 스택 결정을 함께 검토해왔습니다. 사내에서 스택 선정을 검토 중이시라면, 스택 선정 무료 상담을 통해 현재 데이터 민감도·트래픽 예측을 기준으로 한 권장안을 정리해드립니다.