사내 AI 채팅 화면, 직접 만들까 오픈소스를 쓸까
Vercel AI SDK와 assistant-ui 문서는 대화 저장 방식을 개발자가 정하는 구조로 설명합니다. 오픈소스 앱 3종(Open WebUI·LibreChat·Dify)은 완성된 앱이지만 로그인 방식, 역할 범위, 라이선스 조건이 서로 다릅니다.
이 글의 차례 4
사내 서비스의 채팅 화면은 직접 개발하거나 오픈소스 앱을 도입할 수 있습니다. 직접 개발할 때 쓰는 개발 도구는 Vercel AI , assistant-ui, CopilotKit 3종이고, 오픈소스 앱은 Open WebUI, LibreChat, Dify 3종입니다. 각각 어떤 기능을 만들어 주고 어떤 기능을 개발팀이 직접 만들어야 하는지 공식 문서와 저장소를 읽고 정리했습니다.
요지는 세 가지입니다. Vercel AI SDK와 assistant-ui 문서는 대화 저장 방식을 개발자가 정하는 구조로 설명하고, assistant-ui는 로그인 여부를 확인하는 코드 예제도 보여 줍니다. 오픈소스 앱 3종은 로그인과 대화 저장 기능을 이미 갖췄지만 로그인 방식, 역할 범위, 라이선스 조건이 다릅니다. 앱에 직접 접근하는 사용자가 50명을 넘는 회사는 Open WebUI의 이름과 로고를 바꿀 수 없고, 저작권자의 서면 허가나 기업 라이선스가 있으면 바꿀 수 있습니다.
Vercel AI SDK·
Vercel AI ()는 useChat 함수로 답변이 나오는 대로 보여 주는 스트리밍과 메시지 목록 관리를 처리합니다. assistant-ui(MIT)는 대화 목록과 입력창 같은 화면 부품을 제공하고, CopilotKit(MIT)은 이미 만든 앞에 채팅 화면과 사용자 승인 화면을 붙입니다. 직접 만들지 완성된 제품을 쓸지 정하는 일은 에이전트에서도 같고, 에이전트 프레임워크 비교에서 다뤘습니다.
AI SDK 대화 저장 가이드에는 권한 부여와 오류 처리를 다루지 않는다는 안내 문구가 있습니다. 가이드는 예제에서 파일에 저장하고, 실제 서비스에서는 데이터베이스나 클라우드 저장소를 쓰게 된다고 설명합니다.
assistant-ui 문서는 대화를 저장하고 불러오는 코드(어댑터)를 개발자가 두 개 만들고, Postgres 데이터베이스의 테이블과 서버 쪽 주소( 라우트)도 만드는 예제를 보여 줍니다. 같은 회사의 호스팅 서비스 Assistant Cloud가 저장과 감사 로그 기능을 제공하므로, 저장은 직접 구현하거나 이 서비스를 쓰는 두 방식이 있습니다. Assistant Cloud를 자체 인프라에 설치하려면 Enterprise 계약이 필요합니다.
Python으로 채팅 화면을 만드는 도구 Chainlit은 코드 저장소가 2026년 10월 15일 수정할 수 없는 읽기 전용으로 바뀌어 직접 개발 후보에서 뺐습니다.
오픈소스 앱 3종에 이미 들어 있는 기능과 제품별 차이
표의 용어를 먼저 풀면, LDAP은 사내 계정 디렉터리로 로그인하는 방식이고 OIDC와 SAML은 한 번 로그인으로 여러 서비스를 쓰는 로그인 통합(SSO) 표준입니다. (검색 증강 생성)는 사내 문서를 찾아 답에 반영하는 기능이고, 그 문서를 찾는 데 쓰는 저장소가 벡터 DB입니다. (Model Context Protocol)는 AI가 외부 도구에 연결하는 규약이며, MCP 서버의 보안 결함은 MCP SSRF 결함 기사에서 다뤘습니다. compose는 여러 컨테이너를 한 파일로 정의해 함께 띄우는 설정이고, 워크스페이스는 사용자와 앱을 묶는 작업 공간입니다.
항목 | Open WebUI | LibreChat | Dify |
|---|---|---|---|
로그인 연동 | LDAP, OAuth, OIDC(OIDC 로그인 제공자는 한 번에 1곳만 연결) | LDAP/AD, OAuth2, OIDC, SAML(한 곳에서 로그아웃하면 연결된 서비스에서도 로그아웃되는 기능은 미지원) | 이메일+비밀번호, 이메일 코드, ·. LDAP·SAML·OIDC는 문서에서 못 찾음 |
권한 | Admin/User/Pending 역할, 권한을 켜고 끄는 설정, 그룹 안의 그룹, 항목마다 접근을 허용할 사용자와 그룹을 적는 목록 | USER/ADMIN/사용자 정의 역할, 그룹, 기능별 허용 설정 17가지 | 기본 역할 4개(사용자 정의 역할은 Enterprise) |
대화 기록 | 사이드바에 자동 저장(내부 DB webui.db) | 저장된 대화를 검색(Meilisearch 기반) | 앱의 로그 화면에서 확인, 기본 설정은 보관 기간 제한 없음 |
파일 업로드 | 권한을 켜고 끄는 설정, 내장 RAG | 끌어놓기·붙여넣기, RAG | 파일 종류·개수 설정, 크기 제한은 환경변수로 설정 |
관리자 화면 | Admin Panel | Admin Panel(별도 웹앱) | 워크스페이스 설정·멤버·모델 제공자 |
모델 연결 | 연결 화면에서 호환 URL· | 설정 파일 librechat.yaml에 주소(baseURL) 입력 | 모델 제공자를 추가하는 플러그인(OpenAI-API-compatible·Ollama) |
감사 로그 | 요청 감사 로그, 기본 꺼짐 | 권한을 부여하거나 바꾼 기록 | 문서에서 못 찾음(대화 로그는 있음) |
사내 문서 RAG | 내장, 외부 벡터 DB 연결 | 내장(pgvector), MCP | 내장, External Knowledge API |
설치 때 띄우는 서비스 수 | 설치 문서 기준 컨테이너 1개 | compose 서비스 6개 | 기본으로 켜지는 compose 서비스 16개(한 번 실행되고 끝나는 서비스 1개 포함) |
표의 마지막 줄 숫자는 출처가 다릅니다. Open WebUI는 문서에 적힌 값이고, LibreChat과 Dify는 compose 파일에 적힌 서비스를 세어 본 값이라 실제로 띄운 결과는 아닙니다. SSO와 사용자 정의 역할, 여러 워크스페이스는 Dify Enterprise 판 기능입니다. 오픈소스판 Dify는 설치 때 워크스페이스가 하나만 만들어집니다.
부서별 문서 분리는 제품마다 방법이 다릅니다. Open WebUI 문서는 지식베이스를 만들고 그룹별로 접근을 허용하는 방법을 설명합니다. LibreChat 문서에는 에 올린 파일을 그 에이전트와 대화하는 모두가 검색할 수 있다는 설명과, 에이전트를 그룹에 Viewer(보기 권한)로 공유할 수 있다는 설명이 있습니다. 두 설명을 합치면 부서별로 문서를 나눌 수 있습니다.
접근 제어와 관련된 GitHub 보안 공지는 세 제품 모두에 있습니다. Open WebUI의 8월 31일 공지는 사용자가 접근할 수 없는 지식베이스가 내장 지식 도구를 통해 노출되는 문제를 다뤘습니다. 이 문제는 대부분의 벡터 DB 종류에서 나타났고 0.11.1에서 수정됐습니다. Dify는 7월 15일에 다른 테넌트의 파일 미리보기를 볼 수 있는 문제를 공지했고, LibreChat은 공유 MCP 서버와 공유 에이전트에 관한 공지를 냈습니다.
사내 문서 시스템을 연결하는 방법도 다릅니다. Open WebUI의 확장 기능 저장소 Pipelines는 읽기 전용으로 보관된 상태이고, README가 쓰지 말라고 적고 있습니다. Open WebUI의 지금 공식 연결 방법은 Qdrant 같은 외부 벡터 DB 연결, Functions·Tools, MCP 등입니다. Dify는 External Knowledge API, LibreChat은 MCP 서버가 대표 연결 방법입니다.
세 오픈소스의 라이선스와 이름·로고를 바꿀 수 있는 조건
사용자가 100명쯤인 회사에는 어떤 라이선스 조건이 걸릴까요? Open WebUI는 앱에 직접 접근하는 사용자가 50명을 넘으면 이름과 로고를 바꿀 수 없습니다. Dify는 프런트엔드를 쓸 때 로고를 수정할 수 없고 다중 테넌트 서비스에도 제한이 있습니다. LibreChat은 제한 조항이 없습니다. 다중 테넌트(multi-tenant)는 한 설치에서 여러 조직을 분리해 운영하는 방식입니다. 표는 라이선스 원문 기준이며 법률 해석은 아닙니다.
제품 | 라이선스 | 이름과 로고를 바꿀 수 있는지 | 그 밖의 조건 |
|---|---|---|---|
Open WebUI | Open WebUI 자체 라이선스(BSD-3 라이선스에 이름·로고 조항을 더함) | 어느 30일 동안이든 사용자가 50명을 넘으면 바꾸거나 지울 수 없음 | 저작권자의 서면 허가를 받거나 기업 라이선스를 쓰면 이름과 로고를 바꿀 수 있음 |
LibreChat | MIT | 제한 조항 없음 | 제한 조항 없음 |
Dify | 에 추가 조건을 더함 | 프런트엔드를 쓰면 로고와 저작권 표시를 수정할 수 없음 | 다중 테넌트 서비스는 서면 허가 필요 |
Open WebUI 문서는 이름과 로고를 그대로 두고 회사 안에서 쓰면 무료라고 설명합니다. 사용자가 50명을 넘는 회사가 이름과 로고를 자사 것으로 바꿔 내놓는 화이트라벨링에는 기업 라이선스나 저작권자의 서면 허가가 필요합니다.
Dify의 로고 조항은 프런트엔드를 쓸 때 적용됩니다. 프런트엔드는 저장소의 web 디렉터리 또는 web 이미지를 뜻하며, 이를 쓰지 않는 용도에는 로고 조항이 적용되지 않는다고 라이선스에 적혀 있습니다. 다중 테넌트 조항은 이 예외에 들지 않습니다. 라이선스는 한 테넌트를 한 워크스페이스로 정의하고, Dify는 설치 때 워크스페이스를 하나 만듭니다. 부서별 사용이 다중 테넌트에 해당하는지는 적혀 있지 않습니다.
도입 사례와 직접 개발 사례, 후보를 고르기 전 확인 항목
Metabase는 오픈소스 앱을 도입했습니다. 2026년 7월 20일 Metabase 엔지니어링 블로그에 따르면 AI 서비스마다 따로 있던 로그인을 하나로 모으려고 LibreChat, LobeChat, Open WebUI를 비교해 LibreChat을 골랐습니다. 쿠버네티스용 설치 도구 Helm으로 배포한 이 회사에서는 파일 업로드가 처음에 동작하지 않아 를 따로 구성해야 했고, 팀 전체가 쓰는 지식 검색 기능은 직접 만들어 서버로 붙였습니다.
Retool은 직접 개발을 택했습니다. 2025년 8월 5일 Retool 블로그에 따르면 Confluence 문서와 Linear 티켓을 연결한 사내 도우미를 만들며 상용 SaaS 여러 개를 검토했습니다. 채팅 화면은 코드를 처음부터 쓰지 않고 자사 로우코드 제품의 컴포넌트를 조립했습니다. 직접 개발이 곧 화면 코드를 처음부터 쓰는 일은 아니라는 사례이며, Vercel AI ·assistant-ui·CopilotKit을 쓴 것은 아닙니다.
두 글은 각각 한 회사가 자기 블로그에 쓴 경험이고, 만드는 데 걸린 기간과 인력, 비용은 적지 않았습니다. 메모리 값이 올라 AI 시험 장비 가격이 달라진 사정은 중소기업 AI 구축 기사에서 다뤘습니다. 후보를 고르기 전 확인 항목은 아래 네 가지입니다.
- 로그인 방식(LDAP, SAML, OIDC)이 우리 계정 체계와 맞는지, 직접 개발이라면 로그인 코드를 누가 쓰는지
- 부서별 문서 분리를 그 도구의 권한 모델로 표현할 수 있는지, 감사 로그가 기본으로 켜져 있는지
- Open WebUI의 사용자 50명 기준이 우리 사용자 수에 해당하는지
- Dify의 로고 수정 금지와 다중 테넌트 조항이 우리 화면 수정 계획과 부서별 사용에 해당하는지
참고한 자료 12
- Vercel — AI SDK 저장소(LICENSE·README)와 대화 저장 문서
- assistant-ui — 저장소 README와 자체 DB 저장·Auth.js 연동 문서
- assistant-ui — Assistant Cloud 요금·감사 로그 문서
- CopilotKit — 저장소 README
- Chainlit — 저장소(보관 표시)
- Open WebUI — LICENSE와 라이선스·RBAC·RAG 문서
- Open WebUI — Pipelines 저장소와 보안 공지 목록
- LibreChat — LICENSE와 접근 제어·RAG·설정 문서, 릴리스
- Dify — LICENSE와 워크스페이스·역할 문서
- Dify — 웹앱 설정과 Dify Premium 문서
- Metabase — How we picked LibreChat — and ended up with a Slack agent (2026년 7월 20일)
- Retool — What is RetoolGPT? How we built an internal AI assistant (2025년 8월 5일)
