실시간 에이전트를 위한 AI 기술: AgentCore 웹 검색 플레이북

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

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

대부분의 AI 기술 워크플로우는 완전히 잘못된 문제를 해결하고 있습니다. 사람들은 어떤 모델을 사용할지에 집착하지만, 실제 실패는 단계 사이의 간극, 즉 한 에이전트가 다른 에이전트에게 작업을 넘길 때 컨텍스트 (Context)가 조용히 증발하는 지점에서 발생합니다. 현대 AI 기술에 대한 냉혹한 진실은 모델이 병목 현상 (Bottleneck)인 경우는 드물다는 것입니다. 진짜 문제는 구성 요소 간의 조정 (Coordination)이며, 이러한 단 한 번의 프레임워크 설정 오류가 팀의 분기 전체를 허비하게 만듭니다.

AWS는 최근 Amazon Bedrock AgentCore의 웹 검색 (Web Search on Amazon Bedrock AgentCore)을 발표했습니다. 이는 사용자가 스크래퍼 (Scraper)를 단 하나도 구축할 필요 없이 에이전트가 실시간 웹 데이터를 가져올 수 있게 해주는 관리형 도구입니다. 이것이 지금 중요한 이유는 실시간 그라운딩 (Real-time grounding)이 데모 수준의 에이전트와 실제 프로덕션 수준의 에이전트 사이의 가장 큰 격차이기 때문입니다.

이 글을 읽고 나면 여러분은 AgentCore 웹 검색 아키텍처 (Architecture), 그것이 실패하는 지점, 그리고 실제 사용자와의 접점에서도 견뎌낼 수 있는 조정된 멀티 에이전트 시스템 (Multi-agent system)에 이를 어떻게 연결하는지 이해하게 될 것입니다.

AgentCore 웹 검색 흐름: 에이전트가 쿼리 (Query)를 발행하면, AgentCore가 검색 (Retrieval) 및 랭킹 (Ranking)을 처리하고, 근거가 있는 결과 (Grounded results)가 오케스트레이션 레이어 (Orchestration layer)로 반환됩니다. 이를 통해 대부분의 팀이 구축했다가 후회하는 커스텀 스크래퍼를 제거할 수 있습니다.

개요: AgentCore 웹 검색이란 정확히 무엇인가

Amazon Bedrock AgentCore Web Search는 AI 에이전트에게 공개 인터넷에 대한 실시간 접근 권한을 부여하는 완전 관리형 도구 (fully managed tool)입니다. 연결해야 할 크롤러 (crawler)도, 관리해야 할 프록시 로테이션 (proxy rotation)도 없습니다. 사이트가 내비게이션을 재설계할 때마다 깨지는 HTML 파싱 (HTML parsing) 로직도 필요 없습니다. 에이전트는 단일 도구를 호출하기만 하면 순위가 매겨지고, 구조화되었으며, 인용 준비가 된 (citation-ready) 결과를 돌려받습니다. 이는 AWS가 대규모 에이전트 호스팅을 위해 출시한 프로덕션급 환경인 Bedrock AgentCore 런타임 (runtime)에 직접 연결됩니다.

2025년 에이전트형 AI (agentic AI)의 숨겨진 비밀은 이렇습니다. 대부분의 '에이전트'는 시간에 얼어붙어 있었습니다. 이들은 18개월 전의 학습 데이터 (training data)를 바탕으로 훌륭하게 추론하지만, 그보다 최신 정보에 대해서는 자신 있게 환각 (hallucination)을 일으킵니다. 검색 증강 생성 (Retrieval-Augmented Generation, RAG)이 프라이빗 데이터 (private data)에 대해서는 이 문제의 일부를 해결했지만, 오픈 웹 (open web)은 여전히 DIY 악몽으로 남아 있었습니다. 모든 팀이 동일하고 취약한 스크래핑 스택 (scraping stack)을 다시 구축해야 했습니다. AgentCore Web Search는 이를 관리형 프리미티브 (managed primitive)로 통합합니다.

하지만 — 그리고 이것이 이 가이드의 핵심 논지입니다 — 에이전트에 웹 검색을 추가한다고 해서 시스템이 신뢰할 수 있게 되는 것은 아닙니다. 단지 하나의 구성 요소 (component)가 신뢰할 수 있게 될 뿐입니다. 전체 시스템의 신뢰성은 구성 요소 간의 조정 (coordination)에 달려 있으며, 바로 그 지점에서 거의 모든 이들이 인지하지 못한 채 정확도를 잃고 있습니다.

정립된 프레임워크 (Coined Framework)

AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차 (AI Coordination Gap)란 단일 구성 요소 내부가 아니라, AI 구성 요소들 — 검색 (retrieval), 추론 (reasoning), 도구 호출 (tool calls), 그리고 다른 에이전트들 — 사이의 인계 (handoffs) 과정에서 발생하는 신뢰성의 복합적인 손실을 의미합니다. 이는 개별적으로는 뛰어난 부품들로 이루어진 시스템이 왜 프로덕션 환경에서 여전히 실패하는지를 설명하는 용어입니다.

아무도 슬라이드에 올리지 않는 수학적 사실을 고려해 보십시오. 각 단계의 신뢰도가 97%인 6단계 파이프라인 (pipeline)의 엔드 투 엔드 (end-to-end) 신뢰도는 단 83%에 불과합니다 (0.97^6). 여기에 웹 검색 (web search), 리랭커 (re-ranker), 추론 단계 (reasoning step), 검증기 (validator), 그리고 작성기 (writer)를 추가하면, '대체로 잘 작동하는' 당신의 에이전트는 5번 중 1번꼴로 실패하게 됩니다. 웹 검색은 각 '단계'를 개선할 뿐, 단계 사이의 '간극 (gaps)'에는 아무런 도움이 되지 않습니다. 이것이 함정이며, 이는 다단계 추론 체인 (multi-step reasoning chains)에 관한 발표된 연구와도 일치합니다.

83%
단계별 정확도가 97%인 6단계 파이프라인의 엔드 투 엔드 신뢰도
[arXiv 복합 오류 분석, 2025](https://arxiv.org/)
...

이 가이드는 AgentCore 웹 검색 (AgentCore Web Search)이 무엇인지, 조정된 에이전트 (coordinated agent) 내부에서 이를 사용하기 위한 6계층 프레임워크, 각 계층이 실제로 작동하는 방식, 실제 배포 패턴, 정확도를 조용히 갉아먹는 실수들, 그리고 이 모든 것이 어디로 향하고 있는지를 다룹니다. 당신이 시니어 엔지니어(senior engineer)나 AI 리드(AI lead)라면, 이것은 보도 자료가 아닌 시스템 관점의 분석이 될 것입니다.

고장 난 에이전트에 웹 검색을 추가한다고 해서 문제가 해결되지는 않습니다. 그것은 단지 에이전트가 과거에 대해 틀리는 대신, 실시간으로 틀릴 수 있게 만들 뿐입니다.

왜 AI 조정 간극 (AI Coordination Gap)이 진짜 문제인가

대부분의 사람들이 AI 에이전트에 대해 오해하는 점은 모델이 병목 현상 (bottleneck)이라고 생각하는 것입니다. 그들은 GPT, Claude, Gemini를 소수점 셋째 자리까지 벤치마크(benchmark)한 뒤, 3단계에서 4단계로 잘못된 형식의 JSON 블롭 (JSON blob)을 전달하여 실패하는 시스템을 출시합니다. 모델은 문제가 없었습니다. 실패한 것은 '조정 (coordination)'이었습니다.

2026년에 AI 기술로 승리하는 기업은 가장 큰 모델이나 가장 많은 GPU를 보유한 기업이 아닙니다. 그들은 조정을 일급 엔지니어링 문제 (first-class engineering problem)로 취급하는 기업들입니다. 즉, 단계 간의 명시적인 계약 (explicit contracts), 모든 인계 과정에서의 검증 (validation), 그리고 컨텍스트 (context)가 어디서 소멸했는지 보여주는 관측 가능성 (observability)을 갖춘 기업들입니다. 저는 팀들이 이를 무시하다가 분기 전체를 허비하는 것을 지켜봐 왔습니다. 그 패턴은 우울할 정도로 일관적입니다.

실제 운영 중인 에이전트 시스템(production agent systems)에서 발생하는 실패의 약 40%는 모델 호출 내부가 아니라 구성 요소 간의 경계(seams)에서 발생합니다. 모델을 업그레이드한다고 해서 이 경계 문제를 해결할 수는 없습니다.

AgentCore Web Search는 여러 경계에 동시에 걸쳐 있기 때문에 완벽한 사례 연구(case study)가 됩니다. 웹 검색은 다음과 같은 단계들을 도입합니다: (1) 쿼리 구성 전달 (reasoning → search), (2) 결과 수집 전달 (search → context), 그리고 (3) 근거 제시 전달 (context → final answer). 각 단계는 조정 격차(Coordination Gap)가 신뢰성을 갉아먹는 지점입니다. 이는 도구 증강 언어 모델(tool-augmented language models)에 관한 Google Research의 연구에서도 문서화된 것과 동일한 시스템적 우려 사항입니다.

정립된 프레임워크

AI 조정 격차 (The AI Coordination Gap)

이는 구성 요소의 정확도(component accuracy)와 시스템 정확도(system accuracy) 사이의 차이이며, 모든 전달 과정에서 지불하게 되는 보이지 않는 세금입니다. AgentCore Web Search는 구성 요소의 정확도를 높이지만, 시스템의 정확도를 높이는 것은 바로 이 조정 격차(Coordination Gap)를 메우는 것입니다.

시각화된 조정 격차: 추론(reasoning), 웹 검색(web search), 그리고 종합(synthesis) 사이의 각 전달 단계는 신뢰성을 감소시킵니다. AgentCore Web Search와 같이 관리되는 도구들은 단계(steps)를 줄여주지만, 단계 사이의 격차(gaps)를 줄여주지는 못합니다.

AgentCore Web Search를 활용한 실시간 에이전트를 위한 6계층 프레임워크

조정 격차를 실제로 메우는 실시간 에이전트를 구축하려면, AgentCore Web Search를 단순한 기능이 아니라 의도적으로 설계된 스택(stack)의 한 계층으로 취급해야 합니다. 여기에는 각각의 역할, 실패 모드(failure mode), 그리고 해결책을 가진 6개의 계층이 있습니다.

Bedrock AgentCore 기반의 6계층 실시간 에이전트 스택

  1

    **의도 및 쿼리 구성 계층 (Intent & Query Formulation Layer) (Bedrock 기반 LLM)**

추론 모델 (Reasoning model)은 질문에 실시간 데이터가 필요한지 여부를 결정하고, 필요한 경우 정밀한 검색 쿼리 (Search query)를 작성합니다. 입력: 사용자 요청 + 시스템 프롬프트 (System prompt). 출력: 구조화된 검색 의도 (Structured search intent). 지연 시간 (Latency): ~300-800ms. 이것이 첫 번째 이음새 (Seam)입니다. 여기서 모호한 쿼리가 생성되면 이후의 모든 단계가 오염됩니다.

↓

  2
...

AgentCore는 실시간 웹을 대상으로 쿼리를 실행하며, 크롤링 (Crawling), 속도 제한 (Rate limits), 랭킹 (Ranking)을 처리합니다. 출력: URL, 스니펫 (Snippets), 타임스탬프 (Timestamps)가 포함된 구조화된 결과. 지연 시간 (Latency): ~1-3s. 프로덕션 환경에 적합하며 AWS에 의해 완전히 관리됩니다.

↓

  3
...

재순위화 (Re-ranking) 단계 (BGE re-ranker 또는 저비용 LLM 판사)에서 결과의 관련성 (Relevance)과 최신성 (Recency)을 점수화하여, 오래되었거나 주제에서 벗어난 검색 결과를 폐기합니다. 출력: 상위 k개의 신뢰할 수 있는 구절 (Top-k trusted passages). 이 단계는 에이전트가 2019년 포럼 게시물을 근거로 삼는 것을 방지하는 지점입니다.

↓

  4
...

웹 검색 결과는 벡터 데이터베이스 (Vector database, 예: Pinecone)의 프라이빗 컨텍스트 (Private context)와 병합되어, 명시적인 소스 태그 (Source tags)가 포함된 단일한 근거 기반 컨텍스트 창 (Grounded context window)으로 통합됩니다. 출력: 인용 태그가 붙은 프롬프트 (Citation-tagged prompt). 이 계층은 대부분의 팀이 출처 표기 (Attribution)를 조용히 놓치는 지점입니다.

↓

  5
...

모델 — 종종 LangGraph 또는 AutoGen을 통해 조정됨 — 은 태그된 소스를 반드시 인용하도록 강제된 상태에서 답변을 생성합니다. 출력: 초안 답변 + 인용 (Draft answer + citations). 지연 시간 (Latency): ~1-2s. 오케스트레이션 계층 (Orchestration layer)은 모든 주장이 소스에 매핑된다는 계약을 강제합니다.

↓

  6
...

최종 검증기 (Validator)는 답변이 사용자에게 도달하기 전에 인용이 존재하는지, 주장이 근거에 기반했는지, 그리고 정책을 준수하는지 확인합니다. 출력: 검증된 응답 또는 재시도 신호 (Verified response or a retry signal). 이것은 대부분의 팀이 건너뛰는 이음새이며, 그들이 환각 (Hallucinations)을 배포하게 되는 이유입니다.

이 시퀀스는 중요합니다. 왜냐하면 각 화살표는 조정 격차 (Coordination Gap)를 의미하기 때문입니다. 단순히 단계를 최적화하는 것이 아니라, 이 격차를 메우는 것이 신뢰할 수 있는 실시간 에이전트를 만드는 길입니다.

계층 1: 의도 및 쿼리 구성 (Intent & Query Formulation)

가장 큰 영향력을 발휘하는 단 하나의 결정은 검색을 수행할지 여부입니다. 단순한 에이전트는 매 턴마다 검색을 수행하여, 모델이 이미 정답을 알고 있는 경우에도 지연 시간 (Latency)과 비용을 낭비합니다. 더 똑똑한 에이전트는 Claude Haiku나 Amazon Bedrock의 Amazon Nova Micro와 같은 빠른 전처리 단계 (Pre-step)를 사용하여 먼저 의도 (Intent)를 분류합니다. 출력값은 {needs_web: bool, query: string, recency_days: int}와 같은 타입화된 객체 (Typed object)입니다. 이 계약 (Contract)을 제대로 설정하면 다음 5개 계층이 제대로 작동하지만, 잘못 설정하면 노이즈에 대한 비용을 지불하게 됩니다.

계층 2: AgentCore 웹 검색 실행 (AgentCore Web Search Execution)

이것은 AWS가 방금 출시한 계층입니다. 에이전트 정의에 웹 검색 (Web Search)을 도구 (Tool)로 등록하면, AgentCore가 모두가 싫어하는 부분인 봇 탐지 (Bot detection), 프록시 로테이션 (Proxy rotation), HTML 파싱 (HTML parsing)을 포함한 전체 검색 파이프라인 (Retrieval pipeline)을 처리합니다. AWS 공지에 따르면, 이는 가공되지 않은 HTML이 아니라 그라운딩 (Grounding)을 위해 설계된 구조화된 결과 (Structured results)를 반환합니다. 이는 프로덕션 환경에 즉시 적용 가능한 수준입니다. 저는 이를 실험적인 단계로 취급하지 않을 것입니다.

계층 3: 관련성 및 최신성 필터링 (Relevance & Freshness Filtering)

웹 검색은 필요한 것보다 더 많은 정보를 반환하며, 최신성 (Recency)이 곧 관련성 (Relevance)은 아닙니다. 품질을 위해서는 리랭킹 계층 (Re-ranking layer) — BGE re-ranker 또는 0에서 1 사이의 점수를 매기는 LLM-as-judge — 이 필수적입니다. 이를 건너뛰면 검색 결과에서 순위가 가장 높게 나온 정보, 즉 3년 전의 SEO 최적화된 쓰레기 정보에 모델을 그라운딩하게 됩니다. 이 계층이 신뢰할 수 있는 답변과 자신감 있게 들리는 틀린 답변을 구분 짓는 지점입니다.

최신성이 곧 관련성은 아닙니다. 가장 최신인 결과와 가장 정확한 결과는 종종 동일한 문서가 아니며, 이 둘을 혼동하는 에이전트는 자신감 있게 헛소리를 내뱉습니다.

계층 4: 컨텍스트 조립 (Context Assembly (RAG Fusion))

실제 시스템은 실시간 웹 데이터와 내부 지식을 혼합합니다. 이것이 바로 RAG가 웹 검색과 만나는 지점입니다. 벡터로 검색된(vector-retrieved) 내부 문서와 웹 구절을 하나의 컨텍스트 창(context window)으로 융합하며, 각 청크(chunk)에는 소스 ID(source ID) 태그가 붙습니다. 이 태그는 일종의 계약입니다. 이 태그가 있어야만 계층 4(Layer 6)에서 검증(validator) 작업이 가능해집니다. 태그가 없다면 모델이 실제로 인용한 것과 스스로 지어낸 것을 구분할 방법이 없습니다. 벡터 검색(vector retrieval)이 이를 어떻게 뒷받침하는지에 대한 더 자세한 내용은 당사의 벡터 데이터베이스 가이드를 참조하십시오.

계층 5: 합성 및 오케스트레이션 (Synthesis & Orchestration)

이 단계는 LangGraph나 AutoGen이 제 역할을 하는 곳입니다. 오케스트레이션 그래프(orchestration graph)는 합성 노드(synthesis node)가 태그가 지정된 소스에 의해 뒷받침되는 주장(claims)만을 출력하도록 강제하며, 이를 수행하지 못할 경우 재시도 노드(retry node)로 경로를 지정합니다. 여기서 조정(coordination)은 코드(code)로 이루어집니다. 느낌(vibes)이 아닙니다.

계층 6: 검증 및 가드레일 (Validation & Guardrails)

마지막 이음새이자, 대부분의 팀이 완전히 건너뛰는 단계입니다. Bedrock Guardrails와 인용 존재 여부 확인(citation-existence check)을 결합하면 다른 모든 단계에서 빠져나간 실패 사례를 잡아낼 수 있습니다. 이 단계를 건너뛴다면, 대규모로 틀릴 수 있는 더 빠른 방법을 구축한 것과 다름없습니다.

어떤 에이전트 스택에서든 가장 저렴하게 신뢰성을 확보하는 방법은 인용 존재 검증기(citation-existence validator)를 사용하는 것입니다. 즉, 인용된 모든 URL이 실제로 검색된 세트(retrieved set)에 나타났는지 확인하는 50줄 정도의 체크 코드입니다. 이는 거의 제로에 가까운 비용으로 근거 없는 환각(grounding hallucinations)의 상당 부분을 잡아냅니다.