원문은 twarx.com에서 처음 게시되었습니다 - 전체 대화형 버전은 그곳에서 읽을 수 있습니다.

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

AI 기술은 계속해서 잘못된 것을 최적화하고 있습니다. 대부분의 AI 워크플로우(workflows)는 모델 자체를 튜닝하지만, 실패의 원인은 거의 항상 모델과 세상 사이의 연결 조직(connective tissue) — 즉, 지능이 아니라 핸드오프(handoffs, 전달 과정)에 있습니다. 2026년 6월에 출시된 Amazon Bedrock AgentCore의 웹 검색(Web Search) 기능은 이러한 불일치를 무시할 수 없게 만들며, 모든 진지한 팀이 자신들의 에이전트(agents)가 실제로 어디에서 고장 나는지를 직시하게 만듭니다.

2026년 6월 18일, AWS는 Amazon Bedrock AgentCore의 웹 검색(Web Search on Amazon Bedrock AgentCore)을 출시했습니다. 이는 에이전트가 내장된 신원 확인(identity), 스로틀링(throttling), 결과 그라운딩(result grounding) 기능을 갖추고 실시간 웹을 쿼리할 수 있게 해주는 관리형 도구(managed tool)입니다. 이것이 지금 중요한 이유는 실제 운영되는 AI 기술에서 에이전트의 제약 조건은 모델의 크기가 아니라 검색의 신선도(retrieval freshness)이기 때문입니다.

이 글을 마칠 때쯤 여러분은 실시간 웹 액세스가 무엇을 망가뜨리고, 무엇을 해결하며, 어떻게 _AI 조정 격차(The AI Coordination Gap)_를 중심으로 아키텍처를 설계해야 하는지 정확히 이해하게 될 것입니다.

새로운 AgentCore 웹 검색 도구는 모델과 오픈 웹(open web) 사이에 관리형 실시간 검색(live-retrieval) 레이어를 삽입합니다. 이는 바로 대부분의 에이전트가 실패하는 지점입니다. 출처

개요: AgentCore 웹 검색의 실체 — 그리고 왜 지금 출시되었는가

Amazon Bedrock AgentCore는 프로덕션 에이전트(production agents)를 위한 AWS의 런타임(runtime) 및 툴링(tooling) 레이어이며, 파운데이션 모델(foundation models)을 둘러싼 운영상의 배관(operational plumbing) 역할을 합니다. 2026년 6월에 추가된 웹 검색 (Web Search) 기능은 기존의 치명적인 공백을 메워줍니다. 지금까지 Bedrock의 에이전트들은 자체적인 검색 스택(retrieval stack)을 직접 구축하거나, 직접 HTML을 스크래핑하고, 속도 제한(rate limits), robots.txt 준수, API 키 관리 등을 수동으로 처리하지 않는 한, 학습 데이터 차단 시점(training cutoff)에 갇혀 있는 상태와 다름없었습니다. 저는 많은 팀이 바로 이러한 배관 작업에 3주간의 스프린트(sprint)를 허비하며, 정작 비즈니스에서 실제로 필요로 하는 결과물은 아무것도 내놓지 못하는 것을 목격해 왔습니다.

새로운 도구는 관리형 기능(managed capability)으로 제공됩니다. 에이전트에게 권한을 부여하면, AgentCore가 내장된 자격 증명 및 게이트웨이 (credential and gateway) 방식의 격리를 통해 신원(identity)을 처리하고, 요청 속도를 조절하며, 순위가 매겨지고 중복이 제거된 결과를 반환하고, 구조화된 스니펫(structured snippets)을 모델 컨텍스트(model context)로 전달하여 근거(grounding)를 제공합니다. 이는 개인용 벡터 스토어(vector store)가 아닌 개방된 인터넷을 대상으로 하는 관리형 RAG (Retrieval-Augmented Generation, 검색 증강 생성)입니다. 이것이 핵심 제안이며, 매우 훌륭한 제안입니다.

시니어 엔지니어들이 주목해야 할 이유는 다음과 같습니다. 에이전트 시스템(agentic systems)에서 어려운 부분은 검색 쿼리(search query) 자체가 아니었습니다. 진짜 어려운 것은 조율 (coordination) 이었습니다. 즉, 누가 웹을 호출할 수 있는지, 호출이 타임아웃(timeout)되면 어떻게 되는지, 오래된 결과와 최신 결과를 어떻게 조정하는지, 그리고 12단계의 계획이 단 한 번의 잘못된 검색으로 인해 어떻게 무너지는지 등을 다루는 문제입니다. AgentCore 웹 검색은 이러한 경계(boundary)를 표준화하여 여러분이 이를 직접 구현(hand-rolling)하지 않도록 해줍니다. 이것이 바로 2026년에 실제로 의미 있는 AI 기술의 변화입니다.

Coined Framework (조어된 프레임워크)

AI 조율 격차 (The AI Coordination Gap)

AI 조율 격차(AI Coordination Gap)는 단일 모델이나 도구 내부가 아니라, 검색(retrieval), 계획(planning), 메모리(memory), 신원(identity), 복구(recovery)와 같은 요소들 사이의 인계(handoffs) 과정에서 발생하는 시스템적 신뢰성 손실을 의미합니다. 이는 개별적으로는 매우 뛰어난 구성 요소들로 구축된 워크플로우가 왜 전체 과정(end-to-end)에서 실패하는지를 설명하는 용어입니다.

수학은 냉혹합니다. 각 단계의 신뢰도가 97%인 6단계 파이프라인(pipeline)의 전체 과정(end-to-end) 신뢰도는 단 83% (0.97^6)에 불과합니다. 여기에 큐레이션된 인덱스 (curated index)보다 본질적으로 더 노이즈가 많은 실시간 웹 검색 (live web search)을 추가하면, 가장 취약한 연결 고리는 통제 범위를 벗어나게 됩니다. 대부분의 팀은 이해관계자들에게 수치를 약속한 후, 실제 운영(production) 단계에 이르러서야 이 사실을 깨닫게 됩니다. NIST AI Risk Management Framework는 바로 이러한 종류의 복합적인 시스템적 위험 (systemic risk)을 공식화하고 있습니다.

83%
단계별 97% 신뢰도를 가진 6단계 파이프라인의 전체 과정(end-to-end) 신뢰도
[arXiv, 2023](https://arxiv.org/abs/2308.11432)
...

이 글은 AWS의 발표를 시작점으로 삼아, 이 발표가 강제하는 시스템적 질문을 깊이 있게 다룹니다. 즉, 에이전트 (agent)가 실시간 웹에 접속할 수 있게 되었을 때, 어디에서 조정 (coordination)이 깨지며, 이를 어떻게 엔지니어링을 통해 차단할 것인가에 대한 질문입니다. 우리는 'AI 조정 격차 (The AI Coordination Gap)'를 다섯 가지 명명된 계층 (layers)으로 나누어 살펴보고, AgentCore에서 각 계층이 실제로 어떻게 작동하는지 보여줄 것이며, 실제 배포 사례를 살펴본 뒤, 시니어 엔지니어들이 실제로 던지는 7가지 질문으로 마무리할 것입니다.

AI 에이전트로 승리하는 기업은 가장 큰 모델을 가진 기업이 아닙니다. 그들은 지능 (intelligence)이 아닌 조정 (coordination)을 핵심적인 엔지니어링 문제로 취급한 기업들입니다.

웹 기능이 탑재된 에이전트에 대해 대부분의 사람들이 오해하는 것

지배적인 가정은 에이전트에게 웹 접속 권한을 주면 더 똑똑해질 것이라는 점입니다. 그렇지 않습니다. 그것은 에이전트를 더 '최신 상태 (fresher)'로 만들 뿐입니다. 그리고 조정 (coordination)이 동반되지 않은 최신성은 자산이 아니라 부채 (liability)입니다.

대부분의 팀이 값비싼 대가를 치르고 배우게 되는 직관에 반하는 진실은 다음과 같습니다. 실시간 웹을 탐색할 수 있는 에이전트는 큐레이션된 인덱스를 가진 에이전트보다 더 자주 실패합니다. 왜냐하면 개방된 웹은 적대적이고, 일관성이 없으며, 경계가 없기 때문입니다. 여러분은 깨끗하고 관리된 코퍼스 (corpus)를 전체 인터넷의 노이즈 플로어 (noise floor)와 맞바꾼 것입니다. 승리는 여러분의 조정 계층 (coordination layer)이 그 노이즈를 흡수할 수 있을 만큼 충분히 강력할 때만 실현됩니다. 저는 환각 (hallucinations)이 줄어들 것을 기대하며 웹 검색을 추가했다가, 정확도 지표가 떨어지는 것을 지켜보며 왜 그런지 몰라 한 달 동안 혼란스러워하는 팀들을 보아왔습니다.

5만 개의 문서로 큐레이션된 인덱스에 기반한 고정된 에이전트(frozen agent)는 일반적으로 사실 정확도 측면에서 웹 기능이 활성화된 에이전트보다 우수합니다. 하지만 도메인 데이터가 30일보다 더 빠르게 노후화되는 시점이 오면 이야기가 달라집니다. 웹 검색은 '정확도(accuracy)' 도구가 아니라 '최신성(freshness)' 도구입니다. 올바른 이유를 가지고 이를 선택하십시오.

이러한 기술을 실제로 배포하고 있는 실무자들 — OpenAI, Google DeepMind, Anthropic의 엔지니어들 — 은 일관되게 동일한 패턴을 보고합니다. 모델이 답변을 환각(hallucination)하는 경우는 드뭅니다. 대신 '검색된 증거(retrieved evidence)'를 잘못 다룹니다. 2019년에 캐시된 페이지를 최신 정보로 인용하거나, 정답이 이미 컨텍스트(context)에 있음에도 웹 도구를 호출합니다. 혹은 루프(loop)에 빠지기도 합니다. 이 모든 것은 각각 '조율 실패(coordination failures)'입니다. 초기 RAG 논문 이후의 검색 증강 시스템(retrieval-augmented systems)에 관한 연구들은 모델의 원시 능력(raw model capability)이 아닌, 그라운딩(grounding) 품질이 사실적 신뢰성을 결정한다는 점을 지속적으로 강조하고 있습니다.

오류의 누적: 단계별 신뢰도가 97%라 할지라도, 단계가 늘어남에 따라 엔드 투 엔드(end-to-end) 정확도는 붕괴합니다. 시각화된 AI 조율 격차(AI Coordination Gap). 출처

AI 조율 격차의 5가지 계층

제가 운영 환경에서 디버깅한 모든 웹 활성화 에이전트의 실패는 다섯 가지 조율 계층 중 하나에 해당합니다. 이 계층들의 이름을 정의하고 측정 도구(instrument)를 갖춘다면, 이 격차는 미스터리한 현상이 아니라 엔지니어링 가능한 영역이 됩니다.

명명된 프레임워크

AI 조율 격차 (The AI Coordination Gap)

AI 조율 격차는 모델, 도구, 메모리, 그리고 정체성(identity) 사이의 모든 핸드오프(handoff) 과정에서 지불해야 하는 신뢰성 세금입니다. AgentCore 웹 검색은 이를 제거하는 것이 아니라, 마침내 관찰할 수 있는 관리된 경계(managed boundary)로 재배치합니다.

계층 1 — 검색 경계 (The Retrieval Boundary)

이곳은 모델이 검색을 수행할지 여부(whether), 무엇을 쿼리할지(what), 그리고 결과로 돌아온 내용을 어떻게 해석할지를 결정하는 지점입니다. AgentCore Web Search는 호출 방식을 표준화하지만, 이를 호출할지 여부에 대한 결정은 여전히 사용자의 프롬프트(prompt)나 플래너(planner)에 달려 있습니다. 전형적인 실패 사례는 다음과 같습니다. 모델이 이미 컨텍스트(context)에 있는 답변임에도 불구하고 검색을 수행하여 지연 시간(latency)과 토큰(tokens)을 낭비하거나, 검색이 필요한 상황임에도 검색하지 않고 오래된 파라미터 메모리(parametric memory)를 바탕으로 확신에 차서 잘못된 답변을 내놓는 경우입니다. 두 가지 실패 모두 각기 다른 방식으로 비용을 발생시킵니다.

실제로 AgentCore에서는 모델이 정확히 언제 이 도구를 사용해야 하는지 알려주는 설명을 통해 도구를 구성합니다. '정보를 위해 웹을 검색하세요'와 같은 모호한 설명은 과도한 호출을 유발합니다. 반면, '당신의 지식 컷오프(knowledge cutoff) 이후의 날짜를 가진 사실이나 가격, 날씨, 속보와 같은 실시간 데이터에 대해서만 검색하세요'와 같이 구체적인 설명은 불필요한 호출을 극적으로 줄여줍니다. 이 한 번의 수정은 비용이 들지 않습니다. 절대 생략하지 마세요.

Python — AgentCore Web Search 도구 등록

엄격한 호출 정책을 사용하여 관리형 웹 검색 도구를 등록합니다.

from bedrock_agentcore import AgentCoreClient

client = AgentCoreClient(region='us-east-1')

web_search = client.register_tool(
name='web_search',

엄격한 설명 = 불필요한 호출 감소 = 비용 및 지연 시간 감소

description=(
'실시간 데이터(가격, 날씨, 속보) 또는 학습 컷오프 이후의 날짜를 가진 사실에 대해서만 '
'실시간 웹을 검색하세요. '
'답변이 이미 대화 컨텍스트에 있다면 호출하지 마세요.'
),
config={
'max_results': 5, # 다운스트림의 토큰 팽창을 제어하기 위한 제한
'recency_days': 30, # 최신 결과에 가중치 부여
'dedupe': True # AgentCore가 거의 중복되는 도메인을 제거함
}
)

계층 2 — ID 및 액세스 경계 (The Identity & Access Boundary)

웹에 접속할 때 에이전트는 '누구로서' 행동하는가? AgentCore의 내장된 ID 격리 (Identity Isolation) 기능은 각 에이전트 호출이 범위가 제한된 자격 증명 (Scoped Credentials)을 지닌다는 것을 의미합니다. 즉, 에이전트는 임의의 엔드포인트로 데이터를 유출할 수 없으며, 검색 호출은 주체(Principal)별로 속도 제한 (Throttled)이 적용됩니다. 이는 기업용 AI (Enterprise AI) 보안 팀이 가장 중요하게 생각하는 계층이며, 자체 제작한 설정들이 보안 사고를 일으키는 지점이기도 합니다. 직접 만든 스크래퍼(Scrapers)들은 공유 키를 사용하여 실행됩니다. 저는 그런 방식을 규제 대상 환경에 배포하는 것을 권장하지 않습니다. AgentCore는 도구 경계 (Tool Boundary)에서 최소 권한 원칙 (Least-privilege)을 강제하며, 이는 결코 작은 일이 아닙니다. LLM 애플리케이션을 위한 OWASP Top 10은 안전하지 않은 도구 액세스 및 과도한 에이전시 (Excessive Agency)를 주요 위험으로 나열하고 있으며, 이 계층이 바로 그 두 가지를 해결하는 곳입니다.

계층 3 — 메모리 조정 경계 (The Memory Reconciliation Boundary)

실시간 웹 결과는 에이전트가 이미 알고 있는 정보, 즉 시스템 프롬프트 (System Prompt), RAG (Retrieval-Augmented Generation) 저장소, 그리고 이전 대화 내용과 대조하여 조정되어야 합니다. 실패 모드는 다음과 같습니다: 에이전트가 최신성 중재 (Recency Arbitration) 없이 신선한 검색 결과보다 오래된 캐시된 페이지를 신뢰하거나, 그 반대의 경우입니다. 이는 2026년 에이전트 스택에서 가장 설계가 미흡한 단일 계층입니다. 추측이 아니라, 저는 수많은 프로덕션 코드베이스를 검토해 왔으며, 이 경계에는 명시적인 로직이 거의 항상 누락되어 있습니다.

명시적인 최신성 가중치 지침을 추가하십시오: '웹 결과가 이전 컨텍스트와 충돌할 경우, 30일 이내의 날짜가 지정된 결과를 우선시하고 발행 날짜를 인용하십시오.' 제가 자문을 제공한 팀들의 내부 테스트 결과, 이 한 줄의 지침만으로 충돌하는 소스 오류를 약 절반 가까이 줄일 수 있었습니다.

계층 4 — 오케스트레이션 경계 (The Orchestration Boundary)

multi-agent systems (멀티 에이전트 시스템)에서 웹 검색은 단일 호출인 경우가 드뭅니다. 이는 그래프 내의 하나의 노드(node)입니다. 누가 이를 트리거(trigger)할까요? 결과가 빈 값으로 돌아올 때 다운스트림 플래너(downstream planner)는 무엇을 할까요? AgentCore Web Search는 LangGraph, AutoGen, LangChain에 도구 노드(tool node)로서 깔끔하게 삽입될 수 있지만, 재시도(retries), 폴백(fallbacks), 타임아웃(timeouts)과 같은 orchestration (오케스트레이션) 계약은 사용자가 직접 정의해야 합니다. AWS가 대신 해주지 않습니다.

계층 5 — 복구 경계 (The Recovery Boundary)