스크립팅을 멈추고, 설계 시작: Terraform에 대한 OOP 접근
발행: (2025년 12월 11일 오전 01:52 GMT+9)
5 min read
원문: Dev.to
Source: Dev.to
TL;DR
문제: Terraform 코드베이스는 스프레일에 시달리기 쉽습니다—복사‑붙여넣기된 리소스, 강한 결합, 누수된 추상화 등으로 인해 확장이 고통스럽습니다.
해결책: Terraform 모듈을 클래스로, 모듈 인스턴스를 객체로 취급합니다.
핵심 매핑
| OOP 개념 | Terraform 대응 |
|---|---|
| 클래스 | Child module (e.g., ./modules/web_server/) |
| 객체 | module block (instantiation) |
| 인터페이스 | variables.tf (inputs) and outputs.tf (getters) |
| 프라이빗 상태 | locals and internal resources |
| 베스트 프랙티스 | 상속보다 컴포지션(다른 모듈을 이용해 모듈을 구성) 을 선호합니다. 의존성 주입을 사용해 리소스 ID(e.g., vpc_id) 를 전달하고, data 소스로 내부 조회하는 것을 피합니다. |
객체‑지향 접근법은 지저분하고 반복적인 HCL을 확장 가능한 인프라 구조로 바꿔줍니다. 캡슐화, 추상화, 컴포지션, 다형성과 같은 OOP 원칙을 Terraform 모듈에 매핑함으로써, 애플리케이션 코드만큼 유지보수 가능하고 테스트 가능한 인프라를 구축할 수 있습니다.
문제: 단일 Terraform 파일
프로젝트 초기에는 하나의 main.tf 파일이 편리합니다. 인프라가 성장하면서 이 “스크립팅” 사고방식은 취약성을 초래합니다: 환경마다 반복되는 하드코딩 값, 인스턴스와 인라인으로 정의된 보안 그룹, 재사용성 전무.
Terraform을 순수히 설정 스크립트로만 다루면 소프트웨어 엔지니어링 디자인 패턴이 제공하는 구조적 이점을 놓치게 됩니다. 우리는 스크립트를 작성하는 단계에서 객체를 설계하는 단계로 전환해야 합니다.
핵심 비유: 모듈을 클래스처럼
| OOP 개념 | Terraform 구현 |
|---|---|
| 클래스 정의 | ./modules/web_server/ – 무엇을 만들지는 정의하지 않고 어떻게 만들지를 정의하는 청사진 |
| 생성자 | variables.tf – 클래스를 인스턴스화하기 위해 필요한 입력을 정의 |
| 공개 메서드 / 속성 | outputs.tf – 호출자에게 명시적으로 노출되는 데이터를 정의 |
| 프라이빗 멤버 | locals, resource – 부모 스코프에 숨겨진 내부 로직 및 상태 |
| 객체 인스턴스 | module "web_prod" { … } – 청사진의 구체적인 구현 |
시각화: 모듈 인터페이스
classDiagram
class Module {
>
+variables.tf
+outputs.tf
-locals
-resources
}
class ChildModule {
+module "instance" {}
}
Module B[networking]
A --> C[compute]
B --> D[VPC & Subnets]
C --> E[EC2 Instances]코드 예시
# /modules/app_stack/main.tf
module "networking" {
source = "../networking"
cidr = var.cidr
}
module "compute" {
source = "../compute"
subnet_id = module.networking.private_subnet_id # Wiring components together
vpc_id = module.networking.vpc_id
}app_stack 모듈은 파사드 역할을 하여 네트워킹과 컴퓨팅 레이어 간의 상호작용을 조정하면서, 각 서브‑모듈이 단일 책임에 집중하도록 합니다.
4. 추상화 & 재사용: “인터페이스” 동작
(소스에서 내용이 축약되었습니다; 원칙은 variables.tf와 outputs.tf를 통한 명확한 입력/출력 계약을 정의함으로써 재사용 가능하고 교체 가능한 모듈을 만드는 패턴을 지속합니다.)