VPS와 서버리스: 층이 올라갈 때 사라지는 것들

응답 시간을 재려고 헤더를 열었더니 이런 줄이 보였습니다.

alt-svc: h3=":443"; ma=2592000

HTTP/3를 쓰고 있으니 CDN 뒤에 있는 것이고, 그렇다면 그 CDN은 여기겠구나. 저는 이 한 줄을 근거로 특정 회사 이름을 적었습니다. dig 한 번이면 30초에 끝날 확인을 하지 않은 채였습니다.

같은 주에 같은 종류의 실수를 한 번 더 했습니다. 사설망에 있는 데이터베이스는 서버리스에서 쓸 수 없다고 잘라 말했습니다. 그때도 근거는 있었습니다.

헤더는 마지막 한 홉만 말해줍니다

뒤늦게 dig를 쳤습니다. A 레코드는 제가 생각한 회사가 아니라 VPS 사업자의 IP를 가리키고 있었습니다. whois로 확인하니 분명했습니다. 그리고 다시 헤더를 끝까지 읽으니 제가 놓친 줄이 있었습니다.

via: 1.1 Caddy

server: nginx도 같이 있었습니다. 프록시가 둘이었다는 뜻이고, 저는 그중 바깥쪽 하나도 제대로 못 맞힌 것입니다. 응답 헤더는 경로 전체가 아니라 마지막 몇 홉의 흔적입니다. HTTP/3를 지원한다는 사실은 그 앞단이 무엇인지에 대해 거의 아무것도 말해주지 않습니다.

청구서가 층을 알려줍니다

정작 그 VPS가 어떤 성격의 서비스인지는 빌링 화면이 더 정확하게 말해줬습니다.

나흘 쓰고 $0.76이 찍혀 있었습니다. 처음에는 대역폭 요금인 줄 알았는데 아니었습니다. 인스턴스가 켜져 있던 시간의 값이었고, 하루로 나누면 $0.19, 한 달이면 약 $5.7입니다. 최소 플랜의 시간요금과 정확히 맞습니다.

여기서 중요한 것은 액수가 아니라 무엇을 세느냐입니다. 방문자가 한 명도 없어도 같은 금액이 나갑니다. 트래픽과 무관하게 시간으로만 재는 것, 이게 IaaS의 정의에 가장 가까운 신호입니다. 빌린 것이 서비스가 아니라 머신이기 때문입니다.

제 구성은 PaaS를 손으로 조립한 것이었습니다

층을 따져보기 시작하니 제 배포 구성이 다르게 보였습니다.

컨테이너는 Docker Compose로 올리고, 빌드는 CI가 하고, 앞단은 nginx가 막고, 인증서는 리버스 프록시가 자동으로 받아옵니다. 각각은 그냥 필요해서 붙인 것들이었습니다. 그런데 이 목록이 Render나 Railway 같은 서비스가 자동으로 해주는 일 목록과 거의 그대로 겹칩니다.

하는 일	VPS	PaaS
OS 설치와 보안 패치	내가	플랫폼
런타임 설치와 버전 관리	내가	플랫폼
push 감지 후 빌드	내가	플랫폼
프로세스 재시작	내가	플랫폼
리버스 프록시	내가	플랫폼
TLS 인증서 발급과 갱신	내가	플랫폼
로그 수집, 헬스체크, 롤백	내가	플랫폼

저는 IaaS 위에 PaaS를 손으로 만들어 쓰고 있었습니다. 그게 나쁘다는 이야기가 아닙니다. 다만 제가 무엇을 하고 있는지 이름을 붙일 수 있게 되자, 무엇을 포기하고 무엇을 얻는 중인지가 처음으로 계산 가능해졌습니다.

같은 트래픽인데 한쪽은 $5.7이고 한쪽은 $0입니다

계산해봤습니다. 오리진의 접근 로그 114.8시간치를 세니 요청이 2,000건이었습니다. 시간당 17건입니다. 한 달로 환산하면 약 12,500건입니다.

서버리스 쪽 무료 한도는 보통 하루 10만 건, 한 달이면 300만 건 규모입니다. 제 트래픽은 그 0.4%입니다. 같은 트래픽이 한쪽에서는 월 $5.7이고 다른 쪽에서는 $0입니다.

이걸 서버리스가 우월하다는 근거로 읽으면 틀립니다. 제 트래픽이 작아서 나온 결과일 뿐입니다. 고정비와 변동비는 어딘가에서 반드시 교차하고, 그 지점을 넘어가면 방향이 뒤집힙니다. 실제로 대역폭이나 요청이 꾸준히 많은 서비스가 서버리스에서 VPS로 돌아오는 사례는 계속 나옵니다.

제가 얻은 건 어느 쪽이 싸다는 답이 아니라 질문의 형태입니다. 트래픽이 얼마나 되고 얼마나 고르게 들어오는가. 이걸 모르면 어느 쪽도 고를 수 없습니다.

층이 올라가면 네트워크가 먼저 사라집니다

여기서 두 번째 실수가 나왔습니다.

같은 주에 저는 작은 앱을 Cloudflare Workers에 올려보고 있었습니다. 데이터베이스를 어떻게 할지 정하면서, 기존에 쓰던 PostgreSQL은 사설망에 있으니 못 쓴다고 잘라 말했습니다. 공인 IP가 없으니 서버리스에서 닿을 방법이 없다는 논리였습니다.

논리 자체는 층을 정확히 짚고 있었습니다. VPC는 IaaS 층의 개념입니다. IP 주소와 네트워크 인터페이스가 실재하는 곳에서만 성립합니다. 이름만 회사마다 다릅니다.

클라우드	명칭
AWS, Google Cloud, Alibaba, IBM	VPC
Azure	Virtual Network (VNet)
Oracle Cloud	VCN
Vultr, DigitalOcean, Linode	VPC
Hetzner	Networks

VPS 사업자까지 전부 갖고 있습니다. 그런데 PaaS로 한 층 올라가면 희미해지고, FaaS로 한 층 더 올라가면 아예 없습니다. Workers에서 데이터베이스에 붙는 코드에는 호스트도 포트도 등장하지 않습니다. env.DB 같은 객체가 주입될 뿐입니다. 네트워크가 추상화된 게 아니라 없어진 것에 가깝습니다.

그래서 사설망 DB에 못 닿는다는 결론이 자연스러워 보였습니다.

사라진 것은 다리 형태로 돌아옵니다

틀렸습니다. 사라진 네트워크는 각 플랫폼에서 다리의 형태로 다시 나타납니다.

플랫폼	사설망에 닿는 방법
AWS Lambda	함수를 VPC에 직접 붙임
Google Cloud Run	VPC 커넥터, Direct VPC egress
Vercel	Secure Compute (상위 플랜)
Cloudflare Workers	Workers VPC

Cloudflare 쪽은 2026년 4월에 나왔습니다. 터널을 사설망에 연결해두고 특정 호스트와 포트를 서비스로 등록하면, Worker에서 다른 바인딩과 똑같은 모양으로 씁니다. HTTP는 fetch(), TCP 데이터베이스는 Hyperdrive를 경유합니다. 문서 기준으로 베타 기간 동안 모든 Workers 플랜에 무료입니다.

이 다리들의 공통점이 있습니다. 위층에서 없앤 개념을 아래층에서 빌려오는 통로라는 것입니다. 그러니 "서버리스에는 VPC가 없다"는 문장은 맞지만, "그래서 사설망에 못 닿는다"는 문장은 따라 나오지 않습니다. 저는 앞 문장에서 뒷 문장을 추론했고 그게 틀린 지점이었습니다.

그래서 못 하는 일이 양쪽에 다 있습니다

층을 정리하고 나니 선택 기준이 단순해졌습니다. 어느 쪽이 우월한가가 아니라 무엇을 못 하게 되는가입니다.

VPS를 버리면 못 하는 것들이 있습니다. 한 대에 서비스 여러 개를 몰아넣기, 임의의 포트 열기, 데이터베이스를 직접 운영하기, 파일시스템에 상태 남기기. 이건 편의의 문제가 아니라 가능 여부의 문제입니다.

반대 방향도 마찬가지입니다. Render나 Railway 같은 PaaS는 결국 어딘가의 가상 머신 위에서 컨테이너를 돌립니다. 그래서 "위층도 결국 서버 아니냐"는 말이 대체로 맞습니다. Workers만 예외입니다. 가상 머신도 컨테이너도 아니라 V8 isolate라서, 한 프로세스 안에 수천 개가 같이 삽니다. 아무리 잘 세팅한 VPS도 이건 흉내 낼 수 없습니다.

그리고 그 Workers로는 PostgreSQL 프로세스를 띄울 수 없습니다. 양쪽이 서로 못 하는 일을 갖고 있고, 그게 둘 다 남아 있는 이유입니다.