해결됨: FinOps 성숙도와 클라우드 비용 과제를 이해하도록 도와주세요

Source: Dev.to

TL;DR: 클라우드 비용 초과는 가시성 부족과 소유권 부재에서 비롯되며, 비용이 높은 인스턴스를 잊어버리는 사례가 대표적입니다. 해결책은 자동 정리 스크립트, 사전 예방적인 정책‑as‑code 가드레일, 그리고 지속적인 재무 책임성을 위한 showback 및 chargeback으로의 근본적인 조직 변화를 결합한 다각적인 FinOps 접근 방식입니다.

핵심 권고 사항

1. Implement “Janitor” scripts (e.g., AWS Lambda) to automatically identify and terminate untagged or abandoned cloud resources – a reactive cost‑control measure.
   → “Janitor” 스크립트(예: AWS Lambda)를 구현하여 태그가 없거나 방치된 클라우드 리소스를 자동으로 식별하고 종료합니다 – 반응형 비용 관리 조치.

2. Enforce “Policy as Code” using tools like Sentinel, Open Policy Agent (OPA), or Service Control Policies (SCPs) to prevent expensive or untagged resource provisioning at the IaC or AWS Organization level.
   → **“Policy as Code”**를 Sentinel, Open Policy Agent (OPA), **Service Control Policies (SCPs)**와 같은 도구를 사용해 적용하여 IaC 또는 AWS 조직 수준에서 비용이 많이 들거나 태그가 없는 리소스 프로비저닝을 방지합니다.

3. Drive Organizational Change through FinOps practices such as showback (displaying team‑specific cloud spend) and chargeback (allocating costs to team budgets) to foster a culture of financial ownership.
   → FinOps 실천(예: showback(팀별 클라우드 비용 표시) 및 chargeback(비용을 팀 예산에 할당))을 통해 조직 변화를 주도하고 재무 소유 문화를 조성합니다.

문제

“통제되지 않는 클라우드 비용과 미숙한 FinOps 관행에 어려움을 겪고 있나요? 시니어 DevOps 엔지니어가 작성한 이 가이드는 클라우드 낭비의 실제 원인을 분석하고, 빠른 스크립트부터 영구적인 문화 변화까지 세 가지 구체적인 솔루션을 제공하여 지출을 통제할 수 있게 도와줍니다.”

나는 아직도 재무팀으로부터 온 월요일 아침 Slack 메시지를 기억합니다:

“다리안, 이 AWS 급증에 대해 설명해줄 수 있나요?”

청구 콘솔을 열었을 때, 가슴이 내려앉았습니다. 한 개발자가 금요일 오후에 p4d.24xlarge EC2 인스턴스를 “새로운 ML 모델의 빠른 테스트” 용도로 띄워두고 잊어버렸습니다. 단 하루 주말 동안 그 인스턴스는 다섯 자리 수의 요금을 발생시켰습니다.

우리는 가드레일, 알림, 혹은 소유권 정책이 없었습니다. 자유롭게 사용 가능한 환경이었고, 우리는 그 대가를 치르고 있었습니다—말 그대로.

이 이야기가 특수한 경우는 아닙니다. 팀들은 혁신을 위한 막강한 권한을 가지고 클라우드 왕국의 열쇠를 받지만, 재무적 식견이나 가드레일 없이 책임 있게 사용하지 못합니다. 이것이 FinOps 성숙도 투쟁의 핵심입니다. 저렴하게 쓰는 것이 아니라 효율적이고 책임감 있게 사용하는 것이 목표입니다.

근본 원인

이 문제를 해결하는 것은 좀비 서버를 찾는 것만이 아닙니다. 팀이 클라우드와 상호작용하는 방식을 근본적으로 바꾸는 것이 필요합니다.

Source: …

Solution #1 – Reactive “Stop the Bleeding” (Janitor Scripts)

“이것은 반응형, ‘출혈을 멈추는’ 접근 방식입니다. 문화 자체를 고치는 것은 아니지만, 즉각적인 낭비는 멈춥니다.”

우리는 EventBridge에 의해 매일 밤 트리거되는 간단한 AWS Lambda 함수를 만들었습니다. 이 함수는:

1. dev 계정에 있는 모든 EC2 인스턴스와 RDS 데이터베이스를 스캔합니다.
2. owner 태그 또는 TTL(Time‑To‑Live) 태그가 없는 리소스를 표시합니다.
3. 생성자를 (CloudTrail을 통해 식별 가능하면) 태그하여 Slack 채널에 경고를 게시합니다.
4. 리소스가 24시간 동안 태그되지 않은 채로 남아 있으면, 두 번째 Lambda가 해당 리소스를 종료합니다.

결과: 가혹한가요? 예. 효과적인가요? 절대적으로 그렇습니다.

Sample Python (Boto3) – Lambda Janitor

import boto3

def find_untagged_instances(event, context):
    ec2 = boto3.client('ec2', region_name='us-east-1')
    instances = ec2.describe_instances(
        Filters=[{'Name': 'instance-state-name', 'Values': ['running']}]
    )

    for reservation in instances['Reservations']:
        for instance in reservation['Instances']:
            instance_id = instance['InstanceId']
            tags = instance.get('Tags', [])
            tag_keys = [tag['Key'] for tag in tags]

            if 'owner' not in tag_keys:
                print(f"ALERT: Instance {instance_id} is missing 'owner' tag.")
                # In a real script, you'd post this to Slack or SNS
                # and maybe add a "pending_termination" tag

경고: 이것은 전략이 아니라 해킹입니다. 혼란을 정리해 주지만, 누군가가 다시 만들지 못하게 가르쳐 주지는 못합니다. “중요한 테스트 서버”가 종료된 화난 개발자를 상대하고 스크립트를 유지 관리하는 데 시간을 소비하게 될 것입니다. 초기 제어를 확보하기 위해 사용하되, 여기서 멈추지 마세요.

Solution #2 – “Shift‑Left” Prevention (Policy‑as‑Code)

“이것이 바로 ‘좌측 이동(Shift‑Left)’을 통해 문제 자체가 발생하지 않도록 방지하는 단계입니다. 문제를 정리하는 대신, 문제를 만들 수 없게 합니다.”

Core Principle

비용 제어를 IaC 파이프라인과 클라우드 계정 구조에 직접 삽입합니다.

Mandatory Tagging with IaC Policies

• Tools: Sentinel (Terraform Cloud), OPA를 CI/CD에 통합.
• Policy Example: owner 태그가 없거나 S3 버킷에 라이프사이클 정책이 없는 경우 terraform plan을 실패하도록 설정.
• Outcome: 개발자는 배포 전에 즉시 피드백을 받습니다.

Service Control Policies (SCPs)

AWS 조직 수준에서 개발자 계정에 SCP를 적용합니다. SCP는 “스테로이드가 붙은 IAM 정책”처럼 동작하여 특정 인스턴스 패밀리의 생성을 거부할 수 있습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyExpensiveInstanceTypesInDev",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:InstanceType": [
            "p4d.24xlarge",
            "g5.12xlarge",
            "g5.24xlarge"
          ]
        }
      }
    }
  ]
}

• Use‑Case: 지정된 “ML Research” OU가 아닌 모든 계정에서 p4, g5 등 인스턴스 타입을 차단합니다.

솔루션 #3 – 조직 변화 (FinOps 실천)

“‘showback’와 ‘chargeback’ 같은 FinOps 실천을 통해 ‘조직 변화’를 추진하고 재무 소유 문화를 조성합니다.”

구현 단계

1. Showback – 팀, 프로젝트, 태그별 클라우드 비용을 분류한 주간/월간 대시보드를 게시합니다.
2. Chargeback – 실제 비용을 각 팀의 예산에 할당하여 초과 지출을 직접적인 책임으로 만듭니다.
3. FinOps 위원회 – 엔지니어링, 재무, 제품 부서 등 교차 기능 그룹을 구성하여 비용을 검토하고, 예산을 설정하며, 정책을 개선합니다.
4. 교육 및 훈련 – 클라우드 가격 책정, 비용 효율적인 아키텍처 패턴, 태그 표준에 대한 정기 워크숍을 진행합니다.

예상 효과

모두 합치기

핵심 요약: 먼저 빠른 성과인 (janitor 스크립트)로 즉각적인 낭비를 차단하고, 정책‑코드로 프로비저닝을 잠그며, 마지막으로 재무 책임을 조직 문화에 녹여냅니다. 이 3단계 접근법은 ‘불 끄기’에서 ‘재무적으로 스마트한 클라우드 엔지니어링’으로 전환시킵니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringLike": {
          "ec2:InstanceType": [
            "p4d.*",
            "p3.*",
            "g5.*",
            "x2iezn.*",
            "u-12tb1.metal"
          ]
        }
      }
    }
  ]
}

접근 방식 개요

궁극적으로, 성숙한 FinOps 실천은 세 가지를 모두 결합합니다:

• Janitor 스크립트는 놓치는 부분을 처리합니다.
• 가드레일은 대부분의 문제를 예방합니다.
• 문화적 소유권은 모든 사람이 클라우드 자원의 책임 있는 관리자가 되도록 합니다.

갑작스러운 청구서를 쫓는 일을 멈추고, 재무 책임을 가장 쉬운 길로 만드는 플랫폼을 구축하세요.

👉 원본 기사를 TechResolve.blog에서 읽어보세요
☕ 제 작업을 지원해 주세요 – 이 글이 도움이 되었다면 커피 한 잔 사주실 수 있습니다: 👉