월말이 되기도 전에 Slack에 클라우드 비용 이상 알림이 뜹니다. 이번에는 재무팀이 최종 청구서를 보낸 것이 아닙니다. AI agent가 Cost Anomaly Detection, CloudTrail(누가 언제 무엇을 바꿨는지 남기는 기록), Cost Explorer(비용이 어디에 쓰였는지 보는 분석 도구), 최적화 권장 사항을 연결해 어떤 서비스가 비싸졌는지, 누가 설정을 바꿨는지, 어느 팀에 알려야 하는지 답하려고 합니다.

AWS는 2026년 6월 AWS FinOps Agent public preview를 열었습니다. 이 도구는 비용 질문에 답하고, cost anomaly를 조사하고, 정기 보고서를 만들고, 결과를 Slack이나 Jira로 보낼 수 있습니다. 마침내 청구서를 추적해 줄 사람이 생긴 것처럼 보이지만, 진짜 질문은 “AI가 비용 데이터를 봐도 되는가”만이 아닙니다. 이 알림이 들어온 뒤 누가 판단하고, 누가 설정을 바꿀 수 있으며, 어떤 상황에서 반드시 멈춰 인간이 확인해야 하는가를 먼저 정해야 합니다.

이 경계가 먼저 쓰여 있지 않으면 AI는 오래된 문제를 새 입구로 옮길 뿐입니다. 예전에는 아무도 dashboard를 보지 않았고, 이제는 여러 사람이 보기 좋은 요약을 받지만 여전히 아무도 책임지지 않을 수 있습니다.

어떤 흐름을 맡길지 먼저 정하기

FinOps Agent는 단순한 비용 절감 버튼이 아닙니다. AWS 공식 문서는 이를 비용을 지속적으로 모니터링하고, 이상을 조사하고, 비용 질문에 답하고, 최적화 기회를 정리하는 agent로 설명합니다. InfoQ도 같은 지점을 강조합니다. 비용 조사를 중앙 dashboard에서 엔지니어가 평소 쓰는 Slack, Jira, 보고 흐름으로 옮긴다는 것입니다.

따라서 활성화 전에 “정확한가?”부터 묻지 말고, 어떤 흐름을 맡길지 먼저 정해야 합니다.

  • FinOps나 재무팀용 주간 보고서만 만들 것인가?
  • 비용 이상이 발생하면 root cause(비용 변화의 원인)를 자동 조사할 것인가?
  • 특정 engineering owner(실제 담당자)에게 이슈를 배정할 것인가?
  • 엔지니어가 account(계정), service(서비스), team(팀) 비용을 자연어로 질문할 수 있게 할 것인가?
  • 최적화 권장 사항을 Jira ticket(작업 티켓)으로 만들 것인가?

이들은 위험 수준이 다릅니다. 보고서와 Q&A는 비교적 낮은 위험입니다. 자동 ticket 생성은 이미 업무 우선순위에 영향을 줍니다. 자동 수정이나 강제 축소에 가까워질수록 명확한 인간 승인이 필요합니다.

활성화 전에 다섯 칸을 채우기

확인 칸질문비어 있으면 생기는 문제
owner 매핑각 AWS account, team, cost center, tag는 누가 책임지는가?AI가 이상을 찾지만 ticket이 엉뚱한 사람에게 가거나 아무도 맡지 않습니다.
이상 기준얼마의 금액, 비율, 서비스 유형이면 알림이 필요한가?작은 변동이 소음을 만들고, 큰 문제는 묻히기 쉽습니다.
통보 경로무엇은 Slack, 무엇은 Jira, 무엇은 주간 보고서에만 둘 것인가?모든 일이 알림이 되고, 엔지니어가 채널을 mute하기 시작합니다.
인간 승인어떤 제안은 읽기만 하고, 어떤 것은 task가 되며, 어떤 것은 manager 확인이 필요한가?비용 최적화가 맥락 없는 업무 방해가 됩니다.
중지 조건언제 agent를 멈추고, 수동 확인으로 돌리고, 자동화 범위를 줄일 것인가?preview 기간의 불안정한 동작에도 팀이 그대로 따르게 됩니다.

이 다섯 칸은 도구 설정보다 중요합니다. FinOps의 어려움은 보통 데이터가 없어서가 아니라, 데이터가 나온 뒤 누가 다음 책임을 맡는지 모르는 데 있습니다.

광고

먼저 “읽기 + 제안”으로 시작하기

AWS FinOps Agent는 현재 public preview입니다. AWS는 preview 동안 agent 자체 추가 비용은 없다고 설명하지만, 관련 AWS API나 서비스에는 일반 비용이 발생할 수 있고, 사용 가능한 리전에도 preview 제한이 있습니다. DEV Community의 실사용 글도 언어 동작, 통합 설정, Slack 공유, 보고서 출력 같은 세부 사항을 작은 범위에서 먼저 검증해야 함을 보여줍니다.

작은 팀이라면 처음부터 모든 비용 거버넌스를 넘기지 않는 편이 좋습니다. 먼저 읽기 전용 흐름을 만듭니다.

범위 줄이기 → 자료 읽기 → 통보 시험하기 → 사람이 샘플 확인하기 → 나중에 확대하기범위 줄이기자료 읽기통보 시험하기사람이 샘플 확인하기나중에 확대하기
  1. 범위 줄이기: 먼저 한두 개 AWS account(계정)나 workload(작업 범위)만 고릅니다.
  2. 자료 읽기: 그 범위 안의 비용과 사용량 데이터만 agent가 읽게 합니다.
  3. 통보 시험하기: 조사 결과(findings)는 먼저 테스트 Slack channel로 보냅니다.
  4. 사람이 샘플 확인하기: 매주 root cause(비용 변화의 원인)가 합리적인지, owner가 맞는지, 권장 사항이 실행 가능한지 봅니다.
  5. 나중에 확대하기: 몇 주간 안정적이면 Jira ticket(작업 티켓) 생성이나 범위 확장을 검토합니다.

이렇게 하는 목적은 AI를 믿지 않기 위해서가 아닙니다. 팀의 기존 판단과 어디가 다른지 보기 위해서입니다. 어떤 findings가 유용한지, 어디에 context가 부족한지, 어디에서 owner를 잘못 판단하는지 알게 된 뒤에 더 높은 자동화를 논의하는 편이 안전합니다.

아직 도입하지 않는 편이 나은 경우도 있습니다. AWS account와 tag가 owner에게 명확히 연결되어 있지 않거나, 비용 이상이 드물거나, Jira 후속 처리가 안정적이지 않거나, 팀이 청구서를 가끔만 확인한다면 먼저 이름 규칙과 책임표를 정리해야 합니다. 도구는 늦어도 되지만 책임 경계는 늦으면 안 됩니다.

Slack과 Jira는 끝이 아니라 책임 경계

많은 자동화 흐름은 통보 성공을 처리 성공으로 착각해서 실패합니다. FinOps Agent는 조사 결과를 Slack이나 Jira로 보낼 수 있지만, 그것은 메시지가 도착했다는 뜻일 뿐 비용 문제가 해결됐다는 뜻은 아닙니다.

Slack은 알림, 논의, 빠른 확인에 좋습니다. Jira는 일정화, 배정, 완료 추적에 좋습니다. 둘 다 명확한 사용 규칙이 필요합니다.

  • 금액이 작거나 추세성이고 관찰이 필요한 사건은 주간 보고서에 둡니다.
  • 금액이 크고, 상승 중이며, owner가 명확한 사건은 Jira로 보낼 수 있습니다.
  • production 위험, 고객 경험, security 설정에 영향을 주는 제안은 AI 요약만으로 결정하지 말고 인간 owner가 확인해야 합니다.

모든 anomaly가 Jira ticket(작업 티켓)이 되면 팀은 곧 그것을 소음으로 봅니다. 모든 것이 Slack에만 흐르면 아무도 마무리하지 않기 쉽습니다. 실제로 설계해야 하는 것은 어떤 비용 신호를 어떤 책임으로 바꿀지입니다.

작은 시험 범위 만들기

아주 작은 시험부터 시작할 수 있습니다. 먼저 report와 Q&A만 켜고 “어떤 서비스의 비용 변화가 가장 큰가”, “어떤 team 관련 account가 가장 많이 늘었는가”, “어떤 idle 또는 rightsizing 권장 사항이 있는가”에 답할 수 있는지 확인합니다. 요약이 유용하다고 확인되면 낮은 위험의 Slack channel을 연결하고, 요약 전송만 허용합니다. 직접 설정을 바꾸게 하지는 않습니다.

매주 세 가지를 돌아봅니다.

  • agent가 찾은 root cause(비용 변화의 원인)를 engineering owner(실제 담당자)가 인정하는가?
  • agent가 제안한 owner가 실제 책임자와 맞는가?
  • agent가 제안한 action은 일정에 넣을 만큼 구체적인가, 아니면 일반적인 최적화 메모에 그치는가?

세 가지가 안정적이면 Jira 연결을 검토합니다. 하나라도 자주 틀린다면, 알림 범위를 넓히기 전에 계정과 담당자를 연결하는 표(account mapping), 통일된 태그 규칙(tagging convention), 팀 범위 정의(team definition), 정기 검토 주기(review cadence)를 보완합니다.

FinOps에서 AI agent가 가장 가치 있는 지점은 재무팀이 보는 표를 하나 줄이는 것이 아닙니다. 비용 신호를 엔지니어링팀이 실제로 처리할 수 있는 일로 바꾸는 것입니다. 다만 이것은 책임 경계가 먼저 쓰여 있을 때만 가능합니다. 먼저 읽게 하고, 설명하게 하고, 사람이 확인한 뒤 작업 흐름에 넣어야 합니다. 그렇지 않으면 클라우드 비용 알림은 아무도 보지 않는 dashboard에서 아무도 책임지지 않는 AI 요약으로 옮겨갈 뿐입니다.

생활 4컷 만화

팀이 클라우드 비용 알림을 담당자 분류와 사람의 승인 절차로 바꾸는 4컷 만화

  1. 비용 신호가 처음 나타나면 팀이 아는 것은 무언가 비싸졌다는 사실뿐이고, 누가 맡아야 하는지는 아직 분명하지 않습니다.
  2. 모든 알림을 바로 열기보다 계정, 서비스, 담당자를 명확한 책임 표로 정리합니다.
  3. AI는 요약과 경로 제안을 도울 수 있지만, 어떤 조치를 작업으로 넘기고 어떤 조치를 승인 전 단계에서 멈출지는 사람이 확인합니다.
  4. 알림이 담당자가 있는 작업으로 바뀌면 Slack이나 Jira는 단순한 소음이 아니라 끝까지 처리할 수 있는 일이 됩니다.

AI 정리 카드

이 글의 상황에 맞춰 AI에게 정리하게 하기

자신의 AI 채팅 도구에 붙여 넣으면 이 미니 클래스를 개인용 체크리스트로 바꿀 수 있습니다. BMC는 사용자가 AI에 붙여 넣은 내용을 볼 수 없습니다.

광고

Share

이 미니 클래스 공유

이 글이 업무 병목을 푸는 데 도움이 되었다면, AI를 어떻게 쓸지 고민하는 사람에게도 공유해 주세요.

참고 자료