로컬 PC에 Ollama를 설치하거나 사내 서버에 vLLM을 올렸다고 해서 곧바로 ChatGPT 같은 서비스가 완성되는 것은 아닙니다. 모델에 질문을 전달하는 API는 생겼지만, 사용자가 대화를 시작하고 이전 기록을 찾고 문서를 첨부하며 여러 모델을 바꿔 쓰는 화면은 아직 없기 때문입니다.
이 빈자리를 채우는 것이 AI 모델용 UI입니다. 처음에는 단순한 채팅 화면에 가까웠지만, 지금은 사용자 인증, 모델 권한, RAG, 웹 검색, 코드 실행, MCP 도구, 에이전트와 관리 기능까지 담당하는 플랫폼으로 발전했습니다.
대표적인 프로젝트가 Open WebUI입니다. 다만 모든 환경에 Open WebUI가 정답인 것은 아닙니다. LibreChat은 여러 상용 모델과 에이전트를 한 화면에서 운영하는 데 강하고, AnythingLLM은 문서 기반 RAG를 빠르게 시작하기 좋습니다. Jan은 개인 PC의 로컬 실행에 초점을 맞추고, Dify는 채팅 UI를 넘어 AI 애플리케이션과 워크플로를 만드는 플랫폼에 가깝습니다. LobeChat으로 알려졌던 LobeHub도 이제는 멀티에이전트 운영 공간으로 성격이 확장되었습니다.
이 글에서는 2026년 7월 현재 많이 검토되는 여섯 프로젝트를 같은 기준으로 비교하고, 개인용·사내용·RAG·에이전트 앱 개발이라는 목적에 따라 어떤 도구를 선택하면 좋은지 정리합니다.
여기서는 소스가 공개되고 자체 호스팅할 수 있는 프로젝트를 넓은 의미의 “오픈소스 AI UI”로 묶었습니다. 다만 Open WebUI 최신 버전, LobeHub와 Dify에는 표준 MIT·Apache 2.0과 다른 추가 조건이 있습니다. 엄밀한 OSI 오픈소스 여부와 상업적 이용 가능 범위는 뒤의 라이선스 항목에서 별도로 구분합니다.

먼저 구분할 것: 모델 서버와 AI UI는 다른 계층이다
Ollama, vLLM, llama.cpp 서버는 모델을 메모리에 올리고 추론 요청을 처리합니다. OpenAI, Anthropic, Google 같은 서비스는 클라우드 API로 같은 역할을 제공합니다. 반면 Open WebUI 같은 프로젝트는 이 모델과 사람 사이의 사용 경험을 구성합니다.
전체 구조를 단순화하면 다음과 같습니다.
사용자
↓
AI UI ── 대화 기록, 파일, 사용자·권한, 모델 선택
├─ 모델 API ── Ollama, vLLM, OpenAI, Anthropic, Google 등
├─ 지식 계층 ── 문서 파싱, 임베딩, 벡터 DB, RAG
├─ 도구 계층 ── 웹 검색, 코드 실행, 함수 호출, MCP
└─ 운영 계층 ── 인증, 접근 제어, 비용, 로그, 백업
따라서 “로컬 AI를 구축한다”는 말에는 적어도 두 가지 결정이 포함됩니다.
- 어떤 모델을 어디에서 실행할 것인가
- 사용자가 어떤 UI를 통해 그 모델과 데이터에 접근할 것인가
UI를 바꾸더라도 같은 Ollama나 OpenAI 호환 API를 계속 사용할 수 있습니다. 반대로 UI가 훌륭해도 연결한 모델의 성능, 컨텍스트 길이와 도구 호출 능력까지 좋아지는 것은 아닙니다. 기능이 모델 자체에서 제공되는지, UI가 별도 계층으로 구현하는지 구분해야 합니다.
비교할 때 봐야 할 일곱 가지
첫 화면이 예쁜지만 보고 선택하면 실제 운영에서 곤란해질 수 있습니다. 다음 항목을 함께 봐야 합니다.
1. 연결할 수 있는 모델
Ollama만 연결할 것인지, OpenAI·Anthropic·Google·Bedrock 같은 여러 공급자를 함께 쓸 것인지에 따라 선택이 달라집니다. OpenAI 호환 API를 지원한다는 문구도 모든 기능이 똑같이 동작한다는 뜻은 아닙니다. 스트리밍, 비전, 도구 호출과 추론 과정 표시 등은 모델과 API 구현에 따라 차이가 납니다.
2. 개인용인가, 팀 공용인가
한 명이 노트북에서 쓰는 앱과 수백 명이 로그인하는 사내 서비스는 요구사항이 다릅니다. 팀용이라면 사용자 가입 정책, SSO, 그룹, 모델별 권한, 공유 프롬프트와 감사 가능성을 확인해야 합니다.
3. 문서와 RAG가 핵심인가
파일 첨부만 필요한지, 부서별 지식 베이스를 만들고 검색 품질을 조정해야 하는지 구분해야 합니다. 문서 파싱, 청킹, 임베딩 모델, 벡터 데이터베이스, 하이브리드 검색, 재순위화와 출처 표시가 모두 RAG 품질에 영향을 줍니다.
4. 도구와 에이전트가 필요한가
단순 질의응답을 넘어 웹 검색, 사내 API 호출, 코드 실행이나 업무 자동화를 하려면 함수 호출과 MCP 지원을 확인해야 합니다. 다만 도구가 많다는 것은 모델이 수행할 수 있는 작업과 보안 위험이 함께 늘어난다는 뜻입니다.
5. 설치와 운영 복잡도
단일 데스크톱 앱, 단일 컨테이너, 여러 데이터베이스가 포함된 Docker Compose, Kubernetes 배포는 운영 난도가 다릅니다. 백업해야 할 데이터와 업그레이드 시 마이그레이션 절차도 확인해야 합니다.
6. 데이터가 실제로 어디로 가는가
자체 호스팅 UI를 쓴다고 모든 처리가 자동으로 로컬에서 끝나는 것은 아닙니다. 클라우드 모델, 외부 임베딩 API, 웹 검색, OCR 또는 관측 서비스를 연결하면 프롬프트와 문서 일부가 외부로 전달될 수 있습니다.
7. 라이선스와 상업적 사용 조건
소스 코드가 GitHub에 공개되어 있다는 사실과 제한 없는 오픈소스 라이선스는 같은 말이 아닙니다. 특히 화이트라벨, 고객 대상 SaaS, 멀티테넌트 제공이나 파생 제품 배포를 계획한다면 최신 LICENSE를 직접 확인해야 합니다.
한눈에 보는 여섯 프로젝트
| 프로젝트 | 중심 성격 | 가장 잘 맞는 용도 | 배포 형태 | 라이선스 요약 |
| Open WebUI | 범용 셀프호스팅 AI 작업 공간 | Ollama와 여러 API를 팀이 함께 사용 | Docker, Python, Kubernetes 등 | v0.6.6부터 브랜딩 조건이 추가된 라이선스 |
| LibreChat | 멀티프로바이더 ChatGPT형 웹 앱 | 여러 상용·로컬 모델, 에이전트와 MCP를 한곳에서 운영 | 주로 Docker Compose, 웹 서비스 | MIT |
| LobeHub | 에이전트 작업·협업 공간 | 완성도 높은 UI와 멀티에이전트 협업 | Docker, Vercel 등 | Apache 2.0 기반 Community License, 파생 배포 조건 존재 |
| AnythingLLM | 문서·워크스페이스 중심 AI 앱 | 빠른 사내 RAG와 개인 문서 질의 | 데스크톱, Docker | MIT |
| Jan | 로컬 우선 데스크톱 AI | 개인 PC에서 오프라인 모델 실행 | macOS, Windows, Linux 데스크톱 | Apache 2.0 |
| Dify | AI 앱·워크플로 개발 플랫폼 | RAG·에이전트 앱을 만들고 API나 웹 앱으로 공개 | Cloud, Docker Compose, 자체 호스팅 | 수정된 Apache 2.0, 멀티테넌시·브랜딩 조건 존재 |
이 표에서 중요한 점은 여섯 제품이 완전히 같은 범주의 경쟁자가 아니라는 것입니다. Open WebUI와 LibreChat은 팀 공용 채팅 UI로 직접 비교하기 쉽습니다. Jan은 개인용 로컬 런타임에 가깝고, Dify는 최종 사용자가 대화하는 화면보다 제작자가 AI 애플리케이션을 설계하는 화면의 비중이 큽니다.
1. Open WebUI — 가장 균형 잡힌 범용 셀프호스팅 UI
Open WebUI의 장점은 시작하기 쉽지만 기능의 상한도 높다는 점입니다. Docker 컨테이너 하나로 실행할 수 있고, Ollama가 포함된 이미지도 제공합니다. Ollama뿐 아니라 OpenAI, Anthropic과 OpenAI 호환 공급자를 한 화면에 연결할 수 있습니다.
채팅 기록과 파일 업로드에서 끝나지 않습니다. 현재 공식 문서 기준으로 다음 기능을 제공합니다.
- 여러 모델의 답을 나란히 비교하는 멀티모델 채팅
- 지식 베이스와 RAG, 전체 문서 컨텍스트 주입
- 웹 검색, 이미지 생성, 음성, 코드 실행
- 사용자·그룹·리소스 단위 접근 제어
- 모델에 시스템 프롬프트, 지식과 도구를 묶는 프리셋
- Python 도구, OpenAPI와 MCP 연동
- OIDC·LDAP 등 조직 인증 연동

그림: 채팅, Notes, Workspace와 Channels를 한 화면에 통합한 Open WebUI · 출처: Open WebUI 공식 저장소
즉, “사내 ChatGPT 화면을 하나 만들고 로컬 모델과 외부 API를 필요에 따라 연결하자”는 요구에 가장 먼저 검토하기 좋습니다. 모델별 접근 권한과 공유 지식 베이스가 필요한 팀에도 자연스럽습니다.
반면 기능이 많아질수록 Open WebUI 자체가 중요한 데이터 플랫폼이 됩니다. 대화 기록, 업로드 문서, 임베딩 데이터, 사용자와 도구 설정을 백업해야 합니다. 여러 인스턴스로 확장할 때는 기본 SQLite와 내장 벡터 저장소만으로 끝나지 않고 PostgreSQL, Redis와 외부 벡터 데이터베이스 같은 구성을 검토하게 됩니다.
라이선스도 반드시 확인해야 합니다. Open WebUI 공식 설명에 따르면 v0.6.5까지의 코드는 BSD 3-Clause이지만, v0.6.6부터는 브랜딩 제한 조항이 추가되었습니다. 공식 문서는 이 최신 라이선스를 OSI 승인 오픈소스 라이선스가 아니라고 명시합니다. 무료로 내부 사용하면서 Open WebUI 브랜드를 유지하는 경우에는 큰 문제가 없을 수 있지만, 로고를 제거한 고객용 서비스나 화이트라벨 제품을 계획한다면 별도 조건을 검토해야 합니다.
추천 대상: 범용성이 높은 사내 AI 포털, Ollama와 클라우드 모델을 함께 쓰는 조직, RAG와 도구를 한 UI에서 점진적으로 확장하려는 팀
2. LibreChat — 여러 모델과 에이전트를 ChatGPT처럼 운영
LibreChat은 이름처럼 ChatGPT와 비슷한 대화 경험을 자체 호스팅하려는 프로젝트에서 출발했지만, 지금은 에이전트와 MCP 기능이 강한 멀티프로바이더 플랫폼입니다.
OpenAI, Azure OpenAI, Anthropic, Google, AWS Bedrock을 비롯해 Ollama·OpenRouter·DeepSeek 등 OpenAI 호환 엔드포인트를 연결할 수 있습니다. 공식 호환성 표는 스트리밍, 비전, OCR, 메모리, MCP와 같은 기능이 엔드포인트 및 모델에 따라 어떻게 달라지는지도 구분합니다.
LibreChat의 강점은 다음과 같습니다.
- 공급자가 다른 모델을 한 UI에서 전환
- 노코드 에이전트 빌더와 에이전트별 파일 검색
- MCP 서버와 OpenAPI 액션 연결
- RAG, 웹 검색, OCR, 메모리
- 코드 인터프리터와 Artifacts
- 사용자·그룹·역할 및 리소스별 ACL
- OAuth2, SAML, LDAP와 2단계 인증 등 조직용 인증

그림: LibreChat Agent Builder에서 MCP 서버 도구를 선택하는 화면 · 출처: LibreChat MCP 공식 문서
특히 “사용자에게는 익숙한 채팅 화면을 제공하되, 뒤에서는 여러 상용 모델과 사내 도구를 조합하고 싶다”는 환경에 잘 맞습니다. 에이전트별로 모델, 지침, 파일과 도구를 묶고 공유 권한을 나눌 수 있다는 점도 유용합니다.
대신 전체 기능을 켜면 구성 요소가 늘어납니다. 공식 Docker Compose 빠른 설치에는 MongoDB, 검색과 RAG 관련 서비스가 함께 포함되며, 코드 실행까지 자체 호스팅하면 격리와 자원 제한을 별도로 설계해야 합니다. 단순 채팅 UI만 기대하고 도입했다가 운영 범위가 커질 수 있습니다.
LibreChat 본체는 MIT 라이선스입니다. 상업적 수정과 재배포 관점에서는 비교 대상 중 이해하기 쉬운 편이지만, 연결하는 코드 인터프리터, 검색 서비스와 모델의 라이선스·이용 약관은 각각 확인해야 합니다.
추천 대상: OpenAI·Anthropic·Google·Bedrock과 로컬 모델을 함께 제공하는 팀, MCP와 사용자별 에이전트를 적극적으로 활용하려는 조직
3. LobeHub — 예쁜 채팅 UI에서 멀티에이전트 운영 공간으로
과거 LobeChat은 세련된 화면과 다양한 모델 공급자, 플러그인 생태계로 알려진 오픈소스 채팅 UI였습니다. 현재 프로젝트 이름은 LobeHub이며, 공식 소개도 단순 채팅보다 여러 에이전트를 만들고 협업시키는 “Chief Agent Operator”에 초점을 맞춥니다.
현재 방향은 다음과 같습니다.
- 여러 모델과 모달리티를 연결하는 통합 인터페이스
- 에이전트 빌더와 Skills·MCP 플러그인
- 에이전트 그룹과 협업
- 프로젝트, 페이지, 일정 실행과 워크스페이스
- 구조화하고 사용자가 편집할 수 있는 개인 메모리
- Docker와 클라우드 플랫폼을 통한 자체 호스팅

그림: 하나의 전략을 여러 하위 에이전트 작업으로 나누어 운영하는 LobeHub · 출처: LobeHub 공식 저장소
UI 완성도와 에이전트 중심 사용 경험을 중요하게 본다면 매력적입니다. 단순히 모델을 선택해 질문하는 화면보다, 역할이 다른 에이전트를 구성하고 프로젝트 단위로 함께 일하는 경험을 원할 때 성격이 잘 맞습니다.
다만 변화 속도가 빠르고 제품의 중심도 기존 LobeChat에서 확장되고 있습니다. 과거 사용 후기나 설치 글만 보고 현재 버전의 기능과 배포 구조를 판단해서는 안 됩니다. 팀 공용 서비스로 사용할 때는 현재 Community Edition의 인증·협업 범위와 Cloud Edition 차이를 배포 시점에 다시 확인하는 편이 안전합니다.
라이선스는 LobeHub Community License입니다. Apache 2.0을 기반으로 하지만, 소스 코드를 수정하지 않은 상업적 사용과 달리 파생 저작물을 개발해 배포하려면 상업 라이선스가 필요하다는 추가 조건이 있습니다. 화이트라벨이나 자체 제품의 기반으로 삼으려면 이 조항이 중요한 판단 기준이 됩니다.
추천 대상: 디자인 완성도를 중시하는 개인과 팀, 단일 챗봇보다 여러 에이전트의 협업·기억·프로젝트 경험을 원하는 사용자
4. AnythingLLM — 문서 기반 RAG를 가장 빠르게 체감
AnythingLLM은 이름 그대로 모델, 임베딩, 벡터 데이터베이스와 문서 처리 구성을 하나의 앱 안에서 연결하려는 프로젝트입니다. 특히 워크스페이스 단위로 문서를 분리하고 질문하는 흐름이 직관적입니다.
데스크톱 앱은 macOS, Windows와 Linux에서 개인이 빠르게 시작하기 좋습니다. Docker 버전은 다중 사용자와 권한, 웹사이트에 넣을 수 있는 채팅 위젯 등 서버용 기능을 제공합니다.
주요 강점은 다음과 같습니다.
- PDF, 문서와 코드 등 다양한 자료 수집
- 워크스페이스별 문서와 대화 분리
- 출처가 포함된 문서 질의
- 여러 로컬·클라우드 LLM과 임베딩 모델 연결
- 내장 벡터 데이터베이스와 외부 벡터 저장소 선택
- AI 에이전트와 시각적 Agent Flow
- 데스크톱과 다중 사용자 Docker 배포 선택
공식 저장소의 데모에서는 워크스페이스에 문서를 넣고 출처 기반 대화를 시작하는 흐름을 확인할 수 있습니다. AnythingLLM 공식 데모 보기
“사내 규정 PDF를 넣고 질문해 보자” 또는 “프로젝트 문서를 부서별로 나눠 검색하자”처럼 RAG의 가치를 빠르게 확인하기 좋습니다. 인프라 구성 요소를 하나씩 조립하기 전에 사용자 요구와 문서 품질을 검증하는 도구로도 유용합니다.
다만 설치가 쉽다고 RAG 정확도가 자동으로 보장되는 것은 아닙니다. 스캔 PDF의 OCR 품질, 표와 이미지 추출, 청킹 크기, 임베딩 모델과 검색 범위를 조정해야 합니다. 문서를 모두 한 워크스페이스에 넣으면 관련 없는 조각이 함께 검색될 수 있으므로 업무 경계에 맞춰 지식 공간을 나누는 설계가 필요합니다.
프로젝트 라이선스는 MIT입니다.
추천 대상: 문서 질의와 지식 베이스가 첫 번째 목표인 개인·소규모 팀, 복잡한 구축 전에 RAG를 빠르게 검증하려는 조직
5. Jan — 내 PC에서 시작하는 로컬 우선 AI
Jan은 웹 서버를 먼저 구축하기보다 개인 PC에 설치하는 로컬 AI 앱에 가깝습니다. macOS, Windows와 Linux용 데스크톱 앱을 제공하고, 계정 없이 로컬 모델을 내려받아 오프라인으로 사용할 수 있습니다.
Jan의 특징은 UI와 로컬 추론 런타임을 함께 제공한다는 점입니다. 내장된 llama.cpp 기반 OpenAI 호환 API 서버를 실행할 수 있어 Jan의 화면에서 모델을 사용하는 데 그치지 않고 다른 로컬 애플리케이션이 같은 모델을 호출하게 만들 수도 있습니다. 필요하면 OpenAI 또는 호환 API 같은 원격 모델도 연결할 수 있습니다.

그림: 모델 크기와 현재 장치에서의 실행 적합성을 보여주는 Jan Hub · 출처: Jan 공식 QuickStart
최근 Jan은 프로젝트, 사용자 지정 Assistant, Agent와 MCP 연결도 제공합니다. 그럼에도 중심 가치는 여전히 “개인 장치에서 모델을 소유하고 실행한다”는 데 있습니다.
팀 공용 포털, 중앙 SSO, 부서별 권한과 대규모 지식 베이스가 목표라면 Jan보다 서버형 플랫폼이 자연스럽습니다. 또한 로컬이라는 말이 무조건 빠르다는 뜻은 아닙니다. 모델 크기, 양자화, RAM·VRAM과 컨텍스트 길이에 따라 응답 속도와 품질이 크게 달라집니다.
Jan은 Apache License 2.0으로 제공되며, 라이선스 파일에는 적절한 사용자용 문서와 자료에서 출처 표시를 요청한다는 문구가 포함되어 있습니다.
추천 대상: 인터넷 없이 개인 문서를 다루려는 사용자, 로컬 모델을 처음 실행하는 개발자, 데스크톱 앱과 로컬 OpenAI 호환 서버를 함께 원하는 환경
6. Dify — 채팅 UI보다 AI 애플리케이션 제작 플랫폼
Dify를 Open WebUI의 대체재라고만 보면 절반만 이해한 것입니다. Open WebUI가 여러 모델을 사용하는 사람의 공용 작업 공간에 가깝다면, Dify는 제작자가 프롬프트, 지식, 도구와 흐름을 조합해 하나의 AI 애플리케이션을 만드는 플랫폼입니다.
Dify는 다음 기능을 하나의 시각적 환경에서 제공합니다.
- 여러 상용·오픈소스 모델 공급자 연결
- 프롬프트 작성과 모델 응답 비교
- 문서 수집부터 검색까지 이어지는 RAG 파이프라인
- 조건, 반복, 도구와 모델 노드를 연결하는 워크플로
- 에이전트와 플러그인
- 실행 로그와 관측
- 완성한 앱을 웹 앱, API 또는 임베드 형태로 제공

그림: 로컬 모델부터 주요 클라우드 API까지 연결하는 Dify의 모델 공급자 생태계 · 출처: Dify 공식 저장소
예를 들어 전 직원에게 아무 모델이나 선택하는 채팅 화면을 주려면 Open WebUI나 LibreChat이 더 단순합니다. 반면 “보안 정책 문서를 검색한 뒤 위험도를 분류하고, 승인 조건에 따라 티켓을 생성하는 앱”을 만들려면 Dify의 워크플로가 더 잘 맞습니다.
그만큼 운영 구성도 무겁습니다. 자체 호스팅은 여러 컨테이너와 데이터 저장소를 포함하며, 개발·운영 환경 분리, 비밀 관리, 플러그인 권한과 워크플로 버전 관리가 필요합니다.
Dify의 라이선스는 Apache 2.0을 수정한 형태입니다. 상업적 백엔드와 기업용 앱 개발에는 사용할 수 있지만, 별도 서면 허가 없이 Dify 소스 코드로 멀티테넌트 환경을 운영하는 것과 프런트엔드의 로고·저작권 정보를 제거하는 것에는 제한이 있습니다. 고객별 SaaS 플랫폼을 만들 계획이라면 아키텍처를 정하기 전에 라이선스를 검토해야 합니다.
추천 대상: 반복 가능한 AI 업무 앱, RAG 파이프라인과 에이전트 워크플로를 시각적으로 만들고 API로 제공하려는 팀
목적별로 고르면 선택이 단순해진다
개인 PC에서 로컬 모델을 가장 쉽게 써보고 싶다
Jan이 자연스럽습니다. 모델 다운로드, 데스크톱 대화와 로컬 API 서버가 한 앱에 모여 있습니다. 문서 RAG가 가장 중요한 개인 사용자라면 AnythingLLM Desktop도 함께 비교할 만합니다.
Ollama를 사내 공용 ChatGPT처럼 제공하고 싶다
우선 Open WebUI를 검토할 수 있습니다. 설치가 간단하고 모델·지식·도구·사용자 관리를 점진적으로 확장하기 좋습니다. 여러 상용 공급자와 사용자별 에이전트, MCP가 핵심이라면 LibreChat이 더 잘 맞을 수 있습니다.
PDF와 사내 문서를 넣고 빠르게 RAG를 검증하고 싶다
AnythingLLM이 직관적입니다. 다만 실제 운영 전에는 검색 정확도 평가, 문서 갱신, 권한별 지식 분리와 삭제 절차를 추가로 설계해야 합니다.
완성도 높은 에이전트 작업 공간이 중요하다
LobeHub를 살펴볼 수 있습니다. 현재는 구 LobeChat의 이미지보다 멀티에이전트 협업과 지속적인 작업 공간이라는 방향을 기준으로 평가해야 합니다.
업무용 AI 앱과 자동화 흐름을 만들고 싶다
Dify가 적합합니다. 일반 채팅 포털을 고르는 문제가 아니라 AI 애플리케이션 개발·배포 플랫폼을 고르는 문제에 가깝습니다.
라이선스가 단순해야 한다
LibreChat과 AnythingLLM의 MIT, Jan의 Apache 2.0이 상대적으로 이해하기 쉽습니다. Open WebUI 최신 버전, LobeHub와 Dify는 추가 조건이 있으므로 상업적 재배포, 브랜드 제거와 멀티테넌시 요구를 먼저 확인해야 합니다.
자체 호스팅이라고 자동으로 안전해지는 것은 아니다
AI UI는 일반 웹 게시판보다 민감한 데이터를 많이 모읍니다. 사용자의 질문, 업로드 문서, 모델 API 키, 검색 기록, 시스템 프롬프트와 도구 실행 결과가 한곳에 저장될 수 있습니다.
운영 전에는 최소한 다음 항목을 확인해야 합니다.
| 영역 | 확인할 내용 |
| 인증 | 익명 가입 차단, SSO·MFA 적용, 퇴사자 계정 회수 |
| 권한 | 사용자·부서별 모델, 지식 베이스와 에이전트 접근 분리 |
| 외부 전송 | 모델, 임베딩, OCR, 검색과 관측 서비스별 전송 데이터 확인 |
| API 키 | 브라우저 노출 방지, 서버 측 비밀 저장, 주기적 교체 |
| RAG | 원문 ACL 상속, 삭제와 재색인, 검색 결과의 권한 검증 |
| 도구 | MCP·코드 실행·웹 요청의 허용 범위와 승인 정책 |
| 네트워크 | TLS, 리버스 프록시, 외부 공개 최소화, 송신 제어 |
| 데이터 | 대화·파일·DB·벡터 데이터 백업과 보존 기간 |
| 업데이트 | 버전 고정, 변경 내역과 마이그레이션 확인, 롤백 준비 |
| 라이선스 | 현재 배포 버전의 LICENSE와 연결 구성 요소 조건 검토 |
특히 MCP나 코드 실행 기능은 “AI가 답변한다”에서 “AI가 행동한다”로 경계를 바꿉니다. 파일 시스템, 데이터베이스, 브라우저와 사내 API에 연결할수록 최소 권한, 사용자별 인증 전달, 실행 로그와 고위험 작업 승인 절차가 필요합니다.
현실적인 도입 순서
처음부터 모든 기능을 켜는 것보다 다음 순서가 안전합니다.
- 대표 업무 두세 개와 필요한 모델을 정합니다.
- 소수 사용자에게 기본 채팅과 파일 첨부만 제공합니다.
- 클라우드 모델로 전송되는 데이터 범위를 확인합니다.
- RAG 답변은 정답률뿐 아니라 출처 적합성과 권한 누출을 평가합니다.
- SSO와 그룹별 모델·지식 권한을 연결합니다.
- 웹 검색, MCP와 코드 실행은 필요한 기능부터 제한적으로 추가합니다.
- 대화·문서·벡터 DB 백업과 업그레이드 절차를 검증합니다.
- API 비용, 로컬 GPU 사용률과 사용자별 사용량을 관찰합니다.
이 과정을 거치면 UI의 기능 목록보다 실제 조직에 맞는 운영 모델이 먼저 보입니다.
결론: 가장 좋은 UI보다 운영 목적에 맞는 UI를 고르자
Open WebUI는 설치 난도와 기능의 균형이 좋아 범용 사내 AI UI의 출발점으로 추천하기 쉽습니다. 그러나 여러 공급자와 에이전트·MCP가 핵심이면 LibreChat, 문서 RAG를 빠르게 시작하려면 AnythingLLM, 개인 장치의 로컬 실행은 Jan이 더 단순할 수 있습니다. LobeHub는 에이전트 협업 경험, Dify는 AI 앱과 워크플로 제작이라는 다른 문제를 해결합니다.
결국 선택 기준은 기능의 개수가 아닙니다.
누가 사용할지, 데이터가 어디에 저장되고 전송될지, 모델과 지식을 어떻게 나눌지, AI에게 어디까지 행동 권한을 줄지를 먼저 정해야 한다.
AI UI는 단순한 채팅 화면이 아니라 모델, 사내 데이터와 도구를 연결하는 관문입니다. 이 관문을 어떤 프로젝트로 만들 것인지에 따라 사용성뿐 아니라 보안, 비용, 운영 복잡도와 제품의 확장 방향까지 달라집니다.
참고한 공식 자료
'일반IT > AI' 카테고리의 다른 글
| Claude Opus 5 발표 정리 — Fable 5에 가까워진 실무형 에이전트 모델 (0) | 2026.07.25 |
|---|---|
| AI로 페이스북 마케팅을 한다는 것 — 클씨랩 프로젝트에서 만든 작은 팀의 광고 시스템 (1) | 2026.07.24 |
| LLM은 어떻게 배우고 답하는가 — 대규모 언어 모델의 학습과 추론 과정 (0) | 2026.07.22 |
| 생성형 AI는 갑자기 나타난 기술이 아니다 — AI 역사와 분류로 이해하는 기존 머신러닝과의 차이 (1) | 2026.07.22 |
| Claude Fable급 모델을 Qwen으로 직접 운영하면 AWS 비용은 얼마일까? (1) | 2026.07.22 |