• 협업에 유리한 환경: 로컬에서 발생할 수 있는 환경 불일치, 포트 충돌, 보안 설정 이슈 등을 회피하고, 클라우드 환경에서 일관된 개발 및 배포 환경 제공
• 비용 절감: GCP는 신규 사용자에게 $300 크레딧을 제공하여, 예산이 제한된 초기 팀에 적합
• IaaS 학습 기회 제공: VM, 방화벽, IP 구성, 서브넷 등 클라우드 인프라 구성에 대한 실습 기반 마련
• AWS 전환 고려: AWS와 유사한 구조 덕분에, 향후 마이그레이션 시 전환 부담이 적음

• 빠른 MVP 출시: 초기에는 기능 개발과 피드백 확보가 핵심이기 때문에 자동화보다는 수작업 배포를 통해 각 서비스 흐름을 명확히 이해
• 팀 내 인프라 이해도 증진: 배포 과정 전체를 직접 경험함으로써 구성원들이 서비스 인프라 전반에 대한 감각과 책임 의식을 가질 수 있음

💡 Big Bang 배포란? 모든 컴포넌트를 한 번에 수동으로 설치 및 배포하는 전략으로, 초기 서비스 개발 및 팀 숙련도 향상에 적합한 방식이다.

• 하나의 인스턴스에 프론트엔드(Next.js), 백엔드(Spring Boot), AI 서버(FastAPI), DB(MySQL) 을 모두 구성하여 배포
• 도메인 연결 및 정적 리소스 서빙을 위해 Nginx 웹서버를 도입

• 도메인은 가비아에서 구매, GCP Cloud DNS를 통해 네임서버 설정 및 A레코드로 고정 IP와 연동
• Cloud DNS는 GCP와 네이티브하게 통합되어, 복잡한 외부 DNS 설정 없이 도메인 관리 가능
• 서브도메인(fe.domain.com, api.domain.com 등) 을 설정하여 구조적 URL 구성 가능
• 특히 OAuth2 기반 로그인을 도입한 서비스 특성 상, Redirect URI에 사용할 고정 도메인 확보가 필수적임

• 프론트엔드 정적 리소스(HTML/CSS/JS) 서빙을 위해 경량 웹 서버 필요
• Nginx는 높은 성능과 안정성, 리버스 프록시 기능까지 지원해 초기 구성에 적합
• /var/www/html 경로에 빌드된 정적 리소스를 배치하고, index.html을 기본 엔트리로 설정
• 백엔드 및 AI API 요청은 이후 Nginx 리버스 프록시 또는 별도 포트로 분리 운영 가능

• 프로필 이미지, 기업 이미지 등 개발 초기부터 정적 리소스를 활용하는 우리 서비스의 특성을 반영하여 GCP Cloud Storage를 사용하여 저장
• DB 또는 로컬에 이진수(바이트 배열) 형태로 저장하는 방식은 관리와 확장에 불리함
• URL만 DB에 저장함으로써, 스토리지와 연동된 효율적인 미디어 관리 가능

• 배포 방식: 일괄 수작업 배포 (Big Bang)
• 배포 환경: GCP Compute Engine 인스턴스 (총 1개)
• 배포 대상: 프론트엔드, 백엔드, AI 서버, DB 전부 단일 인스턴스에서 운영
• 접속 방식: SSH를 통한 직접 접속
• 도구: SSH, Git, Nginx, Python (venv), Java (Gradle), MySQL

• 총 배포 시간: 약 20~30분 (병렬 진행 시 15분 내외)

• 서비스 중단 가능성: 각 서버/파일 교체 구간에 2~3분 이내의 다운타임 발생 가능

• 배포 시간대 권장:

  ⏰ 새벽 2시~5시 (트래픽 최소 시간대)

  → 우리 서비스의 주요 타겟이 직장인/구직자이므로 출퇴근·점심시간 외 시간대에 진행

배포 담당자 로컬
└── deploy/
    ├── scripts/
    │   ├── deploy.sh
    │   └── rollback.sh
    ├── frontend/
    │   └── dist/
    ├── backend/
    │   └── build/libs/app.jar
    └── ai-server/
        └── ...

✅ MVP/테스트 환경에서는 보안성과 편의성을 고려하여 SCP 사용을 선택

※ 모든 명령어는 deploy/scripts 디렉토리 기준

#!/bin/bash

SERVER_USER=ssmu-morgan
SERVER_IP=34.64.180.54
SSH_KEY=~/.ssh/gcp-ssmu-dev-key
JAR_NAME=careerbee-0.0.1-SNAPSHOT.jar
PROFILE=dev

# 백엔드 JAR 빌드 아티팩트 경로
LOCAL_JAR_PATH=../backend/3-team-CareerBee-be/build/libs/$JAR_NAME
REMOTE_RELEASE_DIR=~/release
REMOTE_APP_LINK=~/app.jar

TIMESTAMP=$(date +%Y%m%d%H%M%S)
REMOTE_JAR_PATH=$REMOTE_RELEASE_DIR/app-$TIMESTAMP.jar

echo "[1] 백엔드 JAR 전송 중..."
scp -i $SSH_KEY $LOCAL_JAR_PATH $SERVER_USER@$SERVER_IP:$REMOTE_JAR_PATH


echo "[2] 프론트엔드 정적 파일 전송 중..."
scp -i $SSH_KEY -r ../frontend/dist/* $SERVER_USER@$SERVER_IP:/var/www/html/


echo "[3] AI 서버 소스코드 전송 중..."
scp -i $SSH_KEY -r ../ai-server $SERVER_USER@$SERVER_IP:~/ai-server/


echo "[4] 백엔드 실행 중단 및 재시작..."
ssh -i $SSH_KEY $SERVER_USER@$SERVER_IP <<EOF
  pkill -f '$JAR_NAME' || echo "기존 백엔드 없음"
  mkdir -p $REMOTE_RELEASE_DIR ~/logs
  ln -sf $REMOTE_JAR_PATH $REMOTE_APP_LINK
  nohup java -jar -Dspring.profiles.active=$PROFILE $REMOTE_APP_LINK > ~/logs/backend.log 2>&1 &
EOF


echo "[5] AI 서버 재시작..."
ssh -i $SSH_KEY $SERVER_USER@$SERVER_IP <<EOF
  cd ~/ai-server
  python3 -m venv venv && source venv/bin/activate || source venv/bin/activate
  pip install -r requirements.txt
  pkill -f 'uvicorn' || echo "기존 AI 없음"
  nohup uvicorn main:app --host 0.0.0.0 --port 8000 > ~/logs/ai.log 2>&1 &
EOF


echo "✅ 배포 완료"

#!/bin/bash

SERVER_USER=ubuntu
SERVER_IP=<GCP-VM-IP>
SSH_KEY=~/.ssh/gcp-ssmu-dev-key

echo "[1] 최신 이전 버전으로 롤백 중..."

ssh -i $SSH_KEY $SERVER_USER@$SERVER_IP <<EOF
  PREV_JAR=\$(ls -t ~/release/app-*.jar | sed -n 2p)
  if [ -z "\$PREV_JAR" ]; then
    echo "❌ 롤백 가능한 이전 버전이 없습니다."
    exit 1
  fi
  echo "🔁 롤백 대상: \$PREV_JAR"
  pkill -f 'app.jar'
  ln -sf \$PREV_JAR ~/app.jar
  nohup java -jar ~/app.jar > ~/logs/backend_rollback.log 2>&1 &
EOF

echo "✅ 롤백 완료"

# 배포 실행
cd deploy/scripts
bash deploy.sh

# 롤백 실행
bash rollback.sh

• 왜 rollback.sh에 백엔드만 있는가?
  • 개발 파트의 특성을 고려하였다.

따라서 백엔드처럼 롤백이 명확하게 필요한 경우만 롤백 스크립트를 따로 관리하고, 나머지는 문제가 발생하면 다시 빌드된 최신 버전으로 재배포하는 방식이 현 상황에서 더 안정적이라고 판단

• VPC (SSMU-DEV)
  • CIDR: 192.168.0.0/16
• Public Subnet (SUBNET-SSMU-DEV-PUBLIC-Azone)
  • CIDR: 192.168.10.0/24
  • GCP 리전: asia-northeast3a
• Compute Engine (FE + BE + AI + DB)
  • 머신 유형: g2-standard-4
    • vCPU: 4개, 메모리(RAM): 16GB
  • 프론트/백엔드, AI 처리 로직, 데이터베이스가 모두 포함된 단일 VM
  • 퍼블릭 IP가 할당되어 있고, Cloud DNS를 통해 도메인으로 접근 가능
  • 사용자 요청과 개발자 배포 모두 이 인스턴스를 중심으로 이루어짐
• Cloud DNS
  • 사용자 요청을 퍼블릭 IP로 전달
  • 도메인 기반 접근이 가능하도록 설정
• Cloud Storage
  • 정적 리소스(이미지, 파일 등) 저장 용도로 연동
• Dev
  • 개발자는 외부에서 scp, ssh을 통해 직접 서버에 배포

📌 본 페이지는 2025년 5월 7일에 마지막으로 업데이트되었습니다.