AWS FinOps Agent가 클라우드 비용을 런타임(Runtime) 문제로 변화시키다

클라우드 비용 관리(Cloud cost management)는 항상 기묘한 감정적 양상을 띠어 왔습니다.

모두가 그것이 중요하다고 동의합니다. 하지만 거의 아무도 그것을 하고 싶어 하지 않습니다. 대시보드(Dashboard)는 마련되어 있습니다. 보고서(Reports)도 존재합니다. 권장 사항(Recommendations)도 기술적으로는 사용 가능합니다. 재무 팀은 합리적인 질문을 던집니다. 엔지니어링 팀은 출시 후에 처리하겠다고 말합니다. 그러다 출시는 두 번의 출시가 되고, 기존 환경은 여전히 실행 중이며, 데이터베이스 클래스는 여전히 너무 크고, 청구서의 의문의 항목은 반복되는 캘린더 초대장이 되어버립니다.

이것이 바로 AWS FinOps Agent가 내 관심을 끈 이유입니다.

발표는 아직 프리뷰(Preview) 단계이므로, 이것을 맹신하지는 않겠습니다. 하지만 그 형태는 중요합니다. AWS는 비용 질문에 답하고, 최적화 기회를 드러내며, 이상 징후를 조사하고, 반복적인 FinOps 워크플로(Workflows)를 실행하며, 보고서를 생성하고, Jira 티켓을 생성하며, Slack에 조사 결과를 게시할 수 있는 에이전트(Agent)를 설명합니다.

이것은 단순히 "클라우드 청구서와 채팅하는 것"이 아닙니다.

이것은 비용 관리가 대시보드 고고학(Dashboard archaeology)에서 운영 워크플로(Operational workflow)로 이동하는 것입니다.

에이전트가 비용 권장 사항을 티켓, Slack 메시지 또는 반복적인 조사로 전환할 수 있는 순간, 클라우드 비용은 단순한 보고(Reporting) 문제가 아니게 됩니다.

그것은 런타임(Runtime) 문제가 됩니다.

대시보드만으로는 결코 충분하지 않았습니다

클라우드 비용 대시보드는 전형적인 기업적 타협안입니다.

그것은 모두에게 지적할 장소를 제공합니다. 하지만 누구에게도 행동할 만큼의 충분한 추진력을 거의 제공하지 못합니다.

A 대시보드는 지출이 증가했다는 것을 알려줄 수 있습니다. 서비스가 유휴 상태(Idle)라는 것, 클러스터(Cluster)가 과다 할당되었다는 것, Savings Plan이 도움이 될 수 있다는 것, 또는 스토리지가 예상보다 빠르게 성장했다는 것을 보여줄 수 있습니다. 그것은 유용한 정보입니다. 하지만 "유용한 정보"와 "누군가가 운영 환경(Production)을 안전하게 변경했다" 사이에는 많은 누락된 작업이 존재합니다.

누군가는 그 권장 사항이 유효한지 결정해야 합니다.

누군가는 어떤 팀이 해당 리소스를 소유하고 있는지 알아야 합니다.

누군가는 해당 워크로드(Workload)에 특이한 트래픽 패턴이 있는지, 컴플라이언스(Compliance) 제약 사항이 있는지, 마이그레이션(Migration)이 진행 중인지, 아니면 Slack 스레드 속에 숨겨진 고객과의 약속이 있는지 이해해야 합니다.

누군가는 티켓(Ticket)을 생성하고, 소유자를 추적하며, 변경 사항을 적용하고, 결과를 검증하며, 재무 부서에 왜 이 절감이 실제적인지 혹은 왜 그렇지 않은지를 설명해야 합니다.

그 간극 때문에 FinOps는 단순한 분석(Analytics)이 아닌 운영(Operations)인 것입니다.

여기서 에이전트(Agent)가 흥미로운 이유는 그 간극 사이에 자리 잡을 수 있기 때문입니다. 에이전트는 비용 신호(Cost signal)를 엔지니어링 팀이 실제로 의사결정을 내리는 워크플로(Workflow)에 연결할 수 있습니다.

그것이 유용한 버전입니다.

위험한 버전은 동일한 에이전트가 대규모로 확신에 차서 노이즈(Noise)를 생성하는 것입니다.

권장 사항은 결정이 아니다

클라우드 최적화 도구들은 항상 번역(Translation) 문제에 직면해 왔습니다.

"이 인스턴스는 사용률이 낮습니다"가 "지금 크기를 조정(Resize)하십시오"와 같은 것은 아닙니다.

"이 데이터베이스는 유휴(Idle) 상태로 보입니다"가 "삭제하십시오"와 같은 것은 아닙니다.

"Savings Plan을 통해 지출을 줄일 수 있습니다"가 "회사를 이 사용 형태에 확약(Commit)하십시오"와 같은 것은 아닙니다.

권장 사항은 단서일 뿐입니다. 결정에는 컨텍스트(Context)가 필요합니다.

AWS는 FinOps Agent가 Cost Optimization Hub 및 Compute Optimizer에서 정보를 가져와 보고서를 생성하고, 라이트사이징(Rightsizing), 유휴 리소스(Idle resource), Savings Plans 권장 사항을 드러내며, 이러한 권장 사항으로부터 Jira 티켓을 생성할 수 있다고 말합니다. 바로 그 지점이 경계가 중요한 부분입니다.

티켓을 생성하는 것은 괜찮습니다. 유용할 수 있습니다. 티켓에는 증거, 예상 절감액, 소유자, 영향을 받는 리소스, 신뢰 수준(Confidence level), 그리고 에이전트가 왜 이 권장 사항을 검토하기에 충분히 안전하다고 판단했는지에 대한 이유가 포함되어야 합니다.

하지만 티켓이 결정은 아닙니다.

결정은 서비스, 예산, 또는 운영 리스크(Operational risk)를 소유한 사람의 몫입니다.

팀들이 에이전트가 얼마나 많은 작업을 만들어내느냐로 에이전트를 측정하기 시작하기 전까지는 이 말이 당연하게 들릴 것입니다. 백 개의 티켓을 생성하는 FinOps 에이전트가 자동으로 성공적이라고 볼 수는 없습니다. 그것은 단순히 대시보드의 노이즈를 Jira로 내보낸 것일 수도 있기 때문입니다.

더 나은 지표는 다소 지루할 수 있습니다. 운영상의 장애(operational incidents)나 검토 피로(review fatigue)를 유발하지 않으면서, 얼마나 많은 권장 사항(recommendations)이 안전하고 검증된 비용 절감으로 이어졌는가 하는 점입니다.

이상 징후 조사(anomaly investigation)가 실질적인 차이를 만드는 지점

AWS 설명에서 가장 흥미로운 부분은 보고서가 아닙니다. 바로 이상 징후 조사(anomaly investigation)입니다.

비용 이상 징후(Cost anomalies)는 매우 성가신데, 대개 긴급하면서도 모호하기 때문입니다. 지출이 변했습니다. 무언가 바뀌었습니다. 제품 출시 때문일 수도 있습니다. 남용 패턴(abuse pattern)일 수도 있습니다. 테스트 환경에서 유출이 발생했을 수도 있습니다. 재시도 루프(retry loop)가 시작되었을 수도 있습니다. 데이터 파이프라인(data pipeline)이 예상보다 더 많이 재처리되었을 수도 있습니다. 혹은 어떤 팀이 의도적으로 무언가를 확장(scale)해놓고 아무에게도 말하지 않았을 수도 있습니다.

첫 한 시간은 보통 맥락을 수집(context gathering)하는 데 사용됩니다.

어떤 계정인가? 어떤 서비스인가? 어떤 리전(region)인가? 어떤 태그(tags)인가? 비슷한 시기에 어떤 배포(deployment)가 있었는가? 어떤 팀의 소유인가? 지출이 여전히 증가하고 있는가? 고객에게 영향을 미치고 있는가? 이것이 월말, 배치 처리(batch processing), 또는 마케팅 캠페인 관점에서 실제로 비정상적인 것인가?

경계가 명확하다면 이것은 훌륭한 에이전트의 작업입니다.

증거를 수집하고, 가능한 원인을 요약하며, 조사 결과를 Slack에 게시할 수 있는 에이전트는 시간을 절약해 줄 수 있습니다. 사람은 빈 대시보드에서 시작할 필요가 없습니다. 장애(incident) 채널이나 FinOps 채널에는 링크, 영향을 받은 리소스, 그리고 다음 조치 사항이 포함된 1차 검토 결과가 전달됩니다.

하지만 에이전트는 자신의 작업 과정을 증명해야 합니다.

만약 에이전트가 근본 원인(root cause)이 데이터 파이프라인이라고 말한다면, 저는 쿼리 추적(query trail)을 보고 싶습니다. 만약 배포(deployment)가 급증(spike)과 상관관계가 있다고 한다면, 저는 배포 링크를 원합니다. 만약 지출이 하나의 계정과 하나의 리전에 국한된다고 한다면, 저는 정확한 필터(filters)를 원합니다. 만약 무언가를 중단할 것을 권장한다면, 실행 전 인간의 승인 단계(human approval gate)를 원합니다.

비용 이상 징후에 있어 증거 없는 확신은 그저 더 빠르게 틀리는 방법일 뿐입니다.

Slack은 책임 모델(accountability model)이 아니다

조사 결과를 Slack에 게시하는 것은 유용합니다.

하지만 그것만으로는 충분하지 않습니다.

Slack 메시지는 알림 (notification)일 뿐입니다. 그것은 소유권 (ownership)이 아닙니다. 그것은 상태 (state)가 아닙니다. 그것은 작업이 완료되었다는 증거가 아닙니다. 또한 비용 결정이 왜 수락되었는지 또는 거부되었는지에 대한 지속 가능한 기록 (durable record)도 아닙니다.

진정한 의미의 FinOps 에이전트(agent)는 시스템 전반에 걸친 추적 경로 (trail)가 필요합니다:

탐지된 이상 징후 (anomaly)
사용된 데이터 소스 (data sources)
영향을 받은 계정 (accounts), 서비스 (services), 리전 (regions) 및 태그 (tags)
생성된 권장 사항 (recommendation)
생성된 티켓 (ticket) 또는 이슈 (issue)
할당된 소유자 (owner)
승인 (approval) 또는 거부 (rejection)
실제 변경 사항 (actual change)
변경 후 측정된 영향 (measured impact)

이것이 없다면, 조직은 그저 말이 더 많아진 비용 대시보드 (cost dashboard)를 갖게 될 뿐입니다.

이것이 있다면, 에이전트는 클라우드 비용을 위한 운영 체제 (operating system)의 일부가 됩니다.

이 지점에서 엔지니어링 (engineering)과 재무 (finance) 팀은 주의를 기울여야 합니다. 에이전트가 재무 팀이 엔지니어링 팀에 티켓을 뿌리는 수단이 되어서는 안 됩니다. 또한

만약 에이전트가 낭비를 줄여야 한다면, 에이전트 역시 동일한 질문에서 예외가 되어서는 안 됩니다.

이 작업이 비용을 들일 만큼 가치가 있는가?

내가 가장 먼저 구축할 것

만약 내가 회사 내부에 FinOps 에이전트를 도입한다면, 영웅적인 버전을 지양할 것입니다.

"모든 AWS 지출을 최적화하라"는 식의 접근으로는 시작하지 않을 것입니다.

나는 다음과 같은 하나의 좁은 루프(loop)로 시작할 것입니다:

하나의 비즈니스 유닛 (business unit)
하나의 태그 지정된 계정 세트 (set of tagged accounts)
하나의 권장 사항 클래스 (class of recommendation)
하나의 티켓 템플릿 (ticket template)
하나의 Slack 채널
하나의 인간 승인 경로 (human approval path)
하나의 측정된 절감 목표

유휴 비프로덕션 리소스 (Idle non-production resources)가 좋은 후보가 될 수 있습니다. 저위험 규모 조정 (low-risk rightsizing) 권장 사항이 또 다른 후보가 될 수도 있습니다. Savings Plans 권장 사항은 유혹적이지만, 나는 약정 결정 (commitment decisions)을 더 높은 거버넌스 (governance) 워크플로우로 취급할 것입니다. 왜냐하면 실패 모드 (failure mode)가 다르기 때문입니다.

첫 번째 목표는 에이전트가 비용 신호 (cost signal)를 소유 가능하고, 검토 가능하며, 측정 가능한 행동 (action)으로 전환할 수 있음을 증명하는 것이어야 합니다.

예쁜 보고서가 아니라,

하나의 행동이어야 합니다.

그런 다음 나는 거절 사유를 측정할 것입니다. 바로 그 지점에서 시스템이 개선됩니다. 만약 소유자들이 태그가 잘못되었다는 이유로 권장 사항을 거절한다면, 플랫폼의 문제는 태깅 (tagging)입니다. 만약 예상 트래픽에 대한 에이전트의 문맥 (context)이 부족하여 거절한다면, 문제는 문맥입니다. 만약 티켓이 너무 많아서 무시한다면, 문제는 워크플로우 설계 (workflow design)입니다.

에이전트는 당신의 클라우드 운영 모델 (cloud operating model)의 지저분한 부분들을 드러낼 것입니다.

당신이 직시할 의지만 있다면, 이는 매우 유용합니다.

핵심 (the punchline)

AWS FinOps Agent는 클라우드 운영이 어디로 향하고 있는지를 보여주는 좋은 신호입니다.

대시보드가 사라지는 것은 아니지만, 무게 중심이 이동하고 있습니다. 비용 데이터는 에이전트가 추론하고, 스케줄링하고, 요약하고, 라우팅하며, 운영 워크플로우에 연결할 수 있는 무언가가 되어가고 있습니다.

이는 진정으로 유용할 수 있습니다. 클라우드 낭비는 실재하며, 이상 징후 대응 (anomaly response)은 지루하고, 많은 비용 권장 사항들은 아무도 그것을 소유된 작업으로 전환하지 않기 때문에 사장됩니다.

하지만 유용한 버전은 "에이전트가 청구서를 관리하게 두는 것"이 아닙니다.

유용한 버전은 책임 소재가 명확한 워크플로 (workflow)입니다: 증거 (evidence), 소유권 (ownership), 승인 (approvals), 티켓 상태 (ticket state), 측정된 영향 (measured impact), 그리고 권고 (recommendation)와 결정 (decision) 사이의 명확한 경계가 그것입니다.

클라우드 비용은 항상 공동 책임 (shared responsibility)이었으며, 이는 종종 모든 사람의 책임인 동시에 아무의 책임도 아니라는 말을 완곡하게 표현하는 방식입니다.

에이전트 (Agents)가 스스로 그 문제를 해결하지는 않을 것입니다.

그들은 결여된 소유권 (ownership)을 더 빠르게 가시화할 뿐입니다.

그것만으로도 여전히 진전입니다.

references

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작할 때 20달러 (USD)를 받고 싶다면, 이 링크를 사용하세요.