저는 둘 다 매일 씁니다. Ollama는 제 노트북과 사무실 GPU 워크스테이션에서 개발용으로, 그리고 제가 쓰는 도구용으로 돌아갑니다. vLLM은 프리랜스 프로젝트에서 96 GB GPU 한 장으로 채팅 모델을 서빙하는데, 처음엔 Docker Compose로 띄웠고 지금은 작은 Kubernetes 클러스터에서 돌립니다. 이 글에서는 각각 무엇을 잘하는지, 어떻게 설치하는지, 그리고 vLLM 쪽에서 시간을 잡아먹은 것들을 다룹니다.

vLLM vs Ollama 한눈에 비교

#

Ollama란?

#

Ollama는 제가 아는 한 내 기계에서 모델이 답하게 만드는 가장 쉬운 방법입니다. llama.cpp에서 출발했고 양자화된 GGUF 모델을 돌리는데, 그래서 8B 모델이 5 GB 정도에 들어가고 MacBook에서도 무리 없이 돌아갑니다. 모델을 이름으로 받아 두면 처음 호출할 때 로드되고, 5분 동안 할 일이 없으면 메모리에서 내려갑니다. 덕분에 같은 기계에서 돌고 있는 다른 것들과 얌전하게 자원을 나눠 씁니다.

그 얌전함이 곧 트레이드오프입니다. Ollama는 한 번에 한 사람이 쓰는 걸 전제로 만들어졌습니다. 몇 개의 요청에 병렬로 답할 수는 있지만 병렬 슬롯마다 메모리가 들고, 수십 명의 사용자를 GPU 한 장에 배치로 몰아넣으라고 만든 물건은 애초에 아닙니다.

vLLM이란?

#

vLLM은 서빙 엔진이고, 바로 그 배칭을 위해 만들어졌습니다. 핵심 아이디어는 두 가지입니다. PagedAttention은 요청마다의 KV 캐시(모델이 토큰을 읽고 쓰면서 쌓아 가는 어텐션 상태)를 작은 고정 크기 블록에 나눠 저장해서, GPU 메모리가 패딩과 단편화로 버려지지 않게 합니다. 연속 배칭은 새 요청이 지금 배치가 끝나기를 기다리지 않고 생성 단계 사이사이에 배치에 끼어들게 해 줍니다. 이 둘 덕분에 vLLM을 돌리는 GPU 한 장은, 같은 GPU가 요청을 하나씩 처리할 때보다 훨씬 많은 동시 사용자를 감당합니다.

대가는 vLLM이 카드를 자기 것처럼 쓴다는 점입니다. 시작할 때 GPU 메모리에서 자기 몫을 차지하고, 가중치가 쓰고 남은 공간은 KV 캐시로 채우고, 호출하는 사람이 있든 없든 그 전부를 쥐고 있습니다. 모델도 Ollama가 쓰는 GGUF 파일이 아니라 Hugging Face 원본 가중치나 FP8 같은 GPU 친화적인 양자화를 원합니다.

API는 하나, 서버는 둘

#

둘 다 OpenAI chat completions API를 제공하기 때문에, 제 코드는 자기가 어느 쪽과 이야기하고 있는지 모릅니다. URL과 모델 이름은 환경 변수에서 가져옵니다.

import os
from openai import OpenAI

# 노트북:   LLM_URL=http://localhost:11434/v1  LLM_MODEL=qwen3:8b
# GPU 서버: LLM_URL=http://localhost:8000/v1   LLM_MODEL=qwen3-8b
client = OpenAI(base_url=os.environ["LLM_URL"], api_key="not-needed")

reply = client.chat.completions.create(
    model=os.environ["LLM_MODEL"],
    messages=[{"role": "user", "content": "Say hello in Korean."}],
)
print(reply.choices[0].message.content)

큰 GPU가 없는 제 노트북에서는 앱이 Ollama를 가리킵니다. 서버에서는 vLLM을 가리킵니다. 그 밖에는 아무것도 바뀌지 않고, GPU 머신을 아예 켜지 않고도 앱을 개발할 수 있습니다. vLLM 쪽에서는 --served-model-name으로 모델에 짧은 이름을 붙여 두면, 클라이언트가 Hugging Face 전체 경로를 보낼 필요가 없습니다.

잊기 쉬운 거라 하나 짚어 두겠습니다. 같은 모델이라도 두 서버에서 같은 답을 내지는 않습니다. Ollama의 qwen3:8b는 4비트 양자화본이고, vLLM에서는 보통 16비트나 FP8 가중치를 돌립니다. 한쪽에 맞춰 다듬은 프롬프트가 다른 쪽에서는 다르게 동작할 수 있으니, 답변 품질이든 거절이든 JSON이 제대로 파싱되는지든, 측정하는 게 무엇이든 프로덕션이 실제로 쓸 서버에서 확인해야 합니다.

Ollama 설치 방법

#

Mac이나 Windows에서는 ollama.com에서 앱을 내려받으면 됩니다. Linux에서는 이렇게 합니다.

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:8b

이게 전부입니다. 이제 API는 http://localhost:11434에 떠 있고, OLLAMA_HOST를 설정하지 않는 한 localhost에서만 듣습니다. 바라던 그대로죠. 제 것은 사무실 워크스테이션에서 127.0.0.1에 바인딩해 두고, 어디서든 터널로 접속합니다(Cloudflare WARP로 이걸 구성한 방법).

vLLM 설치 방법

#

NVIDIA GPU와 최신 드라이버를 갖춘 Linux에서는 이렇게 합니다.

python -m venv .venv && source .venv/bin/activate
pip install vllm
vllm serve Qwen/Qwen3-8B --served-model-name qwen3-8b --max-model-len 16384

첫 실행 때 Hugging Face에서 가중치를 내려받습니다. 로그에 Application startup complete가 찍히면 curl localhost:8000/v1/models가 모델을 보여 주고, 위의 Python 코드도 그대로 동작합니다.

Docker로 vLLM 띄우기

#

계속 떠 있어야 하는 서비스라면 pip 설치 대신 공식 이미지를 씁니다. 주된 이유는 CUDA, PyTorch, vLLM이 서로 맞는 버전으로 묶여서 오기 때문입니다. 범용 Compose 서비스는 이렇습니다.

services:
  vllm:
    image: vllm/vllm-openai:v0.30.0   # 태그를 고정할 것. 이미지는 약 30 GB
    restart: unless-stopped
    ipc: host                          # PyTorch에 공유 메모리가 필요함
    command: >
      --model Qwen/Qwen3-8B
      --served-model-name qwen3-8b
      --gpu-memory-utilization 0.85
      --max-model-len 16384
    volumes:
      - ${HOME}/.cache/huggingface:/root/.cache/huggingface
    ports:
      - "127.0.0.1:8000:8000"          # LAN이 아니라 ssh -L로 접속
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    healthcheck:
      test: ["CMD", "python3", "-c", "import urllib.request; urllib.request.urlopen('http://localhost:8000/health')"]
      interval: 10s
      timeout: 5s
      retries: 90
      start_period: 120s

태그는 고정하세요. vLLM은 빠르게 바뀌고 릴리스마다 플래그와 기본값이 달라지니, 그 변화를 언제 받아들일지는 내가 정해야 합니다. ipc: host(또는 넉넉한 shm_size)는 vLLM의 공식 Docker 안내에도 나와 있습니다. 긴 start_period는 아래에 나올 문제들 중 첫 번째 때문입니다.

vLLM 운영하면서 발목 잡힌 것들

#

시작하는 데 몇 분이 걸립니다. 가중치 로드, 컴파일, CUDA 그래프 캡처까지 제 서버에서 190초가 걸렸고, 큰 모델이라면 3~5분이 보통입니다. 웹 앱에 맞춰 짠 헬스 체크는 준비가 끝나기도 전에 vLLM을 죽여 버립니다. Compose에서는 긴 start_period가, Kubernetes에서는 startup probe가 필요하다는 뜻입니다. 재시작할 때마다 몇 분씩 모델이 없는 상태가 된다는 뜻이기도 하니, 재시작을 가볍게 하면 안 됩니다.

GPU 메모리는 시작할 때 준 만큼 가져갑니다. --gpu-memory-utilization은 vLLM이 쓸 수 있는 카드의 비율로 최근 버전의 기본값은 0.92이고, 가중치가 쓰고 남은 공간은 KV 캐시가 됩니다. vLLM이 카드를 혼자 쓴다면 문제없습니다. 제 경우는 옆에서 작은 모델들이 같이 돌아서 혼자가 아니라, 96 GB 카드에 0.70을 줬습니다. 모델은 FP8로 된 35B MoE(mixture-of-experts)였는데, 로드하고 나니 47.7 GiB를 차지했고 KV 캐시로 15 GiB가 남았습니다. 16k 컨텍스트라면 넉넉한 양이죠. 최대 시퀀스 길이가 KV 캐시에 들어가지 않는다며 vLLM이 시작을 거부하면, 더 큰 GPU를 찾아보기 전에 --max-model-len부터 낮춰 보세요.

LoRA 슬롯은 메모리를 미리 잡아 둡니다. vLLM은 베이스 모델 하나에 LoRA 어댑터 여러 개를 얹어 서빙하고, 요청마다 모델 이름으로 어댑터를 바꿀 수 있습니다. Ollama로는 사실상 못 하는 일이죠. 그런데 시작할 때 --max-lora-rank 기준으로 --max-loras개만큼 어댑터 자리를 예약하고, MoE 모델에서는 그 예약이 전문가(expert)들까지 덮기 때문에 금방 불어납니다. 0.70에서 랭크 64 어댑터 네 개는 들어가지 않았습니다. 두 개는 들어갔습니다.

기본 시퀀스 한도가 하이브리드 모델과 맞지 않았습니다. 제가 서빙하는 모델은 어텐션 사이에 Mamba 계열 레이어가 섞여 있고, 시퀀스마다 그 레이어용 캐시 블록이 따로 필요합니다. 그 카드에서 vLLM 기본 --max-num-seqs로는 시작에 실패했고, --max-num-seqs 256으로 해결됐습니다. 새로운 아키텍처의 모델이 뜨지 않는다면, 더 특이한 원인을 찾기 전에 이 플래그부터 확인해 보세요.

vllm이라는 이름의 Kubernetes Service가 vLLM을 죽입니다. 개인적으로 제일 마음에 드는 문제입니다. Kubernetes는 네임스페이스 안의 모든 Service에 대해 그 Service 이름을 딴 환경 변수를 주입합니다. 그래서 vllm이라는 Service가 있으면 모든 pod에 VLLM_PORT=tcp://<cluster-ip>:8000이 들어갑니다. vLLM은 VLLM_PORT를 자기 설정 중 하나로 읽는데, 거기 URL이 들어 있으니 해석하지 못하고 죽었습니다. 그것도 당연히 모델을 전부 로드한 다음에요. 그래서 시도할 때마다 3분씩 날아갔습니다. vLLM 문서에 이 경고가 있다는 건 나중에야 알았습니다. 해결책은 pod에 enableServiceLinks: false를 주거나, Service 이름을 다르게 짓는 것입니다.

동작하는 Deployment의 뼈대를 중요한 부분만 남겨 옮기면 이렇습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm
spec:
  replicas: 1
  strategy:
    type: Recreate               # 이전 pod가 먼저 GPU를 놓아야 함
  selector:
    matchLabels: {app: vllm}
  template:
    metadata:
      labels: {app: vllm}
    spec:
      enableServiceLinks: false  # Service가 넣는 VLLM_PORT=tcp://... 막기
      containers:
        - name: vllm
          image: vllm/vllm-openai:v0.30.0
          args: ["--model=Qwen/Qwen3-8B", "--served-model-name=qwen3-8b"]
          resources:
            limits:
              nvidia.com/gpu: "1"
              memory: 32Gi       # 로드할 때는 서빙할 때보다 호스트 RAM이 훨씬 많이 듦
          volumeMounts:
            - {name: shm, mountPath: /dev/shm}
          startupProbe:          # 모델이 다 올라오기 전에는 판정하지 않음
            httpGet: {path: /health, port: 8000}
            initialDelaySeconds: 120
            periodSeconds: 10
            failureThreshold: 90
          livenessProbe:         # 재시작은 곧 전체 재로드이니 느긋하게
            httpGet: {path: /health, port: 8000}
            periodSeconds: 30
            timeoutSeconds: 5
            failureThreshold: 10
      volumes:
        - name: shm
          emptyDir: {medium: Memory, sizeLimit: 16Gi}

가져다 쓸 만한 건 probe 부분입니다. startup probe는 2분을 기다린 다음, 모델이 올라올 때까지 15분을 더 주고 나서야 Kubernetes가 죽었다고 판단하게 합니다. liveness probe는 5분쯤 실패가 이어져야 재시작합니다. 바쁜 엔진에서는 /health 응답이 느릴 수 있고, 어차피 재시작하면 전체를 다시 로드해야 하니까요. GPU가 한 장일 때는 Recreate가 중요합니다. 롤링 업데이트는 새 pod를 먼저 띄우는데, 그 pod는 이전 pod가 아직 쥐고 있는 GPU를 기다리며 마냥 서 있게 됩니다. 메모리 제한이 넉넉해 보인다면, 실제로 넉넉하게 잡은 겁니다. 가중치가 GPU에 올라가고 나면 호스트 RAM은 7 GiB 정도에서 안정되지만, 로드하는 동안에는 그보다 훨씬 많이 필요합니다.

Ollama 쓸 때 알아 둘 것

#

놀랄 일은 적습니다. 대체로 하는 일 자체가 적어서죠.

한동안 조용하다가 들어온 첫 요청은 느립니다. 모델이 내려가 있어서 다시 로드해야 하기 때문입니다. OLLAMA_KEEP_ALIVE는 마지막 요청 이후 모델이 메모리에 머무는 시간을 정합니다. 그 멈칫거림이 거슬리면 값을 늘리고, 다른 일을 하지 않는 기계라면 -1로 두세요.

컨텍스트 윈도우는 GPU 메모리가 얼마나 있느냐에 따라 달라집니다. 24 GiB 미만이면 Ollama의 기본값은 4k 토큰으로, 대부분의 모델이 지원하는 길이보다 한참 짧습니다. 게다가 들어가지 않는 프롬프트는 거부되지 않고 조용히 잘립니다. 긴 프롬프트의 앞부분을 답변이 무시하는 것 같다면, OLLAMA_CONTEXT_LENGTH(또는 요청별 num_ctx)를 실제로 필요한 만큼 설정하세요.

원격 Ollama를 노트북으로 포워딩한다면 11434에 두지 마세요. Ollama의 기본 포트라서, 로컬 Ollama가 한 번이라도 뜨면 둘이 그 포트를 두고 경쟁하고, 모르는 사이에 엉뚱한 쪽과 이야기하고 있을 수 있습니다. 저는 11435로 포워딩합니다.

그리고 Ollama는 다중 사용자 서버가 아닙니다. 몇 명이 쓰는 내부 도구라면 괜찮습니다. 진짜 동시 요청이 몰리기 시작하면, 그때가 vLLM으로 옮길 시점입니다.

GPU 메모리는 얼마나 필요할까

#

가중치만 놓고 본 대략적인 크기입니다.

16비트에서는 파라미터당 약 2바이트, 8비트에서는 1바이트, Q4_K_M에서는 0.5바이트를 조금 넘습니다. 가중치 위에 KV 캐시가 더해지는데, 이건 컨텍스트 길이와 동시에 처리 중인 요청 수에 따라 커집니다. 같은 모델이라도 vLLM으로 50명을 서빙할 때가 Ollama로 나 혼자 쓸 때보다 메모리가 훨씬 많이 드는 건 이 두 번째 부분 때문입니다.

어느 쪽을 쓸까

#

내 기계에서 모델을 돌리고 싶은 거라면 Ollama를 설치하고 거기서 멈추세요. 10분이면 답하는 모델이 생깁니다. GPU 서버가 있고 하루 종일 호출할 사용자나 앱이 있다면 vLLM을 쓰고, 느린 시작과 잡아먹는 메모리를 받아들이고, probe를 제대로 잡으세요. 결국 둘 다 쓰게 되는 경우도 많은데, 저도 그렇습니다. 코드를 쓰는 곳에는 Ollama, 요청이 도착하는 곳에는 vLLM.

다른 선택지도 있습니다. SGLang이 vLLM의 대안으로 흔히 꼽히지만 프로덕션에서 돌려 본 적이 없어서, 짐작으로 쓰느니 빼 두었습니다. 그리고 모델이 폰에서 돌아야 한다면 다시 llama.cpp인데, 이건 React Native에서 LLM을 온디바이스로 돌리기에 썼습니다.

제 작업 환경은 좀처럼 한곳에 모이지 않는 기계 세 대입니다. 어디든 들고 다니는 MacBook Air가 있습니다. 사무실에는 devbox라는 워크스테이션이 있는데, 제대로 된 GPU가 달려 있고 Ollama, 파인튜닝 도구, 자체 컨테이너 레지스트리를 갖춘 작은 Kubernetes 클러스터, 그리고 긴 작업을 붙잡고 씨름하도록 놔둔 에이전트가 무엇이든 돌아갑니다. 그리고 폰이 있습니다. 제가 만드는 앱이 실제로 쓰이는 곳이고, 하루 대부분을 wifi가 아니라 모바일 데이터로 보내죠.

오랫동안 이 셋은 서로 제대로 이야기하지 못했습니다. 노트북은 사무실 LAN에 있을 때만 devbox에 닿았고 그 밖에서는 못 닿았습니다. 폰은 노트북과 같은 wifi에 있을 때만 노트북의 dev 서버에 닿았고, 그것도 제가 0.0.0.0에 바인딩하는 걸 잊지 않고 그날 아침 DHCP가 Mac에 준 주소를 직접 쳐 넣었을 때 얘기였습니다. 워크스테이션에서 재미있는 건 전부, 그러니까 Ollama API, 클러스터 대시보드, 트레이스, 레지스트리는 일부러 localhost나 클러스터 네트워크에 바인딩돼 있었습니다. 어느 것도 인터넷에 있을 물건이 아니니까요.

이 글은 Cloudflare WARP와 Cloudflare Tunnel 한 쌍으로 이것들을 어떻게 이었는지, 그게 AI 기능과 모바일 앱을 만드는 방식을 어떻게 바꿨는지, 그리고 저한테 말도 없이 고장 난 몇 가지에 대한 이야기입니다.

제가 실제로 원한 것

#

요구사항으로 적으면 짧습니다.

1. 노트북은 씬 클라이언트여야 합니다. GPU나 많은 RAM, 몇 시간의 실행 시간이 필요한 일은 전부 devbox에서 돌아야 하고, 노트북은 사무실에서든 집에서든 카페에서든 똑같은 방식으로 거기에 닿아야 합니다.
2. 폰은 어디서든, 모바일 데이터로, 켜고 끄는 걸 기억해야 하는 VPN 없이 제 dev 서버와 셸에 닿아야 합니다.
3. 시스템이 어떻게 돌아가는지 보는 데 쓰는 것들, 즉 대시보드, 트레이스, docker info, 모델 목록은 저만 닿을 수 있어야 하고, 공개 URL을 절대 가져서는 안 됩니다.
4. 인바운드 포트는 없습니다. 사무실 라우터에도, 집 라우터에도, 어디에도요.

네 번째 요구사항이 예전의 답, 즉 포트 포워딩과 동적 DNS 이름을 배제합니다. 잔재주도 상당수 배제되죠. devbox와 노트북 둘 다 제가 통제하지 못하는 NAT 뒤에 있고, 노트북은 몇 시간마다 다른 NAT 뒤에 있습니다.

이전: SSH 터널 저장소

#

첫 버전은 제가 직접 만든 작은 저장소였고, 지금도 바닥층으로 남아 있습니다. 노트북에서 “SSH로 닿는 것들에 깔끔한 이름 붙이기” 문제만 풀고, 그 이상은 하지 않습니다. dnsmasq가 *.test에 127.0.0.1로 답하고, Caddy가 호스트명에 따라 로컬 포트로 라우팅하면서 tls internal로 브라우저를 만족시키고, autossh launch agent 묶음이 SSH 포워드를 열어 두었다가 끊기면 다시 잇습니다. 호스트명이 그 물건이 어디 사는지 말해 줍니다.

그래서 https://devbox-ollama.ssh.test/api/tags는 워크스테이션의 모델 목록을 보여 주고, https://api.local.test는 제 기계에서 도는, 지금 작업 중인 앱의 API입니다.

.ssh나 .cloud 같은 새 최상위 이름이 아니라 .test의 서브도메인이고, .local도 아닙니다. RFC 6761이 바로 이런 용도로 .test를 예약해 두었고, .local은 mDNS 몫입니다. 그걸 가로채면 Mac에서 Bonjour 탐색이 멈춥니다. dnsmasq가 이미 *.test 전체를 와일드카드로 잡고 있으니 라벨 하나 더 붙이는 데 드는 비용은 없습니다. 127.0.0.1을 가리키는 /etc/resolver/test 파일 하나면 되고, 그 뒤로 DNS를 더 건드릴 일은 영영 없습니다.

존재하지 않는 이름에 HTTPS 붙이기

#

저 이름들은 전부 브라우저가 신뢰하는 인증서로 HTTPS 서비스됩니다. 제 노트북에만 존재하는 호스트명에 그게 된다니 불가능하게 들리죠. Caddy는 자체 내부 인증 기관으로 이걸 해냅니다. 사이트에 tls internal을 넣으면 Caddy는 Let’s Encrypt에 요청하는 대신 로컬 CA에서 그 사이트의 인증서를 발급하고, 설치 스크립트가 한 번 실행하는 caddy trust가 그 CA의 루트를 macOS 시스템 키체인(Chrome과 Safari가 읽는 곳)과 Firefox 자체 저장소에 넣습니다. 그다음부터 https://anything.test는 인증서 경고 없이 열리고, 평범한 http://는 그쪽으로 리다이렉트되며, 아무것도 기계 밖으로 나가지 않습니다.

겉모양만의 문제가 아닙니다. 요즘 웹 플랫폼의 상당 부분이 평범한 HTTP에서는 동작을 거부합니다. secure 쿠키, 서비스 워커, 클립보드 API, SameSite=None이 들어간 모든 것이요. 웹 빌드를 평범한 http://localhost에서 테스트하면 실제 HTTPS 도메인에서 나타날 버그가 가려집니다. https://app.local.test에서 테스트하면 그 버그가 제 노트북에서 대신 드러납니다.

사이트 블록 하나입니다. 포트만 빼면 모든 서비스가 똑같습니다.

devbox-ollama.ssh.test, devbox-ollama.test {
	tls internal
	import cors
	reverse_proxy 127.0.0.1:11435 {
		import proxyhdr
		transport http {
			keepalive off
			dial_timeout 5s
		}
	}
}

손이 많이 가는 부분은 두 스니펫이 맡습니다. cors는 *를 보내는 대신 호출한 쪽의 Origin을 그대로 돌려줍니다. 자격 증명이 끼는 순간 *는 허용되지 않기 때문입니다. 그리고 OPTIONS 프리플라이트에는 직접 204로 답해서 업스트림이 신경 쓸 필요가 없게 합니다. proxyhdr는 Host 헤더를 다이얼 주소로 바꿔 씁니다. 라우터 관리 페이지나 Chrome의 원격 디버깅 엔드포인트 같은 까다로운 백엔드는 Host를 검사하는데, 이게 없으면 devbox-ollama.ssh.test를 처음 듣는 이름이라며 거부합니다. Ollama의 자체 origin 검사는 포트와 상관없이 루프백을 받아 주니, Host를 127.0.0.1:11435로 바꿔 쓰면 통과합니다.

keepalive off는 제가 틀렸을 법한 부분입니다. 업스트림은 네트워크가 바뀔 때마다 autossh가 허물고 다시 세우는 SSH 포워드입니다. keep-alive가 켜져 있으면 Caddy는 이미 죽은 터널에 대한 풀링된 연결을 쥐고 있다가, 리로드할 때까지 영문 모를 404를 돌려줍니다. 끄면 요청마다 새로 다이얼하는데, 루프백에서는 측정할 만한 비용이 없습니다.

각 서비스는 예전의 평평한 이름(devbox-ollama.test)으로도 답하기 때문에, 접미사 체계 이전의 북마크도 여전히 동작합니다.

메뉴 막대

#

launchd가 포워드 십여 개를 열어 두고 있으니 제가 계속 던진 질문은 “살아 있나?“였고, 그 답은 세 군데에 흩어져 있었습니다. launchctl list, lsof, 그리고 curl. 그래서 작은 메뉴 막대 플러그인으로 한곳에 모았습니다. 호스트명마다 옆에 점이 하나씩 붙습니다.

• 🟢 서비스가 터널을 통한 요청에 답했습니다
• 🟡 터널은 열려 있지만 그 뒤의 서비스가 조용합니다
• 🔴 로컬 포트에서 아무것도 듣고 있지 않으니, 터널 자체가 죽었습니다

쓸모 있는 건 노란색입니다. 초록/빨강 검사로는 “SSH 포워드가 죽었다"와 “반대편에서 Ollama가 뻗었다"를 구분할 수 없고, 둘은 고치는 방법이 전혀 다릅니다. 플러그인은 자체 서비스 목록을 따로 두지 않고 다른 것들과 같은 프록시 설정과 SSH 설정을 읽으니, 거기에 서비스를 추가하면 메뉴에도 추가됩니다.

첫 버전은 욕심이 과했습니다. 10초마다 새로 고치면서 서비스마다 프로세스를 몇 개씩 띄워 한 번 돌 때 70개쯤 됐고, macOS는 곧바로 이 플러그인을 “에너지를 많이 사용하는 앱"에 올렸죠. 한 번 돌 때 스냅샷을 한 번만 뜨고 몇 분 간격으로 새로 고치게 바꾸니 코어 하나의 0.1% 정도로 내려왔습니다. 배터리를 갉아먹는 상태 표시는 도움이 안 되니, 처음부터 비용을 따져 둘 만합니다.

구멍이 하나 있었는데, 하필 중요한 구멍이었습니다. devbox에는 공개 이름이 없습니다. 그 SSH 포워드는 192.168.x 주소로 다이얼했으니, 노트북이 사무실 LAN에 있을 때만 동작했습니다. 사무실을 벗어나면 메뉴 막대가 빨개진 채로 그대로였고, 노트북을 아끼려고 워크스테이션으로 옮겨 둔 모든 것이 정확히 제가 그 옆에 앉아 있지 않을 때 닿지 않았습니다.

방향을 제대로 잡은 터널 두 개

#

해결책은 세 부분이고, 앞의 둘이 Cloudflare Tunnel입니다.

Cloudflare Tunnel은 cloudflared가 Cloudflare 엣지로 아웃바운드 연결을 붙잡고 있는 것입니다. Cloudflare는 그 연결로 요청을 내려보내니, NAT가 몇 겹이든 그 뒤의 기계가 라우터에서 아무것도 듣지 않고도 닿을 수 있게 됩니다. 노트북을 따라 호텔 wifi로 가고, CGNAT에서도 살아남습니다.

저는 기계마다 하나씩 두 개를 돌리는데, 그 이유는 한 문장 들일 만합니다. 뻔한 지름길은 노트북에 터널 하나를 두고, 사무실 LAN에 있는 devbox의 SSH 포트를 가리키는 ingress 규칙을 하나 더 넣는 것이었습니다. 그러면 devbox에는 아무것도 설치할 필요가 없습니다. 대신 노트북을 거쳐 라우팅되는데, 노트북은 사무실을 떠나는 기계입니다. 고치려던 바로 그 상황에서 고장 났을 겁니다. devbox는 제자리에 있으니, devbox가 엣지로 가는 자기 연결을 쥡니다.

# config.yml on devbox (runs as a systemd service)
protocol: auto        # prefer QUIC, fall back to HTTP/2 over TCP 443
ha-connections: 4     # mains-powered, its job is to stay reachable

warp-routing:
  connectTimeout: 5s

ingress:
  - hostname: ssh-devbox.example.com
    service: tcp://127.0.0.1:22
  - service: http_status:404

ssh://가 아니라 tcp://라는 건 헷갈리기 쉬운 부분입니다. ssh://는 Cloudflare의 브라우저 렌더링 터미널을 선택하는데, 이건 스트림을 웹 페이지용으로 감쌉니다. 평범한 ssh 클라이언트를 거기로 통과시키면 배너까지는 받고 키 교환에서 죽습니다. tcp://는 cloudflared access ssh가 기대하는 평범한 바이트 파이프이고, 덤으로 scp, rsync, SSH 위의 git, 포트 포워드까지 실어 나릅니다.

그 마지막 부분이 SSH 계층의 구멍을 막았습니다. 이제 SSH 설정이 연결마다 경로를 고릅니다.

Match originalhost devbox !exec "nc -z -G 1 <office-lan-ip> 22 >/dev/null 2>&1"
    ProxyCommand cloudflared access ssh --hostname ssh-devbox.example.com ...

사무실 LAN에서는 탐침이 성공하고 SSH가 한 홉으로 직접 갑니다. 그 밖의 어디서든 탐침이 실패하고 SSH는 Cloudflare를 거치는데, Access 서비스 토큰으로 인증하니 브라우저 로그인이 끼어들지 않습니다. Match host가 아니라 Match originalhost입니다. host는 HostName이 치환된 뒤에 매칭되니, 그 시점엔 이름이 이미 IP라서 블록이 절대 발동하지 않습니다. 결과적으로 devbox-ollama.ssh.test가 사무실에서도, 집에서도, 기차에서도 동작하고, 메뉴 막대의 점은 초록으로 남습니다.

노트북의 터널은 반대 방향으로 갑니다. Mac의 dev 서버에 진짜 공개 HTTPS 호스트명을 줍니다. 작업 중인 앱마다 API, WebSocket 서버, 웹 빌드요. 전부 Cloudflare Access 뒤에 있는데, 이건 뒤에서 다시 다루겠습니다. 이걸 무모한 게 아니라 안전한 것으로 만드는 부분이니까요.

메뉴 막대도 두 터널을 알게 됐는데, 탐침으로는 할 수 없었습니다. 인바운드 터널에는 확인할 로컬 포트가 없고, 커넥터 둘 중 하나는 노트북에서 돌지도 않으며, 뻔한 테스트인 ssh-devbox.example.com에 curl 날리기는 커넥터가 붙어 있든 말든 Cloudflare 엣지가 답하니, 죽은 터널에서도 초록으로 읽힐 겁니다. launchd도 나을 게 없습니다. cloudflared는 엣지 연결이 전부 끊긴 채로 “loaded, exit 0” 상태로 앉아 있거든요. 그래서 터널 상태는 각 터널에 건강한 커넥터가 붙어 있는지 Cloudflare API에 물어서 확인합니다. ssh가 닿을지를 결정하는 게 바로 그쪽이니까요. API에 닿지 못하면 빨갛게 그리지 않고 그 부분을 통째로 뺍니다. 메뉴는 힐끗 보고 읽는 것이라, 거기서 잘못된 경보는 빠진 한 줄보다 비쌉니다.

세 번째 부분: WARP가 이걸 네트워크로 만듭니다

#

호스트명이 붙은 터널은 HTTPS로 말하는 것, 그리고 cloudflared를 돌릴 수 있는 기계에서의 SSH에는 훌륭합니다. 폰은 못 돌립니다. 게다가 터널 호스트명은 TCP 엔드포인트가 아닙니다. Cloudflare 엣지는 거기서 HTTPS와 WebSocket만 종단하니, ssh.example.com의 22번 포트는 닫혀 있고 Access를 아무리 만지작거려도 열리지 않습니다.

그게 WARP의 일입니다. Cloudflare One Agent(엔터프라이즈용 WARP 클라이언트입니다. 조직에 가입할 수 없는 일반 소비자용 “1.1.1.1” 앱이 아니고요)를 노트북과 폰에 설치해 제 Zero Trust 조직에 등록했습니다. 각 터널이 사설 경로를 광고하면, WARP를 돌리는 기기는 그 주소로 평범한 소켓을 열어 올바른 기계에 닿을 수 있습니다. “이 서비스에 이름으로 닿기"가 아니라 “이 기계들이 나와 같은 네트워크에 있다"가 되는 거죠.

이 주소들은 부팅 때 만들어지는 각 기계의 루프백 별칭이라, DHCP나 제가 어떤 라우터 뒤에 있는지와 아무 상관이 없습니다. 198.18.42.2는 사무실에서도, 집에서도, 5G에 붙은 폰에서도 devbox입니다. Mac의 진짜 LAN 주소는 옮길 때마다 바뀌지만, 이 주소는 절대 바뀌지 않습니다.

스플릿 터널은 include 모드이고, 저 경로들(과 WARP가 스스로 쓰는 Cloudflare 대역)만 들어 있습니다. 이게 클라이언트를 켜 두고 살 수 있게 만드는 부분입니다. 기본값은 exclude 모드인데, WARP가 사설 대역 목록을 뺀 모든 것을 실어 나르니 폰이 보내는 모든 바이트가 Cloudflare를 돌아갑니다. 배터리와 지연 시간 비용이 실제로 있고, 결국 필요할 때만 켜게 됐을 만큼입니다. 그러면 요점이 무너지죠. include 모드에서는 제 기계 세 대로 가는 트래픽만 WARP를 거치고 나머지는 전부 평소 경로로 손대지 않은 채 나갑니다. 그래서 클라이언트는 그냥 켜진 채로 있습니다. 노트북의 warp-cli status는 하루 종일 Connected라고 하고, 저는 신경 쓰지 않습니다.

전송 방식은 UDP 2408 위의 WireGuard가 아니라, UDP 443 위의 HTTP/3에 HTTP/2 폴백이 붙은 MASQUE로 해 두었습니다. 일부 통신사와 게스트 네트워크는 2408을 막지만, 443을 막는 곳은 거의 없습니다. 제 조직 정책에서는 MASQUE에 양자내성 키 합의도 켜져 있는데, 찾아서 켠 건 아니지만 마다할 이유도 없죠.

왜 198.18이고, 왜 IPv6 주소가 있는지

#

주소가 좀 이상해 보이는데, 처음 고른 주소는 배울 게 있는 방식으로 틀렸습니다.

첫 시도는 10.10.0.1이었습니다. 다들 손이 가는 주소니까요. 이건 두 스플릿 터널 모드 모두에서 실패합니다. exclude 모드에서는 WARP의 기본 목록이 RFC 1918 대역 전부와 100.64.0.0/10을 제외하니, 클라이언트가 그 주소로 가는 트래픽을 기기를 떠나기도 전에 버렸을 겁니다. include 모드에서는 제가 어쩌다 붙는 실제 10.x 네트워크와 충돌했을 겁니다. 카페, 코워킹 스페이스, 그리고 꽤 많은 사무실이 딱 그 대역을 씁니다. 198.18.0.0/15는 RFC 2544 벤치마킹 대역입니다. 예약돼 있고, 공용 인터넷에서 라우팅되는 일이 없고, WARP의 exclude 목록에 없으며, 평범한 네트워크라면 쓰지 않습니다. IPv6 주소가 ULA(fd00::/8)인 것도 같은 이유입니다.

IPv6가 애초에 왜 있는지가 더 재미있는 이야기입니다. v4 주소가 동작하자 폰에서 wifi로 테스트해 봤고, 잘 됐고, 끝났다고 선언했습니다. 5G에서는 안 됐습니다. Agent는 connected라고 했고, 터널은 멀쩡했고, Access도 괜찮았습니다. wifi 테스트가 그 전부를 증명했으니까요. 문제는 요즘 모바일 네트워크가 대부분 IPv6 전용이라는 점이었습니다. 폰에는 네이티브 IPv4가 아예 없었고, v4 리터럴에는 통신사의 464XLAT 변환기를 통해 닿고 있었는데, include 목록에 v4 접두사만 있으면 그 변환기는 터널 바깥에 놓입니다. 트래픽은 198.18.0.0/15가 라우팅되지 않는 공용 인터넷으로 나갔고, 소리 없이 버려졌습니다. 폰에도 오류가 없고, 커넥터 로그에도 아무것도 없었습니다.

해결책은 모든 기계에 폰이 IPv6로 네이티브하게 닿을 수 있는 두 번째 주소를 주고, 그걸 경로와 include 목록에 추가하는 것입니다. 이제 모바일 데이터에서 폰의 SSH 클라이언트가 실제로 쓰는 건 fd12:3456:789a:: 주소입니다.

오프로딩: 단말기로서의 노트북

#

이 셋업 전체가 존재하는 이유가 이 부분입니다.

모델과 파인튜닝. Ollama는 devbox에서 돌고 127.0.0.1:11434에 바인딩됩니다. 인터넷은 고사하고 사무실 LAN의 다른 기계에서도 보이지 않습니다. 노트북에서는 https://devbox-ollama.ssh.test로 나타나고, 포트 번호만 원하는 도구에는 그냥 포트로 나타납니다.

OLLAMA_HOST=127.0.0.1:11435 ollama list

11434가 아니라 11435인 건 일부러입니다. 11434는 Ollama 자체 기본값이라, 노트북에서도 로컬 Ollama를 돌리게 되면 둘이 포트를 두고 경쟁하고, 어느 쪽이 먼저 떴느냐에 따라 “로컬” 쪽에서 devbox의 답을 소리 없이 받게 됩니다.

실제 효과는, AI 기능을 만들 때 그 기능이 호출하는 모델이 제가 어디에 있든 노트북이 아니라 워크스테이션 GPU라는 점입니다. 평가 실행, 문서 한 무더기 임베딩, 파인튜닝은 devbox에서 돌고, 노트북 팬은 조용합니다. 에이전트를 프로토타이핑할 때는 워크스테이션의 로컬 모델을 가리키게 해서 API 청구서 없이 툴 호출 반복을 마음껏 태울 수 있고, 루프가 제대로 잡히면 호스팅 모델로 바꾸면 됩니다.

오래 도는 에이전트. 한 시간 도는 에이전트 세션이 제 노트북 덮개가 열려 있는지에 달려 있어서는 안 됩니다. 대신 devbox에서 돌리면 노트북은 그저 거기로 난 창문입니다. 덮개를 닫고, 나중에 어디서든, 혹은 폰에서 ssh devbox를 하면 여전히 거기 있습니다. 터널 이전에는 이게 사무실에서만 됐는데, 사무실은 정확히 이게 필요 없는 곳이었죠.

빌드와 클러스터. devbox의 클러스터에는 자체 레지스트리가 있어서, 이미지를 노트북에서 호텔 wifi로 올리는 대신 워크스테이션에서, 실행될 곳 바로 옆에서 빌드하고 푸시할 수 있습니다. 클러스터 대시보드, ingress 대시보드, 레지스트리 UI는 노트북에서 전부 *.ssh.test 호스트명입니다.

모바일 루프. 폰은 노트북과 같은 사설 네트워크에 있고, 노트북의 dev 서버에는 Access 뒤의 공개 호스트명도 있습니다. 그래서 앱의 네이티브 빌드를 들고 건물 밖으로 나가 5G에서 써도, 제 책상에서 도는 API와 통신합니다. 제가 devbox에 띄워 두었다면 그쪽과 통신하고요. 실제 모바일 네트워크 위의 실제 기기로 피드백 루프를 돌리려면 예전에는 공유 스테이징 서버에 배포해야 했습니다. 지금은 파일을 저장하면 됩니다.

앱 버그로 착각하고 디버깅하기 전에 알아 둘 만한 함정이 하나 있습니다. Access는 WebSocket 호스트명도 보호하는데, 네이티브 WebSocket 클라이언트는 브라우저가 아닙니다. CF_Authorization 쿠키를 들고 있지 않으니, 네이티브 빌드가 WebSocket 서버에 연결하면 엣지에서 403으로 거부되는데, 이게 내 서버가 내는 오류와는 전혀 닮지 않았습니다. 브라우저 탭은 로그인할 때 받은 쿠키를 이미 들고 있으니 괜찮습니다. 브라우저가 아닌 모든 것(네이티브 앱, 스크립트, dev API를 호출하는 에이전트)에 대한 답은 Access 서비스 토큰이고, 헤더 두 개로 보냅니다.

CF-Access-Client-Id:     <client_id>
CF-Access-Client-Secret: <client_secret>

토큰은 그 자체로는 아무 권한도 주지 않습니다. Access는 정책에 그 토큰이 명시된 앱에서만 받아 주니, 토큰이 닿는 범위는 정확히 dev 호스트명 목록이고 그보다 넓지 않습니다. 저는 그 정책을 allow가 아니라 non_identity 결정으로 분류해 두는데, 그러면 감사 로그에서 로그인한 사람이 아니라 bearer 시크릿으로 보입니다.

인터넷은 절대 보지 못하는 통계

#

제가 원한 것의 나머지 절반은 가시성이었습니다. 시스템이 어떻게 돌아가는지 알려 주는 것 대부분은 공개돼 있지 않은 게 맞습니다. devbox에서는 이런 것들입니다.

• ingress 프록시 대시보드, 그리고 그 트레이스가 담긴 트레이싱 UI
• Kubernetes 클러스터용 대시보드
• 컨테이너 레지스트리 UI(읽기 전용)
• Ollama 모델 목록과 지금 로드된 것
• docker info와 컨테이너 통계

이 중 어느 것도 공개 호스트명이 없고, 앞으로도 없을 겁니다. 루프백이나 클러스터 서비스 IP에 바인딩돼 있고, 그 자체가 터널을 타는 SSH 포워드로 닿습니다. 폰의 모니터링 앱은 WARP 너머 SSH로 docker info --format '{{json .}}'를 읽으니, 컨테이너가 떠 있는지 아니면 뭔가 메모리를 다 먹어 치웠는지 어디서든 볼 수 있습니다.

그 앱 덕분에 언급할 만한 작은 버그를 하나 찾았습니다. Mac의 터널용 sshd가 디버깅하던 시절 그대로 LogLevel DEBUG2였습니다. -e를 주면 sshd는 stderr로 로그를 남기는데, 세션에서는 그 stderr가 곧 SSH 채널의 stderr입니다. 모든 명령의 출력 끝에 debug2: do_setup_env: set TMPDIR가 붙어서 돌아왔고, 두 스트림을 합치는 폰 앱은 유효한 JSON 뒤에 로그 한 줄이 붙은 걸 받아 파싱에 실패하고는 통째로 오류로 보여 줬습니다. LogLevel INFO로 고쳤습니다. 디버깅이 끝나면 로그 레벨을 되돌려 놓으세요.

이 네트워크에 올리지 않는 것도 똑같이 의도적입니다. 예전 autossh 터널은 제가 관리를 돕는 남의 네트워크의 라우터 몇 대에도 닿습니다. 그것들에는 공개 호스트명도, WARP 경로도 주지 않습니다. 인터넷에 나온 라우터 관리 페이지는 로그인 뒤에 있어도 골칫거리고, 제가 넓힐 수 있는 제 네트워크도 아니니까요.

Access는 선택이 아닙니다

#

Cloudflare Tunnel 호스트명은 DNS 레코드가 생기는 순간 공용 인터넷에 올라갑니다. 앞에 방화벽이 없습니다. 포트를 열지 않는다는 게 애초에 요점이니까요. 보호는 Cloudflare 엣지에서 와야 하고, 그게 Access가 하는 일입니다. 방문자가 누구인지 증명하기 전까지는 요청을 아예 전달하지 않으니, 인증되지 않은 스캐너는 노트북에 절대 닿지 못합니다. 이게 중요한 건 이것들이 dev 서버이기 때문입니다. 설정값이 그대로 드러나는 디버그 모드 트레이스백, 열려 있는 JavaScript 번들러. 이 호스트명들 뒤에 있는 것 중 인터넷을 마주하도록 만들어진 건 하나도 없습니다.

정책은 제 이메일 주소들만 허용하고 나머지는 아무것도 허용하지 않으며, 증명 방법은 이메일 일회용 PIN과 SSO 두 가지입니다. 세션은 8시간인데, 현실적인 위협은 누군가 PIN을 무차별 대입하는 게 아니라 하루짜리 쿠키를 품은 채 카페에 열어 두고 온 노트북이기 때문입니다.

SSH는 서로의 존재를 모르는 두 시스템이 두 번 인증합니다. Access는 TCP 스트림이 sshd에 닿아도 되는지를 정하고, sshd는 그래도 제 키를 요구합니다. 어느 하나를 잃어도 기계가 열리지는 않습니다. Mac의 터널용 sshd는 Cloudflare의 SSH CA도 신뢰해서, Access가 제 SSO 세션으로 발급한 단기 인증서로 저를 로그인시킬 수 있습니다. 그러면서 authorized_keys도 나란히 동작하니, Access 설정이 망가져도 제 노트북에서 제가 쫓겨나는 일은 없습니다.

제일 마음에 드는 건 작은 부분입니다. 노출은 세 가지가 맞아떨어질 때 일어납니다. DNS 레코드, 돌고 있는 커넥터, 활성 상태의 존. 이 셋은 제가 통제하지 못하는 순서로, 서로 다른 시점에 참이 됩니다. 존은 네임서버를 바꾸고 얼마 뒤에 혼자 활성으로 바뀌는데, Mac이 잠들어 있을 때일 수도 있습니다. 그래서 launch agent는 cloudflared를 직접 실행하지 않습니다. 대신 터널 자체 설정에서 호스트명을 읽어 Access API에 어느 것이 보호되고 있는지 묻고, 하나라도 빠져 있으면 시작을 거부하는 사전 점검을 돌립니다.

HOSTNAMES=$(grep -E '^\s*-\s*hostname:' "$CONFIG" | sed -E 's/.*hostname:\s*//' | sort -u)
PROTECTED=$(curl -fsS -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
    "https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/access/apps?per_page=100" \
    | python3 -c 'import sys,json; print("\n".join(a.get("domain","") for a in json.load(sys.stdin)["result"]))') \
    || { echo "could not reach the Access API. refusing (fail closed)."; exit 1; }

for h in $HOSTNAMES; do
    grep -qxF "$h" <<<"$PROTECTED" || { echo "NOT starting: $h has no Access app"; exit 1; }
done
exec cloudflared tunnel --config "$CONFIG" run

launch agent에는 KeepAlive가 걸려 있어서, 거부되면 30초마다 알아서 재시도하고 Access 앱이 생기면 터널이 혼자 올라옵니다. 닫힌 채로 실패하면 장애를 치르고, 열린 채로 실패하면 노출을 치릅니다. 둘 중 어느 쪽을 해명하고 싶은지는 압니다.

발목을 잡은 네 가지

#

위의 모든 게 지금은 동작합니다. 여기까지 오는 동안 넷 중 셋은 패턴이 같았습니다. 고장 난 부분은 어디에도 오류를 내지 않았고, 제 눈에 보이는 부분은 전부 정상이라고 보고했습니다.

경로와 include 목록은 서로 다른 목록입니다. 터널 경로는 Cloudflare가 어떤 주소를 올바른 커넥터로 실어 나를 의향을 갖게 합니다. WARP include 목록은 클라이언트가 애초에 그걸 보내게 만드는 것입니다. devbox가 폰에서 닿지 않았는데, 경로는 있었지만 include 목록에는 여전히 Mac의 주소만 있었기 때문입니다. 폰은 패킷을 로컬에서 버렸고, 커넥터는 흐름을 보지 못했고, 모든 대시보드는 초록이었습니다. 새 기계를 들일 때마다 주소를 양쪽 모두에 추가해야 합니다.

IPv6 전용 모바일 네트워크의 IPv4 리터럴. 위에서 다뤘습니다. wifi에서는 되고, 5G에서는 안 되고, 오류는 없습니다. WARP 경로가 wifi에서는 되는데 모바일 데이터에서 안 되고 Agent가 connected로 나온다면, 터널이 아니라 라우팅 문제입니다.

cloudflared 뒤의 macOS sshd. macOS는 sshd를 launchd 소켓 활성화로 띄웁니다. 연결마다 수명이 짧은 sshd -i가 하나씩 뜨는 식이죠. cloudflared 뒤에서는 배너가 클라이언트에 닿은 다음, 클라이언트의 식별 문자열이 돌아오기 전에 스트림이 끊겨서, 모든 로그인이 kex_exchange_identification에서 죽습니다. 양쪽 끝에서 확인했고, 평범한 TCP 릴레이로도 재현해서 Cloudflare 탓이 아님을 확인했습니다. 해결책은 127.0.0.1:2222와 WARP 루프백 주소에서 제 사용자로 도는 두 번째 독립 sshd -D인데, 오직 터널의 origin 노릇을 하려고 존재합니다. 시스템 설정의 원격 로그인은 건드리지 않았습니다. 평범하게 오래 사는 sshd를 쓰는 Linux인 devbox에는 이 문제가 애초에 없었습니다.

더는 존재하지 않는 설정 필드. 예전 예제에는 터널 설정에 warp-routing: enabled: true가 있습니다. cloudflared 2026.8은 그 필드를 대놓고 거부합니다. WARP 라우팅은 블록이 있고 경로가 터널을 가리키기만 하면 켜집니다. 이건 적어도 오류를 냈는데, 다른 셋을 겪은 뒤라 거의 너그럽게 느껴졌습니다.

무엇이 바뀌었나

#

솔직하게 요약하면, 하드웨어가 어디 있느냐에 따라 일할 곳을 고르는 걸 그만뒀습니다. 노트북은 배터리가 오래가는 좋은 키보드와 좋은 화면이고, 그 이상일 필요가 없습니다. 워크스테이션은 제가 어디에 있든 무거운 일을 맡습니다. 폰은 사무실 wifi에 묶인 무언가가 아니라 실제 네트워크 위의 실제 테스트 기기입니다. 그리고 시스템이 뭘 하는지 보는 데 쓰는 부분들은 저에게는 클릭 한 번 거리에 있고, 다른 누구에게는 존재하지 않습니다.

이 규모면 Cloudflare의 무료 Zero Trust 플랜에 들어갑니다. 제가 치른 건 시간, 그리고 써 두길 잘했다 싶은 README 하나입니다. 위에 적은 실패는 하나같이 두 번째에도 새로운 미스터리였을 테니까요.

비슷한 걸 고민하고 있다면, 여러분의 셋업에 이런 질문을 던져 보겠습니다.

1. 노트북이 언제나 닿을 수 있는 유일한 기계라는 이유만으로 노트북에서 돌고 있는 건 무엇인가요?
2. 폰이 사무실 wifi에서만이 아니라 모바일 데이터로도 dev 서버에 닿나요? wifi 말고 5G에서 테스트해 보세요.
3. 밖에서 보기 쉬운 방법이 그것뿐이라서 공개된 대시보드는 어느 것인가요? 하나하나가 사설 경로로 옮길 후보입니다.
4. 내일 터널 호스트명이 Access 앱 없이 올라온다면, 무엇이 그걸 막나요? 답이 “제가 기억하겠죠"라면 사전 점검을 작성하세요.
5. 여러분의 사설 주소는 여러분이 드나드는 네트워크가 절대 쓰지 않을 대역에 있나요?