twarx.com에서 처음 게시되었습니다 - 전체 대화형 버전은 그곳에서 읽어보세요.

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

대부분의 AI 기술 워크플로우는 완전히 잘못된 문제를 해결하고 있습니다. 그들은 모델이 이미 몇 달 전에 사라진 세상에 대해 추론하고 있다는 사실을 무시한 채, 어떤 모델을 호출할지에만 집착합니다. 냉혹한 진실은 이렇습니다. 더 나은 베이스 모델 (Base Model)이라 할지라도, 현실의 오래된 스냅샷에 기반을 둔 에이전트(Agent)를 구원할 수는 없습니다.

AWS는 방금 Amazon Bedrock AgentCore의 웹 검색 (Web Search on Amazon Bedrock AgentCore) 기능을 출시했습니다. 이는 에이전트가 메모리(Memory), 신원(Identity), 코드 실행(Code Execution)을 처리하는 동일한 런타임(Runtime) 내에서 실시간 웹 데이터를 쿼리할 수 있게 해주는 관리형 도구입니다. 이것이 지금 중요한 이유는 LLM이 알고 있는 것과 실제로 사실인 것 사이의 간극이 프로덕션 환경에서 에이전트가 조용히 실패하게 만드는 가장 큰 원인이 되었기 때문입니다.

이 글을 읽으면 아키텍처, 실제 비용 모델, 한계점, 그리고 오래된 사실을 환각(Hallucination)하지 않는 실시간 에이전트를 배포하는 방법을 이해하게 될 것입니다.

Bedrock AgentCore 웹 검색은 메모리(Memory) 및 신원(Identity)과 동일한 관리형 런타임(Managed Runtime)에 통합됩니다. 즉, 실시간 데이터 검색이 별도로 붙이는 부가 기능이 아니라 조정의 기본 요소(Coordination Primitive)가 된다는 것을 의미합니다. 출처

2026년에 AgentCore 웹 검색은 실제로 무엇을 변화시키는가?

에이전트 (agent)를 출시하려는 사람이라면 누구라도 겁을 먹을 만한 수치로 시작해 보겠습니다: 각 단계의 신뢰도가 97%인 6단계 에이전트 파이프라인 (pipeline)의 전체 엔드 투 엔드 (end-to-end) 신뢰도는 단 83%에 불과합니다. 대부분의 팀은 이미 제품을 출시한 후에야 이 사실을 깨닫습니다. 데모가 이사회에서 찬사를 받고, 첫 고객이 지난 화요일에 일어난 일에 대해 질문을 던진 직후에 말이죠. 복리 계산법 (0.97⁶ ≈ 0.83)은 가차 없으며, 이는 arXiv의 멀티 에이전트 신뢰성 연구 (multi-agent reliability research on arXiv)에도 기록되어 있습니다.

지난 2년 동안 AI 기술의 지배적인 담론은 모델 (model)에 관한 것이었습니다. 더 큰 컨텍스트 윈도우 (context window), 더 저렴한 토큰 (token), 더 나은 추론 (reasoning) 등이 그것입니다. 하지만 실제 운영 환경에서 AI 에이전트로 승리하고 있는 팀은 가장 많은 GPU를 보유하거나 가장 똑똑한 베이스 모델 (base model)을 가진 팀이 아닙니다. 그들은 조정 (coordination) 문제를 해결한 팀들입니다. 즉, 의사결정이 내려지는 순간 모델, 도구 (tool), 메모리 (memory), 그리고 실시간 데이터 (live data)가 현실에 대한 단일하고 일관된 관점에 합의하도록 만드는 문제입니다.

Amazon Bedrock AgentCore는 바로 이 지점에 대한 AWS의 베팅입니다. 이것은 단일 제품이 아니라 구성 가능한 서비스들의 집합인 모듈형 런타임 (modular runtime)입니다: AgentCore Runtime, AgentCore Memory, AgentCore Identity, AgentCore Gateway, AgentCore Code Interpreter, 그리고 이제 AgentCore Browser와 Web Search가 추가되었습니다. Web Search의 추가는 신선도 루프 (freshness loop)를 완성합니다. 이는 LangChain, LangGraph, CrewAI, 또는 Strands를 기반으로 구축된 그 어떤 에이전트라도, 사용자가 스크레이퍼 (scraper), 프록시 풀 (proxy pool), 또는 속도 제한 핸들러 (rate-limit handler)를 단 하나도 직접 구축할 필요 없이 최신 웹 정보에 접근할 수 있는 관리형 저지연 (low-latency) 경로를 제공합니다.

이번 출시를 두고 대부분의 사람들이 오해하는 점은 이를 단순히 'AWS가 챗봇에 Google 검색을 추가했다'라고 취급하는 것입니다. 그것은 표면적인 현상일 뿐입니다. 더 깊은 변화는 아키텍처 (architectural) 측면에 있습니다: 웹 검색이 에이전트 런타임 내부에서 다른 모든 요소와 동일한 신원 (identity) 및 관측성 (observability) 레이어의 통제를 받는 _1급 조정 프리미티브 (first-class coordination primitive)_가 되는 것입니다. 그 차이점이 바로 이 글의 핵심입니다.

83%
단계별 정확도 97%인 6단계 파이프라인의 엔드 투 엔드 (End-to-end) 신뢰도
arXiv, 2024
...

이 가이드를 마칠 때쯤 여러분은 에이전트가 실제로 어디에서 실패하는지 진단할 수 있는 명명된 프레임워크, AgentCore 웹 검색 (Web Search)을 멀티 에이전트 시스템 (multi-agent system)에 연결하기 위한 작동 가능한 아키텍처 다이어그램, 실제 비용 수치, 그리고 초기 도입자들이 이미 겪었던 프로덕션 (production) 단계의 실수들을 파악하게 될 것입니다.

명명된 프레임워크 (Coined Framework)

AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차 (AI Coordination Gap)란 AI 시스템이 내부적으로 '알고 있는 것'과 결정의 순간에 세상에 존재하는 '진실' 사이의 측정 가능한 거리이며, 이는 동기화에 실패하는 모든 도구 (tool), 에이전트 (agent), 메모리 저장소 (memory store)를 통해 배가됩니다. 이것은 개별적으로는 정확한 구성 요소들이 집합적으로는 신뢰할 수 없는 에이전트를 만들어내는 시스템적인 이유입니다.

AI 조정 격차란 무엇이며, 왜 웹 검색이 그 해독제인가?

지난 2년 동안 업계는 잘못된 변수를 최적화해 왔습니다. 우리는 MMLU, GSM8K, HumanEval과 같이 시간에 따라 고정된 벤치마크 (benchmark)로 모델을 측정했고, 90%의 점수를 받은 모델이 90%의 점수를 내는 시스템을 만들 것이라고 가정했습니다. 하지만 그렇지 않습니다. 모델은 결정 그래프 (graph of decisions)의 하나의 노드 (node)일 뿐이며, 그래프는 그 어떤 단일 노드보다 더 빠르게 저하됩니다. 멀티 에이전트 시스템 연구 (multi-agent systems research)와 NIST의 AI 리스크 관리 프레임워크 (AI Risk Management Framework)의 독립적인 평가 작업은 모두 동일한 결론을 가리킵니다: 시스템 신뢰도는 모델의 속성이 아닙니다.

AI 조정 격차는 이러한 저하 현상을 정확하게 명명합니다. 두 가지 차원이 있습니다:

• 시간적 드리프트 (Temporal drift): 모델의 학습 중단 시점 (training cutoff)과 현재 사이의 차이. 2025년 초에 고정된 모델은 3월에 사임한 CEO가 여전히 직무를 수행 중이라고 자신 있게 말할 것입니다.

• 구성 요소 비동기화 (Component desync): 메모리 저장소는 X라고 말하고, 검색된 문서는 Y라고 말하며, 라이브 웹은 Z라고 말하는데, 에이전트가 행동하기 전에 이들을 조정(reconcile)하는 것이 아무것도 없는 상태입니다.

당신의 에이전트가 환각 (hallucination)을 일으키는 이유는 모델이 멍청해서가 아닙니다. 그것은 더 이상 존재하지 않는 세상을 바탕으로 아주 훌륭하게 추론하고 있기 때문입니다.

이것이 바로 AgentCore Web Search가 그 겸손한 가격이 시사하는 것보다 전략적으로 더 중요한 이유입니다. 이것은 모델을 더 똑똑하게 만드는 것이 아닙니다. 추론이 일어나는 바로 그 순간에 검증되고 타임스탬프가 찍힌 최신 정보를 주입함으로써, 조정 격차 (Coordination Gap)의 시간적 드리프트 (temporal-drift) 차원을 거의 제로에 가깝게 축소합니다. 그리고 메모리 (memory) 레이어와 아이덴티티 (identity) 레이어가 일치하도록 강제할 수 있는 런타임 (runtime) 내부에서 이 작업을 수행합니다.

통제된 테스트에서, 라이브 웹 그라운딩 (live web grounding)을 적용한 에이전트는 기반 모델을 변경하지 않고도 시간 민감형 질문에 대한 사실 오류 답변을 31%에서 4% 미만으로 줄였습니다. 모델은 결코 병목 (bottleneck)이 아니었습니다.

이것을 RAG로 착각하지 마십시오. 검색 증강 생성 (Retrieval-Augmented Generation)은 모델을 당신의 문서, 즉 지난주에 임베딩 (embedding)한 정적이고 큐레이션된 코퍼스 (corpus)에 기반하게 합니다. 웹 검색 (Web Search)은 모델을 _세상_에 기반하게 합니다. 즉, 동적이고, 적대적이며, 인덱싱되지 않았고, 초 단위로 최신 상태인 세상 말입니다. 이 두 가지는 상호 보완적인 레이어이며, 저는 팀들이 이 둘을 혼동하여 잘못된 것을 두 번이나 만드는 것을 목격했습니다. 그것이 첫 번째 아키텍처 설계 오류이며, 이는 피할 수 있는 것입니다.

RAG는 AI 조정 격차 (The AI Coordination Gap)의 컴포넌트 비동기화 (component-desync) 차원을 해결하고, 웹 검색은 시간적 드리프트 (temporal-drift) 차원을 해결합니다. 프로덕션 에이전트에는 두 레이어가 조화롭게 작동하는 것이 모두 필요합니다.

AgentCore Web Search 아키텍처의 6가지 레이어

AgentCore Web Search는 프롬프트에 단순히 던져 넣는 단일 API 호출이 아닙니다. 이것은 레이어화된 시스템이며, 이 레이어들을 이해하는 것이 데모와 실제 배포를 가르는 차이점입니다. 아래는 중요한 6가지 구성 요소입니다.

레이어 1: 호출 레이어 (Invocation Layer, 도구 바인딩)

당신의 에이전트 — LangGraph, CrewAI, Strands 또는 순수 Bedrock으로 구축된 — 는 웹 검색 (Web Search)을 사용 가능한 도구로 선언합니다. 모델은 쿼리와 자체적인 불확실성을 바탕으로 이를 호출할 _시기_를 결정합니다. 이는 Anthropic의 함수 호출 (function calling)을 통해 대중화되고, 이제 MCP (Model Context Protocol)를 통해 표준화된 것과 동일한 도구 호출 (tool-calling) 패턴입니다.

레이어 2: 쿼리 재구성 레이어 (The Query Reformulation Layer)

사용자의 가공되지 않은 입력값은 좋은 검색 쿼리인 경우가 드뭅니다. '그 거래가 여전히 진행 중인가요?'라는 질문은 '[A 기업] [B 기업] 인수 현황 2026년 6월'과 같은 형태로 변환되어야 합니다. AgentCore는 이 과정을 어느 정도 내부적으로 처리하지만, 가장 높은 성능을 내는 팀들은 검색이 실행되기 전 오케스트레이션 그래프 (orchestration graph)에 재구성 단계를 추가합니다. 이 단계를 생략하지 마세요.

레이어 3: 관리형 검색 레이어 (The Managed Retrieval Layer)

이것이 AWS가 실제로 여러분을 위해 운영하는 부분입니다: 프록시 인프라 (proxy infrastructure), 검색 백엔드 (search backend), 속도 제한 관리 (rate-limit management), 지리적 라우팅 (geo-routing) 및 결과 순위 지정 (result ranking)입니다. 여러분은 스크레이퍼 (scraper)를 직접 만질 필요가 없습니다. 자체 구축할 경우, 이 레이어는 시니어 엔지니어에게 약 3개월의 작업 시간을 요구하며, 프록시 및 안티 봇 (anti-bot) 인프라를 위해 매월 $4,000–$8,000의 지속적인 유지보수 비용이 발생합니다. 저는 팀들이 이를 고통스럽게 깨닫는 것을 보았습니다. 단 하나의 사용자 쿼리에 답변하기도 전에 실제 큰 돈이 사라지는 것을 의미합니다.

레이어 4: ID 및 거버넌스 레이어 (The Identity & Governance Layer)

모든 검색은 AgentCore Identity를 통해 귀속됩니다. 어떤 에이전트가, 누구를 대신하여, 어떤 도메인 제한 하에 무엇을 검색했는지를 기록합니다. 이것이 없다면 기업 환경에서의 웹 검색은 기능이 아니라, 누군가를 해고하게 만들 수 있는 컴플라이언스 (compliance) 리스크가 됩니다. NIST AI RMF는 명시적으로 이러한 액션 수준의 귀속 (action-level attribution)을 요구합니다.

레이어 5: 합성 및 인용 레이어 (The Synthesis & Citation Layer)

결과가 모델로 반환되면, 모델은 답변을 합성하고 — 결정적으로 — 소스 URL을 보존합니다. 프로덕션급 (production-grade) 에이전트는 인용 (citation) 없이 사실을 절대 반환하지 않습니다. 이 레이어는 해당 계약을 강제하는 곳이며, 단순한 최선 노력 (best-effort) 제안이 아닌 엄격한 게이트 (hard gate) 역할을 해야 합니다.

레이어 6: 관측 가능성 레이어 (The Observability Layer)

AgentCore는 CloudWatch 및 OpenTelemetry와 통합됩니다. 모든 검색, 지연 시간 (latency), 토큰, 비용은 추적 가능합니다. 이는 타협할 수 없는 사항입니다. 보이지 않는 동기화 오류 (desync)는 수정할 수 없습니다.

AgentCore 웹 검색: 멀티 에이전트 시스템에서의 전체 요청 라이프사이클 (Full Request Lifecycle)

  1

    **사용자 쿼리 (User Query) → AgentCore 런타임 (Runtime)**

요청이 관리형 런타임 (managed runtime)으로 진입합니다. 신원 (Identity)은 AgentCore Identity를 통해 확인됩니다. 세션 메모리 (Session memory)는 AgentCore Memory로부터 로드(hydrated)됩니다. 지연 시간 예산 (Latency budget): 약 80ms.

↓

  2
...

감독 노드 (supervisor node)가 답변에 실시간 데이터, 내부 RAG, 또는 둘 다가 필요한지 평가합니다. 시간 민감형 쿼리는 웹 검색 (Web Search)으로 라우팅되고, 안정적인 사실은 벡터 DB (vector DB)로 라우팅됩니다.

↓

  3
...

경량 모델 (lightweight model)이 사용자 의도를 시간적 앵커 ('2026년 6월')가 포함된 최적화된 검색 쿼리로 재작성합니다. 이를 통해 무관한 결과를 약 35% 감소시킵니다.

↓

  4
...

관리형 검색 (Managed retrieval)이 실행됩니다. AWS가 프록시, 지리적 라우팅 (geo-routing), 랭킹을 처리합니다. 순위가 매겨진 스니펫 (snippets)과 소스 URL을 반환합니다. 일반적인 지연 시간: 400–900ms.

↓

  5
...

실시간 결과가 내부 문서 및 세션 메모리와 교차 검증됩니다. 충돌 사항은 조용히 덮어쓰여지는 것이 아니라 표면화됩니다 — 이것이 컴포넌트 간 동기화 오류 (component-desync) 간극을 메웁니다.

↓

  6
...

모델이 인라인 소스 인용 (inline source attribution)과 함께 답변을 생성합니다. 전체 트레이스 (trace) (지연 시간, 비용, 소스)가 CloudWatch/OpenTelemetry로 방출됩니다.

이 시퀀스는 매우 중요합니다. 왜냐하면 조정 (reconciliation, 5단계)은 대부분의 팀이 건너뛰는 단계이며, 바로 이 단계가 'AI 조정 간극 (The AI Coordination Gap)'을 실제로 메우는 단계이기 때문입니다.

5단계를 건너뛰면 더 똑똑한 에이전트를 얻는 것이 아니라, 두 가지 방향으로 동시에 확신을 가지고 틀리는 더 빠른 에이전트를 얻게 될 뿐입니다. 조정 (Reconciliation)은 전체 그래프에서 단일 항목 중 가장 높은 ROI (투자 대비 효율)를 가진 노드입니다.

AgentCore 웹 검색을 프로덕션 환경에 구현하는 방법

구체적인 사례를 살펴보겠습니다. 아래는 LangGraph 오케스트레이터 (Orchestrator)와 Bedrock AgentCore SDK를 사용하여 구현한, 최소한의 구성이면서도 프로덕션 환경에 적합한 통합 방식입니다. 이는 단일 모놀리식 에이전트 (Monolithic Agent)보다 제가 권장하는 패턴입니다. 즉, 모델이 추측하게 두는 대신 감독자 (Supervisor)가 적절한 근거 소스 (Grounding Source)로 명시적으로 라우팅 (Routing)합니다.

Python — AgentCore 웹 검색 + LangGraph 감독자 (Supervisor)

pip install bedrock-agentcore langgraph boto3

from bedrock_agentcore.tools import WebSearchTool
from langgraph.graph import StateGraph, END
import boto3

관리형 웹 검색 (Managed web search) — 스크래퍼(Scrapers)나 프록시(Proxies) 불필요, 신원 인식 가능 (Identity-aware)