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

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

대부분의 AI 기술 워크플로우(workflows)는 완전히 잘못된 문제를 해결하고 있습니다.

AWS가 방금 Amazon Bedrock AgentCore의 Web Search를 출시했습니다. 이는 에이전트가 관리되는 런타임(runtime) 내에서 라이브 웹을 쿼리할 수 있게 해주는 관리형 AI 기술 도구입니다. 이것이 지금 중요한 이유는 실시간 그라운딩(real-time grounding)이 데모 수준의 에이전트와 현실 세계의 접점에서도 살아남는 프로덕션 시스템(production systems) 사이의 누락된 기본 요소(primitive)였기 때문입니다. 이것은 조용히, 올해 가장 중대한 AI 기술 출시 중 하나가 될 것입니다.

이 가이드를 마칠 때쯤이면 여러분은 아키텍처(architecture), 비용 모델(cost model), 그리고 제가 'AI 조정 격차(AI Coordination Gap)'라고 부르는 프레임워크를 이해하게 될 것이며, 프로덕션 환경에서 소리 없이 실패하지 않는 실시간 에이전트를 배포하는 방법을 알게 될 것입니다.

Amazon BedCore Web Search가 관리되는 라이브 웹 도구를 에이전트 런타임에 어떻게 배치하여, 오래된 컨텍스트(stale-context)를 가진 에이전트를 실시간 시스템으로 전환하는지 보여줍니다. 출처

개요: AWS가 실제로 출시한 것 — 그리고 이것이 왜 단순한 '검색'보다 더 큰 의미를 갖는가

직관에 반하는 진실이 하나 있습니다. AgentCore Web Search의 핵심 기능은 검색 그 자체가 아닙니다. 그것은 바로 _관리형 에이전트 런타임 (managed agent runtime) 내에서 제어되는 실시간 그라운딩 (governed real-time grounding)_입니다. 누구나 LLM에 검색 API를 덧붙일 수는 있습니다. 하지만 모든 팀이 깔끔하게 해내지 못했던 것은, 6개의 서비스를 하나로 엮고 그 연결 부위가 버티길 기도하는 대신, 내장된 ID (identity), 관찰 가능성 (observability), 메모리 지속성 (memory persistence), 그리고 도구 게이트웨이 (tool gateways)를 갖춘 상태로 에이전트에게 실시간 웹 액세스를 부여하는 것이었습니다. 이것은 '프로덕션 준비 완료 (production-ready)'의 기준을 조용히 재설정하는 AI 기술의 전환입니다.

Amazon Bedrock AgentCore는 AWS의 에이전트 런타임 (agent runtime) 레이어입니다. 이는 모든 진지한 에이전트 팀이 시행착오를 통해 깨닫게 되는 관심사들을 분리합니다: 보안 런타임 (secure runtime), ID 레이어 (identity layer), 메모리 서비스 (memory service), 도구 게이트웨이 (tool gateway), 그리고 관찰 가능성 (observability)입니다. Web Search는 도구 게이트웨이에 일급 관리형 기능 (first-class, managed capability)으로 통합됩니다. 따라서 제3자 SERP API 주변에 재시도 로직이 포함된 fetch 루프를 작성하는 대신, 여러분의 에이전트는 AWS가 운영, 보안 및 로깅을 수행하는 도구를 호출하게 됩니다. 공식 AgentCore 문서에는 이러한 각각의 프리미티브 (primitives)가 상세히 설명되어 있습니다.

이것이 화제가 되는 이유는 타이밍 때문입니다. 지난 18개월 동안 업계는 고정된 학습 데이터 (frozen training data)를 기반으로 수천 개의 AI 에이전트 (AI agents)를 구축했습니다. 이들은 최신 사건을 환각 (hallucinate)하고, 이미 사라진 가격을 인용하며, 2026년에 2023년의 사실을 인용했습니다. 실시간 그라운딩 (real-time grounding)은 명백한 해결책이었지만, 이를 엔터프라이즈 규모에서 안전하게 수행하는 것은 미해결 과제였습니다. 이것이 바로 AWS가 겨냥하고 있는 격차이며, NIST AI 위험 관리 프레임워크 (NIST AI Risk Management Framework)와 같은 광범위한 가이드라인과도 일치합니다.

2026년의 병목 현상은 결코 '모델이 웹을 검색할 수 있는가?'가 아니었습니다. 그것은 '에이전트가 ID, 속도 제한 (rate-limits), 감사 로그 (audit logs), 그리고 깔끔한 실패 모드 (failure mode)를 갖추고 웹을 검색할 수 있는가?'였습니다. AgentCore Web Search는 바로 그 기능을 관리형 인프라 (managed infrastructure)로 패키징하여 제공합니다.

하지만 — 그리고 이것이 이 가이드 전체의 논지입니다 — 실시간 검색 도구를 추가한다고 해서 시스템이 신뢰할 수 있게 되는 것은 아닙니다. 그것은 단지 하나의 구성 요소(component)를 신뢰할 수 있게 만들 뿐입니다. 진짜 어려운 문제는 구성 요소 '사이'에서 발생하는 일들입니다. 즉, 플래너(planner)가 어떻게 검색을 결정하는지, 검색 결과가 RAG 메모리와 어떻게 조화(reconciled)되는지, 그리고 서브 에이전트(sub-agent)의 출력이 드리프트(drift) 없이 어떻게 다음 단계로 전달되는지와 같은 문제입니다. 바로 이 지점에서 대부분의 시스템이 무너집니다. 이것이 바로 AI 조정 격차(AI Coordination Gap)입니다.

83%
각 단계의 신뢰도가 97%인 6단계 파이프라인의 엔드 투 엔드(End-to-end) 신뢰도
[arXiv 복합 오류 분석 (compounding-error analysis), 2025](https://arxiv.org/abs/2304.11477)
...

AI 에이전트로 승리하고 있는 기업들은 최고의 모델을 가진 기업들이 아닙니다. 그들은 조정(coordination) 문제, 즉 계획(planning), 검색(searching), 기억(remembering), 실행(acting) 사이의 복잡한 인계(handoffs) 문제를 해결한 기업들입니다.

AI 조정 격차: 에이전트가 실패하는 이유를 설명하는 프레임워크

명명된 프레임워크

AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차란 개별적으로는 신뢰할 수 있는 AI 구성 요소들 — 플래너(planners), 도구(tools), 메모리(memory), 서브 에이전트(sub-agents) — 사이에서, 이들의 인계(handoffs) 과정에 공유 상태(shared state), 오류 전파 규칙(error propagation rules), 그리고 그라운딩 일관성(grounding consistency)이 결여될 때 발생하는 시스템적 신뢰도 손실을 의미합니다. 이는 에이전트의 실패가 모델의 문제인 경우는 드물며, 대부분 조정의 문제라는 진실을 명명한 것입니다.

모든 팀은 구성 요소에 집착합니다. 더 나은 모델, 더 나은 검색, 더 나은 벡터 DB(vector DB)를 찾습니다. 하지만 실제 운영 환경에서의 실패는 거의 결코 단일한 취약한 구성 요소에서 비롯되지 않습니다. 실패는 '이음새(seams)'에서 발생합니다. 즉, 한 구성 요소가 다음 구성 요소로 업무를 인계하는 순간, 서로의 가정이 소리 없이 어긋날 때 발생합니다.

AgentCore Web Search를 구체적으로 살펴보겠습니다. 검색 도구는 97%의 관련성 있는 결과를 반환할 수 있습니다. 플래너(Planner)는 95%의 확률로 올바르게 검색을 선택할 수 있습니다. 실시간 웹 결과와 저장된 RAG 컨텍스트를 병합하는 조정(Reconciliation) 단계는 92%의 정확도를 가질 수 있습니다. 실행(Action) 단계는 96%의 정확도를 보일 수 있습니다. 이 수치들을 곱해 보겠습니다: 0.97 × 0.95 × 0.92 × 0.96 ≈ 0.81. 각각의 구성 요소가 개별적으로는 매우 훌륭하게 느껴지더라도, 결과적으로는 81%의 신뢰도를 가진 시스템이 됩니다. 저는 팀들이 이 정도 수치로 제품을 출시했다가, 고객이 잘못된 답변을 캡처해서 보내올 때서야 비로소 이를 발견하는 것을 목격해 왔습니다. 수학은 냉혹하며, 이는 연구자들이 다단계 LLM 시스템에서의 오류 전파(error propagation in multi-step LLM systems)에 대해 기록한 내용과 일치합니다.

각 단계가 97%의 신뢰도를 가진 6단계 파이프라인(Pipeline)은 엔드 투 엔드(End-to-end)로 보았을 때 단 83%의 신뢰도만을 가집니다. AgentCore는 여러분에게 신뢰할 수 있는 단계들을 제공합니다. 하지만 AgentCore가 신뢰할 수 있는 파이프라인을 제공할 수는 없으며, 제공해서도 안 됩니다. 그 부분은 여러분의 몫입니다.

AI 조정 격차(AI Coordination Gap)에는 네 가지 원인이 있으며, 이를 명명하는 것이 격차를 해소하는 첫 번째 단계입니다.

실시간 에이전트에서 조정이 깨지는 네 가지 계층

  1

    **의도 계층 (Intent Layer: Planner / Router)**

플래너(Planner)는 AgentCore Web Search를 호출할지, 메모리를 조회할지, 아니면 직접 답변할지를 결정합니다. 실패 모드: 기억해야 할 때 검색을 수행하거나, 데이터가 오래되었음에도 기억에 의존하는 경우. 지연 시간(Latency): 플래닝 홉(Planning hop)당 300-900ms.

↓

  2
...

제어되는 도구(Governed tool)가 신원(Identity), 속도 제한(Rate-limits), 감사 로그(Audit logging)를 적용하여 실시간 웹 쿼리를 실행합니다. 실패 모드: 조용한 부분적 결과 반환, 타임아웃이 빈 값으로 처리됨. 지연 시간(Latency): 실시간 검색당 800-2500ms.

↓

  3
...

실시간 웹 결과가 AgentCore Memory 및 벡터 DB RAG 컨텍스트와 병합됩니다. 실패 모드: 최신 웹 데이터와 저장된 사실 사이의 모순이 임의로 해결됨. 이것이 가장 큰 단일 숨겨진 격차입니다.

↓

  4
...

에이전트는 답변을 생성하거나 게이트웨이를 통해 다운스트림 액션 (downstream action)을 트리거합니다. 실패 모드: 조정되었으나 잘못된 컨텍스트 (reconciled-but-wrong context)를 바탕으로 완전한 확신을 가지고 행동하는 경우. 이 지점에서는 AgentCore 트레이스 (traces)를 통한 관찰 가능성 (Observability)이 매우 중요합니다.

각 레이어가 이전 레이어의 불확실성을 상속받기 때문에 시퀀스 (sequence)가 중요합니다. 즉, 포착되지 않은 오류는 상쇄되는 것이 아니라 복리로 쌓이게 됩니다.

네 가지 핸드오프 레이어 (handoff layers)로 시각화된 AI 조정 격차 (AI Coordination Gap) — 대부분의 팀은 박스(레이어)를 최적화할 뿐, 그 사이의 화살표(연결)는 무시합니다. 출처

레이어 1 — 의도 레이어 (The Intent Layer): 검색 시점 결정하기

실시간 에이전트에서 가장 비용이 많이 드는 실수는 불필요하게 검색하는 것입니다. 모든 AgentCore Web Search 호출은 지연 시간 (latency, 800-2500ms)과 비용을 추가합니다. 단순한 에이전트는 매 턴마다 검색을 수행합니다. 조정된 에이전트는 라우터 (router) — 주로 작고 빠른 모델 — 를 사용하여 질문에 실시간 데이터가 필요한지 여부를 결정합니다. '환불 정책이 무엇인가요?'는 메모리 (memory)를 참조해야 합니다. 'p5 인스턴스의 현재 AWS 스팟 가격은 얼마인가요?'는 반드시 웹을 참조해야 합니다. 이러한 구분은 자동으로 이루어지지 않습니다. 직접 구축해야 합니다.

LangGraph에서는 이것이 조건부 엣지 (conditional edge)입니다. CrewAI에서는 태스크 라우팅 규칙 (task-routing rule)입니다. 프레임워크보다 중요한 것은 원칙입니다. 플래너 (planner)가 기본값으로 검색을 선택하게 두지 마십시오. 검색을 의도적이고 정당화된 분기 (branch)로 만드십시오.

레이어 2 — 도구 레이어 (The Tool Layer): 관리되는 프리미티브로서의 AgentCore Web Search

이것이 바로 AWS가 방금 해결한 레이어입니다. AgentCore Web Search가 나오기 전에는 팀들이 제3자 SERP API, 프록시 로테이션(proxy rotation) 서비스, 속도 제한기(rate-limiter), 그리고 로깅 파이프라인(logging pipeline)을 직접 연결한 뒤, 이 모든 것을 영구적으로 관리해야 했습니다. 이제 이는 AgentCore Gateway 내부의 관리형 도구(managed tool)가 되었으며, Bedrock으로부터 ID를 상속받고 AgentCore Observability로 트레이스(traces)를 자동으로 방출합니다.

AgentCore Web Search는 2026년 6월 기준으로 일반적으로 사용 가능(GA)하며 프로덕션 환경에 즉시 적용할 수 있는 상태입니다. 이를 둘러싼 런타임(Runtime), 메모리(Memory), 게이트웨이(Gateway), ID(Identity), 관측성(Observability)은 2025년 말에 GA로 출시되었습니다. 검색 도구는 프로덕션 등급으로 취급하십시오. 대신, *그 도구를 둘러싼 조정 로직(reconciliation logic)*을 반드시 강화해야 할 실험적인 부분으로 취급하십시오. 그 경계가 중요합니다.

python — Strands / boto3를 통한 AgentCore Web Search (예시)

AgentCore Gateway 내부에서 관리되는 웹 검색 도구 구성

from bedrock_agentcore import AgentRuntime, Gateway, tools

gateway = Gateway(identity='prod-agent-role')

일급 관리형 도구로 등록된 웹 검색

web_search = tools.WebSearch(
max_results=5,
freshness='day', # 최신 결과에 가중치 부여
timeout_ms=2500, # 명시적 타임아웃 — 조용히 삼키지 말 것
)

agent = AgentRuntime(
model='anthropic.claude-3-7-sonnet',
tools=[web_search],
memory='session+long_term', # 조정을 위한 AgentCore Memory
observability=True, # 모든 홉(hop)에 대해 트레이스 방출
)

플래너(planner)가 web_search 호출 여부를 결정합니다 — 이것이 레이어 1입니다

response = agent.invoke('What changed in AWS Bedrock pricing this week?')

레이어 3 — 조정 레이어 (The Reconciliation Layer): 대부분의 시스템이 조용히 오류를 범하는 곳

아무도 이 레이어에 대해 이야기하지 않습니다. 모두가 이를 잘못 다룹니다. 실시간 웹 검색 결과가 저장된 메모리나 Pinecone 기반의 RAG 컨텍스트와 충돌할 때, 무엇이 승리해야 할까요? 대부분의 에이전트는 이를 암묵적으로 해결합니다. 즉, 두 정보를 모두 프롬프트(prompt)에 밀어 넣고 모델이 결정하게 만드는 것입니다. 그것은 조정(coordination)이 아닙니다. 그것은 도박이며, 저는 그런 방식으로 제품을 출시하지 않을 것입니다.

해결책은 명시적인 화해 정책(reconciliation policy)입니다. 모든 사실에 타임스탬프(timestamp)를 찍고, 변동성이 큰 데이터(volatile data)에 대해서는 더 최신의 소스를 우선시하며, 조용히 선택하는 대신 모순을 표시(flag)하는 것입니다. AgentCore Memory는 여러분에게 지속성 계층(persistence layer)을 제공합니다. 정책 자체는 여러분이 직접 작성해야 합니다. AWS가 대신 해주지는 않습니다.

모든 실시간 에이전트에서 가장 위험한 순간은 최신 웹 데이터가 저장된 메모리와 모순될 때이며, 시스템이 설계(design)에 의해서가 아니라 우연히(accident) 이를 해결해 버릴 때입니다.

레이어 4 — 액션 레이어(The Action Layer): 정당화 없는 확신

에이전트는 액션 레이어에서 가장 크게 실패하는데, 이는 화해(reconciliation)되었으나 잘못된 컨텍스트(context)를 바탕으로 완전한 확신을 가지고 행동하기 때문입니다. 완화 방법은 관찰 가능성(observability)입니다. AgentCore는 플래너의 결정(planner decision), 검색 쿼리(search query), 결과, 화해(reconciliation), 최종 출력에 이르기까지 모든 단계(hop)에 대해 구조화된 트레이스(structured traces)를 방출합니다. 이러한 트레이스가 없다면, 조정(coordination) 실패를 디버깅하는 것은 고고학 작업과 같습니다. 하지만 트레이스가 있다면, 그것은 단순한 쿼리(query)가 됩니다. OpenTelemetry와 같은 개방형 표준(open standards)은 이러한 트레이스가 내보내지고 검사되는 방식의 기반이 되고 있습니다.

명명된 프레임워크

AI 조정 격차 (The AI Coordination Gap)

이것은 에이전트 시스템 내부가 아니라, 구성 요소들 사이의 이음새에서 새어 나오는 신뢰성(reliability)의 문제입니다. 이를 메우는 것은 모델 업그레이드가 아니라 엔지니어링 규율(engineering discipline)입니다.