두 방식 비교 & 운영 기능

GitHub 연동과 MCP·직접 배포의 장단점, 그리고 배포 후 운영 기능  |  공식 문서: vercel.com/docs

참조 문서 URL/git · /vercel-mcp · /domains · /instant-rollback
문서 수집일2026년 6월 13일
비교 표기 주의"GitHub vs MCP"를 한 문서로 직접 대조한 공식 문단은 없습니다. 아래 비교는 각 기능의 개별 공식 문서를 근거로 정리한 것이며, 어느 한쪽이 우월하다는 공식 권장은 아닙니다.

★ GitHub 연동 vs MCP·직접 배포 — 핵심 비교

이 핸드북의 중심 질문입니다. 두 방식은 같은 목적지(라이브 사이트)로 가는 다른 길이며, 경쟁이 아니라 상황에 따라 갈아타는 도구입니다.

🔗 GitHub(Git) 연동 배포

저장소를 연결해 push/PR로 자동 배포. 표준 협업 워크플로우.

장점
  • 변경 이력이 Git에 남아 추적·되돌리기가 명확
  • PR마다 미리보기 + 자동 코멘트로 팀 리뷰가 쉬움
  • 프로덕션/프리뷰가 브랜치로 깔끔히 분리
  • 한 번 설정하면 이후 자동 — 사람 개입 최소
단점
  • 초기 설정(저장소·권한·Import) 필요
  • Git 개념(브랜치·커밋·PR)을 알아야 함
  • 한 번 띄워 보는 1회성엔 절차가 무거움
🤖 MCP · CLI · v0 직접 배포

AI·터미널·v0로 명시적 명령을 내려 즉시 배포.

장점
  • Git 없이 즉시 — "배포해줘" 한마디 / vercel 한 줄
  • 만들고-배포-로그확인-수정 폐루프가 안 끊김
  • AI 반복 개발(바이브코딩)과 궁합이 최상
  • v0는 코드를 거의 안 쓰고도 배포 가능
단점
  • 변경 이력·리뷰 흐름이 약함(직접 배포 시)
  • MCP는 AI에게 계정 권한을 주는 보안 부담
  • 팀 협업·승인 체계엔 그대로는 부족

한눈에 보는 비교 표

관점GitHub 연동MCP·CLI·v0 직접
트리거git push / PR / merge명시적 명령("배포해줘", vercel, 버튼)
초기 설정저장소 연결·권한 부여 필요CLI 로그인 또는 MCP 인증만
변경 이력Git 커밋·PR로 완전 기록직접 배포 시 약함(Git 미사용 가능)
팀 협업·리뷰★ PR 미리보기·코멘트로 강함그대로는 약함(개인·빠른 작업용)
속도(1회성)설정 후엔 빠르나 첫 설정이 무거움★ 즉시
AI 반복 개발 적합성보통★ 폐루프로 최적
보안 고려GitHub 권한 범위AI에 계정 권한 위임 — 스코프·승인 필수
롤백Instant Rollback / git revertvercel rollback / 대시보드

언제 무엇을 쓰나

어느 방식으로 시작할까? (결정 가이드) 현재 상황에 따라 네 가지 분기로 시작 방식을 안내하는 세로 결정 플로우. 빠르게 한 번만 띄우기는 MCP CLI 직접, AI와 대화하며 만들고 즉시 확인 수정은 MCP 직접 폐루프, 코드 거의 안 쓰기는 v0, GitHub에 코드가 있고 지속 운영 팀 협업은 GitHub 연동. 현실의 정답은 둘 다. 어느 방식으로 시작할까? (결정 가이드) 지금 내 상황은? 빠르게 한 번만 띄워 보고 싶다 MCP · CLI 직접 AI와 대화하며 만들고즉시 확인·수정 MCP 직접 (폐루프) 코드 거의 안 쓰고 만들고 싶다 v0 코드가 GitHub에 있고지속 운영 / 팀 협업·리뷰 GitHub 연동 현실의 정답은 ‘둘 다’ — 직접 배포로 시작해 GitHub 연동으로 정착
그림. 상황별 시작 방식 결정 가이드
현실의 정답은 "둘 다"입니다. 흔한 경로는 ③ CLI/MCP로 빠르게 띄워 감을 잡고 → ② GitHub 연동으로 정착하는 것입니다. v0도 GitHub에 연결하면 두 방식이 한 도구 안에서 만납니다. 처음부터 하나를 고집할 필요가 없습니다.
MCP 직접 방식은 편리하지만 AI에게 내 Vercel 계정 권한을 위임한다는 점을 잊지 마세요. 팀·실서비스에서는 프로젝트 스코프 URL(https://mcp.vercel.com/<org>/<project>) 등록과 실행 전 승인을 기본값으로 두는 것이 안전합니다. (③ M-5 참고)

도메인 연결

모든 배포는 기본 *.vercel.app 주소를 받습니다. 내 도메인(예: myname.com)을 연결하면 자동으로 HTTPS 인증서까지 설정됩니다.

연결 방법

  1. 프로젝트 Settings → Domains에서 도메인 입력 후 추가
  2. Vercel이 안내하는 DNS 레코드를 도메인 등록처(또는 DNS 제공자)에 추가
    • 루트(apex) 도메인: A 레코드를 Vercel이 안내하는 IP로
    • 서브도메인(예: www): CNAME 레코드를 Vercel이 안내하는 값으로
  3. DNS 검증이 끝나면 수 분 내 인증서가 프로비저닝되어 HTTPS가 켜짐
A 레코드 IP나 CNAME 대상 같은 구체값은 시점·프로젝트에 따라 다를 수 있으니, 고정값을 외우지 말고 Vercel 대시보드가 그때 안내하는 값을 그대로 입력하세요. 인증서는 Let's Encrypt로 자동 발급됩니다.

환경 변수 운영

API 키 같은 값을 코드 밖으로 분리해 안전하게 관리합니다. 저장 시 암호화되며, 환경별로 다른 값을 둘 수 있습니다.

환경용도
Development로컬 개발(vercel dev, vercel env pull)
Preview미리보기 배포 — 테스트용 키 권장
Production실서비스 — 실제 키
환경별 변수 — 같은 코드, 다른 값 코드에서는 process.env.API_KEY라는 하나의 이름을 쓰지만, Development와 Preview에는 테스트 키, Production에는 실제 키(Sensitive)가 주입되어 각 환경의 배포에 서로 다른 값이 들어간다. 환경별 변수 — 같은 코드, 다른 값 코드에서: process.env.API_KEY (이름은 하나) Development 값: 테스트 키 Preview 값: 테스트 키 Production 실제 키 (Sensitive) 그 환경의 배포에 주입 그 환경의 배포에 주입 그 환경의 배포에 주입 미리보기엔 테스트 키, 실서비스엔 실제 키 — 사고를 예방
그림. 같은 코드, 환경마다 다른 변수 값

관리 방법

Sensitive(민감) 변수는 한 번 저장하면 대시보드나 vercel env ls로 값을 다시 볼 수 없습니다(보안상 의도된 동작). Preview·Production에서만 켤 수 있고 Development에서는 켤 수 없습니다. Vercel은 빌드 로그에 노출된 민감값을 자동으로 가려([REDACTED]) 표시하려 시도합니다. 한편 Sensitive 변수는 대시보드·vercel env ls에서 값이 가려지지만, 빌드·실행에는 실제로 주입되어야 하므로 vercel env pull로 로컬 .env 파일에는 평문으로 내려받아집니다 — 그래서 pull로 받은 파일은 절대 커밋하지 말고 .gitignore에 두어야 합니다. 또한 환경 변수를 바꾸면 재배포해야 반영됩니다.

함수 & 엣지

서버 로직(로그인·결제·DB·AI 호출)을 실행하는 부분입니다.

구분핵심
Vercel Functions
(Node.js 런타임)
권장 방식. 완전한 Node.js 환경에서 서버 코드 실행. 함수별 메모리·실행 시간은 vercel.jsonfunctions로 조정
Routing Middleware요청 처리 전에 먼저 실행되어 응답을 개인화·리다이렉트(캐시보다 앞단)
Fluid Compute서버리스+서버의 장점을 결합한 실행 모델. 2025-04-23부터 신규 프로젝트 기본 활성화. AI처럼 대기 많은 작업의 비용을 크게 절감(Active CPU 과금)
Region함수 실행 리전. 기본 iad1(워싱턴 D.C.). Pro는 다중 리전 구성 가능
요청이 처리되는 흐름 방문자 브라우저에서 출발한 요청이 Routing Middleware를 거쳐, 정적 자산은 CDN에서 즉시 전달되고 동적 요청은 Vercel Function이 실행되어 응답으로 합류하는 흐름을 보여주는 다이어그램. 요청이 처리되는 흐름 방문자 브라우저 Routing Middleware (요청 처리 전 가공·개인화) 정적 자산 전 세계 CDN에서 즉시 전달 Vercel Function 서버 로직 실행 (인증·DB·AI 호출) 응답 정적은 CDN이 즉시, 동적은 함수가 실행해 응답합니다
그림. 정적 자산·함수·미들웨어를 거치는 요청 흐름
과거 Edge Functions는 deprecated 상태입니다(수집일 기준). 새 코드는 Node.js 런타임의 Vercel Functions를 쓰세요.

롤백 & 승격

프로덕션 도메인이 어떤 배포를 가리킬지 수동으로 바꾸는 기능입니다.

동작의미재빌드
Instant Rollback과거에 프로덕션이었던 배포로 즉시 되돌림(도메인 재할당)없음 — 빠름
Promote (Preview→Prod)미리보기 배포를 프로덕션으로 승격완전 재빌드
Promote (Staged)도메인 미할당 상태로 만든 프로덕션 빌드를 승격없음
배포 생명주기와 즉시 롤백 가로 타임라인에 배포 #1, 안정 배포 #2, 오류 배포 #3이 시간순으로 놓여 있다. Production 포인터가 처음 오류 배포 #3을 가리키다가 Instant Rollback 곡선 화살표를 통해 안정 배포 #2로 즉시 되돌아간다. 하단에는 롤백 후 도메인 자동 할당이 잠시 꺼진다는 주황 경고가 있다. 배포 생명주기와 즉시 롤백 Production 포인터 Production 포인터 배포 #1 배포 #2 (안정) 배포 #3 (오류!) Instant Rollback (재빌드 없음, 즉시) 시간 ⚠ 안전장치 롤백 후 도메인 자동 할당이 잠시 꺼짐 — 사고 재발 방지용 안전장치. 고친 뒤 Undo Rollback / vercel promote 로 복귀.
그림. 배포 타임라인과 Instant Rollback
Instant Rollback은 재빌드하지 않으므로 빠르지만, 롤백 시점의 빌드·환경 변수 상태로 돌아갑니다. 또 롤백 후엔 프로덕션 도메인 자동 할당이 꺼져, main push가 자동 반영되지 않을 수 있습니다 — Undo Rollback 또는 vercel promote로 정상화합니다. 플랜 차이: Hobby는 직전 배포로만, Pro/Enterprise는 과거 모든 프로덕션 배포로 롤백 가능.

분석 & 관측

기능무엇을 보여주나
Web Analytics방문자·인기 페이지·유입 경로·지역·OS·브라우저. 쿠키 없이 익명 데이터만 수집(프라이버시 친화). 무료 플랜은 월 이벤트(데이터 포인트) 한도가 있어 초과 시 수집이 중단되거나 상위 플랜이 필요할 수 있습니다
Speed Insights실제 사용자 기준 성능 지표(Core Web Vitals: LCP·CLS·FCP). @vercel/speed-insights로 설정
Observability에러·트래픽·함수 성능/비용을 쿼리·시각화. 이슈 탐지·진단의 "관제탑"
입문 단계에서는 Web Analytics를 켜 두는 것만으로도 "사람들이 어떤 페이지를 보는지"를 알 수 있어 유용합니다. 성능 튜닝이 필요해지면 Speed Insights를 추가하세요.

참고 링크

다음 문서: 운영 실습 예시 → · 핸드북 홈 →