상위 문서: 클라우드 위키
관련 문서: 클라우드 WHY? 문서

• 1. 개요 및 도입 배경
• 2. 리소스 구성 및 아키텍처
• 3. 빅뱅 배포 프로세스 설계
• 4. 빅뱅 배포 방식 분석
• 5. 향후 개선 방향 및 전환 계획

Big Bang 배포는 전체 시스템(프론트엔드, 백엔드, AI 서버 등)을 한 번에 배포하는 방식으로, 모든 기능이 완성된 시점에서 전체 애플리케이션을 동시에 운영 환경에 반영하는 전략.
배포 시점까지는 내부적으로 통합 테스트와 기능 검증을 마친 뒤, 프로덕션 서버에 전체 기능을 일괄 반영.

즉, '한순간에 전부 교체'하는 전략이기 때문에 이름 그대로 Big Bang(빅뱅) 방식이라 불림.

현재 프로젝트는 MVP 초기 단계로, CI/CD 자동화 환경이 구축되지 않은 상태.
빠르게 피드백을 받고, 운영 경험을 쌓기 위해 단기 배포 전략으로 Big Bang 방식을 도입.

도입 목적:

• 자동화 설계 전, 전체 시스템을 빠르게 반영
• 최소 리소스로 실제 환경 테스트 가능
• 개발 완료된 서비스 통합 배포

특히 next build 중 발생한 OOM 이슈는 실 운영 중 장애로 이어질 수 있어, 장기적으로는 구조 개선이 필요.

현재 배포는 EC2 기반으로 다음과 같이 구성:

⚠️ 리소스 제약상 운영 서버에서 빌드까지 수행하는 구조는 점차 리스크가 커짐.
따라서 향후에는 운영 서버는 실행만, 빌드는 외부 서버나 CI에서 수행하는 구조로 전환할 계획.

본 프로젝트는 다음과 같은 3가지 주요 컴포넌트로 구성:

모든 구성 요소는 단일 EC2 인스턴스에서 함께 실행.

현재 인프라는 다음과 같이 구성됨:

• Nginx: 정적 파일 제공 + API Reverse Proxy 역할
• Spring Boot (JAR): 8080 포트에서 실행
• FastAPI: 8000 포트에서 실행

MVP 단계에서는 고정적인 컴포넌트(도메인, 인증서, 정적 파일 저장소)를 AWS에 배치하고, 컴퓨팅 자원은 GCP 크레딧을 활용하여 전체 시스템을 GCP에서 운영하는 구조로 시작한다.

이후 AI 모델 개발이 본격화되면, AI 서버만 GCP에 분리 배치하고 나머지 컴포넌트는 AWS로 이전하는 구조로 전환하고자 한다.

또한 서비스가 확장되면 EKS 및 Terraform 기반 인프라로의 업그레이드를 고려하고 있으며, 이 과정에서 전체 클라우드를 AWS로 일원화할 계획이다. AWS의 인프라 지원금도 이를 뒷받침할 예정이다.

• GCP 초기 크레딧을 통해 GPU 인스턴스를 무상 운영함으로써 비용을 절감
• AI 서버를 GCP에서 운영하며, 초기 인퍼런스 비용을 효과적으로 회피
• 크레딧이 소진되면 GCP 리소스를 종료하고 AWS로 이전 예정

• 도메인 및 인증서는 Route 53 + ACM 기반으로 AWS에 고정

  • GCP에서도 가능하지만, 마이그레이션 및 만료 이슈 회피 목적
  • DNS 인증 속도 및 자동화 측면에서도 AWS가 유리

• 정적 자산 저장소는 AWS S3에 유지

  • 장기 보관 목적의 안정성과 네트워크 이관 비용 최소화를 고려

• 현재는 EC2 단일 인스턴스 기반으로 운영되지만, 향후 EKS 도입 시점에서 AWS로의 컴퓨팅 집중을 고려
  • Kubernetes 환경에서 클러스터 구성 시, VPC, IAM, ALB 등과의 연동이 중요한데,
    이러한 AWS 생태계의 통합성은 장기적 관리와 비용 최적화에 더 유리
• Terraform 등을 통한 IaC 설계도 결국 클라우드 벤더에 종속될 수밖에 없기 때문에,
  장기적으로는 AWS를 기준으로 인프라 코드를 정착시키는 것이 운영 측면에서 바람직

MVP 단계에서 GCP 크레딧 활용을 통해 GPU 기반 AI 서버를 무료로 운영했지만, 장기적으로는 비용 발생이 불가피하므로 실제 비용 비교를 통해 AWS 이전 타이밍을 판단하고자 한다.

비용 분석 결과, AI 서버만 GCP로 운영할 경우 월간 약 22만 원의 비용 절감 효과가 있음이 확인되었다.

시간당 약 312원 절감 (AI 서버 1대 기준)

• AI 서버는 하루 8시간 × 30일 = 240시간 운영 (최소 기준)

※ BE/FE/DB는 t3.medium 기준 720시간 운영 → 720 × ₩74 = ₩53,280 ※ AI는 g4dn.xlarge vs n1-standard-4 + T4, 720시간 기준 비교

• MVP 단계에서는 고정 자산을 AWS에, 컴퓨팅을 GCP에 임시 배치하여 크레딧을 최대한 활용
• AI 모델이 본격적으로 운영되면 GCP에 우선 배치하고, GPU 인프라 비용 절감 효과를 실현함
• 크레딧 만료 시점에서 EKS 기반 AWS 전환 및 Terraform 인프라 재구축을 통해 장기 안정성을 확보
• 이 전략은 단순한 비용 절감이 아니라 단기 최적화 + 장기 일관성 확보를 동시에 추구하는 방향

이 멀티 클라우드 전략은 단순한 ‘저렴한 곳을 쓰자’가 아닌,

• MVP 단계에서의 비용 효율,
• 도메인과 인증서의 관리 편의성,
• 장기 운영에서의 이식성과 안정성,
• EKS 등 AWS 인프라 확장성과 연계성
  을 함께 고려한 선택.

특히, 비용이 가장 많이 드는 AI 연산 자원만 GCP에서 운용하고,
도메인/인증서/정적 파일/백엔드/DB는 AWS에 고정함으로써
필수 자산의 이관 리스크는 최소화하고, 크레딧이 소진되면 컴퓨팅만 유연하게 이동할 수 있는 구조를 설계.

Big Bang 수작업 배포는 전체 시스템을 한 번에 반영한다는 특성상, 명확한 절차와 역할 분담이 중요하다고 토의.
실제 배포를 어떻게 수행했는지를 중심으로 전반적인 흐름, 역할, 세부 단계, 체크리스트 정리.

• 대상 구성: FE (React), BE (Spring Boot), AI 서버 (FastAPI)
• 배포 방식: SSH로 EC2에 접속 후, 각 프로젝트 디렉토리별 스크립트 실행
• 배포 시점: 전체 기능 구현 완료 후 통합 반영
• 운영 서버: 단일 EC2 인스턴스에서 통합 운영
• 환경 구성: .env 파일 설정, JDK/Python/Nginx 설치 사전 필요

소규모 프로젝트에서는 위 역할을 1~2인이 병행 수행할 수 있음. 단, 역할별 작업 순서를 명확히 해두는 것이 중요.

1. 배포 전 최종 테스트 완료
2. 운영 서버 SSH 접속
3. FE, BE, AI 순서로 수작업 배포 스크립트 실행
4. 로그 확인 및 서비스 정상 여부 확인
5. 배포 완료 후 확인 URL 공유 및 피드백 수렴

FE → BE → AI 순서대로 배포하는 이유는 프론트에서 BE, AI API에 접근하는 구조이기 때문

#!/bin/bash

# 1. 저장소 이동 및 최신 코드 pull
cd ~/onthetop-frontend || exit
git pull origin main

# 2. Node.js 및 의존성 설치 (최초 1회만 필요)
if ! command -v node > /dev/null; then
  echo "Installing Node.js via nvm..."
  curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
  source ~/.bashrc
  nvm install 18
  nvm use 18
fi

# 3. 의존성 설치
npm install

# 4. 환경 변수 파일 설정
cp .env.production .env

# 5. 정적 빌드
npm run build

# 6. Nginx 대상 디렉터리에 빌드 파일 복사
sudo cp -r build/* /var/www/onthetop

#!/bin/bash

# 1. 저장소 이동 및 최신 코드 pull
cd ~/onthetop-backend || exit
git pull origin main

# 2. JDK 확인
if ! command -v java > /dev/null; then
  echo "⚠️  Java 설치 필요"
  exit 1
fi

# 3. 빌드 실행
chmod +x ./gradlew
./gradlew clean build

# 4. 실행 중이던 프로세스 중지 (예: 기존 백엔드)
pkill -f 'onthetop-backend'

# 5. 새 JAR 실행
nohup java -jar build/libs/*.jar --spring.profiles.active=prod > app.log 2>&1 &

#!/bin/bash

# 1. 저장소 이동 및 최신 코드 pull
cd ~/onthetop-ai || exit
git pull origin main

# 2. Python 환경 설정
if ! command -v python3 > /dev/null; then
  echo "⚠️  Python3 설치 필요"
  exit 1
fi

# 3. 가상환경 생성 및 활성화 (최초 1회)
if [ ! -d "venv" ]; then
  python3 -m venv venv
fi
source venv/bin/activate

# 4. 의존성 설치
pip install --upgrade pip
pip install -r requirements.txt

# 5. FastAPI 실행 (백그라운드 실행 예시)
pkill -f 'uvicorn'
nohup uvicorn app.main:app --host 0.0.0.0 --port 8000 > ai.log 2>&1 &

Big Bang 방식 수작업 배포는 초기 단계에서는 빠르게 서비스를 론칭하고, 외부 의존 없이 간단하게 적용할 수 있다는 장점이 있음.
하지만 실제 배포를 진행하면서 다음과 같은 제한사항과 위험 요소들이 확인됨.

• 특히 Next.js와 같은 SSR 프레임워크는 빌드 과정에서 2~4GB 이상의 메모리를 요구함.

• EC2 t2.micro 또는 t3.small과 같은 저사양 인스턴스에서는 메모리 부족(OOM)이 발생할 수 있음.

• 실제로 next build 명령 실행 중 프로세스가 죽거나, SSH가 끊기는 문제가 발생했고,

  swap 메모리 설정으로 임시 해결했음. https://velog.io/@luckyprice1103/AWSec2-freetier-memory-swap

🔧 개선 방향: 빌드 서버와 운영 서버를 분리 → CI 서버에서 빌드하고, 결과물만 운영 서버에 배포

• 현재 방식은 운영 중인 서버를 직접 내려서 배포하는 구조이기 때문에, 사용자 입장에서 갑작스러운 서비스 중단이 발생할 수 있음.
• pkill 이후 nohup으로 다시 실행하긴 하지만, 문제 발생 시 빠른 복구가 어려움.
• 무중단 배포나 롤링 배포 등의 방식이 아님.

🛠 개선 방향: 무중단 배포 구조 도입 (ex. Blue/Green, Load Balancer 활용 등)

• 빌드 누락, 의존성 설치 누락, 환경 변수 오류, 파일 경로 오류 등 사람에 의한 실수 가능성 상존
• 실수 발생 시 재배포까지 소요되는 시간이 길어짐
• 특히 팀 규모가 커지면, 반복적인 수작업은 운영 안정성에 악영향

• Git revert나 수동 재배포 외에 자동 롤백 시나리오 없음
• 문제가 발생하면 로그 분석, 수정, 재배포까지 모두 수동으로 진행해야 함
• 백업을 해두지 않은 경우, 심각한 장애로 이어질 수 있음

💡 개선 방향: 이전 배포본 보관 및 빠른 롤백 스크립트/시나리오 설계

• 현재는 배포 로그나 히스토리가 남지 않음
• 누가 언제, 무엇을, 어떤 서버에 배포했는지 추적 불가능
• GitHub Actions, Slack, Notion 연동 없이 협업 시 이슈 발생 가능

현재 수작업 기반의 빅뱅 배포 방식은 프로젝트 초기 단계에서는 유효했지만,
운영 안정성 확보와 팀 확장, 반복 배포 효율성을 위해 다음과 같은 한계점이 명확히 드러남.:

• 빌드 결과물 다운로드
• 기존 프로세스 종료
• 새로운 결과물 배포 및 실행
• 로그 저장 및 Slack 알림 (선택)

예시 도구: GitHub Actions + EC2 접근용 SSH Key

Big Bang 방식의 수작업 배포는 단기적으로는 효율적이었지만,
점차 자동화된 빌드/배포 시스템으로 전환함으로써 운영 리스크를 줄이고 개발 생산성을 높이는 것이 필요하다고 문의.

CI/CD 파이프라인 도입은 단순한 자동화가 아닌, **“지속 가능한 서비스 운영과 협업을 위한 핵심 인프라 전환”**이라는 점에서 중요.