[SAP] 배포 전략 & CI/CD 파이프라인

Date

2026/03/10

AWS CloudFormation

Stack vs Nested Stack vs StackSets

항목	내용
Stack	단일 계정, 단일 리전 리소스 관리
Nested Stack	대형 템플릿을 모듈화 (재사용성 ↑)
StackSets	멀티 계정 + 멀티 리전 일괄 배포

Nested Stack (중첩 스택)

Nested Stack은 상위 레벨 템플릿에서 리소스로 생성되는 스택이다. 네트워킹•보안 관련 리소스를 하나의 중첩 스택에, 애플리케이션 리소스를 다른 중첩 스택에 분리하면 코드 유지보수성과 재사용성이 향상된다.

Root Stack (부모)
  ├── Nested Stack: VPC + Networking
  ├── Nested Stack: Security (IAM, SG)
  └── Nested Stack: Application (EC2, RDS)
Plain Text
복사

•

장점:

◦

템플릿 51,200 바이트 제한 우회

◦

모듈 재사용 (여러 환경에서 동일 네트워크 스택 재활용)

◦

팀별 독립 관리 가능

•

주의 : 중첩 스택 업데이트는 반드시 루트 스택에서 실행

Change Sets — 안전한 업데이트

Change Set은 스택에 대한 제안된 변경사항이 기존 또는 새로 생성될 리소스에 미치는 영향을 미리 확인할 수 있는 CloudFormation 기능이다. Change Set을 생성하면 CloudFormation은 제출한 리소스 변경사항과 현재 스택을 비교해 변경 목록을 제공한다.

•

Change Set Workflow:

새 템플릿 또는 파라미터 변경사항 제출

Change Set 생성 (실제 변경 아직 없음)

변경 목록 검토 (삭제/교체/수정될 리소스 확인)

승인 후 Execute → 실제 스택 업데이트

•

핵심: RDS 인스턴스가 “교체(Replcae)”로 표시되면 
데이터 손실 위험 → Execute 전 확인 필수

프로덕션 스택 업데이트 시 영향도를 미리 파악 → Change Sets

예상치 못한 리소스 삭제 방지 → Change Set 검토 후 Execute

Drift Detection — 구성 불일치 탐지

CloudFormation 스택 배포 후 누군가 콘솔에서 SG 규칙을 직접 수정 → 드리프트 발생

Drift Detection 실행 → 현재 실제 구성 vs CloudFormation 템플릿 비교 → 불일치 리소스 목록 반환 → IaC 상태로 재동기화 가능

StackSets — 멀티계정 자동 배포

CloudFormation StackSets는 단일 작업으로 여러 AWS 계정과 리전에 걸쳐 스택을 생성•업데이트•삭제할 수 있도록 스택의 기능을 확장한다.

StackSets 권한

•

Self-managed: 계정 간 배포를 위해 필요한 IAM 역할을 직접 생성한다. 이 모델로 StackSets는 IAM 역할 생성 권한이 있는 모든 AWS 계정에 배포할 수 있다.

•

Service-managed: AWS Organizations가 관리하는 계정에 스택 인스턴스를 배포할 수 있다. 이 모델에서는 필요한 IAM 역할을 직접 생성하지 않아도 되며, StackSets가 대신 생성한다. 또한 향후 조직에 추가될 계정에 자동으로 배포되도록 설정할 수 있다.

항목	Self-managed	Service-managed
IAM 역할	직접 생성 필요	StackSets 자동 생성
Organizations 필요
신규 계정 자동 배포		(Auto Deployment)
적합한 상황	Organizations 외부 계정	Organizations 내부 계정

StackSets + Organizations 자동 배포 패턴 (시험 단골)

Organizations
  ├── Management Account
  │     └── StackSet 생성 (Service-managed)
  │           ├── 대상: OU "Production" 전체
  │           └── Auto Deployment: ON
  │
  ├── OU: Production
  │     ├── Account A → Stack 자동 생성 ✅
  │     ├── Account B → Stack 자동 생성 ✅
  │     └── Account C (신규 가입) → Stack 자동 생성 ✅ ← Auto Deployment
Plain Text
복사

•

사용 사례:

◦

전체 계정에 CloudTrail Trail 자동 활성화

◦

전체 계정에 AWS Config Recorder 자동 배포

◦

전체 계정에 기본 VPC/보안 그룹 표준 배포

신규 계정 추가 시 자동으로 보안 설정 배포 → StackSets + Organizations + Auto Deployment, Service-managed 권한 모델 사용

AWS CloudFormationManaging stacks across accounts and Regions with StackSets - AWS CloudFormation

배포 전략

전략별 핵심 비교

다운타임 있음 ◄──────────────────────────────► 다운타임 없음
위험도 높음  ◄──────────────────────────────► 위험도 낮음

All-at-once → Rolling → Rolling+batch → Blue/Green → Canary
Plain Text
복사

전략 1 — All-at-once (일괄 배포)

Before: [v1][v1][v1][v1]
During: [  ][  ][  ][  ]  ← 전체 중단
After:  [v2][v2][v2][v2]
Plain Text
복사

•

장점: 가장 빠름

•

단점: 배포 중 다운타임 발생

•

용도: 개발/테스트 환경

전략 2 — Rolling (순차 배포)

Step 1: [v2][v1][v1][v1]
Step 2: [v2][v2][v1][v1]
Step 3: [v2][v2][v2][v1]
Step 4: [v2][v2][v2][v2]
Plain Text
복사

•

장점: 다운타임 없음, 추가 인스턴스 비용 없음

•

단점: 배포 중 v1, v2 동시 운영, 느림, 배포 중 총 용량 감소

전략 3 — Rolling with Additional Batch

기존 4대에 배치(1대) 추가 → 5대로 Rolling 배포
→ 배포 중에도 항상 4대 유지
Plain Text
복사

•

장점: 용량 감소 없이 Rolling 가능

•

단점: 추가 인스턴스 일시 비용 발생

전략 4 — Blue/Green

Blue (현재 프로덕션): [v1][v1][v1][v1]
Green (신규 환경):    [v2][v2][v2][v2]  ← 별도 생성

테스트 완료 후:
Route 53 또는 ELB → Green으로 트래픽 전환
Blue는 일정 기간 대기 (롤백용)
Plain Text
복사

•

장점: 즉각 롤백 가능 (Blue로 재전환), 다운타임 없음

•

단점: 일시적으로 2배 인프라 비용

•

용도: 프로덕션 배포, 중요 서비스

전략 5 — Canary

Step 1: v1 90% + v2 10%  ← 소수 사용자에게 먼저 배포
Step 2: 모니터링 (CloudWatch Alarms)
Step 3-a: 정상 → v2 100%로 전환
Step 3-b: 이상 → 자동 롤백 v1 100%
Plain Text
복사

•

장점: 위험 최소화, 실제 트래픽으로 검증

•

단점: 배포 시간이 가장 길 수 있음

•

용도: Lambda, ECS 배포, 고위험 변경사항

빠른 배포, 다운타임 허용 → All-at-once

다운타임 없음, 추가 비용 최소화 → Rolling

다운타임 없음, 배포 중 용량 유지 → Rolling with Additional Batch

즉각 롤백 가능, 프로덕션 안정성 → Blue/Green

소수 사용자 검증 후 점진적 배포 → Canary

AWS CodePipeline + CodeBuild + CodeDeploy

CI/CD 전체 흐름

[Source]          [Build]         [Test]         [Deploy]
CodeCommit    →  CodeBuild    →  CodeBuild   →  CodeDeploy
GitHub            (빌드·테스트)    (통합테스트)     (EC2/ECS/Lambda)
S3
     │                                              │
     └──────────── CodePipeline 오케스트레이션 ─────────┘
Plain Text
복사

CodeBuild

•

완전 관리형 빌드 서비스 (Jenkins 대체)

•

buildspec.yml 파일로 빌드 명령 정의

•

Docker 이미지 빌드 + ECR 푸시 가능

•

병렬 빌드 지원

CodeDeploy — 플랫폼별 배포 전략

In-place 배포는 EC2/온프레미스 플랫폼에서만 사용 가능하다. AWS Lambda와 Amazon ECS 배포는 In-place 배포 유형을 사용할 수 없다. Lambda와 ECS는 Blue/Green 배포로 Canary, Linear, All-at-once 트래픽 전환 방식을 지원한다.

플랫폼	In-place	Blue/Green	Canary/Linear
EC2 / On-premises
Lambda		(기본)
ECS		(기본)

In-place 배포는 CodeDeploy Agent가 각 인스턴스에 접속하여 실행 중인 애플리케이션을 중지(Stop)하고 새 버전 코드를 다운로드 및 설치하며, 애플리케이션을 재시작한다. 즉, 새 인스턴스를 만들지 않고, 기존 인스턴스 위에서 애플리케이션만 교체하는 배포 방식이다.

Lambda 배포 트래픽 전환 전략

Lambda 플랫폼 배포 시 Canary, Linear, All-at-once 방식으로 트래픽을 새 Lambda 함수 버전으로 전환할 수 있다.

•

Lambda Canary:

LambdaCanary10Percnet5Minutes → 10% 트래픽을 새 버전으로 5분간 테스트 → 이상 없으면 나머지 90% 전환

•

Lambda Linear:

LambdaLinear10PercentEvery1Minute → 1분마다 10%씩 점진적 전환

•

Lamda All-at-once:

→ 즉시 100% 전환

AppSpec 파일 — 플랫폼별 구조

# EC2 AppSpec (appspec.yml)
version: 0.0
os: linux
files:
  - source: /app
    destination: /var/www/html
hooks:
  BeforeInstall:
    - location: scripts/stop_server.sh
  ApplicationStart:
    - location: scripts/start_server.sh
  ValidateService:     # 제일 마지막 검증을 위해 실행되며 실패 시 이전 버전으로 롤백
    - location: scripts/validate.sh

# Lambda AppSpec
version: 0.0
Resources:
  - MyLambdaFunction:
      Type: AWS::Lambda::Function
      Properties:
        Name: MyFunction
        Alias: live
        CurrentVersion: "1"
        TargetVersion: "2"
hooks:
  BeforeAllowTraffic: PreTrafficHook  # 트래픽 전환 전 검증
  AfterAllowTraffic: PostTrafficHook  # 트래픽 전환 후 검증
YAML
복사

자동 롤백 트리거 — CloudWathch Alarms 연동

CodeDeploy 배포 진행 중
    │
    ▼
CloudWatch Alarm 임계값 초과 (예: 에러율 > 5%)
    │
    ▼
CodeDeploy 자동 롤백 트리거
    │
    ▼
이전 버전으로 자동 복구
Plain Text
복사

설정 방법:

Deployment Group → Rollback Configuration → “Roll back when a deployment fails” → “Roll back when alarm thresholds are met” → CloudWatch Alarm 연결

배포 후 에러율 증가 시 자동 롤백 → CodeDeploy + CloudWatch Alarms 자동 롤백 설정

AWS CodeDeployWorking with deployment configurations in CodeDeploy - AWS CodeDeploy

AWS Systems Manager

주요 기능

항목	기능
Parameter Store	설정값•비밀 저장 (Secrets Manager와 비교)
Session Manager	SSH 없이 EC2 접속 (포트 22 불필요)
Patch Manager	OS 패치 자동화
Run Command	다수 인스턴스에 명령 일괄 실행
Inventory	인스턴스 소프트웨어•구성 현황 수집
OpsCenter	운영 이슈 중앙 관리

Session Manager — Bastion Host 대체

•

기존 방식 (Bastion Host):

◦

인터넷 → Bastion EC2 (Port 22 열림) → 프라이빗 EC2

•

Session Manager 방식:

◦

콘솔/CLI → SSM Agent (아웃바운드 443만 필요) → 프라이빗 EC2

•

장점:

◦

포트 22 완전 차단 가능

◦

SSH 키 관리 불필요

◦

세션 로그 S3/CloudWath 자동 저장

◦

IAM으로 접근 제어

보안 강화를 위해 SSH 포트를 열지 않고 EC2 접속 → Session Manager

Bastion Host 구성 문제에서 Session Manager가 항상 더 나은 답이다.

Run Command vs Patch Manager

•

Run Command:

◦

즉시 명령 실행 (예: 서비스 재시작, 스크립트 실행)

◦

대상: 태그, 인스턴스 ID, 리소스 그룹

•

Patch Manager:

◦

정기 패치 스케줄링 (Maintenance Window 연동)

◦

패치 베이스라인(어떤 패치 적용) 정의 가능

◦

패치 결과 Compliance 리포트 생성

AWS Systems ManagerWhat is AWS Systems Manager? - AWS Systems Manager

Elastic Beanstalk 배포 정책

정책	방식	다운타임	롤백 속도	추가 비용
All-at-once	전체 동시 업데이트	있음	재배포 필요	없음
Rolling	배치 단위 순차	없음	재배포 필요	없음
Rolling with batch	추가 인스턴스로 Rolling	없음	재배포 필요	일시적
Immutable	새 ASG 생성 후 교체	없음	즉각 (기존 ASG 유지)	일시적 2배
Traffic Splitting	트래픽 %로 Canary	없음	즉각	일시적

Beanstalk에서 가장 안전한 배포, 즉각 롤백 가능 → Immutable

소수 사용자에게 먼저 검증 → Traffic Slitting

AWS Service Catalog

Service-managed 권한으로 StackSets는 Organizations가 관리하는 계정에 배포할 때 필요한 IAM 역할을 자동으로 생성한다.

•

Service Catalog 사용 사례:

◦

IT 팀 → 승인된 CloudFormation 포트폴리오 등록

◦

개발자 → 셀프서비스로 승인된 템플릿만 사용 가능

→ 조직 표준 벗어난 리소스 생성 방지

•

Control Tower Account Factory와 조합:

◦

신규 계정 생성 시 Service Catalog 제품으로 표준 환경 자동 프로비저닝

Summary

개념	한 줄 요약
Nested Stack	대형 템플릿 모듈화. 루트에서 업데이트 실행
Change Sets	업데이트 영향도 사전 확인. Execute 전 리소스 교체 여부 검토
Drift Detection	실제 구성 vs IaC 불일치 탐지
StackSets Self-managed	IAM 역할 직접 생성. Organizations 불필요
StackSets Service-managed	IAM 자동 생성. Organizations 필수. 신규 계정 자동 배포 가능
Blue/Green	2배 인프라, 즉각 롤백. ELB 대상 그룹 또는 Route 53 전환
Canary	소수 트래픽 먼저. CloudWatch 알람 기반 자동 롤백
EC2 CodeDeploy	In-place + Blue/Green 모두 가능
Lambda/ECS CodeDeploy	In-place 불가. Blue/Green (Canary/Linear) 만 가능
Session Manager	SSH 없이 EC2 접속. 포트 22 차단 가능
Beanstalk Immutable	가장 안전. 즉각 롤백. 일시 2배 비용