왜 로컬 AI인가?
일단, API 비용이 0원이다.
AI를 몇 번이나 호출해도 요금이 나오지 않는다는 점이 가장 좋고, 두 번째가 프라이버시다. 사실 AI를 통해 넘어가서 학습되더라도 문제가 되지 않는 정보만 다루고 있긴 하지만 사적인 정보를 기반으로 질문할 때는 걱정이 되는 면도 있었다. 따라서 놀고 있는 서버에 로컬 AI를 돌려보기로 결정했다.
활용 방안
-
스마트팜 센서 데이터 분석
수경재배 포트에 ESP32와 온습도/수온/조도/수위 센서를 연결해서 실시간 데이터를 수집할 예정이다. 이 데이터를 로컬 AI가 분석해서 현재 스마트팜 상태 요약을 주기적으로 작성하는 게 목표다. -
아침 브리핑 자동화
RSS 피드로 뉴스와 받은 이메일 정보를 수집하고, 로컬 AI가 요약해서 매일 아침 브리핑을 만들어주는 자동화를 구성할 계획이다.
이외에도 단순히 대화나 반복 작업, 할인 모니터링 같이 자잘한 기능도 구현해보고 싶다.
서버 스펙
홈서버로 사용 중인 N100 미니PC 스펙이다.
| 항목 | 사양 |
|---|---|
| CPU | Intel N100 |
| RAM | 16GB |
| SSD | 512GB |
| OS | Ubuntu 24 |
MLLSE 사의 미니PC로, 알리 익스프레스에서 구매했으며 구매 당시 가격은 212,600원이었다. 이미 Immich(개인 이미지 클라우드), Obsidian 동기화용 MongoDB, 서버 관리를 위한 Portainer, Nginx Proxy Manager, Tailscale이 올라가 있는 상태다. 이 모든 서비스가 돌아가면서 메모리 사용량이 약 1.6GB 정도다.
로컬 AI를 올리기 전에 docker stats로 현황을 먼저 확인했다.
docker stats --no-streamavailable 메모리가 13GB 정도 남아있어서 충분했다.
모델 선택 — Qwen3.5 9B
로컬 AI 모델 선택이 제일 고민이었다.
선택하기에 앞서 두 가지 개념을 먼저 알아보자면,
-
파라미터(B) : B는 Billion(10억)으로 모델의 파라미터 수를 뜻한다. 파라미터는 AI가 학습하면서 만들어진 수십억 개의 숫자값으로, 쉽게 말하면 모델의 "뇌세포 연결 수"다. 파라미터 숫자가 클수록 더 똑똑하지만 메모리를 더 많이 쓴다.
-
양자화(Quantization) : 원래 파라미터 하나를 저장하는 데 32비트를 쓰는데, 이걸 4비트로 압축하면 크기가 1/8로 줄어든다. 품질이 약간 떨어지지만 일반적인 용도에서는 거의 차이를 느끼기 어렵다. Ollama에서 모델을 받을 때 일반적으로 4비트 양자화된 버전을 받아오지만, 태그를 통해 양자화 버전을 특정할 수 있다.
# 기본 (Q4_K_M 자동 선택)
ollama pull qwen3.5:9b
ollama pull qwen3.5:9b-instruct-q4_k_m
# 더 가볍게 (품질 낮아짐)
ollama pull qwen3.5:9b-instruct-q2_K
# 더 높은 품질 (메모리 더 사용)
ollama pull qwen3.5:9b-instruct-q8_0이제 나의 미니PC 성능 기준으로 현실적인 선택지를 정리하면 이렇다.
| 모델 | 용량 (Q4) | 한국어 | 코딩 | 응답 속도 | N100 적합도 |
|---|---|---|---|---|---|
| Gemma4 E2B | ~3GB(실제 7GB) | 보통 | 보통 | 빠름 | 보통 |
| Gemma4 E4B | ~5.5GB(실제 10GB 이상) | 보통 | 좋음 | 느림 | 메모리 과사용 |
| Qwen3.5 9B | ~6.6GB(실제 10GB 이상) | 좋음 | 좋음 | 매우 느림 | 메모리 과사용 |
나머지 서비스들도 메모리를 쓰고, 나중에 다른 모델도 추가할 수 있으니 여유를 남겨두는 게 좋다. Qwen3.5 9B로 결정했다. 256K 컨텍스트 윈도우를 지원하고 한국어 성능도 괜찮다.
하루 정도 지켜보며 n8n으로 자동화도 해봤다가 대화도 해봤다가 여러가지를 시도해보았는데 내 PC 성능상 Qwen3.5 9b 모델은 응답에 10분 이상 소요되어 http 통신에서는 연결이 자동으로 끊어질 정도였으며 Gemma4 E4B는 10분 이내로 응답하지만 메모리를 10GB 이상 차지했다. 내외장 GPU가 없는 환경이라 연산에서 메모리 자원을 훨씬 많이 사용한 듯 싶다.
다른 저성능 모델을 시도해보며 업데이트하겠다.
설치 — Ollama + Open WebUI
Docker Compose로 한 번에 올린다. Portainer를 쓰고 있다면 Stacks에서 바로 붙여넣기 하면 된다.
version: '3'
services:
ollama:
image: ollama/ollama
container_name: ollama
ports:
- "11434:11434"
volumes:
- ollama_data:/root/.ollama
restart: unless-stopped
open-webui:
image: ghcr.io/open-webui/open-webui:main
container_name: open-webui
ports:
- "3000:8080"
environment:
- OLLAMA_BASE_URL=http://ollama:11434
volumes:
- open_webui_data:/app/backend/data
depends_on:
- ollama
restart: unless-stopped
volumes:
ollama_data:
open_webui_data:컨테이너가 올라오면 모델을 pull한다.
docker exec ollama ollama pull qwen3.5:9b6.6GB라 다운로드에 시간이 좀 걸린다. 완료되면 브라우저에서 접속해보자.
http://서버IP:3000처음 접속하면 계정 생성 화면이 나온다. 로컬 전용이라 아무 이메일/비밀번호나 입력해도 된다. 상단에서 qwen3.5:9b를 선택하고 한국어로 말을 걸어보면 된다.
실제 써보니
확실히 클라우드 AI보다 느리다. 내 서버 컴퓨터는 GPU가 없어서 CPU로만 돌리는데, 초당 3~8 토큰 정도 나온다. 자기 소개를 시켜보니 생각에만 3분, 출력에 추가로 시간이 더 걸린다. 실제로는 4~5분만에 답변을 받았다.
많이 느리긴 하지만 특정 시간에 주기적으로 진행하는 자동화 작업은 응답이 느린 로컬 AI를 쓰더라도 괜찮을 것 같다. 센서 데이터 분석이나 예약 작업처럼 요청해두고 나중에 확인하는 용도에는 속도가 크게 문제되지 않는다.
스마트폰에서도 접근하고 싶다면 Tailscale이 이미 설치되어 있으면 간단하다. 스마트폰에 Tailscale 앱을 설치하고 같은 계정으로 로그인하면 외부에서도 http://서버IP:3000으로 접속할 수 있다.
다음 편에서는..
아침 브리핑 자동화를 먼저 구현해볼 예정이다. RSS 피드, Gmail로 정보 수집하고 n8n으로 워크 플로우를 만들어보겠다. 또 재미있는 활용 방법이 생각나면 추가하겠다.
