[OpenStack] OpenStack과 Ollama로 프라이빗 LLM 추론 환경 구축하기

OpenStack 인스턴스에 Ollama를 올려서 프라이빗 LLM 추론 환경을 만드는 이야기는 요즘 꽤 자주 나오더라고요. 저도 홈랩이랑 업무성 테스트 환경을 오가면서 이것저것 붙여봤는데, 공개 SaaS에 바로 데이터를 넣기 애매한 상황에서는 Ollama OpenStack 조합이 생각보다 실용적이었습니다. 특히 로그, 운영 문서, 내부 위키처럼 외부 반출이 조심스러운 데이터를 다룰 때는 더 그렇고요. 혹시 ‘GPU는 비싸고, 그렇다고 완전 관리형 서비스만 믿기엔 불안하다’ 같은 고민 해보신 적 있으신가요? 저는 딱 그 지점에서 이 구성을 꽤 오래 만지작거렸습니다.

이번 글은 특정 벤더 홍보가 아니라, OpenStack AI 실험을 실제 인프라 관점에서 어떻게 굴려볼 수 있는지 정리한 사례입니다. 처음엔 이게 뭔가 싶었는데, 막상 해보니 구조는 단순합니다. OpenStack 가상머신 위에 Ollama를 올리고, 모델을 내려받고, 네트워크와 스토리지, 보안그룹만 제대로 잡아주면 됩니다. 다만 여기서 중요한 포인트가 몇 개 있습니다. CPU만으로도 테스트는 되지만, 추론 속도와 동시성은 기대치를 잘 관리해야 하거든요.

OpenStack 기반 프라이빗 LLM 아키텍처를 한눈에 보여주는 개요 이미지입니다.

1. 왜 굳이 OpenStack에 Ollama를 올렸을까

쉽게 말해 Ollama는 로컬이나 서버에서 대형 언어 모델을 비교적 간단하게 실행하게 도와주는 런타임(runtime, 실행 환경)입니다. 반면 OpenStack은 가상머신, 네트워크, 볼륨 같은 인프라 자원을 묶어서 운영할 수 있게 해주는 IaaS(Infrastructure as a Service, 서비스형 인프라) 플랫폼이고요. 둘을 합치면 뭐가 좋으냐면, 프라이빗 LLM 실험 환경을 내가 통제하는 네트워크 안에서 만들 수 있습니다.

제가 직접 해보니 이 조합의 장점은 아래처럼 정리되더라고요.

• 데이터 통제: 추론 요청과 응답이 내부 네트워크에 머물 수 있습니다.
• 배포 유연성: 테스트용 인스턴스와 운영성 인스턴스를 분리하기 쉽습니다.
• 복제 가능성: 스냅샷(snapshot, 시점 복사)이나 이미지 기반으로 재현이 편합니다.
• 네트워크 제어: 보안그룹(Security Group, 가상 방화벽)과 내부망만으로 노출 범위를 제한할 수 있습니다.
• 확장 여지: 나중에 API Gateway, Reverse Proxy, 모니터링을 붙이기 좋습니다.

반대로 단점도 있습니다. Ollama 자체는 비교적 쉽게 뜨는데, 모델 파일이 크고 디스크 I/O나 메모리 조건을 꽤 타는 편입니다. 그리고 OpenStack 쪽에서 Floating IP, 내부망, 볼륨 연결, 이미지 준비 같은 기본기가 안 되어 있으면 이상하게 자꾸 삽질하게 됩니다. 저도 처음엔 애플리케이션 문제가 아니라 네트워크 정책 때문에 응답이 안 와서 한참 헤맸거든요 ㅎㅎ

2. Ollama OpenStack 구성 개념 쉽게 이해하기

이 구성을 너무 어렵게 볼 필요는 없습니다. 전체 흐름은 이렇습니다.

1. OpenStack에서 Ubuntu 계열 Linux 인스턴스를 하나 만듭니다.
2. 필요하면 Block Storage(블록 스토리지) 볼륨을 따로 붙입니다.
3. 서버에 Ollama를 설치합니다.
4. 원하는 모델을 내려받아 로드합니다.
5. 보안그룹과 Reverse Proxy(리버스 프록시, 요청 전달기)를 붙여 내부 사용자만 접근하게 합니다.
6. curl이나 간단한 앱에서 API 호출로 검증합니다.

여기서 핵심은 모델 실행 위치와 접근 제어입니다. 모델은 인스턴스 안에서 돌고, 사용자는 HTTP API로 붙습니다. 즉, AI 서비스처럼 보이지만 사실은 내부 애플리케이션 하나 더 배포하는 느낌에 가깝습니다. 그래서 인프라 엔지니어 입장에서는 웹 애플리케이션 운영하듯 접근하면 편합니다.

3. 배포 전에 체크할 현실적인 준비 사항

이 단계 무시하면 나중에 꼭 되돌아오게 됩니다. 실제로 써보니까 아래 세 가지가 제일 중요했습니다.

3-1. 컴퓨트 리소스 계획

정확한 수치는 환경마다 달라서 함부로 말하면 안 되지만, 적어도 메모리 여유는 넉넉하게 잡는 게 좋습니다. 작은 모델 테스트와 실서비스성 사용은 체감 차이가 큽니다. CPU-only 환경은 검증용으로는 괜찮아도, 응답 지연이 길어질 수 있습니다. GPU 패스스루(passthrough, 장치 직접 할당)나 vGPU를 쓰는 환경이라면 OpenStack 쪽 설정 난이도가 확 올라가니, 처음에는 CPU 기반 검증 후 확장하는 편이 안전합니다.

3-2. 스토리지 분리

모델 파일은 금방 용량을 먹습니다. 그래서 루트 디스크에 다 넣기보다 별도 볼륨을 붙여서 /var/lib/ollama 같은 경로를 분리하는 방식이 운영상 편했습니다. 백업, 확장, 재배포가 훨씬 수월하거든요.

3-3. 보안 기준

Ollama API를 외부에 바로 열어두는 건 추천하지 않습니다. 적어도 다음은 챙기세요.

• 내부망 우선 배치
• 보안그룹 최소 허용
• SSH 키 기반 로그인
• 필요 시 Nginx로 TLS 종료
• 로그와 요청 이력 점검

여기서 중요한 포인트! 프라이빗 LLM이라고 해서 자동으로 안전해지는 건 아닙니다. 외부 SaaS 대신 내부에 둔다는 의미일 뿐, 접근 제어를 대충 하면 오히려 더 위험해질 수 있습니다.

4. 실전 구현: OpenStack 인스턴스에 Ollama 설치

이제 본격적으로 해보겠습니다. 아래 예시는 Ubuntu 계열 Linux 인스턴스를 기준으로 정리했습니다. 저는 보통 먼저 인스턴스를 띄우고, 볼륨 붙이고, 방화벽부터 확인한 다음 애플리케이션을 올립니다. 순서를 바꾸면 나중에 원인 분석이 꼬이더라고요.

4-1. 보안그룹과 인스턴스 준비

필수 포트는 최소한으로만 엽니다. SSH용 22 포트, 그리고 내부 호출이 필요하면 Ollama 기본 포트로 알려진 11434를 내부 대역에만 허용하는 식이 무난합니다.

# 예시: 서버 접속 후 기본 점검
uname -a
lsblk
ip a
sudo timedatectl set-timezone Asia/Seoul

볼륨을 별도로 붙였다면 먼저 마운트합니다.

sudo mkfs.ext4 /dev/vdb
sudo mkdir -p /data/ollama
sudo mount /dev/vdb /data/ollama
sudo blkid /dev/vdb

/etc/fstab에 UUID 기준으로 등록해두면 재부팅 후에도 안정적입니다.

sudo cp /etc/fstab /etc/fstab.bak
sudo editor /etc/fstab

UUID=YOUR_VOLUME_UUID  /data/ollama  ext4  defaults,nofail  0  2

4-2. Ollama 설치

공식 설치 방식은 시점에 따라 바뀔 수 있으니 실제 배포 전에는 공식 문서를 꼭 같이 확인하시는 걸 권장합니다. 다만 큰 흐름은 비슷합니다. 서버에 패키지를 설치하고 서비스로 띄우는 구조입니다.

curl -fsSL https://ollama.com/install.sh | sh
sudo systemctl enable ollama
sudo systemctl status ollama

설치 후 서비스가 떠 있는지 먼저 확인하세요. 여기서 안 뜨면 모델 문제 보기 전에 서비스 로그부터 보는 게 맞습니다.

sudo journalctl -u ollama -n 100 --no-pager

배포 과정 중 네트워크와 스토리지, 서비스 구성을 설명하는 이미지입니다.

4-3. 데이터 경로 분리

모델 저장 경로를 별도 볼륨으로 빼고 싶다면 서비스 환경 변수를 조정하는 식으로 운영할 수 있습니다. 배포 방식에 따라 경로 정의가 다를 수 있어서 저는 서비스 오버라이드 방식으로 처리하는 편입니다.

sudo mkdir -p /data/ollama/models
sudo systemctl edit ollama

[Service]
Environment="OLLAMA_MODELS=/data/ollama/models"
Environment="OLLAMA_HOST=0.0.0.0:11434"

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo systemctl show ollama --property=Environment

여기서 OLLAMA_HOST를 0.0.0.0으로 열었다면, 네트워크 레벨에서 반드시 접근 대역을 제한하세요. 애플리케이션이 열려 있다는 건 생각보다 금방 스캔됩니다.

4-4. 모델 다운로드와 실행

모델 이름은 시점마다 추가되거나 바뀔 수 있으니, 실제 사용 시에는 현재 지원 목록을 직접 확인하셔야 합니다. 이 글에서는 특정 최신 모델명을 무리하게 적기보다, 일반적인 사용 흐름 위주로 보겠습니다.

ollama pull llama3
ollama list
ollama run llama3

제가 직접 해보니 처음 실행은 모델 준비 때문에 시간이 걸릴 수 있습니다. 이때 ‘멈췄나?’ 싶어서 여러 번 다시 치면 오히려 꼬입니다. 디스크 사용량과 네트워크 다운로드 상태를 같이 보면서 기다리는 게 낫습니다.

4-5. API 호출 테스트

Ollama는 HTTP API 기반으로 붙이기 쉬운 편입니다. 간단한 curl 테스트부터 해보면 감이 금방 옵니다.

curl http://127.0.0.1:11434/api/generate \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3",
    "prompt": "OpenStack 환경에서 프라이빗 LLM을 운영할 때 주의할 점 3가지를 설명해줘.",
    "stream": false
  }'

내부 다른 서버에서 붙일 거라면 127.0.0.1 대신 인스턴스의 프라이빗 IP를 사용하면 됩니다. 다만 이 경우 보안그룹과 OS 방화벽을 같이 확인하세요.

5. Ollama와 Reverse Proxy로 운영 편의성 높이기

실무 느낌으로 가려면 앞단에 Reverse Proxy를 두는 게 편합니다. Nginx를 붙이면 TLS 종료, 접근 경로 통합, 간단한 접근 제어가 가능하거든요. 나중에 인증 프록시나 API Gateway로 확장하기도 좋습니다.

sudo apt update
sudo apt install -y nginx

server {
    listen 80;
    server_name ollama.internal;

    location / {
        proxy_pass http://127.0.0.1:11434;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

sudo nginx -t
sudo systemctl reload nginx

여기까지 오면 내부 DNS나 /etc/hosts로 이름을 붙여서 접근하기도 편해집니다. 작은 차이 같아도 운영성은 꽤 올라갑니다. 특히 여러 추론 서버를 비교 테스트할 때요.

6. ⚠️ 실제 겪었던 문제와 트러블슈팅

이 섹션은 좀 현실적으로 적어볼게요. 저는 이 작업하면서 애플리케이션보다 인프라 쪽에서 더 많이 막혔습니다.

6-1. 포트는 열었는데 접속이 안 되는 문제

처음엔 분명 11434를 열었는데 외부에서 응답이 없었습니다. 알고 보니 셋 중 하나였습니다.

• 서비스가 127.0.0.1에만 바인딩됨
• OpenStack 보안그룹에는 열었지만 OS 방화벽이 차단
• Floating IP가 아닌 내부망 전용 인스턴스라 접근 경로 자체가 다름

해결은 단순합니다. ss -lntp, ufw status, 보안그룹 규칙을 순서대로 확인하면 됩니다.

ss -lntp | grep 11434
sudo ufw status
ip route

6-2. 디스크 공간 부족

작은 테스트 VM에서 시작했다가 모델을 몇 개만 내려받아도 금방 공간이 줄어듭니다. 이건 진짜 많이 겪는 문제예요. 루트 디스크를 아끼겠다고 너무 작게 잡으면 결국 다시 옮기게 됩니다. 그래서 초반부터 모델 저장 경로를 분리하는 걸 추천드립니다.

6-3. 응답 속도가 너무 느린 문제

이건 대부분 버그가 아니라 리소스 문제입니다. CPU 기반에서는 특히 그렇습니다. 프롬프트가 길거나 동시에 여러 요청이 들어오면 체감이 확 느려집니다. 저도 처음엔 설정이 잘못된 줄 알았는데, 실제로는 기대치를 조정해야 하는 영역이더라고요. 검증 목적과 운영 목적을 구분해서 보셔야 합니다.

6-4. 재부팅 후 경로가 꼬이는 문제

볼륨 마운트를 수동으로만 해두면 재부팅 뒤 서비스가 이상한 위치를 바라보는 경우가 있습니다. 꼭 fstab와 systemd 서비스 환경 변수를 함께 확인하세요. 이거 한 번 놓치면 ‘어제 됐는데 왜 오늘 안 되지?’ 모드 들어갑니다 ㅎㅎ

API 테스트와 프록시 구성을 검증하는 실제 운영 흐름을 보여주는 이미지입니다.

7. 검증과 결과 확인

구축이 끝났으면 이제 ‘떠 있다’가 아니라 ‘쓸 수 있다’를 확인해야 합니다. 저는 보통 아래 순서로 검증합니다.

1. 서비스 상태 확인
2. 로컬 API 호출 확인
3. 내부망 다른 서버에서 호출 확인
4. 리소스 사용량 확인
5. 로그 확인

systemctl status ollama
curl http://127.0.0.1:11434/api/tags
curl http://YOUR_PRIVATE_IP:11434/api/tags
free -h
df -h
sudo journalctl -u ollama -n 50 --no-pager

응답이 정상이고, 모델 목록이 보이고, 간단한 프롬프트가 처리되면 1차 검증은 통과입니다. 여기서 한 걸음 더 나가면 Prometheus(프로메테우스, 메트릭 수집기)나 Grafana(그라파나, 대시보드 도구) 같은 모니터링 체계를 붙이는 것도 좋습니다. 아직 이 글에서는 거기까지 깊게 다루진 않지만, 다음 글에서 OpenStack AI 운영 관점의 모니터링도 다뤄볼 예정입니다.

간단한 체크리스트도 남겨보겠습니다.

• ✅ 인스턴스 재부팅 후 서비스 자동 시작 확인
• ✅ 모델 저장 경로가 의도한 볼륨인지 확인
• ✅ 내부 대역 외 접근 차단 확인
• ✅ 테스트 프롬프트 응답 정상 확인
• ✅ 로그에 반복 오류 없는지 확인

드디어 됐다! 싶은 순간은 사실 OpenStack 인스턴스가 뜨는 순간이 아니라, 재부팅 후에도 똑같이 잘 동작할 때입니다. 이건 진짜 운영해보면 공감하실 겁니다.

구축 완료 후 상태 점검과 결과 검증을 시각적으로 보여주는 이미지입니다.

8. 어떤 환경에 특히 잘 맞는가

모든 곳에 이 구성이 정답은 아닙니다. 하지만 아래 같은 경우에는 꽤 잘 맞습니다.

사실 저는 이 구성을 ‘최종 답안’보다는 프라이빗 LLM 운영 감각을 익히는 출발점으로 봅니다. 나중에는 컨테이너 기반으로 옮기거나, 쿠버네티스 위에 올리거나, 인증 계층을 붙이거나, 모델 라우팅을 나누는 식으로 진화할 수 있거든요.

9. 정리하며: OpenStack AI 첫걸음으로는 꽤 괜찮았습니다

Ollama OpenStack 조합은 화려하진 않지만, 인프라 엔지니어 입장에서 이해하기 쉽고 제어하기 편한 방식입니다. 제가 직접 해보니 핵심은 세 가지였습니다. 리소스 계획, 스토리지 분리, 그리고 접근 제어입니다. 이 셋만 제대로 잡아도 절반은 성공입니다.

처음엔 단순히 ‘내부망에서 LLM 한 번 돌려보자’ 정도로 시작했었는데, 실제로 써보니까 운영 포인트가 꽤 명확했습니다. 특히 OpenStack을 이미 쓰고 있는 조직이라면 기존 VM 운영 경험을 그대로 가져올 수 있다는 게 큽니다. 반대로, 모델 성능 자체를 극한까지 뽑아내는 목적이라면 별도 GPU 전략과 오케스트레이션 설계가 더 필요하겠죠.

혹시 지금 AI 추론 환경을 사내에 조용히 검증해보고 싶으셨다면, 이 방식부터 시작해보셔도 좋겠습니다. 이전 글에서 다뤘던 스토리지와 네트워크 기본기와도 연결되는 내용이고, 다음 글에서는 인증 프록시를 붙여 여러 팀이 함께 쓰는 형태까지 이어서 정리해보겠습니다. 여기서 중요한 포인트는 거창한 아키텍처보다, 작게 시작해서 반복 가능하게 만드는 것입니다. 그게 결국 오래 가더라고요. 🎉

구축 절차와 운영 체크포인트를 한 장으로 정리한 요약 이미지입니다.