로컬 LLM을 서비스나 개인 프로젝트에 붙이려면 결국 비용 문제가 따라옵니다. 처음에는 “API로 일단 써보자”로 시작하지만, 프롬프트를 조금만 바꾸고 결과를 비교하는 과정을 반복하면 호출량이 금방 쌓입니다.
이번에는 방향을 바꿔 클라우드 없이 Ubuntu 서버에 로컬 LLM 환경을 직접 구성해봤습니다. 특히 집에 남는 **GTX 1080 장비를 재활용해서 ‘가볍게 테스트’**해보는 게 목적이었습니다.
목표
- Ubuntu에 Ollama 설치
- 모델 1개 다운로드 후 실행
- Open WebUI까지 붙여 브라우저에서 테스트
- GTX 1080 환경에서 “쓸 만한지” 가볍게 확인
왜 로컬 LLM을 써보려고 했나
로컬 LLM을 보게 된 이유는 단순히 비용 통제 때문입니다.
제가 테스트하려는 방향은 자유 채팅형 서비스라기보다, 정해진 데이터를 넣고 요약하거나 설명을 만들어내는 내부 분석형 구조에 가깝습니다.
예를 들면 이런 작업입니다.
- 문서 요약
- 핵심 포인트 정리
- 쉬운 표현으로 다시 설명하기
- 입력 데이터 기반 요약 문구 생성
이런 작업은 꼭 비싼 클라우드 모델이 아니어도 어느 정도 처리할 수 있습니다.
오히려 중요한 건 아래에 더 가까웠습니다.
- 내가 가진 데이터를 잘 정리하느냐
- 응답 속도가 감당 가능한 수준이냐
- 운영비를 통제할 수 있느냐
그래서 이번에는 “최고 성능 모델”보다 “운영 가능한 로컬 환경” 쪽에 초점을 맞췄습니다.
Ollama는 정확히 뭘까
처음에 헷갈리기 쉬운데 Ollama는 모델 자체가 아닙니다.
정리하면 아래처럼 이해하는 게 가장 편합니다.
- Qwen, Llama, EXAONE → 실제 모델
- Ollama → 로컬에서 모델을 실행하게 해주는 런타임(실행 도구)
즉 Ollama를 설치한다고 바로 AI가 완성되는 것은 아니고, 설치 후에 어떤 모델을 쓸지 골라서 다운로드해야 합니다.
예:
ollama run qwen2.5:7b
어떤 장비면 테스트가 가능할까
처음부터 RTX 4090이나 서버급 GPU가 꼭 필요한 건 아닙니다. 가볍게 테스트하는 수준이라면 문턱이 생각보다 낮습니다.
1) 가볍게 설치/동작 확인
- GTX 1080
- RAM 16GB 이상
- 7B급 경량 모델
이 정도면 “설치가 되는지”, “모델이 뜨는지”, “요약이 어느 정도 되는지”는 충분히 확인할 수 있었습니다.
2) 조금 더 무난하게 써보기
- RTX 4070 SUPER / RTX 5070
- RAM 32GB 이상
- 7B~8B급 모델 운영
테스트를 넘어서 로컬 실사용도 현실적인 구간입니다.
3) 여유 있게 실험해보기
- VRAM 16GB 이상
- 14B급 모델까지 검토 가능
물론 실제 체감은 모델 크기, 컨텍스트 길이, 동시 요청 수에 따라 달라집니다. 다만 출발점으로는 GTX 1080 + 7B급도 충분히 의미가 있었습니다.
Ubuntu에 Ollama 설치
설치 자체는 단순했습니다. 공식 설치 스크립트를 그대로 실행하면 됩니다.
curl -fsSL <https://ollama.com/install.sh> | sh
설치 후 버전 확인:
ollama -v
GPU가 Ubuntu에서 정상적으로 잡히는지도 확인했습니다.
nvidia-smi
여기까지는 크게 어렵지 않았습니다. 진짜 시간은 “설치”보다 연결해서 실제로 쓰는 과정에서 더 들었습니다.
모델은 설치 후 따로 받아야 한다
Ollama는 실행기이기 때문에, 설치 후 바로 응답이 오지 않습니다. 실제로 쓸 모델을 하나 받아야 합니다.
처음에는 경량 테스트용으로 Qwen 계열을 받아봤습니다.
ollama pull qwen2.5:7b
설치된 모델 확인:
ollama list
직접 실행:
ollama run qwen2.5:7b
여기서 느낀 점이 하나 있었습니다.
- 로컬 모델은 최신 데이터를 알고 있는 모델이 아니다.
실제로 IPO 관련 질문을 던졌을 때 예전 시점 정보처럼 보이는 답이 나오기도 했고, Qwen 계열은 중국어가 섞이는 경우도 있었습니다.
이 지점에서 “로컬 LLM은 최신 사실 기억용이 아니라 내가 넣어준 데이터를 정리하는 엔진으로 봐야겠구나”라는 생각이 확실해졌습니다.
브라우저에서 테스트하려고 Open WebUI도 붙였다
터미널에서만 테스트하는 것도 가능하지만, 브라우저에서 ChatGPT처럼 확인할 수 있는 UI가 있으면 훨씬 편합니다. 그래서 Open WebUI를 같이 붙였습니다.
Docker Compose 설정은 대략 아래처럼 구성했습니다.
services:
open-webui:
image: ghcr.io/open-webui/open-webui:main
container_name: open-webui
restart: always
ports:
- "3000:8080"
environment:
OLLAMA_BASE_URL: "<http://192.168.0.3:11434>"
WEBUI_SECRET_KEY: "(원하는 값으로 변경)"
volumes:
- open-webui:/app/backend/data
volumes:
open-webui:
실행:
docker compose up -d
브라우저에서 아래 주소로 접속하면 됩니다.
- http://서버IP:3000
실제 접속 화면
아래는 실제로 Ubuntu 서버에 올린 Open WebUI에 브라우저로 접속한 화면입니다.
브라우저에서도 기본적인 채팅 UI가 정상적으로 열리는 것을 확인할 수 있었고,
“일단 로컬 LLM 환경을 웹으로 붙여서 어디서든 접속 가능한 형태로 만들 수 있겠구나” 하는 감이 왔습니다.
아직 이 단계는 완성된 서비스라기보다 테스트 환경에 가깝지만,
Ollama와 Open WebUI 조합만으로도 생각보다 꽤 그럴듯한 로컬 AI 채팅 환경이 만들어졌습니다.
여기까지 오면 끝난 줄 알았는데, 실제로는 이 지점에서 Linux 특유의 네트워크 이슈를 한 번 겪었습니다.
설치보다 오래 걸린 건 “연결 문제”였다
처음에는 Open WebUI에서 Ollama를 바로 읽어올 줄 알았는데 연결이 안 됐습니다.
1) host.docker.internal 이슈
Windows 등에서는 자주 쓰는 host.docker.internal 방식이 Ubuntu에서는 기본으로 바로 동작하지 않는 경우가 있습니다.
그래서 호스트의 실제 내부 IP를 직접 넣는 방식으로 바꿨습니다.
예: 192.168.0.3
2) 더 큰 문제: Ollama가 127.0.0.1에만 바인딩
결정적인 문제는 Ollama가 기본적으로 127.0.0.1:11434에만 바인딩되어 있었던 점입니다.
즉, 호스트 자신은 접근할 수 있지만 Docker 컨테이너는 접근할 수 없는 상태였습니다.
이 문제를 해결하려면 Ollama를 모든 인터페이스에 열리도록 다시 실행해야 했습니다.
pkill ollama
OLLAMA_HOST=0.0.0.0:11434 ollama serve
이제 Open WebUI에서 Ollama에 정상적으로 붙을 수 있었습니다.
systemd에도 영구 반영하기
테스트할 때는 셸에서 OLLAMA_HOST=0.0.0.0:11434로 띄우면 되지만, 이 상태로 두면 재부팅 후 원래대로 돌아갈 수 있습니다.
그래서 systemd override로 영구 반영했습니다.
sudo systemctl edit ollama
아래 내용을 추가합니다.
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
반영:
sudo systemctl daemon-reload
sudo systemctl restart ollama
연결은 됐는데 모델이 안 보일 때
Open WebUI까지 연결하고 나면, 이번에는 모델 목록이 안 보이는 경우가 있습니다.
ollama list
curl http://127.0.0.1:11434/api/tags여기서 모델이 실제로 설치되어 있지 않으면, 당연히 Open WebUI에서도 목록이 비어 있습니다.
그래서 ollama pull을 먼저 하고, 브라우저를 새로고침하거나 Open WebUI를 재기동하면 해결되는 경우가 많았습니다.
docker compose restart또는 로그아웃 후 다시 로그인해도 반영되는 경우가 있습니다.
관리자 계정에서는 보이는데 다른 사용자에게는 모델이 안 보일 때
이건 조금 더 헷갈리는 경우입니다.
관리자 계정으로 접속하면 모델이 잘 보이는데, 일반 사용자 계정에서는 모델 목록이 비어 있거나 선택이 안 되는 경우가 있습니다.
처음에는 Ollama 연결 문제로 생각하기 쉬운데,
실제로는 Open WebUI 내부 설정이나 사용자 노출 범위 문제인 경우가 많습니다.
이럴 때는 아래 순서로 보는 게 가장 빠릅니다.
1) 모델이 실제로 설치돼 있는지 먼저 확인
가장 기본적인 점검입니다.
ollama list여기서 모델이 없으면 관리자든 일반 사용자든 안 보여야 정상입니다.
2) 관리자 계정에서는 보이는지 확인
관리자 화면에서 모델이 보인다면, Ollama 연결과 모델 설치는 대체로 정상이라고 볼 수 있습니다.
이 경우는 네트워크 문제보다는 Open WebUI 설정 문제일 가능성이 높습니다.
3) 일반 사용자 세션을 새로고침한다
새 모델을 pull 한 뒤 일반 사용자 세션에는 바로 반영되지 않는 경우도 있습니다.
이럴 때는 아래 순서가 의외로 잘 먹힙니다.
- 브라우저 새로고침
- 로그아웃 후 재로그인
- 새 채팅 화면으로 다시 진입
- 그래도 안 되면 Open WebUI 재기동
4) 사용자 권한이나 모델 노출 설정을 확인한다
관리자 계정에서는 보이는데 일반 사용자에게만 안 보인다면,
대부분은 Open WebUI 쪽의 사용자 노출 설정이나 권한 범위를 먼저 의심하는 것이 맞습니다.
즉 이런 문제는 보통 GPU나 Ollama 문제라기보다
**“모델은 있는데 사용자 화면에 노출되지 않는 문제”**에 가깝습니다.
정리하면, 이런 경우에는 아래 순서로 점검하면 됩니다.
- ollama list 로 모델 설치 확인
- 관리자 계정에서 모델 보이는지 확인
- 일반 사용자 새로고침/재로그인
- Open WebUI 권한 및 노출 설정 확인
- 필요 시 Open WebUI 재기동
써보니 느낀 점 (핵심 정리)
Ollama 설치 자체는 어렵지 않았습니다. 진짜 중요한 건 설치 후 어떻게 연결해서 실제로 쓰느냐였습니다.
특히 Linux에서는 아래 3가지를 꼭 확인해야 합니다.
- Ollama가 어느 인터페이스에 바인딩되어 있는지
- Docker 컨테이너가 호스트를 어떻게 바라보는지
- Open WebUI가 실제로 어느 주소를 호출하는지
이 부분만 맞추면, 이후에는 생각보다 편하게 로컬 LLM 환경을 쓸 수 있습니다.
- 모델 비교 테스트
- 프롬프트 실험
- 백엔드 연동
- 로컬 AI 채팅 환경 구성
마무리
이번 작업의 목적은 “최고 성능의 AI 서비스”가 아니라, 클라우드 없이도 돌아가는 로컬 LLM 테스트 환경을 직접 구축해보는 것이었습니다.
Ubuntu에 Ollama를 설치하고, GTX 1080 장비에서 가볍게 모델을 실행한 뒤, Open WebUI까지 붙여 브라우저에서 테스트해보니 꽤 실용적이라는 느낌을 받았습니다.
개인 프로젝트나 초기 MVP 단계에서 “일단 클라우드 비용 없이 한 번 돌려보고 싶다”는 생각이 있다면, Ollama + Open WebUI 조합은 좋은 출발점이 될 수 있습니다.
