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

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

대부분의 AI 기술 워크플로우는 완전히 잘못된 문제를 해결하고 있습니다. AWS가 방금 Amazon Bedrock AgentCore의 웹 검색 (Web Search on Amazon Bedrock AgentCore) 기능을 출시했습니다. 모두가 이것이 Tavily API 키보다 나은지에 대해 논쟁하고 있지만, 그들은 그 이면에 있는 구조적 변화를 놓치고 있습니다. 현재 AI 기술의 진짜 이야기는 모델이 더 이상 병목 현상(bottleneck)이 아니라는 점입니다. 조정(Coordination)이 병목이 되었으며, 아직 이를 위해 설계(architecting)하는 사람은 거의 없습니다.

AgentCore의 웹 검색은 Bedrock 에이전트가 추론(reasoning) 중간에 실시간 웹을 쿼리할 수 있게 해주는 관리형 실시간 검색 도구로, 내장된 신원(identity), 메모리(memory), 거버넌스(governance)를 갖추고 있습니다. 이것이 지금 중요한 이유는 모델이 더 이상 병목이 아니라, 조정이 병목이기 때문입니다. LangGraph, CrewAI, 그리고 MCP 서버와 같은 도구들은 모두 동일한 벽에 부딪히고 있습니다.

이 글을 끝까지 읽으면 AI 조정의 격차(AI Coordination Gap)가 무엇인지, AgentCore 웹 검색이 그 격차의 일부를 어떻게 메우는지, 그리고 오래된 사실을 환각(hallucinate)하지 않는 에이전트를 어떻게 설계하는지 이해하게 될 것입니다. 읽으면서 미리 구축된 시작점이 필요하다면, 저희의 AI 에이전트 라이브러리를 찾아보세요.

AgentCore 웹 검색이 Bedrock 에이전트의 추론 루프(reasoning loop)에 실시간 웹 컨텍스트를 주입하는 방식 — AI 조정의 격차를 메우는 핵심입니다. 출처

개요: AgentCore 웹 검색의 실체 — 그리고 이것이 검색보다 더 큰 이유

먼저 역설적인 이야기를 하나 하겠습니다. 사람들이 스크린샷을 찍어 퍼 나를 만한 내용인데요. AI 에이전트(AI agents)로 승리하는 기업은 가장 똑똑한 모델을 가진 기업이 아니라, 모델, 도구(tools), 그리고 실시간 데이터 사이의 조정 문제(coordination problem)를 해결한 기업입니다. 오래된 컨텍스트(context)를 가진 프런티어 모델(frontier model)은 그저 어휘력이 풍부하고 자신감 넘치는 거짓말쟁이에 불과합니다.

Amazon Bedrock AgentCore는 프로덕션 환경의 AI 에이전트를 위한 AWS의 관리형 런타임(managed runtime)입니다. 이는 에이전트 프로젝트의 80%가 사용자에게 도달하기도 전에 무너뜨리는, 눈에 띄지 않지만 중요한 인프라들—ID(identity), 세션 격리(session isolation), 메모리 지속성(memory persistence), 관찰 가능성(observability), 도구 게이트웨이(tool gateways)—을 처리합니다. 새로운 웹 검색(Web Search) 기능은 에이전트가 추론(reasoning) 중간에 호출하여, 기반 모델이 학습 중단 시점(training cutoff)에 암기한 것에 의존하는 대신 오픈 웹에서 실시간 정보를 가져올 수 있는 퍼스트 파티(first-party) 관리형 도구를 추가합니다. 런타임의 공식 범위는 AWS Bedrock documentation에서 확인할 수 있습니다.

이것이 단순한 기능 추가가 아니라 카테고리의 전환인 이유는 다음과 같습니다. 이전에는 Bedrock 에이전트가 어제 일어난 일을 알게 하려면, 제3자 검색 API(Tavily, Serper, Brave)를 연결하고, 직접 속도 제한(rate-limiting)을 구축하며, 결과 순위 지정(result ranking)을 처리하고, HTML을 제거하고, Secrets Manager에서 API 키를 직접 관리해야 했습니다. 또한 에이전트의 추론 루프(reasoning loop)가 검색 여부를 결정하느라 14번의 도구 호출(tool calls)을 낭비하지 않기를 기도해야 했습니다. 이것은 모델의 문제가 아닙니다. 이것은 조정(coordination) 문제입니다. 저는 팀들이 실제 제품 로직을 단 한 줄도 작성하기 전에 정확히 이러한 배관 작업(plumbing)에만 6주를 소비하는 것을 보아왔습니다.

새로 명명된 프레임워크

AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차(AI Coordination Gap)란 개별 AI 모델이 얼마나 똑똑해졌는지와 그 주변 시스템이 컨텍스트, 도구, 메모리, 그리고 최신성(freshness)을 얼마나 형편없이 조정하는지 사이의 벌어지는 간극을 의미합니다. 이는 제대로 오케스트레이션(orchestration)되지 않은 파이프라인 내의 GPT급 모델이 왜 여전히 오래되고, 틀리거나, 검증 불가능한 답변을 내놓는지에 대한 이유를 설명합니다. 지능이 부족한 것이 아니라, 조정(coordination)이 부족한 것입니다.

이 주제가 시니어 엔지니어들 사이에서 폭발적인 관심을 받는 이유는, AgentCore Web Search가 하이퍼스케일러(hyperscaler)가 신선도(freshness), 거버넌스(governance), 그리고 도구 오케스트레이션(tool orchestration)을 하나의 _단일 관리형 프리미티브(single managed primitive)_로 출시한 첫 사례이기 때문입니다. 이제 더 이상 6개의 벤더를 하나하나 이어 붙일 필요가 없습니다. AWS에 따르면, 이 도구는 AgentCore Gateway 및 Memory와 직접 통합되므로, 검색 결과가 재쿼리(re-querying) 없이 세션 전반에 걸쳐 캐싱(cached), 출처 표기(attributed) 및 재사용될 수 있음을 의미합니다.

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

이 가이드의 나머지 부분에서 다룰 내용: 조정 격차(Coordination Gap)가 실제로 어디에 존재하는지를 설명하는 5계층 프레임워크, AgentCore Web Search가 특정 계층을 어떻게 메우는지, 실제 배포 패턴, 신뢰도를 조용히 파괴하는 실수들, 그리고 2027년까지 이 기술이 어디로 향할지에 대해 알아봅니다. 이것은 보도 자료가 아닌 시스템적 관점(systems view)입니다.

오래된 컨텍스트(stale context)를 가진 프런티어 모델(frontier model)은 지능적이지 않습니다. 그것은 어휘력이 뛰어난, 자신감 넘치는 거짓말쟁이일 뿐입니다. 신선도(freshness)는 기능(feature)이 아니라, 신뢰성 요구사항(reliability requirement)입니다.

AI 조정 격차의 5계층 (The Five Layers of the AI Coordination Gap)

제가 운영 환경에서 디버깅한 모든 실패한 에이전트는 다섯 가지 중 한 곳에서 실패했습니다. 모델 때문이 아닙니다. 모델을 둘러싼 조정(coordination) 때문입니다. AgentCore Web Search는 이 계층 중 세 곳을 직접적으로 다루며, 이것이 바로 이 기술이 단순한 검색 엔드포인트(search endpoint)보다 더 중요한 이유입니다. 프레임워크는 다음과 같습니다.

실시간 에이전트를 위한 5계층 조정 스택 (The Five-Layer Coordination Stack for Real-Time Agents)

  1

    **의도 계층 (Intent Layer) — 추론 모델 (Reasoning Model) (Bedrock / Claude / Nova)**

에이전트가 새로운 정보가 정말로 필요한지 여부를 결정합니다. 입력: 사용자 쿼리(user query) + 시스템 프롬프트(system prompt). 출력: 도구 호출(tool-call) 결정. 지연 시간 비용(Latency cost): 1회 추론 왕복(inference round-trip, 약 400–900ms). 대부분의 실패는 여기서 시작됩니다. 모델이 검색하지 말아야 할 때 검색하거나, 신뢰하지 말아야 할 때 메모리(memory)를 신뢰하는 경우입니다.

↓

  2
...

관리형 검색 (Managed retrieval). 입력: 검색 쿼리 문자열. 출력: 소스 URL이 포함된 순위가 매겨지고 정제된 웹 검색 결과. 이곳이 최신성 주입 지점 (freshness injection point)입니다. AWS가 속도 제한 (rate limiting), HTML 제거 (HTML stripping), 결과 순위 지정 (result ranking)을 처리하므로 모델은 가공되지 않은 마크업이 아닌 토큰을 받게 됩니다.

↓

  3
...

검색 결과는 세션 내에서 캐싱(cached)되고 속성(attributed)이 부여되므로, 에이전트가 동일한 사실을 5번씩 다시 쿼리하지 않습니다. 단기(세션) 및 장기(세션 간) 메모리는 비용과 지연 시간 (latency)을 모두 줄여줍니다. 이곳이 RAG와 실시간 검색 (live search)이 수렴하는 지점입니다.

↓

  4
...

누가, 어떤 자격 증명 (credentials)을 가지고, 무엇을 검색할 수 있는가, 그리고 그 결과의 출처를 밝힐 수 있는가? 기업용 서비스의 첫 번째 장애물입니다. 모든 검색 결과는 인용을 위한 소스 URL을 포함하며, 이는 금융, 법률, 의료 분야에서 타협할 수 없는 필수 사항입니다.

↓

  5
...

모든 도구 호출 (tool call), 모든 검색, 모든 토큰을 추적하십시오. 출력: 디버깅 가능한 스팬 (spans). 이것 없이는 '에이전트가 왜 그렇게 말했는가?'라는 질문에 답할 수 없으며, 이는 규제 대상 사용자를 위한 제품을 출시할 수 없음을 의미합니다.

이 시퀀스가 중요한 이유는 조정 격차 (Coordination Gap)가 레이어 내부가 아니라 레이어 사이에 나타나기 때문입니다. 메모리(Layer 3)가 없는 완벽한 모델(Layer 1)은 여전히 같은 내용을 다시 쿼리하고 스스로 모순된 말을 합니다.

레이어 1: 의도 레이어 (The Intent Layer) — 대부분의 에이전트가 이미 실패하는 지점

어떤 에이전트에서든 가장 어려운 결정은 '어떻게' 검색하느냐가 아니라, '검색할 것인가 말 것인가'입니다. 모든 것에 대해 검색하는 모델은 느리고 비용이 많이 듭니다. 아무것도 검색하지 않는 모델은 정보가 낙후되어 있습니다. Anthropic의 도구 사용 (tool-use) 연구에 따르면, 잘 조정된 도구 설명 (tool descriptions)은 불필요한 도구 호출을 두 자릿수 퍼센트만큼 줄여줍니다. AgentCore를 사용하면 Bedrock의 Claude든 Amazon Nova든 추론 모델 (reasoning model)이 이 결정을 내립니다. 여러분의 역할은 이를 제어하는 시스템 프롬프트 (system prompt)와 도구 스키마 (tool schema)를 설계하는 것입니다. 이것이 대부분의 팀이 완전히 간과하고 있는 핵심 레버 (lever)입니다.

검색 기능이 활성화된 에이전트(search-enabled agent)를 위해 수행할 수 있는 단 하나의 가장 강력한 레버리지(leverage) 변화는 모델을 교체하는 것이 아니라, 도구 설명(tool description)을 다시 작성하는 것입니다. 팀들은 모델에게 웹 검색이 정당화되는 시점(when)을 정확히 알려주는 것만으로도 도구 호출(tool-call) 볼륨과 그에 따른 지연 시간(latency)을 통상 30~50%까지 줄입니다.

Layer 2: 도구 계층 (The Tool Layer) — AgentCore 웹 검색이 대체하는 것

이것은 방금 범용화(commoditized)된 계층입니다. 이전에는 이를 직접 조립해야 했으며, 이는 그 누구의 예산 계획보다 더 많은 시간이 소요되었습니다. 이제는 관리형 호출(managed call)이 되었습니다. 여기서의 가치는 단순히 'AWS에 검색창이 있다'는 것이 아니라, 그 검색창이 기본적으로 신원(identity), 메모리(memory), 관찰 가능성(observability)과 연결되어 있다는 점에 있습니다. 이러한 통합이 바로 해자(moat)이며, DIY 스택(DIY stacks)이 엔지니어링 시간을 낭비하는 바로 그 지점입니다. 근본적인 검색 품질(retrieval quality) 또한 중요합니다. Hugging Face에서 추적하는 벤치마크와 같은 사례들은 결과 순위(result ranking)가 다운스트림 추론 정확도(downstream reasoning accuracy)를 얼마나 크게 결정짓는지 보여줍니다.

python — Bedrock AgentCore 웹 검색 도구 등록

AgentCore 에이전트에 관리형 웹 검색 도구를 등록합니다.

2026년 6월 AWS GA 발표 기준, 프로덕션 준비 완료

from bedrock_agentcore import Agent, tools

agent = Agent(
model='anthropic.claude-sonnet-4',

퍼스트 파티 관리형 웹 검색 도구를 부착합니다.

tools=[tools.WebSearch(
max_results=5, # 컨텍스트로 다시 전달되는 토큰 제한
recency_days=30, # 최신 소스에 가중치 부여
return_sources=True # 인용(citation) / 거버넌스(governance)를 위해 필수
)],
memory='agentcore-session' # 결과 캐싱, 재쿼리 방지
)

이제 모델은 추론 과정에서 언제 검색을 호출할지 결정합니다.

각 결과는 소스 URL을 포함하므로 -> 귀속 가능하고(attributable), 감사 가능합니다(auditable).

response = agent.run('이번 달 EU AI Act 집행에서 무엇이 바뀌었나요?')
for citation in response.sources:
print(citation.url) # 모든 주장을 실시간 소스에 근거하게 함

Layer 3: 메모리 계층 (The Memory Layer) — 실시간 검색과 RAG가 만나는 지점

이곳은 모두가 과소평가하는 계층입니다. 메모리가 없다면, 다단계 질문을 조사하는 에이전트는 동일한 사실을 반복해서 검색하고, 턴(turn) 사이에서 스스로 모순된 말을 하며, 그 과정에서 비용을 낭비하게 됩니다. AgentCore Memory는 세션 내에서 검색 결과(search results)를 캐싱(caching)하고, 세션 전반에 걸쳐 중요한 컨텍스트(context)를 유지합니다. 또한 이곳은 기존의 RAG 대 검색(RAG-vs-search) 논쟁이 해소되는 지점이기도 합니다. 독점적인 지식에는 Pinecone 벡터 스토어(vector store)를 사용하고, 실시간의 공개된 세상에는 AgentCore Web Search를 사용하면 됩니다. 이들은 경쟁 관계가 아니라 서로 다른 신선도 계층(freshness tiers)이며, 이 둘을 혼동하는 것은 제가 팀들에게서 보는 가장 비용이 많이 드는 아키텍처 설계 실수 중 하나입니다.

시각화된 5계층 조정 스택(Coordination Stack) — AgentCore Web Search는 도구(Tool), 메모리(Memory), 거버넌스(Governance) 계층을 하나의 관리형 프리미티브(managed primitive)로 통합합니다.

Layer 4: 거버넌스 계층 (The Governance Layer) — 진정한 엔터프라이즈 잠금 해제

어떤 데모에서도 보여주지 않는 사실이 있습니다. 포춘 500대 기업에서 계약을 가로막는 것은 모델의 품질인 경우가 드뭅니다. 조달(procurement)을 실제로 지연시키는 질문은 "이 답변이 어디에서 왔는지 증명할 수 있는가?"와 "에이전트가 검색해서는 안 될 것을 검색하지 못하게 막을 수 있는가?"입니다. AgentCore Identity는 자격 증명 범위(credential-scoped)의 액세스를 처리하며, 모든 Web Search 결과는 소스 URL을 반환합니다. 이러한 단일한 설계 선택 — 의무적인 출처 표기(mandatory attribution) — 가 EU AI Act와 같은 프레임워크가 강화됨에 따라 규제 산업에서 이를 배포 가능하게 만드는 핵심입니다. 이것이 왜 중요한지에 대해 엔터프라이즈 AI 배포(enterprise AI deployments)에서 더 자세히 알아보세요.

엔터프라이즈 환경에서 질문은 결코 "답변이 똑똑한가?"가 아닙니다. "그 답변이 어디에서 왔는지 증명할 수 있는가?"입니다. 출처 표기(Attribution)가 핵심 기능입니다. 그 외의 모든 것은 기본 요건(table stakes)일 뿐입니다.

Layer 5: 관측 가능성 계층 (The Observability Layer) — 이것 없이는 제품을 출시할 수 없는 이유

에이전트가 왜 검색을 했는지, 무엇을 찾아냈는지, 그리고 그것이 어떻게 답변을 형성했는지 추적할 수 없다면 디버깅(debug)할 수 없습니다. 그리고 감사(audit)를 통과하는 것은 확실히 불가능합니다. AgentCore Observability는 CloudWatch로 스팬(spans)을 방출하여 사후에 어떤 결정이든 재구성할 수 있도록 합니다. 대부분의 팀은 잘못된 답변이 고객에게 전달된 이후에야 이것이 필요하다는 사실을 깨닫습니다. 저는 그러한 교훈이 팀의 신뢰성을 회복 불가능한 수준으로 수개월 동안 깎아먹는 것을 목격해 왔습니다. 첫날부터 이를 구축하십시오. 프로덕션 AI 에이전트(production AI agents)에 대한 저희의 분석 내용을 확인해 보세요.

[
▶