[Terraform 튜토리얼 1-6] 중복 없애다 망한 썰 – DRY 원칙, 정말 항상 맞을까?

[Terraform 튜토리얼 1-6] 중복 없애다 망한 썰 – DRY 원칙, 정말 항상 맞을까?

개발자라면 한 번쯤 들어봤을 말,

"Don't Repeat Yourself", 줄여서 DRY 원칙.

이건 소프트웨어 개발에서 아주 중요한 원칙이에요.
중복을 줄이면 버그도 줄고, 유지 보수도 쉬워지고, 코드도 깔끔해지죠.

그런데…
Terraform 같은 IaC 세계에서도 DRY가 무조건 좋을까요?


🤔 DRY가 뭔데?

DRY 원칙의 핵심은 딱 하나:

"같은 걸 반복해서 쓰지 마."
  • 상수 값, 로직, 설정 등을 중앙에서 관리하자
  • 복붙은 금물! 하나만 바꿔도 전체가 반영돼야 한다

전통적인 애플리케이션 개발에선 이게 매우 효과적이에요.


💡 근데 Terraform에선 좀 다릅니다

Terraform에서도 처음엔 DRY를 적용하고 싶을 수 있어요.
저자도 처음엔 그랬고, 대부분의 개발자들도 그렇게 시작합니다.

하지만 이게 오히려 문제를 키우는 경우가 많습니다.

🧱 IaC에서 DRY를 적용하면 생기는 문제들

1. 의도 파악이 어려움

너무 많은 추상화와 재사용 모듈로 구성하면,
코드를 처음 보는 사람이 무슨 인프라가 만들어지는지 이해하기 어려워져요.

"이 EC2 인스턴스가 어떻게 만들어지는 거지?"
"이 변수는 어디서 왔고, 이 output은 어디로 가는 거야?"

2. 테스트가 어렵다

일반 코드에선 메모리에서 돌리는 단위 테스트가 가능하지만,
Terraform은 실제 클라우드와 상호작용해야 의미 있는 결과가 나옵니다.

즉, 코드를 실행해 봐야 알 수 있는데,
너무 DRY 하게 짜면 테스트가 힘들고 디버깅은 지옥이 돼요.

3. 디버깅 난이도 상승

Terraform은 클라우드 리소스 간의 의존성이 많아요.
문제가 생기면 “작은 단위부터 하나씩 쌓아보는 방식”으로 디버깅해야 하는데,
DRY 한 구조는 이런 접근을 복잡하게 만듭니다.


🪣 그래서 등장한 WET 원칙 (!?)

Terraform 커뮤니티에선 종종 WET (Write Everything Twice)이라는 우스갯소리도 나옵니다.
너무 추상화하지 말고, 명확하게, 직관적으로 코드 쓰자는 뜻이에요.

물론 진짜로 중복을 막 쓰라는 건 아니고, 핵심은 이겁니다:

“재사용은 하되, 명확함을 우선하라”
“기술적 우아함보다 실용성과 가독성”

🎯 실무에서의 균형

원칙 Terraform 적용 시
DRY 중복된 리소스 정의 줄이기에는 유용 ex. locals, variables, for_each
너무 DRY ❌ 과한 추상화, 여러 모듈 끼리 의존성 꼬임
적당한 WET ✅ 코드가 명확하고 한눈에 파악됨

📌 정리하자면

DRY는 훌륭한 원칙입니다.
하지만 Terraform처럼 외부 시스템에 강하게 의존하는 코드에선
DRY보다 예측 가능성, 가독성, 명확한 구조가 더 중요할 수 있습니다.

Terraform에선 때때로 “조금의 중복”이
오히려 더 좋은 설계일 수 있어요.


🔚 시리즈 마무리하며

이번 시리즈를 통해 Terraform과 IaC의 기본 개념들 —
멱등성, 불변성, 캡슐화, 응집도, 선언형 철학, DRY 원칙까지
하나씩 짚어봤습니다.

각 개념을 이해하고 실무에 적용하는 순간,
Terraform은 그저 코드 작성 도구가 아닌
여러분의 강력한 인프라 설계 플랫폼이 되리라 확신합니다!

Read more

배타적 서브타입(Exlusive Subtype) 테이블 설계와 백엔드 구현

배타적 서브타입(Exlusive Subtype) 테이블 설계와 백엔드 구현

배타적 서브타입이란? 데이터베이스 테이블 설계에서 슈퍼타입(Super Type)과 서브타입(Sub Type)은 공통 속성을 기준으로 엔티티(테이블)를 상위/하위로 나누는 데이터 모델링 기법입니다. * Super Type (상위 엔티티) * 여러 엔티티가 공통으로 가지는 속성을 모아 놓은 엔티티 * 식별자(PK, ID)를 포함한 공통 정보를 가지고 있음 * Sub Type (하위 엔티티)

By Plato Jung
A2A 메모리 레이어: AI 에이전트를 위한 공유 두뇌 구축하기

A2A 메모리 레이어: AI 에이전트를 위한 공유 두뇌 구축하기

모든 것의 시작이 된 문제 우리를 계속 괴롭히던 것이 있었습니다: 왜 AI 에이전트는 대화가 끝나는 순간 모든 것을 잊어버릴까요? 한번 생각해보세요. 챗봇에게 전화보다 이메일을 선호한다고 말합니다. 다음 세션에서는요? 마치 처음 만난 것처럼 행동합니다. 한 상담원에게 주문 문제를 설명하고, 다른 상담원에게 연결되면, 갑자기 처음부터 다시 시작해야 합니다. 우리 모두 겪어본 일입니다.

By Sardor Madaminov
[시리즈 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