로컬에서 모델을 돌리다 보면 어느 순간 “다른 기기에서도 쓰고 싶다”는 생각이 든다. 스마트폰 앱과 연동하거나, 같은 네트워크의 팀원에게 공유하거나, 클라우드 인스턴스에 Ollama를 올려두고 어디서든 접근하고 싶어지는 것이다. 그때 자연스럽게 찾게 되는 설정이 OLLAMA_HOST=0.0.0.0이다. 바인딩 주소를 바꾸는 것만으로 Ollama가 모든 인터페이스에서 연결을 받아들이게 된다. 그런데 이 한 줄이 생각보다 훨씬 넓은 문을 열어젖힌다.
Ollama의 기본 동작은 127.0.0.1:11434에만 바인딩하는 것이다. 로컬호스트 이외에서는 포트 자체에 닿을 수 없으니, 공격 표면이 사실상 없다. 문제는 0.0.0.0으로 바꾸는 순간 Ollama가 아무런 인증 없이 동작한다는 점이다. /api/generate, /api/chat, /api/embeddings 같은 엔드포인트는 HTTP 요청만 맞으면 누구든 쿼리를 날릴 수 있다. 그것만이 아니다. /api/pull 엔드포인트도 그대로 노출된다. 외부에서 모델 이름을 지정해 요청을 보내면, 호스트 머신이 Ollama 공식 레지스트리에서 수십 GB짜리 모델을 내려받기 시작한다. 디스크를 소진하거나, 트래픽 과금이 있는 클라우드 인스턴스라면 상당한 비용이 청구될 수 있다.
실제로 어떤 상황에서 문제가 되는가
클라우드 인스턴스에 Ollama를 설치하고 0.0.0.0으로 열어두면 사실상 포트 스캐너에 그대로 잡힌다. Shodan이나 Censys 같은 서비스는 이미 공개된 Ollama 인스턴스를 인덱싱하고 있다. 2024~2025년 사이 보안 연구자들이 수천 대에 달하는 Ollama 서버가 인증 없이 인터넷에 노출되어 있다는 보고를 내놓기도 했다. 공격자 입장에서는 GPU가 달린 서버를 무료로 빌리는 셈이다.
로컬 네트워크라고 안전한 것도 아니다. 카페나 컨퍼런스 공용 Wi-Fi에서 Ollama를 0.0.0.0으로 실행하면 같은 네트워크의 누구든 모델을 호출할 수 있다. 민감한 데이터를 프롬프트에 넣어 쓰고 있다면 그 내용이 타인의 눈에 닿을 가능성도 생긴다.
현재 Ollama는 공식적으로 API 키나 기본 인증(Basic Auth) 기능을 내장하고 있지 않다. GitHub 이슈에서 오래전부터 인증 기능 요청이 올라와 있지만, 2025년 기준으로 공식 지원은 아직 없다. 따라서 외부 접근이 필요하다면 Ollama 앞에 별도의 레이어를 두는 것이 유일한 현실적 방법이다.
안전하게 외부 접근을 허용하는 세 가지 방법
가장 범용적인 방법은 Nginx나 Caddy를 리버스 프록시로 세우고 Basic Auth를 적용하는 것이다. Caddy 기준으로 basicauth 블록에 사용자와 bcrypt 해시를 넣으면 프록시 레이어에서 인증을 처리한다. Nginx도 htpasswd로 생성한 파일을 auth_basic_user_file로 지정하면 된다. HTTPS는 Let’s Encrypt 인증서를 붙이면 되고, Caddy는 이를 자동으로 처리해 준다. 다만 Basic Auth는 비밀번호가 평문에 가까운 형태로 전송되기 때문에 반드시 TLS와 함께 사용해야 한다.
두 번째는 Tailscale을 사용하는 방법이다. Tailscale은 WireGuard 기반 메시 VPN으로, 기기 간에 사설 IP 대역을 만들어 준다. Ollama를 127.0.0.1에 바인딩한 채로 두고, Tailscale이 부여한 인터페이스(예: 100.x.x.x)에만 추가로 바인딩하면 된다. 외부 인터넷에서는 포트가 완전히 닫혀 있고, Tailscale 네트워크에 등록된 기기만 접근할 수 있다. 설정이 단순하고, 키 관리나 인증서 갱신 같은 번거로움이 없다. 개인이나 소규모 팀에게 가장 추천할 만한 방식이다.
세 번째는 SSH 포트 포워딩이다. 원격 서버에 SSH 접속이 가능하다면, ssh -L 11434:localhost:11434 user@server 명령 하나로 로컬 11434 포트를 서버의 11434로 터널링할 수 있다. Ollama는 계속 127.0.0.1에만 바인딩되어 있고, 트래픽은 암호화된 SSH 채널을 통해서만 흐른다. 일회성 접근이나 개발 중 테스트 용도라면 이것으로 충분하다. 다만 상시 연결을 유지하거나 여러 사용자에게 공유하기에는 관리가 번거롭다.
이미지 출처: Unsplash
방화벽으로 1차 방어선 세우기
어떤 방법을 택하든 방화벽 설정을 병행하는 것이 좋다. Ubuntu나 Debian 계열 서버라면 UFW로 간단히 처리된다. ufw deny 11434를 먼저 적용하고, 허용할 IP만 ufw allow from 192.168.1.0/24 to any port 11434 형식으로 추가하면 된다. macOS라면 pf(Packet Filter)를 쓸 수 있다. /etc/pf.conf에 block in proto tcp from any to any port 11434를 추가한 뒤 pfctl -f /etc/pf.conf로 적용한다. 다만 macOS 방화벽은 재부팅 시 초기화되는 경우가 있어 LaunchDaemon으로 영구 적용하는 추가 작업이 필요하다.
클라우드 인스턴스를 쓴다면 OS 레벨 방화벽보다 AWS 보안 그룹이나 GCP 방화벽 규칙을 먼저 적용하는 것이 더 확실하다. 인스턴스에 도달하기 전에 패킷을 차단하기 때문에 OS 취약점을 통한 우회도 막아준다.
Ollama 생태계는 빠르게 성장하고 있고, 커뮤니티에서도 인증 내장에 대한 요구가 꾸준히 이어지고 있다. Ollama 팀이 공식적으로 API 키나 OAuth 기반 인증을 도입한다면 외부 노출 설정이 지금보다 훨씬 단순해질 것이다. 그러나 그전까지는 리버스 프록시든 VPN이든 외부 레이어 없이 0.0.0.0으로 열어두는 선택은 피하는 것이 맞다. 로컬 LLM의 장점은 데이터가 외부로 나가지 않는다는 점인데, 포트를 열어두는 순간 그 전제가 흔들린다. 모델을 잘 고르고 잘 돌리는 것만큼, 어디서 누가 접근할 수 있는지를 통제하는 것도 운영의 일부다.
출처