[Terraform 튜토리얼 1-4] 모듈이 정리가 안 될 땐, 응집도(Cohesion)를 의심하라

[Terraform 튜토리얼 1-4] 모듈이 정리가 안 될 땐, 응집도(Cohesion)를 의심하라

인프라를 코드로 관리할 때, 좋은 모듈을 만드는 핵심 개념 중 하나가 바로 응집도(Cohesion)입니다.
이 단어가 좀 낯설게 느껴질 수 있지만, 사실 우리는 매일 응집도가 높은 시스템 속에서 살고 있어요.


✅ 응집도란?

하나의 모듈이 하나의 책임 또는 기능에만 집중하는 정도

응집도가 높은 모듈은 말 그대로 한 가지 일에만 집중합니다.
그래서 이해하기 쉽고, 유지보수하기 편하고, 재사용하기도 좋아요.


🍳 주방에서 보는 응집도

예를 들어 아침 밥을 먹으려고 주방에 갔다고 해봅시다.
당신의 주방이 이렇게 구성되어 있다면 어떤가요?

  • 숟가락, 젓가락, 포크 → 한 서랍
  • 그릇, 접시 → 같은 찬장
  • 양념류 → 한 곳에 모여 있고
  • 우유 → 냉장고 안에

필요한 걸 어디서 꺼내야 할지 명확하고 빠르게 알 수 있죠.
이게 바로 응집도가 높은 구조입니다.


🧯 반대로, 응집도가 낮은 주방은?

  • 숟가락은 서랍에, 젓가락은 찬장 위, 포크는 다른 방에…
  • 그릇은 식탁 위, 접시는 거실…
  • 냉장고는 창고에 있고, 양념은 세탁기 옆…

이런 주방에서 요리하려면 불필요한 움직임과 시간 낭비가 엄청나겠죠?


🧱 Terraform에서 응집도가 중요한 이유

Terraform에서도 마찬가지입니다.

예를 들어 다음과 같은 모듈을 만들었다고 해봅시다:

  • vpc 모듈 → VPC, Subnet, Route Table 등을 포함
  • rds 모듈 → RDS 인스턴스 + 보안그룹
  • s3 모듈 → 버킷 + 버전관리 설정

이렇게 각 모듈이 하나의 기능에 집중하고 있다면,
사용자(혹은 팀원)는 그 모듈이 무슨 역할을 하는지 쉽게 이해할 수 있고,
문제가 생겨도 그 모듈만 보면 되니까 디버깅도 빠릅니다.


💡 모듈 분리 기준 예시

모듈 이름 응집된 기능
network VPC, Subnet, IGW 등 네트워크 설정
security Security Group, IAM Role 등 권한 관련 리소스
compute EC2, Lambda 등 컴퓨팅 리소스
storage S3, EFS 등 스토리지 관련 리소스

이런 식으로 모듈을 나누면 나중에 필요한 기능만 조립하듯 가져다 쓰기 좋아요.


📌 정리하자면

응집도가 높은 모듈은 말 그대로 “하나의 책임만 갖는 깔끔한 모듈”입니다.
이렇게 만들면 재사용, 유지보수, 협업 모든 측면에서 이점이 많습니다.

주방에서 숟가락 찾듯,
Terraform 모듈에서도 필요한 기능을 정확히 찾을 수 있게 만드는 것,
그게 바로 좋은 모듈의 시작입니다.


🔜 다음 글 예고

다음 포스트에서는 "선언형 vs. 명령형"이라는 또 하나의 핵심 개념을 다뤄보겠습니다.
Terraform이 왜 선언형 도구인지, 그게 왜 중요한지를 이해하면 IaC의 철학이 더 잘 보이기 시작할 거예요.

[Terraform 튜토리얼 1-5] 선언형 vs 명령형: Terraform은 왜 선언형인가?
Terraform을 쓰다 보면 종종 듣게 되는 말이 하나 있어요: Terraform은 ”선언형(Declarative)” 도구다. 그런데 이게 도대체 무슨 뜻일까요? ”명령형(Imperative)”이랑은 뭐가 다르고, 왜 Terraform은 선언형일까요? 🧠 선언형과 명령형, 개념부터 정리 구분 선언형 (Declarative) 명령형 (Imperative) 핵심 개념 무엇이 되어야 하는지만 선언 어떻게 할지를 하나하나 명령 예시 “난 스테이크 먹을래” “고기

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