[Terraform 튜토리얼 1-3] 내부는 감추고, 필요한 것만 보여줘 – 캡슐화란?

[Terraform 튜토리얼 1-3] 내부는 감추고, 필요한 것만 보여줘 – 캡슐화란?

Encapsulation, 캡슐화라고 하면 뭔가 개발자스럽고 어려워 보이죠?
객체지향 프로그래밍 할 때나 듣던 단어 같고요.

그런데 이 개념은, Terraform 같은 Infrastructure as Code(IaC)에서도 아주 중요합니다.
이번 글에서는 "캡슐화가 무엇이고", "왜 필요한지", 그리고 "Terraform에서는 어떻게 쓰이는지"를 쉽게 풀어보겠습니다.


✅ 캡슐화, 한 마디로 뭐야?

“필요한 것만 보이게 하고, 나머지는 숨기는 것”
→ 이게 캡슐화의 핵심이에요.

예를 들어, 커피 머신에는 버튼이 몇 개 있고, 우리가 할 일은 그냥 버튼 누르는 거죠.
기계 내부에서 물을 데우고 커피를 내리는 복잡한 과정은 몰라도 됩니다.

Terraform에서도 마찬가지예요.
내가 만든 어떤 구성(=모듈)을 다른 사람이 쓸 수 있도록 하되,
“무슨 값을 넣어야 하고, 어떤 값이 나오는지만” 알면 되도록 만드는 거죠.


🧱 Terraform에서는 어떻게 캡슐화할까?

Terraform에서 모듈(module)이 바로 캡슐화 단위입니다.

  • 모듈은 하나의 폴더에 .tf 파일들을 모아 둔 덩어리
  • 내부에 리소스를 어떻게 구성했는지는 숨기고,
  • 외부에는 input (입력 값)과 output (출력 값)만 공개
module "vpc" {
  source     = "./modules/vpc"
  cidr_block = "10.0.0.0/16"
}

output "vpc_id" {
  value = module.vpc.vpc_id
}

위처럼 cidr_block만 넘기면, 내부에서 알아서 VPC를 만들고 vpc_id만 돌려줍니다.
"어떻게 만들었는지"는 몰라도 되는 거죠.


💡 참고로 루트 모듈도 모듈이다

main.tf, variables.tf, outputs.tf 같은 루트 디렉토리에서 작성하는 구성도 사실상 하나의 모듈이에요.

  • 입력: variable로 받은 값
  • 출력: output으로 정의한 값
  • 내부: resource, data, locals

즉, Terraform을 쓰는 시점부터 이미 우리는 캡슐화를 하고 있는 셈이죠.


🔁 캡슐화가 중요한 이유?

  • 모듈을 재사용하기 쉽고
  • 협업할 때 역할 분담이 명확해지고
  • 내부 구현을 바꿔도 외부엔 영향이 없음

즉, "모듈이 어떤 역할을 하고, 어떤 값이 오고 가는지만 신경 쓰면 된다"는 게 핵심입니다.


📌 정리하자면

Terraform에서의 캡슐화는 리소스를 묶어서 하나의 모듈로 만들고,
입력과 출력만 외부에 공개해서 쉽게 쓰고 재사용할 수 있게 만드는 구조입니다.

잘 만든 모듈 하나면, 매번 수동 설정하거나 코드 복붙하는 번거로움을 줄일 수 있어요.


🔜 다음 글 예고

다음 글에서는 "모듈을 잘 만들었는지 어떻게 판단할까?"에 대한 이야기,
응집도(Cohesion) 개념을 다뤄보겠습니다.

[Terraform 튜토리얼 1-4] 모듈이 정리가 안 될 땐, 응집도(Cohesion)를 의심하라
인프라를 코드로 관리할 때, 좋은 모듈을 만드는 핵심 개념 중 하나가 바로 응집도(Cohesion)입니다. 이 단어가 좀 낯설게 느껴질 수 있지만, 사실 우리는 매일 응집도가 높은 시스템 속에서 살고 있어요. ✅ 응집도란? 하나의 모듈이 하나의 책임 또는 기능에만 집중하는 정도 응집도가 높은 모듈은 말 그대로 한 가지 일에만 집중합니다. 그래서

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