ADR‐006: 배포 아키텍쳐 결정 - Moadong/moadong GitHub Wiki

작성일: 2025-12-01 | 상태: Accepted
결정일자: 2025-01-12

1. 왜 이 결정이 필요했나요?

프로덕션 환경 배포를 위한 인프라 구성이 필요했습니다.

프론트엔드, 백엔드 API, 데이터베이스, 이미지 파일 저장소를 각각 어떤 플랫폼에서 운영할지 결정해야 했으며, 비용 효율성, 관리 복잡도, 확장성, 성능 등을 고려했습니다.



2. 각 영역별 고민과 선택지

2.1 프론트엔드 호스팅

고려한 옵션들

  • Netlify: Git 연동 자동 배포, Preview URL, 무료 SSL/CDN
  • Vercel: Next.js 특화, 자동 배포 우수하나 빌드 시간 제한 빡빡
  • GCP Cloud Storage + Cloud CDN: 저렴하나 CI/CD 직접 구축 필요

최종 선택: Netlify

GCP는 CI/CD와 Preview URL 기능을 직접 구축해야 했고, Netlify와 Vercel은 Git push만으로 자동 배포되고 PR별 Preview URL이 생성되어 협업이 편리했다.

현재 트래픽은 무료 티어로 충분하고 Next.js를 사용하지 않아 Vercel의 특화 기능이 불필요했으며, 빌드 시간 제한도 Netlify가 더 관대했다.

무엇보다 기존에 Netlify 사용 경험이 있어 빌드 설정과 트러블슈팅 노하우가 축적되어 있었기 때문에 익숙한 Netlify를 선택했다.




2.2 백엔드 호스팅 + ci/cd

  • AWS EC2: 신규 가입자 프리티어 제공하나 성능이 낮은 VM
  • GCP Compute Engine: 신규 가입자 무료 크레딧 $300 제공, 완전한 서버 제어

최종 선택: GCP Compute Engine

AWS EC2는 프리티어를 제공하지만 성능이 낮은 t2.micro 인스턴스로 제한되었다.

반면 GCP는 신규 가입자에게 무료 크레딧 $300을 제공하여 초기 3개월간 비용 부담 없이 충분한 성능의 인스턴스를 사용할 수 있었다.


배포 프로세스

  1. 로컬/CI에서 도커 이미지 빌드
  2. GCP Container Registry에 푸시
  3. Compute Engine VM에서 쉡 스크립트를 이용해서 docker-compose로 컨테이너를 blue green 방식으로 배포한다

새로운 도커 이미지로 컨테이너를 교체할 때 기존 컨테이너를 내리고 새 컨테이너를 올리는 방식은 서비스가 잠시 중단되는 다운타임이 발생했다

무중단 배포를 위해 단일 VM 환경에서 구현 가능한 blue-green 방식을 선택했다.



2.3 DB 호스팅

고려한 옵션들

  • MongoDB Atlas: MongoDB 공식 관리형 서비스, 무료 티어 512MB, 자동 백업
  • Self-Hosted MongoDB: Compute Engine VM에 직접 설치

최종 선택: MongoDB Atlas

Self-Hosted는 백업/복구, 레플리카셋, 보안 패치를 직접 관리해야 해서 운영 부담이 컸다

MongoDB Atlas는 MongoDB에서 공식으로 제공하는 관리형 서비스로 무료 티어(512MB)를 제공하여 초기 비용 없이 시작할 수 있었다.

백업/모니터링/장애 복구가 자동화되어 DB 운영에 신경 쓰지 않고 개발에만 집중할 수 있었다.



2.4 이미지 저장소

고려한 옵션들

  • GCS (Google Cloud Storage): GCP 생태계 통합, 저렴한 비용
  • AWS S3: 유사한 오브젝트 스토리지 기능, CloudFront CDN 연동

최종 선택: GCS (Google Cloud Storage)

AWS S3는 기능은 유사하지만 GCP와 플랫폼이 분산되어 관리 포인트가 늘어나는 단점이 있었다.

이미 백엔드를 GCP Compute Engine에서 운영하고 있었기 때문에 같은 GCP 생태계 내에서 Object Storage를 사용하면 여러 이점이 있었다.

⚠️ **GitHub.com Fallback** ⚠️