최근 Organization에 있는 repo를 호스팅하려고 보니, Pro 요금제를 사용하라는 안내를 받았다.
20 달러가 3만원이 넘어가는 기적의 고환율 시대에 더 요금을 내기 싫었던 나는, 여차저차 github action과 개인 레포를 호스팅하는 편법으로 무사히 ci/cd 설정을 마칠 수 있었는데, 문득 vercel 등장 이전에는 heroku나 netlify에서 구린 성능과 느려터진 배포 속도로 고생하거나, 삐끗하면 요금 폭탄이 날아드는 aws s3 + cloudfront를 향해 미지의 발걸음을 내디뎌야 했던 과거가 떠올랐다.
프론트엔드 개발자들의 사이드 프로젝트 개발 환경에서 vercel은 가히 금융계에서 토스의 등장과도 같은 게임 체인저라고 볼 수 있는데, 어떻게 배포를 고수준으로 간편하게 제공할 수 있는지 그 동작 구조가 궁금해졌다.
배포는 Vercel이 지원하는 35개 이상의 프레임워크 중 하나로 작성된 코드나 Build Output API를 사용하여 시작된다. Vercel CLI를 통해 또는 git 저장소에 코드를 푸시하여 배포를 생성할 수 있는데, Vercel Git Integration은 자동으로 커밋을 감지하고 새로운 배포를 트리거한다.
CLI에서 트리거된 배포 프로세스는 두 가지 API 요청으로 시작되는데,
먼저 프로젝트 파일을 확장 가능하고 안전하며 내구성이 뛰어난 데이터 저장 서비스(Amazon S3)에 업로드하기 위한 POST 요청이 이루어진다.
파일이 저장 서비스에 성공적으로 업로드되면, 빌드 및 배포 프로세스를 시작하기 위한 Vercel의 API 엔드포인트 중 하나에 또 다른 POST 요청이 이루어진다.
배포가 생성되기 전에 Vercel은 먼저 사용자를 인증하고 요청을 검사하여 무단 접근과 무결성 손실을 방지하기 위해 요청의 진위와 사용자의 배포 권한을 확인한다. 또한 vercel.json 파일의 Vercel 구성을 검증한다.
모든 것이 확인되면 배포가 빌드를 위해 Deployment Queue(Amazon Simple Queue Service, SQS)에 예약된다. Vercel의 빌드 컨테이너는 프로젝트의 요금제에 따라 충분한 빌드 동시성이 있다면 즉시 빌드 프로세스를 시작할 수 있다.
→ Hobby 팀은 1개의 동시 빌드, Pro 팀은 최대 12개, Enterprise 팀은 최대 동시성을 위해 사용자 지정 수량의 빌드 슬롯을 구매 가능
deploying queue에서 해당 빌드가 준비되었다는 메시지를 빌드 컨테이너가 꺼내오면, 다음 단계가 시작된다.
