AWS FinOps Agent 소개 - 클라우드 비용을 조사하는 AI

👋 안녕하세요, 기술 애호가 여러분!

저는 복잡한 기술 문제를 간단한 솔루션으로 바꾸는 것을 좋아하는 클라우드 아키텍트(Cloud Architect) Sarvar입니다. 저는 실제 기업들을 위해 AWS, Azure, DevOps, 데이터(Data), 분석(Analytics), 생성형 AI (Generative-AI) 및 에이전트형 AI (Agentic-AI)를 활용하여 실제 시스템을 구축해 왔습니다. 이 아티클 시리즈를 통해, 여러분이 숙련자이든 이제 막 시작하는 단계이든 상관없이 따라오기 쉬운 방식으로 제가 배운 것들을 공유하고자 합니다.

자, 시작해 봅시다! 🚀

여러 계정에 걸쳐 AWS 비용을 관리해 본 적이 있다면, 그 고통을 잘 아실 겁니다. 오전 9시에 밤사이 무언가 급증했다는 알림을 받습니다. Cost Explorer를 열고, 서비스별로 필터링하고, 그다음 계정별, 그다음 리전(Region)별로 필터링합니다. 그런 다음 무엇이 변경되었는지 파악하기 위해 CloudTrail로 넘어갑니다. 테스트 계정에서 새로운 인스턴스 유형(Instance type)을 실행한 개발자를 찾아낼 때쯤이면 이미 두 시간이 지나 있습니다. 그리고 그것은 단 하나의 이상 징후(Anomaly)였을 뿐입니다.

저는 50개에서 500개의 AWS 계정을 운영하는 조직들을 대상으로 수년간 이 작업을 수행해 왔습니다. 월간 비용 검토, 설명을 듣기 위해 엔지니어들을 쫓아다니기, 예산 회의 전까지는 아무도 읽지 않는 스프레드시트에 보고서 만들기 등 말이죠. 2026년 6월 9일, AWS가 FinOps Agent를 퍼블릭 프리뷰(Public Preview)로 발표했을 때, 저는 오후 일정을 비우고 이를 설정했습니다.

이 아티클은 제가 실제로 시간을 들여 사용해 본 후 작성한 솔직한 의견입니다. 이 도구가 무엇을 잘하는지, 엔터프라이즈 환경에서 어디에 적합한지, 그리고 아키텍트와 FinOps 팀의 일상 업무를 어떻게 변화시키는지에 대해 다룹니다.

AWS FinOps Agent란 무엇인가요? (쉬운 설명)

이것은 여러분이 기존에 사용하던 AWS 비용 도구인 Cost Explorer, Cost Anomaly Detection, Cost Optimization Hub, Compute Optimizer, 그리고 CloudTrail 상단에서 작동하며, 여러분이 직접 해왔던 수동 작업을 대신 수행하는 AI 에이전트(AI Agent)입니다.

여러분은 일상적인 영어로 질문을 던지기만 하면 됩니다. 그러면 에이전트가 해당 서비스들로부터 데이터를 가져오고, 이벤트 간의 상관관계를 분석하여 답변을 제공합니다. 또한 특정 일정에 따라 작업을 실행하거나, 비용 이상 징후(Cost anomaly)가 발생했을 때 반응하도록 설정할 수도 있습니다.

프리뷰 기간 동안에는 us-east-1에서 실행되지만, 모든 리전(GovCloud 및 중국 제외)의 비용 데이터를 볼 수 있습니다. 프리뷰 기간 동안에는 월간 사용량 제한 내에서 무료로 사용할 수 있습니다.

기저 엔진은 Amazon Bedrock 파운데이션 모델 (foundation models)을 사용하지만, 사용자가 이를 알거나 신경 쓸 필요는 없습니다. 그저 대화만 하면 됩니다.

진정으로 간단한 설정 방법

저는 IAM 정책 (IAM policy) 문제로 골머리를 앓으며 30분 정도 설정할 것을 예상했습니다. 하지만 약 5분밖에 걸리지 않았습니다.

실제 흐름은 다음과 같습니다:

1. AWS 콘솔 (AWS Console)을 열고 us-east-1 리전으로 전환한 뒤, FinOps Agent를 찾습니다.
2. "Get Started"를 클릭하고 에이전트의 이름을 지정합니다.
3. 클릭 한 번으로 결제 및 비용 관리 서비스에 대한 읽기 전용 (read-only) 액세스 권한을 가진 IAM 역할 (IAM role)을 생성해 줍니다.
4. 선택 사항으로 Jira 및 Slack을 연결합니다.
5. 웹 애플리케이션을 열고 질문을 시작합니다.

그게 전부입니다. CloudFormation 스택 (CloudFormation stack), Terraform 모듈 (Terraform module), 커스텀 Lambda 함수 (custom Lambda functions)도 필요 없습니다. 전체 과정이 IAM 정책과 씨름하는 것보다 더 중요한 일을 해야 하는 사람들을 위해 설계된 것처럼 느껴졌습니다.

주의할 점 한 가지: AWS 콘솔에서 멀티 세션 (multi-session)이 활성화되어 있다면 먼저 비활성화하십시오. 저는 Slack 설정 중에 이 문제로 인해 권한 오류 (permissions error)가 발생했습니다. 문서에서는 이 부분을 미리 명확하게 안내하지 않습니다.

또한, Slack을 설정하는 경우 콘솔에서 통합 (integration)을 구성하기 전에 FinOps Agent 앱을 채널의 멤버로 먼저 추가해야 합니다. 이 단계를 놓치면 도움이 되지 않는 메시지와 함께 오류가 발생합니다. AWS 문서에는 "중요 (Important)"라고 표시되어 있지만, 쉽게 지나치기 쉽습니다.

내가 던진 첫 번째 질문

채팅창을 열고 다음과 같이 입력했습니다:

"지난달 서비스 및 계정별로 분류된 상위 5개 비용 동인 (cost drivers)은 무엇이었나요?"

약 15초 이내에 정확히 그 내용을 보여주는 표가 답변으로 돌아왔습니다. Cost Explorer에서 데이터를 가져와 서비스별로 분류하고, 계정 이름을 보여주며, 전월 대비 퍼센트 변화 (percentage change)까지 포함했습니다.

대시보드 (dashboard)를 구축할 필요도, 저장된 보고서 (saved report)를 구성할 필요도 없습니다. 그저 질문과 답변이 있을 뿐입니다.

그 후 저는 제 계정 중 하나에서 왜 EC2 비용이 증가했는지에 대해 후속 질문을 던졌습니다. 에이전트는 더 깊이 파고들어 비용 증가를 유발한 인스턴스 유형 (instance type)을 식별했고, 해당 인스턴스들이 언제 시작되었는지를 보여주는 관련 CloudTrail 이벤트를 드러냈으며, API 호출을 수행한 IAM 역할 (IAM role)을 지목했습니다.

Cost Explorer와 CloudTrail 사이를 오가며 타임스탬프 (timestamp)를 맞추고, 적절한 주체 (principal)를 찾는 식의 조사는 보통 20~30분 정도 걸립니다. 에이전트는 이를 1분도 채 걸리지 않아 수행했습니다.

제가 빠르게 배운 한 가지는 다음과 같습니다. 기본적으로 표시되는 비용에는 크레딧 조정 (credit adjustments)이 포함되어 있다는 점입니다. 만약 크레딧 적용 전 수치(대부분의 기업이 예산 책정을 위해 중요하게 생각하는 수치)를 원한다면, 프롬프트 (prompt)에 이를 명시해야 합니다. 저는 에이전트에게 항상 크레딧을 제외하라고 말했고, 에이전트는 제가 다시 반복하지 않아도 다음 세션에서 그 선호도를 기억했습니다.

이것이 실제 기업의 고충을 해결하는 지점

제가 함께 일했던 모든 조직에서 목격했던 문제들과 이를 매칭해 보겠습니다.

문제 1: 조사되지 않고 방치되는 비용 이상 징후 (Cost Anomalies)

제가 아는 모든 기업은 AWS Cost Anomaly Detection을 켜두고 있습니다. 대부분의 기업은 또한 이러한 알림이 도달하는 공유 이메일 수신함이나 Slack 채널을 운영합니다. 그리고 대부분의 경우, 누군가 확인하기 전까지 해당 알림은 몇 시간 또는 며칠 동안 그대로 방치됩니다.

이유는 간단합니다. 조사가 수동적이고 시간이 많이 걸리기 때문입니다. AWS FinOps Agent는 이를 자동화합니다. 다음과 같은 자동화 설정을 할 수 있습니다: "$500 이상의 비용 이상 징후가 감지되면, 이를 조사하여 근본 원인 (root cause)을 찾고, 그 결과를 우리의 #finops-alerts Slack 채널에 게시하라."

이 시점부터 모든 이상 징후는 발생하는 즉시 조사됩니다. 출력 결과에는 무엇이 변경되었는지, 원인이 된 CloudTrail 이벤트, 책임이 있는 IAM 주체 (IAM principal), 그리고 예상되는 근본 원인에 대한 요약이 포함됩니다.

많은 계정을 지원해야 하는 소규모 FinOps 팀에게 이것은 문제를 몇 일 만에 발견하느냐, 아니면 몇 시간 만에 잡아내느냐의 차이를 만듭니다.

문제 2: 엔지니어가 비용 정보를 스스로 확인할 수 없음 (Self-Serve)

대부분의 기업에서 개발자가 팀의 비용을 파악하고 싶다면, Cost Explorer (비용 탐색기) 접근 권한이 필요하거나 (많은 조직이 이를 제한함), 중앙 FinOps 팀에 요청을 제출해야 합니다.

이는 병목 현상을 초래합니다. 제 경험상, FinOps 팀은 "지난달 스테이징 환경 비용이 얼마였나요?" 또는 "어떤 Lambda 함수가 가장 비용이 많이 발생하나요?"와 같은 기본적인 질문에 답변하는 데 상당한 시간을 할애하게 됩니다.

FinOps Agent를 사용하면 엔지니어가 질문을 던지고, 에이전트가 실제 데이터를 사용하여 답변하며, FinOps 팀은 전혀 개입할 필요가 없습니다.

또한 계정과 팀 소유자를 매핑한 CSV 파일, 태깅 컨벤션 (Tagging Conventions)을 설명하는 문서, 어떤 비용 센터 (Cost Centers)가 어떤 사업 부문에 매핑되는지 정리된 목록과 같은 컨텍스트 (Context) 파일을 업로드할 수 있습니다. 에이전트는 이 컨텍스트를 사용하여, 어떤 계정이 Team Alpha에 속하는지 누군가 설명할 필요 없이 "Team Alpha는 얼마를 쓰고 있나요?"와 같은 질문을 이해합니다.

문제 3: 월간 보고서는 시간 낭비이다

제가 함께 일했던 모든 FinOps 팀은 어떤 형태로든 월간 비용 보고서를 생성합니다. 이 보고서는 재무 팀, 엔지니어링 리더십, 때로는 CTO에게 전달됩니다. 보고서를 만드는 과정에는 Cost Explorer에서 데이터를 내보내고, 슬라이드 덱이나 스프레드시트에 형식을 맞추고, 변경 사항에 대한 설명을 추가한 뒤 발송하는 작업이 포함됩니다.

제 경험상 이 작업에는 매달 4~8시간이 소요됩니다. 이해관계자마다 서로 다른 뷰 (View)를 원하기 때문에 더 많은 시간을 소비하는 팀도 있습니다.

FinOps Agent를 사용하면 이러한 보고서를 예약할 수 있습니다. 다음과 같이 명령할 수 있습니다: "매주 월요일 오전 8시에 지난주 비용 보고서를 생성해줘. 사업 부문별로 분류하고, 10% 이상의 변경 사항은 강조해줘. 그리고 이를 PDF로 변환하여 #finops-weekly Slack 채널로 전달해줘."

에이전트는 예약된 일정에 따라 실행됩니다. 사람의 개입은 필요 없습니다. 보고서는 매주 월요일 Slack에 나타납니다. 대상에 따라 서로 다른 보고서를 설정할 수 있습니다. 엔지니어링 리드용 상세 보고서, 재무 팀용 요약 보고서, CTO용 경영진 보고서 등이 가능합니다.

출력 형식은 HTML, PDF 또는 PPT로, 모두 즉시 발표 가능한 상태로 제공됩니다.

문제 4: 아무도 확인하지 않는 대시보드에 머물러 있는 최적화 권장 사항

AWS Cost Optimization Hub와 Compute Optimizer는 모두 적정 규모 산정 (rightsizing) 기회, 유휴 리소스 (idle resources), Savings Plans 제안 등 확실한 권장 사항을 생성합니다. 문제는 이러한 권장 사항들이 엔지니어들이 거의 확인하지 않는 AWS 대시보드 안에 머물러 있다는 점입니다.

FinOps Agent는 이러한 권장 사항을 가져와 요약하고, 각 리소스를 소유한 팀에 할당된 Jira 티켓을 생성할 수 있습니다. FinOps 분석가가 수동으로 대시보드를 검토하고 티켓을 생성하는 대신, 에이전트가 정해진 일정에 따라 이 작업을 수행합니다.

자동화 예시: "매주 목요일마다 Cost Optimization Hub를 확인하여 잠재적 절감액이 월 $100 이상인 새로운 권장 사항을 찾으세요. 각 항목에 대해 권장 사항 상세 내용, 영향을 받는 리소스, 예상 절감액을 포함하여 INFRA 프로젝트에 Jira 티켓을 생성하세요."

이제 최적화 작업은 누군가가 도구 간에 데이터를 수동으로 복사할 필요 없이, 엔지니어링 스프린트 (sprint)로 자연스럽게 흘러 들어갑니다.

엔터프라이즈 아키텍처에 적용하는 방법

전형적인 멀티 계정 (multi-account) 엔터프라이즈 환경에서 이를 어떻게 배포할지 설명하겠습니다.

관리 계정 (Management Account) 설정

관리 계정(또는 통합 빌링 결제 역할 (consolidated billing payer role)을 가진 계정)에서 FinOps Agent를 생성합니다. 이를 통해 모든 멤버 계정 (member accounts)에 대한 가시성을 확보할 수 있습니다. 에이전트가 생성하는 IAM 역할 (IAM role)은 기본적으로 읽기 전용 (read-only)이므로 인프라에 변경을 가할 수 없습니다.

멤버 계정 소유자 또한 관리 계정 접근 권한 없이 독립적인 비용 가시성을 원한다면 자신의 계정에만 국한된 자체 에이전트를 생성할 수 있습니다. 이는 서로 다른 범위를 가진 여러 에이전트를 운영할 수 있음을 의미합니다. 즉, FinOps 팀을 위한 중앙 집중식 에이전트와, 전체 조직을 볼 필요 없이 자체적인 뷰를 원하는 팀들을 위한 개별 에이전트를 가질 수 있습니다.

액세스 패턴 (Access Patterns)

역할	사용 방식
FinOps 팀	이상 징후 조사, 정기 보고서, 최적화 티켓 생성을 위한 자동화 설정
...

구성 요소 간의 연결 방식

이 에이전트는 지출 데이터를 위해 기존 AWS 비용 서비스인 Cost Explorer를, 알림을 위해 Cost Anomaly Detection을, 권장 사항을 위해 Cost Optimization Hub 및 Compute Optimizer를, 그리고 변경 이력을 위해 CloudTrail을 읽습니다. 사용자가 해당 통합 설정을 구성하고 작업을 트리거할 때만 Jira 및 Slack에 내용을 작성합니다. 어떠한 AWS 리소스도 수정하지 않습니다.

보안 모델 (Security Model)

• IAM 역할 기반 액세스 (에이전트가 읽을 수 있는 권한을 사용자가 제어)
• 기본적으로 비용 서비스에 대해 읽기 전용 (Read-only) 권한 적용
• 쓰기 작업 (Jira 티켓 생성, Slack 포스팅)은 사용자가 구성하고 트리거할 때만 발생
• 모든 활동은 감사를 위해 CloudTrail에 기록됨
• 교차 계정(Cross-account) 쓰기 권한 없음
• 에이전트는 Amazon Bedrock 파운데이션 모델 (Foundation Models)을 사용하여 쿼리를 처리하며, 비용 데이터는 사용자 계정 내의 IAM 역할을 통해 액세스되므로 AWS 외부로 유출되지 않음

리스크를 평가하는 아키텍트가 주목해야 할 한 가지는, 이 서비스는 인프라 의존성이 전혀 없다는 점입니다. 실제 비용 도구, 계정 및 리소스는 변경되지 않습니다. 만약 내일 당장 에이전트가 중단되더라도, 시스템을 재구축하는 것이 아니라 수동 작업으로 돌아가기만 하면 됩니다. 이는 프리뷰 기간 동안 환경에 도입할 때 리스크가 매우 낮음을 의미합니다.

핸즈온 테스트 중 발견한 점

장점 (The Good)

답변 속도. 비용 관련 질문을 던지고 15~30초 만에 실제 답변을 얻는 것은 워크플로우를 변화시킵니다. 저는 수동으로 조사했다면 절대 하지 않았을 후속 질문들을 스스로 던지고 있는 것을 발견했습니다.

근본 원인 상관관계 (Root cause correlation). Cost Anomaly Detection 알림을 CloudTrail 이벤트와 자동으로 연결해 준다는 점은 진정으로 유용합니다. 이는 수동 조사 시 가장 많은 시간이 소요되는 단계입니다.

예약된 작업이 실제로 작동함. 목요일 아침으로 주간 보고서를 설정했습니다. 예정된 시간으로부터 2분 이내에 실행되었으며, 생성된 PDF는 깔끔하고 읽기 쉬웠습니다. 결과물은 나중에 다시 확인할 수 있도록 웹 앱의 "Artifacts" 탭에 저장됩니다.

컨텍스트 파일 (Context files)은 강력합니다. 계정-팀 매핑 (account-to-team mapping) 파일을 업로드한 후, 에이전트는 추가적인 설정 없이도 팀 수준의 질문에 정확하게 답변하기 시작했습니다.

세션 간의 메모리 (Memory across sessions). 비용 총계를 보여줄 때 항상 크레딧 (credits)을 제외하라고 명령했습니다. 다음 세션에서 에이전트는 제가 다시 말하지 않아도 해당 선호도를 기억하고 있었습니다.

미흡한 점 (결국 프리뷰 버전이니까요)

Slack 메시지는 인라인 콘텐츠가 아닌 링크 형태입니다. 에이전트가 Slack에 게시할 때, 전체 분석 내용을 인라인으로 보내는 대신 FinOps Agent 웹 앱으로 연결되는 링크를 보냅니다. 이는 세부 정보를 확인하기 위해 여전히 클릭해서 들어가야 함을 의미합니다. 바쁜 아침에 빠르게 훑어보고 싶을 때는 이 점이 번거로움을 더합니다.

Slack 전송이 자동이 아닙니다. 채팅 세션에서 에이전트가 분석을 완료한 후에도,