본문으로 건너뛰기
Previous
Next
Vercel 완벽 가이드 | 배포·Edge Functions·Analytics·환경 변수·실전 활용

Vercel 완벽 가이드 | 배포·Edge Functions·Analytics·환경 변수·실전 활용

Vercel 완벽 가이드 | 배포·Edge Functions·Analytics·환경 변수·실전 활용

이 글의 핵심

Vercel로 빠른 배포를 구현하는 완벽 가이드. Git 연동, Edge Functions, Analytics, 환경 변수, 도메인 설정까지 실전 예제로 정리. Vercel·Deployment·Edge Functions 중심으로 설명합니다.

솔직히 말하면, 프론트 배포만 놓고 보면 Vercel이 제일 쉬워요. Git 붙이고 push 하면 끝나는 쪽이 여기 쪽이에요. Netlify도 좋고 Cloudflare Pages도 멋지지만, Next·React 쓰는 팀이면 “일단 Vercel”이 제일 덜 싸우는 경우가 많아요. 정적 사이트만 올릴 땐 Netlify 쪽이 무난하다는 말도 있고, JAMstack 범용으로는 Netlify 쪽이 오래 쌓인 레시피가 많은데, Next랑 궁합은 Vercel이 밀어주는 쪽이 확실하죠.

첫 배포에서 환경 변수 안 넣고 올렸다가 API가 500으로 터진 적 있어요. 대시보드에 DATABASE_URL이랑 API_KEY 넣는 건 알고 있었는데, Production에만 넣고 Preview엔 안 넣은 거예요. PR 프리뷰 URL 열었을 때만 비어 있고, 프로덕션은 멀쩡해서 한참 찾았죠. 그 뒤로는 팀 룰로 “프리뷰에도 동일 키 넣기(값은 별도 스테이징이면 그걸로)” 정해버렸어요. 로컬에 맞추고 싶으면 vercel env pull .env.local 한 방이고, Next면 서버는 process.env, 브라우저로 내보낼 땐 NEXT_PUBLIC_ 붙인 것만 쓰는 거, 그냥 그렇게 외우면 돼요.

Vercel이란 건, 예전 ZEIT이고 Next.js 만든 쪽이 운영하는 배포 서비스예요. “프레임워크이랑 배포를 같이 가져가자”는 쪽이 강해요. AWS에서 VPC이니 로드밸런서이니 골라 엮는 것보다, 일단 올리고 보자 쪽이면 손이 덜 갑니다. AWS에서 넘어왔을 때 배포가 10분짜리에서 30초 근처로 줄었던 이야기는 꽤 흔한 패턴이에요(프로젝트·캐시 상태에 따라 다르죠).

Edge에서 돌릴지, 서버리스(Node 풀)로 돌릴지는 감이 조금 달라요. Edge는 사용자 가까이, V8 isolates 쪽이라 cold start 느낌이 거의 없다시피한데, fs 같은 건 막혀 있어요. DB 붙이고 복잡한 건 보통 Serverless 쪽. Next면 export const runtime = 'edge' 한 줄로 Edge로 보낼 수 있고, 지역은 x-vercel-ip-country 같은 헤더로 쓰는 식.

배포 자체는 저장소 연결 → 브랜치 선택 → 감지된 프레임워크로 빌드, 이 흐름이에요. CLI가 편하면 vercel 치고 로그인해서 배포해도 됩니다. PR 올릴 때마다 프리뷰 URL 생기는 건 진짜 생산성에 도움 돼요. 프리뷰만 basic auth 걸고 싶으면 VERCEL_ENV === 'preview'일 때 middleware에서 막는 식으로도 가끔 씁니다(예시는 비밀번호 하드코딩 말고 환경 변수로 빼는 게 맞고요).

@vercel/analytics랑 Speed Insights는 레이아웃에 컴포넌트 꽂으면 Core Web Vitals 쪽 보기 좋게 모아주는 쪽. “대충 감”이 아니라 숫자로 보고 싶을 때.

도메인은 대시보드 Domains에서 추가하고, DNS는 안내 나오는 대로. 보통 루트는 A로 76.76.21.21, www는 CNAME cname.vercel-dns.com 쪽으로 가는 경우가 많아요(실제로는 Vercel이 준 안내랑 레지스트라 UI를 보고 맞추는 게 정답).

vercel.json으로 리전·헤어·리다이렉트 묶을 수 있어요. 한국 트래픽만 노리면 regionsicn1 같은 걸 쓰는 식. 다만 함수 리전이랑 DB 위치가 엇갈리면 레이턴시만 늘 수 있으니, 그 부분은 같이 봐야 합니다. ISR·revalidate는 Next 페이지에서 숫자만 줘도 “대충 캐시 갱신 주기” 잡을 수 있어요.

빌드만 터질 때는 로그에서 환경 변수·Node 버전·패키지 매니저 차이부터 보는 편이에요. 간헐적 오류는 외부 API나 타임아웃, 프리뷰에만 env 없는지 같은 것도 의심 리스트에 넣을 만해요.

정리하자면, “빨리 UI 올리고 PR마다 URL 받고 싶다”면 Vercel 쪽이 제일 싸움이 적다고 봅니다. 무료 Hobby로 개인 프로젝트도 많이 돌아가고, Next만 되는 것도 아니고 Vue·Svelte·Astro도 다루죠. AWS보다 제어는 덜해도, 배포 경험은 대체로 이기기 쉽지 않아요. 팀이 이미 정한 스택이 있으면 그거 따르는 게 맞고, 제 입장에선 “처음? 그럼 Vercel부터 써보고 불만 생기면 옮기자” 정도의 순서를 추천해요.