셀프호스팅 AI 챗 5곳, 순수 MIT는 둘뿐입니다

글쓴이김성진·발행일2026년 10월 5일

ChatGPT 같은 대화 화면을 내 서버에 직접 두고 싶어진 적이 있으신가요. API 키 하나로 여러 AI 모델을 한 화면에서 번갈아 쓰고, 내 문서를 읽혀 보고, 회사 동료와 계정을 나눠 쓰는 화면입니다. 이런 화면을 셀프호스팅 AI 챗이라고 부르고, 대표적인 오픈소스가 다섯 개쯤 됩니다. 그런데 이름 앞에 모두 “오픈소스”가 붙어 있어도 라이선스 문서를 열어 보면 서로 다른 약속이 적혀 있습니다.

이 글은 이런 분을 위해 썼습니다. 내 컴퓨터나 서버에 AI 챗 화면을 처음 올려 보려는 분, 팀이나 회사에서 쓰려는데 나중에 라이선스 문제가 생길까 걱정되는 분, 그리고 “셀프호스팅”이라는 말은 들었지만 뭐가 얼마나 필요한지 모르는 분입니다. 용어는 처음 나올 때 풀어서 씁니다.

비교 대상은 다섯 곳입니다. 모두 2026년 10월 5일 기준으로 각 프로젝트의 깃허브 저장소에서 LICENSE 파일, README, 설치용 docker-compose 파일을 직접 열어 확인했습니다.

• 오픈웹UI(Open WebUI) — 별이 가장 많은 곳. README가 올라마(Ollama) 같은 로컬 모델을 함께 돌리는 이미지까지 따로 안내한다.
• 리브챗(LibreChat) — ChatGPT 화면을 닮은 곳. 에이전트와 코드 실행 기능이 두껍다.
• 로브허브(LobeHub) — 예전 이름은 로브챗(LobeChat). 지금은 에이전트 팀 운영을 앞세운다.
• 애니띵LLM(AnythingLLM) — “내 문서와 대화”를 앞세운 곳. 데스크톱 앱도 있다.
• 오닉스(Onyx) — 회사 앱 50여 곳의 지식을 색인해 두고 묻는 쪽에 강한 곳.

로컬 모델을 돌리는 도구가 궁금하시면 로컬 LLM 실행 도구 비교 글을, 만든 서비스를 어디에 올릴지가 궁금하시면 AI 앱 호스팅 비교 글을 같이 보세요. 이 글은 그 사이, **“모델 앞에 놓을 대화 화면을 무엇으로 할까”**를 다룹니다. 직접 설치해 본 글이 아니라 공개 문서를 읽어 정리한 글이라는 점은 끝에서 한 번 더 밝힙니다.

한눈에: 라이선스와 설치 규모

숫자는 2026년 10월 5일 깃허브 화면과 API로 읽은 값입니다. 별 수는 매일 바뀌고, 최신 버전은 이 글이 올라간 뒤에도 계속 올라갑니다. 리브챗의 v0.8.8은 깃허브 릴리스 목록에서 프리릴리스(시험판) 표시가 붙어 있습니다. 나머지는 일반 릴리스입니다.

“오픈소스”와 “MIT”는 같은 말이 아닙니다

먼저 용어 하나만 풀겠습니다. 라이선스는 “이 프로그램을 어떻게 써도 되는지 적어 둔 약속 문서”입니다. 깃허브 저장소 첫 화면에 LICENSE 파일로 들어 있습니다.

MIT 라이선스는 가장 느슨한 편입니다. 쓰고, 고치고, 팔고, 나눠 줘도 되는데, 원래 저작권 문구만 남기라는 조건이 사실상 전부입니다. 반면 “소스 코드가 공개돼 있다”는 사실만으로는 어디까지 허용되는지 알 수 없습니다. 코드는 공개돼 있어도 “이름을 바꾸지 마라”, “고쳐서 나눠 주려면 계약해라” 같은 조건이 붙을 수 있기 때문입니다.

개인이 혼자 쓰는 데는 다섯 곳 모두 문제가 없어 보입니다. 갈리는 지점은 회사나 팀에서 쓸 때, 우리 이름과 로고를 붙여 쓸 때, 고쳐서 다른 곳에 나눠 줄 때입니다. 이 글의 라이선스 부분은 원문을 읽고 요약한 것이지 법률 자문이 아닙니다. 실제로 사업에 쓰기 전에는 LICENSE 원문을 직접 읽으세요.

오픈웹UI — MIT였다가 두 번 바뀐 약속

오픈웹UI 저장소에는 LICENSE_HISTORY라는 파일이 있습니다. 라이선스가 어떻게 바뀌어 왔는지 적어 둔 파일입니다. 여기에 이렇게 나옵니다.

• 2025년 1월 10일 이전에 만든 코드: MIT 라이선스
• 그 뒤 2025년 4월 18일 이전까지: 세 가지 조건을 붙인 BSD 3조항 계열 라이선스
• 2025년 4월 18일 이후: 지금의 “Open WebUI License”

저장소 커밋 기록으로 확인한 날짜입니다. 4월 18일 커밋의 제목이 “라이선스에 브랜딩 조항 추가”입니다. 그 조항(현재 LICENSE의 4번)을 풀면 이렇습니다.

이용자는 어떤 배포 환경에서든 “Open WebUI”라는 이름, 로고, 그 밖에 소프트웨어를 구별해 주는 시각·문구 표시를 바꾸거나 지우거나 가리거나 대체할 수 없다. 다만 다음 중 하나는 예외다. (1) 직접 접속하는 최종 이용자가 30일 동안 50명을 넘지 않는 배포, (2) 저작권자의 사전 서면 허락, (3) 이름 변경을 명시적으로 허용하는 기업용 라이선스 계약.

번역은 제가 풀어 쓴 것이고, 원문은 영어입니다. 핵심은 세 가지입니다.

1. 이름을 그대로 두고 쓰는 건 자유입니다. 이 조항은 이름·로고를 바꾸는 행위를 막는 조항입니다.
2. 사내 도구로 쓰든 외부에 서비스로 내놓든, 이름과 로고를 바꾸려는데 사용자가 50명을 넘을 수 있다면 허락이나 계약이 필요합니다.
3. 저장소에 기여하려면 별도의 기여자 라이선스 동의서(CLA)에 동의해야 한다고 LICENSE가 적고 있습니다.

그래서 깃허브가 이 저장소의 라이선스를 “NOASSERTION(판정 불가)“로 표시합니다. 표준 라이선스 목록에 없는 문서라는 뜻입니다. README에는 “엔터프라이즈 플랜이 필요하면 영업팀과 이야기하라”는 안내가 맨 위에 있습니다.

기능은 이 다섯 곳 중 가장 많이 열어 둔 편입니다. README가 직접 적은 항목만 추리면 다음과 같습니다.

• 올라마와 OpenAI 호환 API(LM 스튜디오, 그록클라우드, 미스트랄, 오픈라우터, vLLM 등)를 한 화면에서 섞어 쓰기
• 역할과 그룹으로 나누는 세밀한 권한 관리(RBAC)
• 필터·액션·파이프·도구·스킬 같은 플러그인, MCP·MCPO·OpenAPI 도구 서버 연결
• 문서 검색(RAG)에 쓸 수 있는 벡터 데이터베이스 9종(크로마DB, PGVector, 쿼드런트, 밀버스, 일래스틱서치, 오픈서치, 파인콘, S3벡터, 오라클 23ai)
• LDAP/액티브 디렉터리, OAuth, 신뢰 헤더 SSO, SCIM 2.0 계정 자동 연동
• 관리자 화면의 사용량·토큰·비용 집계, 모델 두 개를 붙여 비교하는 아레나
• 데이터베이스는 SQLite 또는 PostgreSQL, 파일 저장은 로컬이나 S3·구글 클라우드·애저

여러 대에 나눠 올리는 구성도 열어 둡니다. 레디스(Redis)로 세션을 공유하는 방식입니다. 반대로 한 대에서 가볍게 시작하는 방법도 있습니다. README가 소개하는 가장 짧은 방법은 도커 한 줄(포트 3000, 데이터 볼륨 지정)이거나 pip install open-webui입니다. 파이썬은 3.11을 쓰라고 안내합니다.

로브허브 — 쓰는 건 자유, 고쳐서 나눠 주려면 계약

로브허브의 LICENSE 첫 줄은 “LobeHub Community License”이고, 저작권 표기가 “2024/06/17 - 현재”로 시작합니다. 설명에는 1.0부터 로브챗이 이 라이선스로 나간다고 적혀 있습니다. 바탕은 아파치 2.0이고, 두 가지 조건이 더 붙습니다.

상업적 이용

• 소스를 고치지 않는다면 프런트엔드·백엔드 서비스로 상업적으로 써도 된다.
• 로브챗을 바탕으로 파생 저작물을 만들어 배포하려면 제작사의 상용 라이선스를 받아야 한다.

기여자 조건

• 제작사는 오픈소스 계약을 필요에 따라 더 엄격하게 또는 더 느슨하게 조정할 수 있다.
• 기여한 코드는 제작사의 클라우드 판을 포함해 상업적으로 쓰일 수 있다.

쉽게 말해 “그대로 올려서 쓰는 것”은 열려 있고, “고쳐서 만든 변형본을 나눠 주는 것”은 계약 대상입니다. 사내에서만 돌리면서 설정만 하는 팀에는 큰 문제가 아닐 수 있습니다. 하지만 코드를 고쳐 제품에 넣어 팔 계획이라면 먼저 제작사에 문의해야 합니다. 기여자 조건의 “조정할 수 있다”는 문구는 앞으로 조건이 바뀔 수 있다는 뜻이기도 합니다.

기능 소개는 “에이전트를 일의 단위로 삼는다”는 쪽으로 쓰여 있습니다. README가 적은 항목은 에이전트 빌더, 여러 에이전트를 묶는 에이전트 그룹, MCP 호환 플러그인을 포함한 1만 개 이상의 스킬, 메신저(IM) 게이트웨이, 여러 에이전트와 함께 글을 쓰는 Pages 같은 것들입니다. 설치는 폴더를 만들고 안내 스크립트를 한 번 실행한 뒤 docker compose up -d를 입력하는 순서입니다. 버셀·지버(Zeabur)·씰로스(Sealos)·알리바바 클라우드 같은 서비스에서 버튼으로 올리는 방법도 안내합니다.

오닉스 — 폴더 이름 하나로 갈리는 라이선스

오닉스의 LICENSE는 첫머리에서 “일부는 이렇게 라이선스한다”고 선언합니다.

• 저장소 안의 ee라는 이름의 폴더(backend/ee, web/src/app/ee, web/src/ee) 안의 내용은 오닉스 엔터프라이즈 라이선스를 따른다.
• 나머지는 MIT 라이선스(“MIT Expat”)다.
• 외부 부품은 각자의 원래 라이선스를 따른다.

README는 이 구분을 “에디션” 두 개로 설명합니다. **커뮤니티 에디션(CE)**은 MIT이고 RAG·AI 채팅·에이전트·액션이라는 핵심 기능을 다 갖추고 있다고 하고, **엔터프라이즈 에디션(EE)**은 큰 조직에 쓸모 있는 기능을 더 얹은 판이라고 합니다. README가 “엔터프라이즈용”이라고 묶어 둔 목록은 공유 기능, SAML·OIDC·구글 OAuth 단일 로그인(SSO)과 SCIM 연동, 세밀한 권한 관리(RBAC), 팀별 분석, 질의 기록 감사, 개인정보 제거 같은 사용자 정의 코드, 화이트라벨링(이름·아이콘 바꾸기)입니다.

여기서 읽을 점은 “MIT”라고 소개된 프로젝트도 저장소 안에 별도 폴더가 숨어 있을 수 있다는 것입니다. 오닉스는 그 사실을 LICENSE 맨 위에 숨기지 않고 적었습니다. 직접 쓸 기능이 EE 쪽 폴더에 있는지는 오닉스 가격 페이지의 기능표를 열어 확인해야 합니다. 이 글에서는 그 표를 확인하지 못했습니다.

리브챗과 애니띵LLM — 둘 다 MIT인데, 구성은 정반대입니다

리브챗의 LICENSE는 “MIT License, Copyright (c) 2026 LibreChat”입니다. 애니띵LLM의 LICENSE는 “The MIT License, Copyright (c) Mintplex Labs Inc.”입니다. 둘 다 순수 MIT로 읽힙니다. 이 다섯 곳 중에서 이름·로고 조항도, 파생 배포 조건도 없는 곳은 이 둘입니다.

그런데 설치 모양은 정반대입니다.

리브챗은 기본 docker-compose.yml이 서비스 여섯 개를 한꺼번에 올립니다.

파일에 적힌 이미지 버전은 몽고DB 8.0.20, 멜리서치(Meilisearch) v1.35.1, pgvector 0.8.0(포스트그레스 15)입니다. 이 숫자들은 파일이 바뀌면 따라 바뀝니다.

애니띵LLM은 도커 이미지 하나를 받아 컨테이너 하나로 돕니다. 도커 문서의 최소 사양은 **메모리 2GB 이상, 저장 공간 10GB 이상(권장)**입니다. 기본 벡터 데이터베이스는 안에 내장된 랜스DB(LanceDB)이고, 텍스트 임베딩도 기본값으로는 그 컨테이너 안에서 처리합니다. 별도 데이터베이스 서버를 따로 띄우지 않아도 되는 구성입니다.

대신 README가 두 가지를 분명히 적습니다. 여러 사용자 계정과 권한 관리, 그리고 내 웹사이트에 붙이는 임베드 채팅 위젯은 “도커 버전에서만” 된다는 것입니다. 데스크톱 앱(맥·윈도우·리눅스)으로 받으면 이 기능이 빠집니다. 안드로이드 모바일 앱도 오픈소스로 공개돼 있습니다.

설치 규모를 서비스 수로 세어 보면

내 서버에 올린 뒤 켜 두어야 할 프로세스가 몇 개인지는 유지 보수 부담과 직결됩니다. 각자 문서가 말하는 기본 구성을 나란히 놓으면 이렇습니다.

로브허브의 compose 파일에는 서비스가 열 개 들어 있습니다. 기본으로 켜지는 것은 lobe(본체), gateway(게이트웨이), postgresql(데이터베이스), redis, rustfs(S3 호환 파일 저장소), rustfs-init(저장소 초기화), searxng(검색 엔진) 일곱 개입니다. 나머지 세 개(elasticsearch, fts-search-reindex, fts-search-sync)는 선택 프로파일을 켰을 때만 뜹니다.

오닉스는 README가 두 가지 배포 모드를 설명합니다. 라이트 모드는 “가벼운 AI 채팅 화면”으로, 메모리가 1GB 미만이면 되지만 문서 색인은 못 합니다. 표준 모드는 벡터·키워드 색인, 커넥터 동기화용 백그라운드 작업 컨테이너, 모델 추론 서버, 레디스, MinIO까지 포함합니다. 설치는 안내 스크립트 한 줄(curl -fsSL https://onyx.app/install_onyx.sh | bash)이 대표 방법입니다. 이런 명령은 실행 전에 스크립트 내용을 먼저 읽어 보는 습관을 권합니다.

이 표에서 가장 큰 차이는 “혼자 가볍게” 시작할 수 있는 곳이 어디냐입니다. 오픈웹UI와 애니띵LLM은 한 줄이나 한 컨테이너로 시작하고, 리브챗과 로브허브는 처음부터 여러 서비스를 함께 올리는 걸 전제합니다. 서비스가 많다는 건 나쁜 게 아니라 그만큼 역할을 나눠 둔 구조이고, 대신 업데이트할 때 챙길 것이 많아집니다.

여럿이 함께 쓸 때: 로그인과 권한

혼자 쓰면 로그인 방식이 의미가 없습니다. 팀으로 가면 이야기가 달라집니다. 문서에 적힌 로그인·권한 기능만 모아 보겠습니다.

이 표를 읽을 때 두 가지를 주의하세요. 첫째, 같은 단어라도 깊이가 다를 수 있습니다. 이 글은 각 문서가 적은 이름을 옮긴 것이지, 실제로 설정해서 얼마나 세밀하게 되는지를 확인한 것이 아닙니다. 둘째, 오닉스의 SSO 줄은 “무료 판에서 안 된다”는 단정이 아닙니다. README가 이 기능들을 엔터프라이즈 항목으로 묶어 두었다는 사실만 확인한 것입니다. 어느 에디션에서 되는지는 가격 페이지를 열어 보세요.

내 문서를 읽히는 기능(RAG)은 어디가 두꺼운가

RAG는 “AI가 답하기 전에 내 문서에서 관련 부분을 먼저 찾아 읽게 하는 방식”입니다. 챗 화면에서 PDF를 올리고 “여기서 환불 규정만 알려 줘” 하는 기능이 이 방식입니다. 벡터 데이터베이스가 문서를 쪼개 검색하기 좋게 저장해 둡니다. 벡터 저장소가 궁금하시면 벡터 DB 5곳 비교 글에서 요금 구조를 다뤘습니다.

• 오픈웹UI: 벡터 데이터베이스 9종 중에서 고를 수 있고, 문서에서 글자를 뽑는 엔진도 여럿(Tika, Docling, Document Intelligence, Mistral OCR 등) 연결됩니다. 키워드 검색(BM25)과 벡터 검색을 섞는 하이브리드 검색을 지원한다고 적혀 있습니다.
• 오닉스: 이쪽이 본업입니다. 50여 개 앱에서 지식을 끌어와 권한 정보와 함께 색인해 두고, 질문이 오면 그 색인에서 바로 찾습니다. README는 “MCP로 여러 앱을 돌며 검색하는 방식보다 안정적이고 지연이 짧고 비용이 낮다”고 주장합니다. 이건 제작사의 주장이고, 이 글에서 직접 비교해 본 것은 아닙니다.
• 애니띵LLM: “내 문서와 대화”를 첫 줄에 내세웁니다. PDF·TXT·DOCX 같은 여러 문서 형식을 올려 출처 인용과 함께 답하는 화면이 기본이고, 대형 문서 묶음을 위한 최적화를 넣었다고 적혀 있습니다. 벡터 저장소는 기본이 내장 랜스DB입니다.
• 리브챗: 별도의 rag_api 서버와 pgvector가 compose에 들어 있습니다. 최근 버전(v0.8.8) 소개에는 첨부 파일을 한 번 올리면 모델에 바로 넘길지, 추출한 글자로 넘길지, 파일 검색·코드 실행 도구를 붙일지를 알아서 정해 주는 “통합 첨부” 기능이 적혀 있습니다.
• 로브허브: README에서 문서 검색 기능을 확인하지 못했습니다. 이 글에서는 “확인 못 함”으로 둡니다.

에이전트와 MCP는 어디까지 열려 있나

**MCP(모델 컨텍스트 프로토콜)**는 AI가 외부 도구(파일, 검색, 사내 시스템)를 부르는 공통 규격입니다. 서비스를 고르는 분들께 중요한 건 **“내가 쓰는 도구를 이 화면에 붙일 수 있느냐”**입니다. MCP 서버를 찾는 방법은 MCP 레지스트리 비교 글에 정리해 두었습니다.

다섯 곳 모두 문서에 MCP 연동을 적었습니다. 차이는 결이 다릅니다.

• 오픈웹UI는 MCP, MCPO(MCP를 일반 웹 인터페이스로 바꿔 주는 중계), OpenAPI 도구 서버를 다 연결합니다. 모델에 도구·지식·지침을 묶어 전용 에이전트를 만드는 기능도 있습니다.
• 리브챗은 노코드 에이전트, 에이전트 장터, SKILL.md 문서로 재사용 가능한 스킬, 하위 에이전트(서브에이전트)까지 갖췄습니다. 코드 실행 API는 파이썬·Node.js·Go·C/C++·자바·PHP·러스트·포트란을 격리된 환경에서 돌린다고 적혀 있습니다.
• 로브허브는 에이전트 구성이 중심입니다. 스킬 1만 개 이상이라는 숫자는 README의 표현 그대로이고, 그중 몇 개가 실제로 쓸 만한지는 확인하지 못했습니다.
• 애니띵LLM은 노코드 에이전트 빌더, MCP 호환, 스케줄 작업(정해진 시각에 프롬프트 실행), 도구가 많을 때 토큰을 줄여 주는 “지능형 스킬 선택”(제작사 표현으로 질의당 최대 80% 절감)을 내세웁니다. 80%는 제작사가 적은 수치입니다.
• 오닉스는 외부 앱에서 작업을 실행하는 액션, 코드 실행 샌드박스, 그리고 거꾸로 오닉스가 MCP 서버 역할을 해서 클로드 코드·코덱스 같은 에이전트에게 회사 지식을 건네는 기능이 눈에 띕니다.

활동성: 별 수보다 최근 소식

별이 많다는 건 관심이 많다는 뜻이지, 지금도 잘 관리된다는 보증은 아닙니다. 그래서 각 저장소의 마지막 푸시 날짜와 첫 공개 연도를 같이 봤습니다.

다섯 곳 모두 이 글을 쓰기 이틀 안에 코드가 올라왔습니다. 깃허브에서 “활동이 멎은 프로젝트”를 걸러 내는 가장 값싼 방법이 마지막 푸시 날짜인데, 이 기준으로는 다섯 곳 다 살아 있습니다. 이슈에 얼마나 빨리 답하는지는 이 글에서 보지 못했습니다.

상황별로 고르면

모든 걸 직접 써 보고 한 말이 아니라 문서에 적힌 조건만 놓고 한 구분입니다.

• 혼자, 가장 빨리 시작하고 싶다 → 오픈웹UI 또는 애니띵LLM. 둘 다 컨테이너 하나로 시작합니다. 올라마로 로컬 모델을 돌리고 있다면, 올라마 포함 이미지를 따로 안내하는 오픈웹UI가 눈에 띕니다.
• 혼자지만 내 문서와 대화가 목적 → 애니띵LLM. 데스크톱 앱으로 받으면 설정이 가장 단순합니다. 단 다중 사용자 기능은 빠집니다.
• 작은 팀이고, 이름·로고를 바꿔 회사 도구처럼 내놓고 싶다 → 리브챗 또는 애니띵LLM(순수 MIT). 오픈웹UI는 50명 초과 가능성이 있으면 허락이나 계약부터 확인해야 하고, 로브허브는 코드를 고쳐 배포하는 순간 상용 라이선스 문제가 됩니다.
• 사내 앱 지식(슬랙, 드라이브, 지라 등)을 한곳에서 묻고 싶다 → 오닉스. 다만 표준 모드는 구성이 무겁고, 필요한 기능이 EE 쪽인지 확인해야 합니다.
• 에이전트를 여러 개 꾸려 일을 맡기는 쪽에 관심 → 로브허브나 리브챗. 로브허브는 컨테이너 일곱 개를 감당할 수 있는지부터 보세요.
• 서버 운영 경험이 없다 → 오픈웹UI·애니띵LLM의 한 줄 설치부터. 리브챗과 로브허브는 데이터가 데이터베이스 볼륨에 쌓이니 볼륨이 어디에 만들어지는지부터 확인하세요. 오픈웹UI 설치 안내도 데이터 볼륨(-v open-webui:/app/backend/data)을 빼먹지 말라고 경고합니다.

이 글에서 확인하지 못한 것

비교 글에서 가장 위험한 건 확인하지 않은 것을 한 것처럼 쓰는 일입니다. 정직하게 빠진 부분을 적습니다.

• 직접 설치해서 써 보지 않았습니다. 이 글은 LICENSE·README·compose 파일을 읽은 정리입니다. 그래서 firsthand(직접 써 본 대상) 표시도 달지 않았습니다.
• 메모리·속도 실측은 없습니다. 애니띵LLM의 최소 사양 2GB, 오닉스 라이트의 1GB 미만은 각 문서가 적은 값이고, 제가 재 본 값이 아닙니다.
• 요금이 있는 클라우드 판은 가격을 확인하지 못했습니다. 오닉스 클라우드, 애니띵LLM의 호스팅 판, 오픈웹UI 엔터프라이즈 플랜은 README가 언급하지만 가격 페이지를 이 글에서 열어 비교하지 않았습니다.
• 오닉스 EE에 정확히 어떤 기능이 들어가는지는 가격 페이지의 기능표를 보지 못했습니다.
• 로브허브의 문서 검색 기능은 README에서 확인하지 못했습니다.
• 라이선스 해석은 법률 자문이 아닙니다. 원문의 핵심 문구를 옮기고 풀어 쓴 것이고, 실제 사업에서는 원문과 전문가 판단이 우선입니다.
• 별 수·최신 버전은 2026년 10월 5일 값입니다. 라이선스는 바뀐 전례가 있는 항목(오픈웹UI는 두 번, 로브허브는 기여자 조건에서 변경 가능성을 명시)이므로, 쓰기 직전에 LICENSE 파일의 최신 내용을 다시 보세요.

이 글에 나온 낯선 말 여섯 개

• 셀프호스팅: 남이 운영하는 서비스를 쓰지 않고, 내 컴퓨터나 서버에 프로그램을 직접 올려 돌리는 것.
• 컨테이너(도커): 프로그램과 실행 환경을 한 상자로 묶어 어디서든 같은 방식으로 돌리게 하는 기술. 상자 하나가 프로세스 하나라고 생각하면 편합니다.
• docker-compose: 여러 상자를 한 번에 올리라고 적어 둔 설계도 파일.
• RAG: 답하기 전에 내 문서에서 관련 부분을 찾아 AI에게 읽혀 주는 방식.
• MCP: AI가 외부 도구를 부르는 공통 규격.
• SSO: 한 번 로그인으로 여러 서비스에 들어가는 방식. 회사 계정으로 로그인하는 화면이 대표적입니다.

정리: 라이선스 한 줄 요약

다섯 곳을 라이선스로만 줄 세우면 이렇습니다. 리브챗·애니띵LLM은 순수 MIT. 오닉스는 MIT인데 ee 폴더만 별도. 로브허브는 쓰는 건 자유이고 고쳐 배포하면 계약. 오픈웹UI는 이름·로고를 바꾸려면 사용자 50명이 넘는 순간 허락이 필요.

설치 규모로 줄 세우면 컨테이너 하나(오픈웹UI·애니띵LLM) → 여섯 개(리브챗) → 일곱 개 이상(로브허브), 오닉스는 가볍게도 무겁게도 쓰는 양면 구조입니다.

두 줄을 겹쳐 보면 선택이 쉬워집니다. 순수 MIT이면서 한 컨테이너인 곳은 애니띵LLM이고, 기능을 가장 넓게 열어 둔 곳은 오픈웹UI이지만 이름 조항이 있습니다. 처음 올려 보는 분이라면 컨테이너 하나짜리 둘 중 하나로 시작하고, 팀 도입을 고민하는 단계에서 라이선스 문서를 한 번 더 읽으세요. 코드는 같은 모양이어도 약속은 곳마다 다르다는 것이 이 글의 결론입니다.