| name | incremental-change |
| description | Delivers infrastructure changes incrementally. Use when making any IaC change that touches multiple resources, modules, or environments. Use when a Terraform/Ansible change feels too large to apply in one step. |
Incremental Change
Overview
인프라 변경을 작은 단위로 나누어 적용·검증·커밋하는 워크플로우입니다.
한 번에 대규모 변경을 적용하면 롤백이 어렵고 장애 원인 파악이 불가능합니다.
각 단계마다 시스템이 정상 상태를 유지해야 합니다.
When to Use
- 여러 리소스를 동시에 변경하는 Terraform 작업
- 다수 호스트에 영향을 주는 Ansible playbook
- 환경 간 마이그레이션 (dev → stg → prd)
- 네트워크 구조 변경 (VPC, Subnet, SG)
- 데이터베이스 스키마 변경이 포함된 배포
적용하지 않는 경우: 단일 리소스 태그 변경, 단일 파라미터 수정 등 범위가 명확한 최소 변경.
The Increment Cycle
┌──────────────────────────────────────────┐
│ │
│ Change ──→ Plan ──→ Apply ──→ Verify ──┐ │
│ ^ │ │
│ └────── Commit <───────────────────┘ │
│ │ │
│ v │
│ Next slice │
│ │
└──────────────────────────────────────────┘
각 단계:
- Change — 최소 단위의 IaC 코드 수정
- Plan —
terraform plan 또는 ansible --check로 영향 범위 확인
- Apply — 변경 적용
- Verify — 리소스 상태, 서비스 정상 동작 확인
- Commit — 변경 사항 커밋 (롤백 포인트)
- Next slice — 다음 단위로 이동
Slicing Strategies
Dependency-First (기본)
의존성 순서대로 적용:
Slice 1: VPC, Subnet 생성
→ terraform apply → 네트워크 리소스 확인
Slice 2: Security Group 생성
→ terraform apply → SG 규칙 확인
Slice 3: EC2/ECS 리소스 생성
→ terraform apply → 인스턴스 상태 확인
Slice 4: ALB + Target Group 연결
→ terraform apply → health check 통과 확인
Risk-First
가장 위험한 변경을 먼저 적용:
Slice 1: RDS 엔진 업그레이드 (가장 위험, 롤백 어려움)
→ 성공 확인 후 다음 진행
Slice 2: 애플리케이션 호환성 변경
Slice 3: 모니터링 업데이트
Environment-First
환경 순서대로 동일 변경 적용:
Slice 1: dev 환경 적용 → 검증
Slice 2: stg 환경 적용 → 검증 + 부하 테스트
Slice 3: prd 환경 적용 → 검증 + 모니터링 확인
Implementation Rules
Rule 1: Plan Before Apply
모든 apply 전에 plan을 확인합니다.
terraform plan -out=tfplan
terraform apply tfplan
Rule 2: One Logical Change Per Apply
하나의 apply에 하나의 논리적 변경만 포함합니다.
나쁨: SG 변경 + RDS 파라미터 변경 + EC2 타입 변경을 한 번에 apply
좋음: 각각 별도 apply → 문제 발생 시 어떤 변경이 원인인지 즉시 파악
Rule 3: Verify After Every Apply
적용 후 반드시 검증합니다.
aws ec2 describe-instances --instance-ids <id> --query 'Reservations[].Instances[].State'
curl -f http://endpoint/health
terraform plan
Rule 4: Rollback Plan Required
각 단계마다 롤백 방법을 명시합니다.
변경: SG에 인바운드 규칙 추가
롤백: terraform apply 이전 커밋의 코드로 재적용
검증: 서비스 접근 정상 확인
Rule 5: No Manual Console Changes
IaC로 관리되는 리소스는 콘솔에서 수동 변경하지 않습니다.
긴급 상황에서 수동 변경 시, 즉시 IaC에 반영합니다.
Terraform Specific
State 안전 규칙
terraform state pull > backup-$(date +%Y%m%d-%H%M%S).tfstate
aws s3api list-object-versions --bucket <tf-state-bucket> \
--prefix <state-key> --max-items 3
terraform state mv aws_instance.old aws_instance.new
terraform import aws_instance.new i-1234567890abcdef0
대규모 변경 시 -target 활용
terraform apply -target=aws_vpc.main
terraform apply -target=aws_subnet.private
terraform apply
🟡 -target은 임시 수단입니다. 최종적으로 전체 terraform apply가 "No changes"여야 합니다.
Ansible Specific
점진적 적용
ansible-playbook site.yml --check --diff
ansible-playbook site.yml --limit "web-01"
ansible-playbook site.yml
태그 활용
ansible-playbook site.yml --tags "nginx"
ansible-playbook site.yml --skip-tags "destructive"
Common Rationalizations
| Rationalization | Reality |
|---|
| "한 번에 apply 하면 빠릅니다" | 장애 시 어떤 변경이 원인인지 모릅니다. 분리합니다. |
| "dev에서 됐으니 prd도 됩니다" | 환경마다 다릅니다. 각 환경에서 검증합니다. |
| "plan 봤으니 apply 해도 됩니다" | plan과 실제 apply 결과가 다를 수 있습니다. apply 후 검증합니다. |
| "작은 변경이라 롤백 계획 불필요합니다" | 작은 변경도 연쇄 장애를 일으킬 수 있습니다. 롤백 계획은 필수입니다. |
| "콘솔에서 빨리 고치겠습니다" | drift가 발생합니다. IaC로 수정합니다. |
Red Flags
terraform apply 전에 terraform plan 미확인- 여러 논리적 변경을 한 번에 apply
- apply 후 검증 없이 다음 작업 진행
- 롤백 계획 없이 프로덕션 변경
- 콘솔 수동 변경 후 IaC 미반영
-target 사용 후 전체 plan 미확인- apply 후 장애 발생 시 →
skill://debugging-and-recovery 전환
Verification
모든 변경 완료 후:
