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

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

대부분의 AI 기술 워크플로우는 완전히 잘못된 문제를 해결하고 있습니다. 실제 병목 현상은 AI 기술이 고정되고 오래된 세상의 스냅샷을 바탕으로 추론하고 있다는 점인데, 사람들은 모델의 품질에만 집착합니다. 해결책은 더 큰 모델이 아닙니다. 그것은 실시간의, 관리되는 그라운딩 (grounding)이며, 이것이 바로 이 AI 기술 가이드가 다루고자 하는 핵심입니다.

이것이 바로 지금 AWS가 Amazon Bedrock AgentCore의 웹 검색 (Web Search on Amazon Bedrock AgentCore)을 출시하는 것이 중요한 이유입니다. 이는 관리되고 제어되는 실시간 웹 검색 프리미티브 (primitive)를 AgentCore Runtime, Memory, Gateway와 나란히 배치되는 일급 에이전트 도구 (first-class agent tool)로 변모시킵니다. 더 이상 LangGraph 루프에 취약한 스크래퍼 (scraper)를 억지로 붙일 필요가 없으며, 더 이상 더 이상 존재하지 않는 세상에 대해 자신 있게 답변하는 AI 기술을 출시할 필요도 없습니다.

이 글을 끝까지 읽고 나면, 여러분은 아키텍처 (architecture), 비용 모델 (cost model), RAG보다 뛰어난 점, 그리고 새로운 실패 모드 (failure modes)를 생성하지 않고 이를 프로덕션 멀티 에이전트 시스템 (multi-agent system)에 연결하는 방법을 이해하게 될 것입니다.

Amazon Bedrock AgentCore Web Search는 AgentCore 스택 내의 Runtime, Memory, Gateway와 함께 관리형 도구로 자리 잡고 있어, 대부분의 팀이 수동으로 구축하는 취약한 커스텀 스크래퍼 (custom-scraper) 계층을 제거합니다. 출처

개요: AgentCore Web Search가 실제로 변화시키는 것

이번 AWS 출시가 드러내는 불편한 진실은 다음과 같습니다. AI 기술 산업은 지난 2년 동안 잘못된 계층(layer)을 최적화하는 데 시간을 허비했습니다. 우리는 모델의 추론 (reasoning) 능력을 벤치마킹하고, 말투 (tone)를 미세 조정 (fine-tuning)하며, 점점 더 거대한 벡터 데이터베이스 (vector databases)를 구축해 왔습니다. 하지만 그동안 에이전트 (agents)들은 더 이상 존재하지 않는 세상에 대해 자신 있게 답변하고 있었습니다.

지식 차단 시점 (knowledge cutoff)이 2024년인 모델은 지난주 선거에서 누가 승리했는지, 경쟁사가 오늘 아침 제품 가격을 얼마로 책정했는지, 혹은 당신이 통합하려는 API가 어제 중대한 변경 사항 (breaking change)을 배포했는지 알지 못합니다. 모델이 틀린 이유는 지능이 낮아서가 아닙니다. 모델이 '단절 (disconnected)'되어 있기 때문입니다.

Amazon Bedrock AgentCore Web Search는 이러한 단절에 대한 AWS의 해답입니다. 에이전트가 실시간 웹 쿼리 (web queries)를 실행하고, 최신 결과를 검색하여, 이를 추론 루프 (reasoning loop)에 공급할 수 있도록 하는 관리형 도구 (managed tool)입니다. 또한 기업 팀이 실제로 필요로 하는 거버넌스 (governance), 관찰 가능성 (observability), 그리고 신원 제어 (identity controls) 기능을 함께 제공합니다. 이는 Runtime (서버리스 에이전트 호스팅), Memory (단기 및 장기 상태), Gateway (API를 에이전트 도구로 변환), 그리고 Identity를 포함하여 점차 확장되고 있는 AgentCore 제품군에 합류하는 것입니다. 자세한 내용은 공식 AWS Bedrock Agents 문서에서 확인할 수 있습니다.

이것이 단순한 기능 발표가 아닌 시스템적인 이야기인 이유는, 이 기능이 동시에 만들어내고 또 해결하는 '조정 문제 (coordination problem)' 때문입니다. 에이전트가 실시간 웹에 접속할 수 있게 되는 순간, 당신은 다단계 파이프라인 (multi-step pipeline)에 새롭고 빠르게 변화하며 신뢰할 수 없는 데이터 소스를 도입하게 됩니다. 바로 이 지점에서 대부분의 팀이 실수를 범하게 되며, 이 글에서 다룰 프레임워크가 필요한 이유이기도 합니다.

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

AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차 (The AI Coordination Gap)는 모델, 도구, 메모리, 검색(Retrieval)과 같은 여러 AI 구성 요소들이 최신성(Freshness), 신뢰성(Trust), 상태(State)에 대해 서로 다른 가정을 가지고 작동할 때 발생하는 복합적인 신뢰성 손실을 의미합니다. 이는 개별적으로는 뛰어난 부품들로 구축된 시스템이 왜 집합적으로는 신뢰할 수 없는 답변을 내놓는지에 대한 이유를 명명한 것입니다.

모든 시니어 엔지니어가 결국 마주하게 되는 수학적 계산을 생각해 보십시오. 각 단계의 신뢰도가 97%인 6단계 파이프라인의 경우, 엔드 투 엔드(End-to-end) 신뢰도는 약 83%에 불과합니다 ($0.97^6$). 여기에 상충되거나 신뢰도가 낮은 소스를 반환하는 웹 검색(Web-search) 단계와 오래된 사실을 캐싱하는 메모리 계층(Memory layer)이 추가되면, 실제 정확도는 단일 구성 요소의 벤치마크가 예측하는 것보다 훨씬 빠르게 무너집니다. 결과물은 구성 요소가 아니라, 바로 그 조정(Coordination)의 산물입니다.

AI 에이전트로 승리하고 있는 기업들은 가장 많은 GPU를 보유한 기업이 아니라, 조정을 해결한 기업들입니다. AgentCore 웹 검색(Web Search)은 에이전트가 자신의 파라미터 메모리(Parametric memory)나 벡터 스토어(Vector store)보다 웹 검색을 언제 더 신뢰해야 하는지 알고 있을 때에만 가치가 있습니다.

이 가이드는 시스템을 명명된 계층(Layers)으로 나누어 각 계층이 실제로 어떻게 작동하는지 보여주고, 실제 배포 패턴, 비용 모델, 신뢰성을 조용히 파괴하는 실수들, 그리고 관리형 에이전트 도구(Managed agent tooling)가 나아갈 방향에 대한 예측 타임라인을 다룹니다. 이 과정 전반에 걸쳐 저는 이것이 LangGraph, AutoGen, CrewAI, n8n, 그리고 모델 컨텍스트 프로토콜(Model Context Protocol)과 같은 더 넓은 생태계와 어떻게 맞물리는지 언급할 것입니다. AgentCore는 진공 상태에서 존재하지 않기 때문입니다.

모델이 틀린 이유는 멍청해서가 아닙니다. 단절되어 있기 때문입니다. 웹 검색은 모델이 알고 있는 것과 지금 실제로 사실인 것 사이의 간극을 메워줍니다.

2026년에는 왜 모델 크기보다 실시간 검색(Real-Time Retrieval)이 더 중요한가

데이터 중심의 논거를 제시하겠습니다. 숫자는 그 어떤 자극적인 의견보다 더 설득력이 있기 때문입니다.

83%
각 단계의 신뢰도가 97%인 6단계 에이전트 파이프라인의 엔드 투 엔드 (End-to-end) 신뢰도
arXiv, 2023
...

스크린샷으로 찍힐 만큼 직관에 반하는 주장을 하나 하겠습니다. 중급 모델 (mid-tier model)에서 프런티어 모델 (frontier model)로 업그레이드하는 것이, 정체된 에이전트에 잘 관리된 웹 검색 (web-search) 도구 하나를 추가하는 것보다 정확도 향상 폭이 더 적습니다. 저는 팀들이 실시간 검색 (real-time retrieval) 레이어를 통해 아주 적은 비용으로 해결할 수 있었던 문제를 해결하기 위해, 프리미엄 모델 토큰에 매달 80,000달러를 쓰는 것을 목격해 왔습니다. 모델은 이미 충분히 똑똑했습니다. 단지 사실(facts)이 없었을 뿐입니다.

이것이 바로 AWS가 기업용 AI 시스템 (enterprise AI systems) 내부에 웹 검색을 제품화하는 핵심 논지입니다. 이제 검색 (retrieval)은 여러분이 직접 구축해야 하는 차별화 요소가 아니라, 소비하는 인프라입니다. 여러분의 차별점은 조정 (coordination), 신뢰도 점수 산정 (trust scoring), 그리고 오케스트레이션 (orchestration) 로직과 같은 상위 스택으로 이동합니다. 이러한 변화는 Meta AI와 Google Research의 연구원들이 관찰한 내용과 일치합니다. 즉, 최신성(freshness)이 중요한 작업에서는 스케일링 (scaling)보다 그라운딩 (grounding)이 더 효과적이라는 것입니다. 검색 (retrieval)에 대한 근본적인 사례는 원래의 RAG 논문 (original RAG paper)에서 제시되었으며, 그 이후로 더욱 강화되었습니다.

관리되는 웹 검색 도구를 추가하는 것이 기반 모델을 업그레이드하는 것보다 실제 환경에서 더 큰 정확도 향상을 가져오는 경우가 많습니다. 왜냐하면 대부분의 운영 환경에서의 실패는 추론 (reasoning)의 실패가 아니라 최신성 (freshness)의 실패이기 때문입니다.

AgentCore 웹 검색을 기반으로 구축된 실시간 에이전트의 5가지 레이어

AI 조정 격차 (AI Coordination Gap)를 해소하려면 기능(feature)이 아닌 레이어(layer) 단위로 생각해야 합니다. 아래는 제가 실시간 데이터에 접근하는 모든 에이전트를 설계할 때 사용하는 프레임워크입니다. 각 레이어는 고유한 역할, 고유한 실패 모드, 그리고 고유한 비용 특성을 가집니다.

Amazon Bedrock AgentCore에서의 실시간 에이전트 스택 (The Real-Time Agent Stack on Amazon Bedrock AgentCore)

  1

    **오케스트레이션 레이어 (Orchestration Layer) (AgentCore Runtime + LangGraph)**

계획을 결정합니다: 어떤 도구(tool)를 호출할지, 어떤 순서로 호출할지, 그리고 언제 멈출지를 결정합니다. 입력(Inputs): 사용자 의도 (user intent). 출력(Outputs): 도구 호출 시퀀스 (tool-call sequence). 지연 시간 예산 (Latency budget): 계획 단계는 추론 단계당 300-800ms를 추가합니다.

↓

  2
...

쿼리가 실시간 데이터(live data), 캐시된 벡터 데이터(cached vector data), 또는 파라미터 메모리(parametric memory)를 필요로 하는지 분류합니다. 이는 대부분의 팀이 건너뛰는 레이어이지만, 조정 격차 (Coordination Gap)를 해소하는 핵심 레이어입니다. 출력(Outputs): 라우팅 결정 (routing decision).

↓

  3
...

웹 검색 (Web Search)은 실시간성이 중요한 쿼리를 처리하고, 벡터 데이터베이스 (vector database)는 독점적이고 안정적인 지식을 처리합니다. 입력(Inputs): 라우팅된 쿼리 (routed query). 출력(Outputs): 타임스탬프가 포함된, 출처가 명시된 순위 기반 결과 (ranked, source-attributed results).

↓

  4
...

출처의 신뢰도를 점수화하고, 웹 검색 결과와 내부 지식 간의 충돌을 해결하며, 신뢰도가 낮은 답변에 플래그를 지정합니다. 출력(Outputs): 신뢰 점수가 포함된 근거 있는 컨텍스트 (grounded context).

↓

  5
...

학습된 내용을 출처(provenance) 및 만료 시간과 함께 영구 저장합니다. 감사를 위해 모든 도구 호출을 로그로 남깁니다. 출력(Outputs): 지속 가능하고 타임스탬프가 찍힌 상태 (durable, time-stamped state) 및 전체 트레이스 (full traces).

시퀀스가 중요합니다: 검색(retrieval) 전의 라우팅, 그리고 메모리(memory) 전의 조정(reconciliation)은 오래된 사실이 장기적인 상태를 오염시키는 것을 방지합니다.

레이어 1: 오케스트레이션 레이어 (The Orchestration Layer)

이곳은 두뇌 역할을 합니다. AgentCore Runtime은 서버리스(serverless) 및 세션 격리(session-isolated) 실행을 제공하지만, 계획 로직은 일반적으로 LangGraph 또는 AutoGen과 같은 프레임워크에 존재합니다. 오케스트레이션 레이어는 '이 경쟁사 요금제의 현재 가격은 무엇인가요?'라고 묻는 사용자는 실시간 검색이 필요하다고 결정하는 반면, '우리의 내부 3분기 정책을 요약해줘'라는 질문은 실시간 검색이 필요하지 않다고 결정합니다.

이 지점에서의 성숙도 격차(maturity gap)에 대해 솔직하게 말할 가치가 있습니다. AgentCore Runtime은 일반적으로 사용 가능(GA, General Availability)하며 프로덕션 격리(production isolation)를 위해 구축되었습니다. 그 위에 덧붙이는 오케스트레이션 프레임워크(orchestration framework) — LangGraph (프로덕션 준비 완료), CrewAI (빠르게 성숙 중), AutoGen (대부분의 배포 환경에서 여전히 연구 중심적) — 가 여러분의 계획(planning)이 실제로 얼마나 견고한지를 결정합니다. 저는 오늘날 규제 환경(regulated environment)에서 AutoGen을 출시하지는 않을 것입니다. 더 깊은 비교를 원하시면 Microsoft의 AutoGen 리포지토리와 그곳의 설계 노트를 참조하십시오.

레이어 2: 신선도 라우터 (The Freshness Router)

이것은 아무도 이야기하지 않지만 모두에게 필요한 레이어입니다. 신선도 라우터(freshness router)는 비용이 많이 드는 검색(retrieval)이 일어나기 전에 _데이터 소스(data source)_를 결정하는 가벼운 분류기(classifier)입니다. 이는 종종 저렴한 모델 호출(model call)이나 규칙 엔진(rules engine)으로 구현됩니다. 이를 건너뛰면 안정적인 사실 기반 질문들을 실시간 웹 검색으로 라우팅하게 되어, 필요하지 않은 노이즈에 비용을 지불하게 될 것입니다.

쿼리의 60-70%를 실시간 검색 대신 캐시된(cached) 답변이나 파라메트릭(parametric) 답변으로 라우팅하면, 일반적으로 검색 비용을 절반으로 줄이고 지연 시간(latency)을 40% 단축하는 동시에 정확도를 향상시킬 수 있습니다. 이는 필요하지 않은 질문에 대해 노이즈가 섞인 웹 검색 결과를 가져오는 것을 중단하기 때문입니다.

python — 신선도 라우터 (단순화 버전)

AgentCore 에이전트를 위한 최소한의 신선도 라우터

def route_query(query: str, model) -> str:

저렴한 분류 호출이 검색 경로를 결정합니다

decision = model.classify(
query,
labels=['live_web', 'vector_store', 'parametric']
)

시간 민감형 의도(intent) -> AgentCore Web Search

if decision == 'live_web':
return 'agentcore_web_search'

독점적/안정적 지식 -> 벡터 DB (Pinecone)

if decision == 'vector_store':
return 'pinecone_retrieval'

안정적인 일반 지식 -> 직접 답변

return 'parametric'

레이어 3: 검색 레이어 (The Retrieval Layer)

여기서 AgentCore Web Search가 실제 작업을 수행합니다. 즉, 라이브 웹(live web)에 통제된 쿼리(governed queries)를 발행하고, 순위가 매겨지고 출처가 명시되며 타임스탬프가 찍힌 결과를 반환합니다. 핵심적인 설계 결정은 Web Search와 귀하의 Pinecone 벡터 스토어(vector store)가 경쟁 관계가 아닌 상호 보완적(complementary) 관계라는 점입니다. Web Search는 빠르게 변화하는 외부 세계를 위한 것이며, 벡터 스토어는 변화가 느린 귀하의 독점적(proprietary) 데이터를 위한 것입니다. 이 두 역할을 혼동하는 것이야말로 어느 한 쪽의 접근 방식보다 더 나쁜, 비용만 많이 드는 엉망인 상태를 초래하는 원인입니다.

레이어 4: 신뢰 및 조정 레이어 (The Trust & Reconciliation Layer)

이 지점은 대부분의 라이브 웹 에이전트(live-web agents)가 조용히 실패하는 구간입니다. 웹은 모순되고, 시대에 뒤떨어지며, 적대적인 콘텐츠로 가득 차 있습니다. 에이전트에는 소스의 신뢰도를 점수화하고 충돌을 조정(reconcile)하는 명시적인 로직이 필요합니다. 예를 들어, 애그리게이터(aggregator)보다 1차 출처(primary source)를 선호하거나, 웹 검색 결과가 검증된 내부 사실과 충돌할 때 이를 플래그(flag) 처리하는 식입니다. 저는 이 레이어를 구축하지 않았기 때문에 에이전트가 벤더의 자체 변경 로그(changelog)보다 2년 전의 블로그 포스트를 인용하는 것을 본 적이 있습니다.