[MoaMoa] FE 배포 (Vercel / AWS) (1)

Vercel과 AWS, 두 가지 프론트엔드 배포 경험을 선택한 이유

UMC 8th MoaMoa 프로젝트를 진행하며, 프론트엔드 배포를 단순히 “올리는 것”이 아니라 운영 관점에서 비교해보고 싶었다.

그래서 프론트엔드를

• Vercel 기반 배포
• AWS 기반 배포(S3/EC2 등)

두 가지 방식으로 시도해보기로 결정했다.

 

Vercel 배포 vs AWS 배포 간단 비교

구분	Vercel	AWS (S3/EC2 등)
설정 난이도	매우 쉬움 (CLI/웹 자동화)	중간~높음 (서버·보안 직접 구성)
성능	CDN 기본 제공	설정에 따라 상이
확장성	플랫폼 제약 있음	Auto Scaling 등으로 높음
보안	기본 설정 자동 처리	HTTPS, IAM, 보안그룹 직접 구성
커스터마이징	제한적	매우 자유로움
실무 적합성	MVP, 빠른 검증	실서비스 운영
비용	무료 티어 있음	세밀한 과금 구조
CI/CD	GitHub 연동 자동	직접 파이프라인 구성
로그/모니터링	제한적 대시보드	CloudWatch 등 활용 가능

 

정리하면, Vercel은 빠르게 결과를 확인하기 좋고, AWS는 직접 인프라를 설계·운영하는 데 적합한 플랫폼이다.

 

 

Vercel 배포 개요

• 프로젝트명: MoaMoa (모아모아)
• GitHub: https://github.com/UMC-8th-Moamoa
• 기술 스택: React, TypeScript, Tailwind CSS
• 배포 목적: 초기 프론트엔드 구현 결과를 빠르게 배포해 피드백 반영

원래 목표했던 배포 전략

• main 브랜치 → Production
• develop 브랜치 → Preview

다만 프로젝트 일정이 촉박해지면서

• develop 브랜치를 Production으로 사용했고
• 후반부 배포 오류로 인해 feat/demoday 브랜치를 새 프로젝트로 분리해 최종 정적 배포했다.

(원칙적으로는 main=prod, develop=preview가 맞다.)

 

Vercel 기본 배포 흐름

브랜치	배포 대상	URL	비고
main	Production	http://front-end-final-sand.vercel.app/	기본설정 되어있음
develop	Production	https://moamoa-front-3s47b6jsr-hyejun-koos-projects.vercel.app/	에러나서 임시페이지 배포..
feat/demoday	Production	http://front-end-demo-coral-iota.vercel.app/	final 배포버전!

 

 

Vercel 배포 트러블슈팅 정리

1) develop 브랜치에 커밋해도 자동 배포가 안 됨

증상

• develop에 커밋/푸시해도 배포가 트리거되지 않음
• 대시보드에는 Branch Tracking = develop으로 표시됨

원인으로 추정한 것

• GitHub App 권한 이슈 (조직 오너 승인 필요)
• 로컬 .vercel 설정이 다른 프로젝트와 잘못 연결된 상태

해결
자동 배포를 기다리지 않고 CLI로 강제 배포 진행.

npx vercel --prod

 

추가로 프로젝트 링크 재설정: 

Remove-Item -Recurse -Force .vercel
npx vercel link --project <프로젝트명> --yes

 

배운 점
자동 배포가 막히면 원인 분석과 별개로 CLI 강제 배포로 먼저 결과를 확보하는 게 실무적으로 효율적이다.

 

2) 수동 배포 후 TypeScript import 오류 대량 발생

증상

• 사용하지 않는 import도 전부 오류 처리
• Cannot find type definition file for 'node' 등 타입 에러 발생

원인

• 프로젝트 전반에 쌓여 있던 엄격한 TS 규칙
• 로컬과 CI(Vercel) 환경의 타입/Node 차이

판단

• 오류 개수가 많아 데모 일정상 전면 수정은 리스크가 큼

최종 선택

로컬에서 빌드 성공 → 빌드 산출물만 배포

 

즉, dist 폴더를 정적 배포하는 방식으로 전략 전환.

 

pnpm build
npx vercel

 

 

설정 요약:

• Build Command: pnpm build
• Output Directory: dist

→ Preview 배포 성공
→ 실제 접근 가능한 URL 확보

 

3) 브랜치 병합 후 배포 설정 꼬임

 

문제

• develop에 다른 브랜치 병합 후 기존 Vercel 배포 설정이 덮어씌워짐
• 버전/환경 설정까지 꼬이면서 기존 배포 페이지 오류 발생

해결

• 데모데이용 feat/demoday 브랜치를 기준으로 새 Vercel 프로젝트 생성
• 최종 발표용 배포 환경을 분리해 안정화

현재 결과임니다~~

 

 

 

정리하며

이번 MoaMoa 프로젝트에서 Vercel을 이용한 프론트엔드 배포를 통해 단순히 정적 파일을 올리는 수준을 넘어, 실제 운영 환경에서 발생하는 문제들을 직접 마주했다.

• GitHub 연동 기반 자동 배포 구조 이해
• 브랜치별 배포 전략(main / develop / demo) 설정과 한계 체감
• 자동 배포가 동작하지 않을 때 CLI 강제 배포로 우회하는 경험
• pnpm lockfile 충돌, TypeScript 빌드 에러 등 CI 환경에서만 드러나는 문제 해결
• 배포 설정이 꼬였을 때 프로젝트를 분리해 안정화하는 판단

특히, 로컬에서는 정상 동작하던 코드가 배포 환경에서는 실패하는 상황을 반복적으로 겪으며 프론트엔드 배포 역시 환경·도구·설정에 크게 의존한다는 점을 체감했다.

이번 경험을 통해 Vercel의 장점과 한계를 모두 이해하게 되었고, 문제가 발생했을 때 배포를 멈추지 않고 현실적인 우회 전략을 선택해 결과를 만들어내는 과정이 프론트엔드 운영에서 중요하다는 것을 배울 수 있었다.

 

다음 글에서는 AWS 기반 프론트엔드 배포(S3/EC2/CloudFront) 경험도 이어서 정리할 예정이다 :)