해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.
Day 85 - Reuse, Don't Repeat - Creating an Infrastructure as Code Module Library
1. 왜 인프라 코드를 모듈화해야 하는가
IaC를 작성하다 보면 VM, 스토리지 계정 등 동일한 리소스를 반복적으로 정의하게 된다.
매번 코드를 복사해서 붙여넣는 방식은 다음과 같은 문제를 야기한다.
-
시간 낭비: 동일한 구성을 매번 새로 작성해야 한다.
-
일관성 결여: 시간이 지남에 따라 초기에 작성한 코드와 나중에 작성한 코드가 달라져 관리 포인트가 늘어난다.
1-1. 모듈화의 4가지 핵심 이점
-
재사용성: 한 번 잘 만들어진 모듈을 여러 프로젝트에서 Parameter만 바꿔가며 반복 사용할 수 있다.
-
복잡성 추상화:
-
클라우드 리소스의 복잡한 설정(
네트워크 피어링, 암호화 세팅 등)을 모듈 내부로 숨기고, 사용자에게는 이름과 위치 같은 단순한 인터페이스만 제공할 수 있다. -
이를 통해 클라우드 전문 지식이 없는 팀원도 손쉽게 인프라를 배포할 수 있다.
-
-
표준 준수: 회사의 보안 정책(예: HTTPS 필수, 퍼블릭 액세스 차단)을 모듈 내부에 하드코딩함으로써, 사용자가 모듈을 쓰기만 해도 자동으로 규정을 준수하도록 강제할 수 있다.
-
지식 공유: 인프라 아키텍트의 노하우와 모범 사례를 모듈에 담아 조직 전체에 배포할 수 있다.
2. 도구별 모듈 구현 방법
대부분의 IaC 도구는 이미 모듈화 기능을 제공한다. 세션에서는 Bicep, Terraform, Pulumi를 예시로 들었다.
2-1. Azure Bicep
-
구현: 일반적인
.bicep파일이 곧 모듈이 된다. -
인터페이스 설계:
param으로 입력을 받고 output으로 결과를 내보낸다. -
내부 로직: 리소스 생성 시
uniqueString()함수 등을 사용해 네이밍 규칙을 자동화하거나, 특정 속성(예:supportsHttpsTrafficOnly: true)을 강제하여 사용자에게 보이지 않게 처리한다.
- 소비:
module키워드를 사용하여 해당 bicep 파일을 참조하고 파라미터를 전달한다.
2-2. Terraform
-
구조: 일반적으로
main.tf(리소스 로직),variables.tf(입력 변수),outputs.tf(출력값)로 파일을 분리하여 관리한다. -
소비:
module블록을 선언하고 source 속성에 모듈이 위치한 경로(로컬 또는 원격)를 지정하여 사용한다.
2-3. Pulumi
-
특징: Python, C# 등 범용 프로그래밍 언어를 사용하므로, 해당 언어의 클래스나 함수 구조를 그대로 활용한다.
-
구현:
'Component Resource'클래스를 정의하여 리소스 생성 로직을 캡슐화한다. -
소비: 메인 코드에서 해당 클래스의 인스턴스를 생성하는 방식으로 모듈을 호출한다.
3. 좋은 모듈을 만드는 7원칙
단순히 코드를 분리한다고 좋은 모듈이 되는 것은 아니다. 지속 가능한 라이브러리를 구축하기 위해 다음 원칙을 따라야 한다.
-
단일 책임 원칙:
-
슈퍼 모듈을 피해야 한다. 스토리지 모듈은 스토리지 생성에만 집중해야 한다.
-
예외: Kubernetes 클러스터처럼 그 자체로 복합적인 리소스는 묶어서 배포하되, 네트워크처럼 외부 의존성이 있는 리소스는 분리하여 주입받는 것이 좋다.
-
-
단순한 인터페이스:
-
모든 속성을 파라미터로 노출하지 말아야 한다. 모듈의 목적은 복잡성 은폐이다.
-
사용자가 고민할 필요가 없는 설정(예: 보안 표준)은 내부적으로 고정하고, 꼭 필요한 값만 입력받는다.
-
-
가치 창출:
-
단순히 리소스 그룹처럼 옵션이 거의 없는 리소스를 감싸는 Wrapper 모듈은 의미가 없다.
-
복잡성을 줄이거나 표준을 강제하는 가치가 있어야 한다.
-
-
버전 관리:
-
모듈 코드를 수정했을 때 기존 사용자의 배포가 깨지면 안 된다.
-
시맨틱 버저닝을 도입하여 사용자가 업그레이드 시점을 선택할 수 있게 해야 한다.
-
-
접근성:
- 사용자가 모듈을 쉽게 가져다 쓸 수 있어야 한다.
-
유지보수:
-
클라우드 공급자의 신규 기능이나 변경 사항을 제때 반영해야 한다.
-
방치된 모듈은 결국 버려진다.
-
-
문서화 및 홍보:
-
사용법이 문서화되지 않은 모듈은 아무도 쓰지 않는다.
-
또한, 모듈의 존재와 사용 이점을 조직 내에 적극적으로 알려야 한다.
-
4. 모듈 배포 및 관리 전략
로컬 경로(./modules/storage)를 참조하는 방식은 협업 환경에서 확장성이 없다.
각 도구별로 제공하는 중앙 저장소 기능을 활용하여 단일 진실 공급원을 구축해야 한다.
-
Azure (Bicep/ARM):
-
Template Specs: Azure 리소스로 템플릿을 저장하고 버전 관리할 수 있다.
-
Bicep Registry: Azure Container Registry(ACR)를 OCI 호환 저장소로 활용하여 모듈을 배포할 수 있다.
-
-
Terraform:
- Git 리포지토리를 직접 참조하거나, Terraform Registry (Terraform Cloud/Enterprise)를 사용한다.
-
Pulumi:
- 프로그래밍 언어 기반이므로 npm (Node.js), PyPI (Python), NuGet (.NET) 등 언어별 패키지 매니저를 통해 배포하고 설치한다.
-
AWS CloudFormation:
- CloudFormation Registry를 통해 모듈을 등록하고 관리한다.
5. 정리
인프라 코드 모듈화는 단순한 코드 정리를 넘어, 조직의 인프라 거버넌스를 기술적으로 구현하는 핵심 전략이다.
