최근 사내 AI 전환이 가속화되면서, 폐쇄망 환경에서도 대규모 언어모델(LLM)을 운영하려는 기업이 늘고 있습니다.
특히, OpenAI나 HuggingFace와 같은 외부 서비스 접근이 제한된 환경에서는 로컬 기반 LLM 서버가 핵심 역할을 합니다.
이번 글에서는
👉 현재 많이 사용되는 Ollama + OpenWebUI 조합의 장단점을 살펴보고,
👉 200명 규모의 개발자들이 함께 사용하는 확장형 LLM+RAG 아키텍처 구성 전략과
👉 Nginx 포트 확장을 통한 멀티서비스 운영 방법까지 정리해보겠습니다.
🧠 1. 현재 환경: Ollama + OpenWebUI
많은 조직에서 가장 손쉽게 구축할 수 있는 방식은 아래 조합입니다.
- Ollama : 로컬에서 LLM 모델을 실행 (예: llama3, qwen, mistral 등)
- OpenWebUI : Ollama API를 UI로 감싸 사용자 친화적인 인터페이스 제공
이 조합의 장점은 명확합니다:
✅ 설치 간단 (Docker 기반으로 몇 줄이면 구축 가능)
✅ 로컬 GPU 활용 가능 (CUDA 자동 인식)
✅ 모델 캐싱, 프롬프트 히스토리, 사용자별 관리 기능 지원
하지만 동시에 아래와 같은 한계도 존재합니다.
⚠️ 2. Ollama + OpenWebUI의 한계
| 항목 | 설명 |
|---|---|
| 성능 확장성 | 다중 사용자(200명 이상) 동시 접속 시 GPU 리소스 한계 노출 |
| 모델 관리 | Ollama는 모델 버전 관리나 fine-tuning 지원이 부족 |
| RAG 연결 | 벡터DB, 문서 검색 기능은 수동 연동 필요 (예: Milvus, Chroma 등 별도 구성) |
| 엔터프라이즈 인증 | LDAP, SSO 등 조직 인증 체계 연동이 어려움 |
| API 관리 | 모델별 API rate limit이나 로깅, 분석 기능이 부족 |
따라서 단일 서버에서 다수 사용자가 사용하는 환경이라면,
보다 체계적인 LLM Serving Framework를 고려할 필요가 있습니다.
🧩 3. Ollama의 대체 또는 보완 가능한 프레임워크
(1) vLLM
- NVIDIA GPU 환경에 최적화된 고성능 LLM Serving 엔진
- HuggingFace 모델 직접 로드 가능
- Tensor Parallel / Multi-GPU 지원
- OpenAI API 호환 REST API 제공 → 기존 OpenWebUI 그대로 사용 가능
🔧 장점:
- Ollama 대비 2~4배 빠른 응답 속도 (KV cache 최적화)
- RAG 시스템 연동이 용이 (LangChain, LlamaIndex와 자연스러운 연결)
📦 폐쇄망 배포:
docker run --gpus all -p 8000:8000 vllm/vllm \
--model /models/llama3-8b \
--api-key mysecret(2) Text Generation WebUI
- 여러 모델 엔진(Transformers, GPTQ, ExLlama, vLLM 등)을 동시에 다룸
- RAG, Embedding, Prompt Template, 사용자 관리까지 내장
🔧 장점:
- Ollama보다 훨씬 많은 기능 제공 (채팅, LoRA, 번역, 문서요약 등)
- 웹UI 사용자 경험이 우수
📦 단점:
- 설치 복잡도 높음 (Python 환경 + CUDA 세팅 필요)
- 대규모 사용자 환경에는 별도 프록시 구성 필요
(3) LangChain + vLLM + Milvus 조합
진짜 RAG 환경 구축을 원한다면 이 조합이 이상적입니다.
| 구성 요소 | 역할 |
|---|---|
| LangChain | 프롬프트 엔지니어링, Chain, RAG 구성 로직 |
| vLLM | LLM 모델 추론 API 서버 |
| Milvus / Qdrant | 벡터DB (내부 문서 임베딩 저장) |
| FastAPI / Flask | 사내 API 게이트웨이 구성 가능 |
이 조합으로 구축하면
✅ 사내 문서를 벡터화하여 질문 응답
✅ GPU 효율적으로 활용
✅ OpenWebUI에서 그대로 프롬프트 사용 가능
🌐 4. Nginx로 포트별 멀티서비스 구성하기
200명 개발자가 동시에 다양한 기능을 이용하려면,
단일 포트에 모든 기능을 몰아넣기보다는 Nginx Reverse Proxy를 통한 포트별 서비스 분리 전략이 효과적입니다.
예시 구성:
| 포트 | 서비스 | 설명 |
|---|---|---|
80 |
OpenWebUI (기본 LLM 인터페이스) | Ollama 또는 vLLM 연결 |
8080 |
RAG API Gateway | LangChain + Milvus 기반 질의응답 API |
8040 |
정적 웹 포털 | 매뉴얼, 문서, 모델 사용 가이드 |
8050 |
Admin UI | 로그, 사용량 통계 대시보드 |
8060 |
내부 챗봇 API | Slack, Teams 등 연동용 REST API |
Nginx 설정 예시:
server {
listen 80;
location / {
proxy_pass http://10.88.2.99:3000; # OpenWebUI
}
}
server {
listen 8080;
location /api/ {
proxy_pass http://10.88.2.99:8000; # vLLM API
}
}
server {
listen 8040;
root /var/www/html;
index index.html;
}🧭 5. 권장 아키텍처 요약
사용자(200명)
↓
[Nginx Proxy]
├─ 80 → OpenWebUI (vLLM 연결)
├─ 8080 → LangChain RAG API
├─ 8040 → 정적 가이드 웹
├─ 8050 → Admin / Monitoring
└─ 8060 → Slack Bot API✅ 결론: “Ollama는 좋은 출발점이지만, 한계는 분명하다”
- 소규모 실험용 → Ollama + OpenWebUI 조합으로 충분
- 조직형 운영(200명 이상) → vLLM 기반 아키텍처로 확장 권장
- RAG 환경 구축 시 → LangChain + Milvus 추가
- 운영 안정성 확보 → Nginx를 통한 포트별 서비스 분리
이 방식으로 구성하면
“폐쇄망 환경에서도 ChatGPT 수준의 사내 LLM 서비스”
를 안전하고 확장성 있게 운영할 수 있습니다.
💡 다음 글 예고
다음 글에서는 👉
“폐쇄망에서 vLLM + LangChain 기반으로 사내 지식RAG 구축하는 방법”
을 실전 예제와 함께 다루겠습니다.
댓글