1. 배포란 무엇인가

배포(Deploy)란

개발한 코드를 실제 서버에서 실행되도록 반영하는 과정이다.

예를 들어:

FastAPI 코드를 수정함

GitHub에 push함

서버에서 해당 코드가 반영되어 서비스가 변경됨

이 전체 과정이 배포다.

2. 수동배포란?

2-1. 정의

수동배포는

사람이 직접 서버에 접속해서
명령어를 하나하나 실행하는 방식이다.

2-2. 수동배포 흐름 (FastAPI 예시)

1. 로컬에서 코드 수정
2. git push
3. 서버에 SSH 접속
4. git pull
5. 가상환경 활성화
6. pip install
7. 서버 재시작

2-3. 수동배포의 장단점

장점

• 구조 이해하기 쉬움

• 디버깅 직관적

• 초반 학습용으로 좋음

단점

• 매번 같은 작업 반복

• 사람 실수 발생 가능

• 배포 누락 / 순서 실수

• 규모 커질수록 비효율적

혼자 개발할 때는 가능하지만, 실무에서는 한계가 명확

3. CI / CD란?

3-1. CI (Continuous Integration)

Continuous Integration: 지속적 통합

코드 변경이 생길 때마다
자동으로 테스트·빌드·검증을 수행하는 과정

Ex)

• GitHub에 push

• 자동으로 테스트 실행

• 빌드 성공/실패 확인

3-2. CD (Continuous Deployment / Delivery)

Continuous Deployment:지속적 배포

• CI가 통과하면
  자동으로 서버에 배포까지 진행

즉,

코드 push → 테스트 → 배포

가 자동으로 이어짐

4. 자동배포란?

4-1. 정의

사람이 서버에 접속하지 않아도
코드 push만으로 배포가 끝나는 구조

4-2. 자동배포 흐름 (내가 만든 구조 기준)

1. 로컬에서 코드 수정
2. git push (main)
3. GitHub Actions 실행
4. Bastion 서버 접속
5. Private 서버로 이동
6. git pull
7. pip install
8. fastapi 서비스 재시작

5. CI/CD + 자동배포 구조 그림 (개념)

1.Local PC
|
| git push
v
2.GitHub Repository
|
| GitHub Actions (CI/CD)
v
3.Bastion Server
|
v
4.Private FastAPI Server
|
v
5.Service Restart

6. 수동배포 vs 자동배포 비교

구분	수동배포	자동배포
배포 트리거	사람이 직접	git push
서버 접속	필요	불필요
실수 가능성	높음	낮음
반복 작업	많음	없음
실무 적합성	낮음	높음

7. CI/CD를 쓰는 이유 (실무 관점)

• 배포 속도 빠름

• 실수 감소

• 배포 표준화

• 팀 작업에 필수

• 서버 접근 권한 최소화 (서버에 직접 접속 안 하는 것 자체가 보안이다)

8.자동배포의 여러가지 방법들

1. 왜 배포 방식이 중요한가?

배포는 단순히

새 코드를 서버에 올리는 것이 아니라

• 서비스 중단을 최소화

• 에러 발생 시 빠른 롤백

• 사용자 영향 최소화

를 목표로 한다.

그래서 실무에서는 어떻게 배포하느냐 가 매우 중요하다.

2. 대표적인 배포 방식 한눈에 보기

방식	핵심 키워드
롤링 배포	조금씩 교체
블루그린 배포	두 환경 교체
카나리 배포	일부 사용자 테스트
A/B 배포	사용자 실험
리크리에이트 배포	전부 종료 후 재시작

3. 롤링배포

기존 서버를 하나씩 순차적으로 교체하는 방식

서버1 (기존) → 서버1 (신규)
서버2 (기존) → 서버2 (신규)
서버3 (기존) → 서버3 (신규)

--->순차적으로 진행되는 모습

특징

• 서비스 중단 없음

• 배포 중에도 요청 처리 가능

• Kubernetes 기본 전략

장점

• 인프라 비용 증가 없음

• 구조 단순

단점

• 구버전/신버전이 동시에 존재

• DB 스키마 변경 시 위험

• 롤백이 느림

언제 사용?

• 서버가 여러 대일 때

• 변경 사항이 크지 않을 때

4. 블루그린 배포 (Blue-Green Deployment)

개념

완전히 동일한 두 환경을 준비하고
트래픽을 한 번에 전환하는 방식

Blue (현재 서비스 중)
Green (신규 버전 대기)

배포 흐름

--->green 환경에서 문제가 생기면 다시 blue 환경으로 돌아오는 모습

기존 버전은 Blue 환경,
새로운 버전은 Green 환경이라고 부른다.

Green 환경에 새로운 소프트웨어를 배포하고 충분히 테스트한 뒤,
라우터(또는 로드밸런서) 설정을 변경해
모든 들어오는 요청을 Blue가 아닌 Green으로 보내도록 전환한다.

이 시점부터 Green이 실제 운영 환경이 되며,
Blue는 대기 상태로 남겨두거나
다음 업데이트를 위한 템플릿으로 사용하기 위해 제거하거나 갱신할 수 있다.

이 방식은 애플리케이션 배포로 인한 다운타임을 제거할 수 있다.
또한 블루그린 배포는 리스크를 줄여준다.
만약 Green 환경의 새로운 버전에서 문제가 발생하면,
라우터를 다시 Blue로 전환함으로써
즉시 이전 버전으로 롤백할 수 있기 때문이다.

장점

• 무중단 배포

• 롤백이 매우 쉬움 (스위치만 되돌리면 됨)

• 배포 안정성 높음

단점

• 인프라 비용 2배

• 환경 관리 복잡

언제 쓰나?

금융 / 결제 / 핵심 서비스

장애 허용 불가 서비스

5. 카나리 배포 (Canary Deployment)

개념

일부 사용자에게만 새 버전을 먼저 배포하는 방식

(광산의 카나리아에서 유래)

배포 흐름
전체 트래픽 100%

25%-->50%-->75%-->100% 순차적으로 배포하는 모습

1.초기 배포 (Initial Deployment)

운영 중인 전체 환경 중 일부 트래픽, 예를 들어 25% 정도만
새로운 버전으로 업데이트한다.

이때 새 버전을 제공받는 사용자 그룹을 카나리(Canary) 라고 부르며,
이 그룹은 전체 사용자 특성을 잘 대표할 수 있도록 신중하게 선택된다.

즉, 모든 사용자에게 한 번에 배포하지 않고
일부 사용자에게만 먼저 노출시키는 단계다.

2.모니터링 및 피드백 (Monitoring and Feedback)

새 버전의

• 성능

• 안정성

• 전반적인 사용자 경험

을 집중적으로 모니터링한다.

이 단계에서 수집되는 로그, 에러, 사용자 반응은
문제를 조기에 발견하는 데 매우 중요하다.

카나리 배포의 핵심은
문제가 작을 때 발견하는 것 이다.

3.점진적 확장 배포 (Incremental Rollout)

초기 배포에서 문제가 없다고 판단되면
새 버전을 제공하는 비율을 점차 늘린다.

예를 들어:

25% → 50% → 75%

이처럼 단계적으로 확장하면서
각 단계마다 계속해서 상태를 관찰하고 평가한다.

이 과정 덕분에:

• 위험을 통제할 수 있고

• 문제가 발생해도 영향 범위를 제한할 수 있다.

4.전체 배포 (Full Deployment)
새 버전이 충분히 안정적이고
개선 효과가 지속적으로 긍정적이라고 판단되면,
마지막으로 전체 사용자에게 배포한다.

이 시점에서:

기존 버전은 완전히 제거되거나

다음 배포를 위한 기준 버전이 된다.

이 단계로 카나리 배포가 완료된다.

장점

• 장애 영향 최소화

• 실제 사용자 기반 검증

• 위험도 낮음

단점

• 트래픽 분기 설정 필요

• 모니터링 필수

• 구현 난이도 높음

언제 쓰나?

• 대규모 서비스

• 변경 영향이 큰 기능

• 실사용 데이터 검증 필요할 때

6. A/B 배포 (A/B Testing Deployment)

서로 다른 버전을 의도적으로 나눠 제공해
성능/반응을 비교하는 방식

카나리와의 차이

구분	카나리	A/B
목적	안정성 검증	실험
버전 수	기존 + 신규	여러 실험 버전
기준	오류/장애	사용자 반응

예시

추천 알고리즘 A vs B

UI 디자인 A vs B

7. 리크리에이트 배포 (Recreate Deployment)

자동배포 실습때 했던 방식이 이 방식임.
기존 서비스 종료 → 새 서비스 시작

1.서비스 종료
↓
2.배포
↓
3.서비스 시작

장점

• 가장 단순

• 인프라 적음

단점

• 서비스 중단 발생

• 실무에선 거의 안 씀

언제 쓰나?

• 개인 프로젝트

• 내부 서비스

• 트래픽 거의 없을 때

8. 배포 방식 선택 기준 (실무 시각)

상황	추천 방식
개인 프로젝트	리크리에이트
소규모 서비스	롤링
무중단 필수	블루그린
위험한 변경	카나리
사용자 실험	A/B