SSD Nodes Learn 🎉 VPS $4.99/월부터
가이드 Matt Connor작성자 Matt Connor · 업데이트됨 2026-08-05

VPS용 Open WebUI 대안 비교: LibreChat 등 4종 분석

VPS 환경에서 Open WebUI, LibreChat, Hollama, OrionChat의 RAM 점유율과 인증 기능, 유지보수 난이도를 비교합니다. 공인 IP 환경에서 모델 구동을 위한 최적의 인터페이스 선택 기준을 확인하십시오.

VPS에 적합한 Open WebUI 대안은 무엇인가

Open WebUI 대안들은 대부분 RAM이 저렴하고 공개 주소로 수신 대기하는 서비스가 없는 노트북 환경을 기준으로 비교됩니다. 하지만 VPS 환경에서는 이 두 가지 조건이 모두 달라지며, 그에 따라 순위도 바뀝니다. Open WebUI는 실제 사용자 계정과 관리자 패널을 제공하므로, 두 명 이상의 사용자가 로그인하는 순간부터 여전히 가장 적절한 기본 선택지입니다. 반면, 인터페이스가 모델과 마지막 1GB의 RAM을 두고 경쟁해야 하는 상황에서는 더 가벼운 프로젝트들이 유리합니다. 이러한 이점의 대가는 인증 기능의 부재입니다.

아래의 모든 내용은 2026년 8월 기준으로 각 프로젝트의 자체 문서를 바탕으로 작성되었습니다. 제시된 네 가지 기준은 서버가 인터넷에서 접근 가능해질 때만 고려해야 하는 요소들입니다.

공인 IP에서만 고려해야 할 네 가지 요소

  • 모델 근처의 메모리. 모델 서버는 시스템에서 가장 많은 자원을 소모하는 프로세스입니다. 인터페이스가 점유하는 모든 메가바이트는 모델이 사용할 수 없는 메모리입니다.
  • 인증. 일부 프로젝트는 사용자 계정과 역할을 지원합니다. 반면 어떤 프로젝트는 사용자의 노트북에서 단독으로 실행된다고 가정하여 로그인 기능이 전혀 없습니다.
  • 원격 추론. 127.0.0.1:11434에만 접근할 수 있는 UI는 모델을 인터페이스와 동일한 서버에서 실행하도록 강제합니다.
  • 유지보수. SQLite 파일을 사용하는 컨테이너 하나를 관리하는 것과 MongoDB 및 벡터 데이터베이스를 포함한 컨테이너 여섯 개를 관리하는 것은 완전히 다른 작업입니다.

모델이 인터페이스를 위해 남겨두는 RAM 용량은 얼마인가

인터페이스는 서버에서 가장 큰 비중을 차지하는 요소가 아닙니다. 모델이 가장 큽니다. 공개된 다운로드 크기는 최소 사양일 뿐입니다. 모델이 응답하는 동안 가중치가 메모리에 상주해야 하며, 컨텍스트 캐시가 할당되면 실제 메모리 사용량은 다운로드 크기보다 커지기 때문입니다.

ChartPublished download size of common Ollama models, August 2026
The data behind this chart
[
  {
    "label": "llama3.2:3b",
    "download_gb": "2.0"
  },
  {
    "label": "qwen3:4b",
    "download_gb": "2.5"
  },
  {
    "label": "gemma3:4b",
    "download_gb": "3.3"
  },
  {
    "label": "qwen3:8b",
    "download_gb": "5.2"
  }
]

위 수치는 2026년 8월 Ollama 라이브러리 페이지에 게시된 내용입니다. 이는 측정값이 아닌 공개된 크기입니다. 4 GB VPS 환경에서 qwen3:4b 모델은 2.5 GB를 차지하며, 운영체제와 기타 작업을 위해 1.5 GB 미만의 여유 공간만 남깁니다. 대화가 길어질수록 컨텍스트 캐시가 이 공간을 잠식합니다. qwen3:8b 모델은 5.2 GB를 차지하므로 해당 서버에서는 아예 실행할 수 없습니다. 이는 노트북 성능 비교 자료에서는 다루지 않는 상황이며, 수백 메가바이트를 점유하는 채팅 인터페이스가 모델의 실행 여부를 결정짓는 지점이기도 합니다.

비교 자료에 나온 숫자를 맹신하지 말고 직접 측정하십시오. 컨테이너가 시작된 지 1분이 아니라, 실제 사용을 시작하고 1시간이 지난 뒤에 docker stats --no-stream를 실행하십시오. 중요한 메모리 할당은 첫 사용 시점에 이루어지기 때문입니다.

Open WebUI: 다중 사용자 환경에서의 기본 설정 유지

Open WebUI는 단일 이미지로 실행되며 데이터를 하나의 볼륨에 저장합니다.

docker run -d -p 127.0.0.1:3000:8080 -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

프로젝트 README에 기재된 명령어는 -p 3000:8080을 게시하며, 이는 모든 인터페이스에서 수신 대기합니다. 127.0.0.1: 접두사를 사용하면 루프백 인터페이스로 제한됩니다. VPS 환경에서는 이 접두사가 해당 라인의 다른 어떤 설정보다 중요합니다. 왜냐하면 Docker는 자체 iptables 규칙을 작성하며, 게시된 포트는 사용자가 설정한 ufw 거부 규칙을 무시하기 때문입니다.

아래에 설명된 터널이나 프록시를 통해 페이지에 접속한 뒤 첫 번째 계정을 생성하십시오. 해당 계정이 관리자 권한을 갖게 됩니다. 이후의 가입자는 DEFAULT_USER_ROLE의 문서화된 기본값인 pending 역할로 생성되므로, 페이지에 접속한 외부인은 관리자가 승인하기 전까지 모델을 사용할 수 없습니다.

Open WebUI는 더 많은 기능을 수행하므로 아래의 다른 프로젝트보다 더 많은 메모리를 사용하며, 자체 성능 페이지에 메모리 점유율이 높은 구성 요소가 명시되어 있습니다. 기본 임베딩 엔진은 컨테이너 내부에서 sentence-transformers 모델을 로드하며, 이는 워커 프로세스당 약 500 MB를 점유하는 것으로 문서화되어 있습니다. RAG_EMBEDDING_ENGINE=ollama을 설정하면 해당 작업을 이미 실행 중인 모델 서버로 위임할 수 있습니다. AUDIO_STT_ENGINE=webapi을 설정하면 로컬 음성 인식(speech-to-text) 모델을 로드하지 않습니다. DATABASE_POOL_SIZE가 설정되지 않은 SQLite 환경에서는 연결 풀이 내부적으로 큰 크기로 할당되며 각 연결이 자체 페이지 캐시와 메모리 맵을 확장하므로, 소규모 서버에서는 DATABASE_POOL_SIZE=8과 DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0을 설정하십시오. ENABLE_AUTOCOMPLETE_GENERATION=False는 사용자가 타이핑하는 도중에 인터페이스가 모델에 완성을 요청하는 동작을 방지합니다.

LibreChat: 다중 사용자 지원 및 관련 스택

git clone https://github.com/danny-avila/LibreChat.git
cd LibreChat
cp .env.example .env
docker compose up -d

인터페이스는 3080 포트에서 응답합니다. 단순한 로그인 상자가 아닌 계정 관리 시스템이 필요할 때 LibreChat을 고려해야 합니다. LDAP 및 OAuth2 로그인을 지원하며, 사용자 및 역할 관리를 위한 관리자 패널을 포함하고 있습니다. 이러한 기능은 관련 스택과 함께 제공됩니다.

ChartContainers a default install adds, not counting the model server
The data behind this chart
[
  {
    "label": "OrionChat",
    "containers": 0,
    "notes": "static files, served by a web server you already run"
  },
  {
    "label": "Hollama",
    "containers": 1,
    "notes": "one container serving a browser app"
  },
  {
    "label": "Open WebUI",
    "containers": 1,
    "notes": "application and SQLite in one image"
  },
  {
    "label": "LibreChat",
    "containers": 6,
    "notes": "api, admin panel, MongoDB, Meilisearch, pgvector, RAG API"
  }
]

기본 compose 파일은 6개의 서비스를 시작합니다: api, admin panel, MongoDB, Meilisearch, pgvector, RAG API. 이 중 모델 서비스는 없습니다. MongoDB와 pgvector는 각각 별도의 메모리를 점유하며, 4 GB 메모리 환경에서는 모델이 필요로 하는 메모리 자원을 잠식합니다.

업그레이드는 git 작업을 통해 수행되며, 사용자가 가장 자주 실수하는 부분입니다.

docker compose down
git pull
docker compose pull
docker compose up -d

추적 중인 docker-compose.yml 파일을 수정하면 git pull 실행 시 충돌이 발생하며, 업그레이드가 절반만 적용됩니다. 변경 사항은 프로젝트에서 제공하는 docker-compose.override.yml 파일에 작성하고, 보안 정보는 .env에 보관하십시오. 두 파일 모두 추적 대상에서 제외되어 있으므로 git pull 실행 시 영향을 받지 않습니다.

librechat.yaml 파일에 사용자 지정 엔드포인트를 설정하여 LibreChat이 자체 모델 서버를 참조하도록 구성하십시오.

endpoints:
  custom:
    - name: "Ollama"
      apiKey: "ollama"
      baseURL: "http://model-host:11434/v1/"
      models:
        default: ["llama3.2"]
        fetch: true
      titleConvo: true
      titleModel: "current_model"
      modelDisplayLabel: "Ollama"

model-host를 Ollama가 실행 중인 서버의 주소로 교체하십시오. apiKey 필드는 Ollama에서 값을 무시하더라도 반드시 존재해야 하므로, 임의의 값을 입력해도 무방합니다. LibreChat이 Docker 컨테이너 내부에서 실행되고 Ollama가 동일한 머신에서 실행 중인 경우, 컨테이너 내부의 localhost은 컨테이너 자신을 가리키므로 대신 host.docker.internal를 사용해야 합니다.

Hollama와 OrionChat: 브라우저가 수행하는 작업

Hollama는 작은 컨테이너 하나에서 브라우저 애플리케이션을 제공합니다. 대화 내용은 서버가 아닌 브라우저 저장소에 보관됩니다.

docker run -d --restart unless-stopped -p 127.0.0.1:4173:4173 --name hollama ghcr.io/fmaclen/hollama:latest

이 명령의 README 버전은 --rm을 사용하는데, 이는 컨테이너가 중지될 때 삭제되므로 재부팅 후에는 인터페이스가 다시 나타나지 않습니다. 리버스 프록시 뒤에서 운영할 때는 -e VITE_ALLOWED_HOSTS='chat.example.com'를 추가하십시오. 이 이미지는 호스트 localhost만 허용하며, 다른 호스트 이름으로 요청이 들어오면 애플리케이션 대신 차단된 호스트 오류를 반환하기 때문입니다.

OrionChat은 한 걸음 더 나아가 서버 구성 요소가 전혀 없습니다. 저장소를 복제한 뒤 이미 운영 중인 웹 서버로 해당 폴더를 제공하거나, 디스크에서 index.html을 직접 여십시오. API 키는 브라우저의 localStorage에 저장되고 대화 기록은 브라우저에 남으며, 대화 개수가 512개를 넘으면 가장 오래된 대화부터 삭제됩니다.

두 프로젝트 모두 서버가 없으므로 로그인 기능도 없습니다. 노트북에서 사용하기에는 적합하지만, VPS에서 운영할 때는 페이지를 0.0.0.0에 절대 게시해서는 안 됩니다. 또한 간과하기 쉬운 사실이 하나 있는데, 브라우저가 서버가 아닌 모델을 직접 호출한다는 점입니다.

이 사실 하나가 두 서비스의 사용 가능 여부를 결정합니다. 브라우저가 Ollama에 직접 도달해야 하므로 Ollama는 루프백 이상의 인터페이스에서 수신 대기해야 하며, Ollama에는 어떠한 인증 기능도 없습니다. 이로 인해 두 가지 브라우저 규칙이 적용됩니다. HTTPS로 제공되는 페이지는 일반 HTTP 엔드포인트를 호출할 수 없으며, 콘솔에는 Mixed Content: The page at 'https://chat.example.com/' was loaded over HTTPS, but requested an insecure resource 'http://203.0.113.10:11434/api/tags'. This request has been blocked.가 출력됩니다. 다른 오리진으로의 호출은 has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource으로 거부되며, 해당 오리진을 허용하기 전까지는 통신할 수 없습니다.

Ollama에서 이 설정을 변경하는 공식적인 방법은 systemd override를 사용하는 것입니다.

sudo systemctl edit ollama.service
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=https://chat.example.com"
sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ss -lntp | grep 11434

이제 ss을 실행하면 이전에 127.0.0.1:11434이 출력되던 자리에 0.0.0.0:11434가 출력되어야 합니다. 이 변경은 방화벽이나 인증 프록시가 해당 포트에 대한 접근을 제어하고 있을 때만 수행하십시오. 11434 포트를 개방하는 것은 모델 서버를 외부에 노출하는 것과 같으며, 대규모 스캐너들은 새로운 공개 포트를 빠르게 찾아내기 때문입니다. 아래의 SSH 터널을 사용하면 이 문제를 완전히 피할 수 있습니다. 페이지가 localhost 오리진에서 실행되므로 Ollama가 기본적으로 허용하며, 포트가 외부로 노출되지도 않습니다.

각각 원격 Ollama 또는 vLLM 엔드포인트를 사용할 수 있습니까

Open WebUI는 가능하며, 연결은 서버 측에서 이루어집니다. OLLAMA_BASE_URL=http://model-host:11434는 Ollama를 가리킵니다. vLLM 또는 기타 OpenAI 호환 서버의 경우, 비어 있지 않은 OPENAI_API_KEY과 함께 OPENAI_API_BASE_URL=http://model-host:8000/v1을 설정하고 필수 항목인 /v1 접미사를 유지하십시오. OPENAI_API_BASE_URLS는 세미콜론으로 구분된 여러 백엔드를 허용합니다.

LibreChat은 위에서 언급한 사용자 지정 엔드포인트의 baseURL을 통해 가능합니다. 해당 요청 또한 서버를 거쳐 나가므로 브라우저 규칙은 적용되지 않습니다.

Hollama와 OrionChat은 설정에 입력하는 모든 엔드포인트를 가리킬 수 있지만, 요청은 브라우저를 통해 나갑니다. 위 섹션의 모든 내용은 해당 애플리케이션에만 적용되며 여기의 다른 항목에는 적용되지 않습니다.

인터페이스와 모델을 분리하는 것은 원격 엔드포인트를 통해 얻을 수 있는 가장 유용한 이점입니다. 인터페이스는 작은 장비에 두고, 모델은 메모리가 충분한 곳에 배치하십시오. 여러 사용자가 동시에 모델과 대화할 때 두 방식의 동작 방식이 크게 다르므로, Ollama와 vLLM 중 무엇으로 요청을 처리할지 결정해야 하는 시점이기도 합니다. 모델 서버가 아직 없다면 VPS에서 Ollama를 실행하는 것부터 시작하십시오. CPU 전용 장비라면 실행기를 선택하기 전에 Ollama와 llama.cpp의 비교 내용을 읽어보시기 바랍니다.

로그인 기능이 없는 채팅 UI를 0.0.0.0에 공개하지 마십시오

Open WebUI의 보안 강화 페이지에 따르면, 이 프로젝트는 "데이터베이스, 컨테이너 레지스트리, CI 서버와 같은 다른 자가 호스팅 인프라와 마찬가지로 사설 및 신뢰할 수 있는 네트워크용으로 구축"되었습니다. 따라서 VPN 뒤에 배치하거나 인증 기능이 있는 리버스 프록시 뒤에 두어야 합니다. 로그인 기능이 전혀 없는 프로젝트라면 최소한 그와 동일한 수준의 보안 조치가 필요합니다.

신뢰하기 전에 어떤 포트가 리스닝 상태인지 확인하십시오.

sudo ss -lntp | grep -E ':(3000|3080|4173|11434)'

127.0.0.1:3000라고 적힌 줄이 정상입니다. 0.0.0.0:3000라고 적힌 줄이 있다면 채팅 인터페이스가 공용 인터넷에 노출된 상태입니다. 본인의 머신에서 curl -sI http://YOUR.VPS.IP:3000 명령을 실행하여 HTTP/1.1 200 OK가 출력된다면, 이는 더 직설적으로 같은 사실을 의미합니다.

WEBUI_AUTH=False를 사용하여 Open WebUI의 로그인을 끄는 것은 외부에서 접근할 수 없는 머신을 위한 단일 사용자 설정입니다. 이미 계정이 생성된 설치 환경에는 이 설정이 적용되지 않으며, You can't turn off authentication because there are existing users.이라는 메시지가 표시됩니다.

패턴 1: 루프백에 바인딩하고 SSH를 통해 접근하기. 모든 포트를 127.0.0.1에 게시한 다음, 필요한 포트만 포워딩하십시오: ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com. 그런 다음 노트북에서 http://localhost:3000로 접속합니다. 아무것도 공개되지 않았으므로 스캔할 수 없습니다. Hollama나 OrionChat의 경우, -L 11434:127.0.0.1:11434을 사용하여 모델 포트를 같은 명령어로 포워딩하고 Ollama는 루프백에 그대로 둡니다. 이 패턴의 보안 수준은 SSH 설정에 달려 있으므로, 키 기반 SSH 및 강화된 sshd와 함께 사용하십시오.

패턴 2: 애플리케이션이 요청을 받기 전에 인증하는 리버스 프록시 사용. 애플리케이션을 루프백에 유지하고, 프록시가 443 포트를 점유하게 한 뒤 그 앞에 SSO(Single Sign-On)를 배치합니다. Docker Compose 레이블로 구동되는 Traefik과 ID 공급자로 Authentik을 사용하면 서버의 모든 애플리케이션에 대해 단일 로그인과 단일 인증서를 적용할 수 있습니다. Open WebUI를 TLS(전송 계층 보안) 뒤에 배치할 때는 WEBUI_SESSION_COOKIE_SECURE=true 및 WEBUI_SESSION_COOKIE_SAME_SITE=strict를 설정하십시오. Open WebUI 문서에 따르면 Redis가 없으면 로그아웃해도 토큰이 무효화되지 않고 만료될 때까지 계속 사용 가능하므로, JWT_EXPIRES_IN의 기본값인 4주를 더 짧게 줄이십시오.

패턴 2는 브라우저 전용 프로젝트를 보호하지 못합니다. 페이지 앞단의 프록시는 모델 엔드포인트를 보호하지 않으며, 해당 페이지에서 다른 호스트 이름으로 요청을 보낼 때 세션 쿠키가 전달되지 않습니다. 따라서 Ollama 앞의 인증 프록시는 로그인 폼으로 리다이렉트 응답을 보내고 채팅은 실패하게 됩니다. 모델 엔드포인트를 페이지와 동일한 호스트 이름으로 라우팅하거나, 패턴 1을 사용하십시오.

어떤 것을 선택할 것인가

본인 외에 다른 사람이 사용한다면 Open WebUI를 실행하십시오. 실제 계정 기능을 지원하며, 신규 사용자는 승인 대기열에 등록되고, 관리자가 제공하는 보안 강화 지침을 따를 수 있습니다. LDAP나 관리자 패널이 필요하다면 LibreChat을 실행하십시오. 단, docker stats를 통해 6개의 서비스와 모델이 실제 리소스 내에서 구동 가능한지 먼저 확인한 뒤 도입해야 합니다. 모델이 이미 RAM의 대부분을 점유하는 소형 서버에서 1인용으로 사용한다면, SSH 터널을 통해 Hollama나 OrionChat을 서비스하고 브라우저가 상태를 유지하게 하십시오. VPS 환경에서 가장 피해야 할 방식은 로그인 절차 없이 0.0.0.0에 직접 노출하는 것입니다.

FAQ

Open WebUI를 공인 IP에 직접 노출해도 안전합니까?

Open WebUI의 보안 강화 페이지에서는 이 소프트웨어를 데이터베이스나 CI 서버와 같이 신뢰할 수 있는 사설 네트워크용으로 분류합니다. 실제 계정 시스템이 존재하며, 첫 번째 계정이 관리자가 되고 이후 계정은 승인 전까지 pending 상태로 유지되므로 로그인 기능이 없는 UI보다는 훨씬 안전합니다. 그럼에도 불구하고 TLS가 적용된 리버스 프록시 뒤에 배치하고, 가능하다면 싱글 사인온(SSO)을 사용하는 것이 좋습니다. Docker의 iptables 규칙이 의도치 않게 인터넷으로 포트를 개방하지 않도록 컨테이너 포트를 127.0.0.1:3000:8080로 게시하십시오.

VPS에서 RAM을 가장 적게 사용하는 Open WebUI 대안은 무엇입니까?

브라우저 기반인 Hollama와 OrionChat이 가장 적은 메모리를 사용합니다. 애플리케이션이 클라이언트 측에서 실행되기 때문입니다. 서버는 정적 파일만 전송하며, 특히 OrionChat은 애플리케이션 컨테이너조차 필요하지 않습니다. Open WebUI는 Python 프로세스, 데이터베이스, 그리고 기본적으로 로컬 임베딩 모델을 메모리에 유지합니다. 임베딩 모델만으로도 워커당 약 500 MB를 점유하는 것으로 알려져 있습니다. 활성화한 기능에 따라 메모리 사용량이 달라지므로 docker stats --no-stream 명령을 사용하여 자신의 서버에서 직접 수치를 확인하십시오.

이러한 채팅 UI를 다른 호스트의 Ollama 서버와 연결할 수 있습니까?

Open WebUI와 LibreChat은 가능합니다. 서버가 직접 연결을 수행하므로 브라우저 규칙의 제한을 받지 않습니다. Open WebUI는 OLLAMA_BASE_URL를 설정하고, LibreChat은 사용자 정의 엔드포인트에서 baseURL을 설정하십시오. vLLM이나 다른 OpenAI 호환 서버를 사용하는 경우 OPENAI_API_BASE_URL에 /v1 접미사를 붙이고 비어 있지 않은 API 키를 사용하십시오. Hollama와 OrionChat도 다른 주소를 지정할 수 있지만, 이 경우 브라우저에서 직접 요청을 보내므로 브라우저에서 해당 엔드포인트에 접근할 수 있어야 합니다.

브라우저 채팅 UI가 왜 Ollama에 연결되지 않습니까?

대부분의 경우 두 가지 원인 때문입니다. Ollama는 기본적으로 127.0.0.1:11434에 바인딩되므로 OLLAMA_HOST를 변경하지 않으면 다른 기기의 브라우저에서 접근할 수 없습니다. 또한 Ollama는 localhost에서 오는 교차 출처(cross-origin) 요청만 허용하므로, 자신의 도메인에서 제공되는 페이지는 OLLAMA_ORIGINS에 해당 출처가 등록되지 않으면 No 'Access-Control-Allow-Origin' header is present on the requested resource 오류로 거부됩니다. 페이지는 HTTPS인데 엔드포인트가 HTTP인 경우, 브라우저는 혼합 콘텐츠(mixed content)로 간주하여 Ollama에 도달하기 전에 요청을 차단합니다. 두 변수를 systemctl edit ollama.service 오버라이드 파일에 설정하거나, SSH로 포트 포워딩을 수행하면 문제가 해결됩니다.

#open-webui#librechat#ollama#self-hosted-ai#chat-ui