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

vLLM vs Ollama 한눈에 비교

#

Ollama란?

#

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

그 얌전함이 곧 트레이드오프입니다. Ollama는 한 번에 한 사람이 쓰는 걸 전제로 만들어졌습니다. 기본값으로는 한 번에 요청 하나만 처리하고, OLLAMA_NUM_PARALLEL로 슬롯을 늘릴 수는 있지만 슬롯마다 컨텍스트 하나 분량의 메모리가 들고, 수십 명의 사용자를 GPU 한 장에 배치로 몰아넣으라고 만든 물건은 애초에 아닙니다.

vLLM이란?

#

vLLM은 서빙 엔진이고, 바로 그 배칭을 위해 만들어졌습니다. 핵심 아이디어는 두 가지입니다. PagedAttention은 요청마다의 KV 캐시(모델이 토큰을 읽고 쓰면서 쌓아 가는 어텐션 상태)를 작은 고정 크기 블록에 나눠 저장해서, GPU 메모리가 패딩과 단편화로 버려지지 않게 합니다. 연속 배칭은 새 요청이 지금 배치가 끝나기를 기다리지 않고 생성 단계 사이사이에 배치에 끼어들게 해 줍니다. 이 둘 덕분에 vLLM을 돌리는 GPU 한 장은, 같은 GPU가 요청을 하나씩 처리할 때보다 훨씬 많은 동시 사용자를 감당합니다. 둘을 직접 비교 측정해 본 적은 없어서 이 글에는 자체 처리량 수치가 없습니다. 이 주장을 실측한 자료로는 Red Hat의 Ollama vs. vLLM 벤치마크가 있습니다. A100 한 장에서 Llama 3.1 8B를 동시 사용자 1명부터 256명까지 돌린 것인데, OLLAMA_NUM_PARALLEL을 32까지 올리고도 vLLM은 초당 약 793 출력 토큰에서 정점을 찍은 반면 Ollama는 41이었습니다.

대가는 vLLM이 카드를 자기 것처럼 쓴다는 점입니다. 시작할 때 GPU 메모리에서 자기 몫을 차지하고, 가중치가 쓰고 남은 공간은 KV 캐시로 채우고, 호출하는 사람이 있든 없든 그 전부를 쥐고 있습니다. 모델도 Hugging Face 원본 가중치나 FP8, AWQ 같은 GPU 친화적인 양자화를 원합니다. GGUF 파일을 읽을 수는 있지만 vLLM 문서 스스로 그 지원을 “highly experimental and under-optimized"라고 부르니, Ollama로 받아 둔 파일을 재사용할 계획은 세우지 마세요.

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

#

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

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

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 기본값은 70 GB 이상 카드에서 1024(그 미만은 256)라서 그 카드에서는 시작에 실패했고, --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으로 옮길 시점입니다.

어느 쪽을 쓸까

#

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

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

GitHub Actions에서 Docker Compose를 돌리는 법을 찾아 오셨다면, 결론부터. 저는 그걸 2년 하다가 그만뒀습니다. 지금 CI는 같은 Postgres와 Valkey 이미지를 services:로 선언하고, 같은 uv run …과 npm run … 명령을 러너에서 바로 돌립니다. Compose는 개발자가 로컬에서 돌리는 것으로 남았고요. 나머지는 그 이유와 실제 파일들입니다.

2024년에 플랫폼 종속 YAML 대신 Docker Compose로 CI/CD 하기라는 글을 썼습니다. 빌드 로직은 Compose에 두고 CI 도구는 그걸 호출하는 일만 하게 하라는 내용이었죠. 2년이 지나 제가 실제로 배포하는 저장소를 전부 다시 훑어봤습니다. 워크플로가 있는 저장소는 넷이고, 커미터는 모두 저 한 명입니다. 그리고 그 워크플로 중 docker compose를 호출하는 건 이제 하나도 없습니다. 원칙은 살아남았고, 방법은 살아남지 못했습니다. 아래는 그 자리를 대신한 것들입니다. 줄여서 예제로 만든 파일, GitHub가 기록한 단계별 소요 시간, 그리고 CI/CD 다이어그램이 바라는 것보다 덜 자동화된 부분까지 적었습니다.

제가 돌리는 파이프라인 전부, 표 하나로

#

교과서 용어로 말하면 두 Hugo 사이트는 지속적 배포이고, 앱(제가 만드는 마켓플레이스 겸 커뮤니티 앱)은 지속적 통합에 명령 한 줄짜리 릴리스를 더한 지속적 전달입니다. 체크는 뭔가 잘못됐다고 알려 줄 뿐, 배포를 막지는 않습니다. 일부러 이렇게 나눴습니다. OTA 업데이트는 대상 바이너리 버전을 쓰는 모든 휴대폰에 닿으니, 머지의 부작용이 아니라 결정이어야 합니다. 그리고 API는 데이터베이스 마이그레이션이 실행되는 곳입니다. 제 나머지 Django 앱 두 개에는 워크플로가 아예 없습니다.

CI 쪽: 워크플로 하나, 잡 두 개

#

앱의 CI는 .github/workflows/checks.yml 파일 하나입니다. 10월 11일 전까지는 이것조차 없었습니다. 아래는 그 구조를 줄여서 만든 예제입니다.

# Lint, types and tests on every push and pull request to main.
# Nothing here deploys.
name: Checks

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

concurrency:
  group: checks-${{ github.ref }}
  cancel-in-progress: true

jobs:
  python:
    runs-on: ubuntu-latest
    timeout-minutes: 30
    services:
      postgres:
        image: postgres:17
        env:
          POSTGRES_USER: myapp
          POSTGRES_PASSWORD: myapp
          POSTGRES_DB: myapp
        ports: ["5432:5432"]
        options: >-
          --health-cmd "pg_isready -U myapp"
          --health-interval 5s --health-timeout 5s --health-retries 20
      valkey:
        image: valkey/valkey:8-alpine
        ports: ["6379:6379"]
    env:
      DEBUG: "True"
      DATABASE_URL: postgresql://myapp:myapp@localhost:5432/myapp
      REDIS_URL: redis://localhost:6379
      PYTHON_JIT: "0"   # match production
    steps:
      - uses: actions/checkout@v7
      - uses: astral-sh/setup-uv@v10
        with:
          enable-cache: true
          prune-cache: true
      - run: uv sync --locked
      - run: uv run ruff check .
      - run: uv run mypy myapp/
      - run: uv run python manage.py test --parallel 4 --noinput

  app:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    defaults:
      run:
        working-directory: frontend
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
          cache-dependency-path: frontend/package-lock.json
      - run: npm ci
      # Expo writes this on `expo start` and it is gitignored,
      # so a fresh checkout doesn't have it.
      - run: printf '/// <reference types="expo/types" />\n' > expo-env.d.ts
      - run: npm run typecheck
      - run: npx jest --ci

두 잡은 나란히 돕니다. 지금까지 성공한 35번의 실행에서 앱 잡의 중앙값은 7분쯤, Python 잡은 12분 반쯤입니다.

services: 블록이 바로 Compose 파일이 옮겨 간 자리인데, 다음 절에서 다룹니다. 환경 변수는 몇 개와 플래그 하나뿐입니다. 나머지는 전부 개발자가 docker compose up에서 받는 개발용 기본값으로 떨어지기 때문에, 테스트에는 시크릿이 하나도 필요 없습니다. 정말 그런지 보려고 딱 그 환경만, 다른 건 아무것도 없이 테스트 일부를 돌려 확인했습니다.

CI는 제 노트북, 프로덕션 이미지와 같은 인터프리터, 즉 uv가 직접 빌드한 Python 3.15.0으로 돕니다. uv sync가 .python-version을 읽고 정확히 그 빌드를 내려받기 때문입니다. (실제 파일에서는 setup-uv에 python-version-file 입력도 넘기는데, 이건 아무 일도 하지 않습니다. setup-uv v6에는 그런 입력이 없고, 매 실행마다 그렇다는 경고가 붙어 있습니다. 이 글을 쓰다가야 알았습니다.)

인터프리터를 맞춘 보람은 워크플로를 넣은 지 8일 만에 나타났습니다. 10월 19일에 3.15의 JIT 컴파일러를 켰더니, 켠 뒤 첫 실행에서 테스트 하나가 실패했습니다. 앱이 저장할 때마다 지나가는 코드 경로의 평범한 yield from이 AttributeError: 'list' object has no attribute 'send'를 던진 겁니다. 같은 커밋을 JIT를 끄고 돌리면 통과했습니다. 제 Mac은 arm64라서 이 문제를 한 번도 만나지 않았고, 러너는 프로덕션 머신과 같은 x86_64입니다. JIT는 CI에서도 Dockerfile에서도 다시 꺼 두었고, 버그는 프로덕션에 닿지 않았습니다. python/cpython#155823로 올라가 있던 버그로, 3.15.0이 나온 뒤인 10월 13일에 업스트림에서 고쳐졌습니다.

사실 맨 첫 실행도 실패했는데, 이유는 더 시시했습니다. Expo는 expo start를 할 때 expo-env.d.ts를 만들고 이 파일은 gitignore되어 있습니다. 그래서 제가 쓰던 작업 사본에는 모두 있었고, 새로 받은 체크아웃에는 없었죠. TypeScript가 로컬에서는 한 번도 보지 못한 오류 다섯 개를 냈습니다. 그 파일을 써 주는 단계가 해결책입니다.

concurrency는 같은 브랜치에 더 새로운 push가 오면 이전 실행을 취소합니다. 지금까지 취소된 12번의 실행은 모두 이렇게 끝났습니다. 커밋 전 훅(pre-commit hook)이 린터를 돌리고, Python이나 TypeScript가 스테이징돼 있으면 타입 체커도 돌리기 때문에 실수는 대부분 push까지 가지도 않습니다.

Docker Compose 파일은 어디로 갔나

#

앱의 docker-compose.yml에서 CI와 관련된 부분을 예제로 옮긴 것입니다. 실제 파일에는 서비스도 더 있고 환경 변수도 훨씬 많습니다.

services:
  valkey:
    image: valkey/valkey:8-alpine
    ports:
      - "6379:6379"

  # Host port 55432, not 5432, so it can't collide with a local Postgres.
  postgres:
    image: postgres:17-alpine
    environment:
      - POSTGRES_USER=myapp
      - POSTGRES_PASSWORD=myapp
      - POSTGRES_DB=myapp
    ports:
      - "55432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U myapp -d myapp"]
      interval: 5s
      retries: 10

  api:
    build: .
    command: python manage.py runserver 0.0.0.0:8000
    volumes:
      - .:/app
    ports:
      - "8000:8000"
    environment:
      - DATABASE_URL=postgresql://myapp:myapp@postgres:5432/myapp
      - REDIS_URL=redis://valkey:6379
    depends_on:
      postgres:
        condition: service_healthy
      valkey:
        condition: service_started

volumes:
  postgres_data:

checks.yml의 services: 블록 옆에 놓고 보면 같은 이미지 두 개입니다. Postgres 17(여기서는 Alpine 빌드, CI에서는 Debian 빌드)과 valkey/valkey:8-alpine. 지금의 관계는 이렇습니다. Compose 파일은 개발자가 돌리는 것이고, CI는 같은 이미지를 서비스 컨테이너로 선언한 다음 개발자가 돌리는 것과 같은 명령, uv run …과 npm run …을 러너에서 바로 돌립니다.

2024년 글과 비교하면, 제가 가장 신경 쓰던 부분은 살아남았습니다. CI 도구는 얇고, 체크와 배포는 제가 직접 돌릴 수 있는 명령입니다. 살아남지 못한 건 CI가 Compose를 호출하는 방식입니다.

앱의 CI는 Docker 이미지를 아예 빌드하지 않습니다. 이미지는 배포할 때 Fly의 빌더가 한 번 빌드하고, CI는 코드가 괜찮은지만 말해 주면 됩니다. 툴체인이 캐시돼 있으면 그건 6초짜리 설치로 끝납니다. 게다가 Compose 파일은 작업 사본을 바인드 마운트하고 데이터를 시드하는데, 테스트 실행이 할 일은 아닙니다. 그러니 CI용 Compose 파일이 따로 필요했을 테고, 그건 같은 서비스를 두 번째로 정의해 손으로 맞춰 가야 한다는 뜻입니다.

그리고 2024년 예제에는 당시 눈치채지 못한 버그가 있었습니다. docker compose build는 이미지를 빌드할 뿐 서비스의 command를 실행하지 않습니다. 그러니 그 파일의 npm test는 CI에서 한 번도 돌지 않았고, 워크플로는 테스트가 통과하든 말든 초록불이었습니다.

그 글이 가장 걱정했던 위험, 즉 CI 업체를 바꾸는 일은 결국 일어나지 않았습니다. 실제로 일어난 이동은 반대쪽 끝에서였습니다. 이 블로그와 그 클라이언트 사이트가 호스팅을 Cloudflare Pages로 옮겼는데, 블로그 쪽은 45줄짜리 워크플로 하나를 새로 쓰는 걸로 끝났습니다. 빌드가 원래 명령 한 줄이었기 때문이죠. 그리고 제가 경고했던 300줄짜리 워크플로요? 하나 있습니다. pyhtml2text의 워크플로입니다. wheel을 Linux, macOS, Windows 러너에서 각각 여러 아키텍처로 빌드해야 해서 긴 건데, 그래서 플랫폼 전용 YAML이 맞는 도구인 유일한 작업이기도 합니다.

캐싱: 단계별 소요 시간부터 읽기

#

GitHub는 모든 단계의 소요 시간을 기록해 두고, gh api repos/<owner>/<repo>/actions/runs/<run-id>/jobs로 꺼내 볼 수 있습니다. 아래는 10월 20일, 앱의 가장 최근 성공 실행입니다.

의존성 캐시 두 개는 모두 켜져 있고, 둘 다 저렴한 부분입니다. GitHub가 이 저장소용으로 보관하는 uv 캐시는 200KB 정도인데, setup-uv가 다시 내려받으면 되는 것들은 정리해 버리기 때문입니다. npm 캐시는 400MB에 가깝습니다. 시간이 드는 곳은 테스트이고, 테스트는 이미 4갈래로 병렬 실행됩니다. 실행을 더 빠르게 하고 싶다면 캐시가 아니라 테스트 스위트를 손보겠습니다.

블로그는 정반대입니다. Hugo가 처리한 이미지는 gitignore된 resources/_gen에 있어서, 새 러너마다 커버, 본문 이미지, 플레이스홀더를 전부 다시 인코딩했습니다. 아래 워크플로는 actions/cache로 이것을 복원합니다. 키는 사진 자체의 해시이고, 키가 맞지 않으면 가장 최근의 이전 캐시로 대신합니다. Hugo는 빠진 것만 처리하니까요. 캐시를 넣기 전 마지막 8번의 실행에서 빌드 단계는 3376초 걸렸고, 넣은 뒤 26번은 620초였습니다. 94초가 한 번 있었을 뿐이고, 같은 커밋에서 플레이스홀더와 두 번째 카드 크기까지 추가했는데도 그렇습니다.

앱의 이미지는 Fly의 빌더에서 빌드되고, 의존성 파일을 코드보다 먼저 복사하며 uv의 다운로드 캐시는 BuildKit 캐시 마운트(RUN --mount=type=cache,target=/root/.cache/uv)에 둡니다. 하지만 더 큰 개선은 캐시가 아니었습니다. 예전 .dockerignore는 블록리스트였는데, 추가 git worktree들을 모아 둔 폴더를 빠뜨렸습니다. worktree마다 자기 의존성과 빌드 산출물이 들어 있었죠. 그래서 파일 27만 7천 개, 7.7GB가 배포할 때마다 빌더로 올라갔습니다. 허용 목록으로 다시 쓴 지금은 빌드 컨텍스트가 40MB 정도입니다. 그 패턴을 예제로 보면 이렇습니다.

# Exclude everything, then let back in only what the Dockerfile COPYs.
*

!pyproject.toml
!uv.lock
!manage.py
!myapp
!static

# Rules match the whole relative path and the last match wins,
# so these re-excludes apply inside the allowed directories too.
**/__pycache__/
**/*.pyc
**/.DS_Store
**/*.log

시크릿은 최대한 적은 곳에

#

시크릿은 세 군데에 있습니다. GitHub Actions 시크릿은 워크플로가 하는 일을 위한 것이고, 두 Hugo 저장소에는 CLOUDFLARE_API_TOKEN 딱 하나씩만 있습니다. Fly 시크릿은 앱의 런타임 설정으로 flyctl secrets set으로 넣고, Actions를 거치지 않습니다. 그리고 제 노트북의 gitignore된 .env에는 배포 스크립트가 Cloudflare 캐시를 비울 때 쓰는 토큰이 있습니다.

PyPI에는 시크릿이 아예 필요 없습니다. pyhtml2text는 신뢰할 수 있는 게시(trusted publishing)를 씁니다. PyPI가 GitHub이 워크플로에 발급하는 수명 짧은 OIDC 토큰을 받아 주기 때문에, 릴리스 잡은 id-token: write만 요청하고 저장소의 시크릿 페이지는 비어 있습니다. 샐 것도, 교체할 것도 없죠.

토큰에는 필요한 만큼만 줍니다. GitHub에 있는 앱의 Fly 토큰은 머신 목록만 조회하는 예약 체크용이라 fly tokens create readonly로 만들었습니다. Pages 배포는 contents: read와 deployments: write만 요청하고 그 이상은 없습니다.

입력값은 스크립트에 바로 넣지 않고 반드시 env:를 거칩니다. OTA 워크플로는 자유롭게 쓰는 릴리스 노트를 받습니다. 이걸 run: 안에 ${{ inputs.notes }}로 쓰면 bash가 읽기 전에 텍스트가 스크립트에 그대로 붙여 넣어지니, 따옴표와 세미콜론이 든 노트는 코드가 되어 버립니다. 환경 변수로 넘기면 데이터로 남습니다. 패턴을 예제로 보면 이렇습니다.

      - name: Publish
        env:
          OTA_API_TOKEN: ${{ secrets.OTA_API_TOKEN }}
          INPUT_PLATFORM: ${{ inputs.platform }}
          INPUT_ROLLOUT: ${{ inputs.rollout }}
          INPUT_NOTES: ${{ inputs.notes }}
        run: |
          args=("$INPUT_PLATFORM")
          [ -n "$INPUT_ROLLOUT" ] && args+=(--rollout "$INPUT_ROLLOUT")
          [ -n "$INPUT_NOTES" ] && args+=(--notes "$INPUT_NOTES")
          ./scripts/publish-ota.sh "${args[@]}"

아예 GitHub 밖에 두는 키도 있습니다. 예약 리포트 하나에는 앱의 로그인 백엔드에 대한 관리자 권한이 있는 키가 필요해서, 그 리포트는 예약 워크플로에서 제 Mac의 예약 작업으로 옮겼습니다. 워크플로는 수동 예비용으로 남아 있고, 그 키가 필요한 섹션은 빼고 게시합니다.

배포: push마다, 스크립트로, 태그로

#

Hugo 사이트는 push마다 배포됩니다

#

블로그 워크플로를 예제로 옮긴 것입니다. Pages 프로젝트를 처음 만드는 단계는 뺐습니다.

name: Deploy to Cloudflare Pages

on:
  push:
  workflow_dispatch:

env:
  HUGO_VERSION: "0.165.0"
  PAGES_PROJECT: my-site

concurrency:
  group: deploy-${{ github.ref }}
  cancel-in-progress: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      deployments: write
    steps:
      - uses: actions/checkout@v7
        with:
          submodules: true

      - uses: peaceiris/actions-hugo@v3
        with:
          hugo-version: ${{ env.HUGO_VERSION }}
          extended: true

      # Processed images are gitignored; restore them so Hugo only
      # re-encodes what is new. An older cache still helps.
      - uses: actions/cache@v6
        with:
          path: resources/_gen
          key: hugo-resources-${{ hashFiles('content/**/*.jpg', 'content/**/*.png', 'assets/img/**') }}
          restore-keys: |
            hugo-resources-

      # A multilingual site has no root 404.html; without one, Pages
      # answers unknown paths with index.html and a 200.
      - name: Build
        run: |
          hugo --gc
          cp public/en/404.html public/404.html

      # ...

      - name: Deploy
        uses: cloudflare/wrangler-action@v4
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ vars.CLOUDFLARE_ACCOUNT_ID }}
          command: pages deploy public --project-name=${{ env.PAGES_PROJECT }} --branch=${{ github.ref_name }}

--branch=${{ github.ref_name }} 덕분에 main은 프로덕션이 되고 다른 브랜치는 모두 미리보기 URL을 받습니다. 클라이언트 사이트의 워크플로는 이것과 같은 구조에 빌드 전 rm -rf public 한 줄이 더 있습니다. 그쪽은 public/이 커밋되어 있어서, 안 그러면 삭제한 페이지가 업로드에 계속 남기 때문입니다.

Hugo 버전은 여기에서만 고정합니다. 10월에 패키지 매니저 업그레이드로 제 노트북의 Hugo가 0.168이 됐는데, 테마가 지원하는 최신 버전보다 하나 높습니다. 배포는 0.165에 머물렀고 아무 일도 없었습니다.

그리고 빌드가 곧 테스트입니다. 9월 14일, 한 브랜치의 미리보기 배포가 세 번 연달아 실패했습니다. 그 브랜치의 글 하나가 Hugo의 ref로 아직 초안인 글을 가리키고 있었거든요. CI는 프로덕션이 빌드하는 것과 똑같이, 초안을 빼고 빌드합니다. 그러니 링크는 아무것도 가리키지 않았고 Hugo는 REF_NOT_FOUND로 멈췄습니다. 그동안에도 main은 계속 배포되고 있었습니다.

앱의 API는 스크립트로 배포합니다

#

배포 스크립트의 핵심을 예제로 옮긴 것입니다.

IMAGE_LABEL="deploy-$(git rev-parse --short HEAD)-$(date +%Y%m%d%H%M%S)"

# Build first, then wake a spare machine, then roll out exactly that image.
flyctl deploy --config fly.toml --build-only --push --image-label "$IMAGE_LABEL"
curl -fsS --retry 5 https://myapp.fly.dev/health > /dev/null
flyctl deploy --config fly.toml --image "registry.fly.io/myapp:$IMAGE_LABEL"

그리고 fly.toml에서 짝이 되는 부분입니다.

[deploy]
  # max_unavailable only counts machines that are running,
  # which is why the script wakes one first.
  strategy = "rolling"
  max_unavailable = 1

이미지는 한 번 빌드해서 커밋과 시각으로 만든 라벨을 붙여 Fly 레지스트리에 올리고, 그 라벨로 배포합니다. 그래서 롤아웃되는 건 정확히 빌드한 그것입니다.

무중단 배포를 가능하게 하는 건 예비 머신을 먼저 깨우는 단계입니다. max_unavailable = 1은 실행 중인 머신만 셉니다. 그런데 앱은 한가할 때 실행 중인 머신을 하나도 두지 않습니다(일시 정지된 머신은 1초 남짓이면 깨어납니다). 그래서 깨어 있던 머신 하나가 잠든 머신들과 같은 묶음에서 교체되곤 했고, 그 뒤에는 따뜻한 머신이 하나도 없었습니다. 9월 28일에 오리진에 프로브를 계속 보내 봤더니, 그냥 flyctl deploy를 할 때는 타임아웃 7번과 7.3초의 공백이 있었고, 먼저 빌드하고 롤아웃 전에 머신 하나를 깨워 두는 스크립트 배포로는 요청 2,514개 중 실패가 하나도 없었습니다.

스크립트의 나머지는 오류 알림이 오는 팀 채팅 채널에 배포 표시를 남깁니다. 그래야 오류가 몰렸을 때 방금 무엇이 바뀌었는지와 맞춰 볼 수 있죠. 그리고 Cloudflare 캐시를 비우고 머신들을 데워 둡니다. 웹 프런트엔드는 이미지를 아예 거치지 않는데, 그건 프론트엔드와 백엔드 따로 배포하기에 적었습니다.

마이그레이션은 파이프라인 단계가 아닙니다. Fly의 release_command가 제 환경에서는 멈춰 버려서, 새 이미지로 처음 부팅하는 머신이 락을 잡고 마이그레이션하는 동안 나머지는 기다립니다. 그러니 모든 마이그레이션은 아직 돌고 있는 코드와도 맞아야 합니다. 컬럼은 한 배포에서 추가하고, 다음 배포에서 쓰지 않게 하고, 세 번째 배포에서 지웁니다.

이 스크립트에 꼭 제 노트북이어야 하는 부분은 없지만, 노트북에만 있는 파일 몇 개가 스크립트를 거기 묶어 둡니다. Cloudflare 자격 증명, 그리고 마지막으로 무엇을 배포했는지 적어 둔 기록입니다. 새 러너에는 이 파일들이 없죠. 커밋하지 않은 변경도 배포해 버리고 채팅 채널에 그렇다고 알리는데, 웹 릴리스 스크립트는 더러운 작업 트리를 거부합니다.

브랜치별 프리뷰 환경에서 저는 이걸 손으로 하는 건 혼자일 때는 괜찮지만, 두 번째 개발자부터는 git에서 뭔가 일어났기 때문에 일어나야 한다고 썼습니다. 앱의 개발자는 아직 한 명입니다. 그 글의 브랜치 환경 워크플로는 제가 만들었던 브랜치에 그대로 있습니다.

OTA 워크플로는 수동 전용입니다. 게시는 결정이어야 하고, 업데이트 서비스는 부분 롤아웃이 열려 있는 동안 새 릴리스를 거부하기 때문에 push 트리거라면 카나리 배포 때마다 걸릴 테니까요. 이 워크플로는 한 번도 실행된 적이 없습니다. 지금까지 OTA 업데이트는 전부 제 노트북에서, 워크플로가 호출하는 것과 같은 스크립트로 나갔습니다. 얇은 워크플로를 쓰는 이유가 한 줄로 이겁니다. 릴리스를 어떻게 시작하든 같은 스크립트죠.

pyhtml2text는 태그로 릴리스합니다

#

릴리스 잡입니다. 패키지 이름은 일반적인 이름으로 바꿨습니다.

  release:
    runs-on: ubuntu-latest
    if: ${{ startsWith(github.ref, 'refs/tags/') || github.event_name == 'workflow_dispatch' }}
    needs: [linux, macos, windows, sdist]
    environment:
      name: pypi
      url: https://pypi.org/p/mypackage
    permissions:
      id-token: write       # trusted publishing and signing
      contents: write
      attestations: write
    steps:
      - uses: actions/download-artifact@v8
      - uses: actions/attest@v4
        with:
          subject-path: 'wheels-*/*'
      - uses: astral-sh/setup-uv@v10
        if: ${{ startsWith(github.ref, 'refs/tags/') }}
        with:
          prune-cache: true
      - name: Publish to PyPI
        if: ${{ startsWith(github.ref, 'refs/tags/') }}
        run: uv publish --trusted-publishing always 'wheels-*/*'

릴리스 잡은 모든 빌드 잡을 기다리고, 실제 게시는 태그일 때만 합니다. 수동 실행은 빌드하고 증명(attestation)까지 만들지만 아무것도 올리지 않습니다. actions/attest는 어느 워크플로가 각 wheel을 빌드했는지 기록하고, uv publish --trusted-publishing always는 비밀번호 대신 OIDC 토큰으로 업로드합니다. 패키지 자체에 대해서는 닫힌 풀 리퀘스트, 포크, 그리고 PyPI 패키지에 썼습니다.

예약 워크플로는 최선을 다할 뿐입니다

#

앱에는 예약 워크플로가 하나 있습니다. Fly가 기준치보다 머신을 더 띄우지 않았는지 보는 체크로, 그냥 두면 청구서에서 처음 알게 될 일입니다. 알림은 일부러 실패하는 방식으로 보냅니다. 예약 실행이 실패하면 GitHub이 소유자에게 메일을 보내니까요.

설정은 cron: '*/15 * * * *', 하루 96번입니다. 그런데 지난 2주 동안은 하루 3~8번만 돌았고, 실행 간격의 중앙값은 3시간 40분쯤이었습니다. GitHub 문서가 내놓는 설명은 부하뿐입니다. Actions가 바쁘면 예약 실행이 늦어질 수 있고, 아주 바쁘면 빠질 수도 있다는 거죠. 계속되는 스케일 아웃이라면 몇 시간이면 충분합니다. 몇 분 안에 울려야 하는 것이라면 GitHub의 cron은 모니터링이 아닙니다.

파이프라인에 던져 볼 질문

#

파이프라인을 만들고 있거나 이미 있는 걸 들여다보고 있다면:

1. GitHub Actions가 하루 동안 멈추면 그래도 릴리스할 수 있나요? 못 한다면 릴리스 로직이 YAML 안에 있는 것이고, 2024년 글이 여전히 유효합니다.
2. CI가 프로덕션과 같은 인터프리터, 같은 CPU 아키텍처, 같은 데이터베이스 메이저 버전으로 도나요? 제 CI가 컴파일러 버그를 잡은 건 러너와 프로덕션은 둘 다 x86_64이고 제 노트북은 아니었기 때문입니다.
3. 새로 받은 체크아웃이 통과하나요? 안 된다면 대개 생성되고 gitignore된 파일 때문입니다.
4. 실행 시간은 실제로 어디에 쓰이나요? 캐시를 넣기 전에 단계별 소요 시간부터 읽어 보세요.
5. 시크릿마다 몇 군데에 있나요? 그리고 정말 GitHub에 있어야 하나요?

빌드와 테스트 단계를 GitHub Actions YAML에 직접 쓰는 팀이 많습니다. 그 자체로는 잘 돌아가죠. 문제는 같은 빌드를 내 노트북에서 돌려보고 싶어질 때, 혹은 누군가 “GitLab으로 옮기면 어때요?“라고 말하는 순간입니다. 파이프라인 전체가 특정 벤더의 설정 포맷에 용접돼 있다는 걸 그제야 깨닫게 되니까요. 요즘 제 방식은 꽤 심심합니다. 진짜 로직은 Docker Compose에 두고, CI 도구는 그걸 호출하는 역할만 시키는 겁니다.

빌드 로직을 Actions YAML에 넣지 않는 이유

#

가장 뻔한 문제는 종속성입니다. Actions 워크플로우는 GitLab, Bitbucket, Jenkins 어디에서도 통하지 않으니, 빌드 단계가 워크플로우 파일 안에 있으면 플랫폼을 바꿀 때 전부 다시 써야 합니다. 그런 작업에 시간을 배정해 주는 조직은 본 적이 없네요.

더 은근하게 괴로운 문제는 파이프라인을 로컬에서 돌릴 수 없다는 점입니다. 빌드 수정을 확인할 방법이 “커밋 푸시하고 Actions 탭 쳐다보기"뿐이면, git 히스토리는 금세 “fix ci”, “fix ci again” 같은 커밋으로 가득 찹니다. Compose 파일은 제 노트북에서나 러너에서나 똑같이 돌아가니, “제 컴퓨터에서는 되는데요” 같은 논쟁도 대부분 시작 전에 끝나고요.

그리고 YAML은 자랍니다. 처음엔 깔끔한 20줄이던 것이 캐싱 트릭과 조건문이 붙으면서 300줄이 되고, 개발자들은 Git에 더해 CI 방언까지 배워야 하죠. 스크립트 하나는 한 가지 일만 해야 하는데, 거대한 워크플로우 파일은 모든 걸 한꺼번에 떠안기 마련입니다.

Compose를 쓰면 이 분담이 깔끔해집니다. 빌드와 테스트는 Compose 파일의 책임, CI 플랫폼은 푸시가 있을 때마다 그걸 실행해 주는 존재일 뿐입니다.

설정 방법

#

1. 먼저 Dockerfile을 만들어 이미지 빌드 방법을 한곳에 모읍니다:

# 공식 Node.js 런타임을 베이스 이미지로 사용
FROM node:14

# 컨테이너 내 작업 디렉토리 설정
WORKDIR /app

# package.json 및 package-lock.json 파일을 컨테이너로 복사
COPY package*.json ./

# 종속성 설치
RUN npm install

# 나머지 애플리케이션 코드를 컨테이너로 복사
COPY . .

# 앱이 실행되는 포트 노출
EXPOSE 3000

# 애플리케이션을 실행하는 명령 정의
CMD ["npm", "start"]

2. 다음으로 빌드와 테스트에 필요한 서비스를 정의하는 docker-compose.build.yaml을 만듭니다.

   services:
     app:
       image: myprivaterepo.com/image:latest
       build: .
       volumes:
         - .:/app
       command: sh -c "npm install && npm test"

3. 로컬에서 먼저 돌려봅니다. 사실 이게 이 방식의 핵심이죠.

   docker compose -f docker-compose.build.yaml build

4. 여기까지 동작하면 GitHub Actions 워크플로우(다른 CI 플랫폼이라도 마찬가지입니다)는 단순한 오케스트레이터로 줄어듭니다.

   name: CI/CD Pipeline
   on: [push, pull_request]
   jobs:
     build:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v2
         - name: Set up Docker Buildx
           uses: docker/setup-buildx-action@v1
         - name: Build and Test with Docker Compose
           run: docker compose -f docker-compose.build.yaml build
         - name: Push the image referenced in the docker compose file
           run: docker compose -f docker-compose.build.yaml push

이제 CI 도구가 하는 일은 빌드와 푸시, 딱 두 가지입니다. 이해할 가치가 있는 부분은 전부, 어떤 플랫폼에서든 어떤 새 팀원이든 바로 실행해 볼 수 있는 파일 안에 있습니다.

이미지 푸시

#

Compose 파일의 반가운 부수 효과 하나는 푸시가 아주 쉬워진다는 겁니다. Docker는 이미지 이름을 보고 푸시할 곳을 판단합니다. image: myprivaterepo.com/image:latest라면 myprivaterepo.com으로 푸시됩니다. 프라이빗 레지스트리라면 액세스 토큰이 필요하니, 그 부분은 사용하는 레지스트리 서비스의 문서를 참고하세요.

지금 GitHub Actions에 만족하고 있다면 서두를 이유는 없습니다. 다만 언젠가 공급자를 바꾸는 날이 오면, 마이그레이션이 “YAML 300줄 이식"이 아니라 “명령어 두 개 복사"로 끝납니다. 그리고 그날이 오기 전까지는, 빌드 디버깅을 커밋 스팸 없이 로컬에서 차분히 할 수 있고요.