Amazon Bedrock AgentCore Web Search: 프로덕션 에이전트를 망가뜨리는 7가지 배포 실수

Originally published at twarx.com - 전체 인터랙티브 버전은 그곳에서 읽어보세요.

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

당신의 AI 에이전트는 환각 (Hallucination)을 일으키는 것이 아닙니다. 작년의 현실을 자신 있게 읊고 있을 뿐이며, 당신의 RAG (Retrieval-Augmented Generation) 파이프라인이 상황을 더 악화시키고 있습니다. Amazon Bedrock AgentCore Web Search는 단순히 그 문제를 패치하는 것에 그치지 않습니다. 이는 대부분의 AWS 팀이 2025년에 조용히 대가를 치르게 될 아키텍처 설계 실수를 드러냅니다. Amazon Bedrock AgentCore Web Search가 인프라 계층에서 실제로 어떻게 작동하는지 이해하는 것은, 6개월 차에도 정확도를 유지하는 에이전트와 조용히 확신에 찬 오답으로 표류하는 에이전트 사이의 차이를 결정짓습니다.

AWS는 방금 Web Search on Amazon Bedrock AgentCore를 출시했습니다. 이는 LangGraph, AutoGen, CrewAI를 기반으로 구축된 에이전트 시스템을 위한 완전 관리형, VPC 호환 실시간 웹 검색 (Web Retrieval) 계층입니다. 이것이 지금 중요한 이유는 프로덕션 환경의 모든 LLM (Large Language Model)이 오래된 학습 데이터로 작동하고 있으며, 규제 산업에서는 쿼리를 제3자 검색 API로 보낼 수 없기 때문입니다.

이 가이드를 마칠 때쯤이면, 에이전트의 성능을 조용히 저하시키는 7가지 배포 실수와 이 모든 실수를 피할 수 있는 정확한 프로덕션 아키텍처를 알게 될 것입니다.

Amazon Bedrock AgentCore Web Search는 인프라 계층에 위치하여 웹 검색 (Web Retrieval)을 AWS 신뢰 경계 (Trust Boundary) 내에 유지합니다. 이는 이 카테고리 전체를 정의하는 아키텍처적 차별점입니다. Source

Amazon Bedrock AgentCore Web Search란 무엇이며 왜 지금 중요한가

Amazon Bedrock AgentCore Web Search는 에이전트가 런타임(runtime) 중에 실시간 웹 컨텍스트를 가져올 수 있게 해주는 관리형 검색(retrieval) 도구입니다. 이 과정에서 데이터는 AWS 인프라를 절대 벗어나지 않습니다. 이전에 Bedrock을 기반으로 구축해 본 적이 있다면, 이것이 2023년의 패턴인 Bedrock Agent에 제3자 검색 API를 덧붙이는 방식과는 아키텍처적으로 다르다는 점을 알 수 있을 것입니다. 이것은 모델 계층의 도구 호출(tool call)이 아니라 인프라 계층의 검색(retrieval)입니다. 규제 환경(regulated environment)에 있는 경우, 이 차이는 대부분의 사람들이 인식하는 것보다 훨씬 더 중요합니다. 이것이 더 넓은 스택에 어떻게 부합하는지에 대한 입문서가 필요하다면, 에이전트형 AI 기초에 관한 설명을 참조하세요.

지식 만료의 함정: 정적 RAG가 시한폭탄인 이유

여기 불편한 진실이 있습니다. GPT-4o나 Claude 3.5 Sonnet과 같은 최첨단 모델(frontier models)조차 학습 데이터 차단 시점(training cutoffs)이 있어, 프로덕션(production)에 배치될 때쯤이면 이미 6~18개월 전의 정보로 노후화되어 있다는 점입니다. 이 격차는 매일 커집니다. 벡터 데이터베이스(vector database)도 도움이 되지 않습니다. 데이터베이스는 사용자가 입력한 것만 알 뿐이기 때문입니다. 원래의 RAG 논문 연구에서는 검색(retrieval)을 신선도(freshness)를 해결하는 방안으로 정의했지만, 대부분의 팀은 그중 '최신성(currency)' 측면을 운영 단계로 구현하지 못했습니다.

조어된 프레임워크(Coined Framework)

지식 만료의 함정(The Knowledge Expiry Trap) — AI 에이전트의 검색 아키텍처가 기술적으로는 작동하지만 인식론적으로는 노후화되어, 그 어떤 환각(hallucination)보다 빠르게 사용자 신뢰를 무너뜨리는 자신만만한 오답을 생성하게 되는 조용한 배포 실패 모드

이 용어는 '정확하게 검색하는(retrieves correctly)' 시스템과 '현재의 정보를 검색하는(retrieves currently)' 시스템 사이의 격차를 지칭합니다. 이 함정은 데모에서는 보이지 않습니다. 데모 데이터는 신선하기 때문입니다. 하지만 세상은 변했는데 에이전트는 변하지 않은 채 맞이하게 될 6개월 차에는 치명적입니다.

AgentCore Web Search가 기존의 Bedrock Agent 웹 통합 방식과 다른 점

기존의 패턴 — Bedrock Agents가 Serper 또는 Bing API를 호출하는 방식 — 은 데이터 유출 (data egress) 문제를 야기했습니다. 쿼리 텍스트와 검색된 결과가 AWS 경계를 넘어 벤더의 로그로 넘어갔기 때문입니다. 금융 서비스, 의료, 정부 기관에게 이는 결코 수용할 수 없는 문제였습니다. 즉각적인 거부 사유였습니다. AgentCore Web Search는 검색 (retrieval) 과정을 관리형 AWS 플레인 (managed AWS plane) 내부에서 실행하며, 엔드 투 엔드 (end-to-end)로 VPC 호환이 가능합니다. 이는 Anthropic의 tool_use API나 OpenAI의 tool layer와 같은 모델 기능이 아니라, 인프라 (plumbing)의 영역입니다.

현재 엔터프라이즈 AI에서 가장 비용이 많이 드는 단 한 가지 실수는 나쁜 모델을 사용하는 것이 아닙니다. 그것은 아주 훌륭한 모델이 작년의 사실을 바탕으로 자신 있게 답변하고, 고객이 알아차릴 때까지 아무도 이를 인지하지 못하는 것입니다.

AWS 내부에 유지되는 것과 그것이 엔터프라이즈 컴플라이언스 (Compliance)에 의미하는 바

Bedrock에서 LangGraph로 오케스트레이션 (orchestrated)된 에이전트를 실행하는 금융 서비스 기업들은 규제 관련 FAQ 흐름에 실시간 웹 컨텍스트 (live web context)를 추가한 후, 에이전트 에스컬레이션 (agent escalations)이 최대 34% 감소했다고 보고했습니다 (AWS re:Invent 2024 파트너 쇼케이스). 진정한 핵심은 컴플라이언스 (compliance)의 해제입니다. 즉, 검색 (retrieval)이 귀하의 신뢰 경계 (trust boundary) 내부에 머문다는 점입니다. NIST AI Risk Management Framework는 규제 산업에서 이러한 요구 사항을 점점 더 강력하게 추진하고 있으며, EU AI Act는 데이터 처리 투명성에 대해 기준을 더욱 높이고 있습니다.

6–18개월
프로덕션 배포 시 프런티어 LLM (frontier LLM) 학습 데이터의 전형적인 노후화 정도
[Anthropic Model Docs, 2025](https://docs.anthropic.com/)
...

실수 1 — 웹 검색을 RAG의 즉각적인 대체제로 취급하는 것

팀들이 AgentCore Web Search를 활성화할 때 가장 먼저 하는 행동은 최악의 선택입니다. 바로 기존의 벡터 스토어 (vector store)를 뽑아버리는 것입니다. 저는 이런 일이 발생하는 것을 한두 번 본 것이 아닙니다. 웹 검색과 벡터 검색 (vector retrieval)은 근본적으로 다른 문제를 해결하며, 이 둘을 혼동하는 것이 귀하의 독자적인 지식에 대한 환각 (hallucinations)을 급증시키는 원인이 됩니다.

벡터 데이터베이스와 웹 검색이 서로 다른 문제를 해결하는 이유

웹 검색은 공개되지 않은 정보를 검색할 수 없습니다. 귀사의 제품 사양, 내부 정책, 고객 기록은 Pinecone, Weaviate, 또는 Amazon OpenSearch Service에 저장되어 있습니다. 모든 것을 웹 검색으로 전환한 팀들은 내부 지식 쿼리에 대해 환각 (hallucination) 발생률이 2~3배 증가했다고 보고했습니다. 에이전트가 비공개 사실에 대해 공개 웹상의 근사치를 임의로 만들어내기 시작했기 때문입니다. 이는 미세한 성능 저하가 아닙니다. 에이전트가 공개 인터넷에서 찾은 무엇이든을 바탕으로 자신 있게 거짓 정보를 지어내는 현상입니다.

Bedrock에서 CrewAI를 실행하는 한 물류 SaaS 팀은 2025년 1분기에 RAG(검색 증강 생성)에서 웹 검색으로의 완전한 전환을 시도했습니다. 하지만 고객 지원 에이전트들이 경쟁사의 보도 자료를 내부 정책으로 인용하기 시작하면서 3주 만에 이전 상태로 되돌아갔습니다. 웹 검색은 귀사의 정책이 무엇인지 전혀 알지 못합니다.

실제 프로덕션에서 작동하는 하이브리드 검색 아키텍처 (Hybrid Retrieval Architecture)

올바른 패턴은 **검색 라우터 (retrieval router)**를 사용하는 것입니다. 조직 내부 지식에는 내부 벡터 데이터베이스 (vector DB)를 사용하고, 시간적(temporal), 시장 및 규제 맥락에는 AgentCore Web Search를 사용합니다. Pinecone, Weaviate, OpenSearch는 AgentCore의 경쟁자가 아니라 상호 보완적인 레이어입니다. 만약 이 스택을 구축하고 있다면, RAG 및 벡터 데이터베이스에 대한 심층 분석에서 조직 내부 지식 레이어를 자세히 다루고 있습니다.

하이브리드 검색 라우터: 벡터 DB + AgentCore Web Search

  1

    **쿼리 의도 분류기 (Query Intent Classifier - Claude Haiku)**

경량 모델이 쿼리를 정적 지식 (static-knowledge) 대 시간 민감형 (time-sensitive)으로 태깅합니다. 쿼리당 약 $0.0003, 120ms 미만 소요.

↓

  2
...

freshness_required 플래그에 따라 내부 RAG, 웹 검색, 또는 둘 다를 사용할지 라우팅합니다.

↓

  3
...

벡터 DB에서 조직적 사실을 가져오고, VPC 내부의 웹 검색에서 시간적 사실을 가져옵니다.

↓

  4
...

모델이 답변을 구성하기 전에 도메인 허용 목록 (allowlist) 확인 및 인용 (citation) 추출을 수행합니다.

이 순서가 중요합니다: 검색하기 전에 분류하고, 비용을 쓰기 전에 라우팅하며, 답변하기 전에 검증하십시오.

검색 라우터 (retrieval router) 패턴은 AgentCore 배포에서 가장 영향력이 큰 단일 결정 사항입니다. 이는 정확도와 비용 모두를 결정합니다.

실수 2 — 오케스트레이션 (Orchestration) 로직에서 지식 만료 함정 (Knowledge Expiry Trap)을 무시하는 것

대부분의 팀은 검색 소스 선택을 정적 설정 (static configuration)으로 취급합니다. 이는 런타임 (runtime) 결정이어야 합니다. 프로덕션 에이전트 시스템 중 소스를 선택하기 전에 데이터 신선도 점수 (data-freshness scoring)를 구현하는 비율은 12% 미만입니다. 즉, 88%가 지식 만료 함정 (Knowledge Expiry Trap)으로 곧장 걸어 들어가고 있다는 의미입니다. Weights & Biases 설문 조사에서 나온 이 수치는 저를 놀라게 하지 않았습니다. 이는 제가 실제 배포 환경에서 계속 목격해 온 사실을 확인시켜 주었습니다.

LangGraph와 AutoGen이 시간적 맥락 (Temporal Context)을 처리하는 방식 (그리고 한계점)

LangGraph의 조건부 엣지 라우팅 (conditional edge routing)은 freshness_required 불리언 (boolean) 값을 사용하여 확장할 수 있습니다. 이를 통해 시간 민감도가 높은 의도 (intent)에 대해서만 AgentCore Web Search를 트리거함으로써, 불필요한 웹 호출을 최대 60%까지 줄이고 지연 시간 (latency)을 유의미하게 단축할 수 있습니다. LangGraph의 상태 저장 오케스트레이션 (stateful orchestration)을 사용하면 이를 깔끔하게 구현할 수 있습니다. 반면, AutoGen의 GroupChat 패턴은 검색 소스 선택기 (retrieval-source selector)를 기본적으로 노출하지 않습니다. 따라서 tool_choice 오버라이드 (override)가 적용된 커스텀 AssistantAgent가 필요합니다. AutoGen 문서는 이 부분에 대해 충분히 명확하게 경고하지 않습니다. 저는 해당 오버라이드가 명시적으로 설정되지 않은 AutoGen 배포 버전은 출시하지 않을 것입니다.

Python — LangGraph 신선도 라우팅 (freshness routing)

# 의도가 시간 민감적일 때만 AgentCore Web Search로 라우팅

def route_retrieval(state):
    intent = classify_intent(state['query']) # Claude Haiku, ~120ms
    if intent.freshness_required: # 규제, 시장, 뉴스
        return 'agentcore_web_search'
    return 'opensearch_vector' # 제품, 정책, 고객

graph.add_conditional_edges(
'classify',
route_retrieval,
{'agentcore_web_search': 'web_node', 'opensearch_vector': 'rag_node'}
)

에이전트 결정 트리(Decision Tree)에 신선도 신호(Freshness Signal) 구축하기

AutoGen + Bedrock 기반으로 구축된 한 이커머스 추천 에이전트는 항상 켜져 있는 웹 검색(always-on web search) 방식에서 쿼리 유형 기반 라우팅(query-type-based routing) 방식으로 전환한 후 지연 시간(latency)이 22% 감소하는 것을 확인했습니다. 미리 구축된 라우팅 패턴을 원하시나요? 오케스트레이션(orchestration) 템플릿을 위해 저희의 AI 에이전트 라이브러리를 탐색해 보세요.

Coined Framework

오케스트레이션(orchestration) 로직에서의 지식 만료 함정 (The Knowledge Expiry Trap)

소스 선택이 의도 기반(intent-driven)이 아닌 하드코딩(hardcoded)되어 있을 때, 에이전트는 최신 정보가 필요한 질문에는 오래된 저장소(stale stores)에서 답하고, 변동성이 큰 웹의 정보가 필요한 질문에는 정적인 저장소에서 답하게 됩니다. 이는 정보의 노후화와 비용을 모두 극대화합니다. 해결책은 라우팅 계층(routing layer)에 신선도 신호(freshness signal)를 도입하는 것입니다.

실수 3 — '관리형(Managed)'이라는 이유로 보안 아키텍처를 건너뛰는 것

'완전 관리형(Fully managed)'은 클라우드 AI에서 가장 위험한 문구입니다. 이는 보안이 알아서 처리될 것이라는 가정을 만듭니다. 그리고 바로 그 가정 때문에 팀들은 에이전트가 대규모로 제한 없는 웹 검색(web retrievals)을 트리거할 수 있게 허용하는, 지나치게 광범위한 IAM 실행 역할(execution roles)을 배포하게 됩니다. 저는 스프린트 계획(sprint planning) 과정에서 이러한 논리가 정당화되는 것을 보았습니다. 결과는 결코 좋지 않습니다.

'데이터가 AWS를 절대 떠나지 않는다'는 말이 실제로는 무엇을 의미하는가

이는 네트워크 경로가 격리되어 있음을 의미합니다. 귀하의 액세스 제어(access controls)가 올바르게 설정되어 있다는 뜻이 아닙니다. Model Context Protocol (MCP)는 오케스트레이션 프레임워크(orchestration frameworks)와 검색 도구(retrieval tools) 사이의 표준 인터페이스가 되어가고 있습니다. 잘못 설정된 MCP 서버 구성은 에이전트 배포 시 의도치 않은 데이터 노출 범위(data surface expansion) 확장의 주요 원인이 됩니다. 이 두 가지는 별개의 문제입니다. AgentCore는 첫 번째 문제를 해결합니다. 두 번째 문제는 귀하의 책임입니다. LLM 애플리케이션을 위한 OWASP Top 10은 반드시 읽어보아야 할 필독서입니다.

VPC 구성, IAM 범위 지정(Scoping), 그리고 MCP 게이트웨이 패턴