AWS Frontier Agents로 시작하는 자율 운영 – Part [3]: FinOps Agent로 비용 이상 자동 조사

이 글은 AWS Frontier Agents 시리즈의 세 번째이자 마지막 편입니다. 1편에서 배포 전 릴리스 리스크를 차단하고, 2편에서 배포 후 보안을 검증했다면, 이번 글은 운영 중인 워크로드의 비용 이상을 자동으로 조사하는 AWS FinOps Agent를 다룹니다.

비용 급증 알림은 받지만 “왜 올랐고 누구 책임인지”를 찾는 데는 며칠이 걸립니다. 이 글에서는 AWS FinOps Agent(Preview)가 AWS Cost Anomaly Detection 알림을 AWS CloudTrail 이벤트와 자동으로 상관 분석해 근본 원인과 리소스 소유자까지 특정하고, 그 결과를 Slack으로 전달하는(Jira 티켓 생성도 지원) 파이프라인을 단계별로 구축합니다. 자연어 비용 Q&A와 정기 리포트 활용법도 함께 다룹니다.

> 블로그 시리즈 보기

Part [1]: DevOps Agent Release Management로 배포 전 리스크 차단하기
Part [2]: Security Agent로 침투 테스트를 온디맨드로 – 취약점 발견부터 수정 PR까지
Part [3]: FinOps Agent로 비용 이상 자동 조사 – 알림에서 근본 원인까지

참고: AWS Security Agent의 온디맨드 침투 테스트는 정식 출시(GA)되었으며, 위협 모델링과 전체 리포지토리 코드 리뷰 등 일부 기능은 2026년 7월 기준 Preview로 제공됩니다. 기능과 화면 구성은 변경될 수 있습니다. 또한 침투 테스트와 코드 스캐닝은 2026년 6월 발표된 AWS Continuum에서 같은 기능이 다른 이름으로도 제공되므로, AWS 자료에서 두 이름이 함께 나타날 수 있습니다.

들어가며: 비용 알림과 원인 사이의 간극

1편과 2편을 거치며 AnyCompany의 주문 서비스는 배포 전 릴리스 관문과 배포 후 보안 검증을 모두 갖췄습니다. 이제 애플리케이션은 안정적으로 배포되고 안전하게 운영됩니다. 그러던 어느 월요일 아침, AnyCompany의 플랫폼팀에 비용 급증 알림이 도착합니다. 지난 주말 사이 특정 계정의 비용이 평소의 세 배로 뛰었습니다.

여기서 익숙한 고생이 시작됩니다.

AWS Cost Anomaly Detection이 이상을 알렸지만, 알림은 “얼마가 올랐다”까지만 말해줍니다.
담당자가 AWS Cost Explorer를 열어 어떤 서비스·리전·사용 유형에서 증가했는지 파고듭니다.
원인으로 의심되는 리소스를 찾으면, 이번엔 AWS CloudTrail을 뒤져 누가 언제 무엇을 했는지 추적합니다.
마침내 리소스를 특정해도, 태깅이 부실하면 “이게 누구 것인지” 알아내는 데 또 시간이 듭니다.

이 과정은 짧게는 몇 시간, 길게는 며칠이 걸립니다. 그 사이 비용은 계속 발생합니다. AWS FinOps Agent는 이 조사 과정 전체를 자동화합니다. 이상 탐지 알림을 CloudTrail 이벤트와 상관 분석해 원인이 된 변경을 짚어내고, 근본 원인과 책임 소유자를 담은 조사 요약을 생성해 Slack이나 Jira로 전달합니다.

참고: Amazon Bedrock AgentCore로 FinOps 에이전트를 직접 구축하는 글로벌 블로그 사례가 있으나, 이 글에서 다루는 AWS FinOps Agent는 그와 달리 콘솔에서 구성만 하면 되는 AWS 관리형 제품입니다.

FinOps Agent의 4가지 기능

AWS FinOps Agent는 중앙 FinOps 팀이 사용하는 것과 동일한 데이터 소스를 기반으로 네 가지 기능을 제공합니다.

기능	무엇을 하는가	트리거
비용 이상 자동 조사	Cost Anomaly Detection 알림을 CloudTrail과 상관 분석해 근본 원인·소유자 특정	이상 탐지 시
자연어 비용 Q&A	“지난달 우리 팀 비용이 왜 올랐어?” 같은 질문에 실제 비용 데이터 기반으로 답변	온디맨드
정기 리포트	HTML·PDF·PPT 형식의 발표 가능한 리포트를 주기적으로 생성	스케줄
최적화 권고 요약	Cost Optimization Hub·Compute Optimizer 권고를 취합해 Jira 티켓으로 요약	스케줄/온디맨드

세 가지 실행 모드(스케줄, 이상 탐지 시, 온디맨드)로 동작하며, 데이터 소스는 다음과 같이 맞물립니다.

그림 1. AWS FinOps Agent 비용 이상 자동 조사 아키텍처 — Cost Explorer·Cost Anomaly Detection·CloudTrail·Cost Optimization Hub·Compute Optimizer를 입력으로, 조직 컨텍스트 파일을 참조해 조사·응답·리포트를 생성하고 Slack·Jira로 전달하는 흐름

데이터 소스	역할
AWS Cost Explorer	비용·사용량 데이터의 기반
AWS Cost Anomaly Detection	이상 조사를 트리거하는 알림
AWS CloudTrail	근본 원인 분석을 위한 이벤트 상관
AWS Cost Optimization Hub	최적화 권고
AWS Compute Optimizer	컴퓨트 리소스 최적화 권고

핸즈온 1: 비용 이상 자동 조사 파이프라인 구축

AnyCompany의 비용 급증 시나리오를 자동 조사 파이프라인으로 재현해 보겠습니다. 자동화를 설정해 두면 이후의 이상은 알림 즉시 조사되고, 이미 발생한 이상은 온디맨드로 조사할 수 있습니다.

1단계: Agent 생성과 사전 준비

먼저 FinOps Agent 콘솔에서(us-east-1 리전) 생성 마법사로 첫 Agent를 만듭니다. 마법사가 필요한 IAM 역할과 정책을 원클릭으로 자동 생성하므로 IAM을 수동으로 구성할 필요가 없습니다. 생성 과정에서 Slack과 Jira를 선택적으로 연결하면 Agent가 티켓을 만들고 메시지를 게시할 수 있습니다. 생성이 끝나면 콘솔에서 Agent의 웹 애플리케이션을 엽니다.

사전 조건이 하나 있습니다 — AWS Cost Anomaly Detection 모니터가 최소 하나 있어야 합니다. Agent는 이 모니터가 만들어내는 이상을 조사합니다. 다행히 대부분의 계정에는 AWS가 서비스 단위 기본 모니터(Default-Services-Monitor)를 자동 생성해 두므로 콘솔에서 존재 여부만 확인하면 됩니다. 참고로 Agent는 us-east-1에서 호스팅되며 GovCloud·중국 리전을 제외한 모든 리전의 비용 데이터를 분석합니다. 관리 계정으로 만들면 조직 전체를, 멤버 계정으로 만들면 해당 계정 범위를 다룹니다.

그림 2. 사전 조건인 AWS Cost Anomaly Detection 모니터 — 계정에 기본 제공되는 Default-Services-Monitor가 AWS 서비스 단위로 이상을 탐지하는 화면

2단계: 조직 컨텍스트 업로드

이 단계가 조사 품질을 좌우합니다. 웹 애플리케이션에 조직의 맥락을 담은 컨텍스트 파일을 업로드하면, Agent가 비용 데이터를 조직의 언어로 해석합니다. 컨텍스트가 없으면 일반적인 AWS 데이터로만 동작하지만, 있으면 응답·리포트·티켓이 조직의 계정·소유자·리뷰 주기를 반영합니다.

account-to-team.csv (예시)

account_id	team_name	team_lead	email
111111111111	주문팀	김주문	order-lead@anycompany.example.com
222222222222	주문팀	김주문	order-lead@anycompany.example.com
333333333333	결제팀	이결제	payment-lead@anycompany.example.com

가장 먼저 올릴 것은 계정-팀 매핑입니다. Agent가 각 계정의 비용을 소유 팀에 귀속시키고, Jira 티켓을 담당자에게 라우팅하는 근거가 됩니다.

이 매핑이 있으면 Agent는 “계정 111111111111의 비용 급증”을 “주문팀의 비용 급증”으로 해석합니다. 이 밖에도 조직 구조(비즈니스 유닛별 비용 배분), 커스텀 지침(“env=production 계정의 EC2 rightsizing 권고는 무시”, “Jira 티켓은 FINOPS 프로젝트에 생성”), 리포트 템플릿 등을 컨텍스트 파일로 올릴 수 있습니다.

그림 3. 웹 애플리케이션의 컨텍스트 파일 화면 — 업로드한 account-to-team.csv가 Active 상태로 등록되어 이후의 조사·응답·리포트에 반영되는 화면

주의: 컨텍스트 파일은 Agent에 접근 가능한 모든 사용자에게 보입니다. 민감 정보나 개인정보가 담긴 파일은 업로드하지 마세요.

3단계: 자연어로 이벤트 자동 조사 설정

FinOps Agent의 자동화는 별도 설정 폼이 아니라 채팅에 자연어로 요청해 만듭니다. 웹 애플리케이션 채팅에 “무엇을 감지하면, 무엇을 조사해서, 어디로 보내라”를 한 문장으로 서술하면, Agent가 이를 일회성 조사가 아닌 지속적인 자동화 설정 요청으로 인식해 이벤트 기반 자동화를 생성합니다.

프로덕션 모니터에서 $100 이상의 비용 이상이 감지되면,
근본 원인을 조사하고 요약을 #finops-alerts 채널에 게시해 주세요.

이 요청을 받으면 Agent는 COST_ANOMALY 트리거를 가진 자동화를 만들고, 내부적으로 계정에 EventBridge 관리형 규칙을 프로비저닝합니다. 이후 Cost Anomaly Detection이 조건에 맞는 이상 이벤트를 낼 때마다 Agent가 자동으로 조사를 수행하고 지정한 Slack 채널에 요약을 게시합니다. Slack 게시와 (설정 시 사전 승인한) Jira 티켓 생성은 이벤트마다 별도 승인 없이 실행됩니다.

생성된 자동화는 웹 애플리케이션의 자동화(Automations) 워크스페이스에서 트리거 유형·상태·마지막 실행 시각과 함께 확인·관리(활성/비활성 전환, 삭제, 실행 이력 검토)할 수 있습니다.

4단계: 조사 실행

3단계의 자동화는 이상이 새로 감지될 때마다 스스로 동작하지만, 이미 발생한 이상은 온디맨드로도 조사할 수 있습니다. 자동화 트리거를 기다리지 않고 채팅에서 바로 요청합니다.

7월에 감지된 Amazon Bedrock 비용 이상의 근본 원인을 조사해 주세요.
각 이상의 임팩트, 사용량 대 요율 구분, 원인이 된 API 활동을 CloudTrail에서 찾아 요약해 주세요.

Agent는 Cost Anomaly Detection이 기록한 이상들을 가져와 비용 임팩트 순으로 근본 원인을 분석하고, 비용 증가가 사용량 증가·요율(토큰당 가격) 변화 중 무엇에서 왔는지 판별합니다. CloudTrail 권한이 있으면 비용 변화와 상관된 API 활동까지 이벤트 이력에서 찾습니다.

5단계: 조사 결과 분석

조사가 끝나면 여러 이상을 한 번에 정리한 조사 리포트가 대화에 표시됩니다. 상단에 계정·기간과 함께 이상 목록이 임팩트 순으로 나열되고, 각 항목은 실제 지출·예상 지출·초과액·초과율을 담습니다.

이번 조사에서 Agent는 7월의 Bedrock 이상 3건을 임팩트 순으로 정리한 뒤, 합산 임팩트($1,567.92)를 먼저 제시하고 셋 모두가 동일한 근본 원인 — 단일 IAM 사용자의 대량 InvokeModelWithResponseStream 호출 — 에서 비롯되었다고 결론지었습니다. 개별 이상을 개별 사건으로 나열하는 데 그치지 않고 여러 이상을 하나의 원인으로 묶어 해석하는 것입니다.

그림 4. 비용 이상 조사 리포트 — Bedrock 이상 3건의 합산 임팩트와, 세 건이 공유하는 단일 근본 원인이 리포트 서두에 요약된 화면

개별 이상을 펼치면 근거가 사용량 단위까지 내려갑니다. 요율은 그대로인데 캐시 쓰기 토큰 사용량만 +24,111% 늘어난 “순수 볼륨 폭증”임을 구분하고, CloudTrail에서 해당 호출을 만든 IAM 사용자·호출 시각까지 특정합니다.

그림 5. 사용량 단위 근본 원인과 CloudTrail 귀속 — 요율 변화가 아닌 사용량 폭증임을 표로 분해하고, 호출 주체를 IAM 사용자 단위로 지목한 화면

사용량 폭증 같은 사용 패턴 변화만 잡는 것이 아니라, 새 인프라가 배포되면서 생기는 비용 이상도 같은 방식으로 추적합니다.

그림 6. 신규 리소스 배포 유형의 조사 리포트 — 계정-팀 매핑이 반영된 헤더와 함께, 탐지된 이상이 서비스별 초과액·초과율 순으로 정리된다. 이번 조사에서는 OpenSearch(초과액 +$141.84) 등이 검출된 화면

여기서 탐지된 각각의 이상을 선택하면 근본 원인이 리소스·요금 단위로 구체화됩니다.

OpenSearch 이상($227.84)에 대해 Agent는 두 가지 인프라 추가가 원인임을 짚어냅니다 — us-west-2에 신규 프로비저닝된 r6g.large 인스턴스(주 원인, $179.86)와 ap-northeast-2의 신규 OpenSearch Serverless 컬렉션(월 약 $422 지속 과금). 여기서 그치지 않고 조사할 CloudTrail 이벤트(es:CreateDomain, aoss:CreateCollection)와 발생 시점, 그리고 종료된 리소스와 여전히 과금 중인 리소스까지 구분해 제시합니다.

그림 7. 개별 이상 상세 — 근본 원인이 리소스·요율(r6g.large, OCU) 단위로 분해되고, 원인 규명에 필요한 CloudTrail 이벤트와 현재 과금 상태까지 정리되는 화면

이 사례에서도 Agent는 개별 이상을 넘어 여러 이상을 묶어 해석합니다.

OpenSearch와 ElastiCache 이상이 모두 같은 계정·같은 리전(us-west-2)에서 며칠 간격(6월 2~5일)으로 시작된 “net-new 리소스 배포” 패턴임을 포착하고, 두 이상이 독립 사건이 아니라 하나의 조율된 인프라 구축일 가능성이 높다고 종합했습니다. 방치할 경우 월 약 $895의 지속 비용이 발생한다는 추정까지 덧붙습니다.

며칠 걸리던 조사가 요청 직후 자동으로 완료되어 담당자는 조사 없이 바로 대응을 시작할 수 있게 되었습니다.

참고: 근본 원인 분석의 깊이는 Agent IAM 역할에 부여된 권한에 달려 있습니다. Cost Explorer 권한만 있으면 이상 상세·영향 서비스·요율 대 사용량 분석까지, CloudTrail 권한이 추가되면 비용 변화와 상관된 API 활동 이력 검색까지 수행합니다. 이 권한은 모두 읽기 전용으로, Agent가 리소스를 변경하거나 종료하지는 않습니다.

6단계: Slack·Jira 연동

조사 요약은 3단계 자동화에서 지정한 Slack 채널로 자동 게시되며, 필요하면 Jira 티켓도 함께 생성됩니다. 이때 2단계에서 올린 계정-팀 매핑이 근거가 되어, Agent는 원인 계정을 소유 팀으로 귀속시키고 티켓을 담당자에게 연결합니다.

그림 8. Agent에 연결된 Slack 채널 — 계정 수준에 등록한 Slack 통합(integration)을 Agent 수준의 채널 연결(connection)로 바인딩하면 상태가 Active로 전환된 화면

그림 9. Slack 채널로 전달된 조사 요약 — 합산 임팩트와 이상 목록, 세 이상이 공유하는 근본 원인, 권장 조치가 하나의 메시지로 게시된 화면

이 흐름의 핵심 가치는 단순한 알림 전달이 아니라, 원인 분석이 완료된 실행 가능한 컨텍스트를 정확한 담당자에게 전달한다는 데 있습니다.

참고: Preview의 Slack 연동은 단방향 전달 전용입니다. Agent가 채널에 결과를 게시하기는 하지만 채널의 메시지를 읽거나 멘션·명령에 응답하지는 않습니다. Slack에서 대화형으로 후속 질문을 하려면 웹 애플리케이션을 사용해야 합니다.

핸즈온 2: 자연어 비용 Q&A와 정기 리포트

자연어 비용 Q&A

엔지니어는 콘솔의 복잡한 필터를 다루지 않고도 평문으로 질문할 수 있습니다.

지난달 주문팀 비용이 왜 올랐어?

컨텍스트 파일이 ‘주문팀’을 계정 집합(111111111111, 222222222222)으로 해석하므로, Agent는 해당 계정들의 실제 비용·사용 데이터를 근거로 비용 변화, 기여 서비스, 사용량 동인을 짚어 답합니다. 좋은 질문과 모호한 질문의 차이를 예로 들면 다음과 같습니다.

모호한 질문	더 나은 질문
“비용이 왜 이래?”	“지난주 프로덕션 계정에서 가장 많이 증가한 서비스 3개는?”
“많이 나왔어?”	“이번 달 주문팀 비용이 예산 대비 몇 % 수준인가?”

질문이 구체적일수록 답도 구체적입니다. 컨텍스트 파일에 팀·환경·서비스 정의가 잘 갖춰져 있으면 모호한 질문도 조직 기준으로 해석되지만, 명시적인 범위를 함께 주면 정확도가 올라갑니다.

정기 리포트

청중별로 다른 주기와 형식의 리포트를 스케줄로 생성할 수 있습니다.

경영진용: 월간 요약, PPT
형식팀별: 주간 지출 뷰, HTML
형식차지백(chargeback): 팀별 비용 배분 업데이트

리포트도 자동화와 같은 방식으로 채팅에서 자연어로 요청합니다. 주기·기간·형식·포함 항목을 한 문장에 담으면 됩니다.

매월 1일에 지난달 비용 요약 리포트를 PPT 형식으로 생성해 주세요.
서비스별 상위 5개 지출, 전월 대비 증감, 감지된 비용 이상을 포함해 주세요.

스케줄 없이 즉시 결과물을 받고 싶다면 “지난달 비용 요약을 경영진 보고용 PPT로 만들어 주세요”처럼 요청합니다. 생성된 파일은 .pptx·.pdf·.html 형식으로 채팅 응답에 첨부되고, 웹 애플리케이션 좌측의 아티팩트(Artifacts) 메뉴에도 저장됩니다.

생성 과정을 펼쳐 보면 이 결과물이 한 번에 나온 것이 아님을 알 수 있습니다. Agent는 데이터를 병렬로 수집해 슬라이드를 만든 뒤, 별도의 QA 검수 서브에이전트를 띄워 6개 슬라이드를 병렬로 다시 읽습니다. 슬라이드 간 수치 모순, 잘린 텍스트, 겹친 요소, 1픽셀 수준으로 렌더링된 차트 바처럼 사람이 발표 직전에야 발견하는 문제들이 검수 기준으로 명시되어 있습니다.

그림 10. 결과물 자체 검수 — QA 검수 서브에이전트가 수치 모순·텍스트 잘림·차트 가독성을 기준으로 슬라이드를 재검토하는 화면

실제로 이번 실행에서는 “이상 임팩트 합계 KPI가 $1,599.94로 표시되지만 상세 행의 합은 $1,598.94로 $1.00 어긋난다”, “6월 RDS 바가 $4,000 축 기준에서 1픽셀 미만으로 렌더링된다” 같은 지적이 나왔고, 지적사항을 반영해 세 차례 수정을 거친 버전(aws-cost-summary-july-2026-r3.pptx)이 최종 아티팩트로 남았습니다. 완결된 결과물을 전달한다는 Frontier Agent의 정의가 산출물 품질 검증까지 포함한다는 것을 보여주는 지점입니다.

그림 11. 생성된 월간 경영진 리포트 — 표지·경영진 요약·상위 서비스·MoM 비교·이상 탐지·권고사항 6개 슬라이드로 구성된 .pptx가 만들어진 화면

그림 12. 리포트의 핵심 수치와 아티팩트 — 총 지출·최대 지출 서비스·증가율·탐지된 이상이 요약되고, 생성된 .pptx가 아티팩트로 첨부된 화면

리포트가 “발표 가능한 형식(presentation-ready)”으로 나온다는 점이 실무에서 유용합니다. 데이터를 뽑아 슬라이드로 재가공하는 수작업이 사라집니다.

운영 고려사항 및 Preview 한계

Preview 기간 무료, GA 가격 미공개: Preview 기간에는 Agent 자체 사용에 추가 비용이 없으나, 월 사용량 한도가 있고 연계된 다른 AWS 서비스(예: 크로스 계정 조사 시 CloudWatch Logs Insights 쿼리) 사용분에는 표준 요금이 별도로 부과됩니다. 정식 출시 후 가격은 아직 공개되지 않았으므로 예산 계획 시 이 점을 감안하세요.
탐지는 실시간이 아님: 비용 데이터 반영과 이상 확정에 하루 안팎의 지연이 있고, 새로 만든 모니터는 약 10일의 학습 기간이 지나야 이상을 탐지하기 시작합니다.
리전: Agent는 us-east-1에서 호스팅되며 GovCloud·중국 리전 데이터는 분석 대상에서 제외됩니다.
멀티 어카운트 환경: AWS Organizations를 사용하는 조직이라면 결제 계정 단위의 접근 구성과 계정-팀 매핑을 컨텍스트 파일에 정리해 두어야 조사·라우팅이 제대로 동작합니다.
태깅 거버넌스가 선행 조건: 소유자 특정의 정확도는 결국 태깅 품질에 달려 있습니다. Team, Environment, Service 같은 필수 태그가 일관되게 적용되어 있지 않으면, Agent가 CloudTrail로 원인 리소스를 찾아도 “누구 것인지”를 명확히 답하기 어렵습니다. FinOps Agent 도입은 태깅 전략을 정비하는 좋은 계기이기도 합니다.
조사 결과는 출발점: 자동 조사는 사람의 추적 시간을 극적으로 줄여주지만, 재무적 의사결정(예약 인스턴스 구매, 예산 재배정 등) 전에는 결과를 검증하는 것이 바람직합니다.

시리즈 마무리: Frontier Agents 운영 모델 총정리

세 편에 걸쳐 AnyCompany의 주문 서비스를 애플리케이션 라이프사이클을 따라 살펴봤습니다. 각 단계에서 Frontier Agent가 어떤 역할을 맡았는지 정리하면 다음과 같습니다.

라이프사이클 단계	담당 Agent	핵심 역할	다룬 편
개발	Kiro	코드 작성 (프로토타입 → 프로덕션)	(시리즈 외)
배포 전	AWS DevOps Agent	릴리스 리스크 검증 (Release Management)	1편
설계~배포 후 (보안)	AWS Security Agent	위협 모델링(설계)·침투 테스트(배포 후)	2편
운영 (비용)	AWS FinOps Agent	비용 이상 조사·최적화	3편

세 Agent는 서로 다른 문제를 풀지만 공통된 동작 패턴을 공유합니다.

자연어로 조직 표준을 정의한다. DevOps Agent의 릴리스 Instructions, Security Agent의 조직 보안 요구사항, FinOps Agent의 컨텍스트 파일 — 모두 조직의 규칙을 한 번 정의하면 반복 적용됩니다.
자율적으로 실행한다. 사람이 매 단계를 지시하지 않아도 목표를 향해 스스로 조사·테스트·분석합니다.
검증된 결과와 액션을 함께 전달한다. 결과만 던지지 않고 수정 PR, Jira 티켓, Slack 메시지 같은 실행 가능한 다음 단계로 이어집니다.

도입을 검토한다면, 무료 평가판과 Preview를 활용해 저위험 워크로드부터 시작하는 것을 권합니다. 각 Agent의 판단을 며칠간 관찰하며 자연어 표준을 다듬고, 팀의 신뢰가 쌓이면 적용 범위를 넓히는 방식이 자율 Agent 도입의 안전한 경로입니다. 자율성은 신뢰를 전제로 하며, 신뢰는 관찰된 성과 위에서 자랍니다.

AI 어시스턴트가 “질문에 답하는 도구”였다면, Frontier Agent는 “결과를 만들어내는 팀의 확장”입니다. 릴리스, 보안, 비용이라는 운영의 세 축을 자율 Agent가 상시 지켜보는 구조는, 사람이 반복적 검증에서 벗어나 판단과 설계에 집중하게 하는 새로운 운영 모델의 출발점입니다.

지금 바로 시작해 보려면:

AWS 기술 블로그