두 방식 비교 & 운영 실습 예시

배포 후 도메인·분석·환경 변수·전략을 다루는 시나리오 | ← 레퍼런스로 돌아가기

이 파일의 목적비교·운영 레퍼런스를 보완하는 실습 시나리오

작성일2026년 6월 13일

● 초급 배포 후 첫 운영 주소를 달고, 누가 보는지 확인

C-1초급내 도메인을 사이트에 연결하기

사이트가 my-app-xxxx.vercel.app 주소로 떠 있습니다. 미리 사 둔 myname.com 도메인을 연결해 더 그럴듯한 주소로 바꾸고 싶습니다.

단계별 실행

프로젝트 Settings → Domains에서 도메인 추가
myname.com을 입력하고 추가합니다. Vercel이 필요한 DNS 레코드를 화면에 안내합니다.
안내받은 DNS 레코드를 등록처에 입력한다
도메인을 산 곳(가비아·후이즈·Cloudflare 등)의 DNS 설정에서 안내값을 그대로 추가합니다.

대상 레코드 값

myname.com (루트) A (Vercel이 안내하는 IP)

www.myname.com CNAME (Vercel이 안내하는 값)
검증·HTTPS 자동 설정을 기다린다
DNS 전파 후 수 분~수 시간 내 Vercel이 도메인을 검증하고 HTTPS 인증서를 자동 발급합니다. 끝나면 https://myname.com으로 접속됩니다.

대상	레코드	값
myname.com (루트)	A	(Vercel이 안내하는 IP)
www.myname.com	CNAME	(Vercel이 안내하는 값)

A 레코드 IP나 CNAME 값은 외우지 말고 그때 화면에 안내된 값을 쓰세요. 시점·프로젝트에 따라 달라질 수 있습니다.

도메인이 아직 없으면 Vercel 안에서 바로 구매(vercel domains buy 또는 MCP buy_domain)할 수도 있습니다.

C-2초급방문자 분석(Web Analytics) 켜기

사이트를 공유했는데, 사람들이 실제로 들어오는지·어떤 페이지를 보는지 궁금합니다. 별도 도구 없이 Vercel 내장 분석을 켭니다.

단계별 실행

프로젝트 → Analytics 탭에서 Enable
Web Analytics를 활성화합니다. 프레임워크에 따라 @vercel/analytics 패키지를 추가하라는 안내가 나올 수 있습니다.
```
npm i @vercel/analytics
```
안내대로 컴포넌트를 추가하고 재배포
패키지 설치만으로는 데이터가 잡히지 않습니다. 반드시 @vercel/analytics의 <Analytics /> 컴포넌트를 앱 루트 레이아웃에 import해 렌더링해야 수집이 시작됩니다. AI에게 "Vercel Analytics 컴포넌트를 루트 레이아웃에 추가해줘"라고 부탁하면 적절한 위치에 넣어 줍니다. (프레임워크가 아닌 순수 정적 HTML 사이트라면 패키지 대신 대시보드에서 Enable만 하면 스크립트가 자동 주입됩니다.) 배포 후 데이터가 쌓이기 시작합니다.
대시보드에서 방문 흐름 확인

vercel.com/my-app/analytics

1,240
Visitors

3,580
Page Views

/ 42%
Top Page

Vercel Web Analytics는 쿠키 없이 익명 데이터만 모읍니다. 개인정보 동의 배너 부담이 적어 입문자가 켜기 좋습니다.

● 중급 안정적으로 굴리기 환경 분리와 두 방식의 결합

C-3중급테스트 키와 실서비스 키를 환경별로 분리

결제·AI API를 쓰는 앱입니다. 미리보기에서 실제 결제가 일어나면 큰일이라, 미리보기엔 테스트 키를, 프로덕션엔 실제 키를 따로 넣고 싶습니다.

단계별 실행

같은 이름의 변수를 환경별로 다른 값으로 등록

Settings → Environment Variables에서 PAYMENT_API_KEY를 두 번 등록하되, 적용 환경과 값을 다르게 합니다.

변수	적용 환경	값
`PAYMENT_API_KEY`	Preview, Development	테스트 키 (sk_test_...)
`PAYMENT_API_KEY`	Production	실제 키 (sk_live_...) — Sensitive

실제 키는 Sensitive로
프로덕션 키는 Sensitive로 등록해, 저장 후 대시보드에서 다시 보이지 않게 합니다(유출 위험 감소).
재배포로 반영
환경 변수는 빌드·런타임에 주입되며, 값을 바꿔도 기존 배포에는 소급되지 않으므로 변경 후 다시 배포해야 적용됩니다.

Sensitive 변수는 한 번 저장하면 값을 다시 조회할 수 없습니다. 실제 키는 별도 안전한 곳(비밀번호 관리자 등)에 보관하세요. Sensitive는 Development에서는 켤 수 없습니다.

미리보기 배포는 자동으로 Preview 환경의 변수를, 프로덕션 배포는 Production 환경의 변수를 씁니다. 그래서 같은 코드라도 미리보기에선 테스트 키로, 실서비스에선 실제 키로 동작합니다.

C-4중급두 배포 방식을 함께 쓰기 — CLI로 시작, GitHub로 정착

처음엔 CLI로 빠르게 띄워 감을 잡았습니다. 이제 꾸준히 운영하고 동료와 협업하려 하니, GitHub 연동으로 옮기고 싶습니다. 기존 프로젝트를 그대로 이어서요.

단계별 실행

코드를 GitHub 저장소에 올린다

git init -b main
git add . && git commit -m "기존 프로젝트 정리"
git remote add origin https://github.com/내계정/my-app.git
git push -u origin main

기존 Vercel 프로젝트에 저장소를 연결한다
프로젝트 Settings → Git에서 방금 만든 GitHub 저장소를 연결합니다(Connect Git Repository). 새 프로젝트를 또 만들 필요는 없습니다.
이제부터는 push가 배포를 트리거
연결 후에는 vercel 명령을 직접 칠 필요 없이, ② GitHub 연동 워크플로우(push·PR·미리보기)로 운영합니다.

CLI 직접 배포와 GitHub 연동은 같은 프로젝트를 공유할 수 있습니다. 시작은 빠른 직접 배포로, 운영은 안정적인 Git 연동으로 — 단계에 맞춰 갈아타는 것이 자연스럽습니다.

Git 연동 후에도 급할 땐 CLI(vercel --prod)나 MCP로 즉시 배포할 수 있습니다. 두 길이 한 프로젝트 위에 공존합니다.

● 고급 전략적으로 결정 팀·서비스 단계에 맞는 배포 전략

C-5고급우리 상황에 맞는 배포 전략 정하기

강의 프로젝트를 여럿이 함께 운영하게 됐습니다. 누가 어떻게 배포할지, 사고가 나면 어떻게 되돌릴지 팀 규칙을 정합니다.

결정 항목

질문	권장 선택
주 배포 경로는?	GitHub 연동 — 변경 이력·리뷰가 필요한 팀의 기본
실서비스에 직접 main push?	금지. 브랜치 + PR 미리보기 → 리뷰 → merge
급한 핫픽스는?	CLI `vercel --prod` 또는 MCP, 단 사후에 Git에도 반영
사고 발생 시?	Instant Rollback으로 즉시 멈춤 → 진정 후 `git revert`로 정리
AI(MCP)에게 권한은?	프로젝트 스코프 + 실행 전 승인
비밀값 관리는?	환경별 분리(Preview=테스트, Production=실제·Sensitive)

정리하면: 평상시 = GitHub 연동(브랜치·PR·미리보기) / 긴급 = 직접 배포(CLI·MCP) / 사고 = Instant Rollback. 세 도구가 역할을 나눠 맡습니다. 어느 하나만 고집하지 않는 것이 핵심입니다.

롤백 후에는 프로덕션 도메인 자동 할당이 꺼질 수 있어, main에 push해도 자동 반영되지 않을 수 있습니다. 정상화는 Undo Rollback 또는 vercel promote로 합니다. 플랜 차이도 기억하세요(Hobby는 직전 배포로만 롤백).

핸드북의 마지막 문서입니다. ← 핸드북 홈으로 돌아가기