Github 다른 브랜치 vercel 배포

개요

 

개인 프로젝트를 Next로 만든다면 커스텀 백엔드, 복잡한 네트워크 구성을 요구하는 경우가 아닌경우라면 Vercel가 가장 편리한 방법이다.

 

그러나, organizaiton을 만들어 배포를하거나, 자신이 만든 레포지토리가 고급 서버 스펙을 필요로 하는 경우엔 과금에 따라 망설여 지곤 한다.

 

이럴 경우에 여러 방법을 사용해 간단하게 vercel로 배포할 수 있는데 알아보자.

 

Vercel

 

Verlcel은 Next.js 기반 프로젝트 최적화된 정적/서버리스 배포 플랫폼이다.

 

졸업 후 만나본 여러 FE 팀원들이 ec2, amplify 배포 경험은 없어도, vercel 배포경험은 대게 있었다.

 

그만큼 편리성에 몰두한 vercel은 다양한 장점이 존재한다.

 

 

장점

 

1. 🔧 Next.js에 최적화된 플랫폼

• Next.js 팀이 만든 플랫폼이라 ISR, SSR, API Routes 등도 자동 지원
• 설정 없이 바로 배포 가능

 

2. 🚀 자동화된 CI/CD

• GitHub, GitLab, Bitbucket 연동하면 push나 PR만으로 자동 배포됨
• 브랜치마다 자동 Preview URL 생성

 

3. 💨 빠른 빌드와 글로벌 CDN

• 정적 사이트는 글로벌 CDN에 자동 배포되어 속도가 빠름
• Edge Network로 레이턴시 최소화

 

4. 📦 서버리스 API 지원

• Next.js API Routes, Edge Functions 사용 가능 → 간단한 백엔드도 함께 개발가능

 

5. 💁‍♀️ 초보자 친화적인 UI/UX

• 대시보드 직관적, 커밋 단위로 배포 내역 확인 가능
• 환경변수 설정, 빌드 로그 확인 등도 쉬움

 

6. 🧪 Preview 환경 분리

• 브랜치/PR마다 고유한 preview 배포가 생성됨
• 디자이너/기획자도 실시간 리뷰 가능

 

역시나 장점이 있으면 단점도 있는 법, 단점으로는 다음과 같다.

 

 

단점

 

1. 💸  프리 플랜 제약

• 빌드 횟수/시간, 서버리스 함수 시간에 제한
• 팀/비즈니스 용도로는 요금제 업그레이드 필요

 

 

2. 🧱 서버 제어권 부족

• 전통적인 서버 환경(x Node 서버 직접 실행 등)은 불가능
• 커스텀 백엔드나 DB가 필요한 경우 별도 인프라 필요

 

 

3. 🌐  복잡한 네트워크 구성 어려움

• 프록시 설정, 쿠버네티스 등 복잡한 인프라 구성은 불가능
• Edge Function 기반으로 제한적인 기능만 사용 가능

 

 

4. ⛔  Vercel 전용 개념에 대한 러닝 커브

• ISR, Edge Function, Middleware 등은 Next.js/Vercel에 특화된 개념
• 다른 플랫폼으로 이동 시 호환성 이슈 발생 가능

 

1. 해당 문제를 풀기위한 작전, 방식 자체가 안떠올라 시작 자체를 못하는 경우

 

2. 어느정도 구현은 했으나 테스트 혹은 제출 단계에서 일부 테스트 케이스를 통과하지 못하는 경우

 

이 두 가지가 단순히 많이 풀어보기 보단 위에서 말한 익숙치 않은 알고리즘, 자료구조에 대한 이해도가 낮다 생각해 코테 문제를 풀며 접하는 여러 상황에 대해서 기록하고자 했다.

 

 

문제

 

Vercel에선 GitHub Organization소속의 레포지토리의 경우 Pro plan이 필요하다.

 

심지어 팀 멤버당 달에 20달러.... 결코 작지않은 돈이다.

 

또한 빌드시간이 오래걸리는 경우엔 내가 제공하는 방법말고, pro-Plan을 적용해야한다.

 

 

방법 1.  과금 pro-Plan

 

가장 간단한 방법으로 월 20달러 과금...

 

이 방법을 꽤나 고민해볼법한 상황이 몇 존재한다.

 

배포 서버가 특정 네트워크 설정, 스펙을 요구하는 경우

-  실제로 대역폭이 1TB로 증가, 도메인 무제한, 일일배포 3000회 등 다양한 기능을 제공한다.

 

본질적인 문제였던, organization 레포 배포가 필요한 경우

 

물론 과금전에 개인 레포를 사용하며, 배포 전 필요한 기능 구현 및 QA를 진행 후 vercel로 배포를 하게된다면 비용 절감을 할 수 있다.

 

 

방법 2.  개인 레포에서 배포

 

이 방법엔 두 가지 접근 방법이 존재한다.

 

1. 꼭 organization에서 해당 레포지토리를 관리하지 않아도 되는 상황일 경우 (혼자 개발, organization기능 미 사용, 소규모 프로젝트)

-> 개인 레포지토리에서 개발을하며, vercel 배포를 진행 후 팀원들에게 url 알려주기

 

2. 팀 레포지토리를 개인 레포지토리에 fork받아 해당 레포지토리 vercel로 배포하기

 

1. team 레포지토리 fork로  받아오기

 

organization을 fork해서 vercel 배포하는 경우 개인 레포지토리 배포로 여겨지기에 무료 플랜으로도 가능하다.

 

⚠️유의점

해당 방법엔 번거로운 점이 있는데 각 점들을 확인하고 개선방법을 알아보자.

 

1. 자신이 작업한 브랜치의 deploy 성공여부를 지정한 main 브랜치외엔 확인하기 어려움

-> feature-01 브랜치로 작업한경우 해당 브랜치까지 fork 해오지 않고 배포되기에 main에 merge 후 배포해야한다,

-> 잘 확인 후 빌드하면 상관없겠지만, vercel환경에서만 추적되는 빌드에러의 경우 번거롭게 핫픽스 브랜치를 만들어 매번 merger하며 적용해야한다.

 

2. origin, upstream 브랜치 중 선택해 개발 후 sync를 진행해야한다.

-> 즉, 기본 organization에 있는 브랜치에서 개발하는 경우, 해당 브랜치에 merge후 vercel에서 배포되는 브랜치는 본인이 만든 레포지토리이기에, 본인 레포지토리에서 sync fork를 매번 진행 후 배포해야한다.

 

 

개선 방법

 

우리가 흔히 첫 pull, push를 할 때면 --set-upstream 을 완료하라고 하는데 보통 하나의 레포지토리와 연결해 origin브랜치로 지정해 merge하곤 한다.

 

우리가 작업하고 배포하는 브랜치는 각각 1. organization 내 레포지토리의 브랜치, 2. 내 깃헙 계정 레포지토리 브랜치로 나누어져 있다.

 

이제 upstream, origin 브랜치로 구분해 로컬 브랜치로 작업 내용을 가져와 내 깃헙 계정 브랜치에 push하면 원격 브랜치가 생성되기에 미리 vercel deploy가 확인 가능하다.

 

1. 연결 확인

git remote -v

 

origin만 지정한 경우 upstream은 따로 존재 하지 않을 것 이다.

 

2. 이제 upstream 브랜치를 내 브랜치로 연결하자

 

git remote add upstream (연결할 레포주소) //https://github.com/OriginalAuthor/project.git

 

입력한 경우 위와 같이 브랜치가 연결될 것 이다.

 

3. 작업 내용이 담긴 내 레포지토리(upstram)으로 push

git push upstream 브랜치명
// origin과 작업 이력 헷갈리지않게 주의!

 

 

4. 깃허브 내 레포지토리에서  push 된 내 브랜치 확인

default인 main브랜치 외에 feature/connect-admin-api를 확인할 수 있다.

그리고, 이 브랜치로 deploy된 것을 vercel에서 확인 가능하다.

 

이젠 개인 작업 브랜치로도 merge전 빌드 오류 여부를 확인 가능!

 

추가)

위와 같은 방법으로 sync하지 않고 본인 작업 내용을 바로 자기 레포지토리에 push해 deploy해 확인하는 방법도 있다.

 

하지만, 작업 이력이 기존의 organization 레포지토리와 꼬일 수 있으니 작업 브랜치에만 해당 방법을 사용하는게 좋지않을까 싶다