Big Bang 방식 수작업 배포 설계 - 100-hours-a-week/20-real-wiki GitHub Wiki

🚀 1. 빅뱅 배포 계획 수립 및 분석

1.1. 빅뱅 배포 정의

1.2. 도입 배경 및 목적

1.3. 빅뱅 방식의 장점

1.4. 빅뱅 배포 시 리소스 구성

1.5. 현 배포 방식의 한계 및 분석

📐 2. 빅뱅 배포 아키텍처 다이어그램

2.1. 구성 요소 설명

🍡 3. 빅뱅 배포 프로세스 설계

3.1. 개요

3.2. 배포 전략 요약

3.3. 배포 정의

3.4. 배포 담당 역할 분담

3.5. 배포 시나리오 (전체 흐름)

3.6. 수작업 배포 단계별 설명

3.7. 수동 체크리스트

빅뱅 배포 설계

🚀 1. 빅뱅 배포 계획 수립 및 분석

1.1. 빅뱅 배포 정의

**빅뱅 배포(Big Bang Deployment)**는 하나의 배포 이벤트를 통해 시스템의 모든 구성 요소를 동시에 일괄 배포하는 방식이다. 개별적으로 업데이트하거나 점진적으로 릴리즈하는 방식과 달리, 초기 단계에서는 전체 시스템을 한 번에 배포하여 MVP 수준의 서비스가 즉시 동작 가능하도록 한다.

1.2. 도입 배경 및 목적

현재 프로젝트는 초기 사용자의 피드백 확보와 서비스 핵심 가치 제공을 위한 MVP 단계의 서비스로, 주요 기능이 완성된 직후 빠르게 전체 시스템을 사용자에게 공개할 필요가 있다.

이러한 상황에서, 다음과 같은 현실적 조건과 팀의 판단에 따라 빅뱅 배포 전략을 선택하게 되었다:

⏰ 짧은 개발 일정과 빠른 피드백 루프의 필요성

일정 내 MVP를 출시하고 사용자 피드백을 기반으로 빠르게 개선해나가기 위해 단일 환경에서 단순한 방식으로 전체 기능을 한 번에 공개하는 배포 전략이 가장 현실적이었다.

💰 초기 비용 및 관리 부담 최소화

현재 프로젝트의 자금은 크게 제한되어 있다. 따라서, 전체 프로젝트 과정에서 효율적인 비용 관리로 서비스를 운영하는게 주요 과제로 제시된다. 초반부터 복잡한 배포 환경이나 고급 클라우드 서비스를 구성할 경우, 초기 비용 및 운영 부담이 크다. 따라서 초기 배포 단계에서는 관리 포인트가 적은 단일 인스턴스 환경에서 직접 관리하고 통제할 수 있는 구조가 적합했다.

🧠 서비스 가치 제공을 위한 최소 구성 확보

MVP 단계에서 사용자들에게 제공할 기능은 다음과 같다:

춘비서: 사용자와 대화하여 정보를 제공하는 AI 챗봇
공지 모아주기: 노션, 디스코드 등 외부 플랫봄에 등록된 공지들을 수집하고 요약하는 정보
뉴스: 디스코드 등록된 소통방의 내용을 수집하여 보여주는 정보

이 프로젝트의 핵심 가치는 **”카카오테크 부트캠프 인원들의 연결성 중심의 경험을 제공하는 것”**이다. 공지 리스트만 제공하거나 챗봇만 제공해서는 이 핵심 가치를 온전히 제공할 수 없다. 위의 기능들이 함께 존재해야만 사용자는 이 프로젝트에서 제공하는 핵심 가치를 느낄 수 있다.

또한, 가치 흐름이 명확해야 실효성 있는 피드백이 가능하다고 판단했다. 예를들어 챗봇으로 질문을 했지만, 관련 정보나 공지가 없으면 사용자는 실제 사용 흐름 기준의 문제 해결 경험이 안 되기 때문에 MVP로서의 기능 검증도, 피드백도 애매해진다.

위와 같은 이유들로 미루어 보아, 빠른 피드백 제공성, 비용 효율성 그리고 서비스 핵심 가치 제공성을 고려할 때, 점진적 배포나 자동화보다 수작업 중심의 빅뱅 배포 방식이 가장 현실적인 선택이었다.

1.3. 빅뱅 방식의 장점

장점	설명
신속한 배포로 빠른 피드백 수용 가능	초기 MVP 상황에 맞춘 간단한 수작업으로 빠르게 배포 및 피드백 가능
기술 스택 단순화	컨테이너, CI/CD 설계 없이 바로 배포 가능
초기 비용 최소화	서버 수 최소화, 관리형 서비스 미사용으로 초기 비용 최소화 가능
단순하고 직관적인 운영 환경	SFTP를 활용한 소스코드 업로드 방식, 콘솔 리소스 직접 확인 및 조작 가능
사용자들에게 핵심 가치 제공 가능	빅뱅 배포를 통해 사용자들에게 연결성 중심의 경험을 제공할 수 있음

1.4. 빅뱅 배포 시 리소스 구성

목차(1.2. 도입 배경 및 목적)에서 언급했듯, 효율적인 비용 관리로 서비스를 운영하는 것이 팀에서 주요 과제이다. 추가적으로, 서비스가 고도화되면서 현실성/장기운영성/확장성을 고려해야 한다. 따라서 본 프로젝트는 초기 MVP 릴리스를 위해 GCP와 AWS를 혼합 사용하는 이원화 클라우드 전략을 채택하였다.

1.4.1. GCP 리소스를 사용하는 이유

목표

전체를 AWS로만 구성했을 때와 GCP + AWS 혼합 구성했을 때, 즉, AI 모델만 GCP로 옮겼을 때 실제 발생하는 절감 비용을 수치로 나타내 혼합 구성을 정당화해 GCP 리소스를 사용하는 이유를 제시하는 것이 목표다.
AWS vs GCP GPU 인스턴스 단가 비교

클라우드 인스턴스 시간당 요금 (서울 리전)

AWS g4dn.xlarge 약 $0.65/hour ≒ ₩923/hour

GCP n1-standard-4 + NVIDIA T4 약 $0.43/hour ≒ ₩611/hour

→ 단순 비교만으로도 1시간당 약 312원 절감

→ 하루 8시간 실행 x 30일 = ₩74,880 차이
시나리오별 월간 비용 비교 예시
- [시나리오 A] 모든 구성 AWS 사용
  
  항목 월간 비용 추청 (720시간 기준)
  
  프론트/백/DB (t3.medium) ₩53,280
  
  AI 서버 (g4dn.xlarge) ₩664,560
  
  총합 ₩718,840
- [시나리오 B] AI 서버만 GCP로 분리
  
  항목 월간 비용 추청 (720시간 기준)
  
  프론트/백/DB (t3.medium) ₩53,280
  
  AI 서버 (g4dn.xlarge) ₩439,920
  
  총합 ₩493,200
→ 절감: ₩225,640

클라우드	인스턴스	시간당 요금 (서울 리전)
AWS	g4dn.xlarge	약 $0.65/hour ≒ ₩923/hour
GCP	n1-standard-4 + NVIDIA T4	약 $0.43/hour ≒ ₩611/hour

항목	월간 비용 추청 (720시간 기준)
프론트/백/DB (t3.medium)	₩53,280
AI 서버 (g4dn.xlarge)	₩664,560
총합	₩718,840

항목	월간 비용 추청 (720시간 기준)
프론트/백/DB (t3.medium)	₩53,280
AI 서버 (g4dn.xlarge)	₩439,920
총합	₩493,200

GCP AI 인스턴스는 AWS AI 인스턴스 대비 약 31% 저렴하고, 추가적으로 크레딧이 소진되기 전까지는 AI 인스턴스를 완전 무상으로 사용할 수 있어, 현재 시점에서 비용 절감 측면에서 GCP 사용은 이상적인 선택이라 볼 수 있다.

1.4.2. AWS 리소스를 사용하는 이유

클라우드 주류 환경 대응

AWS는 현재 대부분의 기업 환경에서 실질적인 표준으로 사용되고 있으며, 장기적인 서비스 운영 및 인프라 마이그레이션에 대비해 AWS 기반의 리소스 운영을 확보하는 것이 필수적이다.
GCP 크레딧 만료 이후를 대비한 이식성 확보

GCP 크레딧 소진 이후를 고려했을 때, 프론트엔드/백엔드/DB는 AWS에 배치함으로써, 향후 비용 구조가 안정화된 이후에도 별도의 마이그레이션 없이 운영을 지속할 수 있는 구조를 선택했다.
역할 분리 & 장애 분산을 위한 이중 클라우드 구성 전략

모델 인퍼런스 트래픽이 급증하거나 GCP 리소스가 일시적으로 느려지더라고, AWS에 배포된 웹/백엔드 서비스에는 영향을 주지 않도록 클라우드 이원화 구조를 선택했다.

1.4.3. 리소스 구성 전략

역할	클라우드	리소스	세부 설명
AI 모델 서빙 (FastAPI)	GCP	GCE	고성능 연산(GPU 등)을 요하는 AI 모델 실행을 위해 GCP 인스턴스 사용
프론트엔드 (Next.js)	AWS	EC2	EC2에서 SSR 지원
백엔드 (Spring Boot)	AWS	EC2	EC2에서 `jar` 실행
데이터베이스 (MySQL)	AWS	EC2	EC2에서 MySQL 설치 및 관리
정적 파일 서빙	AWS	S3	S3 버킷 + CloudFront 조합으로 정적 리소스 (이미지, JS/CSS) 전달 속도 향상
사용자 도메인 관리	AWS	Route 53	Route 53을 통해 도메인 네임 서비스 구성, CloudFront와 연동
HTTPS 지원	AWS	ACM + CloudFront	ACM과 CloudFront를 연계하여 HTTPS 인증서 적용
로그 파일 저장	AWS	S3	EC2 내부의 로그들을 관리하는 버킷 생성

1.5. 현 배포 방식의 한계 및 분석

한계	설명
인적 오류 가능성	빌드/업로드/실행 과정 중 하나라도 실수 시 전체 서비스 오류
환경변수 관리의 어려움	수동으로 `.env` 등의 파일을 다루면 실수로 민감 정보 유출 가능성 존재
모니터링 부족	로그 수집 및 알림 체계 부재 → 장애 인지 지연
무중단 배포 불가	새 버전 반영 시, 기존 프로세스를 반드시 중단해야 함 → 다운 타임 발생
보안 취약	기본적인 보안 조치는 수행했으나, 고도화된 보안 체계의 부재
지속적인 운영 부담	같은 작업을 반복해야 하므로 장기적으로 비효율적
확장성 제약	이후 트래픽 증가, 멀티 인스턴스 운영이 어려움

수작업 기반의 빅뱅 배포 방식은 단순하고 비용 효율적이지만, 아래와 같은 정량적/구체적 리스크를 수반한다:

🔁 배포 시간: 전체 배포 프로세스 (프론트/백엔드 업로드 및 실행 포함)는 최소 20분 이상 소요 예상
⏱️ 다운타임: 백엔드 jar 교체 시점에 평균 1~2분의 서비스 중단이 발생 예상
🧍 운영 인력 의존도: 담당자의 실수로 jar 파일이 잘못 올라가거나 실행 실패 시, 롤백에만 5~10분 이상 소요 예상
📈 트래픽 대응 어려움: 현재는 단일 인스턴스 구조로 되어 있어, 동시접속자가 일정 수준(예: 50명 이상) 넘어갈 경우 병목 발생 가능성이 존재
📄 환경 변수 관리: 수동으로 환경 설정 파일들을 수정/업로드해야 하며, 잘못된 key-value 조합으로 인해 배포 실패 가능성 존재
⚠️ 보안 취약: 현재 배포는 최소 보안 조치로 SSH 접근 제한, S3 공개 접근 차단 및 HTTPS 인증서 적용 등을 설정했지만, 이는 장기적으로 봤을 때 불안정해 IAM, WAF, 모니터링 솔루션 등의 도입이 필요

이러한 요소들은 향후 서비스 고도화 또는 실사용자 증가 시, 반드시 자동화 및 멀티 환경 대응으로의 전환이 필요한 이유가 된다.

📐 2. 빅뱅 배포 아키텍처 다이어그램

ktb_final-BigBang_아키텍처_다이어그램_(1)

2.1. 구성 요소 설명

2.1.1. AWS Cloud

Route 53
- 프로젝트 도메인 kakaotech.com을 등록하고, 전체 트래픽 라우팅을 담당하는 DNS 서비스로 Route 53을 사용한다.
- CloudFront와 연동되는 A 레코드를 설정하여, 사용자 요청이 적절한 리소스로 전달되도록 구성한다.
- 도메인 인증 시 DNS 기반의 자동 검증(CNAME 방식)을 통해 HTTPS 인증서 발급과 연동을 간소화하였다.
CloudFront
- 정적 자산은 S3, 동적 트래픽은 EC2를 오리진으로 연결하는 구조로 CDN을 구성하여 성능과 보안 모두를 고려하였다.
- 정적 파일은 CloudFront에서 캐싱되어 빠르게 전달되며, EC2 인스턴스의 부하를 효과적으로 분산시킨다.
- EC2를 통한 동적 요청은 캐싱을 비활성화하여 사용자 요청을 실시간으로 처리하며, 인증서를 통한 HTTPS 암호화도 함께 적용된다.
- 경로 기준 오리진 매핑 기능을 통해 /images/*는 S3, 나머지 경로는 EC2로 유입되도록 설정 가능하다.
ACM
- HTTPS 트래픽 처리를 위해 인증서를 발급하고 관리하는 서비스로, kakaotech.com 및 하위 도메인(*.kakaotech.com)에 대한 인증서를 사용한다.
- Route 53과 연동된 DNS 기반 검증 방식을 사용하여 도메인 인증 절차를 자동화하고, 인증서 갱신 역시 자동으로 처리된다.
- CloudFront에 TLS 인증서를 적용하여 종단 간 보안을 강화하였다.
VPC 및 네트워크
- IP 범위는 10.0.0.0/16을 사용하며, 퍼블릭 서브넷(10.0.1.0/24) 하나로 구성된 단순 네트워크 구조를 채택하였다.
- IGW(Internet Gateway)를 통해 외부 인터넷과 통신 가능하도록 설정되며, 라우트 테이블을 통해 서브넷과 연동된다.
- MVP 초기 구조에서는 프라이빗 서브넷 없이 모든 트래픽을 퍼블릭 서브넷에서 처리한다.
EC2 인스턴스 (All-in-one)
- 프론트엔드(Next.js), 백엔드(Spring Boot), DB(MySQL)를 단일 EC2 인스턴스에 통합하여 배포한다.
- 단일 인스턴스 구조는 비용과 관리 복잡도를 줄이기 위한 초기 전략으로 사용되며, 이후 MSA 또는 오토스케일링 구조로 확장 가능하다.
- 서비스 실행 환경은 t3.medium 타입의 인스턴스를 사용하고, AMI를 통해 기본 환경을 세팅한다.
IAM 및 Security Group
- IAM Role은 EC2 인스턴스에 할당되어 S3 버킷 접근 등의 권한을 제어한다. 특정 Prefix (images/, logs/)에 대해 필요한 권한만 부여하여 최소 권한 원칙을 적용한다.
- Security Group은 다음과 같은 보안 규칙을 포함한다:
  - SSH는 관리자 고정 IP에만 허용
  - HTTP/HTTPS는 EC2에 대해 전체 개방
  - ICMP는 GCP에서의 헬스체크 및 테스트용으로 한정 개방
  - 아웃바운드는 기본적으로 모든 외부 트래픽 허용

8. S3 버킷 구성

Static Files Bucket
- CloudFront 오리진으로 연결되며 HTML, JS, CSS, 이미지 등 정적 자산을 저장
- IAM Role 및 CloudFront 전용 권한을 통해 접근을 제한하고, 퍼블릭 접근은 차단
Log Files Bucket
- EC2 로그를 수집하는 버킷으로, PutObject 권한만 부여하여 보안성 강화
- 라이프사이클 정책을 통해 로그는 30일 후 자동 삭제되며, 버전관리를 통해 복구 가능

2.1.2. Google Cloud Platform

VPC (10.178.0.0/20)
- 독립된 10.178.0.0/20 범위의 네트워크를 사용하며, AWS와의 직접적인 VPC 피어링은 존재하지 않는다.
- GCP 방화벽은 AWS EC2의 고정 퍼블릭 IP만 허용하여 상호 통신 보안을 강화한다.
Compute Engine (AI Model API)
- FastAPI로 개발된 AI 모델 추론 서버를 GPU 기반 GCP 인스턴스에서 운영한다.
- 인스턴스 타입은 n1-standard-4 + T4 GPU로, 모델 서빙을 위한 고속 연산 환경을 제공한다.
- 외부에서 호출 가능한 고정 IP를 할당받아 AWS 백엔드(Spring Boot)에서 REST API 형태로 호출되며, 응답은 실시간으로 처리된다.

🍡 3. 빅뱅 배포 프로세스 설계

3.1. 개요

본 문서는 팀 프로젝트의 MVP 버전을 클라우드 환경에 스크립트 기반 수작업 배포하는 전체 절차를 설명한다.

AI 모델은 GCP 인스턴스에, 프론트엔드 및 백엔드는 AWS EC2에 배포되며, 배포는 GitHub 저장소를 기준으로 배포 스크립트로 실행된다.

또한, CI/CD, Docker, Cloud SQL 등 자동화 및 관리형 서비스를 사용하지 않고, GitHub Clone → 빌드 → 스크립트 실행을 통해 서비스를 일괄 배포한다.

3.2. 배포 전략 요약

항목	내용
배포 방식	스크립트 기반 빅뱅 수작업 배포
배포 환경	GCP (GCE - GPU 모델), AWS (EC2 - FE/BE/DB)
배포 대상	프론트엔드 (Next.js), 백엔드 (Spring Boot), DB (MySQL), AI 모델 (FastAPI)
업로드 방식	인스턴스 내부에서 직접 GitHub 저장소를 `clone`하여, 빌드 및 실행
실행 방식	EC2 및 GCE 내 스크립트 실행 (`deploy_springboot.sh`, `deploy_next.sh`)
롤백 전략	신규 버전 배포 이 후, 헬스체크 진행 → 문제 발생 시 롤백 진행
정적 리소스 배포	정적 리소스는 S3에 업로드되며, CloudFront를 통해 서빙
도메인 및 HTTPS 구성	Route 53에서 도메인을 구매하고, CloudFront에 연결해 HTTPS 인증 구성

3.3. 배포 정의

항목	내용
인프라 구성	GCP GCE, GCP GCS, AWS EC2 , AWS S3, AWS VPC, AWS CloudFront, AWS Route53
프론트엔드 배포	EC2 내부에서 GitHub 클론 → `build` → `Nest.js` 실행
백엔드 배포	EC2 내부에서 GitHub 클론 → `build` → `Spring Boot` 프로세스 백그라운드 실행
AI모델 배포	GCE 내부에서 GitHub 클론 → 프로세스 백그라운드 실행
데이터베이스 구성	인스턴스 내부에 직접 MySQL 설치 및 초기화 수행
배포 흐름	`GitHub 원격 저장소 업로드 -> EC2 인스턴스 접속 -> clone -> build -> 배포 스크립트 실행`의 반복

3.4. 배포 담당 역할 분담

역할	담당자	주요 업무
배포 총괄	클라우드 담당자	소스코드 빌드 및 스크립트 실행, 배포 스케줄 조율, 배포 점검 체크, 최종 승인
프론트 배포자	프론트엔드 개발자	GitHub 원격 저장소에 소스코드 업로드
백엔드 배포자	백엔드 개발자	GitHub 원격 저장소에 소스코드 업로드
AI 모델 배포자	AI 개발자	GitHub 원격 저장소에 소스코드 업로드
테스트	전원	배포 후 기능 Smoke Test 수행

3.5. 배포 시나리오 (전체 흐름)

[1] 인스턴스 환경 설정 스크립트 실행
	[1-1] 의존성 설치 (git, Java, pnpm, PM2 등)
	[1-2] MySQL 설치 및 데이터 초기화
	[1-3] 로그 및 백업 디렉토리 생성

[2] GitHub 저장소에서 최신 소스코드 pull
	[2-1] frontend/next-app
	[2-2] backend/spring

[3] 프론트엔드 배포 (deploy_next.sh)
	[3-1] 기존 빌드 및 설정 파일 백업
	[3-2] 의존성 설치 및 빌드 수행 (pnpm)
	[3-3] PM2를 통해 Next.js 실행
	[3-4] 헬스체크 실패 시 자동 롤백

[4] 백엔드 배포 (deploy_springboot.sh)
	[4-1] 기존 JAR 및 로그 백업
	[4-2] Gradle 빌드 수행
	[4-3] Java로 Spring Boot 실행
	[4-4] 헬스체크 실패 시 자동 롤백

[5] 수동 Smoke Test 및 점검
	[5-1] 브라우저 UI, API 호출, AI 응답 확인
	[5-2] 로그 확인 및 모니터링

[6] 배포 완료 보고 및 PM2 상태 저장

3.6. 수작업 배포 단계별 설명

단계	설명	수행자	사용 도구	예상 소요	다운타임 여부
1	AMI 기반 EC2/GCE 인스턴스 시작	클라우드 담당자	AWS AMI	1분	❌
2	GitHub 저장소 pull	EC2	`git pull`	30초	❌
3	프론트 배포 스크립트 실행	EC2	`bash deploy_next.sh`	4~5분	✅ (단기)
4	백엔드 배포 스크립트 실행	EC2	`bash deploy_springboot.sh`	4~5분	✅ (단기)
5	로그 확인 및 헬스체크 확인	전체	`curl`, `tail`	2분	조건부
6	수동 테스트 및 smoke test 수행	전체	브라우저, Postman	5분	❌
7	최종 배포 완료 보고	전체	Discord	1분	❌
8	AI 서버 실행	스크립트	`uvicorn`	자동	❌
9	헬스체크 및 조건부 롤백	스크립트	`curl`	10초 + (조건부 30초)	조건부(헬스체크 실패 시)
10	수동 테스트 및 보고	전원	브라우저, Postman	5분	❌

3.7. 수동 체크리스트

항목	상태	확인자	확인 일시
인스턴스 환경 설정 성공 (AMI 생성)	☐
GitHub에서 코드 정상 `pull` 완료	☐
프론트 배포 스크립트 실행 (`deploy_next.sh`)	☐
백엔드 배포 스크립트 실행 (`deploy_springboot.sh`)	☐
기존 프로세스 정상 종료 및 백업 완료	☐
정적 리소스 S3 업로드 완료	☐
프론트 헬스체크 200 응답 확인	☐
백엔드 헬스체크 200 응답 확인	☐
AI 모델 응답 확인	☐
로그 파일 확인 (`tail -f spring.log, next.log`)	☐
PM2 상태 저장 (`pm2 save`)	☐
최종 배포 완료 보고	☐