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

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

대부분의 AI 기술 워크플로우는 완전히 잘못된 문제를 해결하고 있습니다. 사람들은 어떤 모델을 사용할지에 집착하는 동안, 그들의 에이전트들은 학습 데이터 차단 시점(training cutoff) 이후에 발생한 사건들에 대해 조용히 환각(hallucination) 답변을 내놓고 있습니다. 그리고 AWS는 방금 이러한 실패 모드를 선택 사항으로 만들었습니다. 이번 달 출시된 가장 중대한 AI 기술은 더 큰 모델이 아니었습니다. 그것은 에이전트가 라이브 웹(live web)에 접속하는 방식을 마침내 견고하게 만드는 관리형 배관(managed plumbing) 기술이었습니다.

6월 18일, AWS는 Amazon Bedrock AgentCore의 웹 검색(Web Search on Amazon Bedrock AgentCore)을 출시했습니다. 이는 MCP를 통해 에이전트 런타임(agent runtimes)에 직접 연결되는 관리형이며 완전히 거버넌스가 적용된 라이브 웹 검색 도구입니다. 유지 관리해야 할 스크래퍼(scraper)도, 속도 제한(rate-limit)의 불확실성도, 제3자 검색 API 계약도 필요하지 않습니다. 프로덕션 에이전트를 운영하는 시니어 엔지니어들에게 이 AI 기술은 취약했던 전체 하위 시스템을 단일 관리형 프리미티브(managed primitive)로 축소해 줍니다.

이 분석을 마칠 때쯤이면 여러분은 AgentCore 웹 검색이 정확히 무엇인지, 그 이면의 아키텍처는 무엇인지, 멀티 에이전트 스택(multi-agent stack)의 어디에 위치하는지, 그리고 이것이 실제로 해결하는 구체적인 조정 문제(coordination problem)가 무엇인지 이해하게 될 것입니다.

AgentCore 웹 검색 도구는 에이전트 런타임과 라이브 웹 사이에 위치하여, 근거가 있고 인용 가능한(citation-ready) 결과를 반환함으로써 우리가 'AI 조정 격차(AI Coordination Gap)'라고 부르는 문제를 해결합니다. 출처

개요: Amazon Bedrock AgentCore의 웹 검색이란 실제로 무엇인가

Amazon Bedrock AgentCore의 웹 검색 (Web Search)은 자율 에이전트(autonomous agents)에게 실시간 웹을 쿼리할 수 있는 능력—최신 페이지를 가져오고, 콘텐츠를 추출하며, 근거가 있고 출처가 명시된 결과를 반환하는 능력—을 부여하는 관리형 AI 기술 도구입니다. 이를 통해 여러분의 팀은 검색 파이프라인을 직접 구축하거나 운영할 필요가 없습니다. 이 기능은 Model Context Protocol (MCP) 표준을 통해 도구(tool)로 제공되므로, MCP를 지원하는 모든 에이전트 프레임워크—LangGraph, CrewAI, AutoGen, Strands 또는 커스텀 런타임(custom runtime)—는 거의 추가 코드(glue code) 없이도 이를 호출할 수 있습니다.

대부분의 팀이 놓치고 있는 사실은 다음과 같습니다. 에이전트에게 웹 접속 권한을 주는 과정에서 어려운 점은 검색 쿼리 자체가 아니었습니다. 진짜 어려운 점은 그 주변의 모든 것이었습니다. 검색 API를 위한 자격 증명 순환(credential rotation), 매주 깨지는 HTML 파싱(HTML parsing), 콘텐츠 중복 제거(content de-duplication), 최신성 점수 산정(freshness scoring), 속도 제한 백오프(rate-limit backoff), 그리고 에이전트가 데이터를 유출하거나 차단된 도메인에서 정보를 가져오지 않는다는 것을 보안 팀에 증명할 거버넌스 계층(governance layer) 등이 바로 그것입니다. AgentCore 웹 검색은 이러한 모든 운영 영역을 Bedrock Agents 문서에 명시된 관리형 서비스로 흡수합니다.

이것이 지금 당장 중요한 이유는, 업계가 지난 18개월 동안 취약한 검색 기반(retrieval foundation) 위에 점점 더 정교한 에이전트를 구축하는 데 시간을 보냈기 때문입니다. 우리는 에이전트에게 추론(reasoning)을 학습시키고, 메모리(memory)를 부여하고, 도구 사용 루프(tool-use loops)에 연결했습니다. 그러고 나서 제3자 API 키와 정규 표현식(regex)으로 겨우 유지되는 웹 접속 계층을 그들에게 넘겨주었습니다. 그 결과, 프로덕션 에이전트 시스템(production agentic systems)에서 지배적인 실패 모드(failure mode)가 나타나고 있습니다. 바로 오래되었거나 조작된 사실을 바탕으로 자신감 있고 논리적인 답변을 내놓는 것입니다. 저는 이 문제로 인해 다른 부분은 잘 구축되었음에도 불구하고 프로젝트가 무너지는 것을 목격해 왔습니다.

각 도구 호출(tool call)의 신뢰도가 95%인 6단계 에이전트 파이프라인(agent pipeline)의 경우, 엔드 투 엔드(end-to-end) 신뢰도는 약 77%에 불과합니다. 웹 검색(Web retrieval)은 역사적으로 가장 신뢰도가 낮은 단계(종종 80% 미만)였으며, 이는 전체 시스템 실패의 주된 원인이었음을 의미합니다. 이를 해결하는 것은 에이전트 전체의 계산식을 바꿉니다.

이 기능은 연구용 프리뷰(research preview)가 아닌 프로덕션 준비 완료(production-ready) 상태로 출시되었습니다(AWS 발표에 따르면 특정 AWS 리전에서 일반 사용 가능(GA)). 이는 조달 결정을 내리는 팀들에게 의미 있는 차이입니다. 이 기능은 Memory, Gateway, Identity, Code Interpreter와 함께 더 넓은 AgentCore 제품군에 합류하며, AWS가 단일 모델 엔드포인트(model endpoint)를 넘어 완전한 관리형 에이전트 기질(managed agent substrate)을 제공할 수 있도록 포지셔닝합니다.

전략적 해석: AWS는 모델 품질만으로 경쟁하는 것이 아닙니다. AWS는 모델과 현실 세계 사이의 인프라(infrastructure between the model and the real world로 경쟁하고 있습니다. 즉, 웹사이트의 HTML이 변경된 후 화요일에 에이전트가 제대로 작동할지를 결정하는, 화려하지는 않지만 필수적인 배관(plumbing) 작업입니다. 그곳이 바로 대부분의 에이전트 프로젝트가 실제로 실패하는 계층이며, 이번 출시가 직접적으로 겨냥하고 있는 계층입니다.

~77%
단계별 95% 신뢰도를 가진 6단계 에이전트의 엔드 투 엔드 신뢰도
[arXiv 복합 오류 분석 (compounding-error analysis), 2024](https://arxiv.org/abs/2210.03629)
...

대부분의 사람들이 오해하는 것: AI 조정 격차 (The AI Coordination Gap)

거의 모든 사람이 범하는 실수는 AI 에이전트를 _추론 문제(reasoning problem)_로 취급하는 것입니다. 가장 똑똑한 모델을 선택하고, 가장 영리한 프롬프트(prompt)를 작성하고, 성찰 루프(reflection loop)를 추가하면 에이전트가 잘 작동할 것이라고 믿습니다. 하지만 프로덕션 환경에서 병목 현상은 추론 품질 때문인 경우가 거의 없습니다. 그것은 모델의 의도(intent)와 모델이 행동해야 하는 무질서하고, 상태 유지적(stateful)이며, 지연 시간(latency)에 제약을 받는 현실 세계 사이의 조정(coordination) 문제입니다.

명명된 프레임워크

AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차(AI Coordination Gap)란 모델이 _하기로 결정한 것_과 도구, 상태, 신원(identity), 그리고 실시간 외부 세계에 걸쳐 주변 인프라가 신뢰성 있게 실행할 수 있는 것 사이의 체계적인 거리입니다. 이는 대부분의 프로덕션 에이전트가 실패하는 계층이며, 모든 데모에서는 보이지 않는 부분입니다.

데모는 격차를 숨깁니다. 데모는 알려진 웹사이트를 대상으로, 새로운 API 키를 사용하여, 깨끗한 네트워크 환경에서 단 한 번 실행되기 때문입니다. 반면 프로덕션 (Production)은 이를 노출합니다. 프로덕션은 매시간 변하는 웹을 대상으로, 만료되는 자격 증명을 사용하여, 감사 로그 (Audit logs)를 원하는 보안 팀의 통제 하에 만 번 실행되기 때문입니다. AgentCore의 웹 검색 (Web Search)은 단순한 검색 기능이 아니라, AWS가 AI 조정 격차 (AI Coordination Gap) 중 매우 구체적이고 비용이 많이 드는 부분인 '실시간 세계 검색 (Live-world retrieval)' 조각을 메우는 것으로 이해하는 것이 가장 정확합니다.

AI 에이전트로 승리하는 기업은 가장 똑똑한 모델을 가진 기업이 아닙니다. 모델과 현실 사이의 지루한 계층을 산업화한 기업입니다.

문제를 이런 방식으로 재구성하면 AgentCore의 전략이 명확해집니다. 메모리 (Memory)는 격차의 상태 (State) 조각을 메웁니다. 아이덴티티 (Identity)는 인증 (Auth) 조각을 메웁니다. 게이트웨이 (Gateway)는 도구 통합 (Tool integration) 조각을 메웁니다. 웹 검색 (Web Search)은 외부 세계 (External-world) 조각을 메웁니다. 각각은 취약하고 수동으로 제작된 서브시스템을 서비스 수준 협약 (SLA)을 갖춘 무언가로 전환합니다. 이것이 게임의 전부입니다. 이 구성 요소들이 어떻게 맞물리는지에 대한 더 심도 있는 분석은 우리의 멀티 에이전트 시스템 (Multi-agent systems) 가이드를 참조하십시오.

시각화된 AI 조정 격차 (AI Coordination Gap): 모델의 의도와 현실 세계의 실행 사이의 모든 화살표는 프로덕션 에이전트가 소리 없이 실패하는 지점입니다. AgentCore 웹 검색은 외부 검색 (External-retrieval) 화살표를 강화합니다.

AgentCore 웹 검색의 5가지 계층

이 AI 기술을 프로덕션에서 운영하려면 다섯 가지 기능 계층으로 분해해야 합니다. 각 계층은 제거되는 실제 실패 모드와 매핑됩니다.

계층 1 — MCP 도구 인터페이스 (The MCP Tool Interface)

웹 검색(Web Search)은 MCP (Model Context Protocol) 도구로 노출됩니다. 이는 이번 출시에서 가장 과소평가된 설계 결정입니다. 이 도구는 MCP를 준수하기 때문에, 에이전트의 추론 루프(reasoning loop) 곳곳에 AWS 전용 SDK 호출을 맞춤형으로 배치할 필요가 없습니다. 에이전트 런타임(runtime)은 도구를 발견하고, 스키마(schema)를 읽고, 다른 기능과 마찬가지로 이를 호출합니다. 커스텀 검색 래퍼(wrapper)에서 AgentCore 웹 검색으로 교체하더라도 LangGraph 노드는 거의 변하지 않습니다. 저는 이를 훌륭한 추상화 경계(abstraction boundary)라고 부르고 싶습니다.

계층 2 — 검색 및 페치 엔진 (The Retrieval & Fetch Engine)

인터페이스 아래에서 AWS는 실제 검색 및 페치(search-and-fetch) 메커니즘을 운영합니다. 즉, 쿼리(query)를 발행하고, 후보 페이지를 검색하며, 콘텐츠를 가져와 렌더링하고, 속도 제한(rate limits), 재시도(retries), 그리고 그렇지 않았다면 여러분의 문제가 되었을 순환 인프라(rotating infrastructure)를 처리합니다. 이 계층은 과거에 이를 유지하기 위해서만 분기당 엔지니어 1주일의 업무량이 소모되던 곳이었으며, 이는 과장이 아닙니다. HTML 구조가 변경되고, 속도 제한이 엄격해지며, IP 범위가 차단됩니다. 누군가는 항상 그 난장판을 책임져야 했습니다. 이제 그 대상은 여러분이 아닙니다.

계층 3 — 추출 및 그라운딩 계층 (The Extraction & Grounding Layer)

가공되지 않은 HTML은 에이전트에게 무용지물입니다. 이 계층은 깨끗하고 관련성 있는 콘텐츠를 추출하여 모델이 그라운딩(grounding)할 수 있는 구조로 반환하며, 에이전트가 인용할 수 있도록 소스 URL을 첨부합니다. 인용을 포함한 그라운딩(Grounding-with-citation)은 규제 대상 고객에게 바로 보낼 수 있는 답변과 절대 보낼 수 없는 답변을 가르는 차이점입니다. 인용을 생략한다면, 컴플라이언스(compliance) 검토 단계에서 이 문제를 아주 고통스럽게 다시 경험하게 될 것입니다.

계층 4 — 거버넌스 및 ID 계층 (The Governance & Identity Layer)

웹 검색은 Bedrock AgentCore 내부에서 실행되므로, AWS 네이티브 ID, IAM 권한, 그리고 감사 로깅(audit logging)을 상속받습니다. 어떤 에이전트가 검색할 수 있는지 제한할 수 있고, 모든 쿼리를 기록하며, 깔끔한 컴플라이언스 스토리를 제시할 수 있습니다. 기업 구매자들에게 이 계층은 모델이나 프롬프트가 아니라, 프로젝트의 출시 여부나 중단 여부를 결정짓는 실제 이유가 되는 경우가 많습니다. 바로 거버넌스(governance) 이야기입니다.

레이어 5 — 런타임 통합 레이어 (The Runtime Integration Layer)

마지막으로, 이 도구는 AgentCore의 나머지 구성 요소들과 결합합니다. 검색 결과가 턴(turn) 간에 유지되도록 하는 메모리 (Memory), 검색 기능이 다른 도구들과 나란히 배치되도록 하는 게이트웨이 (Gateway), 그리고 루프를 오케스트레이션 (orchestrate)하는 에이전트 런타임 (Runtime)이 그 대상입니다. 이러한 결합성 (composability)이야말로 검색 도구를 단순히 덕테이프로 이어 붙인 일회성 통합 (one-off integration)이 아닌, 일관된 에이전트 플랫폼의 일부로 변모시키는 핵심 요소입니다. 이를 하나로 묶어주는 오케스트레이션 패턴 (orchestration patterns)에 대해서는 당사의 에이전트 오케스트레이션 레이어 (agent orchestration layers) 분석 내용을 참조하십시오.

프로덕션 환경에서 AgentCore 웹 검색 호출이 흐르는 방식

  1

    **에이전트 런타임 (Agent Runtime) (LangGraph / Strands)**

추론 루프 (reasoning loop)가 현재 지식이 불충분하다고 판단하여 도구 호출 (tool call)을 생성합니다. 입력: 자연어 쿼리 (natural-language query). 결정 지점: 검색을 할 것인가, 아니면 메모리에서 답변할 것인가.

↓

  2
...

표준화된 도구 스키마 (standardised tool schema)가 호출을 검증하고 라우팅 (route)합니다. 에이전트 로직 내에 AWS 전용 글루 (glue) 코드는 포함되지 않습니다. 여기서의 지연 시간 예산 (latency budget)은 무시할 수 있는 수준입니다.

↓

  3
...

IAM이 에이전트의 검색 권한을 확인하며, 감사를 위해 쿼리가 기록됩니다. 차단된 도메인이 필터링됩니다. 이곳은 컴플라이언스 (compliance)를 나중에 덧붙이는 것이 아니라, 실행 단계에서 강제하는 지점입니다.

↓

  4
...

AWS 관리형 검색 (AWS-managed search)이 쿼리를 실행하고, 후보 페이지를 가져오며, 속도 제한 (rate limits) 및 재시도 (retries)를 처리합니다. 지연 시간의 주요 원인은 일반적으로 네트워크 왕복 시간 (network round-trips)입니다.

↓

  5
...

정제된 콘텐츠와 소스 URL이 모델로 반환됩니다. 최종 답변의 출처를 밝히고 감사할 수 있도록 인용 (citations) 정보가 보존됩니다.

↓

  6
...

결과가 AgentCore 메모리 (Memory)를 통해 유지되므로, 후속 턴에서 다시 가져올 필요가 없습니다. 이것이 세션 내에서 학습하는 에이전트와 똑같은 말을 반복하는 에이전트의 차이점입니다.

이 시퀀스(sequence)는 매우 중요합니다. 거버넌스 (governance)는 검색(fetch) 이전에 발생하고, 그라운딩 (grounding)은 모델이 콘텐츠를 보기 전에 발생하기 때문입니다. 즉, 각 경계(boundary)에서 실패 모드 (failure modes)가 제어됩니다.

인용 (citations)을 반환하지 못하는 검색 도구는 연구 보조원이 아닙니다. 그것은 어휘력만 더 나은, 자신감 넘치는 거짓말쟁이일 뿐입니다.

구현 방법: 실질적인 경로

시니어 엔지니어들에게 이 통합은 의도적으로 매우 얇게(thin) 설계되었습니다. 에이전트가 MCP 도구로서 웹 검색을 호출하면, 나머지는 AWS가 처리합니다. 다음은 LangGraph 스타일의 에이전트 노드를 사용하는 대표적인 패턴입니다.

python

의사 코드(Pseudocode): AgentCore 웹 검색을 MCP 도구로 LangGraph 에이전트에 연결하기

from mcp_client import MCPToolClient # 모든 MCP 호환 클라이언트
from langgraph.graph import StateGraph