CloudFormation으로 Infrastructure as Code 구현하기

AWS CloudFormation을 사용하여 인프라를 코드로 관리하는 방법을 배웁니다. 스택과 템플릿의 개념부터 실제 리소스 배포까지, 초급자도 쉽게 따라할 수 있는 실습 중심의 가이드입니다.

---

목차

1. Infrastructure as Code의 필요성
2. CloudFormation의 핵심 개념
3. YAML 템플릿 작성 기초
4. Parameters Resources Outputs 섹션
5. 스택 생성 및 업데이트 실습
6. Change Set으로 변경 사항 미리보기

---

1. Infrastructure as Code의 필요성

어느 날 김개발 씨는 운영 서버에 심각한 문제가 발생했다는 연락을 받았습니다. 급하게 새 서버를 구성해야 하는데, 기존 서버가 어떻게 설정되어 있었는지 아무도 정확히 기억하지 못했습니다.

"분명 3개월 전에 보안 그룹 설정을 바꿨는데..." 누가, 언제, 무엇을 변경했는지 알 수 없는 상황이었습니다.

**Infrastructure as Code(IaC)**는 서버, 네트워크, 데이터베이스 같은 인프라를 코드로 정의하고 관리하는 방식입니다. 마치 요리 레시피처럼 인프라 구성을 문서화하여, 언제든 동일한 환경을 재현할 수 있게 합니다.

수동 클릭 대신 코드로 관리하면 버전 관리, 협업, 자동화가 가능해집니다.

다음 코드를 살펴봅시다.

# 전통적인 방식: AWS 콘솔에서 수동 클릭
# 1. EC2 콘솔 접속
# 2. 인스턴스 시작 버튼 클릭
# 3. AMI 선택, 인스턴스 타입 선택...
# 4. 보안 그룹 설정...
# 5. 키 페어 생성...
# (매번 수동으로 반복, 실수 가능성 높음)

# IaC 방식: 코드로 정의
AWSTemplateFormatVersion: '2010-09-09'
Resources:
  MyWebServer:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: ami-0c55b159cbfafe1f0
      InstanceType: t2.micro
      # 이 코드 하나로 동일한 서버를 언제든 재생성

김개발 씨는 입사 6개월 차 주니어 개발자입니다. 어느 날 갑자기 운영팀에서 긴급 연락이 왔습니다.

메인 서버에 장애가 발생했고, 빠르게 동일한 환경의 새 서버를 구성해야 한다는 것이었습니다. 문제는 여기서 시작됩니다.

기존 서버가 어떻게 구성되어 있었는지 정확히 아는 사람이 없었습니다. 3개월 전에 누군가 보안 그룹을 수정했고, 2개월 전에는 다른 누군가가 IAM 역할을 변경했습니다.

그 모든 변경 사항이 콘솔에서 클릭 몇 번으로 이루어졌기 때문에 기록이 남아있지 않았습니다. 선배 개발자 박시니어 씨가 한숨을 쉬며 말했습니다.

"이래서 Infrastructure as Code가 필요한 거야. 우리가 왜 이렇게 고생하는지 이제 알겠지?" Infrastructure as Code란 무엇일까요?

쉽게 비유하자면, 요리 레시피와 같습니다. 숙련된 요리사가 머릿속으로만 기억하고 요리한다면, 그 요리사가 없을 때 같은 맛을 낼 수 없습니다.

하지만 레시피가 있다면 누구든 동일한 요리를 만들 수 있습니다. 인프라도 마찬가지입니다.

AWS 콘솔에서 마우스로 클릭하며 서버를 구성하는 것은 머릿속 레시피로 요리하는 것과 같습니다. 하지만 이를 코드로 작성해두면, 언제든 동일한 인프라를 재현할 수 있습니다.

IaC가 없던 시절에는 어땠을까요? 개발자들은 서버를 구성할 때마다 콘솔에 접속해서 하나하나 클릭해야 했습니다.

개발 환경, 스테이징 환경, 운영 환경을 만들 때마다 같은 작업을 반복했습니다. 사람이 하는 일이니 실수도 잦았습니다.

더 큰 문제는 변경 이력이 남지 않는다는 것이었습니다. "지난달에 보안 그룹 어떻게 설정했더라?" 같은 질문에 누구도 정확히 답할 수 없었습니다.

장애가 발생하면 원인을 파악하기도 어려웠습니다. 바로 이런 문제를 해결하기 위해 IaC가 등장했습니다.

인프라를 코드로 정의하면 Git으로 버전 관리를 할 수 있습니다. 누가, 언제, 무엇을 변경했는지 모든 기록이 남습니다.

코드 리뷰를 통해 실수를 미리 잡을 수도 있습니다. 또한 자동화가 가능해집니다.

CI/CD 파이프라인에 인프라 배포를 포함시키면, 코드를 푸시하는 것만으로 인프라가 자동으로 구성됩니다. 개발자가 콘솔에 접속할 필요가 없어집니다.

무엇보다 일관성을 보장합니다. 같은 코드로 배포하면 항상 같은 결과가 나옵니다.

개발 환경과 운영 환경의 차이로 인한 "제 컴퓨터에서는 되는데요" 문제가 사라집니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

만약 그 팀이 IaC를 사용하고 있었다면 어땠을까요? Git 저장소에서 인프라 코드를 가져와 명령어 한 줄로 동일한 서버를 배포할 수 있었을 것입니다.

누가 언제 무엇을 변경했는지 Git 히스토리에서 확인할 수 있었을 것입니다. 이것이 바로 Infrastructure as Code의 힘입니다.

AWS에서는 이러한 IaC를 구현하기 위해 CloudFormation이라는 서비스를 제공합니다. 다음 장에서 CloudFormation의 핵심 개념을 자세히 알아보겠습니다.

실전 팁

💡 - 인프라 코드는 애플리케이션 코드와 같은 저장소 또는 별도의 인프라 전용 저장소에서 버전 관리하세요

• 수동으로 콘솔에서 변경한 내용은 반드시 코드에도 반영하는 습관을 들이세요

---

2. CloudFormation의 핵심 개념

박시니어 씨가 김개발 씨에게 CloudFormation 교육을 시작했습니다. "CloudFormation을 이해하려면 두 가지 핵심 개념을 알아야 해.

바로 템플릿과 스택이야." 김개발 씨는 펜을 들고 노트할 준비를 했습니다.

웹 서버 인프라 템플릿 Resources: WebServer: Type: AWS::EC2::Instance Properties: InstanceType: t2.micro ImageId: ami-0c55b159cbfafe1f0 # 스택 (Stack) 생성 - AWS CLI 명령어 # aws cloudformation create-stack \ # --stack-name my-web-stack \ # --template-body file://template.yaml

다음 코드를 살펴봅시다.

# 템플릿 (Template) - 설계도
# template.yaml 파일로 저장
AWSTemplateFormatVersion: '2010-09-09'

박시니어 씨가 화이트보드에 그림을 그리기 시작했습니다. "CloudFormation을 이해하려면 두 가지 개념을 확실히 알아야 해.

템플릿과 스택이야." 김개발 씨가 고개를 갸웃했습니다. "템플릿은 알겠는데, 스택은 뭔가요?" 박시니어 씨가 웃으며 비유를 들었습니다.

"집을 지을 때 설계도가 필요하잖아? 그 설계도가 바로 템플릿이야.

그리고 그 설계도를 가지고 실제로 지은 집이 스택이지." 하나의 설계도로 똑같은 집을 여러 채 지을 수 있듯이, 하나의 템플릿으로 여러 개의 스택을 만들 수 있습니다. 예를 들어 같은 템플릿으로 개발용 스택, 스테이징용 스택, 운영용 스택을 각각 생성할 수 있습니다.

템플릿은 YAML 또는 JSON 형식으로 작성합니다. 최근에는 가독성이 좋은 YAML 형식을 더 많이 사용합니다.

템플릿 파일에는 어떤 AWS 리소스를 만들지, 각 리소스의 속성은 무엇인지 정의합니다. 스택은 CloudFormation이 템플릿을 읽고 실제로 AWS에 생성한 리소스들의 모음입니다.

중요한 점은 스택에 포함된 리소스들은 하나의 단위로 관리된다는 것입니다. 스택을 삭제하면 그 안에 포함된 모든 리소스가 함께 삭제됩니다.

김개발 씨가 질문했습니다. "그럼 실수로 스택을 삭제하면 모든 리소스가 다 날아가는 건가요?" 박시니어 씨가 고개를 끄덕였습니다.

"맞아, 그래서 운영 환경의 스택에는 삭제 방지 설정을 해두는 게 좋아. 그리고 중요한 데이터가 있는 RDS 같은 리소스는 DeletionPolicy를 Retain으로 설정해서 스택을 삭제해도 데이터베이스는 남도록 할 수 있어." 스택의 또 다른 장점은 상태 관리입니다.

CloudFormation은 스택에 포함된 리소스들의 현재 상태를 추적합니다. 템플릿을 수정하고 스택을 업데이트하면, CloudFormation이 현재 상태와 원하는 상태를 비교해서 필요한 변경만 수행합니다.

이것을 선언적(Declarative) 방식이라고 합니다. "EC2 인스턴스를 생성하라"가 아니라 "EC2 인스턴스가 있어야 한다"고 선언하는 것입니다.

이미 있으면 그대로 두고, 없으면 만들고, 설정이 다르면 수정합니다. 박시니어 씨가 정리해주었습니다.

"정리하면, 템플릿은 코드로 작성된 설계도고, 스택은 그 설계도로 만든 실제 인프라야. 이 두 가지만 제대로 이해하면 CloudFormation의 절반은 이해한 거야." 김개발 씨는 고개를 끄덕였습니다.

이제 본격적으로 템플릿을 작성하는 방법을 배울 차례입니다.

실전 팁

💡 - 스택 이름은 환경을 구분할 수 있도록 명명 규칙을 정하세요 (예: myapp-dev, myapp-prod)

• 운영 환경 스택에는 반드시 삭제 방지(Termination Protection) 설정을 활성화하세요

---

3. YAML 템플릿 작성 기초

김개발 씨가 처음으로 CloudFormation 템플릿 파일을 열었습니다. YAML 형식의 들여쓰기와 구조가 낯설게 느껴졌습니다.

박시니어 씨가 옆에서 말했습니다. "걱정 마, YAML은 사람이 읽기 쉽도록 만들어진 형식이야.

몇 가지 규칙만 알면 금방 익숙해질 거야."

나의 첫 번째 CloudFormation 템플릿 # 파라미터 섹션 - 배포 시 입력받을 값 Parameters: EnvironmentType: Type: String Default: dev AllowedValues: - dev - prod # 리소스 섹션 - 생성할 AWS 리소스 정의 Resources: MyS3Bucket: Type: AWS::S3::Bucket Properties: BucketName: !Sub 'my-bucket-${EnvironmentType}' # 출력 섹션 - 스택 생성 후 확인할 값 Outputs: BucketName: Value: !Ref MyS3Bucket

다음 코드를 살펴봅시다.

AWSTemplateFormatVersion: '2010-09-09'

박시니어 씨가 새 파일을 열고 타이핑을 시작했습니다. "CloudFormation 템플릿은 YAML이라는 형식으로 작성해.

JSON으로도 쓸 수 있지만, YAML이 훨씬 읽기 쉬워서 요즘은 대부분 YAML을 써." 김개발 씨가 화면을 유심히 보았습니다. "YAML은 처음 보는데요, 어렵지 않나요?" 박시니어 씨가 미소를 지었습니다.

"전혀 어렵지 않아. YAML의 핵심은 딱 두 가지야.

들여쓰기와 키-값 쌍." YAML에서 들여쓰기는 계층 구조를 나타냅니다. 마치 폴더 안에 폴더가 있는 것처럼요.

같은 레벨에 있는 항목들은 같은 들여쓰기를 가지고, 하위 항목은 더 깊은 들여쓰기를 가집니다. 중요한 규칙이 있습니다.

반드시 **공백(스페이스)**을 사용해야 하며, **탭(Tab)**은 사용하면 안 됩니다. 보통 공백 2칸을 한 단계로 사용합니다.

이 규칙을 어기면 템플릿이 동작하지 않습니다. 키-값 쌍은 콜론(:)으로 구분합니다.

Type: String처럼 키 다음에 콜론, 공백, 값 순서로 작성합니다. 콜론 뒤에 공백을 빼먹으면 에러가 발생하니 주의하세요.

CloudFormation 템플릿의 기본 구조를 살펴보겠습니다. 가장 먼저 AWSTemplateFormatVersion이 옵니다.

현재는 '2010-09-09'가 유일한 버전입니다. 그 다음 Description에 템플릿에 대한 설명을 적습니다.

그 아래로 여러 섹션이 올 수 있습니다. Parameters는 배포할 때 입력받을 값을 정의합니다.

Resources는 실제로 생성할 AWS 리소스를 정의합니다. Outputs는 스택 생성 후 확인할 값을 정의합니다.

이 중에서 Resources 섹션만 필수이고, 나머지는 선택사항입니다. 하지만 실무에서는 대부분 Parameters와 Outputs도 함께 사용합니다.

템플릿에서 자주 보이는 느낌표(!)로 시작하는 것들은 **내장 함수(Intrinsic Functions)**입니다. !Ref는 다른 리소스나 파라미터를 참조하고, !Sub는 문자열 치환을 수행합니다.

이런 함수들은 다음 장에서 더 자세히 다루겠습니다. 박시니어 씨가 강조했습니다.

"YAML 작성할 때 가장 흔한 실수가 들여쓰기 오류야. 에디터에서 YAML 린터를 활성화해두면 실시간으로 오류를 잡아줘서 편해." 김개발 씨가 직접 템플릿을 작성해보았습니다.

처음에는 들여쓰기가 헷갈렸지만, 몇 번 연습하니 금방 익숙해졌습니다. YAML은 생각보다 직관적이고 읽기 쉬운 형식이었습니다.

실전 팁

💡 - VS Code나 IntelliJ에 CloudFormation 플러그인을 설치하면 자동 완성과 문법 검사가 가능합니다

• YAML 들여쓰기는 반드시 스페이스를 사용하고, 탭은 절대 사용하지 마세요

---

4. Parameters Resources Outputs 섹션

기본 구조를 익힌 김개발 씨가 박시니어 씨에게 물었습니다. "템플릿에 Resources만 있으면 되는 거 아닌가요?

Parameters랑 Outputs는 왜 필요한 거예요?" 박시니어 씨가 답했습니다. "좋은 질문이야.

그 세 가지가 CloudFormation의 핵심이거든."

생성된 EC2 인스턴스 ID Value: !Ref WebServer Export: Name: !Sub '${Environment}-WebServerInstanceId'

다음 코드를 살펴봅시다.

AWSTemplateFormatVersion: '2010-09-09'

# Parameters: 배포 시 입력받는 값
Parameters:
  InstanceType:
    Type: String
    Default: t2.micro
    AllowedValues: [t2.micro, t2.small, t2.medium]

박시니어 씨가 화이트보드에 세 개의 상자를 그렸습니다. "CloudFormation 템플릿을 레스토랑에 비유해볼게.

Parameters는 손님의 주문, Resources는 주방에서 만드는 요리, Outputs는 완성된 요리와 함께 나오는 영수증이야." 먼저 Parameters 섹션을 살펴보겠습니다. Parameters는 템플릿을 배포할 때 입력받는 값입니다.

같은 템플릿으로 개발 환경과 운영 환경을 만들 때, 인스턴스 타입이나 환경 이름 같은 값만 다르게 입력하면 됩니다. Parameters에는 다양한 옵션을 설정할 수 있습니다.

Type은 파라미터의 자료형입니다. String, Number, List 등이 있습니다.

Default는 기본값이고, AllowedValues는 선택 가능한 값들을 제한합니다. 이렇게 하면 잘못된 값을 입력하는 실수를 방지할 수 있습니다.

김개발 씨가 끄덕였습니다. "아, 그래서 같은 템플릿으로 dev, staging, prod 환경을 만들 수 있는 거군요!" 다음은 Resources 섹션입니다.

이 섹션은 템플릿에서 유일하게 필수인 섹션입니다. 여기서 EC2 인스턴스, S3 버킷, RDS 데이터베이스 등 실제로 생성할 AWS 리소스를 정의합니다.

각 리소스는 논리적 이름(Logical Name)을 가집니다. 위 예제에서 WebServer가 바로 논리적 이름입니다.

이 이름은 템플릿 내에서 해당 리소스를 참조할 때 사용됩니다. !Ref WebServer처럼요.

Type은 어떤 AWS 리소스인지 지정합니다. AWS::EC2::Instance, AWS::S3::Bucket 같은 형식입니다.

Properties에는 해당 리소스의 세부 설정을 입력합니다. 마지막으로 Outputs 섹션입니다.

스택이 생성된 후 중요한 정보를 확인하거나 다른 스택에서 사용할 수 있도록 내보내는 역할을 합니다. 예를 들어 EC2 인스턴스의 퍼블릭 IP 주소, 생성된 S3 버킷 이름, RDS 엔드포인트 등을 Output으로 내보낼 수 있습니다.

Export를 사용하면 다른 스택에서 이 값을 참조할 수 있습니다. 박시니어 씨가 실무 팁을 알려주었습니다.

"Outputs에 Export를 설정하면 다른 스택에서 !ImportValue로 참조할 수 있어. 이걸 **크로스 스택 참조(Cross-Stack Reference)**라고 해.

네트워크 스택에서 VPC ID를 Export하고, 애플리케이션 스택에서 Import하는 식으로 사용하지." 김개발 씨가 정리했습니다. "Parameters로 유연하게, Resources로 리소스 정의, Outputs로 결과 확인 및 공유.

이 세 가지가 CloudFormation의 뼈대군요!"

실전 팁

💡 - Parameters에 AllowedValues를 설정하여 잘못된 입력을 사전에 방지하세요

• 자주 변경되는 값은 Parameters로, 고정된 값은 Resources에 직접 작성하세요

---

5. 스택 생성 및 업데이트 실습

김개발 씨가 드디어 첫 번째 템플릿 작성을 마쳤습니다. 이제 이 템플릿으로 실제 AWS 리소스를 생성할 차례입니다.

박시니어 씨가 터미널을 열며 말했습니다. "자, 이제 네가 만든 설계도로 진짜 건물을 지어볼 거야."

스택 생성은 aws cloudformation create-stack 명령어로 수행합니다. 템플릿에 정의된 모든 리소스가 순서대로 생성됩니다.

스택 업데이트는 update-stack 명령어를 사용하며, CloudFormation이 변경된 부분만 자동으로 파악하여 적용합니다.

다음 코드를 살펴봅시다.

# 1. 스택 생성
aws cloudformation create-stack \
  --stack-name my-web-stack \
  --template-body file://template.yaml \
  --parameters ParameterKey=Environment,ParameterValue=dev \
               ParameterKey=InstanceType,ParameterValue=t2.micro

# 2. 스택 생성 상태 확인
aws cloudformation describe-stacks --stack-name my-web-stack

# 3. 스택 이벤트 확인 (진행 상황 모니터링)
aws cloudformation describe-stack-events --stack-name my-web-stack

# 4. 템플릿 수정 후 스택 업데이트
aws cloudformation update-stack \
  --stack-name my-web-stack \
  --template-body file://template.yaml \
  --parameters ParameterKey=InstanceType,ParameterValue=t2.small

# 5. 스택 삭제 (모든 리소스 함께 삭제)
aws cloudformation delete-stack --stack-name my-web-stack

박시니어 씨가 터미널 창을 열었습니다. "템플릿은 설계도일 뿐이야.

이제 이 설계도로 실제 리소스를 만들어볼 거야." 스택을 생성하려면 create-stack 명령어를 사용합니다. --stack-name으로 스택 이름을 지정하고, --template-body로 템플릿 파일 경로를 알려줍니다.

파라미터가 있다면 --parameters로 전달합니다. 명령어를 실행하면 CloudFormation이 백그라운드에서 리소스를 생성하기 시작합니다.

즉시 완료되는 것이 아니라 시간이 걸립니다. EC2 인스턴스 하나 정도는 1-2분, 복잡한 인프라는 10분 이상 걸리기도 합니다.

김개발 씨가 물었습니다. "생성이 잘 되고 있는지 어떻게 알 수 있어요?" describe-stack-events 명령어로 진행 상황을 확인할 수 있습니다.

각 리소스의 생성 상태가 시간순으로 나타납니다. CREATE_IN_PROGRESS, CREATE_COMPLETE, 또는 CREATE_FAILED 같은 상태를 볼 수 있습니다.

만약 중간에 에러가 발생하면 어떻게 될까요? CloudFormation은 **롤백(Rollback)**을 수행합니다.

이미 생성된 리소스들을 모두 삭제하고 이전 상태로 돌아갑니다. 이것이 CloudFormation의 큰 장점입니다.

절반만 생성되어 어중간한 상태로 남는 일이 없습니다. 스택 생성이 완료되면 이제 업데이트를 해봅시다.

템플릿을 수정한 후 update-stack 명령어를 실행합니다. CloudFormation은 현재 상태와 새 템플릿을 비교하여 변경이 필요한 부분만 업데이트합니다.

박시니어 씨가 주의사항을 알려주었습니다. "여기서 중요한 게 있어.

어떤 변경은 리소스를 교체(Replace)해야 해. 예를 들어 EC2의 AMI ID를 바꾸면 기존 인스턴스를 삭제하고 새로 만들어야 해." 이런 변경을 **대체(Replacement)**라고 합니다.

반면 인스턴스의 태그를 바꾸는 것은 기존 리소스를 그대로 두고 수정만 하는 **업데이트(Update)**입니다. 어떤 속성이 어떤 종류의 변경을 유발하는지는 AWS 문서에서 확인할 수 있습니다.

실수로 리소스가 교체되면 데이터가 날아갈 수 있습니다. 그래서 운영 환경에서는 update-stack을 바로 실행하지 않습니다.

다음 장에서 배울 Change Set을 먼저 만들어서 어떤 변경이 일어날지 미리 확인합니다. 마지막으로 스택 삭제입니다.

delete-stack 명령어를 실행하면 스택에 포함된 모든 리소스가 삭제됩니다. 간단하지만 그만큼 위험합니다.

운영 환경에서는 Termination Protection을 활성화해두는 것이 필수입니다. 김개발 씨가 실습을 마치고 뿌듯해했습니다.

"코드 한 줄 바꾸고 명령어 한 번으로 인프라가 업데이트되다니, 정말 편하네요!"

실전 팁

💡 - 스택 생성 중 에러가 발생하면 describe-stack-events로 상세 원인을 확인하세요

• 운영 환경 스택은 반드시 Termination Protection을 활성화하세요

---

6. Change Set으로 변경 사항 미리보기

김개발 씨가 운영 환경 스택을 업데이트하려는 순간, 박시니어 씨가 말렸습니다. "잠깐!

운영 환경에서 바로 update-stack을 실행하면 안 돼. 어떤 변경이 일어날지 먼저 확인해야지." 그리고는 Change Set에 대해 설명해주었습니다.

Change Set은 스택 업데이트 전에 어떤 변경이 발생할지 미리 보여주는 기능입니다. 마치 Git의 diff처럼 추가, 수정, 삭제될 리소스를 확인할 수 있습니다.

특히 리소스가 교체(Replace)되는 위험한 변경을 사전에 파악하여 사고를 예방합니다.

다음 코드를 살펴봅시다.

# 1. Change Set 생성
aws cloudformation create-change-set \
  --stack-name my-prod-stack \
  --change-set-name update-instance-type \
  --template-body file://template.yaml \
  --parameters ParameterKey=InstanceType,ParameterValue=t2.medium

# 2. Change Set 상세 내용 확인
aws cloudformation describe-change-set \
  --stack-name my-prod-stack \
  --change-set-name update-instance-type

# 결과 예시:
# "Changes": [
#   {
#     "Type": "Resource",
#     "ResourceChange": {
#       "Action": "Modify",
#       "Replacement": "False",  # 교체 없이 수정만
#       "LogicalResourceId": "WebServer"
#     }
#   }
# ]

# 3. 검토 후 Change Set 실행
aws cloudformation execute-change-set \
  --stack-name my-prod-stack \
  --change-set-name update-instance-type

# 4. 변경을 원하지 않으면 삭제
aws cloudformation delete-change-set \
  --stack-name my-prod-stack \
  --change-set-name update-instance-type

박시니어 씨가 심각한 표정으로 말했습니다. "예전에 한 번 사고가 났었어.

운영 환경에서 템플릿 조금 수정하고 바로 update-stack 했는데, RDS 인스턴스가 교체되면서 데이터가 다 날아갔거든." 김개발 씨가 놀랐습니다. "네?

업데이트만 했는데 데이터가 날아가요?" 박시니어 씨가 고개를 끄덕였습니다. "어떤 속성을 바꾸면 리소스를 삭제하고 새로 만들어야 하거든.

이걸 Replacement라고 해. 문제는 update-stack을 실행하기 전까지는 이게 Replacement인지 아닌지 모른다는 거야." 바로 이 문제를 해결하기 위해 Change Set이 있습니다.

Change Set은 Git에서 커밋 전에 git diff로 변경 사항을 확인하는 것과 같습니다. 실제로 변경하기 전에 무엇이 바뀔지 미리 볼 수 있습니다.

Change Set을 만들면 각 리소스에 대해 세 가지 정보를 알려줍니다. Action은 Add(추가), Modify(수정), Remove(삭제) 중 하나입니다.

Replacement는 True 또는 False로, True면 리소스가 삭제 후 재생성됩니다. Replacement: True가 보이면 빨간불입니다.

해당 리소스가 완전히 교체된다는 뜻입니다. EC2 인스턴스라면 기존 인스턴스가 삭제되고 새 인스턴스가 생성됩니다.

EBS 볼륨이 연결되어 있었다면 그 데이터도 사라집니다. 김개발 씨가 물었습니다.

"그럼 Change Set을 확인하고 위험해 보이면 어떻게 해요?" Change Set은 검토 후 두 가지 선택이 가능합니다. 문제가 없으면 execute-change-set으로 실제 변경을 적용합니다.

위험해 보이면 delete-change-set으로 Change Set을 삭제하고 템플릿을 수정합니다. 박시니어 씨가 실무 사례를 들었습니다.

"우리 팀은 운영 환경 배포 프로세스에 Change Set 검토를 필수로 넣어뒀어. Change Set을 만들면 자동으로 Slack에 알림이 가고, 시니어 개발자가 Replacement 여부를 확인한 후에야 실행할 수 있도록 했지." AWS 콘솔에서도 Change Set을 사용할 수 있습니다.

콘솔의 장점은 변경 내용이 시각적으로 표시된다는 것입니다. 어떤 속성이 바뀌는지 색깔로 구분되어 한눈에 파악하기 쉽습니다.

김개발 씨가 정리했습니다. "결국 Change Set은 안전장치네요.

운영 환경에서는 무조건 Change Set으로 먼저 확인하고 실행해야겠어요." 박시니어 씨가 웃으며 말했습니다. "그래, 그게 핵심이야.

급하다고 Change Set 건너뛰면 안 돼. 5분 검토해서 큰 사고를 막는 거야." CloudFormation을 안전하게 사용하려면 Change Set 활용이 필수입니다.

특히 운영 환경에서는 절대 update-stack을 바로 실행하지 말고, 항상 Change Set으로 변경 사항을 미리 확인하세요.

실전 팁

💡 - 운영 환경에서는 Change Set 검토를 배포 프로세스의 필수 단계로 지정하세요

• Replacement: True인 리소스가 있으면 데이터 백업 여부를 반드시 확인하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!