• Infrastructure as Code 의 약자

• 수동 프로세스 및 설정 대신 코드를 사용하여 인프라를 프로비저닝(자원과 인프라를 사전에 준비하고 설정하여 제공하는 프로세스)하고 지원하는 기능

인프라 구성을 코드로 관리함으로써 반복적인 구축 및 변경 작업을 자동화하고 동일한 구성을 재현할 수 있음

• 선언형

  선언형 ex)

  • ec2가 1대 있어야 한다
  • 인스턴스 타입은 t3.small이어야 한다
  • 이 sg가 연결되어 있어야한다

  → Terraform이나 aws cloudformation같은 iac도구가 현재 상태와 원하는 상태 비교하여 필요한 작업 알아서 수행

• 명령형

  명령형 ex)
  # 1. VPC 생성
  
  aws ec2 create-vpc \
  
    --cidr-block 10.0.0.0/16
  
  # 2. Subnet 생성
  
  aws ec2 create-subnet \
  
    --vpc-id vpc-123456 \
  
    --cidr-block 10.0.1.0/24

  • 원하는 구성을 수행하는데 필요한 특정 커맨드 정의

    • 이때 커맨드는 올바른 순서로 실행해야함

    • 원하는 상태 변경하는 경우 명령적툴은 자동적용X, 어떻게 적용할지 결정하도록 함

      ex)

      1. 만약 백엔드 앞단에 ALB를 추가하고 싶다면
      2. alb명령어만 넣으면 끝이 아님
      3. vpc 생성 명령도 다시 들어가기에 조건을 세세하게 지정해야함
         • vpc 있으면 → 생성 x
         • vpc 없으면 → 생성

  • 즉, 명령형은 인프라 전체 관리 목적보다는 인프라 상태를 정의하지 않고 즉시 작업을 수행하고 싶은 경우에 직관적임

• 쉬운 환경 복제
  • 동일한 IaC 사용하여 동일한 환경을 다른 위치의 다른 시스템에 배포 가능
• 구성 오류 감소
  • 설정에서 오류를 줄이고 오류 검사 간소화
  • 이전 버전의 IaC 구성파일로 환경 롤백 가능

• 현재 서비스는 VPC, EC2, RDS, SQS, IAM, Security Group 등 여러 AWS 리소스가 서로 연결되는 구조
• V2 이후 ALB, ECS, Auto Scaling 등이 추가되면서 인프라 복잡도가 증가할 예정
  • V1 구조만으로는 도입의 필요성이 낮음

• 콘솔을 통한 수동 설정만 사용할 경우
  • 인프라 설정 재현이 어려움
  • 팀원 간 설정 차이가 발생할 수 있음
  • 변경 이력을 추적하기 어려움
  • dev / prod 환경 생성 시 동일한 설정을 반복해야 함

⇒ 인프라 설정을 하나하나 들어가서 어떤 것을 선택했었는지 확인해야 함

• 어떤 작업을 했는지 따로 문서화 시켜야함
• 변경 과정을 관리하기가 상대적으로 어려움

⇒ v1 배포 이후부터 인프라 구성을 코드로 관리하는 IaC 도입

• 인프라 생성 자동화 목적보다는 인프라 구성을 코드로 보존하는 목적
• v1~v3의 변경사항을 git을 통해 추적
• 동일한 환경 재현의 편의성

=> v1 부터 선택하지 않는 이유

• 우리 서비스는 인프라 규모가 작음(콘솔 관리의 부담이 적음)
• 반복 구축의 필요성이 낮음(별도의 개발서버 미존재)
• IaC 세팅, 코드 작성 보다는 v1에서는 빠른 개발, 인프라 검증의 우선순위가 더 높다 판단

• 도구 선택에 앞서 우선 우리서비스에서 IaC 도입은 전체 인프라 관리를 위함이기에 명령형 방식이 아닌 선언형을 지원하는 IaC를 도입해야함

⇒ 비교군은 대표적인 선언형인 Terraform, AWS기반인 CloudFormation, CDK만 우선적으로 고려

비교 기준	Terraform	CloudFormation	CDK
정의 방식	HCL	YAML / JSON	프로그래밍 언어
AWS 외 플랫폼	Provider를 통해 지원	AWS 전용	기본적으로 AWS 중심
상태 관리	별도 State 필요	CloudFormation 관리	CloudFormation 관리
변경 사전 확인	terraform plan	Change Set	cdk diff
기존 Resource 편입	Import	Resource Import	CloudFormation 기반
Resource 표현	비교적 명시적	비교적 명시적	Construct 수준에 따라 달라짐
추상화/재사용	Module 등	Template 구조화 기능	Construct
현재 AWS 구조와의 관계	AWS Provider 사용	AWS Native	CloudFormation 기반
CSP 변경 시	도구/Workflow 유지 가능하나 Resource 재작성 필요	Template 재작성 필요	AWS 중심 구조 재검토 필요