에이전트에게 실시간 인터넷 접속 권한을 부여하는 AI 기술: AgentCore 웹 검색 빌더 가이드

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

최종 업데이트: 2026년 2월 18일

대부분의 AI 기술 워크플로우는 완전히 잘못된 문제를 해결하고 있습니다. 모델의 품질에만 집착하는 사이, 정작 배포되는 에이전트들은 학습 데이터(training data)가 동결된 날 이후로 존재하지 않게 된 세상에 대해 자신 있게 답변하고 있습니다. 해결책은 더 똑똑한 모델이 아닙니다. AI 기술에 현재 시점에 대한 실시간 접속 권한을 부여하는 것이며, AWS에서 제공하는 관리형 도구가 이제 프로덕션 팀들에게 이를 실용적으로 만들어 주었습니다.

AWS는 방금 Amazon Bedrock AgentCore의 웹 검색(Web Search on Amazon Bedrock AgentCore) 기능을 출시했습니다. 이는 에이전트가 기존의 프로덕션 Bedrock 배포를 구동하는 것과 동일한 런타임(runtime), 게이트웨이(gateway), 그리고 ID 계층(identity layer) 내에서 실시간 인터넷을 쿼리할 수 있게 해주는 관리형 도구입니다. 실시간 검색(real-time retrieval)이 더 이상 편법(hack)이 아닌 인프라(infrastructure)가 되었기 때문에 이는 지금 매우 중요합니다.

이 가이드의 직관에 반하는 논지: 웹 검색은 에이전트를 더 똑똑하게 만드는 것이 아니라, 에이전트를 _최신 상태(current)_로 만듭니다. 그리고 '최신성'은 '지능'과는 완전히 다른 축입니다. 라우팅(routing)이 잘못된 최신 에이전트는 정보가 뒤처진(stale) 에이전트보다 더 나쁠 수 있습니다.

이 글을 다 읽을 때쯤이면 여러분은 아키텍처(architecture), 실패 모드(failure modes), 비용 — 대규모 환경에서 검색 호출당 약 $0.002–$0.008 수준의 구체적인 비용 범위 포함 — 그리고 AgentCore 웹 검색을 프로덕션 멀티 에이전트 시스템(multi-agent system)에 정확히 연결하는 방법을 알게 될 것입니다.

Amazon Bedrock AgentCore 웹 검색은 실시간 인터넷 결과값을 에이전트 런타임(agent runtime)에 직접 주입하여, 동결된 학습 데이터와 현재 시점 사이의 간극을 메웁니다.

Amazon Bedrock AgentCore 웹 검색은 실제로 무엇을 바꾸는가?

당신을 괴롭힐 수도 있는 숫자가 하나 있습니다. 각 단계의 신뢰도가 97%인 6단계 에이전트 파이프라인(agentic pipeline)의 경우, 엔드 투 엔드(end-to-end) 신뢰도는 단 83%에 불과합니다. 대부분의 팀은 제품을 이미 출시한 후에야, 그리고 고객이 8개월 전에 사임한 CEO를 인용하는 에이전트의 스크린샷을 찍어 보낸 후에야 이 사실을 깨닫게 됩니다.

Amazon Bedrock AgentCore는 프로덕션 환경의 AI 에이전트를 배포하기 위한 AWS의 프레임워크 불가지론적(framework-agnostic) 런타임입니다. 이미 지속적인 컨텍스트를 위한 메모리(Memory) 서비스가 출시되었고, 도구 노출을 위한 게이트웨이(Gateway)가 추가되었습니다. 에이전트별 권한 범위를 지정하기 위한 ID(Identity) 기능도 도입되었습니다. 코드 인터프리터(Code Interpreter)는 샌드박스 실행을 처리하며, 브라우저(Browser) 도구는 전체 페이지를 구동합니다. 이번에 새로 추가된 웹 검색(Web Search) 기능은 LangGraph, CrewAI, Strands, 또는 순수 모델 루프(raw model loop)로 구축된 모든 에이전트가 스크래퍼(scraper), 프록시 풀(proxy pool), 또는 속도 제한 큐(rate-limit queue)를 직접 운영하지 않고도 실시간 웹에서 최신 정보와 인용 근거가 포함된 정보를 가져올 수 있는 능력을 부여합니다.

그렇다면 실제로 무엇이 바뀌는 걸까요? 핵심 가치는 단순히 "에이전트가 이제 구글링을 할 수 있다"는 것이 아닙니다. 작년에 저는 4인 규모의 팀이 이미 한 번 출시했던 웹 검색 파이프라인(robots.txt 준수, 콘텐츠 추출, 랭킹, 최신성 점수 산정, 남용 방지 등)을 재구축하는 데 한 분기 전체를 허비하는 것을 지켜보았습니다. 결국 그들은 첫 번째 시도를 실패하게 만들었던 것과 동일한 프록시 풀 속도 제한 문제에 다시 부딪혔습니다. AgentCore 웹 검색은 바로 그러한 운영상의 악몽을 기존 IAM 경계 내에 존재하는 관리형 프리미티브(managed primitive)로 흡수합니다. 이미 이 작업에 한 분기를 소모한 팀에게 이는 다시는 쓰지 않아도 될 약 8만 달러에서 20만 달러 상당의 완전 비용 포함(fully-loaded) 엔지니어링 시간을 절약해 주는 것입니다.

웹 검색의 어려운 점은 검색 그 자체가 아니었습니다. 규모에 맞게 규정을 준수하면서도 저지연(low-latency)을 유지하고 중복이 제거된 검색 파이프라인을 운영하는 것이었습니다. AgentCore 웹 검색은 약 6~9개월 분량의 플랫폼 엔지니어링 작업을 단 한 번의 도구 호출(tool invocation)로 바꿔 놓습니다.

하지만 — 그리고 이것이 이 글 전체의 논지입니다 — 새로운 데이터를 추가하는 것이 더 깊은 문제를 해결해주지는 않습니다. 오히려 그 문제를 드러낼 뿐입니다. 에이전트가 이제 실시간 정보를 가져올 수 있게 되면, 병목 현상은 "모델이 무엇을 알고 있는가"에서 "끊임없이 변화하는 현실을 중심으로 내 에이전트들이 어떻게 협업(coordinate)하는가"로 이동합니다. 그것은 전혀 다른, 더 어려운 문제입니다. 저는 이를 AI 조정 격차 (AI Coordination Gap)라고 부릅니다.

정립된 프레임워크

AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차 (AI Coordination Gap)란, 개별적으로 역량을 갖춘 AI 에이전트들이 공유된, 빠르게 변화하는 상태(state)를 중심으로 자신의 행동을 조율(reconcile), 순차화(sequence), 또는 동기화(synchronize)하지 못할 때 발생하는 실패 모드(failure mode)를 의미합니다. 이는 더 뛰어난 모델이 나와도 결코 해결할 수 없는 시스템적 문제를 지칭합니다. 왜냐하면 이것은 지능의 문제가 아니라 오케스트레이션 (orchestration)의 문제이기 때문입니다. Twarx의 설립자 Rushil Shah가 명명함 (Twarx 프레임워크, 2026).

이 가이드는 AI 조정 격차를 명명된 6개의 계층으로 나누고, AgentCore 웹 검색이 각 계층에 어떻게 연결되는지 보여주며, 실제 배포 사례를 살펴보고, 운영 시스템을 망가뜨리는 실수들을 폭로하며, 시니어 엔지니어와 AI 리더들을 위한 솔직한 FAQ로 마무리합니다.

83%
단계별 정확도 97%인 6단계 파이프라인의 엔드 투 엔드(End-to-end) 신뢰도
[arXiv, 2023](https://arxiv.org/abs/2308.00352)
...

왜 실시간 검색(Real-Time Retrieval)이 이제 필수 요건(Table Stakes)인가?

"정체된(stale)" 데이터가 어떤 비용을 초래하는지 솔직하게 말해봅시다. 고정된 모델은 가격, 재고, 규제, 스포츠, 시장, 속보, 경쟁사 포지셔닝, 보안 권고 사항과 같이 변화가 빠른 도메인에 배포되는 순간 부채(liability)가 됩니다. 모델은 자신이 틀렸다는 사실을 알지 못합니다. 모델은 자신감 있고 유창하며 그럴듯한 답변을 환각(hallucination)할 것이고, 사용자는 그것을 믿게 될 것입니다. Google Research의 검색 근거 설정(retrieval grounding)에 관한 연구는 파라미터 기반 생성(parametric-only generation)에 비해 근거를 기반으로 한 답변이 환각률을 실질적으로 낮춘다는 것을 일관되게 보여줍니다.

자신이 무엇을 모르는지 모르는 모델은 지식 시스템이 아닙니다. 그것은 훌륭한 문법을 갖춘, 자신감 넘치는 부채일 뿐입니다.

이것이 바로 검색 증강 생성 (Retrieval-Augmented Generation (RAG))이 기업용 패턴의 주류가 된 정확한 이유입니다. 하지만 전통적인 RAG는 사용자의 인덱싱된 코퍼스(corpus), 즉 Pinecone과 같은 벡터 데이터베이스 (vector database)에 이미 임베딩(embedding)해 둔 문서로부터 정보를 검색합니다. 내부 지식을 다루는 데는 탁월합니다. 하지만 개방형 웹 (open web)에는 무용지물이며, 인덱싱 작업이 현실을 따라가지 못하는 순간 정보는 구식이 되어버립니다. 이 패턴이 처음이라면, RAG와 벡터 데이터베이스에 관한 입문서에서 인덱싱의 트레이드오프 (trade-offs)를 심도 있게 다루고 있습니다.

AgentCore Web Search는 그 문제의 절반인 개방형 웹 문제를 해결합니다. 이제 에이전트는 하이브리드 검색 (hybrid retrieval)을 수행할 수 있습니다. 즉, 독점적 지식을 위한 프라이빗 RAG (private RAG)와 현재 시점의 정보를 위한 라이브 웹 검색 (live web search)을 병행하는 것입니다. 이러한 조합이야말로 프로덕션 환경에서 에이전트를 진정으로 신뢰할 수 있게 만드는 요소입니다. 더 똑똑해지는 것이 아니라, 신뢰할 수 있게 되는 것입니다. 이는 전혀 다른 문제입니다.

웹 검색이 에이전트를 더 똑똑하게 만드는 것은 아닙니다. 웹 검색은 에이전트를 최신 상태로 만듭니다. 그리고 '최신성'은 완전히 다른 차원의 문제입니다. 라우팅 (routing)이 잘못된 최신 에이전트는 예측 불가능하게 실패하며, 이는 일관되게 실패하는 구식 에이전트보다 더 나쁩니다.

— Rushil Shah, Twarx 설립자

AgentCore Web Search가 프로덕션 에이전트 루프 (Agent Loop)를 통해 흐르는 방식

  1

    **사용자 질의 (User Query) → AgentCore 런타임 (Runtime)**

요청이 관리형 런타임 (managed runtime)으로 들어옵니다. 어떤 도구(tool)가 실행되기 전에 신원(Identity)과 IAM 범위(scope)가 확인됩니다. 지연 시간 예산(Latency budget)이 설정됩니다 (~통상적으로 200ms 미만의 오버헤드).

↓

  2
...

플래닝 에이전트 (planning agent)가 질의에 새로운 데이터가 필요한지 결정합니다. 필요하다면 웹 검색 (Web Search) 도구로 라우팅합니다. 내부 정보만으로 충분하다면 대신 프라이빗 RAG로 라우팅합니다.

↓

  3
...

관리형 검색 (Managed retrieval): 규정을 준수하는 크롤링 (crawling), 랭킹 (ranking), 콘텐츠 추출 (content extraction) 및 중복 제거 (deduplication)가 서버 측에서 수행됩니다. 소스 URL과 타임스탬프가 포함된 순위가 매겨진 구절(passages)을 반환합니다.

↓

  4
...

모델은 라이브 구절과 프라이빗 RAG 컨텍스트 (context)를 융합하고, 인용 (citations)을 첨부하며, 최신성 여부를 표시합니다. '인용이 없으면 주장도 없다'는 규칙이 강제됩니다.

↓

  5
...

결과(Result), 출처(sources), 그리고 도구 지연 시간(tool latency)이 기록됩니다. 메모리(Memory)는 턴(turn) 간에 문맥(context)을 유지합니다. 추적(Traces) 데이터는 감사(audit) 및 드리프트 탐지(drift detection)를 위해 CloudWatch로 내보내집니다.

이 시퀀스(sequence)는 매우 중요합니다. 왜냐하면 2단계에서의 계획 결정(planning decision) — 검색(search)을 할 것인가, RAG를 사용할 것인가, 아니면 둘 다 하지 않을 것인가 — 이 지점이 대부분의 조정 실패(coordination failures)가 발생하는 곳이기 때문입니다.

하이브리드 검색(Hybrid retrieval) — 프라이빗 RAG(private RAG)와 AgentCore 웹 검색(AgentCore Web Search)의 결합 — 은 프로덕션 에이전트가 자체 데이터(proprietary-aware)와 최신 정보(present-aware)를 모두 인지할 수 있게 만드는 아키텍처(architecture)입니다.

AI 조정 격차(AI Coordination Gap)의 6가지 레이어는 무엇인가?

프레임워크는 다음과 같습니다. AI 조정 격차(AI Coordination Gap)는 단일 문제가 아니라, 서로 겹쳐져 있는 6가지의 실패 표면(failure surfaces)입니다. 실시간 웹 검색을 추가하는 것은 이 모든 레이어에 영향을 미칩니다.

레이어 1: 최신성 레이어 (The Freshness Layer)

이것은 AgentCore 웹 검색이 직접적으로 해결하는 레이어입니다. 이 레이어가 답하는 질문은 다음과 같습니다: 이 정보는 최신인가?
실패 모드(failure mode)는 정보의 노후화(staleness)입니다. 즉, 에이전트가 폐기된 API, 오래된 가격, 혹은 해임된 임원을 확신을 가지고 주장하는 경우입니다. 웹 검색은 타임스탬프(timestamped)가 찍히고 순위가 매겨진 구절(passages)을 반환하므로, 합성 에이전트(synthesis agent)는 쿼리가 시간에 민감할 때 최신 정보를 우선시할 수 있습니다.

함정: 모든 쿼리에 최신 데이터가 필요한 것은 아니며, 검색이 필요하지 않은 상황에서 검색을 수행하면 지연 시간(latency)과 비용이 추가됩니다. 최신성 레이어는 라우팅 결정(routing decision)을 요구하며, 이는 문제를 레이어 2로 격상시킵니다.

웹 기능이 활성화된 에이전트에서 가장 영향력이 큰 단일 결정은 '검색/비검색 라우터(search/no-search router)'입니다. 이 결정이 틀리면 오래된 답변을 제공하거나(검색 부족), 토큰 및 지연 시간 예산의 3~5배를 낭비하게 됩니다(과잉 검색). 이 결정은 프롬프트(prompt) 속에 묻혀 있어서는 안 되며, 전용 계획 노드(planning node)에 위치해야 합니다.

레이어 2: 라우팅 레이어 (The Routing Layer)

이곳은 오케스트레이션 브레인 (orchestration brain)입니다. 어떤 도구를 사용할 것인가? 어떤 에이전트를 사용할 것인가? 웹 검색 (web search), 프라이빗 RAG (private RAG), 코드 인터프리터 (code interpreter), 아니면 그냥 직접 답변할 것인가? LangGraph에서는 이것이 상태 그래프 (state graph) 내의 조건부 엣지 (conditional edge)입니다. CrewAI에서는 매니저 에이전트 (manager agent)입니다. Anthropic'의 도구 사용 (tool-use) 패턴에서는 모델의 도구 선택 (tool selection)입니다. 이러한 결정 노드 (decision nodes)를 구축하는 방법에 대해서는 우리의 LangGraph routing patterns 가이드에서 더 자세히 다룹니다.

라우팅 레이어 (routing layer)는 AI 조정 격차 (AI Coordination Gap)가 가장 크게 발생하는 지점입니다. 추론 (reasoning) 능력이 뛰어난 모델이라도 언제 행동할지 결정하는 데에는 형편없을 수 있습니다. 제가 운영 환경에서 디버깅한 대부분의 조정 버그 (coordination bugs)는 생성 실패 (generation failure)가 아니라 라우팅 실패 (routing failure)로 인해 발생한 것이었습니다. 이 차이는 문제가 발생했을 때 어디를 살펴봐야 하는지를 결정하기 때문에 매우 중요합니다.

레이어 3: 상태 레이어 (The State Layer)

여러 에이전트가 실시간 데이터에 따라 행동할 때, 이들에게는 상태 (state)에 대한 공유되고 일관된 관점이 필요합니다. 만약 에이전트 A가 T=0 시점에 검색하고 에이전트 B가 T=8s 시점에 검색한다면, 두 에이전트는 서로 모순되는 사실을 보유하게 될 수 있습니다. 상태 조정 (state-reconciliation) 전략이 없다면, 합성 에이전트 (synthesis agent)는 상충하는 입력을 받게 되어 쓸데없이 말을 흐리거나 무작위로 하나를 선택하게 됩니다.

AgentCore Memory가 지속성 기질 (persistence substrate)을 제공하지만, 조정 로직 (reconciliation logic)은 여러분이 직접 설계해야 합니다. 이는 팀들이 흔히 건너뛰는 레이어이며, 동시에 운영 환경에서 가장 당혹스러운 사고를 일으키는 레이어이기도 합니다. 저는 어떤 팀들이 모델 품질 문제라고 생각했던 것을 해결하기 위해 2주 동안 매달렸으나, 알고 보니 두 에이전트가 8초 간격으로 동일한 페이지를 가져왔고 그 사이 변경된 숫자에 대해 서로 의견이 달랐던 문제였음을 목격한 적이 있습니다.

각각 99% 정확한 두 에이전트라도, 그들 사이의 조정을 책임지는 주체가 없다면 100% 틀린 답을 내놓을 수 있습니다. 조정 (coordination)은 모델의 속성이 아닙니다. 그것은 아키텍처 결정 (architecture decision)입니다.

레이어 4: ID 및 신뢰 레이어 (The Identity & Trust Layer)