Vercel의 팀 플랜 과금 우회부터 BFF 서버리스 요금 분석까지

최근 AI 에이전트를 활용한 바이브 코딩이 트렌드로 자리 잡으면서, 프론트엔드 생태계에서 Vercel의 입지는 더욱 강력해진 것으로 알고 있습니다. 사내에서도 비용 절감과 배포 편의성을 위해 Vercel을 도입하자는 의견이 나왔습니다.

솔직히 저는 처음에는 회의적이었습니다. 이미 Cloudflare를 사용하고 있는 상황에서 굳이 기능이 겹쳐 보이는 Vercel을 도입해 러닝 커브를 키울 필요가 있을까 싶었습니다. 하지만 제 개인 포트폴리오를 AWS에 호스팅하며 매월 약 4만 원의 고정 유지비용을 지불하고 있던 터라, 초기 비용이 거의 들지 않는 Vercel의 이점은 직접 테스트해 볼 충분한 가치가 있었습니다.

하지만 Vercel을 실무 하네스에 연동하려다 보니 두 가지의 비용적 함정 을 만났고, 이를 기술적으로 돌파하고 분석한 과정을 공유합니다.

The Problem 1: Vercel Git Integration의 함정과 $20

Vercel의 가장 큰 장점은 GitHub 레포지토리를 연결해 두면 자동으로 배포해 주는 'Git Integration'입니다. 하지만 여기에는 치명적인 함정이 있습니다. 프로젝트에 기여하는(Commit을 남기는) 팀원이 늘어날 때마다 개발자 1명당 매월 $20의 고정 비용 이 발생합니다. 프로젝트 단위로 의뢰를 받는 에이전시 특성상, 이는 눈덩이처럼 불어날 수밖에 없는 구조였습니다.

The Solution 1: Vercel CLI와 GitHub Actions를 활용한 'Custom CI'

이 비용을 우회하고 배포 제어권을 가져오기 위해, Git Integration을 해제하고 GitHub Actions와 Vercel CLI를 결합한 Custom CI 파이프라인 을 구축했습니다.

1. Infisical을 통한 인증 정보 동적 주입

Vercel에 접근하기 위한 VERCEL_TOKEN 등을 GitHub Secrets에 하드코딩하지 않고, 실행 시 중앙 환경변수 서버인 Infisical에서 동적으로 주입받아 보안을 극대화했습니다.

2. GitHub Actions 러너에서 빌드 위임

- name: Pull Vercel environment info
  run: vercel pull --yes --environment=${{ steps.env.outputs.vercel_env }} --token=${{ steps.vercel-creds.outputs.token }}

- name: Build with Vercel
  run: vercel build ${{ steps.env.outputs.prod_flag }} --token=${{ steps.vercel-creds.outputs.token }}

Vercel 서버의 빌드 리소스를 쓰지 않고, GitHub Actions 환경에서 vercel pull과 build를 수행하여 산출물(.vercel/output)을 생성합니다.

3. 사전 빌드된 결과물만 Vercel로 전송

- name: Deploy to Vercel
  run: |
    vercel deploy --prebuilt ${{ steps.env.outputs.prod_flag }} \
      --token=${{ steps.vercel-creds.outputs.token }} \
      --meta githubCommitAuthor="${{ github.actor }}" \
      --meta githubCommitSha="${{ github.sha }}" ...

이 파이프라인의 핵심입니다. --prebuilt 옵션으로 GitHub Actions에서 완성된 산출물만 쏘아 올립니다. Vercel 대시보드에 커밋 로그를 살리기 위해 --meta 태그로 GitHub의 메타데이터를 직접 매핑해 주었습니다.

결과적으로 팀원들은 Vercel에 초대받지 않아도, 평소처럼 Push만 하면 토큰 기반으로 배포가 완료되어 인당 과금($20)을 완벽히 방어 했습니다.

The Problem 2: 단순 계정료를 넘어선 '서버리스 실행 시간'의 진짜 비용

팀 플랜 과금을 방어하고 나니 안심이 되었지만, 아키텍처를 더 깊게 파고들수록 진짜 고민해야 할 지점은 따로 있었습니다. 바로 '렌더링 방식과 BFF 구조에 따른 서버리스 실행 비용(GB-hours)' 입니다.

사내 프로젝트들이 BFF(Backend For Frontend) 구조를 띠다 보니, 프론트엔드 서버가 API 서버의 응답을 기다리는 시간이 그대로 Vercel의 실행 시간 요금으로 청구되는 구조였습니다. 트래픽이 적을 땐 클라우드보다 저렴하겠지만, 트래픽이 몰리면 어떻게 될지 요금 시뮬레이션(하루 50만 건, 월 1,500만 건)을 돌려보았습니다.

결과는 충격적이었습니다. 응답 시간이 1초에서 5초로 늘어나는 것만으로 요금이 약 5배 폭증 하여 111만 원에 달했습니다. 즉, 외부 API 지연 등 우리가 통제할 수 없는 요인에 의해 인프라 비용이 치솟을 수 있다는 뜻입니다.

The Result & Retrospective

Vercel은 분명 세팅 비용이 거의 들지 않고 최고의 DX를 제공합니다. 커스텀 CI를 통해 인당 과금 리스크도 해결했습니다. 하지만 대규모 트래픽 스파이크가 발생했을 때의 막대한 스케일 인/아웃(Scale in/out) 비용과, Cloudflare가 제공하던 강력한 엣지 단의 보안 장치들을 제대로 사용할 수 없다는 점 은 뼈아픈 트레이드오프입니다.

이러한 불확실성 때문에, 당장은 Vercel의 생산성을 누리되 실제 서비스를 운영하며 데이터를 축적해 보기로 했습니다. 만약 트래픽 증가로 인해 비용 효율이 역전되거나 보안적 한계가 명확해진다면, 언제든 다시 AWS나 Docker 기반의 클러스터로 전환할 수 있도록 아키텍처를 유연하게 유지하는 것이 이번 엔지니어링의 최종 결론입니다.