Ver3.0 전체 열람

Ver3.0 🚀 클라우드 인프라 변경 자동화: Terraform과 CI/CD로 완성하는 스마트한 배포 전략

2025.11.08

재능넷

댓글 0 전체 79 페이지

🚀 클라우드 인프라 변경 자동화: Terraform과 CI/CD로 완성하는 스마트한 배포 전략

코드 한 줄로 인프라를 관리하는 마법 같은 세계로 초대합니다! ✨

안녕, 친구! 😊 혹시 클라우드 인프라를 수동으로 관리하면서 "이거 실수하면 어쩌지?" 하고 식은땀 흘린 적 있어? 아니면 서버 설정을 바꾸려고 AWS 콘솔을 클릭클릭하다가 "아, 이거 어디까지 했더라?" 하고 헷갈린 적은? 🤔

나도 그랬어. 그런데 Terraform과 CI/CD를 만나고 나서 완전히 새로운 세상이 열렸지! 이제는 코드 몇 줄로 수백 개의 서버를 관리하고, 실수 없이 자동으로 배포할 수 있게 됐거든. 마치 마법 같은 일이야! ✨

오늘은 이 놀라운 기술들을 친구에게 설명하듯이 쉽고 재미있게 풀어볼게. 재능넷에서 DevOps 관련 재능을 공유하거나 배우고 싶은 사람들에게도 딱 맞는 내용이니까, 끝까지 함께 가보자! 🎯

🎯 왜 인프라 자동화가 필요할까?

먼저 이야기를 하나 해볼게. 내 친구 민수(가명)는 스타트업에서 백엔드 개발자로 일하고 있어. 어느 날 서비스가 갑자기 터졌는데, 알고 보니 누군가 AWS 콘솔에서 보안 그룹 설정을 잘못 건드린 거였어. 😱

문제는 누가, 언제, 무엇을 바꿨는지 추적이 안 된다는 거야. 팀원들끼리 "내가 아닌데?" 하면서 서로 눈치만 보다가 결국 몇 시간 동안 서비스가 다운됐지. 이런 상황, 정말 끔찍하지 않아?

💥 수동 인프라 관리의 문제점들

1. 휴먼 에러의 위험 🙈
사람이 직접 클릭하고 타이핑하다 보면 실수는 필연적이야. 특히 새벽 3시에 긴급 배포할 때는 더더욱!

2. 일관성 부족 🎭
개발 환경, 스테이징 환경, 프로덕션 환경... 각각 설정이 조금씩 다르면 "내 컴퓨터에선 되는데?"라는 악몽이 시작돼.

3. 추적 불가능 🕵️
누가 언제 무엇을 바꿨는지 기록이 없으면, 문제가 생겼을 때 원인을 찾기가 정말 어려워.

4. 확장성 한계 📈
서버 10대는 수동으로 관리할 수 있어도, 100대, 1000대가 되면? 상상만 해도 끔찍하지.

5. 지식의 사일로화 🏝️
"이 설정은 철수만 알아"라는 상황이 되면, 철수가 휴가 가면 팀 전체가 멈춰버려.

이런 문제들을 해결하기 위해 등장한 게 바로 Infrastructure as Code (IaC)야! 인프라를 코드로 관리하는 거지. 그리고 그 중심에 Terraform이 있어. 🎪

🏗️ Terraform이 뭐길래?

Terraform은 HashiCorp라는 회사에서 만든 오픈소스 IaC 도구야. 간단히 말하면, 인프라를 코드로 정의하고 관리할 수 있게 해주는 마법 도구지! 🪄

예를 들어볼게. AWS에서 EC2 인스턴스를 만들려면 보통 이렇게 하잖아?

전통적인 방법:
1. AWS 콘솔에 로그인 🖱️
2. EC2 서비스로 이동
3. "인스턴스 시작" 버튼 클릭
4. AMI 선택
5. 인스턴스 타입 선택
6. 네트워크 설정
7. 스토리지 설정
8. 태그 추가
9. 보안 그룹 설정
10. 키 페어 선택
11. 최종 확인 및 시작

총 소요 시간: 약 10-15분 (클릭 포함) 😓

하지만 Terraform을 사용하면?

Terraform 방법:

resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
  
  tags = {
    Name = "MyWebServer"
  }
}

그리고 터미널에서:
terraform apply

총 소요 시간: 약 2-3분 (코드 작성 + 실행) 🚀

🎉 Terraform의 핵심 장점 1. 선언적 문법 (Declarative)
"어떻게" 만들지가 아니라 "무엇을" 만들지만 정의하면 돼. Terraform이 알아서 최적의 방법으로 만들어줘!

2. 멀티 클라우드 지원
AWS, Azure, GCP, 심지어 온프레미스까지! 하나의 도구로 모든 클라우드를 관리할 수 있어. 🌍

3. 상태 관리 (State Management)
현재 인프라의 상태를 추적해서, 변경사항만 정확하게 적용해. 똑똑하지?

4. 실행 계획 (Plan)
실제로 적용하기 전에 "이렇게 바뀔 거예요"라고 미리 보여줘. 실수를 방지할 수 있지!

5. 모듈화
재사용 가능한 코드 블록을 만들어서, 마치 레고 블록처럼 조립할 수 있어. 🧱

📚 Terraform의 핵심 개념들

1. Provider (프로바이더)

Provider는 Terraform이 어떤 클라우드나 서비스와 통신할지 정의하는 거야. AWS, Azure, GCP 등등 말이야.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
}

provider "aws" {
  region = "ap-northeast-2"  # 서울 리전
}

2. Resource (리소스)

실제로 생성하고 관리할 인프라 구성 요소야. EC2, RDS, S3 버킷 등등!

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-awesome-bucket-2024"
  
  tags = {
    Environment = "Production"
    Team        = "DevOps"
  }
}

3. Variable (변수)

코드를 재사용 가능하게 만들어주는 마법! 환경별로 다른 값을 쉽게 적용할 수 있어.

variable "instance_type" {
  description = "EC2 인스턴스 타입"
  type        = string
  default     = "t2.micro"
}

resource "aws_instance" "app_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = var.instance_type
}

4. Output (출력)

생성된 리소스의 정보를 출력해서 다른 곳에서 사용할 수 있게 해줘.

output "instance_public_ip" {
  description = "EC2 인스턴스의 공개 IP"
  value       = aws_instance.app_server.public_ip
}

5. Module (모듈)

재사용 가능한 Terraform 코드 묶음! 마치 함수처럼 사용할 수 있어.

module "vpc" {
  source = "./modules/vpc"
  
  vpc_cidr = "10.0.0.0/16"
  environment = "production"
}

💡 실전 팁: Terraform을 처음 배울 때는 작은 프로젝트부터 시작해봐. 예를 들어 S3 버킷 하나 만들기부터! 그리고 점점 복잡한 인프라로 확장해 나가는 거야. 재능넷에서 Terraform 멘토를 찾아서 1:1로 배우는 것도 정말 효과적이야! 🎓

⚙️ Terraform 워크플로우: 실전 사용법

자, 이제 Terraform을 실제로 어떻게 사용하는지 알아볼까? Terraform의 워크플로우는 크게 4단계로 나뉘어. 이걸 이해하면 Terraform 마스터의 절반은 온 거야! 💪

🔄 Terraform 4단계 워크플로우

1️⃣ Write (작성)

먼저 .tf 파일에 원하는 인프라를 코드로 작성해. HCL(HashiCorp Configuration Language)이라는 언어를 사용하는데, 정말 읽기 쉬워!

# main.tf
terraform {
  required_version = ">= 1.0"
  
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
}

provider "aws" {
  region = var.aws_region
}

# VPC 생성
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true
  
  tags = {
    Name        = "main-vpc"
    Environment = var.environment
  }
}

# 서브넷 생성
resource "aws_subnet" "public" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.1.0/24"
  availability_zone       = "ap-northeast-2a"
  map_public_ip_on_launch = true
  
  tags = {
    Name = "public-subnet"
  }
}

2️⃣ Init (초기화)

terraform init 명령어로 Terraform을 초기화해. 이 과정에서 필요한 Provider 플러그인들을 다운로드받아.

$ terraform init

Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/aws versions matching "~> 4.0"...
- Installing hashicorp/aws v4.67.0...
- Installed hashicorp/aws v4.67.0

Terraform has been successfully initialized! 🎉

💡 알아두면 좋아요: .terraform 디렉토리가 생성되는데, 여기에 Provider 플러그인들이 저장돼. 이 폴더는 .gitignore에 추가하는 게 좋아!

3️⃣ Plan (계획)

terraform plan으로 실행 계획을 확인해. 실제로 적용하기 전에 "이렇게 바뀔 거예요"라고 미리 보여주는 거야. 이게 진짜 중요해! 🔍

$ terraform plan

Terraform will perform the following actions:

  # aws_vpc.main will be created
  + resource "aws_vpc" "main" {
      + cidr_block           = "10.0.0.0/16"
      + enable_dns_hostnames = true
      + enable_dns_support   = true
      + id                   = (known after apply)
      + tags                 = {
          + "Environment" = "production"
          + "Name"        = "main-vpc"
        }
    }

  # aws_subnet.public will be created
  + resource "aws_subnet" "public" {
      + cidr_block              = "10.0.1.0/24"
      + vpc_id                  = (known after apply)
      + availability_zone       = "ap-northeast-2a"
      + map_public_ip_on_launch = true
      + tags                    = {
          + "Name" = "public-subnet"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

여기서 주목할 점! ✨
- + (초록색): 새로 생성될 리소스
- ~ (노란색): 수정될 리소스
- - (빨간색): 삭제될 리소스

이렇게 미리 확인할 수 있으니까 실수를 방지할 수 있어!

4️⃣ Apply (적용)

모든 게 괜찮아 보이면 terraform apply로 실제로 적용해!

$ terraform apply

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

aws_vpc.main: Creating...
aws_vpc.main: Creation complete after 3s [id=vpc-0123456789abcdef]
aws_subnet.public: Creating...
aws_subnet.public: Creation complete after 2s [id=subnet-0123456789abcdef]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

짜잔! 🎊 이제 AWS에 실제로 VPC와 서브넷이 생성됐어!

⚠️ 주의사항: terraform apply를 실행하기 전에 항상 terraform plan을 먼저 확인하는 습관을 들여! 특히 프로덕션 환경에서는 더더욱! 한 번의 실수가 서비스 전체를 다운시킬 수 있거든. 😱

🗑️ 보너스: Destroy (삭제)

테스트가 끝나고 리소스를 정리하고 싶을 때는 terraform destroy를 사용해. 생성한 모든 리소스를 깔끔하게 삭제해줘!

$ terraform destroy

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes

aws_subnet.public: Destroying... [id=subnet-0123456789abcdef]
aws_subnet.public: Destruction complete after 1s
aws_vpc.main: Destroying... [id=vpc-0123456789abcdef]
aws_vpc.main: Destruction complete after 2s

Destroy complete! Resources: 2 destroyed.

🎯 프로 팁: 개발 환경에서는 작업이 끝나면 destroy로 리소스를 삭제해서 비용을 절약할 수 있어. AWS는 사용한 만큼만 과금되니까! 💰

🔐 State 관리: Terraform의 두뇌

Terraform의 가장 중요한 개념 중 하나가 바로 State(상태)야. 이게 뭐냐면, Terraform이 관리하는 인프라의 현재 상태를 기록하는 파일이야. 마치 인프라의 "사진"을 찍어두는 거지! 📸

🧠 State 파일이 하는 일

1. 현재 상태 추적
어떤 리소스가 생성되어 있는지, 각 리소스의 ID는 무엇인지 등을 기록해.

2. 변경사항 계산
코드와 실제 인프라를 비교해서 무엇을 추가/수정/삭제해야 하는지 계산해.

3. 성능 최적화
매번 클라우드 API를 호출하지 않고, State 파일을 참조해서 빠르게 동작해.

4. 메타데이터 저장
리소스 간의 의존성 정보 등을 저장해.

📁 Local State vs Remote State

State 파일은 기본적으로 로컬에 terraform.tfstate라는 이름으로 저장돼. 하지만 팀으로 일할 때는 문제가 생겨!

⚠️ Local State의 문제점 1. 협업 불가: 내 컴퓨터에만 State 파일이 있으면, 팀원들은 어떻게 해? 😰
2. 동시 수정 위험: 두 명이 동시에 apply하면 충돌 발생!
3. 백업 부재: 컴퓨터가 고장나면? State 파일도 날아가!
4. 보안 위험: State 파일에는 민감한 정보(비밀번호, API 키 등)가 들어있어.

그래서 실무에서는 Remote State를 사용해! 주로 S3나 Terraform Cloud를 사용하지.

✅ Remote State 설정 예시 (S3 + DynamoDB)

# backend.tf
terraform {
  backend "s3" {
    bucket         = "my-terraform-state-bucket"
    key            = "production/terraform.tfstate"
    region         = "ap-northeast-2"
    encrypt        = true
    dynamodb_table = "terraform-lock"  # State Lock용
  }
}

# S3 버킷 생성 (별도로 먼저 생성 필요)
resource "aws_s3_bucket" "terraform_state" {
  bucket = "my-terraform-state-bucket"
  
  lifecycle {
    prevent_destroy = true  # 실수로 삭제 방지!
  }
}

# 버킷 암호화 설정
resource "aws_s3_bucket_server_side_encryption_configuration" "terraform_state" {
  bucket = aws_s3_bucket.terraform_state.id
  
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

# 버전 관리 활성화
resource "aws_s3_bucket_versioning" "terraform_state" {
  bucket = aws_s3_bucket.terraform_state.id
  
  versioning_configuration {
    status = "Enabled"
  }
}

# DynamoDB 테이블 생성 (State Lock용)
resource "aws_dynamodb_table" "terraform_lock" {
  name           = "terraform-lock"
  billing_mode   = "PAY_PER_REQUEST"
  hash_key       = "LockID"
  
  attribute {
    name = "LockID"
    type = "S"
  }
}

💡 State Lock이 뭐야? 여러 명이 동시에 Terraform을 실행하면 State 파일이 꼬일 수 있어. State Lock은 한 번에 한 명만 작업할 수 있게 "잠금"을 거는 거야. DynamoDB를 사용하면 이 기능을 쉽게 구현할 수 있지! 🔒

🛠️ State 관리 명령어들

State를 직접 조작해야 할 때가 있어. 조심해서 사용해야 하지만, 알아두면 정말 유용해!

# State 파일 내용 확인
$ terraform state list

# 특정 리소스의 상세 정보 확인
$ terraform state show aws_instance.web_server

# 리소스를 State에서 제거 (실제 리소스는 삭제 안 됨)
$ terraform state rm aws_instance.old_server

# 리소스를 다른 이름으로 이동
$ terraform state mv aws_instance.old aws_instance.new

# State 파일을 원격에서 로컬로 가져오기
$ terraform state pull > terraform.tfstate

# 로컬 State를 원격으로 푸시
$ terraform state push terraform.tfstate

⚠️ 경고: State 파일을 직접 수정하는 건 정말 위험해! 가능하면 Terraform 명령어를 통해서만 조작하고, 직접 편집은 피하는 게 좋아. 백업은 필수! 🚨

🔄 CI/CD와 Terraform의 만남

자, 이제 진짜 재미있는 부분이야! Terraform을 CI/CD 파이프라인에 통합하면, 인프라 변경도 코드 배포처럼 자동화할 수 있어. 이게 바로 GitOps의 핵심이지! 🎯

🎭 전통적인 방식 vs CI/CD 방식

구분	전통적인 방식	CI/CD 방식
배포 방법	개발자가 수동으로 실행	Git push만 하면 자동 배포
검증	개발자의 눈으로만 확인	자동화된 테스트와 검증
승인 프로세스	구두 또는 이메일	Pull Request 리뷰
롤백	수동으로 이전 상태 복구	Git revert로 자동 롤백
감사 추적	별도 문서 작성	Git 히스토리에 자동 기록

🏗️ CI/CD 파이프라인 구조

Terraform을 CI/CD에 통합하는 전형적인 워크플로우를 살펴볼까?

1단계: 코드 작성 및 커밋 📝

개발자가 Terraform 코드를 작성하고 Git에 커밋해.

$ git checkout -b feature/add-rds-database
$ vim main.tf  # RDS 리소스 추가
$ git add .
$ git commit -m "Add RDS database for production"
$ git push origin feature/add-rds-database

2단계: Pull Request 생성 🔍

GitHub/GitLab에서 PR을 생성하면, CI 파이프라인이 자동으로 실행돼.

자동 실행되는 작업들:
- 코드 포맷 검사 (terraform fmt -check)
- 문법 검증 (terraform validate)
- 보안 스캔 (tfsec, Checkov 등)
- 비용 예측 (Infracost)
- Plan 실행 및 결과를 PR 코멘트로 자동 게시

3단계: 코드 리뷰 및 승인 👥

팀원들이 PR을 리뷰하고, Plan 결과를 확인한 후 승인해.

💡 리뷰 체크리스트:
✅ Plan 결과가 예상과 일치하는가?
✅ 보안 이슈는 없는가?
✅ 비용 증가가 합리적인가?
✅ 네이밍 컨벤션을 따르는가?
✅ 문서화가 충분한가?

4단계: 머지 및 자동 배포 🚀

PR이 머지되면, CD 파이프라인이 자동으로 terraform apply를 실행해!

배포 프로세스:
1. main 브랜치에 머지
2. CD 파이프라인 트리거
3. 환경별로 순차 배포 (dev → staging → production)
4. 각 단계마다 승인 게이트 설정 가능
5. 배포 완료 후 Slack/이메일 알림

5단계: 모니터링 및 롤백 📊

배포 후 모니터링하고, 문제가 생기면 즉시 롤백!

# 문제 발견 시 Git revert
$ git revert HEAD
$ git push origin main

# CI/CD가 자동으로 이전 상태로 롤백!

🔧 GitHub Actions로 구현하기

실제로 GitHub Actions를 사용해서 Terraform CI/CD를 구현해볼까? 완전 실전 예제야! 💪

파일 구조:

my-terraform-project/
├── .github/
│   └── workflows/
│       ├── terraform-plan.yml    # PR 생성 시 실행
│       └── terraform-apply.yml   # 머지 시 실행
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   └── variables.tf
│   ├── staging/
│   │   ├── main.tf
│   │   └── variables.tf
│   └── production/
│       ├── main.tf
│       └── variables.tf
└── modules/
    ├── vpc/
    ├── ec2/
    └── rds/

terraform-plan.yml (PR 시 자동 실행)

name: 'Terraform Plan'

on:
  pull_request:
    branches:
      - main
    paths:
      - 'environments/**'
      - 'modules/**'

env:
  TF_VERSION: '1.5.0'
  AWS_REGION: 'ap-northeast-2'

jobs:
  terraform-plan:
    name: 'Terraform Plan'
    runs-on: ubuntu-latest
    
    strategy:
      matrix:
        environment: [dev, staging, production]
    
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2
        with:
          terraform_version: ${{ env.TF_VERSION }}
      
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ env.AWS_REGION }}
      
      - name: Terraform Format Check
        id: fmt
        run: terraform fmt -check -recursive
        continue-on-error: true
      
      - name: Terraform Init
        id: init
        run: |
          cd environments/${{ matrix.environment }}
          terraform init
      
      - name: Terraform Validate
        id: validate
        run: |
          cd environments/${{ matrix.environment }}
          terraform validate -no-color
      
      - name: Terraform Plan
        id: plan
        run: |
          cd environments/${{ matrix.environment }}
          terraform plan -no-color -out=tfplan
        continue-on-error: true
      
      - name: Run tfsec
        uses: aquasecurity/tfsec-action@v1.0.0
        with:
          working_directory: environments/${{ matrix.environment }}
      
      - name: Comment PR
        uses: actions/github-script@v6
        if: github.event_name == 'pull_request'
        env:
          PLAN: "terraform\n${{ steps.plan.outputs.stdout }}"
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const output = `#### Terraform Format and Style 🖌\`${{ steps.fmt.outcome }}\`
            #### Terraform Initialization ⚙️\`${{ steps.init.outcome }}\`
            #### Terraform Validation 🤖\`${{ steps.validate.outcome }}\`
            #### Terraform Plan 📖\`${{ steps.plan.outcome }}\`
            
            <details><summary>Show Plan</summary>
            
            \`\`\`\n
            ${process.env.PLAN}
            \`\`\`
            
            </details>
            
            *Environment: ${{ matrix.environment }}*
            *Pushed by: @${{ github.actor }}, Action: \`${{ github.event_name }}\`*`;
            
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: output
            })
      
      - name: Terraform Plan Status
        if: steps.plan.outcome == 'failure'
        run: exit 1

terraform-apply.yml (머지 시 자동 실행)

name: 'Terraform Apply'

on:
  push:
    branches:
      - main
    paths:
      - 'environments/**'
      - 'modules/**'

env:
  TF_VERSION: '1.5.0'
  AWS_REGION: 'ap-northeast-2'

jobs:
  terraform-apply-dev:
    name: 'Apply to Dev'
    runs-on: ubuntu-latest
    environment: dev
    
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2
        with:
          terraform_version: ${{ env.TF_VERSION }}
      
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ env.AWS_REGION }}
      
      - name: Terraform Init
        run: |
          cd environments/dev
          terraform init
      
      - name: Terraform Apply
        run: |
          cd environments/dev
          terraform apply -auto-approve
      
      - name: Notify Slack
        uses: 8398a7/action-slack@v3
        if: always()
        with:
          status: ${{ job.status }}
          text: 'Terraform Apply to Dev: ${{ job.status }}'
          webhook_url: ${{ secrets.SLACK_WEBHOOK }}
  
  terraform-apply-staging:
    name: 'Apply to Staging'
    runs-on: ubuntu-latest
    needs: terraform-apply-dev
    environment: staging
    
    steps:
      # Dev와 동일한 스텝들...
      - name: Checkout
        uses: actions/checkout@v3
      
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2
        with:
          terraform_version: ${{ env.TF_VERSION }}
      
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ env.AWS_REGION }}
      
      - name: Terraform Init
        run: |
          cd environments/staging
          terraform init
      
      - name: Terraform Apply
        run: |
          cd environments/staging
          terraform apply -auto-approve
  
  terraform-apply-production:
    name: 'Apply to Production'
    runs-on: ubuntu-latest
    needs: terraform-apply-staging
    environment: 
      name: production
      url: https://myapp.example.com
    
    steps:
      # Staging과 동일한 스텝들...
      - name: Checkout
        uses: actions/checkout@v3
      
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2
        with:
          terraform_version: ${{ env.TF_VERSION }}
      
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ env.AWS_REGION }}
      
      - name: Terraform Init
        run: |
          cd environments/production
          terraform init
      
      - name: Terraform Apply
        run: |
          cd environments/production
          terraform apply -auto-approve
      
      - name: Notify Slack - Success
        uses: 8398a7/action-slack@v3
        if: success()
        with:
          status: custom
          custom_payload: |
            {
              text: '🎉 Production 배포 완료!',
              attachments: [{
                color: 'good',
                text: `Commit: ${{ github.event.head_commit.message }}\nAuthor: ${{ github.actor }}`
              }]
            }
          webhook_url: ${{ secrets.SLACK_WEBHOOK }}

💡 GitHub Environment 설정하기 GitHub Settings → Environments에서 dev, staging, production 환경을 만들고:
- Production에는 승인자(Reviewer) 설정
- 각 환경별로 Secret 변수 설정
- 배포 브랜치 제한 설정

이렇게 하면 프로덕션 배포 전에 팀장의 승인을 받을 수 있어! 🔐

🎨 실전 예제: 3-Tier 웹 애플리케이션 인프라

이론은 충분히 배웠으니, 이제 실전 예제를 만들어볼까? 전형적인 3-Tier 웹 애플리케이션 인프라를 Terraform으로 구축해보자! 🏗️

🏛️ 아키텍처 구성

Presentation Tier (프론트엔드)
- CloudFront (CDN)
- S3 (정적 파일 호스팅)
- Route53 (DNS)

Application Tier (백엔드)
- Application Load Balancer
- Auto Scaling Group
- EC2 인스턴스들

Data Tier (데이터베이스)
- RDS (PostgreSQL)
- ElastiCache (Redis)
- S3 (백업 및 로그)

📁 프로젝트 구조

3tier-webapp/
├── main.tf                 # 메인 설정
├── variables.tf            # 변수 정의
├── outputs.tf              # 출력 값
├── backend.tf              # State 백엔드 설정
├── versions.tf             # Provider 버전
│
├── modules/
│   ├── networking/         # VPC, 서브넷, 라우팅
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   │
│   ├── compute/            # EC2, ASG, ALB
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   │
│   ├── database/           # RDS, ElastiCache
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   │
│   └── cdn/                # CloudFront, S3
│       ├── main.tf
│       ├── variables.tf
│       └── outputs.tf
│
└── environments/
    ├── dev/
    │   ├── terraform.tfvars
    │   └── backend.hcl
    ├── staging/
    │   ├── terraform.tfvars
    │   └── backend.hcl
    └── production/
        ├── terraform.tfvars
        └── backend.hcl

🌐 1. Networking 모듈

modules/networking/main.tf

# VPC 생성
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true
  
  tags = {
    Name        = "${var.project_name}-vpc"
    Environment = var.environment
  }
}

# 인터넷 게이트웨이
resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id
  
  tags = {
    Name = "${var.project_name}-igw"
  }
}

# Public 서브넷들 (ALB용)
resource "aws_subnet" "public" {
  count             = length(var.availability_zones)
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet(var.vpc_cidr, 8, count.index)
  availability_zone = var.availability_zones[count.index]
  
  map_public_ip_on_launch = true
  
  tags = {
    Name = "${var.project_name}-public-${var.availability_zones[count.index]}"
    Type = "Public"
  }
}

# Private 서브넷들 (EC2용)
resource "aws_subnet" "private" {
  count             = length(var.availability_zones)
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet(var.vpc_cidr, 8, count.index + 10)
  availability_zone = var.availability_zones[count.index]
  
  tags = {
    Name = "${var.project_name}-private-${var.availability_zones[count.index]}"
    Type = "Private"
  }
}

# Database 서브넷들 (RDS용)
resource "aws_subnet" "database" {
  count             = length(var.availability_zones)
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet(var.vpc_cidr, 8, count.index + 20)
  availability_zone = var.availability_zones[count.index]
  
  tags = {
    Name = "${var.project_name}-database-${var.availability_zones[count.index]}"
    Type = "Database"
  }
}

# NAT 게이트웨이용 EIP
resource "aws_eip" "nat" {
  count  = length(var.availability_zones)
  domain = "vpc"
  
  tags = {
    Name = "${var.project_name}-nat-eip-${count.index + 1}"
  }
  
  depends_on = [aws_internet_gateway.main]
}

# NAT 게이트웨이
resource "aws_nat_gateway" "main" {
  count         = length(var.availability_zones)
  allocation_id = aws_eip.nat[count.index].id
  subnet_id     = aws_subnet.public[count.index].id
  
  tags = {
    Name = "${var.project_name}-nat-${count.index + 1}"
  }
}

# Public 라우팅 테이블
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id
  
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.main.id
  }
  
  tags = {
    Name = "${var.project_name}-public-rt"
  }
}

# Private 라우팅 테이블
resource "aws_route_table" "private" {
  count  = length(var.availability_zones)
  vpc_id = aws_vpc.main.id
  
  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.main[count.index].id
  }
  
  tags = {
    Name = "${var.project_name}-private-rt-${count.index + 1}"
  }
}

# 라우팅 테이블 연결
resource "aws_route_table_association" "public" {
  count          = length(var.availability_zones)
  subnet_id      = aws_subnet.public[count.index].id
  route_table_id = aws_route_table.public.id
}

resource "aws_route_table_association" "private" {
  count          = length(var.availability_zones)
  subnet_id      = aws_subnet.private[count.index].id
  route_table_id = aws_route_table.private[count.index].id
}

💻 2. Compute 모듈

modules/compute/main.tf

# Application Load Balancer
resource "aws_lb" "main" {
  name               = "${var.project_name}-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb.id]
  subnets            = var.public_subnet_ids
  
  enable_deletion_protection = var.environment == "production" ? true : false
  
  tags = {
    Name        = "${var.project_name}-alb"
    Environment = var.environment
  }
}

# ALB 타겟 그룹
resource "aws_lb_target_group" "app" {
  name     = "${var.project_name}-tg"
  port     = 80
  protocol = "HTTP"
  vpc_id   = var.vpc_id
  
  health_check {
    enabled             = true
    healthy_threshold   = 2
    interval            = 30
    matcher             = "200"
    path                = "/health"
    port                = "traffic-port"
    protocol            = "HTTP"
    timeout             = 5
    unhealthy_threshold = 2
  }
  
  tags = {
    Name = "${var.project_name}-tg"
  }
}

# ALB 리스너
resource "aws_lb_listener" "http" {
  load_balancer_arn = aws_lb.main.arn
  port              = "80"
  protocol          = "HTTP"
  
  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.app.arn
  }
}

# HTTPS 리스너 (인증서 있을 경우)
resource "aws_lb_listener" "https" {
  count             = var.certificate_arn != "" ? 1 : 0
  load_balancer_arn = aws_lb.main.arn
  port              = "443"
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-TLS-1-2-2017-01"
  certificate_arn   = var.certificate_arn
  
  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.app.arn
  }
}

# Launch Template
resource "aws_launch_template" "app" {
  name_prefix   = "${var.project_name}-lt-"
  image_id      = var.ami_id
  instance_type = var.instance_type
  
  vpc_security_group_ids = [aws_security_group.app.id]
  
  iam_instance_profile {
    name = aws_iam_instance_profile.app.name
  }
  
  user_data = base64encode(templatefile("${path.module}/user_data.sh", {
    environment = var.environment
    app_name    = var.project_name
  }))
  
  block_device_mappings {
    device_name = "/dev/xvda"
    
    ebs {
      volume_size           = 20
      volume_type           = "gp3"
      delete_on_termination = true
      encrypted             = true
    }
  }
  
  monitoring {
    enabled = true
  }
  
  tag_specifications {
    resource_type = "instance"
    
    tags = {
      Name        = "${var.project_name}-instance"
      Environment = var.environment
    }
  }
}

# Auto Scaling Group
resource "aws_autoscaling_group" "app" {
  name                = "${var.project_name}-asg"
  vpc_zone_identifier = var.private_subnet_ids
  target_group_arns   = [aws_lb_target_group.app.arn]
  health_check_type   = "ELB"
  health_check_grace_period = 300
  
  min_size         = var.asg_min_size
  max_size         = var.asg_max_size
  desired_capacity = var.asg_desired_capacity
  
  launch_template {
    id      = aws_launch_template.app.id
    version = "$Latest"
  }
  
  tag {
    key                 = "Name"
    value               = "${var.project_name}-asg-instance"
    propagate_at_launch = true
  }
  
  tag {
    key                 = "Environment"
    value               = var.environment
    propagate_at_launch = true
  }
}

# Auto Scaling 정책 - CPU 기반
resource "aws_autoscaling_policy" "cpu_scale_up" {
  name                   = "${var.project_name}-cpu-scale-up"
  scaling_adjustment     = 1
  adjustment_type        = "ChangeInCapacity"
  cooldown               = 300
  autoscaling_group_name = aws_autoscaling_group.app.name
}

resource "aws_autoscaling_policy" "cpu_scale_down" {
  name                   = "${var.project_name}-cpu-scale-down"
  scaling_adjustment     = -1
  adjustment_type        = "ChangeInCapacity"
  cooldown               = 300
  autoscaling_group_name = aws_autoscaling_group.app.name
}

# CloudWatch 알람 - CPU 높음
resource "aws_cloudwatch_metric_alarm" "cpu_high" {
  alarm_name          = "${var.project_name}-cpu-high"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = "2"
  metric_name         = "CPUUtilization"
  namespace           = "AWS/EC2"
  period              = "120"
  statistic           = "Average"
  threshold           = "80"
  
  dimensions = {
    AutoScalingGroupName = aws_autoscaling_group.app.name
  }
  
  alarm_actions = [aws_autoscaling_policy.cpu_scale_up.arn]
}

# CloudWatch 알람 - CPU 낮음
resource "aws_cloudwatch_metric_alarm" "cpu_low" {
  alarm_name          = "${var.project_name}-cpu-low"
  comparison_operator = "LessThanThreshold"
  evaluation_periods  = "2"
  metric_name         = "CPUUtilization"
  namespace           = "AWS/EC2"
  period              = "120"
  statistic           = "Average"
  threshold           = "20"
  
  dimensions = {
    AutoScalingGroupName = aws_autoscaling_group.app.name
  }
  
  alarm_actions = [aws_autoscaling_policy.cpu_scale_down.arn]
}

# Security Group - ALB
resource "aws_security_group" "alb" {
  name        = "${var.project_name}-alb-sg"
  description = "Security group for ALB"
  vpc_id      = var.vpc_id
  
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
  
  tags = {
    Name = "${var.project_name}-alb-sg"
  }
}

# Security Group - Application
resource "aws_security_group" "app" {
  name        = "${var.project_name}-app-sg"
  description = "Security group for application instances"
  vpc_id      = var.vpc_id
  
  ingress {
    from_port       = 80
    to_port         = 80
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
  }
  
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
  
  tags = {
    Name = "${var.project_name}-app-sg"
  }
}

🗄️ 3. Database 모듈

modules/database/main.tf

# RDS 서브넷 그룹
resource "aws_db_subnet_group" "main" {
  name       = "${var.project_name}-db-subnet-group"
  subnet_ids = var.database_subnet_ids
  
  tags = {
    Name = "${var.project_name}-db-subnet-group"
  }
}

# RDS 인스턴스
resource "aws_db_instance" "main" {
  identifier     = "${var.project_name}-db"
  engine         = "postgres"
  engine_version = "14.7"
  instance_class = var.db_instance_class
  
  allocated_storage     = var.db_allocated_storage
  max_allocated_storage = var.db_max_allocated_storage
  storage_type          = "gp3"
  storage_encrypted     = true
  
  db_name  = var.db_name
  username = var.db_username
  password = var.db_password  # 실제로는 AWS Secrets Manager 사용 권장!
  
  db_subnet_group_name   = aws_db_subnet_group.main.name
  vpc_security_group_ids = [aws_security_group.rds.id]
  
  multi_az               = var.environment == "production" ? true : false
  backup_retention_period = var.environment == "production" ? 7 : 1
  backup_window          = "03:00-04:00"
  maintenance_window     = "mon:04:00-mon:05:00"
  
  enabled_cloudwatch_logs_exports = ["postgresql", "upgrade"]
  
  skip_final_snapshot       = var.environment != "production"
  final_snapshot_identifier = var.environment == "production" ? "${var.project_name}-final-snapshot-${formatdate("YYYY-MM-DD-hhmm", timestamp())}" : null
  
  tags = {
    Name        = "${var.project_name}-db"
    Environment = var.environment
  }
}

# RDS 읽기 전용 복제본 (프로덕션만)
resource "aws_db_instance" "read_replica" {
  count              = var.environment == "production" ? 1 : 0
  identifier         = "${var.project_name}-db-replica"
  replicate_source_db = aws_db_instance.main.identifier
  instance_class     = var.db_instance_class
  
  skip_final_snapshot = true
  
  tags = {
    Name        = "${var.project_name}-db-replica"
    Environment = var.environment
  }
}

# ElastiCache 서브넷 그룹
resource "aws_elasticache_subnet_group" "main" {
  name       = "${var.project_name}-cache-subnet-group"
  subnet_ids = var.database_subnet_ids
}

# ElastiCache Redis 클러스터
resource "aws_elasticache_replication_group" "main" {
  replication_group_id       = "${var.project_name}-redis"
  replication_group_description = "Redis cluster for ${var.project_name}"
  
  engine               = "redis"
  engine_version       = "7.0"
  node_type            = var.redis_node_type
  num_cache_clusters   = var.environment == "production" ? 2 : 1
  
  port                 = 6379
  parameter_group_name = "default.redis7"
  subnet_group_name    = aws_elasticache_subnet_group.main.name
  security_group_ids   = [aws_security_group.redis.id]
  
  at_rest_encryption_enabled = true
  transit_encryption_enabled = true
  auth_token                 = var.redis_auth_token
  
  automatic_failover_enabled = var.environment == "production" ? true : false
  multi_az_enabled          = var.environment == "production" ? true : false
  
  snapshot_retention_limit = var.environment == "production" ? 5 : 0
  snapshot_window         = "03:00-05:00"
  
  tags = {
    Name        = "${var.project_name}-redis"
    Environment = var.environment
  }
}

# Security Group - RDS
resource "aws_security_group" "rds" {
  name        = "${var.project_name}-rds-sg"
  description = "Security group for RDS"
  vpc_id      = var.vpc_id
  
  ingress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [var.app_security_group_id]
  }
  
  tags = {
    Name = "${var.project_name}-rds-sg"
  }
}

# Security Group - Redis
resource "aws_security_group" "redis" {
  name        = "${var.project_name}-redis-sg"
  description = "Security group for Redis"
  vpc_id      = var.vpc_id
  
  ingress {
    from_port       = 6379
    to_port         = 6379
    protocol        = "tcp"
    security_groups = [var.app_security_group_id]
  }
  
  tags = {
    Name = "${var.project_name}-redis-sg"
  }
}

💡 보안 팁: 실제 프로덕션 환경에서는 데이터베이스 비밀번호를 코드에 직접 넣지 말고, AWS Secrets Manager나 Parameter Store를 사용해야 해! 그리고 Terraform State 파일도 암호화된 S3에 저장하는 거 잊지 마! 🔐

🌍 4. 메인 설정 파일

main.tf

terraform {
  required_version = ">= 1.5.0"
  
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = var.aws_region
  
  default_tags {
    tags = {
      Project     = var.project_name
      Environment = var.environment
      ManagedBy   = "Terraform"
    }
  }
}

# Networking 모듈
module "networking" {
  source = "./modules/networking"
  
  project_name       = var.project_name
  environment        = var.environment
  vpc_cidr           = var.vpc_cidr
  availability_zones = var.availability_zones
}

# Compute 모듈
module "compute" {
  source = "./modules/compute"
  
  project_name        = var.project_name
  environment         = var.environment
  vpc_id              = module.networking.vpc_id
  public_subnet_ids   = module.networking.public_subnet_ids
  private_subnet_ids  = module.networking.private_subnet_ids
  
  ami_id              = var.ami_id
  instance_type       = var.instance_type
  asg_min_size        = var.asg_min_size
  asg_max_size        = var.asg_max_size
  asg_desired_capacity = var.asg_desired_capacity
  certificate_arn     = var.certificate_arn
}

# Database 모듈
module "database" {
  source = "./modules/database"
  
  project_name           = var.project_name
  environment            = var.environment
  vpc_id                 = module.networking.vpc_id
  database_subnet_ids    = module.networking.database_subnet_ids
  app_security_group_id  = module.compute.app_security_group_id
  
  db_instance_class      = var.db_instance_class
  db_allocated_storage   = var.db_allocated_storage
  db_max_allocated_storage = var.db_max_allocated_storage
  db_name                = var.db_name
  db_username            = var.db_username
  db_password            = var.db_password
  
  redis_node_type        = var.redis_node_type
  redis_auth_token       = var.redis_auth_token
}

📊 5. 환경별 변수 설정

environments/production/terraform.tfvars

# 프로젝트 설정
project_name = "myapp"
environment  = "production"
aws_region   = "ap-northeast-2"

# 네트워크 설정
vpc_cidr           = "10.0.0.0/16"
availability_zones = ["ap-northeast-2a", "ap-northeast-2c"]

# Compute 설정
ami_id               = "ami-0c55b159cbfafe1f0"  # Amazon Linux 2
instance_type        = "t3.medium"
asg_min_size         = 2
asg_max_size         = 10
asg_desired_capacity = 4

# Database 설정
db_instance_class        = "db.t3.medium"
db_allocated_storage     = 100
db_max_allocated_storage = 500
db_name                  = "myapp_prod"
db_username              = "admin"
# db_password는 환경변수나 Secrets Manager에서 가져오기!

# Redis 설정
redis_node_type = "cache.t3.medium"

# SSL 인증서
certificate_arn = "arn:aws:acm:ap-northeast-2:123456789012:certificate/xxxxx"

environments/dev/terraform.tfvars

# 프로젝트 설정
project_name = "myapp"
environment  = "dev"
aws_region   = "ap-northeast-2"

# 네트워크 설정
vpc_cidr           = "10.1.0.0/16"
availability_zones = ["ap-northeast-2a"]  # 개발은 단일 AZ

# Compute 설정
ami_id               = "ami-0c55b159cbfafe1f0"
instance_type        = "t3.small"  # 개발은 작은 인스턴스
asg_min_size         = 1
asg_max_size         = 2
asg_desired_capacity = 1

# Database 설정
db_instance_class        = "db.t3.small"
db_allocated_storage     = 20
db_max_allocated_storage = 50
db_name                  = "myapp_dev"
db_username              = "admin"

# Redis 설정
redis_node_type = "cache.t3.micro"

# SSL 인증서 (개발은 없을 수도)
certificate_arn = ""

💡 비용 최적화 팁: - 개발/스테이징 환경은 작은 인스턴스 타입 사용
- Multi-AZ는 프로덕션에만 적용
- 개발 환경은 업무 시간 외에는 자동으로 중지
- Reserved Instance나 Savings Plan 활용
- 불필요한 리소스는 즉시 삭제 (terraform destroy)

이렇게 하면 클라우드 비용을 50% 이상 절감할 수 있어! 💰

🛡️ 보안과 베스트 프랙티스

Terraform과 CI/CD를 사용할 때 보안은 정말 중요해! 한 번의 실수로 회사의 모든 인프라가 노출될 수 있거든. 😱 실전에서 꼭 지켜야 할 보안 원칙들을 알아보자!

🔐 1. 민감한 정보 관리

❌ 절대 하지 말아야 할 것들: - 비밀번호, API 키를 코드에 직접 작성
- State 파일을 Git에 커밋
- AWS Access Key를 코드에 하드코딩
- 프로덕션 자격증명을 개발자 로컬에 저장

✅ 올바른 방법:

AWS Secrets Manager 사용:

# Secrets Manager에서 비밀번호 가져오기
data "aws_secretsmanager_secret_version" "db_password" {
  secret_id = "prod/database/password"
}

resource "aws_db_instance" "main" {
  # ... 다른 설정들 ...
  password = data.aws_secretsmanager_secret_version.db_password.secret_string
}

환경 변수 사용:

# GitHub Actions에서
env:
  TF_VAR_db_password: ${{ secrets.DB_PASSWORD }}
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

OIDC를 통한 인증 (추천!):

# GitHub Actions에서 OIDC 사용
- name: Configure AWS Credentials
  uses: aws-actions/configure-aws-credentials@v2
  with:
    role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
    aws-region: ap-northeast-2
    # Access Key 없이 안전하게 인증!

🔍 2. 보안 스캔 자동화

코드를 배포하기 전에 자동으로 보안 취약점을 검사해야 해!

tfsec - Terraform 보안 스캐너:

# GitHub Actions에 추가
- name: Run tfsec
  uses: aquasecurity/tfsec-action@v1.0.0
  with:
    soft_fail: false  # 보안 이슈 발견 시 빌드 실패

Checkov - 정책 기반 스캐너:

- name: Run Checkov
  uses: bridgecrewio/checkov-action@master
  with:
    directory: .
    framework: terraform

주요 검사 항목들:
✅ 암호화되지 않은 스토리지
✅ 공개된 보안 그룹
✅ 로깅이 비활성화된 리소스
✅ 취약한 암호화 알고리즘
✅ 과도한 IAM 권한

🎯 3. 최소 권한 원칙 (Least Privilege)

IAM 역할과 정책은 필요한 최소한의 권한만 부여해야 해!

❌ 나쁜 예:

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}
# 모든 권한 부여 - 절대 금지!

✅ 좋은 예:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeImages",
        "ec2:DescribeKeyPairs",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeSubnets",
        "ec2:DescribeVpcs"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:RunInstances",
        "ec2:TerminateInstances"
      ],
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "ap-northeast-2"
        }
      }
    }
  ]
}
# 필요한 권한만 명시적으로 부여

📝 4. 코드 리뷰 프로세스

모든 인프라 변경은 반드시 코드 리뷰를 거쳐야 해!

리뷰 체크리스트:

항목	확인 사항
보안	민감한 정보 노출 여부, 보안 그룹 설정, 암호화 적용
비용	예상 비용 증가, 불필요한 리소스, 인스턴스 타입 적정성
가용성	Multi-AZ 설정, 백업 정책, 장애 복구 계획
성능	리소스 크기 적정성, Auto Scaling 설정, 캐싱 전략
규칙 준수	네이밍 컨벤션, 태그 정책, 문서화

💡 자동화 팁: GitHub의 CODEOWNERS 파일을 사용하면 특정 디렉토리의 변경사항에 대해 자동으로 리뷰어를 지정할 수 있어!

# CODEOWNERS
/environments/production/ @senior-devops @team-lead
/modules/database/ @database-admin @senior-devops
*.tf @devops-team

🔄 5. State 파일 보안

State 파일에는 모든 인프라 정보가 들어있어서 정말 중요해!

필수 보안 설정:

# backend.tf
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "production/terraform.tfstate"
    region         = "ap-northeast-2"
    
    # 암호화 필수!
    encrypt        = true
    kms_key_id     = "arn:aws:kms:ap-northeast-2:123456789012:key/xxxxx"
    
    # State Lock으로 동시 수정 방지
    dynamodb_table = "terraform-lock"
    
    # 버전 관리로 롤백 가능
    versioning     = true
  }
}

# S3 버킷 보안 설정
resource "aws_s3_bucket_public_access_block" "terraform_state" {
  bucket = aws_s3_bucket.terraform_state.id
  
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

# 버킷 정책 - 특정 역할만 접근 가능
resource "aws_s3_bucket_policy" "terraform_state" {
  bucket = aws_s3_bucket.terraform_state.id
  
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Deny"
        Principal = "*"
        Action = "s3:*"
        Resource = [
          aws_s3_bucket.terraform_state.arn,
          "${aws_s3_bucket.terraform_state.arn}/*"
        ]
        Condition = {
          Bool = {
            "aws:SecureTransport" = "false"
          }
        }
      }
    ]
  })
}

📊 6. 모니터링과 알림

배포 후에도 계속 모니터링해야 해!

CloudWatch 알람 설정:

resource "aws_cloudwatch_metric_alarm" "unauthorized_api_calls" {
  alarm_name          = "UnauthorizedAPICalls"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = "1"
  metric_name         = "UnauthorizedAPICalls"
  namespace           = "AWS/CloudTrail"
  period              = "300"
  statistic           = "Sum"
  threshold           = "5"
  alarm_description   = "무단 API 호출 감지"
  
  alarm_actions = [aws_sns_topic.security_alerts.arn]
}

resource "aws_cloudwatch_metric_alarm" "root_account_usage" {
  alarm_name          = "RootAccountUsage"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = "1"
  metric_name         = "RootAccountUsage"
  namespace           = "AWS/CloudTrail"
  period              = "60"
  statistic           = "Sum"
  threshold           = "0"
  alarm_description   = "루트 계정 사용 감지"
  
  alarm_actions = [aws_sns_topic.security_alerts.arn]
}

SNS 토픽으로 알림:

resource "aws_sns_topic" "security_alerts" {
  name = "security-alerts"
}

resource "aws_sns_topic_subscription" "security_email" {
  topic_arn = aws_sns_topic.security_alerts.arn
  protocol  = "email"
  endpoint  = "security-team@company.com"
}

resource "aws_sns_topic_subscription" "security_slack" {
  topic_arn = aws_sns_topic.security_alerts.arn
  protocol  = "https"
  endpoint  = "https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
}

🎓 7. 팀 교육과 문서화

아무리 좋은 도구와 프로세스가 있어도, 팀원들이 제대로 이해하지 못하면 소용없어!

필수 문서들:
✅ 아키텍처 다이어그램
✅ Terraform 모듈 사용 가이드
✅ CI/CD 파이프라인 설명
✅ 트러블슈팅 가이드
✅ 긴급 상황 대응 매뉴얼
✅ 보안 정책 및 체크리스트

💡 재능넷 활용 팁: Terraform이나 DevOps 관련 지식을 팀원들과 공유하고 싶다면, 재능넷에서 전문가를 초청해서 사내 교육을 진행하는 것도 좋은 방법이야! 실무 경험이 풍부한 전문가에게 직접 배우면 훨씬 효과적이거든. 🎯

🚨 트러블슈팅: 자주 만나는 문제들

Terraform과 CI/CD를 사용하다 보면 여러 가지 문제를 만나게 돼. 내가 실제로 겪었던 문제들과 해결 방법을 공유할게! 😊

❌ 문제 1: State Lock 걸림

증상:

Error: Error acquiring the state lock

Error message: ConditionalCheckFailedException: The conditional request failed
Lock Info:
  ID:        a1b2c3d4-e5f6-7890-abcd-ef1234567890
  Path:      my-bucket/terraform.tfstate
  Operation: OperationTypeApply
  Who:       user@hostname
  Version:   1.5.0
  Created:   2024-01-15 10:30:00 UTC

원인:
- 이전 Terraform 실행이 비정상 종료됨
- 다른 사람이 동시에 실행 중
- CI/CD 파이프라인이 중복 실행됨

해결 방법:

# 1. 먼저 정말로 다른 사람이 실행 중인지 확인!
# 팀원들에게 물어보기

# 2. 확실히 아무도 실행 중이 아니라면 Lock 강제 해제
$ terraform force-unlock a1b2c3d4-e5f6-7890-abcd-ef1234567890

# 3. DynamoDB에서 직접 확인
$ aws dynamodb get-item \
    --table-name terraform-lock \
    --key '{"LockID": {"S": "my-bucket/terraform.tfstate"}}'

⚠️ 주의: force-unlock은 정말 확실할 때만 사용해! 다른 사람이 실행 중인데 강제로 해제하면 State 파일이 꼬일 수 있어!

❌ 문제 2: State Drift (상태 불일치)

증상:
누군가 AWS 콘솔에서 직접 리소스를 수정해서, Terraform State와 실제 인프라가 달라짐.

감지 방법:

$ terraform plan

# 출력:
Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the
last "terraform apply":

  # aws_instance.web_server has changed
  ~ resource "aws_instance" "web_server" {
        id                    = "i-0123456789abcdef"
      ~ instance_type         = "t2.micro" -> "t2.small"
        # (10 unchanged attributes hidden)
    }

해결 방법:

# 방법 1: Terraform 코드를 실제 상태에 맞춤
# main.tf를 수정해서 instance_type = "t2.small"로 변경

# 방법 2: 실제 인프라를 Terraform 코드에 맞춤
$ terraform apply
# 다시 t2.micro로 변경됨

# 방법 3: State를 실제 상태로 업데이트 (권장하지 않음)
$ terraform refresh

💡 예방 방법: - AWS Config Rules로 수동 변경 감지
- CloudTrail로 모든 변경사항 로깅
- 팀 규칙: 모든 변경은 Terraform을 통해서만!
- 프로덕션 환경은 콘솔 접근 제한

❌ 문제 3: 순환 의존성 (Circular Dependency)

증상:

Error: Cycle: aws_security_group.app, aws_security_group.db

원인:
두 리소스가 서로를 참조하고 있음.

# 잘못된 예
resource "aws_security_group" "app" {
  # ...
  egress {
    security_groups = [aws_security_group.db.id]
  }
}

resource "aws_security_group" "db" {
  # ...
  ingress {
    security_groups = [aws_security_group.app.id]
  }
}

해결 방법:

# 올바른 방법: Security Group Rule을 별도로 분리
resource "aws_security_group" "app" {
  name = "app-sg"
  # egress 규칙 제거
}

resource "aws_security_group" "db" {
  name = "db-sg"
  # ingress 규칙 제거
}

# 별도의 규칙으로 정의
resource "aws_security_group_rule" "app_to_db" {
  type                     = "egress"
  from_port                = 5432
  to_port                  = 5432
  protocol                 = "tcp"
  security_group_id        = aws_security_group.app.id
  source_security_group_id = aws_security_group.db.id
}

resource "aws_security_group_rule" "db_from_app" {
  type                     = "ingress"
  from_port                = 5432
  to_port                  = 5432
  protocol                 = "tcp"
  security_group_id        = aws_security_group.db.id
  source_security_group_id = aws_security_group.app.id
}

❌ 문제 4: Provider 버전 충돌

증상:

Error: Failed to query available provider packages

Could not retrieve the list of available versions for provider
hashicorp/aws: locked provider registry.terraform.io/hashicorp/aws 4.0.0
does not match configured version constraint ~> 5.0

해결 방법:

# 1. .terraform.lock.hcl 파일 삭제
$ rm .terraform.lock.hcl

# 2. .terraform 디렉토리 삭제
$ rm -rf .terraform

# 3. 다시 초기화
$ terraform init -upgrade

# 4. 새로운 lock 파일 생성됨

💡 버전 관리 팁: - versions.tf 파일에 명시적으로 버전 지정
- .terraform.lock.hcl은 Git에 커밋
- 팀 전체가 같은 Terraform 버전 사용
- 메이저 버전 업그레이드는 신중하게!

❌ 문제 5: 리소스 삭제 실패

증상:

Error: Error deleting VPC: DependencyViolation: The vpc 'vpc-xxxxx' has
dependencies and cannot be deleted.

원인:
VPC 안에 다른 리소스들이 남아있음 (ENI, NAT Gateway 등)

해결 방법:

# 1. 의존성 확인
$ terraform state list

# 2. 의존성 그래프 확인
$ terraform graph | dot -Tpng > graph.png

# 3. 수동으로 리소스 정리
$ aws ec2 describe-network-interfaces --filters "Name=vpc-id,Values=vpc-xxxxx"

# 4. Terraform으로 다시 시도
$ terraform destroy -target=aws_vpc.main

# 5. 그래도 안 되면 State에서 제거하고 수동 삭제
$ terraform state rm aws_vpc.main
$ aws ec2 delete-vpc --vpc-id vpc-xxxxx

⚠️ 주의: terraform state rm은 최후의 수단! State에서만 제거되고 실제 리소스는 남아있어서, 나중에 문제가 될 수 있어.

❌ 문제 6: CI/CD 파이프라인 실패

증상:
GitHub Actions에서 Terraform apply가 실패함.

주요 원인들:

1. AWS 자격증명 문제

# 해결: GitHub Secrets 확인
Settings → Secrets and variables → Actions
- AWS_ACCESS_KEY_ID
- AWS_SECRET_ACCESS_KEY
- AWS_REGION

2. 권한 부족

# IAM 정책 확인
$ aws iam get-role-policy \
    --role-name GitHubActionsRole \
    --policy-name TerraformPolicy

3. 타임아웃

# GitHub Actions에서 타임아웃 늘리기
jobs:
  terraform:
    timeout-minutes: 60  # 기본값은 360분

4. 동시 실행

# 동시 실행 방지
concurrency:
  group: terraform-${{ github.ref }}
  cancel-in-progress: false  # 진행 중인 작업 취소하지 않음

💰 비용 최적화 전략

클라우드 인프라를 자동화하면 편하지만, 방심하면 비용이 폭탄처럼 나올 수 있어! 💣 실전에서 사용하는 비용 최적화 전략들을 공유할게.

📊 1. Infracost로 비용 예측

Terraform 코드를 실행하기 전에 예상 비용을 미리 확인할 수 있어!

GitHub Actions에 통합:

- name: Setup Infracost
  uses: infracost/actions/setup@v2
  with:
    api-key: ${{ secrets.INFRACOST_API_KEY }}

- name: Generate Infracost JSON
  run: |
    infracost breakdown --path . \
      --format json \
      --out-file /tmp/infracost.json

- name: Post Infracost comment
  uses: infracost/actions/comment@v1
  with:
    path: /tmp/infracost.json
    behavior: update

PR에 자동으로 비용 정보 표시:

💰 Monthly cost estimate

  Name                     Monthly Qty  Unit   Monthly Cost
  
  aws_instance.web_server
  ├─ Instance usage               730  hours        $8.47
  └─ root_block_device
     └─ Storage                    20  GB           $2.00
  
  aws_rds_instance.main
  ├─ Database instance            730  hours       $73.00
  └─ Storage                      100  GB          $11.50
  
  OVERALL TOTAL                                    $94.97
  
  ──────────────────────────────────
  
  💸 Change from current: +$94.97 (+100%)

💡 비용 알림 설정: 예상 비용이 일정 금액을 초과하면 자동으로 승인을 요구하도록 설정할 수 있어!

⏰ 2. 스케줄링으로 비용 절감

개발/스테이징 환경은 업무 시간에만 켜두고, 밤에는 자동으로 꺼버리자!

Lambda + EventBridge로 자동화:

# lambda_scheduler.tf
resource "aws_lambda_function" "instance_scheduler" {
  filename      = "scheduler.zip"
  function_name = "instance-scheduler"
  role          = aws_iam_role.lambda_scheduler.arn
  handler       = "index.handler"
  runtime       = "python3.9"
  
  environment {
    variables = {
      ENVIRONMENT = var.environment
    }
  }
}

# 평일 오전 9시에 시작
resource "aws_cloudwatch_event_rule" "start_instances" {
  name                = "start-instances"
  schedule_expression = "cron(0 0 * * MON-FRI *)"  # UTC 기준
}

resource "aws_cloudwatch_event_target" "start_instances" {
  rule      = aws_cloudwatch_event_rule.start_instances.name
  target_id = "StartInstances"
  arn       = aws_lambda_function.instance_scheduler.arn
  input     = jsonencode({
    action = "start"
  })
}

# 평일 오후 7시에 중지
resource "aws_cloudwatch_event_rule" "stop_instances" {
  name                = "stop-instances"
  schedule_expression = "cron(0 10 * * MON-FRI *)"  # UTC 기준
}

resource "aws_cloudwatch_event_target" "stop_instances" {
  rule      = aws_cloudwatch_event_rule.stop_instances.name
  target_id = "StopInstances"
  arn       = aws_lambda_function.instance_scheduler.arn
  input     = jsonencode({
    action = "stop"
  })
}

예상 절감액:
- 하루 10시간만 운영 (업무 시간)
- 주말 완전 중지
- 월 730시간 → 약 220시간 (70% 절감!)
- EC2 t3.medium 기준: $30/월 → $9/월 💰

🎯 3. 적절한 인스턴스 타입 선택

환경	추천 인스턴스	이유
개발	t3.micro ~ t3.small	버스트 가능, 저렴, 개발에 충분
스테이징	t3.medium	프로덕션과 유사한 환경 테스트
프로덕션	c5.large 이상	안정적인 성능, 예측 가능
배치 작업	Spot Instance	최대 90% 할인!

Spot Instance 활용:

resource "aws_spot_instance_request" "batch_worker" {
  ami           = var.ami_id
  instance_type = "c5.xlarge"
  spot_price    = "0.05"  # 최대 지불 가격
  
  wait_for_fulfillment = true
  spot_type            = "one-time"
  
  tags = {
    Name = "batch-worker"
  }
}

# Spot Instance는 중단될 수 있으니 중요한 작업은 피하기!

💾 4. 스토리지 최적화

EBS 볼륨 타입 선택:

resource "aws_ebs_volume" "data" {
  availability_zone = "ap-northeast-2a"
  
  # gp3가 gp2보다 20% 저렴하고 성능도 좋아!
  type = "gp3"
  size = 100
  
  # IOPS와 처리량을 필요한 만큼만 설정
  iops       = 3000  # 기본값
  throughput = 125   # 기본값
  
  tags = {
    Name = "data-volume"
  }
}

S3 Lifecycle 정책:

resource "aws_s3_bucket_lifecycle_configuration" "logs" {
  bucket = aws_s3_bucket.logs.id
  
  rule {
    id     = "archive-old-logs"
    status = "Enabled"
    
    # 30일 후 Glacier로 이동
    transition {
      days          = 30
      storage_class = "GLACIER"
    }
    
    # 90일 후 삭제
    expiration {
      days = 90
    }
  }
  
  rule {
    id     = "delete-incomplete-uploads"
    status = "Enabled"
    
    abort_incomplete_multipart_upload {
      days_after_initiation = 7
    }
  }
}

예상 절감액:
- S3 Standard: $0.025/GB
- S3 Glacier: $0.004/GB (84% 절감!)
- 1TB 로그 데이터 기준: $25/월 → $4/월 💰

🔍 5. 사용하지 않는 리소스 찾기

AWS Cost Explorer로 분석:

# Terraform으로 Cost Explorer 활성화
resource "aws_ce_cost_category" "environment" {
  name         = "Environment"
  rule_version = "CostCategoryExpression.v1"
  
  rule {
    value = "Production"
    rule {
      dimension {
        key           = "TAG"
        values        = ["production"]
        match_options = ["EQUALS"]
      }
    }
  }
  
  rule {
    value = "Development"
    rule {
      dimension {
        key           = "TAG"
        values        = ["dev", "development"]
        match_options = ["EQUALS"]
      }
    }
  }
}

정기적으로 확인할 것들:
✅ 연결되지 않은 EBS 볼륨
✅ 사용하지 않는 Elastic IP
✅ 오래된 스냅샷
✅ 트래픽 없는 Load Balancer
✅ 빈 S3 버킷
✅ 사용하지 않는 NAT Gateway

🎉 실제 사례: 한 스타트업에서 이런 최적화를 통해 월 $3,000 → $1,200으로 60% 절감했어! 특히 개발 환경 스케줄링과 Spot Instance 활용이 큰 효과를 봤지. 💪

🎓 학습 로드맵과 다음 단계

여기까지 읽었다면 정말 대단해! 👏 이제 Terraform과 CI/CD의 기본은 마스터했어. 하지만 DevOps의 세계는 정말 넓고 깊어. 다음 단계로 나아가기 위한 로드맵을 알려줄게!

📚 초급 → 중급 (지금 당신의 위치!)

✅ 이미 배운 것들:
- Terraform 기본 문법과 워크플로우
- 주요 리소스 타입 (VPC, EC2, RDS 등)
- State 관리와 Remote Backend
- GitHub Actions를 통한 CI/CD
- 기본적인 보안 설정

🎯 다음 학습 목표:
1. Terraform 모듈 고급 활용
- 재사용 가능한 모듈 설계
- 모듈 버전 관리
- Terraform Registry 활용

2. 다양한 Provider 경험
- Kubernetes Provider
- Helm Provider
- Datadog, PagerDuty 등 모니터링 도구

3. 고급 State 관리
- Workspace 활용
- State 마이그레이션
- State 백업 및 복구

4. 테스트 자동화
- Terratest로 인프라 테스트
- Kitchen-Terraform
- Compliance 테스트

🚀 중급 → 고급

1. GitOps 완전 정복

# ArgoCD + Terraform
resource "kubernetes_namespace" "argocd" {
  metadata {
    name = "argocd"
  }
}

resource "helm_release" "argocd" {
  name       = "argocd"
  repository = "https://argoproj.github.io/argo-helm"
  chart      = "argo-cd"
  namespace  = kubernetes_namespace.argocd.metadata[0].name
  
  set {
    name  = "server.service.type"
    value = "LoadBalancer"
  }
}

2. Multi-Cloud 전략
- AWS + GCP 동시 관리
- Cloud-agnostic 아키텍처 설계
- 클라우드 간 데이터 동기화

3. 대규모 인프라 관리
- Terraform Cloud/Enterprise
- Sentinel 정책 관리
- Cost Estimation & Governance
- Private Module Registry

4. 고급 보안
- Vault를 통한 시크릿 관리
- OPA (Open Policy Agent) 통합
- Compliance as Code
- Zero Trust 아키텍처

🛠️ 실전 프로젝트 아이디어

프로젝트 1: 개인 블로그 인프라
- CloudFront + S3로 정적 사이트
- Route53으로 커스텀 도메인
- ACM으로 SSL 인증서
- GitHub Actions로 자동 배포
- 예상 비용: 월 $5 이하

프로젝트 2: 마이크로서비스 플랫폼
- EKS 클러스터 구축
- Service Mesh (Istio)
- 중앙화된 로깅 (ELK Stack)
- 분산 추적 (Jaeger)
- 예상 비용: 월 $200-500

프로젝트 3: 데이터 파이프라인
- Airflow on ECS
- Redshift 데이터 웨어하우스
- Glue ETL 작업
- QuickSight 대시보드
- 예상 비용: 월 $300-800

💡 프로젝트 팁: 작은 프로젝트부터 시작해서 점점 복잡하게 만들어가는 게 좋아. 그리고 모든 코드를 GitHub에 올려서 포트폴리오로 활용하자! 재능넷에서 DevOps 멘토링을 제공할 때도 이런 프로젝트 경험이 큰 도움이 돼. 🎯

📖 추천 학습 자료

공식 문서:
- Terraform Documentation (terraform.io/docs)
- AWS Well-Architected Framework
- Kubernetes Documentation

온라인 강의:
- HashiCorp Learn (learn.hashicorp.com)
- A Cloud Guru
- Udemy의 Terraform 강의들

커뮤니티:
- Terraform Community Forum
- Reddit r/Terraform
- DevOps Korea 커뮤니티
- 재능넷의 DevOps 전문가들

책:
- "Terraform: Up & Running" by Yevgeniy Brikman
- "Infrastructure as Code" by Kief Morris
- "The DevOps Handbook"

🎓 자격증 추천: - HashiCorp Certified: Terraform Associate
- AWS Certified DevOps Engineer
- Certified Kubernetes Administrator (CKA)

이런 자격증들은 취업이나 이직할 때 정말 도움이 돼!

🤝 커뮤니티 참여하기

혼자 공부하는 것도 좋지만, 커뮤니티에 참여하면 훨씬 빠르게 성장할 수 있어!

오픈소스 기여:
- Terraform Provider 버그 리포트
- 문서 개선 PR
- 커뮤니티 모듈 개발

지식 공유:
- 기술 블로그 작성
- 컨퍼런스 발표
- 재능넷에서 멘토링 제공
- YouTube 튜토리얼 제작

💡 재능넷 활용하기: Terraform이나 DevOps 관련 지식을 재능넷에서 공유해보는 건 어때? 다른 사람을 가르치다 보면 자신의 지식도 더 단단해지고, 부수입도 생기고, 네트워킹도 할 수 있어서 일석삼조야! 🎯

🎬 마무리하며

와! 여기까지 정말 긴 여정이었어. 🎉 Terraform과 CI/CD를 활용한 클라우드 인프라 자동화에 대해 정말 많은 걸 배웠지?

✨ 핵심 요약

1. Infrastructure as Code의 힘
- 코드로 인프라를 관리하면 일관성, 재현성, 버전 관리가 가능해
- Terraform은 선언적 문법으로 쉽게 배울 수 있어
- 멀티 클라우드 지원으로 벤더 종속성 없음

2. CI/CD 통합의 중요성
- 자동화된 테스트와 배포로 휴먼 에러 방지
- Pull Request 기반 워크플로우로 협업 강화
- GitOps로 모든 변경사항 추적 가능

3. 보안은 선택이 아닌 필수
- 민감한 정보는 절대 코드에 넣지 말기
- State 파일 암호화와 접근 제어
- 자동화된 보안 스캔 도구 활용

4. 비용 최적화
- 환경별로 적절한 리소스 크기 선택
- 스케줄링으로 불필요한 비용 절감
- Infracost로 사전에 비용 예측

5. 지속적인 학습
- DevOps는 끊임없이 진화하는 분야
- 커뮤니티 참여와 지식 공유
- 실전 프로젝트로 경험 쌓기

🚀 당신의 다음 액션 플랜

오늘 당장 시작할 수 있는 것들:

1단계: 환경 설정 (30분)
- Terraform 설치
- AWS CLI 설정
- GitHub 저장소 생성

2단계: 첫 프로젝트 (2-3시간)
- S3 버킷 하나 만들어보기
- Terraform 워크플로우 익히기
- GitHub Actions 연동

3단계: 실전 적용 (1주일)
- 회사/개인 프로젝트에 적용
- 팀원들과 지식 공유
- 문제 해결 경험 쌓기

4단계: 심화 학습 (지속적)
- 고급 기능 학습
- 커뮤니티 참여
- 자격증 취득 고려

💬 마지막 한마디

DevOps와 인프라 자동화는 처음에는 어렵게 느껴질 수 있어. 하지만 한 번 익숙해지면, 이전으로는 절대 돌아갈 수 없을 거야! 😊

수동으로 서버를 설정하던 시절이 얼마나 비효율적이었는지 깨닫게 될 거고, 코드 한 줄로 수백 개의 서버를 관리하는 자신을 발견하게 될 거야.

실수를 두려워하지 마! 개발 환경에서 마음껏 실험하고, 실패하고, 배워. 그게 성장하는 가장 빠른 방법이야. 💪

그리고 혼자 고민하지 말고, 재능넷 같은 플랫폼에서 전문가들의 도움을 받거나, 반대로 당신의 지식을 공유하면서 함께 성장하자!

당신의 DevOps 여정을 응원해! 화이팅! 🚀✨

📢 질문이나 피드백이 있다면: - 재능넷 커뮤니티에서 DevOps 전문가들과 소통하세요
- GitHub에서 오픈소스 프로젝트에 참여해보세요
- 기술 블로그를 시작해서 배운 내용을 정리해보세요
- 컨퍼런스나 밋업에 참석해서 네트워킹하세요

함께 배우고 성장하는 DevOps 커뮤니티를 만들어가요! 🤝

지식인의 숲 - 지적 재산권 보호 고지

지적 재산권 보호 고지

사용 제한: 재능넷의 명시적 서면 동의 없이 본 컨텐츠를 복제, 수정, 배포, 또는 상업적으로 활용하는 행위는 엄격히 금지됩니다.
데이터 수집 금지: 본 컨텐츠에 대한 무단 스크래핑, 크롤링, 및 자동화된 데이터 수집은 법적 제재의 대상이 됩니다.
AI 학습 제한: 재능넷의 AI 생성 컨텐츠를 타 AI 모델 학습에 무단 사용하는 행위는 금지되며, 이는 지적 재산권 침해로 간주됩니다.

프로그램개발 · 분야 선택22개 분야

🚀 클라우드 인프라 변경 자동화: Terraform과 CI/CD로 완성하는 스마트한 배포 전략

🎯 왜 인프라 자동화가 필요할까?

💥 수동 인프라 관리의 문제점들

🏗️ Terraform이 뭐길래?

📚 Terraform의 핵심 개념들

⚙️ Terraform 워크플로우: 실전 사용법

🔄 Terraform 4단계 워크플로우

🗑️ 보너스: Destroy (삭제)

🔐 State 관리: Terraform의 두뇌

🧠 State 파일이 하는 일

📁 Local State vs Remote State

🛠️ State 관리 명령어들

🔄 CI/CD와 Terraform의 만남

🎭 전통적인 방식 vs CI/CD 방식

🏗️ CI/CD 파이프라인 구조

🔧 GitHub Actions로 구현하기

🎨 실전 예제: 3-Tier 웹 애플리케이션 인프라

🏛️ 아키텍처 구성

📁 프로젝트 구조

🌐 1. Networking 모듈

💻 2. Compute 모듈

🗄️ 3. Database 모듈

🌍 4. 메인 설정 파일

📊 5. 환경별 변수 설정

🛡️ 보안과 베스트 프랙티스

🔐 1. 민감한 정보 관리

🔍 2. 보안 스캔 자동화

🎯 3. 최소 권한 원칙 (Least Privilege)

📝 4. 코드 리뷰 프로세스

🔄 5. State 파일 보안

📊 6. 모니터링과 알림

🎓 7. 팀 교육과 문서화

🚨 트러블슈팅: 자주 만나는 문제들

❌ 문제 1: State Lock 걸림

❌ 문제 2: State Drift (상태 불일치)

❌ 문제 3: 순환 의존성 (Circular Dependency)

❌ 문제 4: Provider 버전 충돌

❌ 문제 5: 리소스 삭제 실패

❌ 문제 6: CI/CD 파이프라인 실패

💰 비용 최적화 전략

📊 1. Infracost로 비용 예측

⏰ 2. 스케줄링으로 비용 절감

🎯 3. 적절한 인스턴스 타입 선택

💾 4. 스토리지 최적화

🔍 5. 사용하지 않는 리소스 찾기

🎓 학습 로드맵과 다음 단계

📚 초급 → 중급 (지금 당신의 위치!)

🚀 중급 → 고급

🛠️ 실전 프로젝트 아이디어

📖 추천 학습 자료

🤝 커뮤니티 참여하기

🎬 마무리하며

✨ 핵심 요약

🚀 당신의 다음 액션 플랜

💬 마지막 한마디

관련 키워드

댓글 작성

로그인이 필요합니다

댓글 0

지식인의 숲 - 지적 재산권 보호 고지

지적 재산권 보호 고지

해당 지식과 관련있는 인기재능

서버 구축·배포·오류 해결, AWS·리눅스·도메인·SSL