해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.
Day 57 - A practical guide to Test-Driven Development of infrastructure code
1. 테스트 주도 개발 (TDD) 란?
TDD(Test-Driven Development)는 소프트웨어 요구 사항을 실행 가능한 일련의 테스트로 변환하는 개발 관행이다.
-
테스트 작성: 실제 기능 코드를 작성하기 전, 요구 사항을 반영한 테스트를 먼저 작성한다.
이때 뒷받침할 코드가 없으므로 테스트는 당연히 실패한다. -
코드 작성: 테스트를 통과할 수 있는 아주 간단한 코드를 점진적으로 작성한다.
-
리팩토링: 테스트를 반복 실행하며 회귀 오류나 버그 유무를 확인하고, 코드를 다듬고 개선한다.
소프트웨어 개발에서는 유닛 테스트, 통합 테스트, 기능 테스트 등 테스트 피라미드라 불리는 다양한 유형이 존재한다. 그렇다면 이러한 개념을 IaC에는 어떻게 적용할 수 있을까?
2. IaC의 테스트
IaC에서 바라는 테스트의 핵심 목표는 다음과 같다.
-
코드 유효성(Code Validity): 코드가 올바른 구문을 가지며 코딩 표준을 따르는지 확인한다.
-
보안 모범 사례(Security Best Practices): 리소스 구성의 보안성을 검토하고, 비밀번호나 키가 평문으로 노출되지 않도록 한다.
-
컴플라이언스(Compliance): 대상 환경의 정책 및 거버넌스를 준수하는지 확인한다. 배포 단계에서 정책 위반으로 차단되는 상황을 방지한다.
-
클라우드 제공업체 모범 사례: Microsoft Azure의 경우 Well-Architected Framework와 같은 권장 사항을 준수한다.
-
기능적 요구 사항: 필요한 컴포넌트와 속성이 올바르게 프로비저닝되는지 확인한다.
IaC의 테스트 및 검증 영역은 크게 Inner Loop와 Outer Loop로 구분할 수 있다.
-
Inner Loop: 코드를 원격 저장소에 푸시하기 전, 로컬 환경에서 실행하는 테스트
-
Outer Loop: 로컬이 아닌 CI/CD 파이프라인 상에서 실행되는 테스트
1) 코드 검증 (Code Validation)
코드가 유효한지, 오류가 없는지를 다룬다.
-
Linter: Bicep에는 내장된 Linter가 존재
-
Pester: PowerShell용 테스트 프레임워크지만 Bicep 검증에도 활용 가능
-
Bicep 실험적 기능: Bicep 자체의 네이티브 테스트 기능이 있으나, 아직 개발 초기 단계
2) 베스트 프랙티스 (Best Practices)
Well-Architected Framework 등의 권장 사항 준수 여부를 확인한다.
-
PSRule for Azure: 400개 이상의 사전 정의된 규칙을 제공하는 PowerShell 모듈이다. 배포 내용이 권장 사항을 준수하는지 확인한다.
-
ARM TTK: 과거 ARM 템플릿 시절 도구이며, 현재 Bicep 팀은 이 규칙들을 네이티브 린터로 통합하고 있다.
3) 보안 테스트 (Security Testing)
- Snyk & Kics: 인프라 코드의 보안 취약점을 점검하는 대표적인 도구들이다.
4) 컴플라이언스 (Compliance)
대상 환경의 정책 위반 가능성을 다룬다.
- PSRule + EPAC (Enterprise Policy as Code): EPAC을 통해 실제 환경의 정책을 내보내고, 이를 PSRule이 이해할 수 있는 형식으로 변환하여 로컬에서 정책 준수 여부를 테스트할 수 있다.
5) 배포 검증 (Deployment Validation) - 아우터 루프
배포 파이프라인 상에서 수행된다.
-
Deployment Validate: 대상 리전의 Quota나 서비스 가용성을 확인한다.
-
What-if: 현재 Azure 상태와 코드 상의 상태를 비교하여 변경 사항을 예측한다.
6) 배포 후 검증 (Post-Deployment)
실제 배포가 완료된 후 리소스를 검증한다.
- BenchPress & Pester: 배포된 리소스를 조회하여 속성이 의도대로 설정되었는지 확인한다.
3. IaC의 테스트 작성
TDD는 테스트를 먼저 작성하라고 요구하지만, IaC의 경우 모든 테스트를 직접 작성할 필요는 없다.
대부분의 도구 (Linter, PSRule 등)가 내장된 테스트를 제공하기 때문에 이를 활용하면 되고, 사용자는 필요에 따라 커스텀 규칙만 추가하면 되므로 부담이 적다.
코드를 작성하는 환경은 크게 로컬과 원격으로 나뉘게 된다.
-
로컬 설치: VS Code에 모든 도구를 직접 설치 방법
-
Dev Container: 도커 컨테이너 안에 필요한 모든 도구를 미리 설치하는 방식.
로컬에 Docker만 있다면 복잡한 설치 과정 없이 환경을 구축할 수 있음. -
GitHub Codespaces: Dev Container 설정을 그대로 활용하여 클라우드 상에서 개발 환경을 즉시 실행하는 방법
-
Microsoft Dev Box: 윈도우 풀 환경을 제공하나 IaC 개발에는 오버스펙일 수 있음.
코딩 랜딩 존 (Coding Landing Zone) ?
복잡한 도구 설정과 사전 요구 사항을 매번 구성하는 것은 비효율적이다.
이를 해결하기 위해 '코딩 랜딩 존' 개념을 도입할 수 있다. 이는 모든 설정이 내장된 GitHub Template Repository를 의미한다.
-
표준화된 구조: Bicep 파일, 테스트, 문서 폴더 구조화.
-
워크플로우: 검증 및 배포를 위한 표준 GitHub Actions 워크플로우 포함.
-
설정 파일: bicepconfig.json, ps-rule.yaml 등 미리 정의된 설정.
-
Dev Container: 환경 설정을 자동화하여, 사용자가 도커 데스크탑이나 Codespaces를 통해 즉시 개발을 시작할 수 있도록 지원.
이러한 방식은 도구와 설정에 대한 오버헤드를 줄이고, 조직 내에서 표준화된 IaC 개발 환경을 제공하는 데 매우 효과적이다.
4. IaC 테스트를 왜 해야하는가?
-
피드백 루프의 단축
-
일반적으로 클라우드 배포는 시간이 걸린다. 코드를 작성하고 커밋한 뒤, CI/CD 파이프라인이 돌고 클라우드에 배포를 시도하다가 에러가 나서 실패하는 과정을 겪으면 수십 분이 낭비
-
이점: 로컬(Inner Loop)에서 Linter와 테스트 도구를 돌리면, 굳이 클라우드에 배포해보지 않아도 코드를 짜는 즉시 오류를 발견할 수 있어, 개발 속도를 비약적으로 높여준다.
-
-
각 클라우드 플랫폼의 정책 준수
-
코드를 짜서 배포를 눌렀는데 조직의 거버넌스 정책(예: 특정 리전 배포 금지, 공용 IP 생성 금지 등) 때문에 배포가 막히는 것은 좌절스러운 경험
-
이점: PSRule과 EPAC 같은 도구를 사용하면 조직의 정책 위반 여부를 로컬에서 미리 확인할 수 있다.
-
-
보안 사고의 사전 예방
-
인프라 코드에 실수로 데이터베이스 비밀번호를 평문으로 적거나, 스토리지 계정을 전체 공개로 열어두는 실수는 흔하지만 치명적
-
이점: Snyk이나 Kics 같은 보안 도구는 사람이 놓치기 쉬운 보안 취약점이나 비밀번호 노출을 자동으로 스캔하여, 보안 사고가 발생하기 전에 차단해 준다.
-
-
인프라 품질의 상향 평준화 (Best Practices)
-
팀 내에서 누가 코드를 작성하느냐에 따라 인프라의 품질이 달라질 수 있다. 누군가는 MS의 권장 사항(Well-Architected Framework)을 잘 따르지만, 누군가는 기능 구현에만 초점을 맞출 수 있음.
-
이점: PSRule for Azure와 같은 도구는 400개 이상의 검증된 규칙을 기반으로 코드를 검사한다. 이를 통해 누가 작성하든 전문가 수준의 모범 사례(Best Practices)를 준수하는 고품질의 인프라를 구축할 수 있다.
-
IaC 테스트 툴을 도입하는 것은 "인프라 구성을 스크립트 작성 수준에서 소프트웨어 엔지니어링 수준으로 끌어올리는 것"이다.
