Vercel의 역사: ZEIT와 Now에서 Fluid compute까지
Vercel은 흔히 "Next.js를 배포하는 곳"으로 알려져 있습니다. 현재의 결합을 보면 자연스러운 설명이지만, 제품의 출발점은 프레임워크 호스팅보다 단순했습니다. 명령어 하나로 애플리케이션을 인터넷에 올리고, 배포마다 고유한 주소를 부여하는 것이 첫 문제였습니다.
저도 Vercel을 호스팅 제품의 기능 목록으로만 설명한 적이 있습니다. ZEIT와 Now 시절부터 역사를 따라가 보니 핵심은 서버의 종류보다 배포를 다루는 단위에 있었습니다. Vercel은 소스의 각 버전을 변경 불가능한 배포로 만들고, Git과 URL을 연결해 배포 자체를 협업 도구로 바꿨습니다.
ZEIT와 Now에서 시작했습니다
Vercel은 2015년에 설립됐고, 2016년 첫 제품 now를 공개했습니다. 당시 목표는 개인 개발자가 DNS, TLS 인증서, 라우팅과 서버 설정을 각각 다루지 않고도 명령어 하나로 앱을 배포하게 만드는 것이었습니다.
now로 만든 배포에는 고유한 URL이 붙었습니다. 새 버전을 올릴 때 기존 서버의 파일을 덮어쓰는 대신 새로운 배포가 생겼습니다. 특정 버전을 URL 하나로 공유할 수 있고, 운영 도메인은 검증된 배포를 가리키도록 바꿀 수 있었습니다. 지금 Vercel이 말하는 Immutable Deployment의 초기 형태입니다.
같은 2016년 ZEIT는 Next.js를 공개했습니다. 초기 Next.js의 목표는 설정을 많이 작성하지 않고 React 애플리케이션을 서버 렌더링하고 코드 분할하는 것이었습니다. 프레임워크가 애플리케이션 구조를 알고, 배포 플랫폼이 그 구조에 맞는 인프라를 만드는 결합이 이때부터 시작됐습니다.
| 시기 | 주요 변화 |
|---|---|
| 2015년 | 회사 설립 |
| 2016년 | now와 Next.js 공개 |
| 2019년 | Git 기반 배포, Serverless Functions와 로컬 개발 경험 확대 |
| 2020년 4월 | ZEIT에서 Vercel로 사명 변경, Develop, Preview, Ship에 초점 |
| 2022년 | Edge Functions 정식 출시, Preview Deployment 댓글 기능 확대 |
| 2022년부터 2023년 | Next.js App Router와 Framework-defined Infrastructure 흐름 강화 |
| 2025년 | Fluid compute가 새 프로젝트의 기본값으로 전환, AI Cloud 범위 확대 |
Preview가 스테이징 서버를 잘게 나눴습니다
Vercel의 Git 연동은 운영 브랜치가 아닌 모든 브랜치와 Pull Request에 Preview Deployment를 만듭니다. 커밋마다 고유 URL이 생기고, 브랜치 URL은 그 브랜치의 최신 배포를 계속 가리킵니다. 운영 브랜치에 병합하면 별도의 Production Deployment가 생성됩니다.
이 구조에서 Preview는 하나뿐인 공용 스테이징 서버가 아닙니다. 동시에 열린 여러 변경 사항이 서로 다른 배포와 URL을 가집니다. 디자이너와 기획자는 로컬 실행 방법을 몰라도 실제 상호작용을 확인할 수 있고, 개발자는 특정 커밋에서 발생한 문제를 같은 배포로 다시 열 수 있습니다. 2022년에는 Preview 화면에 직접 댓글을 남기는 기능도 전체 팀으로 확대됐습니다.
배포가 변경 불가능하다는 점은 복구 방식도 바꿉니다. 문제가 생긴 운영 서버의 파일을 다시 고치는 대신, 도메인이 이전의 정상 배포를 가리키도록 되돌릴 수 있습니다. Git 커밋, 빌드 결과와 실행 인프라의 버전이 함께 움직이는 셈입니다.
Next.js는 인프라 설정의 입력이 됐습니다
Vercel이 Next.js만 지원하는 것은 아닙니다. 여러 프레임워크와 정적 빌드 결과를 배포할 수 있습니다. 그래도 Next.js와의 관계가 특별한 이유는 프레임워크 기능이 필요한 인프라를 구체적으로 드러내기 때문입니다.
정적 페이지는 CDN에 놓고, 서버 렌더링 페이지와 API Route는 함수로 만들며, 이미지 최적화와 캐시 재검증에는 별도 기능이 필요합니다. 개발자는 프레임워크 코드를 작성하고 Vercel은 빌드 결과를 분석해 이 구성 요소를 배치합니다. Vercel은 이를 Framework-defined Infrastructure라고 설명합니다.
2022년 공개된 Next.js 13의 App Router는 React Server Components와 Streaming을 중심에 놓았습니다. 요청 전체가 끝날 때까지 기다렸다가 한 번에 HTML을 보내는 방식 대신, 준비된 UI부터 전달하는 실행 모델이 중요해졌습니다. 프레임워크의 변화가 배포 플랫폼의 함수 실행 시간, 캐시와 스트리밍 방식에도 직접 영향을 주기 시작했습니다.
이 긴밀한 통합은 편리하지만 설계 판단까지 없애 주지는 않습니다. 함수가 사용자와 가까워도 데이터베이스가 먼 지역에 있으면 왕복 지연이 커집니다. 캐시 가능한 작업과 요청마다 계산해야 하는 작업을 구분하지 않으면 비용과 응답 시간이 함께 늘어납니다. Zero Config는 설정 파일을 없애는 경험이지, 시스템의 물리적 제약이 사라진다는 뜻은 아닙니다.
Serverless에서 Edge를 거쳐 Fluid로 이동했습니다
초기의 Serverless Functions는 요청이 들어올 때 격리된 실행 환경을 만들고, 트래픽이 없으면 0으로 줄이는 모델이었습니다. 서버 운영 부담은 작았지만 콜드 스타트와 한 인스턴스의 낮은 활용률이 약점이었습니다. 외부 API나 데이터베이스를 기다리는 동안에도 실행 환경의 메모리는 잡혀 있고, 동시 요청이 늘면 여러 인스턴스가 필요했습니다.
Vercel은 2022년 Edge Functions를 정식 출시해 더 가벼운 V8 기반 런타임을 전 세계 엣지에서 실행하는 선택지를 제공했습니다. 다만 Node.js의 모든 API와 라이브러리를 그대로 쓸 수 없고, 계산을 사용자 가까이에 둘지 데이터 가까이에 둘지 선택해야 했습니다. 현재 Vercel의 공식 안내는 새 프로젝트에서 Edge Runtime을 기본 답으로 삼기보다 Node.js Vercel Functions와 Fluid compute를 먼저 검토하도록 바뀌었습니다.
Fluid compute는 전통적인 서버리스의 요청 하나와 인스턴스 하나라는 결합을 느슨하게 만듭니다. 하나의 함수 인스턴스가 여러 요청을 동시에 처리하고, 새 인스턴스를 만들기 전에 이미 실행 중인 자원의 남는 용량을 사용합니다. 트래픽이 없을 때는 0으로 줄어드는 성질을 유지하면서 서버 프로세스의 자원 효율을 일부 가져온 방식입니다.
2025년 4월부터 Fluid compute는 새 Vercel 프로젝트의 기본값이 됐습니다. AI 모델 호출처럼 CPU 계산보다 외부 응답을 기다리는 시간이 긴 작업이 늘어난 것도 이 변화와 맞닿아 있습니다. 같은 해 Vercel은 Frontend Cloud에서 AI Cloud로 제품 범위를 넓히며 AI SDK, Gateway, Sandbox 같은 도구를 함수와 배포 시스템에 연결했습니다.
Vercel의 제품은 배포 URL에서 출발했습니다
Vercel의 역사를 기능 순서로만 보면 정적 호스팅에 함수와 엣지, AI 기능이 계속 붙은 것처럼 보입니다. 배포 단위로 보면 흐름은 더 일관됩니다.
소스의 한 버전
-> 변경 불가능한 빌드와 실행 인프라
-> 고유한 Preview URL
-> 검증 후 운영 도메인 연결
-> 문제 발생 시 이전 배포로 복구Now의 한 줄 배포는 Git 커밋마다 독립된 환경을 만드는 Preview로 확장됐습니다. Next.js는 코드에서 필요한 인프라를 알아내는 프레임워크가 됐고, Serverless와 Edge를 거친 함수는 Fluid compute로 실행 모델을 바꿨습니다.
제가 Vercel을 다시 설명한다면 "Next.js 전용 호스팅"보다 "Git의 버전 모델을 배포와 실행 인프라까지 확장한 플랫폼"이라고 하겠습니다. Next.js와의 통합은 그 모델을 가장 깊게 사용하는 경로지만, 출발점은 특정 프레임워크가 아니라 각 변경 사항을 바로 배포하고 공유하려는 문제였습니다.
공식 자료
함께 읽기
- 웹 플랫폼 핵심 개념 지도: URL에서 렌더링과 보안까지웹 개발을 프레임워크 이름으로만 배우면 기술이 바뀔 때마다 지식도 함께 낡아 보입니다. 하지만 브라우저가 주소를 해석하고, 서버와 통신하고, 문서를 파싱하고, 픽셀을 그리는 기본 과정은 훨씬 천천히 바뀝니다. React, Vue, Svelte와 Next.js도 이 과정 위에서 서로 다른 개발 방식을 제공합니다.
- 홈페이지 플랫폼 이전 체크리스트: 도메인, SEO, 콘텐츠, 폼, 분석 데이터홈페이지 플랫폼 이전은 새 화면을 만드는 작업만이 아닙니다. 기존 URL과 검색 노출, 도메인과 회사 메일, 게시물과 이미지, 문의 폼, 분석 태그까지 함께 옮겨야 비로소 이전이 끝납니다.
- 아임웹과 카페24에서 맞춤 개발로 넘어가야 하는 8가지 신호아임웹이나 카페24로 시작한 사이트가 성장하면 어느 순간 “이제 맞춤 개발을 해야 할까?”라는 질문이 생깁니다. 관리자 화면 밖의 엑셀 작업이 늘고, 앱과 외부 서비스를 계속 붙이는데도 업무가 매끄럽지 않기 때문입니다.
- 아임웹 vs WordPress vs Webflow vs Framer: 회사 홈페이지 제작 도구 비교회사 홈페이지를 만들 때 반드시 Next.js 같은 개발 프레임워크가 필요한 것은 아닙니다. 회사 소개, 서비스 설명, 구축 사례와 문의 접수가 중심이라면 홈페이지 빌더나 CMS가 더 빠르고 운영하기 쉬울 수 있습니다.
- 홈페이지에 백엔드는 언제 필요할까? 랜딩페이지부터 업무시스템까지랜딩페이지를 만들 때도 백엔드가 필요하다고 생각하는 경우가 있다. 반대로 로그인, 예약, 결제와 파일 업로드가 있는 서비스를 단순 홈페이지처럼 구성하려는 경우도 있다.