Vercel이 Dockerfile을 직접 실행한다는 것의 의미
Vercel은 그동안 프론트엔드와 서버리스 함수 중심의 플랫폼으로 인식되어 왔다. 그런데 최근 Dockerfile.vercel 파일 하나로 어떤 컨테이너 기반 서버든 Vercel 위에서 실행할 수 있는 기능이 공개됐다. Go, Spring Boot, Rails, Laravel, ASP.NET, nginx 뒤에 붙는 웹 서버까지 — HTTP를 말하고 포트를 리슨하는 서버라면 스택에 관계없이 동일한 방식으로 배포할 수 있다. Java 백엔드 개발자 입장에서 보면, Spring Boot 애플리케이션을 별도의 컨테이너 레지스트리나 쿠버네티스 클러스터 없이 그대로 Vercel에 올릴 수 있다는 뜻이다.
작동 방식: 두 개 파일로 배포 완료
핵심 규칙은 단 하나다. 서버가 $PORT 환경변수로 지정된 포트를 리슨해야 한다. Vercel은 이 포트로 트래픽을 라우팅한다.
프로젝트 루트에 Dockerfile.vercel 파일을 추가하면 Vercel CLI가 이미지를 빌드하고, 내부 레지스트리에 저장하고, Fluid compute 위에 배포한다. 아래는 Go 예시지만 구조는 어느 스택이든 동일하다.
# Dockerfile.vercel
FROM golang:1.24-alpine AS build
WORKDIR /src
COPY . .
RUN go build -o /server main.go
FROM alpine:3.20
COPY --from=build /server /server
CMD ["/server"]
멀티스테이지 빌드로 컴파일 후 최소한의 Alpine 이미지만 실행 이미지로 사용하는 전형적인 패턴이다. Spring Boot라면 FROM eclipse-temurin:21-jre 기반의 이미지를 동일한 파일명으로 작성하면 된다.
배포는 단 한 줄이다.
vercel deploy
이 명령 하나로 이미지 빌드, 레지스트리 저장, Fluid compute 배포, 프로덕션 URL 발급이 순서대로 처리된다. git push 시에는 자동으로 이미지를 재빌드하고 새로운 프리뷰 URL을 제공한다.
인프라 부담 없는 배포가 실무에서 갖는 의미
기존 컨테이너 배포 플로우는 결코 가볍지 않다. ECR 또는 Docker Hub에 이미지를 푸시하고, ECS 태스크 정의를 업데이트하거나 쿠버네티스 매니페스트를 수정하고, 로드밸런서 설정을 확인하는 과정이 따라온다. 소규모 팀이나 사이드 프로젝트, 내부 툴링 서버에서는 이 오버헤드가 실제 개발 속도를 갉아먹는다.
Vercel의 이 기능은 그 복잡도를 제거한다. 로컬에 Docker 데몬이 필요 없고, 별도 레지스트리를 운영할 필요도 없으며, 클러스터를 직접 관리할 일도 없다. 과금은 실제 CPU 사용량 기반이라 트래픽이 없으면 비용도 발생하지 않는다. 프로덕션 서비스보다는 MVP, 내부 API 서버, 팀 도구, 백오피스 서비스 등에 특히 적합한 포지셔닝이다.
다만 Fluid compute는 서버리스 컨테이너 모델에 가깝기 때문에, 장기 커넥션이나 WebSocket, 배치성 백그라운드 처리가 중심인 서비스에서는 동작 방식을 사전에 검토해야 한다.
정리
Dockerfile.vercel파일 하나로 어떤 HTTP 서버든 Vercel에 배포 가능하며, Spring Boot도 예외가 아니다- 컨테이너 레지스트리·클러스터 운영 없이
vercel deploy한 줄로 빌드~배포~URL 발급이 완결된다 - CPU 사용량 기반 과금과 간소한 배포 플로우는 소규모 서비스·내부 툴에 실질적인 이점을 제공하지만, 장기 커넥션 등 서버리스 제약은 사전 확인이 필요하다