클라우드 비용을 관리하다 보면 이런 질문을 자주 하게 됩니다.

“왜 이번 달 AWS 비용이 갑자기 증가했을까?”

문제는 비용이 증가했다는 사실을 확인하는 것보다 왜 증가했는지를 찾는 일이 훨씬 어렵다는 것입니다.

어떤 서비스 때문인지,

어떤 계정에서 발생했는지,

어떤 리소스가 변경되었는지,

그리고 실제로 비용을 줄일 수 있는 것인지

하나씩 확인해야 합니다.

특히 AWS 계정과 서비스가 많아지면 Cost Explorer만 열어 놓고 원인을 찾는 것도 생각보다 쉽지 않습니다.

이런 상황에서 AWS가 AWS FinOps Agent를 공개했습니다.

AWS FinOps Agent는 2026년 6월 9일 Public Preview로 공개되었으며, 비용 관련 질문, 비용 이상 조사, 최적화 기회 탐색, 반복적인 FinOps 업무 자동화 등을 지원합니다.

1. AWS FinOps Agent란?

쉽게 말하면 AWS 비용을 관리해주는 AI Agent입니다.

예를 들어 엔지니어가 다음과 같이 질문할 수 있습니다.

“지난달 AWS 비용이 왜 증가했어?”

그러면 Agent가 실제 AWS 비용 및 사용량 데이터를 확인해서 어떤 서비스와 사용량 변화가 비용 증가에 영향을 주었는지 분석합니다.

여기서 중요한 것은 단순한 챗봇이 아니라는 점입니다.

질문 → 답변

에서 끝나는 것이 아니라,

질문 → 데이터 조회 → 분석 → 원인 파악 → 후속 작업

까지 연결할 수 있습니다.

2. 실제 운영에서는 이런 상황이......

예를 들어 월요일 아침에 AWS 비용 알림이 왔다고 생각해 보겠습니다.

AWS Cost Anomaly Detection
예상보다 비용이 증가했습니다.

기존에는 담당자가 직접 AWS Console에 들어갑니다.

그리고

Cost Explorer

→ 어느 서비스인가?

→ 어느 계정인가?

→ 어떤 리소스인가?

→ 사용량이 증가했는가?

→ 단가가 변경되었는가?

→ 최근 배포가 있었는가? 변경이 있었는가?

등을 하나씩 확인해야 합니다.

AWS FinOps Agent를 사용하면 이 과정을 자동화할 수 있습니다.

AWS가 제공하는 기능 중 하나가 Cost Anomaly Detection 이벤트를 받아 Agent가 자동으로 조사하고 결과를 Slack이나 Jira로 전달하는 기능입니다.

3. 실제로는 어떤 흐름으로 동작할까?

쉽게 구성하면 다음과 같이 생각할 수 있습니다.

AWS Cost Anomaly Detection--> AWS FinOps Agent--> Cost / Usage 분석-->관련 AWS 이벤트 확인--> 원인 분석--> Slack 또는 Jira

예를 들어 새로운 EC2 인스턴스가 대량으로 생성되어 비용이 증가했다고 해보겠습니다.

Agent가 비용 변화만 보는 것이 아니라 관련 AWS 이벤트까지 확인하면,

“특정 시점에 EC2 사용량이 증가했고, 해당 시점에 새로운 인스턴스가 생성된 것을 확인했습니다.”

와 같은 형태로 원인을 좁혀갈 수 있습니다. 바로 원인을 알 수 있는 거죠.

AWS도 비용 변화와 CloudTrail 이벤트 등을 연결하여 비용 이상을 조사하는 방식을 설명하고 있습니다.

4. 실무적으로 재미있는 부분

실무에서는 “비용이 증가했다”는 사실 자체가 문제는 아닐 수도 있습니다.

예를 들어 신규 서비스를 출시하면서 EC2 사용량이 증가했다면 비용 증가는 자연스러운 현상입니다.

반대로 개발자가 테스트를 위해 생성한 리소스를 삭제하지 않아 비용이 증가했다면 최적화 대상이 될 수 있습니다.

따라서 FinOps에서 중요한 것은 단순한 Cost Increase Detection이 아니라,

“이 비용 증가가 정상적인 것인가?”

를 판단하는 것입니다.

AWS FinOps Agent가 지향하는 것도 단순히 비용이 증가했다고 알려주는 것이 아니라, 비용 변화의 원인을 조사하고 최적화 기회를 찾는 것입니다. 게다가 이것을 챗봇의 형태로, 자연어로 질문하고 답변 받을 수 있다는 것이 장점입니다.

5. 조직 정보 추가

실무에서는 AWS 계정 이름만 가지고 담당자를 판단하기 어려운 경우가 많습니다.

예를 들어

만 있다면 이 계정이 어느 팀 소유인지 알기 어렵습니다.

AWS FinOps Agent에서는 계정-담당자 매핑, 팀 정보, 태그 규칙, 예외사항 등의 Context를 제공할 수 있습니다.

예를 들어

처럼 조직의 정보를 제공하면,

“AI팀의 지난달 비용이 왜 증가했지?”

라는 질문을 조직의 실제 계정 구조에 맞춰 처리할 수 있습니다.

이런 부분은 실제 회사 환경에서 상당히 중요합니다. 보통은 MSP 솔루션에서 이런 기능을 추가로 제공합니다.

6. Slack과 Jira까지 연결

개인적으로 실무에서 가장 의미있는 부분은 Slack과 Jira 연결입니다.

비용 이상이 발견되었는데 담당자가 AWS Console을 다시 확인해야 한다면 자동화 효과가 크지 않습니다.

하지만 다음과 같이 연결할 수 있습니다.

Cost Anomaly --> FinOps Agent 조사 --> 원인 분석 결과 --> Slack 알림 --> Jira Ticket --> 담당자 조치

AWS FinOps Agent는 비용 이상 조사 결과를 Slack 또는 Jira로 전달할 수 있고, 최적화 추천 사항을 Jira 티켓으로 정리할 수도 있습니다.

즉, FinOps 분석 결과를 실제 개발팀의 업무 프로세스 안으로 가져오는 것입니다.

7. 자동화 예시

실제 운영 환경을 가정해 보면 다음과 같은 형태가 될 수 있습니다.

시나리오

1. AWS 비용 이상 발생

2. Cost Anomaly Detection 이벤트 발생

3. FinOps Agent 자동 실행

4. 비용 증가 서비스 확인

5. 사용량 변화 분석

6. 관련 변경사항 조사

7. 최적화 가능 여부 판단

8. Slack에 결과 전달

9. 필요한 경우 Jira Ticket 생성

이렇게 만들어 놓으면 담당자가 매번 비용 이상 알림을 보고 처음부터 조사할 필요가 줄어듭니다.

AWS 공식 문서에서도 이러한 이벤트 기반 자동화 workflow를 하나의 주요 사용 방식으로 설명하고 있습니다.

8. 기존 FinOps와 비교해 보면

기존 방식은 대략 다음과 같습니다.

비용 알림

→ 사람이 확인

→ Cost Explorer 확인

→ 관련 서비스 확인

→ 담당자 확인

→ 원인 조사

→ 최적화 방법 검토

→ Jira 등록

반면 Agent를 활용하면

비용 알림

→ Agent 자동 조사

→ 원인 분석

→ 최적화 기회 확인

→ Slack / Jira 전달

과 같이 바뀔 수 있습니다.

즉,

사람이 데이터를 찾아가는 방식에서 Agent가 데이터를 찾아서 정리해주는 방식으로 바뀌는 것입니다.

9. 그렇다고 모든 것을 Agent에게 맡기면 될까?

여기서 한 가지 주의할 점이 있습니다.

분석과 실제 리소스 변경은 구분할 필요가 있습니다.

예를 들어

“이 EC2 인스턴스는 사용하지 않는 것 같습니다.”

라는 분석 결과와

“그러니 EC2 인스턴스를 삭제하겠습니다.”

는 완전히 다른 문제입니다.

특히 Production 환경에서는 잘못된 판단 하나가 서비스 장애로 이어질 수 있습니다.

따라서 초기에는

Agent → 분석 → 사람 승인 → 실행

방식으로 시작하는 것이 현실적입니다.

즉, Agent에게 모든 권한을 주기보다는 읽기 및 분석 권한 중심으로 시작하고, 실제 변경 작업은 승인 절차를 두는 방식이 좋습니다.

AWS FinOps Agent도 각 Agent에 IAM 권한과 접근 리소스를 별도로 구성할 수 있도록 하고 있습니다.

마무리

AWS FinOps Agent를 처음 보면

“AWS 비용을 자연어로 물어볼 수 있는 AI 서비스”

정도로 생각할 수도 있습니다.

하지만 실제 의미는 조금 더 큽니다.

기존에는

비용 발생 → 사람이 확인→ 사람이 분석→ 사람이 조치

였다면,

앞으로는

비용 발생→ AI Agent 조사→ 원인 분석→ 최적화 추천→ 업무 시스템 연결

이라는 방식으로 발전할 수 있습니다.

특히 AWS FinOps Agent는 Cost Explorer, Cost Anomaly Detection, Cost Optimization Hub, Compute Optimizer 등의 기존 AWS 비용 관리 기능을 Agent가 활용하도록 연결했다는 점에서 의미가 있습니다.

그리고 이 변화의 핵심은 결국 하나라고 생각합니다.

“비용을 보여주는 것”에서 “비용 문제를 찾아서 해결하는 것”으로.

앞으로 FinOps가 단순한 비용 관리 업무가 아니라 AI 기반의 Continuous Operations로 발전할지 지켜볼 만한 부분입니다.

참고 자료

AWS — Announcing the public preview of AWS FinOps Agent

AWS — AWS FinOps Agent is now available in preview

AWS — Introducing AI-Powered Cost Investigations For Cost Anomalies

AWS — Which AI tool for which FinOps Use Case?

LLM을 사용하다 보면 이런 질문을 한 번쯤 하게 됩니다.

“이 AI가 지금 최신 정보를 알고 있을까?”

예를 들어

“오늘 주식시장은?”

“2026년 최신 AI 기술은?”

“어제 발표된 AWS 서비스는?”

라고 질문한다면 문제가 생깁니다. 정확한 대답을 못하고 환각을 일으킬지 모릅니다.(그냥 문자를 만들어 내는 거죠)

LLM이 학습한 데이터에 최신 정보가 포함되어 있지 않을 수 있기 때문입니다.

그래서 지금까지는 이런 문제를 해결하기 위해 검색엔진 + LLM을 별도로 연결하는 방식이 많이 사용되었습니다.

그런데 AWS가 최근 흥미로운 기능을 발표했습니다.

바로 Web Search on Amazon Bedrock입니다.

AWS는 2026년 8월 4일 이 기능을 일반 제공(GA)한다고 발표했습니다.

1. LLM은 왜 최신 정보를 모를까?

LLM은 기본적으로 학습된 데이터를 바탕으로 답변을 생성합니다.

따라서 모델이 아무리 뛰어나더라도

오늘 발생한 사건, 방금 발표된 제품, 실시간 주가, 최신 뉴스

같은 정보는 알기 어렵습니다.

물론 개발자가 별도의 검색 시스템을 연결할 수 있습니다.

대표적인 방식이 바로 RAG(Retrieval-Augmented Generation)입니다. 검색 증강 생성이지요.

구조를 단순하게 보면 다음과 같습니다.

사용자 질문 --> 검색 시스템 --> 관련 문서 검색 --> LLM에 전달 --> 답변 생성

이 방식은 매우 강력하지만 개발자가 직접 검색 시스템을 구성하고 관리해야 하는 경우가 많습니다.

LLM 만 있으면 되는게 아니라 이를 활용한 시스템을 만드러야 한다는 의미입니다. 예를 들면 추가로 LLM 뿐만아니라 Vector DB, Embedding 등이 필요합니다. 

이러한 것들을 쉽게 구성, 개발할 수 있도록 프레임웩을 제공하기도 합니다. LangChain 이 그 대표적인 예입니다.

2. AWS가 발표한 Web Search는 무엇인가?

AWS가 발표한 Web Search on Amazon Bedrock은 이 과정을 Amazon Bedrock 안에서 사용할 수 있도록 만든 기능입니다.

쉽게 말하면

“LLM이 필요할 때 웹을 검색해서 최신 정보를 가져온 다음 답변하도록 만드는 것”

입니다.

AWS는 Web Search를 서버 측 내장 도구(server-side built-in tool)라고 설명합니다.

따라서 별도의 제3자 검색 서비스나 외부 API를 직접 연결하지 않고도 웹 기반 grounding을 구현할 수 있습니다.

3. 기존 RAG와 무엇이 다를까?

기존 RAG에서는 일반적으로 개발자가 다음과 같은 시스템을 구축합니다.

Web / Database --> Crawler --> Embedding --> Vector Database --> Retriever --> LLM

상당히 많은 구성 요소가 필요합니다.

반면 Web Search를 사용하면

사용자 --> Amazon Bedrock --> Web Search --> 최신 웹 정보 --> LLM

이라는 훨씬 단순한 구조를 만들 수 있습니다.

물론 RAG와 Web Search가 서로 대체 관계라고 보기는 어렵습니다.

기업 내부 문서를 검색해야 한다면 기존 RAG가 여전히 중요합니다.

반면 인터넷의 최신 정보를 찾아야 한다면 Web Search가 훨씬 자연스러운 선택이 될 수 있습니다.

4. 가장 큰 변화는 “최신성”이다

LLM 애플리케이션에서 중요한 문제가 하나 있습니다.

바로 Knowledge Cutoff입니다.

모델이 아무리 뛰어나도 학습 이후 발생한 사건을 알 수는 없습니다.

Web Search를 사용하면 이 부분을 보완할 수 있습니다.

예를 들어

“최근 AWS에서 발표한 AI 기술 중 중요한 것은?”

이라는 질문이 들어왔다고 생각해 보겠습니다.

기존 LLM이라면 학습 데이터에 따라 오래된 AWS 기술을 이야기할 가능성이 있습니다.

하지만 Web Search를 사용하면

질문 --> 웹 검색 --> 최근 AWS 발표 검색 --> 관련 정보 수집 --> LLM 답변 생성

이라는 방식으로 최신 정보를 반영할 수 있습니다.

5. 검색만 하는 것이 아니라 Grounding이 중요하다

여기서 중요한 단어가 하나 있습니다.

Grounding 입니다.

단순히 검색 결과를 보여주는 것과 검색 결과를 근거로 답변을 생성하는 것은 다릅니다.

Grounding의 목적은 LLM이 자신의 기억만으로 답변하는 것이 아니라 외부의 실제 정보에 근거해서 답변하도록 만드는 것입니다.

AWS는 Web Search를 통해 모델 응답을 현재 웹 지식에 grounding할 수 있다고 설명하고 있습니다.

따라서 앞으로 AI 애플리케이션에서는

“AI가 얼마나 똑똑한가?”

뿐만 아니라

“AI가 어떤 정보를 근거로 답변하고 있는가?”

도 중요해질 것입니다.

6. 그렇다면 RAG가 필요 없어지는 것일까?

그렇지는 않습니다.

오히려 두 기술의 역할이 달라진다고 보는 것이 좋습니다.

예를 들어 회사의 내부 문서를 검색하는 AI라면

사내 문서 → RAG 가 적합합니다.

반면 최신 시장 뉴스나 공개된 웹 정보를 검색한다면

인터넷 → Web Search 가 적합합니다.

그리고 실제 기업용 AI에서는 두 가지를 함께 사용할 수도 있습니다.

예를 들어 고객이

“우리 회사의 최신 제품 정책과 현재 시장 상황을 비교해줘.”

라고 질문한다면

회사 내부 데이터, 최신 웹 정보를 함께 사용해야 합니다.

결국 앞으로의 AI 애플리케이션은 하나의 검색 방식만 사용하는 것이 아니라 질문에 따라 적절한 지식 소스를 선택하는 방향으로 발전할 가능성이 높습니다.

7. Agent 시대에는 더 중요해진다

이 기능이 특히 흥미로운 이유는 AI Agent와 연결되기 때문입니다.

AI Agent는 단순히 질문에 답하는 것이 아니라 검색하고 판단하고 도구를 사용하고 다음 행동을 결정하는

방향으로 발전하고 있습니다.

예를 들어 여행 Agent라면

사용자 요청 --> 여행 정보 검색 --> 항공편 확인 --> 호텔 검색 --> 가격 비교 --> 일정 생성

같은 작업을 수행할 수 있습니다.

여기서 최신 웹 정보가 없다면 Agent의 판단도 오래된 정보에 의존할 수밖에 없습니다.

따라서 Web Search 같은 실시간 정보 접근 능력은 Agent의 중요한 기본 기능이 될 가능성이 높습니다.

8. 개발자 입장에서는 무엇이 달라질까?

기존에는 개발자가 직접

• 검색 API 선택
• 검색 시스템 구축
• API 인증 관리
• 검색 결과 처리
• 보안 검토
• 장애 처리
• 결과를 LLM에 전달하는 로직

등을 관리해야 했습니다.

AWS는 Web Search를 Bedrock의 기능으로 제공하면서 이러한 외부 검색 서비스 연결에 필요한 일부 복잡성을 줄이는 방향을 제시하고 있습니다. 특히 AWS는 별도의 제3자 공급자 도입이나 외부 API orchestration, 제3자 보안 검토가 필요 없다는 점을 강조하고 있습니다.

즉,

검색 기능을 직접 만드는 것에서 검색 기능을 AI 플랫폼의 기본 기능으로 사용하는 것

으로 변화하고 있는 것입니다.

9. 그런데 새로운 문제가 하나 생긴다

여기서 재미있는 문제가 생깁니다.

검색을 많이 하면 비용도 증가할 수 있다는 것입니다.

LLM 호출 비용뿐만 아니라

검색 → 검색 결과 처리 → 추가적인 Input Token → LLM 추론

이 연결될 수 있습니다.

따라서 앞으로 AI 애플리케이션에서는 단순한 Cloud FinOps를 넘어

LLM Token FinOps 까지 함께 고려해야 합니다.

예를 들어 다음과 같은 지표가 중요해질 수 있습니다.

• 요청 수
• Web Search 호출 수
• 검색 결과 수
• Input Token
• Output Token
• LLM 호출 비용
• Search 비용
• 요청당 총 비용
• 성공적인 답변 비율

결국 “검색을 사용해서 얼마나 좋은 결과를 만들었는가?”까지 분석해야 합니다.

마무리

이번 AWS의 Web Search 발표를 단순히

“Bedrock에 검색 기능 하나가 추가됐다.”

라고 보면 조금 아쉽습니다.

더 중요한 변화는 LLM이 고정된 지식만 사용하는 구조에서 벗어나 최신 외부 정보를 필요할 때 직접 가져오는 구조로 발전하고 있다는 것입니다.

기존에는 LLM --> 학습된 지식 이었다면,

앞으로는 LLM, 검색, 외부 데이터, Tools 들를 결합하는 방향으로 발전할 가능성이 높습니다.

그리고 이것은 우리가 앞에서 살펴본 AI Observability와 FinOps와도 연결됩니다.

AI가 어떤 정보를 검색했는지,

얼마나 많은 토큰을 사용했는지,

얼마나 비용이 발생했는지,

그리고 그 결과 실제로 얼마나 좋은 답변을 만들었는지를 함께 관찰해야 하기 때문입니다.

결국 앞으로의 AI 시스템에서는

“AI가 얼마나 똑똑한가?”

라는 질문에서 한 단계 더 나아가

“AI가 최신 정보를 얼마나 잘 찾고, 올바르게 사용하며, 얼마나 효율적으로 비용을 관리하면서 가치를 만들어내는가?”

가 중요한 경쟁력이 될 것 같습니다.

참고

AWS 공식 발표 — Introducing Web Search on Amazon Bedrock

Amazon Bedrock 공식 페이지

클라우드를 사용하면 IT 인프라를 빠르게 확장할 수 있습니다. 사실 요즘 클라우드를 모르는 사람이 없을 정도 입니다.

필요할 때 서버를 만들고, 사용하지 않으면 줄일 수 있습니다. 그런데 여기에는 한 가지 문제가 있습니다.

“편리한 만큼 비용도 쉽게 증가한다.”

클라우드 사용량이 늘어나면서 기업들은 단순히 비용을 줄이는 것보다 클라우드 비용을 어떻게 비즈니스 가치로 연결할 것인가를 고민하기 시작했습니다.

이때 등장한 개념이 바로 Cloud FinOps입니다.

1. FinOps란 무엇인가?

FinOps는 Finance + DevOps를 결합한 용어입니다.

쉽게 말하면,

기술팀, 재무팀, 비즈니스팀이 함께 클라우드 비용과 사용량을 관리하는 운영 방식

입니다.

중요한 것은 FinOps가 단순한 “클라우드 비용 절감 방법”​이 아니라는 점입니다.

최근 FinOps Foundation의 정의도 비용 절감보다는 기술의 비즈니스 가치를 극대화하고, 데이터 기반 의사결정과 비용에 대한 책임을 만드는 것​에 초점을 맞추고 있습니다.

즉,

싸게 사용하는 것

보다

필요한 곳에 적절한 비용을 사용해서 더 큰 가치를 만드는 것

이 FinOps의 핵심입니다.

2. 왜 FinOps가 필요할까?

전통적인 IT 환경에서는 서버를 구매하면 비용이 어느 정도 고정되어 있었습니다.

하지만 클라우드는 다릅니다.

서버를 많이 사용하면 비용이 증가하고,

데이터를 많이 저장하거나 전송해도 비용이 증가합니다.

AI를 사용하면 GPU 비용까지 추가됩니다.

문제는 이러한 비용이 여러 팀과 서비스에 분산되면서

“도대체 누가 얼마나 사용하고 있는가?”

를 파악하기 어려워진다는 것입니다.

따라서 FinOps에서는 먼저 비용을 보이게 만드는 것이 중요합니다.

3. FinOps의 핵심은 가시성이다

예를 들어 한 달 클라우드 비용이 1억 원이 발생했다고 생각해 보겠습니다.

단순한 청구서만 보면

Cloud Cost = 1억원

이라는 사실만 알 수 있습니다.

하지만 FinOps에서는 이를 다음과 같이 나누려고 합니다.

• 어느 서비스에서 사용했는가?
• 어느 팀이 사용했는가?
• 어떤 프로젝트인가?
• GPU 비용은 얼마인가?
• Storage 비용은 얼마인가?
• Network 비용은 얼마인가?
• 실제 비즈니스 매출이나 사용자 수와 어떤 관계가 있는가?

이렇게 비용을 서비스·팀·프로젝트·사용량과 연결하면 비로소 비용을 분석할 수 있습니다.

4. FinOps는 어떻게 동작할까?

FinOps를 아주 단순하게 표현하면 다음과 같습니다.

데이터 수집 --> 비용 가시화 --> 분석 --> 최적화 --> 성과 측정

그리고 다시 데이터를 수집합니다.

즉, 한 번 비용을 줄이고 끝나는 것이 아니라 지속적으로 반복하는 운영 사이클입니다.

예를 들어 사용하지 않는 VM을 발견했다면 삭제할 수 있고,

사용량이 일정한 서비스라면 적절한 약정 할인이나 요금제를 검토할 수 있습니다.

반대로 비용은 증가했지만 매출이나 사용자 가치가 더 크게 증가했다면 단순히 비용을 줄이는 것이 정답은 아닐 수도 있습니다.

이것이 FinOps가 단순한 Cost Cutting과 다른 이유입니다.

5. 중요한 것은 “비용”보다 “가치”다

FinOps에서 점점 중요해지고 있는 개념이 Unit Economics입니다.

예를 들어 AI 서비스의 비용을 단순히

“이번 달 GPU 비용이 5천만 원이다.”

라고 보는 것보다,

“사용자 1명에게 AI 서비스를 제공하는 데 평균 100원이 든다.”

또는

“AI 질문 1,000건을 처리하는 데 2만 원이 든다.”

처럼 비용을 비즈니스 단위와 연결하는 것입니다.

그러면 비용이 증가했을 때도 그것이 정말 나쁜 것인지 판단할 수 있습니다.

FinOps Foundation 역시 Cloud Unit Economics를 클라우드 비용과 사용량을 비즈니스 성과와 연결하는 중요한 개념으로 설명하고 있습니다.

6. AI 시대에는 FinOps가 더 중요해진다

AI 서비스에서는 FinOps가 더욱 중요해질 가능성이 높습니다.

특히 GPU는 일반 CPU 서버보다 비용 구조가 복잡하고 사용량에 따라 비용 차이도 커질 수 있습니다.

예를 들어 다음과 같은 데이터를 함께 볼 수 있습니다.

• GPU 사용률
• GPU 사용 시간
• GPU 종류
• GPU 전력
• AI 모델
• Training / Inference 작업
• 사용자 수
• API 호출량
• 토큰 사용량
• 클라우드 비용

그러면 단순히

“GPU 비용이 얼마인가?”

가 아니라

“AI 서비스를 제공하기 위해 사용자 1명 또는 요청 1건당 얼마의 비용이 발생하는가?”

를 계산할 수 있습니다.

이것이 AI 시대의 FinOps에서 중요한 방향 중 하나입니다.

특히, LLM 사용이 폭발적으로 증가하면서 토큰 사용에 대한 FinOps가 대두되고 있습니다.

7. Multi-Cloud에서는 더 어려워진다

AWS, Azure, Google Cloud 등을 동시에 사용한다면 비용 관리는 더욱 복잡해집니다.

각 클라우드마다

• 상품 이름
• 과금 방식
• 할인 정책
• 청구 데이터 형식

이 다르기 때문입니다.

그래서 최근 FinOps 분야에서는 FOCUS(FinOps Open Cost and Usage Specification)​가 중요해지고 있습니다.

FOCUS는 서로 다른 클라우드와 기술 공급자의 비용·사용량 데이터를 일관된 형식으로 표준화하기 위한 개방형 규격입니다. 2026년 6월에는 FOCUS 1.4가 발표됐습니다.

쉽게 말하면,

AWS 비용, Azure 비용, Google Cloud 비용을 같은 언어로 비교할 수 있도록 만드는 것

이라고 이해하면 됩니다.

8. FinOps는 Cloud에서 끝나지 않는다

흥미로운 변화도 있습니다.

FinOps의 범위가 점점 Cloud를 넘어가고 있다는 것입니다.

2026년 FinOps Foundation 자료에 따르면 FinOps 실무자 중 98%가 AI 비용을 관리하고 있으며, SaaS, 라이선스, Private Cloud, Data Center까지 관리 범위가 확대되고 있습니다.

특히 데이터센터 비용까지 FinOps의 관리 대상으로 포함하려는 움직임이 커지고 있습니다. 2026년에는 FinOps와 FOCUS를 데이터센터 환경에 적용하는 방법도 본격적으로 논의되고 있습니다.

결국 FinOps는

Cloud Cost Management

에서

Technology Value Management

로 확장되고 있는 것입니다.

마무리

Cloud FinOps를 한 문장으로 정리하면 다음과 같습니다.

“기술 비용을 투명하게 만들고, 기술팀과 비즈니스팀이 함께 비용과 가치를 관리하는 방법”

처음에는

“클라우드 비용을 어떻게 줄일까?”

라는 질문에서 시작합니다.

하지만 FinOps가 발전하면 질문이 바뀝니다.

“이 비용으로 어떤 가치를 만들고 있는가?”

그리고 AI 시대에는 다시 질문이 바뀔 수 있습니다.

“GPU와 클라우드에 투자한 비용이 실제 AI 서비스의 가치로 얼마나 전환되고 있는가?”

결국 FinOps의 핵심은 비용 절감 자체가 아니라 비용과 사용량, 그리고 비즈니스 가치를 연결하는 것​이라고 볼 수 있습니다.

그리고 앞으로 AI 데이터센터, Cloud, GPU 인프라가 하나로 연결될수록 Observability와 FinOps의 결합도 중요한 주제가 될 것으로 보입니다.

Observability가 “무슨 일이 일어나고 있는가?”를 보여준다면,
FinOps는 “그 일이 얼마의 비용과 가치를 만들고 있는가?”를 보여주는 것입니다.

두 영역이 연결되면 AI 인프라를 단순히 잘 운영하는 것을 넘어 경제적으로 운영하는 것까지 가능해질 것입니다.

AI 데이터센터가 커질수록 운영은 점점 어려워지고 있습니다.

수천, 수만 개의 GPU가 연결되고, 여기에 고속 네트워크와 스토리지, 냉각 시스템까지 함께 움직입니다.

문제는 여기서 시작됩니다.

GPU 한 개에 문제가 생겼다면, 정말 GPU만의 문제일까?

최근 AI 인프라에서는 이 질문이 점점 중요해지고 있습니다.

그래서 AI 데이터센터에서는 기존의 Monitoring을 넘어 Observability가 중요해지고 있습니다.

단순히 GPU 사용률만 봐서는 부족하다

기존 데이터센터에서는 CPU 사용률, 메모리, 디스크, 네트워크 등의 상태를 확인하고 문제가 발생하면 알람을 발생시키는 방식이 일반적이었습니다.

하지만 AI 데이터센터는 조금 다릅니다.

예를 들어 GPU 사용률이 갑자기 100%에서 20%로 떨어졌다고 생각해 보겠습니다.

무슨 문제가 발생한 것일까요?

GPU 자체의 문제일 수도 있습니다.

하지만 CPU가 데이터를 제대로 공급하지 못했을 수도 있고,

스토리지에서 데이터를 읽는 속도가 느려졌을 수도 있습니다.

또는 GPU 사이의 NVLink, InfiniBand와 같은 네트워크 통신​에 문제가 발생했을 수도 있습니다.

즉,

GPU → CPU → Storage → Network → Job

전체를 함께 봐야 원인을 찾을 수 있습니다.

Monitoring과 Observability의 차이

Monitoring은 쉽게 말하면

“무슨 일이 발생했는가?”

를 알려주는 것입니다.

예를 들어

GPU Utilization = 20%

라는 정보를 보여줍니다.

하지만 Observability는 한 단계 더 나아갑니다.

“왜 GPU 사용률이 20%가 되었는가?”

를 찾는 것입니다.

예를 들어

GPU 사용률 감소 --> CPU 데이터 공급 지연 --> Storage I/O 증가 --> 학습 Job의 처리 속도 감소

와 같이 여러 데이터를 연결해서 원인을 찾아가는 것입니다.

최근 NVIDIA 역시 AI 인프라에서 GPU뿐 아니라 컴퓨팅, 네트워크, 스토리지, 애플리케이션 등 여러 계층의 텔레메트리를 연결하는 Full-Stack Observability를 강조하고 있습니다.

AI 데이터센터에서는 무엇을 봐야 할까?

AI DC Observability에서는 단순히 GPU만 보는 것이 아니라 여러 계층의 데이터를 함께 볼 필요가 있습니다.

예를 들면 다음과 같습니다.

• GPU 사용률
• GPU Memory
• GPU 온도
• GPU 전력
• GPU Error
• CPU 사용률
• Memory
• Storage I/O
• InfiniBand 상태
• NVLink 상태
• 서버 전력
• Rack 전력
• 냉각 상태
• Kubernetes / SLURM Job 상태
• AI Training / Inference 상태

중요한 것은 데이터의 양이 아니라 서로 연결하는 것입니다.

진짜 중요한 것은 Correlation이다

예를 들어 AI Training Job이 갑자기 느려졌다고 생각해 보겠습니다.

단순한 Monitoring 시스템이라면

“GPU 사용률이 감소했습니다.”

라는 알람을 보여줄 수 있습니다.

하지만 Observability 시스템이라면 다음과 같이 분석할 수 있습니다.

Training 속도 감소 --> GPU Utilization 감소 --> GPU 자체의 오류 없음 --> InfiniBand Latency 증가 --> 특정 Switch Port에서 Packet Error 증가 --> Network 문제가 Training 성능 저하의 원인

이렇게 되면 운영자는 GPU를 교체할 필요가 없다는 것을 빠르게 알 수 있습니다.

이것이 AI DC Observability의 중요한 가치입니다.

장애를 발견하는 것에서 위험을 예측하는 것으로

더 흥미로운 방향도 있습니다.

Observability의 목적이 단순히

“장애가 발생했습니다.”

라고 알려주는 것에서 끝나지 않는 것입니다.

GPU의 Error, 온도, 전력, 사용 패턴 등의 데이터를 장기간 분석하면

“어떤 GPU가 장애 위험이 높은가?”

를 판단할 수도 있습니다.

최근 연구에서도 대규모 GPU 클러스터의 장애를 정확한 발생 시점으로 예측하기보다는 장애 위험이 높은 노드를 순위화하는 방식이 효과적이라는 결과가 발표되었습니다.

이런 방식은 AI 데이터센터 운영에서 상당히 중요한 의미를 가집니다.

앞으로는 GPU를 잘 배치하는 것도 Observability가 된다

여기서 한 단계 더 나아갈 수 있습니다.

만약 시스템이

• GPU Health
• GPU 사용률
• GPU 전력
• 온도
• Network 상태
• Job 중요도
• 과거 장애 이력

을 모두 알고 있다면,

단순히 장애를 알려주는 것에서 끝나는 것이 아니라

“이 Job은 장애 위험이 높은 GPU를 피해서 실행하자.”

라고 판단할 수 있습니다.

즉,

Observability --> Anomaly Detection --> Risk Prediction --> Resource Optimization

으로 발전하는 것입니다.

AI 데이터센터의 새로운 운영 방식

결국 AI 데이터센터의 운영 방식도 바뀌고 있습니다.

기존에는

Monitoring → Alert → 사람이 대응

이었다면,

앞으로는

Observability → Correlation → Anomaly Detection → Root Cause Analysis → 자동 대응

으로 발전할 가능성이 높습니다.

특히 AI 데이터센터에서는 GPU, 네트워크, 전력, 냉각, Job이 서로 강하게 연결되어 있기 때문에 각각을 별도로 관리하는 방식에는 한계가 있습니다.

최근 AI 인프라 Observability 분야에서도 GPU 사용률뿐 아니라 GPU 상태, 냉각, 전력, 네트워크 등을 함께 바라보는 통합적인 접근이 중요해지고 있습니다.

마무리

AI 데이터센터가 커질수록 중요한 것은 단순히 GPU를 많이 설치하는 것이 아닙니다.

그 GPU들이

정상적으로 동작하고 있는지,

제대로 활용되고 있는지,

서로 통신하고 있는지,

전력을 효율적으로 사용하고 있는지,

장애가 발생하기 전에 위험을 발견할 수 있는지

를 알아야 합니다.

그래서 앞으로 AI 데이터센터에서는

Monitoring보다 Observability가 중요해질 것입니다.

그리고 궁극적으로는

Observability → AI 분석 → 예측 → 자동 최적화

라는 방향으로 발전할 가능성이 높습니다.

AI 데이터센터가 거대한 GPU 공장이 되어갈수록,

그 안에서 무슨 일이 일어나고 있는지를 “볼 수 있는 능력” 자체가 새로운 경쟁력이 될 것 같습니다.