1. 사내 LLM, 도입보다 운영이 어려운 이유
다양한 산업의 IT 운영팀이 폐쇄망 LLM 도입을 검토하고 있습니다. 외부 챗봇은 보안 정책상 사용이 어렵고, 모델을 직접 운영해야 하는 상황에서 어디서부터 시작해야 할지 막막하다는 이야기가 늘고 있습니다.
다행히 모델 자체의 진입장벽은 많이 낮아졌습니다. 소형 오픈소스 모델(메타의 Llama 3 8B, 미스트랄AI의 Mistral 7B 등)은 한 대의 GPU에서도 충분히 운영할 수 있는 수준이 되었습니다. 정작 어려운 부분은 모델을 도입한 다음, 사내 서비스로 안정적으로 운영해 가는 단계입니다.
이를 뒷받침하듯, Gartner는 기업이 도입한 생성형 AI 프로젝트의 30%가 시범 운영(POC, Proof of Concept) 단계에서 멈추고 실제 사내 서비스로 이어지지 못할 것이라고 분석했습니다. 모델 도입까지는 가능해도, 운영 단계에 안착하지 못하는 경우가 적지 않다는 의미입니다.
폐쇄망 LLM을 도입하기 전에 IT 운영팀이 확인해야 할 사항을 인프라·데이터·보안·모니터링 4가지로 정리합니다. 실제 운영 사례에서 자주 발생하는 문제와 점검해야 할 항목을 함께 살펴보겠습니다.
2. 폐쇄망 LLM 운영, 도입 전에 점검해야 할 4가지
폐쇄망 LLM은 클라우드처럼 즉시 리소스를 조정하거나 벤더에 위임할 수 없어, 운영팀이 직접 챙겨야 할 범위가 넓습니다. 실제 도입 현장에서는 특히 다음 4가지에서 운영 이슈가 자주 발생합니다. 각 영역은 서로 연결되어 있어 한 곳의 결정이 다른 항목의 운영 비용과 안정성에 영향을 줍니다.
1. 인프라 - GPU 사양과 데이터센터 환경
2. 데이터 - RAG와 파인튜닝
3. 보안과 운영 책임 - 권한·가드레일·법규
4. 모니터링 - 시스템 지표 + LLM 답변 품질
2-1. GPU 사양을 결정하기 전에 정해야 할 인프라 조건
LLM은 모델 크기, 응답 속도, 동시 사용자 수에 따라 필요한 인프라가 크게 달라집니다. 같은 소형 모델이라도 사내 임직원 50명이 가끔 쓰는 환경과, 콜센터에서 동시에 200명이 호출하는 환경은 GPU 구성부터 다릅니다.
이때 함께 살펴야 할 것이 데이터센터 환경 조건입니다. 일반 서버 랙은 4~10kW 수준이지만, H100급 이후 고성능 GPU를 본격적으로 운용하는 환경에서는 한 랙당 20kW를 훌쩍 넘기 때문에, 전력·쿨링·랙 공간을 함께 점검하지 않으면 운영 첫 단계부터 막히는 사례가 적지 않습니다. 최근 고성능 GPU를 다루는 환경에서는 수랭식 냉각 도입이 빠르게 늘고 있어 도입 전에 데이터센터 설비도 함께 점검하는 것이 좋습니다.
폐쇄망은 클라우드처럼 즉시 증설이 어렵기 때문에, 첫 도입 단계에서 6개월~1년치 사용량을 가정한 여유분 확보가 중요해집니다. 도입 전에 정리해야 할 항목은 다음과 같습니다.
- 사내에서 쓸 모델 크기와 양자화 여부
- 동시 사용자 수와 목표 응답 시간
- 데이터센터 전력·쿨링 여유
- 향후 확장을 위한 슬롯 여분
결과적으로 GPU 사양은 '어떻게 쓸지'가 정해진 다음에야 제대로 고를 수 있습니다.
GPU 견적서를 받기 전에 '사내에서 누가, 언제, 어떻게 쓸지'를 한 장으로 정리해 보세요. 이 한 장이 견적의 정확도와 도입 후 만족도를 좌우합니다.
2-2. 사내 데이터와 모델을 연결하는 두 가지 방법, RAG와 파인튜닝
폐쇄망 LLM은 사내 데이터를 어떻게 연결하느냐에 따라 답변 품질이 달라집니다. 크게 RAG(검색 증강 생성, Retrieval-Augmented Generation)와 파인튜닝(추가 학습) 두 가지 방법 중에서 선택하는 경우가 많습니다.
항목 | RAG | 파인튜닝 |
데이터 갱신 주기 | 자주 갱신되는 환경에 적합 | 변동 적은 도메인에 적합 |
비용 | 상대적으로 낮음 | 상대적으로 높음 |
답변 일관성 | 검색 결과에 따라 변동 | 톤·스타일 통일 |
정제 부담 | 벡터 DB 구축·관리 | 학습 데이터셋 구축 |
재학습 필요 | 없음 (문서만 갱신) | 필요 |
적합한 시기 | 매뉴얼·정책·고객 응답 | 답변 일관성·톤이 중요할 때 |
RAG는 사내 문서를 벡터 DB에 넣어두고, 질문이 들어올 때 관련 문서를 찾아 답변에 반영하는 방식입니다. 모델 재학습 없이 문서만 갱신하면 되기 때문에, 정보가 자주 바뀌는 매뉴얼·정책·고객 응답 환경에 적합합니다. 다만 문서 구조가 크게 바뀌거나 임베딩 모델을 교체할 경우에는 재벡터화 작업이 필요합니다. 파인튜닝은 사내 데이터로 답변 스타일이나 도메인 지식을 모델에 직접 학습시키는 방식입니다. 비용과 시간이 더 들지만, 답변의 일관성과 톤이 중요한 환경에서 선택합니다.
어느 방식을 택하든 먼저 거쳐야 할 공통 작업이 데이터 정제입니다. 사내 문서는 양은 많지만, 중복·구버전 문서, 민감정보가 섞인 자료, 부서별로 형식이 다른 문서가 뒤섞여 있어 그대로 쓰기 어려운 경우가 대부분입니다. 그렇기에 분류·정리·마스킹 작업이 먼저 이뤄져야 합니다.
실제 도입 프로젝트에서 데이터 정제에만 전체 일정의 30~50%가 소요되는 경우도 적지 않기 때문에 일정 설계 단계에서 별도로 시간을 넉넉히 배분해 두는 것이 안전합니다.
실무에서는 RAG와 파인튜닝을 함께 쓰는 하이브리드 구성도 늘고 있습니다. 자주 갱신되는 매뉴얼은 RAG로, 답변 톤이나 도메인 어휘는 파인튜닝으로 분담하는 식입니다.
2-3. 폐쇄망 LLM에서 추가로 챙겨야 할 보안과 운영 책임
폐쇄망에 모델을 들였다는 사실만으로 모든 보안이 해결되지는 않습니다. 모델이 사내 데이터를 학습했거나 RAG로 참조한다면, 누가 어떤 질문에 어떤 답변을 받을 수 있는지를 사용자 권한 단위로 관리해야 합니다.
대표적인 항목이 RBAC(역할 기반 접근 제어)와 MFA(다중 인증) 적용 여부입니다. 인사 정보는 인사팀에게만, 영업 데이터는 영업팀에게만 답변이 가도록 모델 응답 단계에서 권한 필터링이 필요합니다. ISMS-P 인증을 받은 환경이라면 모델 호출 로그도 감사 대상에 포함되어야 합니다.
LLM 고유의 위험으로 자주 거론되는 것이 프롬프트 인젝션입니다. 프롬프트 인젝션은 OWASP가 발표한 LLM 애플리케이션 Top 10에서 2023년 이후 줄곧 1위를 지키고 있는 보안 취약점입니다. 사용자가 시스템 프롬프트를 의도적으로 우회하거나, RAG가 참조하는 문서에 악의적인 명령어가 숨어 있어 모델이 의도하지 않은 답변을 내놓는 경우가 이에 해당합니다.
LLM 운영 책임은 IT 운영팀 단독으로 끝나지 않습니다. 모델 결과를 책임지는 부서(서비스·기획팀), 데이터 정제를 담당하는 부서(데이터·업무팀), 보안을 검토하는 부서(보안·IT 운영팀)가 각자 다를 수 있어, 누가 어떤 결정을 내리는지가 명확해야 답변에 문제가 생겼을 때 책임 소재가 분명해집니다. 한국에서는 2026년 1월 22일 시행된 AI 기본법(인공지능 발전과 신뢰 기반 조성 등에 관한 기본법)과 개인정보보호위원회의 생성형 AI 개발·활용 안내서가 LLM 운영의 기준이 되고 있어, 이에 맞춰 책임 부서별 정기 리뷰 일정을 잡아두는 경우가 많습니다.
보안은 모델 가드레일 단독이 아니라 권한 필터·입출력 검증·감사 로그를 동시에 챙겨야 합니다. 이 세 가지가 어느 부서 책임인지 도입 전에 미리 합의해 두면, 사고가 났을 때 대응 속도가 달라집니다.
2-4. 시스템 지표만으로는 부족한 LLM 모니터링
전통적인 시스템 모니터링은 CPU·메모리·응답 시간 같은 인프라 지표가 중심이었습니다. LLM 운영에서는 여기에 모델 답변의 정확도와 환각률이라는 새로운 축이 더해집니다. 시스템 지표는 모두 정상인데 답변 품질만 점점 떨어지는 상황이 자주 보고됩니다.
원인은 다양합니다. RAG가 참조하는 사내 문서가 갱신되지 않아 모델이 옛 정보를 답변하거나, 사용자 질문 패턴이 도입 초기와 달라져 모델이 처음 보는 유형이 늘어나거나, 모델 가드레일을 우회하려는 시도가 누적되는 식입니다. 이런 변화는 CPU·응답 시간만 봐서는 잡히지 않습니다. 인프라 지표를 넘어서 답변 자체를 추적하는 LLM 옵저버빌리티 관점이 필요해진 이유입니다.
답변 품질을 자동으로 평가하는 도구로는 RAGAS 같은 평가 프레임워크가 자주 사용됩니다. 답변이 질문과 얼마나 관련 있는지, 참조한 문서를 충실히 반영했는지, 환각이 얼마나 섞였는지를 수치로 측정하는 방식으로, 주기적으로 모델 성능 변화를 잡아내는 데 도움이 됩니다.
다만 자동 평가는 주기적인 점검에 적합하고, 운영팀이 매일 마주치는 이상 징후를 실시간으로 잡기엔 별도의 운영 지표가 필요합니다. 일상적으로 챙겨야 할 지표로는 다음이 자주 쓰입니다.
- 호출량과 응답 시간
- 답변에 포함된 민감정보 패턴 탐지
- 사용자 피드백(좋아요·싫어요) 비율
- 가드레일 우회 시도 횟수
이런 지표가 한 화면에 모이지 않으면 이상 알림이 떠도 어디부터 봐야 할지 정하기 어렵습니다.
자동 평가(RAGAS 등)와 운영 대시보드는 역할이 다릅니다. 자동 평가는 주기적인 모델 점검에, 운영 대시보드는 매일의 이상 감지에 씁니다. 이 둘을 분리해서 설계하면 알림이 와도 어디부터 봐야 할지 헷갈리지 않습니다.
3. 4가지를 한 플랫폼에서 다루는 방법, 통합 LLMOps
여기까지 정리하면, 인프라·데이터·보안·모니터링 4가지는 각자 다른 도구로 다루기 시작하는 순간, 도구 수가 빠르게 늘어나고 부서별 책임 경계도 흐려지기 쉽습니다. 실제 도입 현장에서는 모델 서빙 도구, 벡터 DB, 권한 체계, 모니터링 대시보드를 따로따로 들여놓고 나서 운영 인력 부담이 커지는 경우가 자주 보고됩니다.
이런 흐름 때문에 4가지를 한 플랫폼에서 통합 운영하려는 시도가 늘고 있습니다. 통합 LLMOps 플랫폼 엑셈블(eXemble)도 이런 방향으로 설계된 폐쇄망 LLMOps 솔루션으로, 온프레미스·폐쇄망 환경에서 LLM 모델 배포부터 보안·감사까지 단일 플랫폼에서 다룹니다. 앞에서 살펴본 4가지가 실제로 어떻게 한 플랫폼에 묶여 운영되는지를 다음에서 항목별로 살펴봅니다.
3-1. 데이터 소스부터 AI 서비스까지 한 흐름으로
사내 데이터는 매뉴얼, 보고서, 운영 DB 등 형태와 위치가 제각각인 경우가 많습니다. 이를 하나씩 수동으로 연결하다 보면 파이프라인 관리만으로도 운영 부담이 커집니다. 엑셈블은 다양한 소스를 자동으로 연계하는 데이터 수집 파이프라인을 제공하고, PDF·HWP·이미지 등 다양한 포맷을 자동 OCR·벡터화합니다. 데이터가 변경되면 자동 재벡터화로 검색 품질을 유지하고, 분산 쿼리 엔진으로 대용량 데이터도 조회·분석할 수 있습니다.
3-2. 코드 없이 설계하는 AI 에이전트 워크플로우
LLM 기반 업무 흐름을 구성하려면 보통 개발 리소스가 필요해 운영팀 단독으로 빠르게 시도하기 어렵습니다. 엑셈블은 드래그 앤 드롭 캔버스에서 별도 코드 없이 AI 에이전트와 외부 도구를 연결해 업무 흐름을 직접 구성할 수 있습니다. AI 응답에 사용된 출처와 판단 과정을 단계별로 공개해 환각을 줄이고, 사용자 채팅 피드백을 평가 데이터셋으로 활용해 워크플로우를 지속적으로 고도화합니다.
3-3. 한 화면에서 보는 통합 운영 대시보드
모델·데이터·보안 지표가 각각 다른 화면에 흩어져 있으면, 이상 징후가 생겨도 원인을 찾는 데 시간이 걸립니다. 엑셈블은 AI 서비스의 사용량·비용·응답 속도를 한 화면에서 통합 모니터링하고, GPU 자원 사용 패턴을 추적해 운영 비용 최적화에 활용할 수 있습니다. 모든 실행 기록은 자동으로 자산화되어 서비스 품질 개선과 사용자 행동 분석의 기반이 됩니다.
3-4. 폐쇄망 보안과 자연스럽게 연동되는 권한 관리
폐쇄망 환경이라도 사내 시스템과 별도로 LLM 서비스의 권한 체계를 새로 구성해야 한다면, 도입 초기부터 보안팀과의 협의 부담이 생깁니다. 엑셈블은 조직 구조에 맞춘 RBAC 기반 접근 권한과 부서·직급별 데이터 접근 범위 제한을 기본으로 제공해, 기존 폐쇄망 보안 정책과 자연스럽게 연동됩니다. 민감정보 자동 탐지·실시간 마스킹, 정책 위반 로그 수집과 실시간 이상 징후 관제도 함께 지원합니다.
4. 도입 검토를 시작하기 전에
앞서 정리한 인프라·데이터·보안·모니터링은 사내 LLM 운영의 토대가 되는 항목입니다. 조직마다 준비 상태는 다를 수 있지만, 도입 후 운영팀이 마주치는 어려움 대부분이 이 4가지에서 비롯됩니다. 폐쇄망 LLM 도입을 검토 중이라면, GPU 가격을 비교하기 전 이 4가지부터 정리해 두시는 것을 권합니다. 도입 이후 시행착오를 가장 많이 줄여 주는 작업입니다.
아래와 같은 상황에 해당된다면, 통합 LLMOps 플랫폼 엑셈블(eXemble)이 이러한 4가지 상황을 어떻게 다루는지 직접 확인해 보실 수 있습니다.
- 모델 도입은 했지만 운영 단계에서 멈춰 있는 PoC
- 보안과 권한이 명확하지 않아 사내 도입이 미뤄지는 상황
- 시스템 지표는 정상인데 답변 품질이 점점 떨어지는 운영 환경
- 모델·데이터·권한·모니터링이 각각 다른 도구로 분산되어 운영 책임이 흐려지는 상태
출처
"Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept by End of 2025" - Gartner (2024.07.29) ’데이터센터로 밀려드는 새 물결’ 수랭식 냉각 트렌드 따라잡기 - CIO Korea (2024.04.04) 인공지능 발전과 신뢰 기반 조성 등에 관한 기본법(AI 기본법) - 국가법령정보센터 생성형 인공지능(AI) 개발·활용을 위한 개인정보 처리 안내서 - 개인정보보호위원회 (2025.08) LLM 애플리케이션을 위한 OWASP Top 10 2025 한국어판 - OWASP (CC BY-SA 4.0)
함께 보면 좋은 아티클
