2026 IaC,FinOps,엣지 컴퓨팅 완전 가이드

Terraform·AWS 비용 최적화·Cloudflare Workers

이 장을 읽기 전에: 7장, 8장을 먼저 읽으면 클라우드 기반과 PaaS의 역할 분담이 연결되기 쉽다.

인프라 운용이 어려워지는 것은 서버 대수가 늘었을 때가 아니다. 누가 무엇을 변경했는지를 알 수 없게 되고, 얼마가 드는지가 보이지 않게 되고, 어디서 처리해야 하는지를 잘못 판단했을 때 한꺼번에 무너진다.

이 장에서는 다음 3가지를 함께 다룬다.

IaC로 변경을 재현 가능하게 한다

FinOps로 비용을 가시화한다

엣지와 리전의 역할을 나눈다

� 한국 시장 맥락: 국내에서는 AWS 서울 리전(ap-northeast-2) 단일 리전 구성이 표준이며, Terraform이 IaC 도구로 가장 많이 사용된다. 공공·금융 환경은 NCP/KT Cloud에서 자체 IaC 또는 Terraform NCP Provider를 사용한다.

1. IaC (Infrastructure as Code)

이 섹션이 답하는 질문: 인프라를 코드로 관리한다는 것은 어떤 것인가?

IaC의 본질

IaC는 "인프라를 코드로 만드는" 것보다, 인프라의 변경을 재현 가능하게 하기 위한 수단이다.

수작업 콘솔 조작은 빠르게 보이지만, 다음 문제를 남기기 쉽다.

재현할 수 없다

감사할 수 없다 (ISMS-P·CSAP 인증에서 문제가 됨)

리뷰할 수 없다

환경 차이가 증가한다

주요 선택지

� 국내 현황: 원티드·프로그래머스 채용 공고 기준으로 IaC 도구 수요는 Terraform이 압도적으로 1위다. OpenTofu는 Terraform의 라이선스 변경(BSL) 이후 대안으로 검토되는 팀이 늘고 있다. NCP 환경은 Terraform NCP Provider를 사용한다.

무엇으로 선택하는가

State와 락의 취급

IaC 도구에서 가장 사고가 나기 쉬운 것은 state 관리다. state에는 현재 실제 환경과의 차이를 계산하기 위한 정보가 들어간다. 여기에는 기밀 정보나 내부 ID가 포함되는 경우가 있다.

⚠️ state는 로컬 PC의 작업 파일이 아니다. 팀에서 사용한다면 공유 백엔드, 암호화, 접근 제어, 락을 처음에 결정해야 한다.

---

# Terraform AWS 백엔드 설정 — 서울 리전 기준

# (S3 backend + DynamoDB 락 방식은 현재 공식 문서 확인 권장)

terraform {

required_version = ">= 1.6"

required_providers {

aws = {

source = "hashicorp/aws"

version = "~> 5.0"

}

}

backend "s3" {

bucket = "my-company-tfstate"

key = "prod/infra/terraform.tfstate"

region = "ap-northeast-2" # 서울 리전

encrypt = true

# Terraform 1.6+ 에서는 backend 락 방식이 변경됨

# 반드시 사용 버전의 공식 문서 확인 후 설정

}

}

provider "aws" {

region = "ap-northeast-2" # 서울 리전

default_tags {

tags = {

Environment = var.environment

Team = var.team

ManagedBy = "Terraform"

}

}

}

---

실무상의 주의

remote state를 사용한다

암호화와 접근 제어를 넣는다

락 방식은 도구와 backend에 맞춘다

plan / preview를 PR 리뷰에 통합한다 (GitHub Actions 연동)

수동 변경에 의한 drift를 정기적으로 감지한다

⚠️ Terraform 계열에서는 S3 backend의 락 방식이나 권장 구성이 업데이트되고 있다. 예전에 자주 보이던 DynamoDB 기반 방법을 그대로 베끼는 것이 아니라, 현재 사용하는 버전의 공식 backend 문서를 확인하는 편이 안전하다.

---

# GitHub Actions — Terraform Plan 자동화 예시

name: Terraform Plan

on:

pull_request:

paths:

- 'infra/**'

jobs:

plan:

runs-on: ubuntu-latest

permissions:

pull-requests: write

contents: read

id-token: write

steps:

- uses: actions/checkout@v4

- name: AWS 인증 (OIDC)

uses: aws-actions/configure-aws-credentials@v4

with:

role-to-assume: arn:aws:iam::123456789:role/github-actions-role

aws-region: ap-northeast-2

- uses: hashicorp/setup-terraform@v3

with:

terraform_version: "1.8"

- name: Terraform Plan

id: plan

run: |

cd infra

terraform init

terraform plan -no-color

- name: PR에 Plan 결과 코멘트

uses: actions/github-script@v7

with:

script: |

github.rest.issues.createComment({

issue_number: context.issue.number,

owner: context.repo.owner,

repo: context.repo.repo,

body: `## Terraform Plan 결과\n\`\`\`\n${{ steps.plan.outputs.stdout }}\n\`\`\``

})

---

언제부터 IaC를 넣어야 하는가

"커지면 IaC"는 늦는 경우가 많다. 적어도 다음은 일찍 코드화하는 편이 좋다.

본번 네트워크 (VPC·서브넷·보안 그룹)

본번 데이터베이스 (RDS·Aurora)

DNS (Route 53)

시크릿 참조처 (Secrets Manager)

공유 큐나 스토리지 (SQS·S3)

반대로, 시작 단계에서는 모든 것을 엄밀하게 IaC화하지 않아도 좋다. 중요한 것은 공유되는 본번 기반부터 먼저 코드화하는 것이다.

정리

IaC의 선정은 도구 종파로 결정하는 이야기가 아니다. state를 안전하게 가질 수 있는가, 리뷰에 통합할 수 있는가, 팀이 계속 읽을 수 있는가 의 3가지로 생각하면 실패하기 어렵다.