실시간 에이전트를 위한 AI 기술: AgentCore Web Search가 어떻게 오래된 답변을 제거하는가

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

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

대부분의 AI 기술 워크플로우는 완전히 잘못된 문제를 해결하고 있습니다. 사람들은 어떤 모델을 사용할지에 집착하는 동안, 에이전트들은 18개월 전의 학습 중단 시점(training cutoff)으로부터 나온 사실들을 조용히 환각 (hallucinate) 하고 있으며, 고객이 알아차리기 전까지는 아무도 이를 인지하지 못합니다. AWS의 최신 AI 기술은 마침내 이 계산 방식을 재정의하며, 이는 더 큰 모델을 선택하는 것과는 아무런 관련이 없습니다.

AWS가 방식을 바꾸었습니다. Amazon Bedrock AgentCore의 Web Search는 프로덕션 에이전트에게 라이브 웹 데이터로 향하는 관리되고 통제된 경로를 제공합니다. 관리해야 할 스크래핑 인프라가 없고, 유지 관리해야 할 취약한 API 접착제(glue)가 없으며, 결정적으로 고객에게 오래된 답변이 전달되지 않습니다. 더 넓은 AgentCore 런타임 (runtime)과 결합하여, 이는 '근거를 둔 (grounded)'이라는 말이 실제로 무엇을 의미하는지 재정의합니다.

이 가이드는 실시간 에이전트 뒤에 숨겨진 시스템 아키텍처 (systems architecture), 프로덕션 환경에서 에이전트를 망가뜨리는 조정 실패 (coordination failures), 그리고 지연 시간 (latency)이나 예산을 낭비하지 않고 AgentCore Web Search를 배포하는 정확한 방법을 다룹니다. 이는 막연한 설명이 아닌, 명시된 배포 사례와 출처가 분명한 벤치마크 (benchmarks)에 기반합니다.

AgentCore Web Search가 어떻게 Bedrock 에이전트의 추론 루프 (reasoning loop)에 라이브 웹 컨텍스트 (web context)를 주입하는지 보여줍니다 — 이는 모델과 실제 세계 사이의 누락된 조각입니다. 출처

AgentCore Web Search란 무엇이며, 왜 2026년에 중요한가?

우리가 대화했던 한 핀테크(fintech) 팀은 이자율 견적 에이전트(rate-quoting agent)를 위한 모델 선택을 6주 동안 A/B 테스트를 진행했습니다. 하지만 그 과정에서 누군가가 진짜 버그를 발견하기 전까지는 말이죠. 에이전트가 2024년 3분기에 고정된 이자율 데이터를 사용하여 실시간 주택 담보 대출(mortgage) 질문에 답변하고 있었던 것입니다. 모델을 교체한다고 해서 해결될 문제가 아니었습니다. 프로덕션(production) AI의 병목 현상은 거의 항상 모델 때문이 아닙니다. GPT-4급 및 Claude급의 추론(reasoning) 능력은 2024년 이후 대부분의 기업용 작업에 충분히 훌륭했습니다. 병목 현상은 바로 _조정(coordination)_입니다. 시스템 전체가 지연 시간(latency)과 비용 문제로 무너지지 않으면서, 적절한 시점에, 적절한 소스로부터, 적절한 컨텍스트(context)를 가져와 적절한 에이전트에게 전달하는 것입니다.

Amazon Bedrock AgentCore는 AI 에이전트를 대규모로 배포하고 운영하기 위한 AWS의 관리형 런타임(managed runtime)입니다. 이번 달에 발표된 Web Search 기능은 에이전트가 실시간 인터넷을 쿼리(query)할 수 있게 해주는 퍼스트 파티(first-party) 기반의 관리형 도구를 추가합니다. 이를 통해 에이전트는 답변하기 전에 추론할 수 있는 순위가 매겨지고 인용 가능한 결과를 반환받습니다. 모델 재학습(retraining)도 필요 없고, 지식 컷오프(knowledge cutoff) 문제도 없으며, 웹사이트가 디자인을 변경할 때마다 깨지는 자체 제작 스크래핑 파이프라인(scraping pipeline)도 필요하지 않습니다.

이것이 왜 지금 중요한가요? 업계 전체가 2024년과 2025년에 RAG(검색 증강 생성)와 파인튜닝(fine-tuning)으로 정보의 노후화(staleness) 문제를 임시방편으로 해결하려 노력해 왔지만, 이 두 가지 방식은 모두 다른 문제를 해결하는 도구입니다. RAG는 사용자가 큐레이션한 코퍼스(corpus)에서 정보를 검색합니다. 파인튜닝은 고정된 시점까지의 지식을 모델에 내재화합니다. 이 중 어느 것도 어제 규정이 바뀌었거나, 오늘 아침 경쟁사가 가격을 인하했거나, 한 시간 전에 항공편이 취소되었다는 사실을 에이전트에게 알려주지 못합니다. Web Search는 관리형 AWS 컨트롤 플레인(control plane) 내부에서 그 간극을 메워줍니다. 이것이 실제적인 변화입니다.

지식 컷오프(knowledge cutoff)가 고정된 모델은 구조적으로 시간에 민감한 정보에 대해 정확할 수 없습니다. 웹 검색은 단순한 기능이 아닙니다. 그것은 아는 에이전트와 자신 있게 추측하는 에이전트 사이의 차이입니다.

AgentCore Web Search를 단순한 보도 자료가 아닌 진정한 변화로 만드는 세 가지 요소는 다음과 같습니다:

• 관리 및 거버넌스가 제공됩니다. AWS가 검색 인프라, 속도 제한 (rate limits), 결과 순위 지정 (result ranking)을 처리합니다. 여러분은 팀원 중 누군가가 새벽 2시에 관리해야 하는 Bing, SerpAPI, 그리고 Lambda 스크레이퍼를 하나하나 이어 붙이는 대신, IAM 수준의 제어, CloudWatch를 통한 관찰성 (observability), 그리고 단일 결제 인터페이스를 얻게 됩니다.

• 에이전트 루프 (agent loop)에 내장되어 있습니다. 이 도구는 AgentCore 런타임 (runtime)에 직접 통합되므로, 에이전트는 검색을 모델 실행 전의 일회성 사전 가져오기 (pre-fetch)로 취급하는 대신, 언제 검색할지 결정하고, 결과에 대해 추론하며, 검색을 체이닝 (chaining)할 수 있습니다.

• MCP와 결합됩니다. Model Context Protocol을 통해 AgentCore 도구는 LangGraph 및 CrewAI와 같은 프레임워크를 포함한 더 넓은 에이전트 생태계와 상호 운용이 가능해집니다.

이 가이드는 제가 실시간 에이전트 프로젝트가 실패하는 이유를 진단하기 위해 사용해 온 프레임워크와, AgentCore Web Search가 더 큰 시스템의 한 계층으로서 어떻게 자리 잡는지 소개합니다. 저는 이를 **AI 조정 격차 (The AI Coordination Gap)**라고 부릅니다.

고안된 프레임워크

AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차는 에이전트의 추론 능력 (reasoning capability)과 의사 결정 시점에 정확하고 최신이며 거버넌스가 적용된 컨텍스트 (context)에 접근할 수 있는 능력 사이의 체계적인 거리입니다. 이는 대부분의 AI 배포가 약한 모델 때문이 아니라, 추론 (reasoning), 검색 (retrieval), 그리고 실시간 데이터 사이의 깨진 조정 (coordination) 때문에 실패한다는 점을 명시합니다.

왜 AI 조정 격차가 여러분이 해결해야 할 진짜 문제인가요?

에이전트 설계 방식을 바꿔 놓을 수 있는 수치를 하나 말씀드리겠습니다. 각 단계가 독립적으로 97%의 신뢰도를 가진 6단계 에이전트 파이프라인 (agentic pipeline)에서, 엔드 투 엔드 (end-to-end) 신뢰도는 단 83% (0.97^6)에 불과합니다. 대부분의 팀은 제품을 출시한 후에 이를 발견합니다. 고객이 17%의 실패 경로에 진입하고, 사후 분석 (postmortem) 결과 기술적으로 '고장 난' 단일 구성 요소가 없다는 사실이 밝혀질 때 말입니다.

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

조정 격차 (Coordination Gap)는 세 가지 지점에서 나타나며, AgentCore Web Search는 그중 하나를 직접적으로 해결합니다:

• 시간적 격차 (Temporal gap) — 에이전트의 지식은 고정되어 있지만, 현실은 계속 변합니다. Web Search가 이 격차를 메웁니다.

• 소스 격차 (Source gap) — 에이전트가 진실을 보유한 시스템(사용자의 CRM, 파트너 API, 라이브 웹 등)에 도달할 수 없습니다. 이는 의도적인 툴링 (tooling)을 필요로 합니다.

• 핸드오프 격차 (Handoff gap) — 에이전트, 도구, 그리고 오케스트레이션 (orchestration) 단계 사이를 전달되는 과정에서 컨텍스트 (context)가 저하됩니다. 이 격차는 멀티 에이전트 시스템 (multi-agent systems)을 조용히 무너뜨립니다.

한 플랫폼 팀은 에이전트 예산의 70%를 추론 (inference)에 사용했는데, 가장 심각한 성능 저하 (regression)가 모델 변경이 아닌, 9일 동안 조용히 빈 페이지를 반환한 스크레이퍼 (scraper) 때문에 발생했다고 우리에게 말했습니다. 모두가 모델을 주시하고 있었지만, 아무도 데이터를 보고 있지 않았습니다.

실시간 에이전트에 대해 대부분의 사람들이 잘못 알고 있는 점은 '웹 검색 추가'를 단순한 기능 토글 (feature toggle)로 생각한다는 것입니다. 그렇지 않습니다. 단순한 (Naive) 웹 검색은 에이전트를 더 느리고 멍청하게 만듭니다. 신호가 낮은 SERP 노이즈로 컨텍스트 윈도우 (context window)를 범람시키고, 지연 시간 예산 (latency budget)을 초과하며, 모델에게 환각 (hallucination)을 일으킬 수 있는 모순된 소스들을 제공하기 때문입니다. 어려운 부분은 바로 _조정 (coordination)_입니다: 언제 검색할지, 어떻게 순위를 매길지, 얼마나 주입할지, 그리고 어떻게 출처를 밝힐지 말입니다. 그것이 바로 AgentCore의 관리형 레이어 (managed layer)가 처리하도록 설계된 핵심입니다.

AI 조정 격차 (AI Coordination Gap)의 세 가지 모습. AgentCore Web Search는 시간적 격차를 직접적으로 메우는 반면, MCP 기반 툴링은 소스 및 핸드오프 격차를 해결합니다.

실시간 AgentCore 시스템의 5가지 레이어는 무엇인가?

다음은 다섯 가지 명명된 레이어로 구분된 프레임워크입니다. 각 레이어는 조정 격차 (Coordination Gap)가 넓어질 수 있는 지점인 동시에, AgentCore가 이를 좁히기 위해 관리 가능한 레버 (lever)를 제공하는 지점이기도 합니다.

AgentCore 실시간 에이전트 스택: 요청에서 근거 있는 답변까지 (Request to Grounded Response)

  1

    **AgentCore 런타임 (Reasoning Layer, 추론 레이어)**

에이전트가 요청을 받으면 모델 (Claude, Nova 또는 기타 Bedrock 모델)이 계획을 세웁니다. 모델은 내부 지식만으로 충분한지, 아니면 실시간 조회 (live lookup)가 필요한지 결정합니다. 지연 시간 (Latency): 계획 수립에 200-800ms 소요.

↓

  2
...

에이전트가 도구 (tool)를 선택합니다. 웹 검색 (Web Search)은 쿼리가 시간에 민감하거나 코퍼스 (corpus) 외의 내용일 때만 실행됩니다. 이러한 게이팅 (gating)은 비용과 지연 시간을 결정하는 가장 큰 레버입니다. 과도한 검색 (over-searching)은 가장 빈번한 실패 모드 (#1 failure mode)입니다.

↓

  3
...

관리형 웹 쿼리 (Managed web query)가 순위가 매겨지고 인용 가능한 결과를 반환합니다. AWS가 속도 제한 (rate limiting), 순위 지정 (ranking), 최신성 (freshness)을 처리합니다. 출력: 소스 URL이 포함된 상위 k개 구절 (top-k passages). 지연 시간 (Latency): 400-1200ms (내부 Twarx 추정치, 아래 방법론 참고).

↓

  4
...

에이전트는 검색된 구절을 압축하고 내부 RAG 컨텍스트와 대조하여 조정하며, 모순을 해결하고 출처를 명시합니다. 이 단계는 대부분의 환각 (hallucination)이 방지되거나 발생하는 지점입니다.

↓

  5
...

근거 있는 답변 (grounded answer)이 인용구와 함께 전달됩니다. CloudWatch는 도구 호출 (tool calls), 토큰 사용량 (token spend), 지연 시간을 기록합니다. 가드레일 (Guardrails)이 정책을 강제합니다. 이는 감사 (audit) 및 비용 제어를 위한 루프를 완성합니다.

이 시퀀스는 매우 중요합니다. 레이어 3의 검색 (retrieval) 이전에 레이어 2에서 검색을 게이팅하는 것이 실시간 에이전트를 빠르고 경제적으로 유지하는 핵심입니다.

레이어 1 — 추론 레이어 (Reasoning Layer, AgentCore 런타임)

이곳은 모델이 계획을 세우는 곳입니다. 핵심적인 설계 결정 사항은 다음과 같습니다: 에이전트가 검색을 _기본값(default)_으로 설정할 것인가, 아니면 추론 과정에서 불확실성이 감지될 때만 검색할 것인가? '검색 기본값' 방식은 게으른 패턴입니다. 이는 지연 시간(latency)과 비용을 동시에 폭발시킵니다. 절제된 패턴은 '불확실성 기반 검색(uncertainty-gated search)'으로, 모델이 도구(tool)를 호출하기 전에 '이 부분의 내 지식은 아마도 오래되었을 것이다'라고 명시적으로 추론하는 방식입니다. AgentCore의 런타임은 구조화된 도구 사용 프롬프팅(structured tool-use prompting)을 통해 이를 지원하며, 이는 Anthropic 문서에서 설명하는 Claude의 도구 호출(tool calling) 방식과 동일한 패턴입니다.

레이어 2 — 결정 레이어 (Decision Layer, 도구 라우터 (Tool Router))

라우터는 조정 격차(Coordination Gap)의 승패가 결정되는 지점입니다. 그게 전부입니다. 잘 조정된 라우터는 일반적인 고객 지원 또는 연구 에이전트에서 쿼리의 약 20~30% 정도만 검색을 수행합니다. 반면, 미숙한 라우터는 90% 이상의 쿼리에 대해 검색을 수행하여 비용을 3배로 늘리고, 모델이 이미 알고 있는 질문에 대해서도 1초의 지연 시간을 추가합니다. 명시적인 게이팅(gating)을 구축하십시오: 시간 민감형 의도(time-sensitive intent), 코퍼스(corpus)가 다루지 않는 고유 명사, 그리고 낮은 모델 신뢰도(model confidence)가 모두 검색을 트리거합니다. 그 외의 모든 것은 컨텍스트(in-context) 내에 유지됩니다. 저는 단지 이 하나의 기능을 강화하는 것만으로 월간 추론(inference) 비용을 거의 절반으로 줄인 팀들을 보았습니다.

도구 라우터를 '모든 것을 검색'하는 방식에서 '쿼리의 약 25%만 검색'하는 방식으로 튜닝하면, 내부 벤치마크 기준으로 에이전트 운영 비용을 40~60% 절감할 수 있는 동시에 답변 품질을 _향상_시킬 수 있습니다. 깨끗한 내부 컨텍스트가 노이즈가 많은 웹 검색 결과로 인해 희석되는 것을 방지할 수 있기 때문입니다.

레이어 3 — 검색 레이어 (Retrieval Layer, 웹 검색)

이것은 새로운 AWS 기능입니다. 여기서 얻는 이점은 더 이상 스크래핑 인프라 (scraping infrastructure)를 유지하거나, 프록시 (proxies)를 교체하거나, 제3자 SERP API의 속도 제한 (rate limits)을 관리할 필요가 없다는 점입니다. AgentCore Web Search는 관리되는 AWS 경계 내에서 순위가 매겨지고 인용 가능한 결과를 반환합니다. 숙련된 팀의 경우, 신뢰성 향상을 고려하기 전에도 전용 스크래핑/검색 마이크로서비스 (microservice)를 제거함으로써 얻는 운영 비용 절감만으로도 엔지니어링 및 인프라 오버헤드 측면에서 월 $4,000–$9,000의 가치가 있을 수 있습니다 (연봉 약 $200K인 미드 레벨 엔지니어의 완전 비용에 프록시 및 SERP-API 항목을 더한 Twarx 내부 추정치 기준).

레이어 4 — 그라운딩 레이어 (The Grounding Layer, 컨텍스트 합성)

검색된 구절 (passages)은 가공되지 않은 상태입니다. 에이전트는 이를 압축하고, 모순을 조정하며 (두 소스의 가격이 다를 경우 어떤 것이 더 최신인가?), 주장에 대한 URL 출처를 밝혀야 합니다. 이것이 실시간 웹 데이터와 귀하의 RAG 코퍼스 (RAG corpus)를 결합하는 지점입니다. 잘 수행된다면 에이전트는 출처를 인용합니다. 잘못 수행된다면, 두 개의 틀린 숫자를 자신 있게 평균 내버립니다. 주입되는 컨텍스트 (context)를 타이트하게 유지하십시오. 20개가 아니라 상위 3~5개의 구절이어야 합니다. 진심입니다, 20개가 아닙니다.

명명된 프레임워크 (Coined Framework)

AI 조정 격차 (The AI Coordination Gap)