[클라우드 비용 관리] Terraform Cloud 비용 최적화: RUM 모델 이해 및 절감 전략

안녕하세요, 13년차의 서버실 주인장입니다. 오늘은 인프라 자동화 좀 해봤다 하는 분들이라면 한 번쯤은 만나봤을 Terraform Cloud에 대한 이야기를 해볼까 합니다. 특히, "어? 이거 왜 이렇게 비용이 많이 나왔지?" 하고 고개를 갸웃하게 만드는 그 미스터리, 바로 RUM (Resource Usage Model) 모델과 그 비용을 최적화하는 전략에 대해 제 경험을 바탕으로 솔직하게 풀어보려고 합니다.

처음 Terraform Cloud를 도입했을 때, 저는 그 편리함에 감탄했었죠. 원격 상태 관리(Remote State Management), 팀 협업, CI/CD 통합까지… IaC(Infrastructure as Code)의 생산성을 정말 한 단계 끌어올려 주더라고요. 근데 어느 날 청구서를 받아보니, 예상했던 것보다 훨씬 많은 금액에 깜짝 놀랐습니다. terraform apply 한두 번 했을 뿐인데 이게 무슨 일인가 싶었죠. 혹시 여러분도 이런 경험 없으신가요? ⚠️

이건 바로 Terraform Cloud의 독특한 과금 방식인 RUM 모델 때문이거든요. 저도 삽질 좀 하면서 이 모델을 파고들었고, 그 결과 몇 가지 효과적인 비용 절감 전략을 찾을 수 있었습니다. 오늘은 그 노하우를 여러분과 공유해볼까 합니다. 자, 그럼 함께 Terraform Cloud 비용 청구의 비밀을 파헤쳐 볼까요?

Terraform Cloud RUM 모델 개요: 리소스가 어떻게 비용으로 연결되는지 보여주는 다이어그램입니다.

Terraform Cloud RUM (Resource Usage Model)이란 무엇인가요?

Terraform Cloud의 비용 구조에서 가장 핵심적인 부분은 바로 RUM (Resource Usage Model, 리소스 사용 모델)입니다. 쉽게 말해, Terraform Cloud가 "관리하는 리소스의 개수"에 따라 비용을 청구하는 방식이에요.

그럼 어떤 리소스가 RUM에 포함될까요? terraform state list 명령어를 실행했을 때 출력되는 모든 리소스가 RUM 카운트에 포함된다고 생각하시면 됩니다. 예를 들어, AWS EC2 인스턴스, S3 버킷, VPC, Subnet 등 resource "aws_instance" "my_server" 이런 식으로 HCL(HashiCorp Configuration Language)에 선언된 모든 것들이요. Terraform Cloud는 이런 리소스들을 워크스페이스(Workspace) 단위로 관리하고, 각 워크스페이스가 관리하는 리소스의 총합에 따라 과금하는 방식이에요.

여기서 중요한 포인트는 💡 데이터 소스 (Data Source)나 로컬 리소스 (Local Resource)는 RUM 카운트에 포함되지 않는다는 점입니다! 즉, data "aws_ami" "latest"나 locals { ... } 블록은 아무리 많이 써도 비용에 영향을 주지 않아요. 이 점을 잘 활용하면 비용을 효과적으로 절감할 수 있거든요.

Terraform Cloud 비용 절감 핵심 전략

이제 본격적으로 Terraform Cloud 비용을 최적화하는 전략들을 알아볼 시간입니다. 제가 직접 써보고 효과를 본 방법들이니, 여러분 환경에도 적용해보시면 분명 도움이 될 거예요.

1. 불필요한 워크스페이스 정리하기

이건 정말 기본 중의 기본이자 가장 효과적인 방법입니다. 개발 초기 단계나 테스트 목적으로 만들었다가 방치된 워크스페이스, 혹은 더 이상 사용하지 않는 프로젝트의 워크스페이스가 있다면 과감히 정리해야 합니다. 각 워크스페이스는 관리하는 리소스 수에 따라 RUM 비용을 발생시키기 때문이죠. 😅

저도 처음엔 테스트용으로 워크스페이스를 여러 개 만들었는데, 나중에 보니 수십 개의 워크스페이스가 활성 상태로 남아있더라고요. 이걸 정리했더니 월별 청구액이 꽤 많이 줄었습니다. 🎉

워크스페이스를 정리할 때는 다음 단계를 따르세요:

1. 상태 파일 백업: 혹시 모를 상황에 대비해 terraform state pull > my_backup.tfstate 명령어로 상태 파일을 로컬에 백업해두는 게 좋습니다.
2. 리소스 삭제: 워크스페이스가 관리하는 실제 클라우드 리소스를 terraform destroy 명령어로 삭제합니다. 이 과정을 빼먹으면 클라우드 비용만 계속 나갑니다!
3. 워크스페이스 삭제: Terraform Cloud UI나 API를 통해 워크스페이스를 삭제합니다.

만약 수많은 워크스페이스를 일일이 확인하기 어렵다면, tfe-cli 같은 도구를 활용해서 스크립트로 자동화하는 것도 좋은 방법이에요.

# 예시: 특정 태그를 가진 오래된 워크스페이스 목록 확인 (tfe-cli 예시)
tfe workspace list --json | jq '.[] | select(.tags[] | contains("test")) | select(.updated-at < "2023-01-01T00:00:00Z")'

# 삭제는 더 신중하게 접근해야 합니다.
# tfe workspace delete [WORKSPACE_NAME]

2. 리소스 설계 최적화: Data Sources 및 Locals 활용

앞서 언급했듯이 Data Sources (데이터 소스)와 Locals (로컬 변수)는 RUM 카운트에 포함되지 않습니다. 이 점을 최대한 활용하여 resource 블록의 수를 줄이는 방향으로 설계를 최적화할 수 있어요.

• Data Sources 활용: 이미 존재하는 리소스의 정보를 가져올 때 data "aws_vpc" "existing"처럼 데이터 소스를 사용하세요. 특히, 자주 바뀌지 않거나 다른 Terraform 스택에서 관리하는 리소스 정보를 가져올 때 유용합니다. 제가 해보니, AMI ID나 특정 보안 그룹 ID 같은 것들을 데이터 소스로 가져오면 resource 블록을 하나 줄일 수 있더라고요.
• Locals 활용: 복잡한 표현식의 결과를 저장하거나, 여러 리소스에서 공통으로 사용되는 값을 정의할 때 locals 블록을 사용하면 코드 가독성도 높이고, 불필요한 리소스 선언을 피할 수 있어요.

# RUM에 포함되지 않는 Data Source 예시
data "aws_ami" "ubuntu" {
  most_recent = true
  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"]
  }
  owners = ["099720109477"]
}

# RUM에 포함되지 않는 Locals 예시
locals {
  instance_type = "t3.micro"
  common_tags = {
    Project     = "MyService"
    Environment = "Development"
  }
}

# RUM에 포함되는 Resource 예시 (이것의 수가 과금의 기준이 됩니다)
resource "aws_instance" "web_server" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = local.instance_type
  tags          = local.common_tags
}

3. Sentinel Policy 활용하여 비용 낭비 방지

Terraform Cloud의 Sentinel (센티넬)은 정책 기반 코드(Policy as Code)를 통해 인프라 변경 사항을 검증하는 강력한 도구입니다. 이 Sentinel을 활용하면 비용 낭비를 사전에 막을 수 있어요. 예를 들어:

• 고가용성 리소스 제한: 특정 고가 리소스(예: 고성능 데이터베이스 인스턴스)의 생성을 제한하거나, 특정 환경(예: 개발 환경)에서는 특정 인스턴스 타입 이상을 생성하지 못하게 정책을 걸 수 있어요.
• 리소스 개수 제한: 특정 타입의 리소스(예: EC2 인스턴스)가 한 워크스페이스 내에서 일정 개수 이상 생성되지 못하도록 막을 수 있거든요. 저도 실수로 count 값을 너무 높게 설정해서 수십 개의 인스턴스를 한 번에 배포할 뻔한 적이 있는데, Sentinel 덕분에 막을 수 있었죠. 휴~ 😮‍💨

# 예시: EC2 인스턴스의 개수를 5개로 제한하는 Sentinel Policy (pseudo-code)

# import "tfplan/v2" as tfplan

# instance_count = length(tfplan.resource_changes as r, r.type is "aws_instance" and r.change.actions contains "create")

# main = rule {
#   instance_count <= 5
# }

실제 Sentinel 정책은 위 예시보다 더 복잡하지만, 핵심은 원하는 제약을 코드로 정의하여 terraform apply 전에 검증함으로써 불필요한 리소스 생성을 막는다는 거죠.

Terraform Cloud 워크스페이스와 Sentinel 정책: 중앙 정책 적용으로 비용 낭비를 막는 방법을 보여줍니다.

4. Run 실행 횟수 관리 (간접적 영향)

RUM 모델 자체는 리소스 개수에 초점을 맞추지만, 상위 티어에서는 Run (실행) 횟수도 과금 요소가 될 수 있어요. 그리고 잦은 Run은 불필요한 리소스 변경으로 이어질 가능성을 높여 RUM 카운트에도 간접적으로 영향을 줄 수 있거든요.

• 변경 사항 신중하게 검토: terraform plan 결과를 항상 꼼꼼하게 확인하고, 꼭 필요한 변경 사항만 apply 하세요.
• CI/CD 파이프라인 최적화: 불필요한 트리거로 Run이 실행되지 않도록 CI/CD 파이프라인을 설계하는 게 중요합니다. 예를 들어, 모든 커밋마다 Run을 돌리기보다는, 특정 브랜치에 머지될 때만 실행되도록 설정하는 식이죠.

비용 최적화 결과 확인하기

위 전략들을 적용했다면, 이제 그 효과를 확인해야겠죠? Terraform Cloud는 자체적으로 Billing & Usage (청구 및 사용량) 대시보드를 제공합니다. 여기서 월별 RUM 사용량과 청구 금액을 확인할 수 있어요.

제 경험상, 불필요한 워크스페이스를 정리하고 리소스 설계를 조금만 변경해도 눈에 띄게 RUM 카운트가 줄어드는 것을 볼 수 있었습니다. 처음엔 이게 뭔가 싶었는데, 막상 수치가 줄어드는 걸 보니 뿌듯하더라고요. ✅

대시보드에서 Managed Resources (관리되는 리소스) 그래프를 꾸준히 모니터링하면서, 어떤 워크스페이스가 많은 리소스를 관리하고 있는지, 그리고 그 추이가 어떻게 변하는지 확인해보세요. 이걸 보면서 "아, 이 워크스페이스는 리소스가 너무 많네. 줄여야겠다" 같은 의사결정을 할 수 있거든요.

Terraform Cloud Billing & Usage 대시보드: 비용 절감 전략 적용 후 월별 RUM 사용량이 감소하는 가상의 그래프입니다.

마무리하며: 삽질을 줄이는 현명한 비용 관리

오늘은 Terraform Cloud의 RUM 모델을 이해하고, 이를 바탕으로 비용을 최적화하는 여러 전략에 대해 이야기해봤습니다. 13년차 인프라 엔지니어로서 제가 직접 겪었던 "비용 폭탄" 경험과 그 해결 과정을 공유하면서, 여러분의 삽질을 조금이나마 줄여드리고 싶었어요. 💡

핵심은 결국 "내가 무엇을 관리하고 있고, 그게 과금에 어떻게 영향을 미치는지 정확히 아는 것"이에요. Terraform Cloud는 정말 강력한 도구지만, 그만큼 현명하게 사용해야 예상치 못한 비용 문제로 당황하지 않을 수 있거든요.

여러분도 이 글에서 소개한 전략들을 바탕으로 Terraform Cloud 비용을 최적화하고, 더 효율적인 IaC 환경을 구축하시길 바랍니다. 다음 글에서는 Terraform Cloud의 원격 실행 환경(Remote Operations)과 로컬 실행 환경(Local Operations)의 장단점을 비교해보는 시간을 가져볼게요. 기대해주세요! 😄

Terraform Cloud 비용 절감 핵심 전략 요약: 주요 절감 팁을 한눈에 볼 수 있는 인포그래픽입니다.