PR 기반 자동화 파이프라인 구축 – Terraform (4)

수동 검증의 한계

Terraform을 쓰면서 가장 먼저 부딪힌 문제는 검증의 일관성이었다.
PR 하나 열 때마다 리뷰어는 다음을 확인해야 한다.

• Terraform 문법
• 보안 취약점
• 조직 정책 준수 여부
• 비용 변화
• 필수 태그 여부
• 네이밍 규칙
• 암호화 설정

문제는 간단하다.
사람이 이걸 매번 수동으로 검증하면 언젠가 반드시 놓친다.
리뷰 시간이 길어지고, 리뷰어에 따라 기준도 달라진다.
심하면 배포 이후에 문제를 발견한다.
그래서 나는 검증 자체를 PR에 붙여 버렸다.
리뷰어의 역량이나 컨디션에 의존하지 않도록.

---

PR이 열리면 자동으로 검증이 흐르는 구조

내가 만든 전체 구조는 이렇다.

PR 생성 → GitHub Actions 트리거
          │
          ├─ Terraform 검증 (fmt, validate)
          ├─ 보안 스캔 (tfsec)
          ├─ 정책 검증 (checkov, OPA)
          └─ 비용 분석 (Infracost)
          │
          ├─ 모든 검증 통과
          └─ PR 코멘트 자동 생성

 
이렇게 해두니 리뷰어는 단순하다.
“검증 통과했는지 보고, 논리적인 변경인지 판단만 한다.”
사람이 해야 하는 일과 기계가 해야 하는 일을 명확히 나눴다.

---

GitHub Actions로 구성한 검증 파이프라인

전체 파이프라인은 하나의 YAML 안에서 다음 네 단계를 분리했다.

1. Terraform 검증
2. 보안 스캔(tfsec, checkov)
3. 조직 정책 검증(OPA)
4. 비용 분석(Infracost)

각 단계는 독립된 job이며, 실패하면 바로 리뷰 차단된다.
코드 일부는 다음과 같다:
 

name: Terraform Plan
on:
  pull_request:
    paths:
      - 'terraform/**/*.tf'

 
아래는 생략하지만 전체 구조는 위 4단계로 깔끔하게 나뉜다.

---

1단계 — Terraform 검증

포맷 검증

기본이지만 매우 중요하다.

terraform fmt -check -recursive terraform/

포맷이 틀리면 바로 실패한다.
리뷰어가 “포맷 좀 맞춰주세요” 같은 말 할 필요가 없다.

terraform validate

잘못된 속성명을 쓰거나 리소스 구조를 잘못 잡으면 여기서 걸린다.

---

2단계 — 보안 스캔(tfsec, checkov)

tfsec

AWS 보안 베스트 프랙티스를 기준으로 검증한다.
예를 들어 보안 그룹에 0.0.0.0/0이 열려 있으면 바로 걸린다.

tfsec terraform/

실제로 작업하면서 제일 많이 잡히는 부분이기도 하다.

checkov

조직 정책 수준의 검증이다.

• S3 로그 필수 여부
• CloudWatch 로그 KMS 여부
• IAM Wildcard 여부 등

개발자가 직접 찾기 어려운 실수들이 여기서 걸러진다.

---

3단계 — OPA로 조직 정책 강제

tfsec, checkov가 “일반적인 best practice”라면,
OPA는 말 그대로 조직의 규칙을 강제로 지키게 하는 도구다.
예를 들어 “모든 리소스는 특정 태그를 가져야 한다”
이런 정책은 Terraform으로 강제할 수 없다.
그래서 OPA 정책을 직접 만들었다.

• 필수 태그 검사
• 네이밍 규칙(kebab-case, snake_case)
• S3 / RDS / CloudWatch Logs 암호화

검증 실패 시 PR이 바로 차단된다.
OPA 정책 예시는 이런 것들이다:

deny[msg] {
  resource := input.resource_changes[_]
  missing := required_tags - {tag | resource.change.after.tags[tag]}
  count(missing) > 0
}

 

---

4단계 — 비용 분석(Infracost)

Terraform에서 비용 변화가 얼마나 발생하는지 자동으로 코멘트를 남긴다.
코드만 보면 잘 모르는 변경도 Infracost가 알려준다.

• 이전 월 비용
• 새로운 월 비용
• 증가/감소 퍼센트
• 어떤 리소스가 비용을 올리는지

Previous cost: $197.44
New cost: $238.89
Difference: +$41.45 (+21%)

 
 

PR 자동 코멘트

검증이 모두 끝나면 PR에 코멘트가 자동으로 달린다.
예시는 이런 느낌이다:

## ✅ All validations passed

Format: OK  
Validate: OK  
tfsec: OK  
checkov: OK  
OPA: OK  
Cost: +$12.50 (+5%)

리뷰어는 변경 내용을 읽고
“이 변경이 타당한가?”
이것만 보면 된다.
반대로 실패하면 이렇게 나온다:

 

❌ Missing required tags
❌ S3 bucket must use KMS
❌ Format mismatch

개발자가 고쳐서 다시 push하면 다시 검증이 돈다.

---

로컬에서도 동일하게 검증

CI에만 의존하지 않도록 pre-commit hook도 만들어뒀다.

pre-commit run --all-files

 
 
로컬에서 미리 문제를 잡을 수 있어 빠르게 피드백을 돌릴 수 있다.

---

정리

이 4단계 검증 파이프라인을 붙이고 나서 인프라 변경이 훨씬 안정적이 됐다.

• 사람이 실수할 여지가 줄고
• 리뷰의 품질이 올라가고
• 배포 전 문제를 대부분 걸러내고
• 조직 정책을 코드로 강제하고
• 비용까지 예측된다

더 이상 “놓친 게 있을까?” 걱정하지 않는다.
PR만 열면 모든 검증이 자동으로 흘러가도록 만들었기 때문이다.