Web Search Amazon Bedrock AgentCore: 오래된 지식 문제의 종결과 AI 에이전트의 진화

원문은 twarx.com에서 처음 게시되었습니다 - 전체 인터랙티브 버전은 그곳에서 읽어보세요.

최종 업데이트: 2026년 6월 19일

Web Search Amazon Bedrock AgentCore는 AWS가 실시간 웹 그라운딩 (Web Grounding)을 에이전트 인프라 내부의 일급 관리형 기능 (First-class managed capability)으로 전환하고 있음을 보여줍니다. 이는 실제 운영 환경의 AI가 가진 가장 위험한 결함을 조용히 해결합니다. 즉, 오늘 이전에 여러분의 팀이 배포한 모든 에이전트는 고정된 지식 (Frozen knowledge)을 바탕으로 의사결정을 내리고 있었으며, 운영 환경에서 오래 실행될수록 더욱 확신에 찬 오답을 내놓게 된다는 점입니다.

Web Search Amazon Bedrock AgentCore를 통해 ML 팀은 에이전트가 사실 관계를 최신 상태로 유지하기 위해 Tavily, SerperDev 또는 Bing을 LangGraph 및 AutoGen 파이프라인에 일일이 수동으로 연결할 필요가 없습니다. 이는 데모 수준의 에이전트와 실제 배포 수준의 에이전트 사이의 격차가 항상 그라운딩 (Grounding) 문제였다는 점에서 현재 매우 중요한 이슈입니다.

이 글을 마칠 때쯤 여러분은 이 기능이 해결하는 구조적 실패 모드 (Structural failure mode)가 무엇인지, OpenAI, Anthropic 및 LangChain의 접근 방식과 어떻게 비교되는지, 그리고 정확히 무엇을 가장 먼저 마이그레이션해야 하는지 이해하게 될 것입니다.

이 시각화 자료는 배포 시간에 따른 정적 지식 에이전트 (Static-knowledge agent)와 웹 그라운딩 에이전트 (Web-grounded agent) 간의 차이를 보여줍니다. 이것이 바로 지식 동결 문제 (Knowledge Freeze Problem)의 핵심입니다. 출처

이 기능이 나오기 전에 구축된 모든 AI 에이전트가 구조적으로 결함이 있었던 이유

대부분의 팀이 겉으로 말하지 않는 역설적인 진실은 다음과 같습니다. 높은 벤치마크 점수가 당신의 에이전트가 실제 운영 환경(production)에서 신뢰할 수 있다는 증거는 아닙니다. 그것은 당신의 에이전트가 더 이상 존재하지 않는 세상에 대한 질문에 답하는 데 능숙했다는 증거일 뿐입니다. 저는 내부 평가(internal evals)를 완벽하게 통과하고도 출시 바로 다음 날 실시간 가격 조회 질문에서 우리를 당황하게 만든 에이전트들을 배포해 본 적이 있습니다. 그리고 바로 그 경험이 Web Search Amazon Bedrock AgentCore가 제거하고자 하는 핵심 요소입니다.

지식 동결 문제 (The Knowledge Freeze Problem): 정의와 시간이 흐를수록 심화되는 이유

대부분의 ML 엔지니어들은 학습 중단 시점(training cutoffs)을 사용자가 이해하고 우회할 수 있는 알려진 한계로 취급합니다. 하지만 그 가정은 틀렸습니다. 문제는 모델에 최신 정보가 부족하다는 것이 아닙니다. 문제는 모델이 자신의 정보가 오래되었다는 것을 알려주는 내부 신호(internal signal)가 없다는 점입니다. 그래서 모델은 시간 민감적인(temporally-sensitive) 질문에 대해서도 변하지 않는 사실에 대한 질문과 동일한 확신을 가지고 답변합니다. 유보적인 태도도, 불확실성도 없습니다. 그저 사실처럼 전달되는 유창하고 틀린 답변뿐입니다.

정립된 프레임워크

지식 동결 문제 (The Knowledge Freeze Problem) — 정적 학습 데이터(static training data)로 작동하는 AI 에이전트가 시간이 지남에 따라 점진적으로 신뢰성이 떨어지게 되는 구조적 상태를 의미하며, 인프라 계층에서의 실시간 웹 그라운딩(live web grounding) 없이는 프롬프트 엔지니어링(prompt engineering)이나 RAG 튜닝만으로는 완전히 해결할 수 없는 복합적인 환각(hallucination) 위험을 생성함

이 용어는 배포된 모든 에이전트가 겪게 되는 조용한 쇠퇴 곡선을 명명합니다. 즉, 학습 중단 시점 이후로 시간 민감적인 질문에 대한 정확도는 지속적으로 저하되는 반면, 확신도는 평탄하게 유지됩니다. 위험한 것은 오류율 자체가 아니라, 답변이 오래되었다는 것을 다운스트림 시스템(downstream systems)에 경고할 수 있는 어떠한 불확실성 신호도 없다는 점입니다.

정적 학습 중단 시점이 어떻게 확신에 찬 에이전트를 확신에 찬 거짓말쟁이로 만드는가

6개월 전의 학습 중단 시점(training cutoff)을 가진 상태로 1월에 배포된 에이전트를 가정해 봅시다. 이 에이전트가 1년 동안 운영되는 동안, 가격 책정, 인력, 규제 및 경쟁사의 움직임에 대해 18개월이나 지난 정보로 추론할 수 있으며, 이를 매우 유창하게 수행할 것입니다. OpenAI의 환각(hallucination)에 관한 자체 연구에 따르면, 모델은 안정적인 사실에 대한 질문보다 시간 민감적인(temporally-sensitive) 질문에서 측정 가능한 수준으로 더 확신에 차서 틀린 답을 내놓는다는 점이 기록되어 있으며, 이러한 발견은 LLM 환각에 관한 광범위한 학술 조사에서도 확인됩니다. 그 확신이 바로 함정입니다. 이것은 모델의 버그가 아닙니다. 구조적인 보장(structural guarantee)입니다.

지식이 고정된(frozen-knowledge) 에이전트는 정확도가 점진적으로 떨어지는 것이 아닙니다. 틀렸을 때 가장 큰 비용이 발생하는 바로 그 질문들에 대해 더욱 확신에 차서 틀린 답을 내놓습니다.

RAG와 프롬프트 엔지니어링(Prompt Engineering)이 이를 해결하기에 결코 충분하지 않았던 이유

이에 대한 표준적인 답변은 검색 증강 생성 (RAG, Retrieval-Augmented Generation)입니다. RAG는 검색 코퍼스(retrieval corpus) 자체가 실시간(live)인 경우에만 지식 동결 문제(Knowledge Freeze Problem)를 중화할 수 있습니다. 하지만 대부분의 기업용 RAG 파이프라인 (RAG pipelines)은 그렇지 않습니다. Pinecone과 같은 벡터 데이터베이스(Vector databases)는 독점적인 내부 지식을 검색하는 데 매우 탁월합니다. 하지만 이들은 당신이 주입(ingested)한 것을 검색할 뿐, 오늘 아침 세상에서 변한 내용을 검색하지는 않습니다. Lewis et al.의 원본 RAG 논문은 시간적 신선함(temporal freshness)을 주장한 적이 없습니다. 그것은 검색 방법의 속성이 아니라, 당신의 데이터 주입 파이프라인(ingestion pipeline)의 속성입니다.

LangGraph 및 AutoGen과 같은 프레임워크는 개발자가 외부 검색 도구를 수동으로 연결(wire)해야 합니다. 이는 지연 시간(latency), API 비용 복잡성, 그리고 대부분의 팀이 운영 환경의 장애(production incident)가 발생하여 감사를 수행하기 전까지는 과소평가하는 새로운 장애 발생 지점(failure surface)을 추가합니다. 2024년, LLM 기반 계약 분석 에이전트를 사용하는 기업 법무팀은 규제 참조 정보가 8개월에서 14개월 정도 뒤처져 있다는 사실을 발견했으며, 이는 전체 파이프라인 감사가 필요한 컴플라이언스 검토 실패를 초래했습니다. 에이전트들은 단위 테스트(unit test)로 잡아낼 수 있는 방식으로 고장 난 것이 아니었습니다. 구조적으로 동결(structurally frozen)되어 있었던 것입니다.

8–14개월
기업용 법무 에이전트에서 발견된 규제 참조 정보의 노후화
[AWS Machine Learning Blog, 2026](https://aws.amazon.com/blogs/machine-learning/introducing-web-search-on-amazon-bedrock-agentcore/)
...

대부분의 사람들이 오해하는 점은 환각(hallucination)이 모델 품질의 문제라고 생각하는 것입니다. 이는 점점 더 인프라(infrastructure)의 문제가 되고 있습니다. 지식 경계(knowledge boundary)가 노후화된 GPT급 모델은 가중치(weights)가 아무리 훌륭하더라도 2026년 가격 문의에 대해 자신 있게 환각을 일으킬 것입니다. 왜냐하면 정답이 가중치 안에 애초에 없었기 때문입니다.

Web Search Amazon Bedrock AgentCore가 실제로 하는 일 — 마케팅 미사여구를 제외하고

발표 내용 해독: AWS가 실제로 출시한 것

AWS는 웹 검색을 AgentCore 내부의 일급 관리형 기능(first-class managed capability)으로 통합했습니다. 실질적인 의미는 다음과 같습니다: 개발자는 더 이상 제3자 검색 API를 프로비저닝(provision), 인증(authenticate), 속도 제한(rate-limit)하거나 오류 처리(error-handle)할 필요가 없습니다. 근거 계층(grounding layer)은 플랫폼이 소유합니다. 에이전트가 최신 정보가 필요할 때, 검색(retrieval), 순위 지정(ranking), 컨텍스트 주입(context injection)은 관리형 오케스트레이션 런타임(managed orchestration runtime) 내부에서 수행됩니다. 즉, 귀하의 애플리케이션 코드 내부에서 일어나는 일이 아니며, 새벽 2시에 디버깅해야 할 귀하의 문제도 아닙니다. 전체 기능은 Bedrock AgentCore 개발자 문서에 기록되어 있습니다.

네이티브 웹 검색(Native Web Search)이 직접 검색 API를 도구 호출(Tool-Calling)하는 방식과 다른 점

이것이 가장 중요하면서도, 제가 읽어본 모든 보도 자료에서 간과되고 있는 차이점입니다. LangChain의 Tavily 통합이나 CrewAI의 SerperDev 도구(tooling)를 연결할 때, 검색은 도구 호출(tool-call) 계층에서 이루어집니다. 즉, 모델이 도구를 호출하기로 결정하면, 사용자의 코드가 이를 실행하고, 결과를 파싱한 뒤, 포맷팅된 컨텍스트(context)를 다시 프롬프트에 주입합니다. 이러한 모든 핸드오프(handoff) 과정은 각각 실패 가능성(failure surface)을 내포하고 있습니다. 잘못된 결과 형식, 컨텍스트 오버플로(context overflow), 포맷팅 드리프트(formatting drift), 조용한 잘림(silent truncation) 등이 발생할 수 있습니다. 저는 팀들이 한 스프린트(sprint) 내내 버그를 잡으려 애쓰다가, 알고 보니 Tavily가 부하 상황에서 약간 다른 JSON 형태를 반환했기 때문이라는 것을 발견한 사례를 여러 번 보았습니다.

Bedrock AgentCore의 웹 검색은 도구 호출 계층에 덧붙여진 것이 아니라, 오케스트레이션 계층(orchestration layer)에 내장되어 있습니다. 플랫폼이 결과 포맷팅과 컨텍스트 윈도우 관리(context-window management) 계약을 직접 소유하기 때문에, 컨텍스트 주입 실패(context-injection failures)라는 범주 전체를 제거할 수 있습니다.

네이티브 AgentCore 웹 그라운딩(Web Grounding) vs 수동 도구 래퍼(Manual Tool Wrapper)의 쿼리 흐름 방식

  1

    **사용자 쿼리가 AgentCore 런타임(runtime)에 도달**

입력이 도착합니다. 오케스트레이션 계층은 모델 호출(model invocation) 전에 쿼리가 시간 민감성(pricing, news, regulatory, personnel)을 갖는지 평가합니다.

↓

  2
...

AgentCore는 검색, 랭킹(ranking), 중복 제거(dedup)를 내부적으로 수행합니다. 앱 측의 API 키, 재시도 로직(retry logic), 또는 속도 제한(rate-limit) 처리가 필요 없습니다. 지연 시간 예산(latency budget)은 런타임에 의해 관리됩니다.

↓

  3
...

결과는 플랫폼이 관리하는 토큰 예산(token budgeting) 하에 포맷팅되어 모델의 컨텍스트에 주입됩니다. 이는 Bedrock을 통해 Claude 3.5, Amazon Nova, Llama 전반에 걸쳐 작동합니다.

↓

  4
...

모델은 실시간 데이터를 사용하여 답변합니다. AgentCore는 다운스트림(downstream)에서 출처 속성(source attribution)을 드러내며, 이는 지식 동결 문제(Knowledge Freeze Problem)에서 결여되었던 불확실성 신호(uncertainty signal)를 제공합니다.

이 순서가 중요한 이유는 그라운딩 (grounding)이 애플리케이션에서 관리하는, 조용히 실패할 수 있는 도구 호출 (tool call) 방식이 아니라, 인프라 계층 (infrastructure layer)에서 모델 호출 (model invocation) 전후로 발생하기 때문입니다.

경쟁사들이 아직 실행하지 못한 인프라 계층의 전환

AWS는 자체 벤치마크를 인용하며, 네이티브 웹 그라운딩 (native web grounding)을 사용하는 에이전트가 실시간 검색 기능이 없는 동일한 모델보다 최신 이벤트에 민감한 응답을 훨씬 더 높은 사실적 정확도로 반환한다는 것을 보여주었습니다. 특히 가격 정보, 인사 변동, 규제 업데이트 분야에서 그러했습니다. 더 깊은 신호는 Anthropic의 개발자 문서에도 기록된 MCP (Model Context Protocol) 호환성입니다. AgentCore의 아키텍처는 웹 검색을 표준화된 컨텍스트 소스 (context source)로 드러내도록 설계되었으며, 이는 AWS가 Anthropic이 구축하는 데 기여한 MCP 채택 곡선보다 앞서 나가도록 위치시킵니다. 이는 사소한 구현 세부 사항이 아닙니다. 이는 컨텍스트 소싱 (context sourcing)이 표준화될 지점에 대한 플랫폼 차원의 베팅입니다.

도구 호출 (tool-call) 계층에서의 그라운딩은 기능 (feature)입니다. 오케스트레이션 (orchestration) 계층에서의 그라운딩은 플랫폼 (platform)입니다. AWS는 방금 그 차이를 프로덕션 에이전트의 새로운 기준점으로 만들었습니다.

LangChain 및 CrewAI의 도구 호출 계층 검색과 대조되는, Bedrock AgentCore 내부의 오케스트레이션 계층에 배치된 웹 그라운딩. 출처

AgentCore의 웹 검색이 해결하도록 설계된 실제 실패 모드 (Failure Modes)

실패 모드 1: 오래된 데이터의 확신 함정 (The Stale-Data Confidence Trap)

정적 데이터셋 (Static datasets)에서 높은 벤치마크 점수를 기록한 에이전트들은, 학습 중단 시점 (Training cutoff) 이후에 변경된 주제에 대한 실시간 질의 (Live queries)에서 빈번하게 실패합니다. 이때 하위 시스템 (Downstream systems)이나 최종 사용자에게 불확실성 신호 (Uncertainty signal)를 전혀 보내지 못한다는 점이 문제입니다. 이것이 바로 지식 동결 문제 (Knowledge Freeze Problem)의 운영적 발현입니다. 에이전트는 내부적으로 스스로 불확실하다고 느끼지 않기 때문에 불확실성을 표시하지 않습니다. 단지 변화해버린 세상에 대해 틀린 정보를 가지고 있을 뿐입니다. 여기에는 우아한 성능 저하 (Graceful degradation)가 없습니다. 대규모로, 확신에 차서, 조용히 실패할 뿐입니다.

실패 모드 2: 커스텀 검색 래퍼 비용 (The Custom Search Wrapper Tax)

규모가 큰 엔지니어링 팀들은 에이전트 구축 시간의 15~30%를 검색 통합을 위한 배관 작업 (Plumbing) — 인증 (Authentication), 재시도 로직 (Retry logic), 결과 파싱 (Result parsing), 컨텍스트 포맷팅 (Context formatting) — 에 소비한다고 보고합니다. 이 중 어느 것도 차별화된 작업이 아닙니다. AWS 상에서 경쟁 정보 (Competitive intelligence) 에이전트를 구축 중인 한 금융 서비스 기업은, 수동으로 연결된 Bing Search API 통합에서 관리형 그라운딩 레이어 (Managed grounding layer)로 전환했을 때 초기 내부 테스트 결과 에이전트 인프라 유지보수 오버헤드가 약 40% 감소했다고 보고했습니다. 팀 인력을 구성할 때 이는 결코 작은 수치가 아닙니다.

월간 에이전트 질의가 100만 건일 때, 커스텀 검색 통합에 들어가는 총비용(Fully-loaded cost) — 엔지니어링 유지보수, 모니터링, 장애 대응 (Incident response) — 은 일반적으로 순수 API 비용의 2~3배에 달합니다. 비용을 발생시키는 것은 검색 자체가 아니라 바로 이 배관 작업 (Plumbing)입니다.

실패 모드 3: 멀티 에이전트 파이프라인에서의 환각-그라운딩 불일치 (The Hallucination-Grounding Mismatch in Multi-Agent Pipelines)