IaC?

출처: https://learn.microsoft.com/ko-kr/devops/deliver/what-is-infrastructure-as-code

IaC(Infrastructure as Code)는 인프라를 코드로 정의하고 관리하는 방식이다.
서버, 네트워크, 스토리지 같은 인프라 자원을 사람이 직접 UI나 콘솔에서 설정하는 것이 아니라, 컴퓨터가 읽을 수 있는 코드 파일로 정의하고 실행한다는 개념이다.

핵심 개념은 다음과 같다.

  • 인프라는 코드로 표현된다.
  • 코드는 인프라의 상태를 설명한다.
  • 수동 작업이 아닌 자동 실행으로 인프라를 관리한다.
  • 동일한 환경을 반복적으로 재현할 수 있다.

즉, IaC는 인프라 운영을 소프트웨어 개발 방식으로 끌어오는 개념이다.

Terraform의 특징

출처: https://dev.to/aws-builders/terraform-on-aws-an-introductory-guide-5dfb

인프라는 “한 번 만들고 끝”이 아니라 계속 바뀌는 대상이다. 서버 추가, 네트워크 변경, 권한 정책 수정, 모니터링 도구 설정 같은 작업이 반복되는데, 이걸 사람 손으로 매번 하면 다음 문제가 생긴다.

  • 작업자마다 방식이 달라 품질이 흔들린다.
  • 변경 이력이 남지 않거나, 남아도 추적이 어렵다.
  • 롤백이 어렵고, 장애 시 원인 파악이 늦어진다.
  • 환경이 커질수록 운영 비용이 폭증한다.

테라폼은 이런 반복 작업을 “코드 기반 워크플로”로 표준화해서, 같은 결과를 더 빠르고 안전하게 만들자는 도구이다.

Terraform의 3가지 철학

워크플로(workflow)

테라폼은 특정 클라우드나 기술에 종속되지 않고 인프라를 만들고, 변경하고, 검증하는 흐름 자체를 표준화한다.

대표적인 워크플로는 다음과 같다.

  • terraform plan : 무엇이 바뀌는지 미리 확인한다.
  • terraform apply : 계획된 변경을 실제로 적용한다.

이 구조의 핵심은 다음이다.

  • 환경이 바뀌어도 작업 방식은 동일하다.
  • AWS → Azure → 온프레미스로 바뀌어도 흐름은 유지된다.
  • 인프라 변경에 대한 예측 가능성이 높다.

즉, 기술이 아니라 “일하는 방식”을 표준화한 것이다.

코드형 인프라(IaC)

“Infrastructure as Code”는 말 그대로 인프라 구성을 코드로 표현하는 것이다. 여기서 중요한 포인트는 “코드가 문서이면서 실행 가능”하다는 점이다.

  • 코드로 남기면 버전 관리가 된다.
  • 리뷰와 승인 프로세스를 태울 수 있다.
  • 누가 언제 무엇을 바꿨는지 추적이 된다.
  • 동일 구성을 재현할 수 있어 재사용이 된다.

즉 IaC는 “사람 기억”이 아니라 “저장소의 코드”를 기준으로 인프라를 운영하자는 철학이다.

실용주의(pragmatism)

테라폼은 이론적으로 완벽한 설계보다 현실에서 쓰기 좋은 구조를 선택한다.

  • 모든 것을 추상화하려 하지 않는다.
  • 클라우드별 특성도 인정한다.
  • 필요하면 타협한다.

이 철학 덕분에 테라폼은

  • 멀티 클라우드
  • 하이브리드 인프라
  • 점진적 도입과 같은 현실적인 환경에서도 잘 동작한다.

Terraform과 Provider 구조

출처: https://shopify.engineering/manage-infrastructure-with-terraform

테라폼은 인프라를 직접 구성하지 않고,  terraform apply와 같은 명령으로 구현된 동작으로 만들어진 코드를 실행하고 배포를 하는 방식으로 동작한다. 이미지에 나온 그림의 핵심은 다음과 같다.

  • 테라폼 코어는 plan/apply, 상태(state) 관리, 리소스 그래프 구성 같은 “엔진” 역할이다.
  • 프로바이더(provider) 는 각 서비스(AWS, GCP, Kubernetes, GitHub 등)의 API와 테라폼 코어를 연결하는 “드라이버/플러그인” 역할이다.
  • 대상의 API 는 실제 인프라가 제공하는 HTTP(S) API이다.

동작 흐름을 한 줄로 정리하면 다음과 같다.

  1. 사용자가 HCL 코드 작성한다.
  2. 테라폼 코어가 계획(plan)을 만든다.
  3. 적용(apply) 시 코어가 프로바이더를 RPC로 호출한다.
  4. 프로바이더가 실제 서비스 API를 HTTP(S)로 호출해서 리소스를 만든다/바꾼다/지운다.

여기서 중요한 것은, 테라폼 단독으로는 아무것도 못 하고, 프로바이더가 있어야 특정 인프라를 실제로 다룰 수 있다는 것이다.

Terraform 제공 유형

On-Premise (오픈소스 바이너리)

보통 사람들이 “terraform”이라 부르는 CLI 도구 형태이다.

  • 내 PC나 서버에서 실행한다.
  • 상태(state)는 로컬 파일이 될 수도 있고 원격 저장소가 될 수도 있다.
  • 개인/소규모 팀에서 가장 흔히 시작하는 방식이다.

Hosted SaaS (Terraform Cloud)

클라우드 서비스(SaaS) 형태로 제공되는 운영 플랫폼이다.

  • 실행, 상태 관리, 협업 기능을 서비스가 대신 제공한다.
  • 팀 단위로 워크스페이스/권한/변수/실행 이력을 관리하기 편하다.

Private Install (Enterprise)

기업 내부망에 설치해서 사용하는 형태이다.

  • 인터넷이 막힌 환경, 내부 규정이 강한 환경에서 쓴다.
  • 거버넌스/정책/감사(Audit) 같은 엔터프라이즈 기능이 강화된다.

테라폼 코어(기본 기능)는 공통이고, Cloud/Enterprise는 협업·거버넌스·셀프서비스 같은 플랫폼 기능이 추가된다.

IaC 도구 비교

Terraform

  • 프로비저닝 중심 IaC이다.
  • 장점: 멀티 클라우드/하이브리드에 강하다. 리소스 라이프사이클을 코드로 관리한다.
  • 방식: 선언형에 가깝고, 원하는 상태를 정의하고 맞추는 쪽이다.

Ansible

  • 구성 관리(컨피그 관리) 도구이다.
    • 강점: 서버 내부 설정(패키지 설치, 설정 파일 배포, 서비스 재시작)을 단계적으로 자동화하기 좋다.
    • 특징: 보통 “이미 만들어진 서버”에 들어가서 상태를 맞춘다. 그래서 테라폼으로 인프라를 만들고, 앤서블로 OS/미들웨어 설정을 잡는 조합이 흔하다.

CloudFormation

  • AWS 전용 프로비저닝 템플릿이다.
    • 강점: AWS 내부에서의 완성도/통합성이 높다.
    • 한계: 멀티 클라우드에는 불리하다.

ARM Template

  • Azure 전용 프로비저닝 템플릿이다.
    • 강점: Azure 자원에 최적화되어 있다.
    • 한계: 멀티 클라우드에는 불리하다.

결국 위 내용들을 종합해서 판단해보면 다음과 같은 결론을 내릴 수 있다.

  • 멀티 클라우드/하이브리드를 한 코드 흐름으로 묶고 싶으면 테라폼을 사용하는 것이 효율적이다.
  • 서버 안의 설정 자동화는 앤서블을 사용하는 것이 좋다.
  • 특정 클라우드 환경 내에서만 구성한다면, 그 클라우드 전용 템플릿도 선택지가 될 수 있다.

Terraform 사용 목적과 과제

워크플로

사람이 GUI/CLI로 운영할 때는 다음과 같은 문제가 발생할 확률이 높다.

  • 콘솔에서 클릭하거나, 서버에서 명령어로 설정을 바꾸는 방식은 작업자가 누구냐에 따라 결과가 달라지기 쉽다.
  • 같은 목표(예: VPC 하나 만들기)라도 어떤 사람은 보안그룹을 타이트하게 구성하고, 어떤 사람은 러프하게 구성할 수 있고, 태그도 제각각이고, 네이밍도 제각각이 될 수 있다.

테라폼이 주는 워크플로는 위와 같은 획일화 되지 않은 절차를 고정하는 것이 목적이다.

따라서 테라폼은 인프라 구성/변경을 아래 흐름으로 고정한다.

  1. 코드로 정의한다: 원하는 상태(desired state)를 먼저 선언한다.
  2. 계획을 먼저 본다(plan): 실제로 무엇이 생성/수정/삭제되는지 미리 확인한다.
  3. 승인 후 적용한다(apply): 변경이 일어나면 그 결과가 상태(state)에 기록된다.

이렇게 고정된 워크플로를 통해 어떤 작업자든 같은 절차로 작업을 하게되고, 작업 후 변경된 내용을 사전에 검토 가능한 형태로 만들 수 있다.

자산화

프로비저닝 노하우를 코드로 자산화 할 수 있다.

  • 테라폼 코드는 단순 스크립트가 아니라, 조직이 쌓아온 인프라 설계·보안·운영 기준을 확립할 수 있는 기준이 된다.
  • 사람에게 물어봐야 하는 운영 지식(예: 서브넷 분리 규칙, 태그 규칙, 로깅/모니터링 기본 세팅)을 코드로 고정하면, 그 자체로 자산이 될 수 있다.

Git과 CI/CD와 통합할 수 있다. 

  • 코드이므로 버전관리(Git) 가 가능하다. 언제 누가 무엇을 바꿨는지 추적 가능하다.
  • CI에서 fmt/validate/plan을 돌려서 코드 품질과 변경 내용을 자동 검증할 수 있다.
  • CD 혹은 파이프라인으로 승인된 변경만 apply 되게 만들 수 있다.

정리하면, 테라폼은 인프라 운영을 소프트웨어 개발 방식으로 끌어와서 검토·재현·롤백·감사가 쉬워지게 하는 도구라고 보면 된다.

표준화

표준화란 조직 내 공통 규격을 만드는 일이다. 문서 내용에서 말하는 모듈화된 상태는 보통 다음 형태를 말한다.

  • 네트워크 모듈: VPC/Subnet/Route/NAT 규칙을 회사 표준대로 만든 모듈이다.
  • 보안 모듈: Security Group 규칙, 로깅, 암호화 기본값을 강제하는 모듈이다.
  • 공통 태그/네이밍: cost center, owner, env, service 같은 태그를 빠짐없이 붙이게 만든다.

이렇게 표준 규격을 만들어두면, 숙련자가 아니어도 해당 규격만 준수하면 일정 수준 이상의 인프라를 구성할 수 있게 된다.

또한 내부 정책뿐만 아니라 외부 협업에 대한 표준화된 규격도 수립할 수 있다.

  • 내부 정책: 예를 들어 “모든 리소스는 태그 필수”, “퍼블릭으로 열리는 포트는 제한”, “암호화 기본” 같은 규칙을 코드로 강제할 수 있다.
  • 외부 협업: 벤더/협력사가 작업해도 동일한 규칙과 코드베이스로 맞추기 쉬워진다.결국 사람이 바뀌어도 운영 품질이 유지되는 방향으로 간다.

프로비저닝 자동화

테라폼은 다른 자동화 도구와 통합하기 쉽다. 특히 Git, CI/CD, Jira와 같은 도구와 함께 변경관리 프로세스에 통합시킬 수 있다.

예를 들어 다음과 같이 프로비저닝을 자동화 할 수 있다.

  • Jira 티켓 생성 → PR 생성 → CI에서 plan 출력 → 리뷰/승인 → 배포 파이프라인에서 apply
    이렇게 연결되면, 인프라 변경이 요청-검토-승인-반영-기록 흐름으로 관리된다.

plan이 중요한 이유이다.

  • 테라폼은 적용 전에 실행 계획을 보여줘서 변경 영향도를 미리 확인하게 해준다.
  • 운영에서 진짜 사고는 뭘 바꾸는지 모르고 바꾼 것에서 터진다.
  • plan은 그 위험을 줄이는 장치이다. 빠르게 바꾸되, 바뀌는 내용을 보고 바꾸게 만든다.

결국, 테라폼의 목적은 인프라를 코드로 만들어 워크플로(절차), 자산(노하우), 표준(규칙), 자동화(변경관리)를 얻는 것이고, 과제는 조직의 수동 문화와 도입 비용, 그리고 운영자가 plan 및 상태를 이해하는 역량을 갖추는 데 있다.

 

Reference

  • 김민수, ⌜테라폼으로 시작하는 IaC⌟, 한빛미디어, 2024, 429쪽

 

티스토리툴바