클라우드 비용 줄줄 새는 이유, '이것' 때문입니다 (AWS 자산 관리의 모든 것)

클라우드를 사용하면서 "어? 이 EC2 인스턴스는 누가 만든 거지?", "이 S3 버킷은 왜 아직도 남아있을까?" 하는 생각, 한 번쯤 해보셨을 겁니다. 🤔 분명 리소스를 몇 개 안 만든 것 같은데, 매달 청구서를 보면 깜짝 놀라곤 하죠.

 

이 문제의 핵심은 바로 '자산 관리'에 있습니다. 예전처럼 데이터센터에 서버를 들여놓던 시절에는 엑셀 시트에 자산 목록을 만들어 관리하는 게 가능했습니다. 하지만 클릭 몇 번으로 서버 수십 대가 뚝딱 만들어지고 사라지는 클라우드 환경에서는 그런 방식은 절대 통하지 않습니다. 낡은 지도를 들고 시시각각 변하는 도시를 탐험하는 것과 같죠. 🗺️➡️🏙️

 

AWS는 이런 동적인 클라우드 환경에 딱 맞는, 현대적인 자산 관리 솔루션을 제시합니다. 더 이상 수동으로 관리하지 마세요! AWS가 어떻게 이 문제를 해결하는지, 그 전체적인 그림을 알기 쉽게 설명해 드리겠습니다.

---

🎯 AWS 자산 관리의 핵심 사이클: 식별 → 제어 → 추적 → 최적화

AWS의 자산 관리 철학은 간단한 4단계 사이클로 요약할 수 있습니다. 각 단계가 유기적으로 연결되어 완벽한 관리 체계를 만들어냅니다.

1. 🔍 식별 (Identify): 우리 회사 계정에 어떤 자산이 있는지 완벽하게 파악합니다.
2. ⚙️ 제어 (Control): 자산을 일관된 기준으로 분류하고, 정책에 맞게 생성되도록 통제합니다.
3. 🕵️ 추적 (Track): 자산의 모든 변경 사항과 규정 준수 여부를 감시합니다.
4. 💰 최적화 (Optimize): 자산과 비용을 연결해 낭비를 줄이고 효율을 극대화합니다.

이 사이클을 AWS의 어떤 서비스들이 담당하는지 하나씩 살펴보겠습니다.

1단계: 🔍 식별 - "내 모든 재산 목록을 실시간으로"

모든 관리의 시작은 내가 무엇을 가지고 있는지 아는 것입니다. 숨어있는 자산, 잊힌 자산까지 모두 찾아내야 합니다.

✅ AWS Config: 클라우드 자산의 '주민등록등본'

AWS Config는 여러분의 AWS 계정에 있는 모든 리소스의 구성 정보를 스냅샷처럼 찍어 상세히 기록하고, 변경될 때마다 그 이력을 자동으로 추적하는 서비스입니다. 이게 왜 중요할까요?

• 실시간 인벤토리: "현재 우리 계정에 떠 있는 모든 EC2 인스턴스 목록과 사양을 알려줘!"라고 물으면 즉시 답을 줍니다.
• 변경 이력 추적: "누가 이 보안 그룹 설정을 어젯밤에 바꿨지?" 와 같은 질문에 대한 답을 찾을 수 있습니다.

[AWS Config가 기록하는 데이터 예시 (EC2 인스턴스)] 아래처럼 리소스 하나하나에 대한 모든 설정값이 JSON 형태로 상세하게 기록됩니다.

{
  "configurationItem": {
    "version": "1.3",
    "accountId": "123456789012",
    "configurationItemCaptureTime": "2025-11-08T00:39:00.000Z",
    "configurationItemStatus": "OK",
    "resourceType": "AWS::EC2::Instance",
    "resourceId": "i-0123456789abcdef0",
    "resourceName": "MyWebServer",
    "ARN": "arn:aws:ec2:ap-northeast-2:123456789012:instance/i-0123456789abcdef0",
    "configuration": {
      "instanceId": "i-0123456789abcdef0",
      "imageId": "ami-0abcdef1234567890",
      "instanceType": "t3.micro",
      "privateIpAddress": "172.31.16.8",
      "vpcId": "vpc-0a1b2c3d4e5f67890",
      "subnetId": "subnet-0a9b8c7d6e5f43210",
      "tags": [
        {
          "key": "Project",
          "value": "Phoenix"
        },
        {
          "key": "Owner",
          "value": "dev-team"
        }
      ]
    }
  }
}

✅ AWS Systems Manager (Inventory): 자산의 '내부'까지 들여다보기

AWS Config가 리소스의 '외부' 설정(인스턴스 타입, VPC 등)을 본다면, Systems Manager는 EC2 인스턴스 '내부' OS 수준의 정보(설치된 소프트웨어, 패치 상태 등)를 수집합니다. "Nginx 1.20 버전이 설치된 서버가 어디 있지?" 같은 질문에 답할 수 있게 되죠. 🩺

---

2단계: ⚙️ 제어 - "우후죽순 생기는 자산에 질서 부여하기"

자산을 식별했다면, 이제 의미 있는 단위로 묶고 관리할 기준이 필요합니다.

✅ 태깅(Tagging): 자산 관리의 알파이자 오메가 ⭐

가장 기본이지만, 가장 중요한 원칙입니다. 모든 AWS 리소스에 일관된 규칙으로 '꼬리표(Tag)'를 붙이는 것입니다. 태그가 없다면 자산 관리는 불가능에 가깝습니다.

예를 들어, 모든 리소스에 아래와 같은 태그를 붙이는 정책을 세울 수 있습니다.

• Project: 이 리소스가 속한 프로젝트 (예: Phoenix, New-Mobile-App)
• Owner: 관리 책임자 또는 팀 (예: dev-team, data-science-team)
• Environment: 개발, 스테이징, 운영 환경 구분 (예: dev, stg, prod)
• CostCenter: 비용을 부담하는 부서 코드 (예: CC-1234)

이렇게 태그를 잘 붙여두면 나중에 비용을 추적하거나 특정 프로젝트의 리소스만 찾아낼 때 엄청난 위력을 발휘합니다.

✅ 코드로서의 인프라 (IaC): 자산 생성부터 '코드로' 관리하기

실수로 잘못된 사양의 EC2를 만들거나, 꼭 필요한 태그를 빠뜨리는 일을 어떻게 막을 수 있을까요? 정답은 자동화입니다. AWS CloudFormation이나 Terraform 같은 IaC 도구를 사용하면 인프라 구성을 코드로 정의할 수 있습니다.

[CloudFormation 코드 예시 (태그 포함)] 아래 코드는 Project와 Owner 태그가 붙은 S3 버킷을 생성하는 것을 보장합니다. 사람은 코드를 실행만 할 뿐, 수동으로 설정할 여지가 없습니다.

AWSTemplateFormatVersion: '2010-09-09'
Description: A sample template to create an S3 bucket with standard tags.

Resources:
  MyS3Bucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: my-unique-project-phoenix-bucket-2025
      Tags:
        - Key: Project
          Value: Phoenix
        - Key: Owner
          Value: dev-team

Outputs:
  BucketName:
    Value: !Ref MyS3Bucket
    Description: Name of the S3 bucket created.

이렇게 하면 모든 자산이 처음부터 표준화된 방식으로, 필요한 태그를 모두 가진 채로 생성됩니다. 이것이 바로 정책 기반의 제어입니다.

---

3단계: 🕵️ 추적 - "모든 변경 사항을 손바닥 위에"

자산이 생성되고 사용되는 동안, 누가 무엇을 바꾸는지, 정해진 보안 규칙은 잘 지키고 있는지 계속 감시해야 합니다.

✅ AWS CloudTrail: 모든 것을 기록하는 '블랙박스'

CloudTrail은 여러분의 AWS 계정에서 일어나는 모든 API 호출을 기록하는 서비스입니다. 간단히 말해, "누가, 언제, 어디서, 무엇을 했는지"에 대한 모든 로그를 남깁니다.

• "어제 새벽에 누가 운영 DB의 보안 그룹을 열었지?" 😱
• "이 IAM 사용자는 최근에 어떤 작업을 수행했지?"

CloudTrail 로그를 보면 모든 것을 추적할 수 있어 보안 감사와 운영 투명성 확보에 필수적입니다.

✅ AWS Config Rules: 우리 회사의 '규칙 지킴이'

미리 정의된 규칙을 위반하는 리소스가 생기면 즉시 알려주는 자동 검사관입니다. 예를 들어, 다음과 같은 규칙을 설정할 수 있습니다.

• s3-bucket-public-read-prohibited: 모든 S3 버킷은 공개 읽기 권한을 가지면 안 된다.
• encrypted-volumes: 모든 EC2에 연결된 EBS 볼륨은 암호화되어야 한다.

규칙을 위반하는 리소스가 발견되면 즉시 알림을 받고 수정할 수 있어, 보안 및 규정 준수 상태를 높은 수준으로 유지할 수 있습니다.

---

4단계: 💰 최적화 - "태그, 비용과 만나다"

자산 관리가 결국 빛을 발하는 순간은 비용 관리와 만났을 때입니다. 2단계에서 열심히 붙인 태그가 여기서 결정적인 역할을 합니다.

✅ AWS Cost Explorer: 비용을 파헤치는 '현미경'

Cost Explorer는 태그를 기반으로 비용을 분석하고 시각화해주는 강력한 도구입니다.

• "이번 달 Project:Phoenix에서 발생한 비용은 얼마지?"
• Environment:dev 태그가 붙은 개발 환경 리소스들의 비용 추이가 어떻게 되지?"

이런 질문들에 대한 답을 그래프와 함께 명확하게 보여주어, 어떤 서비스, 어떤 프로젝트에서 비용이 많이 발생하는지 직관적으로 파악하고 최적화 포인트를 찾을 수 있게 해줍니다.

---

😵‍💫 우리가 하면 안 되는 것: '엑셀' 자산 관리

이 모든 강력한 도구를 두고 왜 아직도 엑셀 시트에 자산 목록을 수기로 관리하려 하시나요?

• 정확성 문제: 사람은 반드시 실수하고, 누락합니다.
• 실시간성 부재: 엑셀을 업데이트하는 순간, 클라우드의 자산 상태는 또 변해 있습니다. 정보는 이미 과거의 것입니다.
• 확장성 한계: 수천, 수만 개의 자산을 엑셀로 관리하는 것은 불가능합니다.

클라우드 자산 관리는 더 이상 사람이 밤새워가며 할 일이 아닙니다. 자동화된 시스템과 정책에 맡겨야 합니다.

✨ 결론: AWS 자산 관리는 '유기적인 시스템'이다

AWS의 자산 관리는 어느 한 가지 서비스로 해결되는 것이 아닙니다.

1. 태깅(Tagging)으로 모든 자산에 정체성을 부여하고,
2. AWS Config로 중앙 인벤토리를 구축하며,
3. CloudFormation (IaC)으로 생성부터 표준을 강제하고,
4. CloudTrail로 모든 변경을 감시하며,
5. Cost Explorer로 자산과 비용을 연결해 분석하는,

이 모든 것이 맞물려 돌아가는 하나의 거대한 유기적인 시스템입니다. 이 시스템의 전체 그림을 이해하고 여러분의 환경에 맞게 구축한다면, 더 이상 유령 리소스나 예상치 못한 비용 청구서 때문에 골머리를 앓는 일은 없을 것입니다.

클라우드, 이제는 똑똑하게 관리하세요! 🚀

---