들어가며
개발을 처음 시작했을 때, 나는 배포를 엄청 거창한 뭔가라고 생각했다.
근데 막상 프로젝트를 만들고Vercel을 써보니까, 그냥 GitHub에 코드 푸시만 하면 자동으로 웹사이트가 딱! 배포됐다.
너무 간단해서 “아, 배포란 건 그냥 git push만 하면 끝나는구나” 하고 넘겨버렸었다.
그런데 조금 더 알아보니까 배포에는 여러 기술이 있고, 또 사용자를 어떻게 새 버전에 노출시킬지 전략도 있다는 걸 알게 됐다.
지금까지는Vercel만 써본 입장이지만, 이번 기회에 배포의 기본 개념부터 전략까지 정리해보려고 한다.
나처럼 “Vercel밖에 안 써봤다”거나 “배포가 그냥 서버에 올리는 거 아닌가?”라고 생각했던 분들이 읽으면 같이 감 잡을 수 있을 거다.
2. 내가 처음 접한 배포: Vercel
내가 처음 “배포”라는 걸 직접 해본 건
Vercel이었다.
(사실 그 전에Netlify로 한 번 배포해본 적은 있다 ㅋㅋ 근데 뭘 한 건지도 모르고 그냥 튜토리얼 따라 했던 수준이라 진짜 ‘내가 배포했다’라는 느낌은 없었다.)
본격적으로 프로젝트를 만들면서는 주변에서 다들
“Next.js쓸 거면Vercel이 제일 좋아”
“Vercel은Next.js에 최적화돼 있다”
라고 해서 그냥 아무 생각 없이 Vercel을 쓰기 시작했다.
GitHub연결해놓고 코드 푸시하니까 자동으로 빌드되고, 잠시 후에 사이트가 열렸다.
그때는 “아 배포라는 건 그냥 git push 하면 끝나는구나”라고 단순하게 생각했다.
배포 과정에 뭐가 들어가는지는 전혀 몰랐고, 그냥 툴이 알아서 다 해주니까 편하게만 느꼈다.
3. 배포에 관해 알아보기
사실 그동안은 그냥 툴이 잘 해주니까 깊게 생각을 안 했었다.
근데 이번에 개인 프로젝트를 하면서는 “이제는 배포라는 걸 정확히 알고 넘어가야겠다”는 생각이 들었다.
그래서 공부할 겸, 그리고 나중에 까먹지 않게 정리해두자는 마음으로 글을 쓰게 됐다.
배포란 뭘까?
내가 이해한 배포는 단순히
코드를 서버에 올려서 다른 사람들이 인터넷에서 쓸 수 있게 만드는 과정이다.
내 컴퓨터에서만 돌아가던 코드를, 다른 사람이 URL을 열었을 때 똑같이 볼 수 있게 만드는 것이라고 보면 된다.
조금 더 풀어서 말하면, 배포에는 이런 단계가 들어간다.
- 내가 작성한 코드를
빌드(=실행 가능한 형태로 변환)- 빌드 결과물을 서버나 플랫폼에 올림
- 인터넷 주소(URL)를 통해 사용자들이 접속할 수 있도록 연결
즉, 배포는 “개발자의 작업물이 세상에 공개되는 순간”이라고 할 수 있다.
나는Vercel만 써봐서 git push → 자동 빌드 → URL 생성 이 전부라고 생각했는데, 알고 보니 그 안에는 여러 과정과 기술들이 숨어 있었다.
3-1. 배포 기술에는 어떤 게 있을까?
내가 처음엔 배포라고 하면 그냥 “코드 올리면 끝”이라고만 생각했는데, 찾아보니 사람들이 자주 쓰는 배포 서비스나 방법들이 몇 가지 있었다.
- Vercel / Netlify: 프론트엔드 개발자들이 제일 많이 쓰는 배포 서비스.
GitHub연결만 해두면 푸시할 때마다 자동으로 빌드와 배포가 된다.
Next.js, React같은 프레임워크에 특히 잘 맞는다.
- Firebase Hosting: 구글에서 제공하는 서비스. 정적 웹사이트나 간단한 앱을 올리기 쉽고,
Firebase Auth나Firestore같은 다른 기능들이랑 같이 쓰기 편하다.
- Heroku: 예전부터 유명한 서비스. 서버 코드를 그대로 올려서 돌리기 쉬워서 지금도 사이드 프로젝트나 간단한 서버에 많이 쓰인다.
- AWS: 다양한 서비스를 조합해서 자유롭게 배포 환경을 만들 수 있다. 편의성은 덜하지만 세밀하게 커스텀할 수 있고, 규모가 커질수록 장점이 많다.
- Amplify (풀스택)
- EC2 (가상 서버)
- S3 (정적 호스팅)
- Lambda (서버리스)
Vercel같은 서비스는 설정이 거의 필요 없어서 빠르게 시작할 수 있고,
AWS는 반대로 세세하게 직접 설정할 수 있어서 규모가 커지거나 커스텀 요구가 많을 때 적합하다.
3-2. 배포 자동화란?
내가
Vercel을 처음 썼을 때 신기했던 게, 그냥 코드를GitHub에 푸시했을 뿐인데 자동으로 빌드가 되고 배포까지 된다는 점이었다.
그때는 그냥 “와 편하다” 정도로만 생각했는데, 사실 이게 다 자동화 덕분이었다.배포 자동화는 보통 CI/CD라고 부른다.
CI (Continuous Integration, 지속적 통합)
- 코드가 푸시될 때마다 자동으로 테스트를 돌리고, 빌드를 실행해서 문제 없는지 확인하는 단계.
CD (Continuous Deployment/Delivery, 지속적 배포/전달)
- 빌드된 결과물을 자동으로 서버나 플랫폼에 올려서 실제 서비스에 반영하는 단계.
이 과정을 자동으로 해주면 좋은 점이 많다.- 사람이 직접 서버에 들어가서 배포할 필요가 없다.
- 실수가 줄어든다. (파일을 빼먹는다든지, 잘못된 버전을 올린다든지 하는 문제)
- 코드가 바뀔 때마다 빠르게 결과를 확인할 수 있다.
Vercel이나Netlify같은 서비스는 내부적으로 이미 CI/CD가 들어있어서 개발자가 따로 설정할 필요가 없다.
자동화에 특화된 기술 스택
CI/CD를 직접 구성하려면 이런 툴들을 주로 쓴다.
- GitHub Actions: GitHub 저장소에 연결되어 있어 가장 많이 쓰임.
- GitLab CI/CD: GitLab 기반 프로젝트에서 강력한 자동화 제공.
- CircleCI: 다양한 언어와 환경 지원, 속도 최적화에 강점.
- Jenkins: 오래된 오픈소스 CI/CD 도구, 커스터마이징 자유도 높음.
이런 도구들을 활용하면 테스트, 코드 검사, 알림 같은 작업들을 배포 전에 자동으로 처리할 수 있다.
Vercel + GitHub Actions
근데 찾아보니 사람들은 Vercel + GitHub Actions을 같이 쓰는 경우가 많았다.
이유는 간단하다.Vercel의 자동화는 “빌드 → 배포”에 특화되어 있지만,
그 전에 하고 싶은 작업들(예: 테스트 실행, 코드 스타일 검사, 린트, 이미지 최적화, DB 마이그레이션 같은 것들)은 직접 넣기 어렵다.그래서 GitHub Actions에서 이런 작업들을 먼저 자동으로 실행한 다음,
마지막 단계에서Vercel로 배포를 트리거하는 식으로 조합하는 거다.
즉,
- Vercel = “자동 배포 담당”
- GitHub Actions = “그 전에 할 일들을 자동으로 처리”
이렇게 역할을 나누는 셈이다.
아래 글을 통해GitHub Actions의 기본 개념에 대해 알아보고 프로젝트에서 어떻게 적용했는지 살펴보자!
내가 정리한 github actions
3-3. 배포 순서
자동화까지 포함된 배포의 흐름을 정리하면 아래와 같다.
- Developer writes code (Git push)
→ 개발자가 코드를 작성하고GitHub에 푸시한다.
- GitHub Actions (Test / Lint / Build)
→ 푸시된 코드를 자동으로 테스트, 린트, 빌드해서 문제 없는지 확인한다.
- Deployment Tool (Auto Build & Deploy)
→ 빌드가 통과하면 배포 툴이 자동으로 빌드를 진행하고 새로운 버전을 배포한다.
(예: Vercel, Netlify, AWS Amplify 등)
- Users see updated service
→ 최종적으로 사용자들이 새로운 버전을 확인할 수 있게 된다.
4. 배포 전략
배포에도 사실 여러 가지 전략이 있다는 걸 이번에 처음 알았다.
나는 그냥 “코드 올리면 새 버전으로 바뀌는 거 아닌가?” 정도로만 생각했는데,
실제로는 사용자에게 영향을 최소화하면서 서비스를 안정적으로 업데이트하기 위해 다양한 방식이 존재했다.
대표적으로는 이런 것들이 있다.롤링 배포 (Rolling Deployment)
서버를 하나씩 순차적으로 새 버전으로 교체해 나가는 방식.
서비스가 멈추지 않고 점진적으로 업데이트된다.
→ 비유: 음식점 좌석을 한 줄씩 교체해 나가는 것. 손님은 계속 식사할 수 있지만, 어떤 사람은 새 의자에 앉고 어떤 사람은 기존 의자에 앉을 수 있다.
블루-그린 배포 (Blue-Green Deployment)
“Blue”(현재 운영)와 “Green”(새 버전) 환경을 동시에 유지하다가,
한순간에 트래픽을 Green으로 넘기는 방식.
문제가 생기면 다시 Blue로 되돌릴 수 있다.
→ 비유: 도로를 새로 깔아놓고, 어느 순간 신호를 바꿔 차량들이 새 도로로 다니게 하는 것. 문제가 생기면 다시 원래 도로로 돌릴 수 있다.
카나리 배포 (Canary Deployment)
새 버전을 일부 사용자에게만 먼저 적용해서 문제가 없는지 확인한 뒤,
이상 없으면 전체로 확장하는 방식.
→ 비유: 탄광에 카나리아를 먼저 들여보내서 안전한지 확인하는 것. 문제 없으면 사람들도 들어간다.
리크리에이트 배포 (Recreate Deployment)
기존 버전을 완전히 종료하고, 새 버전을 띄우는 단순한 방식.
서비스가 잠시 중단될 수 있다는 단점이 있다.
→ 비유: 가게를 하루 문 닫고 내부 인테리어를 싹 갈아엎은 후 다시 여는 것. 그동안은 손님이 못 들어온다.
A/B 테스트 배포 (A/B Testing Deployment)
사용자를 그룹으로 나눠서 일부는 A(구버전), 일부는 B(신버전)을 쓰게 하는 방식.
실험이나 퍼포먼스 비교에 자주 활용된다.
→ 비유: 같은 음식을 레시피 A, 레시피 B로 나눠서 손님들에게 내고, 어느 쪽이 더 맛있는지 보는 것.
섀도우 배포 (Shadow Deployment)
새 버전을 실제 트래픽과 똑같이 흘려보내서 테스트하지만,
결과는 사용자에게 노출하지 않는다.
운영 환경과 똑같은 상황에서 검증할 수 있다는 장점이 있다.
→ 비유: 새 요리 레시피로 손님이 주문한 것과 똑같이 요리를 해보지만, 손님에게는 기존 요리를 내놓는 것. 주방에서 맛을 보고 검증만 하는 셈.
Feature Toggle / Flag
코드 자체는 배포되지만 기능을 켜고 끄는 스위치(토글)를 둬서,
특정 기능을 점진적으로 열거나 닫을 수 있는 방식.
→ 비유: 놀이공원에 놀이기구를 설치해두고, 준비가 되면 전원 스위치를 켜서 개방하는 것.
사실Vercel같은 배포 툴을 쓰다 보면 이런 전략들이 이미 내부적으로 적용되어 있어서,
개발자가 직접 고민하지 않아도 된다.
예를 들어,Vercel의 Preview 환경은블루-그린과 비슷한 개념이고,
자동 배포는 기본적으로롤링 배포와 비슷하게 동작한다.
나처럼 초보자는 당장 전략을 고를 일은 거의 없지만,
“아 이런 방식들이 있구나” 정도로 알고 있으면 앞으로 도움이 될 것 같다.
5. 프론트엔드 배포 vs 백엔드 배포
배포라고 해도 프론트엔드와 백엔드의 방식은 조금 다르다.
- 프론트엔드 배포
보통 빌드된 결과물(HTML, CSS, JS 같은 정적 파일)을 올려서 사용자 브라우저에서 실행되게 한다.
→ 대표 도구: Vercel, Netlify, Firebase Hosting, AWS S3+CloudFront
- 백엔드 배포
API 서버,데이터 처리 로직,인증 시스템같은 걸 담은 서버 코드를 배포한다.
서버는 요청을 받고 응답을 돌려줘야 하기 때문에 프론트보다 복잡하다.
→ 대표 도구: AWS EC2, AWS Lambda(서버리스), Heroku, Render, Supabase(BAAS), Railway
정리하면,
프론트는 “사용자가 볼 화면을 어디서 호스팅하느냐”의 문제고,
백엔드는 “데이터와 로직을 어떤 서버에서 실행하느냐”의 문제라고 볼 수 있다.
6. 그래서 이번엔 어떤 거?
이번 개인 프로젝트에서는 처음 백엔드를 다뤄볼 거라서,
프론트는 Vercel, 백엔드는 Supabase(BAAS) 조합으로 가기로 했다.
왜 AWS Amplify는 안 썼나?
- 러닝커브:
Cognito, AppSync, DynamoDB등 여러 AWS 서비스 개념을 한꺼번에 익혀야 했다. 지금은 “빨리 만들어 보고 배우는” 단계라 부담이 컸다.- 설정 복잡도: IAM, 권한, 리소스 연결 같은 초기 세팅 요소가 많았다.
- 내 요구와의 거리: 웹 → 데스크탑 → 모바일로 확장하려는 이번 프로젝트에서 필요한 건
Auth + DB + Realtime정도였는데,Amplify는 다소 과한 스펙이었다.
왜 Vercel + Supabase인가?
- Vercel: 프론트 배포에 최적화.
GitHub에 푸시하면 자동으로 빌드·배포되고 Preview 환경까지 제공한다.- Supabase:
Auth, Postgres DB, Storage, Realtime기능을 한 번에 제공.SQL기반이라 직관적이고, 권한 관리(RLS)도 깔끔하다.- 조합 장점: 프론트는
Vercel이 자동 배포, 백엔드는Supabase가 관리형 인프라 → 빠른 개발 & 안정적 운영이 가능하다.- 멀티플랫폼 확장성: 웹, 데스크탑, 모바일이 모두 같은
Supabase 백엔드를 공유할 수 있다.
웹 → 앱 확장 시에도 그대로 간다
나중에
React Native로 모바일 앱을,Tauri/Electron으로 데스크탑 앱을 만들더라도,
바뀌는 건 프론트 배포 방식뿐이다.
- 웹: Vercel
- 모바일: 앱스토어(구글/애플)
- 데스크탑: 자동 업데이트(Electron/Tauri)
서버는 그대로 Supabase를 유지한다.
모든 플랫폼이 같은 백엔드(Auth/DB/Storage/Realtime)에 붙으니까,
연동 문제 없이 그대로 확장할 수 있다.
