[클라우드] Ollama 클라우드 배포 성공 사례: AWS EC2에서 LLM 운영하기

Ollama 클라우드 배포를 고민하시는 분들이 정말 많아졌습니다. 로컬에서는 잘 돌던 LLM(Large Language Model, 대규모 언어 모델)이 팀 단위로 쓰이기 시작하면, 그다음부터는 거의 무조건 운영 이슈가 따라오거든요. 저도 처음엔 홈랩에서만 굴리다가 “이걸 외부에서 안정적으로 붙여 써야 하는데?” 하는 순간이 왔습니다. 그때 선택지가 여러 개 있었는데, 가장 먼저 손에 익는 건 역시 AWS EC2(Elastic Compute Cloud, 가상 서버)였습니다.

실제로 써보니까 Ollama는 로컬 테스트용으로만 보기엔 아까운 도구였습니다. 모델 pull, 실행, API 호출 흐름이 꽤 단순해서 진입장벽이 낮고, 작은 팀에서 내부 AI API처럼 다루기에도 괜찮더라고요. 다만 Ollama AWS 구성을 아무 생각 없이 열어두면 보안, 디스크, 프로세스 관리에서 바로 삽질하게 됩니다. 저도 초반에 포트만 열고 붙였다가 “되긴 되는데 이거 운영 맞나?” 싶은 상태를 한동안 겪었거든요.

이번 글에서는 제가 정리한 LLM 클라우드 운영 관점의 최소 구성, 실제 배포 순서, 그리고 중간에 겪었던 문제를 중심으로 풀어보겠습니다. 화려한 MLOps(Machine Learning Operations, 머신러닝 운영 자동화)까지는 아니고요. 작게 시작해서 안정적으로 굴리는 방법에 초점을 맞춰볼게요.

EC2 인스턴스, 보안 그룹, 리버스 프록시, Ollama API 흐름이 한눈에 보이는 전체 구조 이미지가 들어갈 자리입니다.

1. 왜 Ollama 클라우드 배포가 필요했나

쉽게 말해 로컬 LLM은 혼자 실험할 때는 편한데, 여러 환경에서 재사용하려고 하면 금방 한계가 보입니다. 노트북 전원을 꺼버리면 끝이고, 네트워크 경로도 들쑥날쑥하고, 로그를 남기기도 애매하죠. 특히 다음 같은 상황이면 클라우드 쪽으로 한 번은 넘어가게 됩니다.

• 사내 도구나 개인 앱에서 공통 API 엔드포인트가 필요할 때
• 로컬 PC 대신 항상 켜져 있는 서버가 필요할 때
• 모델 파일과 런타임을 한곳에서 관리하고 싶을 때
• 테스트 환경과 운영 환경을 분리하고 싶을 때

여기서 중요한 포인트! Ollama 클라우드 배포는 거대한 분산 시스템을 만드는 작업이 아닙니다. 처음엔 EC2 한 대와 제대로 잠근 네트워크, 그리고 프로세스 자동 시작만 있어도 충분합니다. 저도 처음엔 Kubernetes(쿠버네티스)까지 갈 생각을 했었는데, 솔직히 그건 너무 빨랐습니다. 먼저 단일 노드 운영 감각부터 잡는 게 훨씬 낫더라고요.

2. Ollama AWS 구성, 쉽게 말해 어떤 구조인가

Ollama는 모델을 내려받아 로컬 API로 노출하는 실행 환경에 가깝습니다. 쉽게 말해 “서버에 모델 실행기 하나 올려두고 HTTP로 호출한다” 정도로 이해하면 편합니다. 그래서 AWS에 올릴 때도 구조는 생각보다 단순합니다.

1. EC2 인스턴스를 만든다.
2. 서버에 Ollama를 설치한다.
3. 필요한 모델을 pull 한다.
4. 외부 접근은 직접 열지 말고 reverse proxy(리버스 프록시)나 VPN으로 감싼다.
5. systemd(시스템디)로 자동 시작되게 만든다.
6. 로그와 디스크 사용량을 주기적으로 본다.

제가 직접 해보니 핵심은 모델 그 자체보다 운영 경계를 어디에 두느냐였습니다. Ollama는 잘 떠도, 포트를 0.0.0.0으로 열어놓고 인증 없이 노출하면 그 순간부터는 운영이 아니라 사고 대기 상태가 되거든요.

로컬 운영과 클라우드 운영 차이

이 표만 봐도 감이 오실 겁니다. LLM 클라우드는 모델 성능 자체보다 운영 습관이 더 중요합니다.

3. AWS EC2 배포 전 설계: 인스턴스, 디스크, 네트워크

처음엔 이게 뭔가 싶었는데, 실제 배포 전에 세 가지만 정하면 이후가 편해집니다. 바로 인스턴스 유형, 스토리지 크기, 접근 방식입니다.

인스턴스 선택 기준

• 가벼운 테스트: CPU 인스턴스로 시작해도 됩니다.
• 응답 속도가 중요한 경우: GPU 인스턴스를 검토하는 편이 낫습니다.
• 동시 요청이 많은 경우: 모델 크기보다 메모리와 큐잉 전략을 먼저 봐야 합니다.

여기서 제가 한 번 삽질했던 게 디스크였습니다. 모델 파일이 생각보다 금방 쌓입니다. “일단 기본 용량으로 가자” 했다가, 모델 몇 개만 받아도 금방 답답해지더라고요. 그래서 저는 초기에 여유 있는 EBS(Elastic Block Store, 블록 스토리지)를 잡고, 나중에 모델 정리 정책을 따로 가져가는 쪽이 훨씬 낫다고 봅니다.

네트워크 접근 방식

• 가장 안전한 방식: VPN 또는 bastion host(배스천 호스트)를 통한 내부 접근
• 현실적인 절충안: Nginx(엔진엑스) reverse proxy 뒤에 두고 IP 제한 또는 인증 적용
• 비추천: Ollama 포트를 인터넷에 직접 공개

혹시 이런 경험 있으신가요? 테스트한다고 열어둔 포트가 나중에 그대로 운영이 되는 경우요. 진짜 자주 나옵니다. 그래서 시작부터 접근 레이어를 분리하는 게 좋습니다.

4. 실전 구현: AWS EC2에 Ollama 올리기

이제 실제 구성입니다. 아래 예시는 Ubuntu 계열 서버를 기준으로 정리했지만, 핵심 흐름은 다른 배포판에서도 비슷합니다. 저는 EC2 생성 후 보안 그룹에서 SSH와 프록시에 필요한 포트만 열고 시작했습니다.

1) 기본 패키지 설치

sudo apt update
sudo apt install -y curl nginx

여기서는 복잡하게 가지 않았습니다. 먼저 네트워크 진입점으로 Nginx를 두고, 그 뒤에서 Ollama를 띄우는 구조로 갔습니다.

2) Ollama 설치

curl -fsSL https://ollama.com/install.sh | sh
ollama --version

설치 후에는 버전 확인 정도만 해도 충분합니다. 굳이 여기서 세부 옵션을 많이 건드리기보다, 먼저 정상 실행부터 보는 게 좋습니다.

3) 모델 다운로드와 테스트

ollama pull llama2
ollama run llama2

모델명은 실제 운영 목적에 따라 바꾸시면 됩니다. 중요한 건 먼저 한 개 모델만 올려서 엔드투엔드로 확인하는 겁니다. 저도 처음엔 이것저것 한꺼번에 올리려다가 디스크 사용량이 꼬여서 다시 정리했었습니다.

터미널 설치 과정, 보안 그룹, 리버스 프록시 구성을 시각적으로 보여주는 이미지가 들어갈 자리입니다.

4) 외부 바인딩과 서비스 실행

환경에 따라 Ollama를 서비스로 띄우는 방식이 다를 수 있어서, 저는 systemd override로 환경 변수를 명시하는 쪽을 선호합니다.

sudo mkdir -p /etc/systemd/system/ollama.service.d
sudo tee /etc/systemd/system/ollama.service.d/override.conf > /dev/null <<'EOF'
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
EOF

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo systemctl enable ollama
sudo systemctl status ollama

OLLAMA_HOST를 열면 접근성이 좋아지는 대신 위험도 커집니다. 그래서 이 설정은 단독으로 쓰지 말고, 바로 앞단 프록시나 네트워크 제한과 같이 가져가야 합니다.

5) Nginx reverse proxy 설정

server {
    listen 80;
    server_name your-domain.example;

    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;
    }
}

도메인을 쓰지 않는다면 내부망에서만 접근하게 해도 되고요. 외부 공개가 필요하다면 TLS(전송 계층 보안)까지 반드시 올리시는 걸 권장합니다.

6) API 동작 확인

curl http://127.0.0.1:11434/api/tags

curl http://127.0.0.1:11434/api/generate \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama2",
    "prompt": "hello",
    "stream": false
  }'

이 단계에서 응답이 오면 일단 절반은 끝난 겁니다. 드디어 됐다, 싶은 순간이 여기서 오더라고요.

5. 운영 편의성 높이기: 로그, 상태 확인, 배포 습관

Ollama AWS 구성이 한 번 붙고 나면, 그다음부터는 운영 습관이 중요합니다. 저는 최소한 아래 세 가지는 꼭 챙깁니다.

1. 서비스 자동 시작 여부 확인
2. 로그 확인 루틴 만들기
3. 디스크 사용량 주기 점검

sudo systemctl is-enabled ollama
sudo journalctl -u ollama -n 100 --no-pager
df -h
ollama list

실제로 써보니까 가장 자주 보는 건 로그와 디스크였습니다. 모델 pull이 반복되거나, 테스트 모델을 안 지우고 쌓아두면 생각보다 빨리 관리 포인트가 생깁니다.

간단한 운영 체크리스트

• 사용하지 않는 모델은 주기적으로 정리하기
• 운영용과 테스트용 인스턴스 분리 고려하기
• 공개 엔드포인트라면 인증 레이어 추가하기
• CloudWatch(클라우드와치) 같은 모니터링 연동 검토하기

6. ⚠️ 실제로 겪었던 문제와 해결법

이 섹션이 아마 제일 실전적일 겁니다. 저도 처음엔 “설치 스크립트 돌리면 끝 아닌가?” 싶었는데, 운영은 늘 그 뒤가 문제더라고요.

문제 1. 외부에서 접속이 안 됨

원인 후보는 대부분 비슷합니다. 보안 그룹, 방화벽, Ollama 바인딩 주소, 프록시 설정. 저는 초반에 서비스는 떠 있는데 127.0.0.1에만 묶여 있어서 한참 헤맸습니다.

• 해결: OLLAMA_HOST 설정 확인
• 해결: EC2 보안 그룹 인바운드 규칙 재점검
• 해결: 프록시가 올바른 백엔드 주소를 보는지 확인

문제 2. 모델은 올라왔는데 응답이 너무 굼뜸

이건 제품 탓이라기보다 자원 배분 문제인 경우가 많습니다. 모델 크기와 인스턴스 성격이 안 맞으면 바로 티가 납니다. 처음엔 모델만 바꾸면 해결될 줄 알았는데, 실제로는 메모리와 디스크 I/O 영향도 꽤 크더라고요.

• 해결: 더 작은 모델로 먼저 검증
• 해결: 동시 요청 수를 낮춰서 병목 위치 확인
• 해결: 필요 시 GPU 인스턴스로 이동 검토

문제 3. 재부팅 후 서비스가 안 살아남

이거 진짜 자주 놓칩니다 ㅎㅎ 설치는 됐는데 enable을 안 했거나, override 파일 반영 전에 재시작이 꼬인 경우가 있었습니다.

• 해결: systemctl enable ollama 확인
• 해결: daemon-reload 후 재시작
• 해결: journalctl로 시작 실패 로그 확인

문제 4. 디스크가 금방 찬다

모델 파일이 커지면 금방 체감됩니다. 저도 처음엔 “테스트 모델 몇 개쯤이야” 했는데, 나중엔 정리부터 하게 되더라고요.

• 해결: 운영 모델만 남기고 정리
• 해결: EBS 여유 용량 확보
• 해결: 모델 추가 전 목적부터 정리

주의할 점은, 문제를 만날 때마다 툴을 바꾸기보다 현재 병목이 네트워크인지, 자원인지, 프로세스 관리인지 먼저 분리해서 보는 겁니다. 이 습관 하나로 삽질 시간을 꽤 줄였습니다.

7. 검증과 결과: Ollama 운영 후기

구성이 끝나면 결국 확인해야 할 건 두 가지입니다. 정상 응답과 반복 가능한 운영입니다. 저는 아래 순서로 검증했습니다.

1. 로컬에서 curl로 API 응답 확인
2. 프록시 경유 응답 확인
3. 재부팅 후 자동 시작 확인
4. 모델 목록과 로그 확인
5. 간단한 애플리케이션에서 실제 호출 테스트

curl http://your-domain.example/api/tags
sudo reboot
sudo systemctl status ollama
sudo journalctl -u ollama -n 50 --no-pager

검증이 끝난 뒤 느낀 건 분명했습니다. Ollama 클라우드 배포는 생각보다 빨리 구축할 수 있고, 운영 난이도도 폭발적으로 높지는 않습니다. 다만 “그냥 설치”와 “운영 가능한 상태” 사이에는 꽤 큰 차이가 있습니다. 제가 직접 해보니 그 차이를 만드는 건 거창한 기술보다도 보안 경계, 서비스 자동화, 디스크 관리 같은 기본기였습니다.

API 응답 성공, systemd 상태, 로그 확인 결과를 보여주는 검증용 대시보드 이미지가 들어갈 자리입니다.

이번 구성에서 얻은 체감상 장점

• 로컬 장비를 계속 켜둘 필요가 없습니다.
• 앱이나 스크립트에서 공통 엔드포인트로 붙이기 편합니다.
• 모델과 런타임을 서버 기준으로 일관되게 관리할 수 있습니다.

반대로 기억할 한계

• 큰 모델일수록 자원 계획이 중요합니다.
• 공개 운영은 반드시 보안 레이어가 필요합니다.
• 장기적으로는 모니터링과 인증 체계가 추가되어야 합니다.

8. 정리와 다음 단계

정리해보면, Ollama AWS 운영의 핵심은 복잡한 오케스트레이션이 아니라 작게 시작해서 안전하게 굴리는 것입니다. 저도 처음엔 이걸 너무 크게 생각했는데, EC2 한 대에 Ollama와 프록시를 올리고, 서비스 자동 시작과 접근 제어만 제대로 걸어도 꽤 쓸 만한 기반이 만들어지더라고요.

특히 LLM 클라우드를 처음 만지는 분이라면 아래 순서로 접근해보시면 좋겠습니다.

1. 작은 모델 하나로 API 응답부터 확인하기
2. 보안 그룹과 프록시로 외부 노출 경계 만들기
3. systemd와 로그 확인 루틴 정리하기
4. 그다음에야 GPU, 인증, 모니터링을 확장하기

다음 글에서는 Nginx 앞단에 인증을 더하는 방법이나, 여러 모델을 나눠 운영할 때 어떤 기준으로 분리하면 좋은지 다뤄볼 예정입니다. 이전 글에서 홈랩 기반 LLM 구성 이야기를 보셨다면, 이번 글은 그 연장선으로 보셔도 좋습니다.

배포 흐름, 주의사항, 검증 포인트를 한 장으로 정리한 요약 인포그래픽 이미지가 들어갈 자리입니다.

9. 자주 묻는 질문 FAQ

Q1. Ollama를 EC2에 바로 공개해도 되나요?

권장하지 않습니다. 가능은 해도, 운영 관점에서는 프록시나 내부망 제어 없이 바로 공개하는 방식은 위험합니다.

Q2. 꼭 GPU가 있어야 하나요?

아닙니다. 테스트나 가벼운 용도는 CPU 기반으로도 시작할 수 있습니다. 다만 응답 속도와 모델 크기에 따라 한계는 빨리 옵니다.

Q3. Kubernetes까지 바로 가야 하나요?

제 경험상 아닙니다. 단일 EC2에서 운영 감각을 먼저 잡는 게 훨씬 중요합니다. 저도 처음엔 큰 구조를 생각했는데, 결국 기본기가 먼저였어요.

Q4. 운영하면서 가장 먼저 볼 지표는 뭔가요?

로그, 메모리, 디스크 사용량입니다. 특히 디스크는 모델 파일 때문에 생각보다 빨리 체감됩니다.

마지막으로 한 줄 정리해보겠습니다. Ollama 운영 후기를 한마디로 말하면, “설치는 쉽고 운영은 기본기가 전부”였습니다. 이 말이 꽤 정확하더라고요.