Vercel 배포와 CI/CD
"Git Push만 하면 끝인 줄 알았다"
11년차 QA 엔지니어로서 개발을 시작했을 때, 배포는 정말 간단한 작업이라고 생각했습니다. 과거 한 때, 개발자들이 "푸시했어요"라고 말하면 몇 분 후 운영 환경에 반영되는 걸 보며, 'Git push만 하면 알아서 다 되는구나'라고 생각했죠.
그런데 직접 해보니... 이게 뭐라고 이렇게 복잡한지. 특히 환경별로 다른 설정, 다른 도메인, 다른 환경 변수를 관리하면서 자동 배포를 구성하는 건 정말 쉽지 않더라고요.
시작은 단순했다: Vercel의 마법
처음 Vercel을 만났을 때의 감동을 잊을 수 없습니다. GitHub 레포지토리를 연결하고, 몇 번의 클릭만으로 배포가 완료되다니!
"와, 이게 바로 현대적인 배포구나!" 싶었죠. 근데 이게 시작일 뿐이었습니다.
브랜치별 자동 배포: 첫 번째 함정
Vercel의 가장 매력적인 기능 중 하나는 브랜치별 자동 배포였습니다. develop 브랜치에 푸시하면 개발 환경으로, main 브랜치에 푸시하면 운영 환경으로 자동 배포되는 거죠.
실제로는 이렇게 됐습니다.
"아니, 왜 URL이 이렇게 길어?"
모든 브랜치가 자동으로 배포되면서 각각 고유한 URL을 가지게 되더라고요. 처음엔 신기했지만, 곧 문제가 생겼습니다.
환경 변수의 악몽: "왜 개발에서는 되는데..."
가장 큰 문제는 환경 변수 관리였습니다. 로컬에서는 .env 파일로 관리하지만, Vercel에서는 Dashboard에서 관리해야 했죠.
Vercel Dashboard에서 환경 변수를 설정하는 건 이렇게 생겼습니다.
1. Project Settings → Environment Variables
2. Key, Value 입력
3. Environment 선택 (Production, Preview, Development)
4. Save
"간단하네!" 싶었는데, 여기서 첫 번째 실수를 했습니다.
실수 1: Preview vs Development 환경의 차이
develop 브랜치를 Development 환경으로 생각하고 환경 변수를 설정했는데, 실제로는 Preview 환경이었던 거죠. 이 때문에 개발 환경에서 환경 변수를 못 읽는 문제가 발생했습니다.
실수 2: 백엔드 환경 변수 동기화
더 큰 문제는 백엔드였습니다. Frontend와 Backend를 모두 Vercel에 배포하면서, 각각의 환경 변수를 따로 관리해야 했죠.
"잠깐, 서로의 URL을 알아야 하는데, 배포 전까지는 URL을 모르잖아?"
이 순환 참조 문제를 해결하기 위해 와일드카드를 사용했습니다.
배포 전 검증 스크립트: 실수를 줄이기 위한 노력
이런 실수들을 겪고 나서, 배포 전에 환경을 검증하는 스크립트를 만들었습니다.
Vercel.json: 배포 설정의 중앙 집중화
배포 설정을 코드로 관리하기 위해 vercel.json을 활용했습니다.
GitHub Actions와의 통합: 진정한 CI/CD
Vercel의 자동 배포는 좋지만, 더 복잡한 검증이 필요했습니다. GitHub Actions를 통해 배포 전 검증을 강화했죠.
배포 모니터링: 배포 후가 진짜 시작
배포가 성공했다고 끝이 아니었습니다. 실제로 잘 동작하는지 확인이 필요했죠.
https://gist.github.com/jamescompany/592d83fffe1710b81a568bd21fac5f38
롤백 전략: 실수했을 때를 대비하여
운영 배포 후 문제가 발생했을 때를 대비한 롤백 전략도 필요했습니다.
환경별 배포 전략 정리
결국 이런 전략으로 정착했습니다.
1. 개발 환경 (develop branch)
자동 배포 활성화
모든 커밋마다 배포
환경 변수는 Preview 환경으로 설정
실패해도 큰 문제 없음
2. 운영 환경 (main branch)
PR 머지 시에만 배포
GitHub Actions 검증 필수
배포 전 스테이징 환경 테스트
배포 후 헬스 체크 필수
롤백 계획 준비
3. Feature 브랜치
자동 배포 비활성화 (리소스 절약)
필요시 수동으로 Preview 배포
PR 단계에서 Preview URL로 테스트
깨달은 점들
1. 배포는 코드를 옮기는 것 이상이다
단순히 파일을 서버에 올리는 게 아니라, 환경 설정, 의존성, 보안, 모니터링 등 모든 것이 조화롭게 동작해야 합니다.
2. 환경 변수 관리는 정말 중요하다
잘못된 환경 변수 하나가 전체 서비스를 마비시킬 수 있습니다. 특히 운영 환경에서는 더욱 신중해야 합니다.
3. 자동화는 좋지만 검증은 필수다
"자동 배포니까 안심"이 아니라, 자동화됐기 때문에 더 철저한 검증이 필요합니다.
4. 롤백 계획은 보험이다
"실수하지 않으면 되지"가 아니라, 실수했을 때 빠르게 복구할 수 있는 계획이 필요합니다.
QA 관점에서의 교훈
이제 개발자가 "배포했어요"라고 할 때, 그 뒤에 숨은 복잡성을 이해하게 됐습니다.
배포 전: 어떤 검증을 거쳤는지
배포 중: 어떤 프로세스로 진행되는지
배포 후: 어떻게 모니터링하고 있는지
이런 이해를 바탕으로 더 나은 배포 관련 테스트 케이스를 작성할 수 있게 됐죠.
"Git push만 하면 끝"이라고 생각했던 제게, Vercel은 현대적인 배포의 편리함과 동시에 그 복잡성을 모두 보여줬습니다.
이제는 배포 파이프라인을 보면서 각 단계에서 무슨 일이 일어나는지 이해하고, 문제가 생겼을 때 어디를 확인해야 하는지 알게 됐습니다. 무엇보다 개발자들이 "배포 롤백해야 할 것 같아요"라고 할 때의 그 무게감을 이해하게 됐죠.
다음 편에서는 Frontend와 Backend 각각의 패키지 관리, 특히 yarn과 uv pip을 함께 사용하면서 겪은 의존성 관리의 이중고에 대해 이야기하겠습니다.
"package.json이랑 requirements.txt만 있으면 되는 거 아니야?"라고 생각했던 제가 얼마나 순진했는지...(ㅎㅎ)
