🚀 모노레포 배포 전쟁기

pnpm과 Turborepo 기반의 모노레포 프로젝트를 진행하며 구축한 브랜치 전략과 배포 파이프라인을 복기해본다. 이번 설계의 핵심은 단순히 배포 자동화를 넘어, 한정된 자원을 어떻게 전략적으로 사용할 것인가에 있었다.

1. 브랜치 전략: 왜 배포 환경을 이원화했는가?

정통 Git-flow를 따르되, AWS EC2(운영) 와 Vercel(검증) 로 배포 타겟을 완전히 분리했다.

💰 인프라 비용의 현실적인 고려

현재 프로젝트는 $1,000의 AWS 크레딧을 보유하고 있으나, 인스턴스는 켜져 있는 시간만큼 비용이 정직하게 발생한다. 따라서 운영 환경인 EC2는 1차 MVP 개발이 완료된 시점부터 상시 가동하는 것이 자원 활용 측면에서 옳다고 판단했다.

🔗 Vercel을 통한 'Only View' 환경 구축

개발 과정에서 발생하는 수많은 코드 리뷰와 UI 확인(Only View)을 위해 매번 EC2를 켜고 끄는 것은 비효율적이다. 이에 따라 무료 배포가 가능하고 프리뷰 URL을 자동으로 생성해주는 Vercel을 채택하여 개발 및 출시 준비 단계의 병목을 제거했다.

---

2. CI/CD의 핵심: AWS 방화벽 제어 (Firewall Bot)

보안상 SSH(22번) 포트를 상시 개방하는 리스크를 줄이기 위해, GitHub Actions 파이프라인 내에서 보안 그룹을 동적으로 제어하는 로직을 구현했다.

🤖 Automation Workflow

1. Runner IP Whitelist: 배포 시작 시점에만 GitHub Actions 러너의 IP를 AWS 보안 그룹에 임시 허용한다.
2. Docker Deployment: SSH 접속 후 최신 이미지를 pull하여 컨테이너를 갱신한다.
3. : 배포 결과와 상관없이 작업 종료 시 해당 IP 권한을 즉시 회수한다.