AWS FinOps Agent로 비용 분석 자동화 파이프라인 구축하기
들어가며 AWS를 사용하는 프로젝트에서 비용 관리는 필수적이지만, 매일 콘솔에 접속해서 비용을 확인하고 분석하는 것은 비효율적이다. Farmily 프로젝트를 진행하며 AWS FinOps Agent를 활용해 비용 데이터 수집부터 분석, 리포트 생성, Slack 전송까지 전 과정을 자동화했다. 이 글에서는 FinOps 자동화 파이프라인을 어떻게 구축했는지, 그리고 실제로 어떤 인사이트를 얻을 수 있었는지 공유한다. 1. FinOps 자동화 파이프라인 아키텍처 전체 자동화 흐름은 다음과 같다: AWS 비용 데이터 → FinOps Agent 분석 → HTML 리포트 생성 → Slack 전송 이 흐름을 매일, 매월, 그리고 임계값 초과 시 자동으로 실행하도록 구성했다. 1.1 핵심 구성 요소 FinOps Agent AWS 비용 데이터를 조회하고 분석해서 리포트를 만들어 Slack으로 보내는 AI 에이전트다. 사람이 콘솔에 직접 들어가 확인하던 작업을 완전히 자동화했다. Automations (트리거) 에이전트가 언제 실행될지를 정의하는 자동화 트리거다. 시간 기반(CRON) 2개와 이벤트 기반(COSTANOMALY) 1개, 총 3종으로 구성했다. Memory 리포트 작성 기준을 저장해둔 파일이다. farmilyreportstandards에 다음 항목들이 저장된다: 리포트 11개 섹션 목록 데이터 수집 순서 형식 규칙 (한국어, HTML, 전송 방식) 리포트 (HTML Artifact) 에이전트가 생성하는 결과물이다. AWS Cloudscape 스타일의 인터랙티브 HTML 파일로, Slack에 파일로 첨부되어 전달된다. 2. 자동화 트리거 전략 세 가지 트리거를 통해 상황에 맞는 비용 리포트를 받을 수 있도록 설계했다. 이름 트리거 방식 실행 시점 Farmily Monthly Cost Report CRON 매월 1일 오전 9시 (KST) Daily AWS Cost Report Slack CRON 매일 오전 9시 (KST) Farmily Cost Threshold Slack Alert COSTANOMALY MTD 비용이 $50 단위 초과 시 즉시 2.1 시간 기반 트리거 (CRON) 정해진 시간에 무조건 실행되는 방식이다. EventBridge 스케줄러를 기반으로 하며, UTC 기준이기 때문에 KST(UTC+9)로 변환해서 설정했다. 매일 오전 9시: cron(0 0 ? ) 매월 1일 오전 9시: cron(0 0 1 ? ) 2.2 이벤트 기반 트리거 (COSTANOMALY) 시간과 무관하게 AWS 비용 이상 감지 이벤트가 발생하면 즉시 실행된다. $50 단위 임계값 초과를 감지해 트리거하며, "언제"가 아니라 "무슨 일이 생겼을 때" 동작한다. 예를 들어, 이번 달 누적 비용(MTD)이 $150에서 $200을 넘어가는 순간 자동으로 경고 리포트가 발송된다. 3. 에이전트 실행 흐름 자동화가 트리거되면 다음 단계를 거쳐 리포트가 생성된다. Step 1: 에이전트 실행 트리거가 발생하면 FinOps Agent가 깨어나 Memory에서 리포트 기준(farmilyreportstandards)을 로드한다. Step 2: AWS Cost Explorer API 호출 다음 순서로 비용 데이터를 순차 조회한다: 서비스별 비용 (SERVICE 차원) 리전별 비용 (REGION 차원) USAGETYPE 상세 비용 비용 예측 (Forecast) Step 3: 분석 및 리포트 생성 수집한 데이터를 바탕으로 리포트를 생성한다: 월간: 11개 섹션으로 구성된 종합 HTML 리포트 일간: 핵심 지표 요약 리포트 임계값 초과: 경고 메시지 및 원인 분석 Step 4: Slack 전송 생성된 HTML 파일을 첨부하고 한국어 요약 메시지와 함께 Slack 채널로 전송한다. 4. Memory를 활용한 일관성 유지 자동화 실행 시 에이전트는 이전 대화를 기억하지 못한다. 그래서 "어떤 형식으로 만들어라"는 기준을 Memory 파일에 저장해두면, 매번 실행될 때마다 그 기준을 읽고 동일한 품질의 리포트를 만들 수 있다. 대화에서 기준 확정 → Memory 저장 → 프롬프트에 "Memory 준수" 명시 → 실행 시마다 동일 기준 적용 이를 통해 사람이 직접 지시하지 않아도 자동화가 일관된 품질의 리포트를 생성할 수 있다. 5. 11개 섹션으로 구성된 종합 분석 프롬프트 월간 리포트는 Cloud FinOps 프레임워크를 기반으로 11개 섹션으로 구성된다. 각 섹션은 비용 최적화를 위한 구체적인 인사이트를 제공한다. 섹션 1: 현재 비용 현황 분석 전체 비용 파악 총 누적 비용: 프로젝트 시작부터 현재까지 총 지출 금액 월별 비용 추이: 최근 6개월 월별 지출 그래프 (증가/감소 추세) 일별 평균 비용: 최근 30일 기준 하루 평균 지출 예상 월간 비용: 현재 추세로 이번 달 예상 총액 서비스별 비용 분석 비용 순서대로 모든 AWS 서비스를 나열하고 각 서비스의 총 비용, 전체 비용 대비 비율, 주요 과금 요소, 비용 증가/감소 추세를 분석한다. 특히 EKS, RDS, ALB/NLB, VPC, Lambda, S3, CloudWatch, Route53, Bedrock, ECR 등 주요 서비스를 상세하게 분석한다. 리전별 비용 분석 서울 리전 (apnortheast2): Production 환경 비용 도쿄 리전 (apnortheast1): DR 환경 비용 기타 리전: useast1 (Route53 Health Check 등) 섹션 2: FinOps Big Five 분석 Rightsizing (적정 크기 조정) 컴퓨팅 리소스의 실제 사용률과 프로비저닝을 비교 분석한다. EKS Worker Nodes의 CPU/Memory 평균 사용률, RDS 인스턴스의 CPU/Memory/Connection 사용률, Lambda 함수의 메모리 설정 대비 실제 사용량을 확인한다. 과다 프로비저닝된 리소스는 다운사이징, 부족한 리소스는 업사이징을 제안한다. Scheduling (스케줄링) 상시 운영 중인 리소스를 식별하고 절감 시나리오를 제시한다. DR 환경 Warm Standby를 24/7 운영할지 주간만 운영할지, 개발/테스트 환경을 야간/주말에 중지할 수 있는지, 배치 작업을 스팟 인스턴스로 전환할 수 있는지 검토한다. Pricing Model (요금 모델) 현재 사용 중인 요금 모델을 분석하고 최적화 기회를 제시한다. OnDemand, Reserved Instances, Savings Plans, Spot Instances의 비율을 확인하고, RI/SP 전환 시 절감 효과를 1년/3년 약정으로 비교한다. Storage Tier (스토리지 계층화) S3 스토리지를 분석한다. 버킷별 용량과 접근 빈도를 확인하고, Lifecycle Policy 적용 현황을 점검한다. Standard에서 IA, 그리고 Glacier로 전환할 수 있는 기회를 찾는다. EBS/RDS 스토리지의 경우 gp3와 gp2의 비용을 비교하고, IOPS 프로비저닝 대비 실제 사용량을 확인한다. Monitoring (모니터링 최적화) CloudWatch 비용을 분석한다. 커스텀 지표 개수, 로그 보관 기간, 대시보드/알람 개수를 확인하고 최적 Retention을 제안한다. Container Insights의 필요 여부도 비용 대비 효용성 관점에서 재평가한다. 섹션 3: EKS/Container 비용 심층 분석 Kubernetes 환경의 비용을 Podlevel, Nodelevel, Data Transfer 세 가지 관점에서 분석한다. Podlevel 비용 Namespace별, Deployment별로 비용을 추정한다. farmilyapi, farmilyappai 등의 CPU/Memory Request, Limit, 실제 사용량을 비교하고 Resource Request/Limit 조정을 제안한다. Vertical Pod Autoscaler(VPA) 도입도 검토한다. Nodelevel 비용 서울 Production 환경에서는 Karpenter를 사용하는데, 노드 효율성을 평가하고 인스턴스 타입 믹스(t3, c6i, m6i 등)를 분석한다. Spot과 OnDemand의 비율도 확인한다. 도쿄 DR 환경의 경우 현재 Node Group 1노드(t3.medium)를 24/7 운영 중인데, Fargate Warm Standby로 전환하면 사용 시에만 과금되는 장점이 있다. Data Transfer 비용 인터넷 송신(Transfer Out) 비용과 리전 간 전송 비용을 분석한다. ALB에서 사용자로 가는 트래픽, ECR Pull 트래픽, RDS CrossRegion Replication(서울→도쿄) 등을 확인한다. CloudFront 도입이나 VPC Endpoint를 통한 AWS 서비스 통신으로 Transfer 비용을 절감할 수 있는지 검토한다. 섹션 4: DR 비용 최적화 Farmily는 서울도쿄 간 Warm Standby 전략을 사용 중이다. 현재 DR 전략의 비용을 평가하고 대안을 제시한다. 현재 DR 전략 평가 도쿄 EKS 노드, 도쿄 RDS Replica, 기타 리소스(ALB, 네트워크)의 월 비용을 합산하여 총 DR 비용을 산출한다. 현재 RTO 15분, RPO 1분 목표를 달성하기 위해 Warm Standby가 필요한데, 만약 RTO를 4시간으로 늘릴 수 있다면 Pilot Light로 전환하여 약 70%를 절감할 수 있다. DR 계층별 비용 비교 전략 RTO 월 비용 절감액 비고 Backup & Restore 24시간 $50 $XXX 스냅샷만 Pilot Light 14시간 $200 $XXX RDS만 대기 Warm Standby (현재) 15분 $XXX 1노드 상시 운영 ActiveActive 섹션 5: AI/ML 비용 분석 Bedrock 사용 현황 모델별(Claude, Titan 등) 사용량을 토큰 수로 파악하고, API 호출 빈도를 시간당/일간으로 확인한다. 평균 응답 토큰 수를 Input/Output 비율로 분석한다. 최적화 기회 캐싱 전략으로 반복 질문을 캐싱하거나, Prompt 최적화로 토큰 수를 줄이거나, 저렴한 모델로 전환 가능한 작업을 식별한다. Lambda 함수 비용 farmilyselectphoto, farmilycardrenderer 등의 호출 수와 실행 시간을 분석하고, 메모리 설정 대비 실제 사용량을 확인한다. Provisioned Concurrency의 필요 여부와 메모리 크기 조정을 성능 대비 비용 관점에서 검토한다. 섹션 6: 낭비 요소 탐지 유휴 리소스 Detached 상태의 EBS 볼륨, 미할당 Elastic IP(시간당 과금됨), 오래된 AMI/스냅샷, 빈 S3 버킷, 사용하지 않는 Load Balancer 등을 식별한다. 비정상 패턴 탐지 특정 날짜에 비용이 2배 이상 증가한 구간의 원인을 분석하고, 매주 특정 시간대의 과도한 Lambda 호출 같은 주기적 낭비를 식별한다. 예상보다 높은 Transfer Out은 공격이나 오류 가능성을 의미할 수 있다. 섹션 7: 실행 가능한 권장 사항 각 권장 사항마다 우선순위(High/Medium/Low), 예상 절감액(월간 $), 구현 난이도(쉬움/보통/어려움), 리스크(서비스 영향도), 실행 단계(구체적 작업 목록)를 제공한다. 예시: 권장 사항 1: RDS 인스턴스 다운사이징 우선순위: High 예상 절감: 월 $120 (연 $1,440) 난이도: 쉬움 (10분 작업) 리스크: 낮음 (CPU 사용률 15% → 30%로 증가하지만 여유 충분) 실행 단계: 1. 스냅샷 생성 (백업) 2. db.t3.medium → db.t3.small 변경 3. 1주일 모니터링 4. 성능 이상 없으면 확정 섹션 8: FinOps KPI 제시 비용 효율성 Unit Cost: 사용자 1명당 월 비용 Transaction Cost: API 요청 1만 건당 비용 Cost per Feature: 주요 기능별 비용 배분 최적화 진행도 절감 실현율: (절감 실행액 / 식별된 총 절감 기회) × 100 RI/SP 커버리지: (약정 적용 시간 / 전체 사용 시간) × 100 낭비율: (유휴 리소스 비용 / 총 비용) × 100 목표 설정 낭비율 5% 이하 RI 커버리지 70% 이상 월 비용 증가율 섹션 9: Unit Economics & 비즈니스 가치 비용 대비 가치 CAC(Customer Acquisition Cost), LTV(Lifetime Value), LTV/CAC 비율(3 이상 유지 목표)을 계산한다. 기능별 ROI 각 주요 기능의 비용 대비 비즈니스 기여도를 평가한다. AI 추천 기능은 Bedrock 비용 대비 사용자 참여도 증가로, 실시간 알림은 Lambda + SNS 비용 대비 이탈률 감소로, DR 환경은 Warm Standby 비용 대비 서비스 신뢰도 가치로 측정한다. ROI가 1 미만인 기능은 축소/제거를 검토하고, ROI가 3 이상인 기능은 투자를 확대한다. 섹션 10: 보고서 형식 Executive Summary (경영진용) 총 비용 현황을 1문장으로 요약하고, Top 3 비용 서비스를 각 1줄로 정리한다. 즉시 실행 가능한 절감 방안 Top 3를 총 절감액과 함께 제시한다. Detailed Analysis (실무진용) 서비스별 상세 분석을 표와 그래프로 제공하고, FinOps Big Five 각 항목별 권장 사항을 나열한다. 단계별 실행 계획을 30일/60일/90일로 구분하여 제안한다. Appendix 전체 리소스 목록, 비용 산출 근거, 참고 문서 링크를 첨부한다. 섹션 11: FinOps 운영 프로세스 분석 후 지속적인 운영을 위한 사이클을 제안한다. Inform (알림) 매주 비용 이상 패턴 알림 예산 대비 진행률 Optimize (최적화) 매월 권장 사항 실행 RI/SP 갱신 검토 Operate (운영) 분기별 전체 FinOps 전략 재평가 목표 KPI 조정 6. 리포트 형식을 HTML로 선택한 이유 여러 형식을 비교한 결과, HTML을 선택했다. 형식 특징 텍스트 메시지 간단하지만 표나 차트 표현 불가 PDF 정적이라 인터랙션 없음 HTML 테이블 정렬, 탭 전환, 차트 hover 등 인터랙티브 가능 Slack에 HTML 파일로 첨부하면 팀원들이 다운로드해서 브라우저로 열어볼 수 있다. 데이터를 직접 탐색하면서 필요한 정보를 찾을 수 있다는 점이 큰 장점이다. 7. 실제 리포트 결과 2026년 6월 월간 리포트를 통해 얻은 주요 인사이트다. 비용 현황 6월 총 비용과 전월 대비 증가율 확인 주요 비용 서비스: EKS, RDS, Bedrock 순 즉시 실행 가능한 최적화 기회 1. RDS 다운사이징을 통한 월 절감 2. DR 환경 Pilot Light 전환 검토 3. CloudWatch 로그 보관 기간 조정 FinOps KPI 낭비율, RI 커버리지, 사용자 1명당 월 비용 등의 지표를 대시보드로 확인 8. 임시 리포트 요청 방법 자동화 외에 임시로 리포트가 필요할 때는 에이전트에게 직접 요청하면 된다. "이번 달 리포트 만들어줘" 에이전트가 Memory에서 기준을 읽어 자동화와 동일한 형식으로 만들어준다: "이번 달 리포트 만들어줘" → Memory 로드 → 데이터 수집 → HTML 생성 → Slack 전송 9. 얻은 교훈 성공 요인 Memory를 활용한 일관성 유지 자동화마다 동일한 품질의 리포트를 생성할 수 있었다. 프롬프트 버전 관리도 용이했다. 3가지 트리거 전략 정기 리포트(월간/일간)와 이상 감지를 조합해서 완벽한 커버리지를 확보했다. 비용 급증 시 즉시 대응할 수 있었다. HTML 인터랙티브 리포트 팀원들이 직접 탐색하면서 인사이트를 발견할 수 있었다. 표 정렬, 차트 hover 등의 UX가 큰 도움이 되었다. 마치며 AWS FinOps Agent를 활용한 비용 분석 자동화로 다음과 같은 효과를 얻었다. 먼저 시간을 크게 절감했다. 매일 30분씩 소요되던 비용 확인 작업을 완전히 자동화했다. 인사이트도 향상되었다. 11개 섹션의 체계적 분석을 통해 놓치고 있던 최적화 기회를 발견할 수 있었다. 비용 임계값 초과 시 실시간 알림을 받아 빠르게 대응할 수 있게 되었다. 특히 Cloud FinOps 프레임워크 기반의 체계적인 11개 섹션 분석을 통해 단순 비용 확인을 넘어 실행 가능한 최적화 방안을 도출할 수 있었다. Rightsizing, Scheduling, Pricing Model, Storage Tier, Monitoring 등 FinOps Big Five를 기반으로 한 분석은 놓치기 쉬운 절감 기회를 발견하는 데 큰 도움이 되었다.
