Tagging — 비용 할당의 80%를 주도하는 20%

Source: Dev.to

일반적인 FinOps 실수: 과도하게 설계된 태깅

Series B SaaS 팀이 47개의 필드로 구성된 태그 분류 체계(예: Environment, Service, Owner, Business unit, Cost center, Data classification, Compliance zone, Criticality, Expiry, PII flag, Migration source, CI pipeline ID)를 설계하는 데 3개월을 투자했습니다.

• 이를 강제할 수 없었습니다.
• Terraform 코드베이스에 약 80개의 모듈이 있었고, 절반에 해당하는 리소스는 분류 체계가 존재하기 전에 이미 프로비저닝되었습니다.
• 롤아웃 계획은 6개월이었지만, 팀은 4개월 만에 포기했습니다.

그 사이에도 비용 할당 보고서는 여전히 다음과 같았습니다:

Sum by service:
- EC2 = 34%
- RDS = 22%
- Datadog = 18%
- Others = 26%

47개의 필드 스키마는 전혀 비즈니스 가치를 제공하지 못했습니다.

실제로 효과적인 80/20 태깅 접근법

오직 다섯 개의 태그만 필요하며, Service Control Policies (SCP), CI 게이트, IaC 정책을 통해 강제합니다:

# Example IaC policy (pseudo‑code)
required_tags:
  - team
  - service
  - env
  - cost_center
  - expiry
enforcement: block_if_missing
auto_flag: true

• 필수: 태그가 하나라도 누락되면 리소스 생성이 차단됩니다.
• 정책 위반 시 자동 플래그가 지정됩니다.

이 다섯 개 태그 스키마는 **≈95 %**의 FinOps 보고 요구를 충족합니다.

경험 법칙: 공급업체가 권장하는 추가 42개의 태그는 구체적인 질문에 대한 답이 필요할 때만 만들고, 사전에 만들지 마세요.

태그 전략 성숙도 곡선

1. 단순하게 시작 – 위의 다섯 개 태그 스키마를 채택합니다.
2. 반복 – 구체적이고 정당화된 필요가 생길 때만 추가 태그를 도입합니다.
3. 문서는 짧게 – 태깅 RFC가 세 페이지를 초과한다면 다시 작성하세요. 짧은 문서가 더 배포하기 쉽습니다.

Tags: AWS FinOps CloudCost DevOps Tagging InfrastructureAsCode IndiaSaaS Engineering Founders