폐쇄형 LLM과 사내 LLM 구축: 지속 가능한 기업 AI의 조건
보안 때문에 생성형 AI 도입이 막혀 있다면, 질문을 바꿔볼 때입니다. 데이터가 회사 밖으로 나가지 않는 폐쇄형 LLM의 뜻과 기업 AI의 추세가 사내 LLM 구축과 sLLM으로 움직이는 이유, 우리 회사에 맞는지 판단하는 네 가지 기준을 정리했습니다.
Aug 21, 2026
생성형 AI를 업무에 쓰자는 논의가 사내에서 막히는 지점은 대개 한 곳입니다. 바로 보안입니다. 고객 정보가 담긴 문서를 외부 AI에 붙여넣어도 되는가라는 질문은 기업 AI의 도입과 활용을 막는 요인이 됩니다. 적지 않은 회사가 사내 사용을 금지하는 방편을 택했습니다. 그러나 이렇게 마냥 기업 내 AI 사용을 억제만 할 수도 없습니다. 경쟁사는 AI로 업무 속도를 올리고 있고, 직원들은 저마다 남몰래 개인 계정으로 씁니다.
이 교착을 푸는 질문은 "제일 좋은 모델이 무엇인가"가 아닙니다. "우리 데이터를 어디에 둘 것인가"입니다. 질문을 바꾸면 선택지에 폐쇄형 LLM, 그러니까 데이터가 회사 밖으로 나가지 않는 사내 LLM 구축에 대한 이야기입니다.이 글은 폐쇄형 LLM이 무엇인지, 현재 시장이 왜 이 방향으로 움직이는지, 어떤 조건에서 맞는 선택인지, 그리고 구축은 어떤 경로로 하는지를 정리합니다.
폐쇄형 LLM이란?
폐쇄형 LLM은 외부 서버로 데이터를 보내지 않고 회사가 통제하는 환경 안에서 돌아가는 대규모 언어모델을 가리킵니다. 실무에서는 여러 이름으로 불립니다. 회사 서버에 직접 설치하면 온프레미스(on-premise) LLM, 회사 전용 클라우드 공간에 올리면 프라이빗 LLM, 규모를 줄여 특정 업무에 맞춘 소형 모델이면 sLLM(소형 언어모델)입니다. 명칭은 달라도 공통점은 하나입니다. 프롬프트에 입력한 데이터가 회사가 통제하지 않는 외부로 나가지 않는다는 것.
반대편에 있는 것이 상용 LLM API입니다. 챗GPT나 클로드 같은 서비스를 API로 호출해 쓰는 방식으로, 성능은 앞서지만 데이터가 외부 사업자의 서버를 거칩니다. 이 구조 차이가 이 글 전체의 출발점입니다.
상용 LLM API에서 데이터의 보안
상용 API를 쓰는 순간 데이터의 경로는 이렇게 됩니다. 직원이 프롬프트에 입력한 내용, 거기에 첨부된 사내 문서와 고객 정보가 외부 사업자의 서버로 전송되어 처리됩니다. 사업자마다 학습 활용 여부와 보관 정책이 다르고 기업용 요금제는 보호 조항을 강화하고 있지만, 발주자 관점의 본질은 남습니다. 데이터가 우리 통제 밖의 인프라를 거친다는 사실 자체입니다. 개인정보보호법상 처리 위탁·국외 이전 검토가 필요해지는 지점이기도 합니다.
규제 산업에서는 이것이 선택의 문제가 아닙니다. 국내 금융권은 망분리 규제로 외부 생성형 AI 사용이 원천적으로 제약되어 왔고, 그래서 금융사들의 대응은 처음부터 사내 구축이었습니다. 미래에셋증권은 온프레미스 방식의 금융 특화 sLLM을 구축해, 직원과 부서가 업무 매뉴얼과 노하우 문서를 올려 학습시키고 전용 챗봇을 만들어 쓰는 구조를 운영하고 있습니다. 다른 은행과 증권사들도 같은 방향을 검토 중인 것으로 전해집니다. 망분리 규제는 완화 논의가 진행 중이지만, 민감 데이터를 다루는 산업의 기본 감각이 "데이터는 안에 둔다"라는 점은 달라지지 않았습니다.
AI 업계에서 기업들의 선택은 이미 달라지고 있습니다
이같은 기업 AI의 흐름은 비단 국내 금융권에 국한되지 않습니다. 이러한 현상은 국내외를 막론하고 글로벌한 방향성과도 부합합니다.
기업 서베이에서 프로덕션 AI 추론의 주 환경으로 퍼블릭 클라우드를 쓴다는 응답은 1년 사이 56%에서 41%로 떨어졌고, 프라이빗 클라우드에서 운영하거나 계획 중이라는 응답이 56%에 이릅니다. 2026년 현재 규제 산업의 기본 배포 방식은 전용 클라우드(VPC) 또는 온프레미스로 자리 잡았다는 것이 업계의 관측입니다. 2024~2025년을 지배했던 데이터 보안 불안이, 민감한 워크로드를 퍼블릭 API에서 빼내는 이동으로 귀결된 것입니다. 국가 단위로도 같은 방향이 보입니다. 시장조사기관 가트너(Gartner)는 2027년까지 세계 국가의 35%가 자국 통제형(소버린) AI 플랫폼에 의존할 것으로 전망했습니다.
모델 선택의 기준도 함께 바뀌었습니다. 최신 초거대 모델을 따라가는 대신, Phi나 Llama, Mistral 계열의 소형 모델을 자사 데이터로 파인튜닝해 사내에 배포하는 SLM 전략이 확산되고 있습니다. 국내 기업들의 AI 전략 분석에서도 중심은 sLLM입니다. 업무별로 다른 모델을 쓰는 라우팅, 그러니까 민감하고 반복적인 업무는 사내 소형 모델로, 일반적인 탐색 업무는 상용 API로 나눠 보내는 구성이 비용과 성능의 실무 최적점으로 정리되는 중입니다.
성능 격차는 모델의 성능이 아닌, 최적화로 좁힙니다
사내 LLM 구축을 검토할 때 가장 흔한 반문은 성능입니다. 작은 모델이 최신 상용 모델을 따라갈 수 있느냐는 것입니다. 범용 능력으로는 못 따라갑니다. 그러나 회사 업무의 대부분은 범용 문제가 아닙니다.
우리 회사의 계약서 양식을 검토하고, 우리 제품의 매뉴얼로 고객 문의에 답하고, 우리 부서의 보고서 형식으로 초안을 쓰는 일. 이런 도메인 업무에서는 자사 데이터로 파인튜닝하고 사내 문서를 검색해 답에 반영하는 RAG를 붙인 소형 모델이, 아무 맥락 없는 범용 대형 모델보다 나은 결과를 내는 경우가 많습니다. 최적화의 핵심은 모델의 크기가 아니라 우리 업무와의 정합입니다.
이 방향을 학술적으로 정리한 논문이 근래 발표된 바 있습니다. 엔비디아(NVIDIA) 연구진이 조지아공대와 함께 발표한 「Small Language Models are the Future of Agentic AI」는, 기업의 에이전트형 AI 업무 대부분이 의도 분류, 데이터 추출, 정형 출력처럼 좁고 반복적이어서 소형 언어모델이 충분히 강력하고, 구조적으로 더 적합하며, 더 경제적이라고 논증합니다. 실험 수치도 실려 있습니다. 모든 작업을 중형 모델(7B)에 맡긴 구성과, 하위 작업은 소형 모델(3B)이 처리하고 중형 모델은 검증만 맡는 이종 구성을 비교했더니 성능은 거의 같았고 지연은 31.6%, 비용은 41.8% 줄었습니다. 사소한 요청까지 거대 모델로 보내며 예산을 태우는 관행에 대한 지적인 셈인데, 초거대 모델 붐의 최대 수혜 기업이 소형 모델의 미래를 논증하고 있다는 사실 자체가 이 전환의 방향을 보여줍니다.
비용 구조도 다릅니다. 사용량이 많은 업무라면 자체 호스팅한 공개 가중치 모델이 프리미엄 상용 API보다 토큰당 최대 18배 저렴하다는 분석이 있습니다. 물론 조건이 붙는 숫자입니다. 사용량이 적으면 API 종량제가 싸고, 자체 호스팅에는 GPU 인프라와 운영 인력이 필요합니다. 중견기업 기준 하드웨어 진입선이 1만~1만 5천 달러 수준까지 내려왔다는 점을 감안해도, 이 계산은 사용량과 업무 성격에 따라 달라집니다. 그래서 다음 장의 판단 기준이 필요합니다.
온프레미스 LLM이 성능을 내는 환경: 국외 사례
숫자와 논문이 가리키는 이같은 성능은, 실제 현장에서도 확인됩니다.
미국의 데이나파버 암연구소(Dana-Farber Cancer Institute)는 병원 사설망 안에 LLM을 통째로 올렸습니다. 프롬프트와 응답이 격리된 환경을 벗어나지 않고, 모델은 인터넷에 접근하지 못합니다. 의료정보보호법(HIPAA)을 지키면서 직원들의 문서 작성과 분석 업무 생산성을 끌어올렸고, 거버넌스 위원회와 사용 정책으로 리스크를 관리합니다. 인도 통계부는 정부 보안 인프라 위에 공개 가중치 모델을 자체 호스팅해, 1만 건이 넘는 국가 통계 문서를 검색해 답하는 RAG 시스템을 외부 API 호출 없이 운영하고 있습니다.
두 사례의 공통점이 온프레미스 LLM이 효용을 내는 환경을 보여줍니다. 첫째, 규제가 강한 데이터(의료 기록, 국가 통계)를 다루기 때문에 외부 전송 자체가 선택지에 없습니다. 둘째, 업무가 사내 문서 자산에 묶여 있어 RAG로 답의 정합도를 끌어올릴 여지가 큽니다. 셋째, 같은 유형의 질의가 조직 전체에서 반복되어 구축 비용이 사용량으로 회수됩니다. 2025년 기업 AI 지출의 절반 이상이 온프레미스로 향했고 그 앞줄에 은행과 병원, 공공기관이 서 있다는 집계는, 이 세 조건이 갖춰진 곳부터 이동이 일어나고 있음을 보여줍니다.
사내 LLM 구축이 맞는 조건, 아닌 조건
물론 폐쇄형 LLM이 모든 회사의 답은 아닙니다. 판단과 결정의 기준은 네 가지입니다.
- 데이터 민감도: 고객 개인정보, 금융·의료 정보, 영업 기밀이 프롬프트에 실리는 업무라면 사내 구축 쪽 근거가 강해집니다. 공개 자료 중심의 업무라면 상용 API로 충분합니다.
- 규제 환경: 망분리, 개인정보 국외 이전 제한, 산업별 컴플라이언스가 걸려 있다면 선택지가 사실상 정해져 있습니다.
- 사용량과 반복성: 같은 유형의 업무가 대량으로 반복된다면 자체 호스팅의 경제성이 살아나고, 간헐적 사용이라면 API 종량제가 합리적입니다.
- 운영 여력. 사내 구축은 만들고 끝나지 않고 운영과 재학습이 따라옵니다. 이 여력이 없으면 구축형보다 관리형(프라이빗 클라우드)이 현실적입니다.
정리하면 이렇습니다. 민감 데이터를 다루는 반복 업무는 사내 sLLM, 일반 업무는 상용 API. 그러나 실무 현장에서는 두 가지 선택지 중 하나를 고르는 문제라기보다 부서별, 업무별로 나뉠 수밖에 없습니다. 실제로 시장이 정착시키고 있는 기업 AI 구성도 이와 같은 혼합형이기도 합니다.
사내 LLM 구축의 실행 경로와 물어야 할 질문
사내 LLM 구축이 맞다고 판단되면 경로는 셋으로 나뉩니다. 내부 팀을 꾸리거나, 기성 솔루션을 도입하거나, 외주 개발로 구축하는 것입니다.
내부 팀은 LLM 엔지니어 채용이 전제인데, 이 인력은 채용 시장에서 가장 확보가 어려운 구간에 있습니다. 신사업 개발 인력 채용에 서너 달이 걸리는 시장 상황은 「개발 병목 없이 일정을 지키는 법」에서 다뤘고, LLM 특화 인력은 그보다 좁은 시장입니다. 기성 솔루션은 빠르지만 우리 업무 데이터와 문서 구조에 맞춘 커스터마이징에 한계가 있고, 솔루션 사업자에 대한 종속이 생깁니다. 외주 개발은 우리 업무에 맞춘 파인튜닝과 RAG 구성을 프로젝트 단위로 진행하는 경로로, 사내 LLM 구축을 외주 개발로 진행할 때는 일반 시스템 개발과 같은 검증 원칙이 적용됩니다.
어느 경로든 맡기기 전에 네 가지를 물어야 합니다. 첫째, 데이터 흐름도. 학습과 추론 각 단계에서 데이터가 어디를 거치는지 그림으로 받습니다. "사내에 구축한다"는 말과 실제 아키텍처가 다른 경우를 거르는 질문입니다. 둘째, 모델 선택의 근거. 왜 이 모델이고 왜 이 크기인지, 우리 업무 기준의 성능 검증 계획이 있는지 확인합니다. 셋째, 운영과 재학습의 비용 구조. 구축비 뒤에 오는 GPU 운영비, 모델 업데이트, 재학습 주기가 견적에 있는지 봅니다. 시스템 생애비용의 대부분이 구축 후에 발생한다는 원칙은 「개발 종료 후 유지보수 비용의 진실」에서 다뤘는데, LLM은 모델 노화가 있어 이 비중이 더 큽니다. 넷째, 소유권. 파인튜닝된 모델과 학습에 쓴 데이터, 구축된 시스템의 권리가 계약서에 명시되어 있는지 확인합니다.
모델은 바뀌어도 데이터는 남습니다
최신 모델의 순위는 몇 달 단위로 바뀝니다. 지금 1위 모델은 내년에 구형이 됩니다. 반면 한 번 외부로 나간 데이터는 돌아오지 않고, 우리 업무에 맞게 최적화된 사내 모델과 그 학습 데이터는 회사에 남는 자산이 됩니다. 2026년의 시장이 폐쇄형 LLM과 sLLM으로 움직이는 이유를 한 문장으로 줄이면 이것입니다. 모델은 갈아탈 수 있지만 데이터 통제권은 갈아탈 수 없습니다.
스파르타빌더스는 AI 기능 개발을 포함한 외주 개발에서 데이터 흐름도와 운영·재학습 설계, 산출물 소유권 명시를 계약 표준으로 다룹니다. 구축한 시스템을 인수인계 패키지로 넘겨 발주사가 내재화할 수 있는 상태로 마무리하는 원칙은 사내 LLM 구축에서도 같습니다. 보안 때문에 AI 도입이 멈춰 있다면, 위의 판단 기준 네 가지부터 검토해 보시기 바랍니다.
자주 묻는 질문
Q1. 폐쇄형 LLM이 정확히 무엇입니까?
- 프롬프트에 입력한 데이터가 회사가 통제하지 않는 외부 서버로 나가지 않는 구조의 언어모델을 통칭합니다. 회사 서버에 설치하는 온프레미스 LLM, 전용 클라우드에 올리는 프라이빗 LLM, 특정 업무에 맞춘 소형 모델인 sLLM이 모두 여기에 속합니다. 판단 기준은 데이터의 경로 하나입니다.
Q2. sLLM 같은 작은 모델이면 성능이 많이 떨어지지 않습니까?
- 범용 능력은 최신 상용 모델이 앞섭니다. 다만 회사 업무의 대부분은 도메인 문제라서, 자사 데이터로 파인튜닝하고 사내 문서 검색(RAG)을 붙인 소형 모델이 해당 업무에서는 더 정확한 경우가 많습니다. 우리 업무 기준의 성능 검증을 구축 전에 설계하는 것이 실무 순서입니다.
Q3. 사내 LLM 구축 비용은 어느 정도입니까?
- 범위가 넓습니다. 하드웨어는 중견기업 기준 1만~1만 5천 달러 수준의 진입선까지 내려왔고, 사용량이 많은 업무라면 자체 호스팅이 상용 API 종량제보다 토큰당 크게 저렴해질 수 있습니다. 반대로 사용량이 적으면 API가 쌉니다. 구축비보다 중요한 것은 GPU 운영·재학습을 포함한 운영 비용 구조를 견적 단계에서 확인하는 것입니다.
Q4. 우리 회사에 사내 LLM 구축이 필요한지 어떻게 판단합니까?
- 네 가지 축으로 봅니다. 프롬프트에 민감 데이터가 실리는가, 규제(망분리·개인정보 국외 이전)가 걸리는가, 같은 업무가 대량 반복되는가, 운영 여력이 있는가. 넷 중 앞의 둘에 해당하면 구축 검토가 필요하고, 전부 아니라면 상용 API의 기업용 요금제로 충분할 가능성이 높습니다. 실무 정답은 대개 업무별로 나누는 혼합 구성입니다.
Q5. 사내 LLM 구축을 외주 개발로 진행할 수 있습니까?
- 가능하고, 내부에 AI 인력이 없는 회사의 현실적인 경로입니다. 다만 일반 외주 개발과 같은 검증 원칙이 적용됩니다. 데이터 흐름도, 모델 선택 근거, 운영·재학습 비용, 그리고 파인튜닝된 모델과 데이터의 소유권을 계약 단계에서 확인해야 합니다. 특히 소유권 조항이 없으면 산출물이 개발사에 귀속될 수 있으므로 계약서 명시가 필수입니다.
Share article