왜 나는 Docker를 기본 Deploy Path로 두고 싶지 않은가
Source: Dev.to
Docker은 좋은 소프트웨어입니다. 인터넷은 모든 툴링 의견을 격투 경기로 바꾸는 특별한 재능이 있기 때문에 먼저 이렇게 말하고 싶습니다.
저는 Docker를 사용합니다. 데이터베이스, 반복 가능한 CI 작업, 특이한 의존성 스택, 내부 서비스, 그리고 어디서나 동일하게 동작하는 깨끗한 시스템 이미지를 필요로 하는 모든 경우에 Docker를 좋아합니다.
하지만 저는 Docker가 모든 웹 애플리케이션의 기본 배포 경로가 되길 원하지 않습니다.
때때로 저는 작은 앱을 VPS에 올려서 바로 실행하고 싶을 뿐입니다. 그 정도는 지루하게 느껴져야 합니다.
기본 경로가 무거워졌다
많은 최신 배포 튜토리얼이 조용히 다음과 같이 바꿉니다:
# 전통적인 단계
build app
copy files to server
start app
route traffic이를 다음과 같이 바꿉니다:
# Docker‑centric 단계
write a Dockerfile
pick a base image
handle build layers
create a registry
push an image
pull it on the server
wire up compose
configure networking
mount secrets
debug why the container exits이 단계들이 악한 것은 아니며, 단지 양이 많을 뿐입니다. 많은 애플리케이션에 있어서는 이 부분이 흥미로운 핵심이 아닙니다.
사이드 프로젝트, 작은 SaaS, 웹훅 핸들러, 대시보드, 혹은 작은 내부 도구를 배포한다면, 보통 애플리케이션에 필요한 것은 몇 가지 간단한 일입니다:
- 코드를 빌드한다
- 프로세스를 시작한다
- HTTPS를 제공한다
- 충돌 시 재시작한다
- 비밀 정보를 git에서 분리한다
- 문제가 발생했을 때 로그를 확인한다
- 같은 머신에서 몇 개의 앱을 실행할 수도 있다
그 목록이 자동으로 “모두 컨테이너화한다”는 의미는 아닙니다.
컨테이너가 실제 문제를 해결한다
이 글은 Docker에 반대하는 글이 아니다. Docker는 실제로 존재하는 문제들을 해결한다:
- 재현 가능한 런타임
- 덜 신비로운 시스템 패키지
- 서비스 격리
- 더 쉬운 CI
- 공유할 수 있는 공통 아티팩트
이것들은 유용하지만, 기본값도 중요하다. Docker가 모든 배포의 첫 단계가 되면, 아주 작은 애플리케이션조차도 컨테이너 문제가 생기기 전에 컨테이너와 관련된 고민을 떠안게 된다. 개발자들은 이미지 크기, 빌드 캐시, 멀티‑스테이지 빌드, 레지스트리 인증, 컨테이너 네트워킹, 볼륨 경로, 베이스 이미지 업데이트, 그리고 프로세스가 컨테이너 내부에서 올바른 포트를 찾을 수 있는지 등에 대해 생각하기 시작한다. 모두 타당한 고민이지만, 항상 가장 먼저 해결해야 할 문제는 아니다.
VPS는 일반 프로세스를 실행할 수 있습니다
VPS는 이미 컴퓨터입니다. 프로세스를 실행할 수 있습니다. 최신 배포 가이드에서는 서버가 컨테이너 스케줄러를 실행할 때만 유용하다고 말하는 경우가 많지만, 많은 애플리케이션에서는 직접 프로세스 모델만으로도 충분합니다:
# Example process commands
bun run start
node server.js
./my-go-app
./target/release/my-rust-app핵심은 보통 **“리눅스가 이 바이너리를 실행할 수 있나요?”**가 아니라 그 주변의 모든 것입니다:
- 트래픽은 어떻게 전달되나요?
- HTTPS는 어떻게 동작하나요?
- 다운타임 없이 새 버전을 어떻게 배포하나요?
- 로그는 어디에 저장되나요?
- 비밀 정보는 어떻게 주입하나요?
- 어떻게 재시작하나요?
- 하나의 서버에서 여러 애플리케이션을 어떻게 실행하나요?
이것들은 배포 문제이며, 반드시 Docker 문제는 아닙니다.
서버를 포기하지 않고 PaaS 느낌을 원해요
PaaS의 느낌이 마음에 들어요:
deploy그리고 바로 앱이 살아나요. 또한 작은 VPS를 직접 운영하는 것도 좋아요—저렴하고 유연하며 “지루하게” 신뢰할 수 있거든요. 앱이 어디서 실행되는지 알고, SSH로 접속할 수 있고, 머신을 직접 살펴볼 수 있어요. 매 주말 프로젝트마다 클라우드 아키텍처 다이어그램을 만들지는 않으려 합니다.
제가 생각하는 이상적인 흐름은 다음과 같습니다:
tako deploy- 로컬 머신에서 앱을 빌드합니다.
- 배포 도구가 릴리스를 서버에 복사합니다.
- 서버가 앱을 일반 프로세스로 실행합니다.
- 프록시가 요청을 정상적인 인스턴스로 라우팅합니다.
- HTTPS를 처리합니다.
- 로그를 확인할 수 있습니다.
- 비밀 정보는 무작위
.env파일이 아닌 외부에서 관리됩니다.
이미지 레지스트리가 필요 없어요. 실제로 원하지 않는 한 Dockerfile도 필요 없고, 두 개 라우트 웹 앱을 위한 컨테이너 네트워킹 퍼즐도 없습니다.
그 방향을 탐구하고 있는 것이 바로 Tako입니다. 자체 서버에서 앱을 실행하기 위한 작은 배포 도구죠.
지루한 경로가 바로 행복한 경로가 되어야 합니다
거의 실망스러울 정도로 평범하게 느껴지는 배포 버전이 있습니다:
tako init
tako servers add
tako deploy그것이 내가 원하는 지루함의 종류입니다—여기서 말하는 지루함은 다음과 같은 의미입니다:
- 첫 번째 배포 전에 개념이 적을수록
- 인프라 전용으로 생성되는 파일이 적을수록
- 작은 앱에 필요한 움직이는 부품이 적을수록
- 간단한 실수가 숨어 있을 수 있는 장소가 적을수록
- “잠깐, 이게 Docker 문제인가 앱 문제인가?” 하는 순간이 적을수록
기본 경로는 앱을 먼저 온라인에 올리는 데 최적화되어야 합니다. 이후에 앱이 컨테이너가 필요하게 되면 그때 컨테이너를 사용하면 됩니다.
Docker는 선택 사항이어야지 입장료가 되어서는 안 됩니다
웹은 강력한 도구를 필수 도구로 바꾸는 습관이 있습니다. Docker는 강력하고 그에 걸맞은 자리를 차지하지만, 모든 배포가 개발자에게 컨테이너 레시피 작성을 요구하면서 시작해야 한다고는 생각하지 않습니다.
많은 프로젝트에 대해 가장 좋은 배포 경로는 아직도 다음과 같습니다:
- 앱을 빌드한다
- 서버에 올린다
- 실행한다
- 트래픽을 라우팅한다
- 업데이트를 지루하게 만든다
이는 구식이라기보다 좋은 추상화일 뿐입니다. 기본 배포 경로는 서버가 여러분의 앱 실행을 도와주는 느낌이어야 하며, 점심 먹기 전까지 플랫폼 엔지니어가 되라고 강요하지 않아야 합니다.