13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] 클라우드

  • [Cloud] 기존 인프라를 Pulumi로 전환하기: 마이그레이션 전략 및 체크리스트

    [Cloud] 기존 인프라를 Pulumi로 전환하기: 마이그레이션 전략 및 체크리스트

    목차

    안녕하세요, 13년차의 서버실 운영자입니다. 오늘은 많은 인프라 엔지니어분들이 한 번쯤 고민해봤을 주제, 기존 인프라를 Pulumi(풀루미)로 전환하는 마이그레이션 전략에 대해 이야기해보려고 해요.

    혹시 지금도 수동으로 서버를 만들고, 설정 변경할 때마다 손으로 클릭하거나 스크립트를 돌리고 계신가요? 처음엔 괜찮았는데, 인프라가 커질수록 관리하기 너무 힘들잖아요. 저도 그랬거든요. 예전에는 직접 하나하나 다 세팅했었는데, 시간이 지나니 너무 비효율적이라는 걸 깨달았어요. 그러다 IaC(Infrastructure as Code, 코드형 인프라)에 관심을 가지게 되었고, 특히 Pulumi를 접하면서 기존 인프라를 코드로 관리하는 것에 매력을 느꼈습니다. 기존 인프라를 Pulumi로 마이그레이션(Migration)하는 과정이 쉽지는 않았지만, 그만큼 얻는 것이 많았기에 제 경험을 공유하고 싶었어요.

    이 글을 통해 여러분의 Pulumi 도입과 IaC 전환에 도움이 될 만한 실질적인 전략과 마이그레이션 체크리스트를 함께 살펴보겠습니다. 삽질했던 경험도 솔직하게 풀어낼 테니, 비슷한 고민을 하고 계신다면 분명 도움이 될 거예요. 자, 그럼 시작해볼까요?

    수동 인프라와 Pulumi 코드형 인프라 비교 다이어그램

    수동으로 관리되는 복잡한 인프라와 Pulumi로 코드화되어 정돈된 인프라의 개념적인 비교 다이어그램입니다.

    Pulumi, 왜 도입해야 할까요? IaC 전환의 필요성

    우선, Pulumi가 정확히 무엇이고 왜 우리가 굳이 기존 인프라를 Pulumi로 전환(Pulumi Migration)해야 하는지 간단하게 짚고 넘어가 볼까요?

    Pulumi(풀루미)는 Python, TypeScript, Go, C# 같은 익숙한 프로그래밍 언어로 클라우드 인프라를 코드로 정의하고 배포할 수 있는 IaC(Infrastructure as Code, 코드형 인프라) 도구예요. 쉽게 말해, AWS EC2 인스턴스나 S3 버킷 같은 리소스들을 CLI(Command Line Interface)나 콘솔에서 직접 만드는 게 아니라, Python 스크립트처럼 코드로 작성해서 관리하는 거죠.

    제가 처음 Pulumi를 써봤을 때 가장 인상 깊었던 건, 기존 프로그래밍 언어의 강점을 그대로 가져온다는 점이었어요. 조건문, 반복문, 함수 같은 일반적인 프로그래밍 로직을 인프라 코드에 적용할 수 있으니 훨씬 유연하고 강력하게 인프라를 관리할 수 있더라고요. Terraform(테라폼)도 훌륭한 IaC 도구지만, HCL(HashiCorp Configuration Language)이라는 자체 언어를 배워야 했거든요. Pulumi는 제가 이미 아는 언어로 인프라를 다룰 수 있다는 게 정말 큰 장점이었어요.

    그럼 왜 IaC로 전환(IaC 전환)해야 할까요? 기존 인프라가 잘 돌아가고 있는데 굳이 건드려야 하나 싶을 수도 있어요. 하지만 IaC는 다음과 같은 명확한 이점을 제공합니다.

    • 일관성(Consistency): 코드로 정의되니 휴먼 에러가 줄어들고, 항상 동일한 환경을 배포할 수 있어요.
    • 반복 가능성(Repeatability): 개발, 스테이징, 프로덕션 환경을 똑같이 빠르게 구축할 수 있습니다.
    • 버전 관리(Version Control): Git(깃) 같은 VCS(Version Control System)로 인프라 변경 이력을 추적하고, 필요하면 롤백(Rollback)도 가능해져요.
    • 협업(Collaboration): 여러 엔지니어가 함께 인프라를 정의하고 검토할 수 있습니다.
    • 재사용성(Reusability): 공통 모듈을 만들어 인프라 배포 시간을 단축할 수 있죠.

    이런 장점들 때문에 기존 인프라를 인프라 코드화하는 건 이제 선택이 아닌 필수가 되어가고 있어요.

    기존 인프라 Pulumi 마이그레이션 전략 및 체크리스트

    자, 이제 본론으로 들어와서, 기존에 수동으로 구축된 인프라를 Pulumi로 마이그레이션(Migration)하는 구체적인 전략과 제가 직접 겪으면서 만들어 본 체크리스트(Checklist)를 공유해 드릴게요. 한 번에 모든 걸 바꾸려고 하면 대혼란이 올 수 있으니, 점진적인 접근이 중요합니다.

    1. 사전 준비 및 환경 설정 (Pre-requisites & Setup)

    가장 먼저 Pulumi를 사용할 환경을 구축해야겠죠? 제 경험상 이 단계에서 꼼꼼하게 준비해야 나중에 삽질을 줄일 수 있더라고요.

    1. Pulumi CLI 설치: 운영체제에 맞는 Pulumi CLI를 설치합니다. 
      curl -fsSL https://get.pulumi.com | sh
    2. 클라우드 프로바이더 인증 설정: AWS, Azure, GCP 등 여러분이 사용하는 클라우드에 Pulumi가 접근할 수 있도록 인증 정보를 설정해야 합니다. 예를 들어 AWS의 경우, ~/.aws/credentials 파일이나 환경 변수를 통해 설정하죠.
    3. 프로젝트 생성 및 초기화: Pulumi 프로젝트를 생성하고 사용할 언어를 선택합니다. 저는 주로 TypeScript나 Python을 사용하는데, 여기서는 Python을 예시로 들어볼게요. 
      mkdir my-pulumi-infra
cd my-pulumi-infra
pulumi new python

      이 명령어를 실행하면 기본 템플릿 파일들이 생성됩니다.

    4. 백엔드 상태 저장소 결정: Pulumi는 인프라의 상태(State)를 관리하는데, 이 상태 파일을 어디에 저장할지 결정해야 합니다. 기본적으로 Pulumi Service(클라우드)에 저장되지만, AWS S3나 Azure Blob Storage 같은 자체 스토리지를 사용할 수도 있습니다. 프로덕션 환경에서는 자체 스토리지를 권장해요.

    2. 리소스 임포트 전략 (Resource Import Strategy)

    기존 인프라를 Pulumi로 가져오는 가장 중요한 단계입니다. Pulumi는 이미 존재하는 리소스를 코드로 임포트(Import)하는 기능을 제공하는데, 이게 정말 유용하더라고요. 수동으로 하나하나 코드를 작성하는 것보다 훨씬 빠르고 정확합니다.

    제가 해보니, 한 번에 모든 리소스를 임포트하는 것보다는 작은 단위로 쪼개서 임포트하는 것이 훨씬 안전하고 관리하기 편했습니다. 예를 들어 VPC(Virtual Private Cloud), 서브넷(Subnet), 보안 그룹(Security Group)부터 먼저 임포트하고, 그다음에 EC2 인스턴스, RDS(Relational Database Service) 데이터베이스 순으로 진행하는 식이죠.

    1. 임포트할 리소스 식별: 마이그레이션할 인프라 리스트를 작성하고, 어떤 순서로 임포트할지 우선순위를 정합니다. 의존성(Dependency)이 낮은 리소스부터 시작하는 게 좋아요.
    2. 임포트 대상 리소스 ID 확인: 클라우드 콘솔이나 CLI에서 각 리소스의 ID(또는 ARN)를 확인합니다. 이 ID는 임포트 명령에 필요해요.
    3. Pulumi 임포트 코드 작성 및 실행: Pulumi는 pulumi import 명령어를 통해 기존 리소스를 가져올 수 있습니다.
    # my_pulumi_infra/__main__.py 에 임포트할 리소스 코드를 먼저 작성합니다.
import pulumi_aws as aws

# 이 리소스는 아직 실제 AWS에 존재하지 않습니다.
# 임포트를 위해 임시로 코드를 작성하고, 실제 리소스 ID를 지정해야 합니다.
my_vpc = aws.ec2.Vpc("my-existing-vpc",
    cidr_block="10.0.0.0/16",
    # 기타 속성들은 실제 VPC의 속성과 일치시켜야 합니다.
    # 예를 들어, tags={ "Name": "my-existing-vpc" } 등
)

# 임포트 명령 실행 예시 (터미널에서)
# pulumi import aws:ec2/vpc:Vpc my-existing-vpc vpc-xxxxxxxxxxxxxxxxx
# 여기서 'vpc-xxxxxxxxxxxxxxxxx'는 실제 AWS VPC의 ID입니다.

    pulumi import 명령을 실행하면 Pulumi가 해당 리소스의 현재 상태를 읽어와서 __main__.py 파일에 코드를 생성해 줍니다. 이 코드를 기반으로 Pulumi 스택(Stack)과 클라우드 리소스 간의 상태가 동기화되는 거죠. 이 과정에서 diff(차이점)를 잘 확인하는 게 중요해요.

    Pulumi 기존 리소스 임포트 과정 플로우차트

    Pulumi CLI를 이용해 기존 클라우드 리소스를 코드로 임포트하는 과정의 흐름을 보여주는 플로우차트입니다.

    3. 코드 리팩토링 및 모듈화 (Code Refactoring & Modularization)

    임포트된 코드는 보통 원시적인 형태입니다. 이걸 그대로 사용하는 것보다는 리팩토링(Refactoring)하고 모듈화(Modularization)하는 과정이 꼭 필요해요.

    1. 하드코딩된 값 제거: IP 주소, 리소스 이름 등 하드코딩된 값들을 pulumi.Config나 변수로 분리하여 유연성을 높입니다.
    2. 재사용 가능한 모듈 생성: VPC, 네트워크 구성, 공통 보안 그룹 등 여러 스택에서 재사용될 수 있는 부분은 별도의 모듈(예: Python 파일)로 분리합니다. 이렇게 하면 코드가 훨씬 깔끔해지고 유지보수가 쉬워집니다. 
      # modules/network.py 예시
import pulumi_aws as aws

def create_vpc(name: str, cidr_block: str):
    vpc = aws.ec2.Vpc(name, cidr_block=cidr_block)
    # 서브넷, 인터넷 게이트웨이 등 추가 생성 로직
    return vpc

# my_pulumi_infra/__main__.py 에서 사용
# from .modules import network
# my_vpc = network.create_vpc("my-app-vpc", "10.0.0.0/16")
    3. Pulumi 컴포넌트 리소스 활용: 복잡한 인프라 패턴을 추상화하고 싶다면 Pulumi 컴포넌트 리소스(Component Resources)를 직접 만들어 사용하는 것도 좋은 방법입니다. 여러 개의 기본 리소스를 하나의 논리적인 단위로 묶을 수 있거든요.

    4. 테스트 및 검증 (Testing & Validation)

    코드 리팩토링 후에는 반드시 테스트(Testing)를 거쳐야 합니다. 특히 기존에 잘 운영되던 서비스에 영향을 주면 안 되니까요.

    1. Dry Run (pulumi preview): pulumi preview 명령어를 통해 실제 변경 사항이 어떻게 적용될지 미리 확인합니다. 이 단계에서 예상치 못한 변경이 없는지 꼼꼼하게 검토해야 합니다. ⚠️
    2. Staging 환경 배포: 프로덕션 환경에 바로 적용하기보다는, 최대한 프로덕션과 유사한 스테이징(Staging) 환경에 먼저 배포해보고 문제가 없는지 철저히 검증합니다.
    3. 서비스 영향도 최소화: 마이그레이션 중 서비스 중단이 불가피하다면, 다운타임(Downtime)을 최소화할 수 있는 전략(예: Blue/Green Deployment, Canary Deployment)을 고려해야 합니다.

    ⚠️ Pulumi 마이그레이션 시 주의사항 및 삽질 경험

    제가 13년간 인프라를 만져보면서 느낀 건데, 항상 계획대로만 되는 건 아니더라고요. Pulumi 마이그레이션(Migration) 과정에서도 예상치 못한 문제들이 발생했습니다. 몇 가지 주의사항(Caveats)과 제가 삽질(Troubleshooting)했던 경험을 공유해 드릴게요.

    • 상태 불일치 (State Drift): 가장 흔한 문제 중 하나입니다. Pulumi가 관리하는 코드 상태와 실제 클라우드 리소스 상태가 달라지는 경우죠. 예를 들어, Pulumi 코드를 배포한 후에 누군가 수동으로 AWS 콘솔에서 보안 그룹 설정을 변경했다면, 다음 pulumi up 실행 시 Pulumi는 이 변경 사항을 되돌리려고 할 수 있습니다. 이걸 막으려면 Pulumi가 관리하는 리소스는 절대로 수동으로 변경하지 않도록 팀원들과 약속해야 합니다. 만약 상태 불일치가 발생하면, pulumi refresh 명령으로 현재 클라우드 상태를 읽어와 Pulumi 스택 상태를 업데이트하거나, pulumi state delete 후 다시 임포트하는 등의 방법을 사용해야 합니다.
    • 의존성 문제 (Dependency Issues): 리소스 간의 의존성을 Pulumi가 정확히 파악하지 못해서 배포 순서가 꼬이는 경우가 가끔 있었습니다. 특히 복잡한 네트워크 구성에서 이런 문제가 발생하더라고요. 이럴 때는 depends_on 옵션을 명시적으로 사용해서 의존성을 지정해 주면 해결할 수 있습니다. 
      my_resource_b = aws.some.ResourceB("my-resource-b",
    # ...
    opts=pulumi.ResourceOptions(depends_on=[my_resource_a])
)
    • 기존 리소스 삭제 위험: pulumi import를 잘못 사용하거나, 임포트 후 코드를 수정하는 과정에서 기존 리소스가 삭제될 수 있다는 경고를 보지 못하고 진행했던 적이 있어요. 😱 항상 pulumi preview 결과를 꼼꼼히 확인하고, 삭제(Delete) 또는 교체(Replace) 작업이 있다면 다시 한번 심사숙고해야 합니다. 특히 프로덕션 환경에서는 더욱 조심해야겠죠.
    • 권한 문제: Pulumi CLI를 실행하는 계정이 필요한 클라우드 리소스에 대한 모든 권한을 가지고 있지 않아 배포가 실패하는 경우가 많았습니다. 특히 IAM(Identity and Access Management) 정책이 복잡할 때 자주 발생하더라고요. 최소한의 권한(Least Privilege) 원칙은 중요하지만, 마이그레이션 초기에는 필요한 권한을 충분히 부여하고, 안정화된 후에 점진적으로 줄여나가는 전략도 고려해 볼 만합니다.

    이런 삽질들을 겪으면서 Pulumi 마이그레이션(Pulumi Migration)은 기술적인 부분만큼이나 프로세스(Process)와 팀원 간의 소통(Communication)이 중요하다는 걸 깨달았습니다. 항상 변경 사항을 공유하고, 리뷰하는 과정을 거치는 것이 중요해요.

    마이그레이션 완료 후 검증 및 관리

    성공적으로 Pulumi 마이그레이션(Pulumi Migration)을 마쳤다면, 이제 모든 것이 제대로 작동하는지 검증(Validation)해야 합니다. 그리고 앞으로 Pulumi로 관리되는 인프라를 어떻게 운영할지에 대한 계획도 세워야겠죠?

    1. Pulumi 스택 상태 확인: pulumi stack ls, pulumi stack select <stack_name>, pulumi stack output 명령어를 통해 현재 스택의 상태와 배포된 리소스 정보를 확인합니다.
    2. 클라우드 리소스 확인: 실제 클라우드 콘솔이나 CLI에서 Pulumi가 배포한 리소스들이 의도한 대로 생성되고 설정되었는지 다시 한번 확인합니다. 불필요한 리소스가 남아있지는 않은지도 확인해야 해요.
    3. 모니터링 연동: 기존에 사용하던 모니터링 시스템(예: Prometheus, Grafana, CloudWatch)과 Pulumi로 배포된 리소스들이 제대로 연동되어 데이터를 수집하고 있는지 확인합니다.
    4. CI/CD 파이프라인 구축: Pulumi 코드를 Git 저장소에 올리고, CI/CD(Continuous Integration/Continuous Delivery) 파이프라인을 구축하여 코드 변경 시 자동으로 pulumi preview, pulumi up이 실행되도록 자동화하는 것이 좋습니다. 제가 직접 해보니, 이렇게 자동화했을 때 인프라 배포 속도와 안정성이 엄청나게 향상되더라고요.
    Pulumi 클라우드 리소스 관리 대시보드 예시

    Pulumi를 통해 배포 및 관리되는 클라우드 리소스들의 현황을 한눈에 볼 수 있는 가상의 대시보드 화면입니다.

    마이그레이션을 마치며: Pulumi와 함께 성장하기

    지금까지 기존 인프라를 Pulumi로 전환(Pulumi 마이그레이션)하는 전략과 제가 겪었던 경험들을 공유해 드렸습니다. 처음에는 낯선 IaC 도구와 씨름하는 것이 쉽지 않게 느껴질 수 있어요. 저도 처음엔 기존 스크립트나 수동 작업에 익숙해서 ‘이걸 언제 다 코드로 바꾸나’ 막막했었거든요. 하지만 한 번 전환하고 나니, 인프라 관리가 훨씬 수월해지고, 개발 생산성(Developer Productivity)도 눈에 띄게 좋아지는 걸 체감할 수 있었습니다.

    Pulumi 도입(Pulumi 도입)은 단순히 도구 하나를 바꾸는 것을 넘어, 인프라를 바라보는 관점을 바꾸는 중요한 과정이라고 생각합니다. 코드로 인프라를 정의하고 관리함으로써, 우리는 더 예측 가능하고, 안정적이며, 확장 가능한 시스템을 구축할 수 있게 되죠. 인프라 코드화의 여정은 계속될 거예요.

    이 글이 여러분의 Pulumi 마이그레이션(Pulumi 마이그레이션) 여정에 작은 도움이 되었기를 바랍니다. 다음번에는 Pulumi의 고급 기능이나 특정 클라우드 서비스 연동에 대해 더 깊이 파고들어 보는 시간을 가져볼게요. 혹시 궁금한 점이나 공유하고 싶은 삽질 경험이 있다면 언제든지 댓글로 남겨주세요! 저도 배우는 게 많을 겁니다. 🎉

    Pulumi IaC 및 DevOps 요약 인포그래픽

    Pulumi 로고와 함께 IaC, DevOps, 자동화, 클라우드 관리 등의 핵심 개념을 시각적으로 요약한 인포그래픽입니다.

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

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

    [클라우드 비용 관리] 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 비용 절감 핵심 전략 요약: 주요 절감 팁을 한눈에 볼 수 있는 인포그래픽입니다.