왜 테라폼 인가?

데브옵스(DevOps)란?

‘데브옵스(DevOps)’는 패트릭 드보이스(Patrick Debois)가 2009년에 처음 소개한 용어로 이후 그는 이 분야의 전문가로 부상했습니다. 이 용어는 개발(development)’과 ‘운영(operations)’을 결합한 말로, 사람들이 데브옵스가 무엇을 의미하는지 이해할 수 있는 시작점을 제공합니다. 데브옵스는 프로세스, 기술 또는 표준이 아닙니다. 많은 추종자들은 데브옵스를 하나의 ‘문화’라고 언급합니다.

시장조사기관 가트너(Gartner)의 정의를 선호합니다.

“데브옵스는 시스템 위주의 접근 방식이라는 문맥에서 민첩하고 효율적인 관행을 도입함으로써, IT 서비스를 신속하게 제공하는 데 초점을 맞춘 IT 문화의 변화를 나타냅니다. 데브옵스는 사람(과 문화)을 강조하며, 운영 팀과 개발 팀 간의 협업을 개선하고자 합니다. 데브옵스 구현에는 기술, 특히 수명주기 관점에서 프로그래밍 가능한 동적 인프라를 활용할 수 있는 자동화 툴을 활용합니다.”

 

중요한 것은, 데브옵스의 의미가 확장되어 기능, 패치, 업데이트를 자주 제공할 수 있도록 빠른 피드백 루프를 사용하여 소프트웨어 개발 주기를 단축하는 데 사용되는 프로세스, 문화 및 사고 방식을 포괄하는 용어가 되었다는 사실입니다.

데브옵스의 기원

데브옵스의 기원에 대해서는 의견이 분분하지만, 처음부터 완전한 개념은 아니었다는 점은 확실합니다. 데브옵스라는 씨앗이 오래 전에 심어졌고, 여러 분야의 미래 지향적인 IT 전문가들이 지속적으로 이를 키워왔다고 말할 수 있습니다. 지금의 데브옵스를 있게 한 두 가지 주요 요인은 다음과 같습니다.

• 엔터프라이즈 시스템 관리(ESM).
  • 데브옵스의 초기 정의에 관여한 사람들은 대부분 시스템 관리자였습니다. 이 운영 전문가들은 설정 관리, 시스템 모니터링, 자동화된 프로비저닝, 툴체인 접근 방식 등 데브옵스에 ESM의 주요 모범 사례를 적용했습니다.
• 애자일 개발.
  • "데브옵스는 애자일(Agile)의 결과물로 해석될 수 있습니다. 애자일 소프트웨어 개발은 고객, 제품 관리, 개발자 및 QA의 긴밀한 협업을 통해 서로의 격차를 해소하고, 더 나은 제품을 빠르게 개발할 수 있도록 신속하게 반복하는 것으로 규정될 수 있습니다. 데브옵스는 서비스 제공과 앱 및 시스템의 상호 작용은 클라이언트에게 제공하는 가치 제안의 토대가 되는 부분이기 때문에, 제품 팀은 이러한 문제를 우선순위에 두어야 합니다. 이러한 관점에서 데브옵스는 애자일 원칙을 코드의 경계를 넘어 전체 제공 서비스로 확장하고 있습니다.”

코드형 인프라란(IaC)?

코드형 인프라란 무엇일까요?
코드형 인프라(IaC)는 수동 프로세스 및 설정 대신 코드를 사용하여 컴퓨팅 인프라를 프로비저닝하고 지원하는 기능입니다. 모든 애플리케이션 환경에는 운영 체제, 데이터베이스 연결, 스토리지 등의 많은 인프라 구성 요소가 필요합니다. 개발자는 애플리케이션 개발, 테스트 및 배포를 위해 인프라를 정기적으로 설정, 업데이트 및 유지 관리해야 합니다.

수동 인프라 관리는 시간이 많이 걸리고 오류가 발생하기 쉽습니다. 특히 애플리케이션을 대규모로 관리하는 경우 더욱 그렇습니다. 코드형 인프라를 사용하면 원하는 상태에 도달하기 위한 모든 단계를 포함하지 않고도 인프라의 원하는 상태를 정의할 수 있습니다. 인프라 관리를 자동화하여 개발자가 환경을 관리하는 대신 애플리케이션을 구축하고 개선하는 데 집중할 수 있습니다. 조직은 인프라를 코드로 사용하여 비용을 제어하고 위험을 줄이고 새로운 비즈니스 기회에 신속하게 대응합니다.

코드형 인프라의 장점

코드형 인프라의 이점은 무엇인가요?
자동화는 모든 컴퓨팅 환경에서 핵심 목표입니다. 코드형 인프라(IaC)는 인프라 자동화를 통해 환경을 생성하는 데 사용됩니다. IaC의 가장 일반적인 용도는 응용 프로그램을 구축, 테스트 및 배포하기 위한 소프트웨어 개발입니다.

기존에는 시스템 관리자가 스크립트와 수동 프로세스를 조합해서 사용하여 인프라 환경을 설정했습니다. 이 과정은 복잡하고 시간이 많이 걸렸습니다. 이제는 IaC를 사용하여 몇 분 내에 환경을 자동으로 설정하고 더 효율적으로 관리할 수 있습니다. 다음은 몇 가지 이점입니다.

• 쉽게 환경 복제
• 구성 오류 감소
• 모범 사례 환경 반복

코드형 인프라는 어떻게 작동하나요?

소프트웨어 코드가 애플리케이션과 그 작동 방식을 설명하는 것과 마찬가지로 코드형 인프라(IaC)는 시스템 아키텍처와 그 작동 방식을 설명합니다. 인프라 아키텍처에는 서버, 네트워킹, 운영 체제, 스토리지 등의 리소스가 포함됩니다. IaC는 구성 파일을 소스 코드 파일처럼 처리하여 가상화된 리소스를 제어합니다. 이를 사용하여 체계화되고 반복 가능한 방식으로 인프라를 관리할 수 있습니다. IaC 구성 관리 도구는 다른 언어 사양을 사용합니다. Python 또는 Java의 애플리케이션 코드와 유사한 IaC를 개발할 수 있습니다. 또한 내장 오류 검사 기능을 갖춘 통합 개발 환경(IDE)에서 IaC를 작성할 수 있습니다. 코드가 변경될 때마다 커밋을 통해 소스 제어하에 이를 유지할 수 있습니다. IaC 파일은 더 넓은 코드베이스의 일부로 포함됩니다.

• IaC에 대한 접근 방식
  • 선언적
    • 선언적 IaC를 사용하면 개발자가 원하는 시스템의 최종 상태를 구성하는 리소스와 설정을 설명할 수 있습니다. 그러면 IaC 솔루션이 인프라 코드에서 이 시스템을 생성합니다. 따라서 개발자가 애플리케이션을 실행하는 데 필요한 구성 요소와 설정을 알고 있으면 선언적 IaC를 쉽게 사용할 수 있습니다.
  • 명령형
    • 명령적 IaC를 사용하면 개발자가 리소스를 설정하고 원하는 시스템 및 실행 상태에 도달하는 모든 단계를 설명할 수 있습니다. 명령적 IaC를 작성하는 것은 선언적 IaC만큼 간단하지 않지만 복잡한 인프라 배포에서는 명령적 접근 방식이 필요합니다. 이벤트 순서가 중요한 경우 특히 그렇습니다.

테라폼 작동 방식

1. 초기화 단계 (Init)
   •  terraform init 명령어 실행 시 가장 먼저 일어나는 과정입니다
   •  필요한 프로바이더와 모듈을 다운로드하고 .terraform 디렉토리에 저장합니다
   •  상태 파일(state file) 백엔드를 초기화합니다
2. 구문 분석 (Parser)
   • . tf 파일의 HCL(HashiCorp Configuration Language) 코드를 파싱합니다.
   •  구문 오류를 체크하고 내부 데이터 구조로 변환합니다
3. 그래프 구성 (Graph Building)
   •  리소스 간의 의존성을 분석하여 방향성 비순환 그래프(DAG)를 생성합니다.
   •  어떤 리소스가 먼저 생성되어야 하는지 순서를 결정합니다
4. 계획 수립 (Plan)
   •  현재 상태(state)와 목표 상태(config)를 비교합니다.
   •  리소스의 생성(create), 수정(update), 삭제(delete) 작업을 결정합니다.
   •  실행 계획(execution plan)을 생성합니다
5. 적용 단계 (Apply)
   •  계획된 변경사항을 순서대로 실행합니다.
   •  각 리소스에 대해 프로바이더 API를 호출합니다.
   •  작업 결과를 상태 파일에 기록합니다
6. 상태 관리 (State Management)
   •  terraform.tfstate 파일에 현재 인프라 상태를 저장합니다.
   •  리소스의 속성값, 의존성 정보 등을 관리합니다. 원격 백엔드(S3, Consul 등)를 통해 팀 간 상태 공유가 가능합니다
7. 프로바이더 통신
   •  각 클라우드 프로바이더의 API와 통신합니다
   •  CRUD 작업을 수행하고 결과를 받아옵니다
   •  에러 처리와 재시도 로직을 포함합니다

---

테라폼과 다른 도구 비교

1. Terraform vs Terragrunt

특징	Terraform	Terragrunt
용도	기본 IaC 도구	Terraform wrapper
구성 방식	개별 설정 필요	DRY 원칙, 설정 상속
환경 관리	수동 관리	다중 환경 쉬운 관리
학습 곡선	상대적으로 낮음	추가 학습 필요
상태 관리	개별 관리	중앙화된 관리
코드 재사용	모듈 시스템	설정 상속 및 재사용

 

Terraform 예제

다중 환경을 위해서는 각 환경별로 설정을 반복해야 합니다:

# prod/main.tf
provider "aws" {
  region = "ap-northeast-2"
}

terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "ap-northeast-2"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

module "vpc" {
  source = "../modules/vpc"
  environment = "prod"
  cidr_block = "10.0.0.0/16"
}

# dev/main.tf - 설정 중복 발생
provider "aws" {
  region = "ap-northeast-2"
}

terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "dev/terraform.tfstate"
    region         = "ap-northeast-2"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

module "vpc" {
  source = "../modules/vpc"
  environment = "dev"
  cidr_block = "172.16.0.0/16"
}

Terragrunt 예제

공통 설정을 한 번만 정의하고 상속할 수 있습니다:

# terragrunt.hcl (root)
remote_state {
  backend = "s3"
  config = {
    bucket         = "my-terraform-state"
    key            = "${path_relative_to_include()}/terraform.tfstate"
    region         = "ap-northeast-2"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

# 공통 프로바이더 설정
generate "provider" {
  path      = "provider.tf"
  if_exists = "overwrite_terragrunt"
  contents  = <<EOF
    provider "aws" {
      region = "ap-northeast-2"
    }
  EOF
}

# prod/vpc/terragrunt.hcl
include {
  path = find_in_parent_folders()
}

terraform {
  source = "../../modules/vpc"
}

inputs = {
  environment = "prod"
  cidr_block = "10.0.0.0/16"
}

# dev/vpc/terragrunt.hcl
include {
  path = find_in_parent_folders()
}

terraform {
  source = "../../modules/vpc"
}

inputs = {
  environment = "dev"
  cidr_block = "172.16.0.0/16"
}

2. Terraform vs Pulumi

특징	Terraform	Pulumi
언어	HCL	일반 프로그래밍 언어(Python, TypeScript 등)
접근 방식	선언적	프로그래밍 방식
생태계	매우 성숙함	성장 중
사용자	인프라 중심	개발자 중심
테스팅	기본적인 테스트	풍부한 테스트 도구
타입 체크	제한적	언어 자체 지원

 

Terraform 예제

VPC와 서브넷 생성:

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"

  tags = {
    Name = "main"
    Environment = var.environment
  }
}

resource "aws_subnet" "public" {
  count             = length(var.availability_zones)
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet(aws_vpc.main.cidr_block, 8, count.index)
  availability_zone = var.availability_zones[count.index]

  tags = {
    Name = "public-${count.index + 1}"
    Environment = var.environment
  }
}

Pulumi 예제 (Python)

동일한 인프라를 Python으로 구현:

import pulumi
import pulumi_aws as aws

config = pulumi.Config()
environment = config.require('environment')
availability_zones = config.require_object('availability_zones')

# VPC 생성
vpc = aws.ec2.Vpc('main',
    cidr_block="10.0.0.0/16",
    tags={
        'Name': 'main',
        'Environment': environment
    }
)

# 동적으로 서브넷 생성
public_subnets = []
for i, az in enumerate(availability_zones):
    subnet = aws.ec2.Subnet(
        f'public-{i+1}',
        vpc_id=vpc.id,
        cidr_block=f"10.0.{i}.0/24",
        availability_zone=az,
        tags={
            'Name': f'public-{i+1}',
            'Environment': environment
        }
    )
    public_subnets.append(subnet)

# 프로그래밍적 로직 추가 가능
def calculate_subnet_count():
    return len(availability_zones)

total_subnets = calculate_subnet_count()
pulumi.export('total_subnets', total_subnets)

3. 도구 선택 가이드

- Terragrunt 사용 고려 사항

사용 권장	사용 비권장
여러 환경 관리 필요	소규모 프로젝트
대규모 인프라	단일 환경 관리
팀 단위 협업	간단한 인프라 구성
설정 중복 제거 필요	빠른 프로토타이핑

- Pulumi 사용 고려 사항

사용 권장	사용 비권장
개발자 중심 팀	IaC 입문 팀
복잡한 로직 필요	단순한 인프라 구성
기존 개발 도구 통합 중요	안정성 최우선 시
고급 테스트 필요	빠른 학습곡선 필요 시

- 실제 프로젝트 선택 기준

고려사항	추천 도구	선택 이유
단순한 인프라 관리	Terraform	간단한 구문, 빠른 학습 가능
대규모 환경 관리	Terraform + Terragrunt	설정 중복 제거, 일관성 유지
개발자 친화적 환경	Pulumi	친숙한 프로그래밍 언어 사용
엔터프라이즈 환경	Terraform 또는 Terraform + Terragrunt	안정성과 커뮤니티 지원
마이크로서비스 아키텍처	Pulumi 또는 Terraform + Terragrunt	복잡한 의존성 관리 용이

참고

• what-is-devops
• what-is-iac