반응형

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의 핵심입니다.

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 인프라를 단순히 잘 운영하는 것을 넘어 경제적으로 운영하는 것까지 가능해질 것입니다.

반응형

+ Recent posts