[Terraform 튜토리얼 1-5] 선언형 vs 명령형: Terraform은 왜 선언형인가?

[Terraform 튜토리얼 1-5] 선언형 vs 명령형: Terraform은 왜 선언형인가?

Terraform을 쓰다 보면 종종 듣게 되는 말이 하나 있어요:

Terraform은 "선언형(Declarative)" 도구다.

그런데 이게 도대체 무슨 뜻일까요?
"명령형(Imperative)"이랑은 뭐가 다르고, 왜 Terraform은 선언형일까요?


🧠 선언형과 명령형, 개념부터 정리

구분 선언형 (Declarative) 명령형 (Imperative)
핵심 개념 무엇이 되어야 하는지만 선언 어떻게 할지를 하나하나 명령
예시 “난 스테이크 먹을래” “고기 꺼내서, 굽고, 소금 뿌리고, 접시에 담아”
Terraform 예시 resource "aws_instance" {...} aws ec2 run-instances --image-id ...

🍽️ 식당 비유로 이해해 봅시다

  • 선언형 방식은 마치 레스토랑에 가서 메뉴를 고르는 것과 같아요.
    • “스테이크 주세요!”
    • 요리, 플레이팅, 순서 고민은 셰프가 알아서 합니다.
    • 결과물(스테이크)이 어떻게든 나오긴 나와요.
  • 반대로, 명령형 방식직접 요리하는 것과 같아요.
    • 냉장고에서 재료 꺼내고, 순서대로 조리하고, 불 조절도 하고, 접시에 담기까지 전부 직접 해야 해요.
    • 순서 하나라도 틀리면? 생고기 플레이팅도 가능하죠.

🧱 인프라에선 어떻게 다를까?

  • 명령형 도구
    • 예: Ansible, Bash Script
    • 순서를 정해줘야 해요 (서브넷 먼저, 그다음 EC2, 그리고 나서 보안 그룹 설정 등)
    • 실행할 때마다 똑같은 결과가 나올 거란 보장이 없음 (예: 중복 생성 가능)
  • 선언형 도구 (Terraform)
    • 어떤 인프라 리소스가 “있어야 하는지”만 기술
    • Terraform이 계획(plan) 세우고, 필요한 작업만 적용(apply)
    • 이미 만들어졌다면 그대로 둠 = 멱등성(idempotence)도 보장

🍝 선언형의 장점

  • 코드가 깔끔함: 복잡한 순서, 조건문 필요 없음
  • 결과 예측 가능: 상태(state) 기반으로 차이만 반영
  • 협업에 강함: 누구나 코드만 봐도 최종 목표를 이해할 수 있음
  • 롤백/드리프트 관리 쉬움: 코드가 곧 진실(source of truth)

🧭 그래서 Terraform은 선언형이다

Terraform에서 우리는 이렇게 말해요:

resource "aws_instance" "web" {
  ami           = "ami-123456"
  instance_type = "t2.micro"
}

이게 무슨 뜻이냐면:

“나는 이 환경에 t2.micro EC2가 하나 존재하길 원해.”
그리고 Terraform은 알아서 “없는걸 만들고”, “이미 있으면 건드리지 않아요.”

📌 정리하자면

명령형은 “내가 시킨 대로만 하는 요리사”
선언형은 “내가 주문한 걸 알아서 만들어주는 레스토랑”

Terraform은 후자예요.
원하는 인프라의 상태만 정의하면,
Terraform이 그 차이를 계산하고 필요한 작업만 수행해 줍니다.
이게 바로 Terraform이 선언형 도구라는 뜻이에요.


🔜 다음 글 예고

다음 튜토리얼에서는 개발자라면 다들 알고 있어야 할 소프트웨어 원칙,
바로 DRY (Don't Repeat Yourself) 원칙이 Terraform에선 어떻게 적용되는지를 다뤄볼게요.

[Terraform 튜토리얼 1-6] 중복 없애다 망한 썰 – DRY 원칙, 정말 항상 맞을까?
개발자라면 한 번쯤 들어봤을 말, “Don’t Repeat Yourself”, 줄여서 DRY 원칙. 이건 소프트웨어 개발에서 아주 중요한 원칙이에요. 중복을 줄이면 버그도 줄고, 유지 보수도 쉬워지고, 코드도 깔끔해지죠. 그런데… Terraform 같은 IaC 세계에서도 DRY가 무조건 좋을까요? 🤔 DRY가 뭔데? DRY 원칙의 핵심은 딱 하나: ”같은 걸 반복해서 쓰지 마.” * 상수 값, 로직, 설정

Read more

[시리즈 2편] 실무로 배우는 메시지 큐 - RabbitMQ

[시리즈 2편] 실무로 배우는 메시지 큐 - RabbitMQ

들어가며 [시리즈1]에서는 프로세스 내부 메시지 큐를 다뤘습니다. 이번엔 네트워크 메시지 큐인 RabbitMQ를 다룹니다. RabbitMQ 공식 문서나 기술 블로그는 많지만, 실무에서 어떻게 사용하는지에 대한 글은 의외로 적습니다. "Producer가 뭐고 Consumer가 뭔지는 알겠는데, 그래서 실제로는 어떻게 쓰는데?" 이번 글에서는 우리 MES 시스템에서 RabbitMQ를 어떻게 활용하고 있는지 실제 코드와 함께 공유합니다. 우리

By Jeonggil
[시리즈 1편] 실무로 배우는 메시지 큐 - Windows Message Loop

[시리즈 1편] 실무로 배우는 메시지 큐 - Windows Message Loop

들어가며 이 글은 "실무로 배우는 메시지 큐" 시리즈의 첫 번째 글입니다. 실무에서 발견한 문제를 해결하는 과정에서, IME 입력 문제와 해결 과정을 공유합니다. 메시지 큐는 RabbitMQ, Kafka 같은 네트워크 레벨만 있는 게 아닙니다. 우리가 매일 쓰는 Windows 애플리케이션도 메시지 큐 기반으로 동작합니다. * 시리즈1 (이 글): 프로세스 내부의 메시지 큐 - Windows

By Jeonggil
[시리즈 2편] 그림으로 풀어낸 SaaS 알림 시스템

[시리즈 2편] 그림으로 풀어낸 SaaS 알림 시스템

이 글은 1편 - 그림으로 풀어낸 SaaS 알림 시스템의 후속편입니다. 들어가며 1편에서는 설비 연속 OFF 알림 기능의 핵심 로직과 어떤식으로 해결했는지 그림으로 알아봤습니다. 이번 글에서는 실무에서 마주한 진짜 고민들을 공유합니다: * 왜 3개의 새로운 테이블이 필요했나? * 어떻게 확장 가능한 구조를 만들었나? * SMS 14원짜리 알림이 왜 무서운가? * 운영 레벨로 나가기까지 무엇을 준비했나?

By Jeonggil
[시리즈 1편] 그림으로 풀어낸 SaaS 알림 시스템

[시리즈 1편] 그림으로 풀어낸 SaaS 알림 시스템

들어가며 제조업 IoT 플랫폼에서 N대 이상의 설비를 실시간으로 모니터링하고, 설비가 연속으로 꺼졌을 때 담당자에게 즉시 알림을 보내는 기능을 개발하게 되었습니다. 데이터는 실시간으로 쌓이지만, 설비이상을 체크하는 스케줄러 주기는 1분으로 설정하였습니다. 시스템 아키텍처 기존 인프라와 Push 기능은 이미 구축되어 있었습니다. 저는 중간에 들어가는 Alert Scheduler만 구현하면 되는 상황이었습니다. ┌──────────────────────────────────────────────────────────┐ │ 설비 IoT 센서 (실시간)

By Jeonggil