실시간 에이전트를 위한 AI 기술: Bedrock AgentCore가 비용을 70% 절감하는 방법

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

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

대부분의 AI 기술 워크플로우는 완전히 잘못된 문제를 해결하고 있습니다. 병목 현상이 모델 때문이 아님에도 불구하고, 모델을 최적화하려고 합니다. 실제 병목은 모델과 모델이 호출하는 도구(tools), 그리고 모델이 추론하는 실시간 세계 사이의 조정(coordination)에 있습니다. 오늘날 출시되는 가장 가치 있는 AI 기술은 더 큰 모델이 아닙니다. 에이전트의 모든 부분이 현실에 대해 합의를 유지하도록 하는 관리형 인프라(managed infrastructure)입니다. 이러한 단 한 번의 프레임워크 재설정이 신뢰할 수 있는 에이전트를 출시하는 팀과, 매달 수만 달러를 조용히 태워버리는 데모를 출시하는 팀을 가르는 차이점입니다.

AWS는 방금 Amazon Bedrock AgentCore의 웹 검색(Web Search on Amazon Bedrock AgentCore)을 출시했습니다. 이는 SerpAPI, 프록시(proxies), 그리고 파싱(parsing)의 악몽을 직접 엮을 필요 없이 에이전트가 실시간 데이터를 가져올 수 있게 해주는 관리형 실시간 검색 프리미티브(retrieval primitive)입니다. 데모 에이전트와 프로덕션(production) 에이전트 사이의 격차는 거의 전적으로 실시간 그라운딩(live grounding)과 도구 조정(tool coordination)에 달려 있기 때문에 이는 지금 매우 중요합니다.

이 글을 마칠 때쯤이면, 여러분은 시스템 아키텍처(system architecture), 어디에서 문제가 발생하는지, 비용은 얼마인지, 그리고 이를 어떻게 출시할 수 있는지 이해하게 될 것입니다.

Bedrock AgentCore 웹 검색은 추론 모델(reasoning model)과 실시간 웹 사이에 관리형 실시간 검색 레이어(retrieval layer)를 삽입합니다. 이 레이어는 대부분의 팀이 직접 구현하다가 실패하는 부분입니다. 출처

실시간 에이전트를 위한 AI 기술이란 무엇인가?

실시간 에이전트를 위한 AI 기술이란 언어 모델이 학습 중단 시점(training cutoff) 이전에 암기한 정보에 의존하는 대신, 추론 시점(inference time)에 실시간 데이터를 가져오고, 검증하며, 그 데이터를 바탕으로 추론할 수 있게 해주는 관리형 인프라를 의미합니다. 대부분의 팀이 에이전트 프로젝트를 시작하고 6개월이 지났을 때 깨닫는 사실이 있습니다. 바로 LLM(Large Language Model) 자체가 어려운 부분이 아니었다는 점입니다. GPT-4급 및 Claude급의 추론 능력은 2024년 초부터 이미 프로덕션(production) 작업에 충분한 수준이었습니다. 프로젝트를 망치는 것은 모델 '주변'의 모든 것들, 즉 검색(retrieval), 도구 오케스트레이션(tool orchestration), 데이터의 신선도, 그리고 이 모든 것을 하나로 묶어주는 취약한 글루 코드(glue code)입니다.

Amazon Bedrock AgentCore는 프로덕션 AI 에이전트를 구축, 배포 및 운영하기 위한 AWS의 런타임(runtime)이자 툴킷(toolkit)입니다. 새로운 웹 검색 기능(Web Search capability)은 관리형 프리미티브(managed primitive)입니다. 에이전트가 쿼리를 발행하면 AgentCore가 실시간 검색, 크롤링(crawling), 파싱(parsing) 및 랭킹(ranking)을 처리한 다음, 모델이 추론할 수 있는 깨끗하고 인용 가능한 콘텐츠를 반환합니다. 여러분은 프록시 로테이션(proxy rotation)을 건너뛸 수 있습니다. CAPTCHA(캡차)와의 군비 경쟁도 피할 수 있습니다. 그리고 데모에서는 아무도 언급하지 않는 부분, 즉 출시 전날 새벽 2시에 가공되지 않은 HTML 덩어리(HTML soup)를 반환하는 잘못 만들어진 스크래퍼(scraper)를 디버깅해야 하는 상황도 피할 수 있습니다.

에이전트 생태계의 숨겨진 비밀은 여러분이 데모에서 본 거의 모든 '실시간 AI 에이전트'가 취약한 검색 계층(retrieval layer) 위에 구축되어 있다는 것입니다. 즉, 제3자 검색 API를 수동으로 연결하거나, 매주 고장 나는 스크래퍼를 사용하거나, 가공되지 않은 HTML로 가득 찬 컨텍스트 윈도우(context window)를 사용하는 방식입니다. AgentCore Web Search는 AWS 수준의 신뢰성, IAM 범위 권한(IAM-scoped permissions), 그리고 내장된 관찰성(observability)을 통해 해당 계층을 프로덕션 수준으로 끌어올립니다. 이것이 이 기술이 처음 들리는 것보다 훨씬 더 중요한 이유입니다.

모델은 결코 병목 현상(bottleneck)이 아니었습니다. 여러분의 병목 현상은 지난 봄부터 계속 패치하며 사용해 온, 반쯤 만들어진 검색 파이프라인(retrieval pipeline)이었습니다.

하지만 — 그리고 이것이 이 글의 핵심입니다 — 훌륭한 검색 도구(retrieval tool)를 추가한다고 해서 더 깊은 구조적 문제가 해결되지는 않습니다. 오히려 그 문제를 드러낼 뿐입니다. 에이전트에게 실시간 웹 접속 권한을 부여하면, 모델, 검색 도구, 메모리(memory), 그리고 다운스트림 도구(downstream tools)가 세상에서 방금 무슨 일이 일어났는지에 대해 모두 _합의(agree)_해야 하는 시스템을 갑자기 마주하게 됩니다. 이 합의의 문제를 저는 'AI 조정 격차 (AI Coordination Gap)'라고 부르며, 이는 신뢰할 수 있는 에이전트를 출시하는 팀과 프로덕션 환경에서 무너져 버리는 인상적인 데모만을 선보이는 팀을 가르는 결정적인 요소입니다.

정립된 프레임워크

AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차는 단일 AI 구성 요소의 실패로 인해 발생하는 것이 아니라, 구성 요소들이 서로 _합의_하지 못할 때 발생하는 신뢰성 손실을 의미합니다. 즉, 모델, 검색 계층(retrieval layer), 메모리, 그리고 도구들이 각각 미세하게 다른 버전의 현실을 바탕으로 작동할 때 발생합니다. 이는 대부분의 팀이 '모델 품질 (model quality)' 문제로 오진하는 시스템적 문제를 명명한 것입니다.

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

왜 실시간 검색이 에이전트의 게임의 법칙을 완전히 바꾸는가?

정적인 LLM은 학습 중단 시점(training cutoff)에 고정된 세상의 스냅샷입니다. 가격 책정, 경쟁 정보, 규제 모니터링, 변경되는 문서에 대한 고객 지원, 금융 조사와 같은 방대한 비즈니스 문제 영역에서, 고정된 스냅샷은 단순히 도움이 되지 않는 수준이 아닙니다. 그것은 확신에 찬 오답을 내놓습니다. 이것이 지난 2년 동안 AI 기술에서 일어난 가장 중요한 변화입니다. 가치의 중심이 모델이 무엇을 암기했느냐에서 모델이 실시간으로 무엇을 검증할 수 있느냐로 이동한 것입니다.

이것이 AgentCore Web Search와 같은 도구, 그리고 더 넓은 의미의 검색 증강 생성 (RAG) 패턴이 존재하는 핵심 논거입니다. 모델을 재학습(retraining)시킨다고 해서 최신성(freshness) 문제가 해결되는 것이 아닙니다. 추론(inference) 시점에 모델을 실시간 데이터에 접지(grounding)시킴으로써 문제를 해결해야 합니다. 벡터 저장소(vector store)를 활용한 RAG와 실시간 웹 검색의 차이는 단지 접지 대상이 되는 코퍼스(corpus)가 무엇인지, 즉 사용자의 개인 문서인지 아니면 지속적으로 업데이트되는 개방된 웹인지의 차이일 뿐입니다.

'모르겠습니다, 검색해 보겠습니다'라고 말하는 모델이 100%의 확률로 자신 있게 거짓 정보를 만들어내는(fabricates) 모델보다 훨씬 낫습니다. 에이전트의 신뢰성은 더 큰 모델에서 나오는 것이 아니라, 언제 검색(retrieve)해야 하는지를 아는 것에서 나옵니다.

실시간 에이전트에 대해 사람들이 가장 흔히 오해하는 점은 검색 결과 자체에 가치가 있다고 생각하는 것입니다. 그렇지 않습니다. 가치는 *조정(coordination)*에 있습니다. 즉, 새로 검색된 사실이 추론(reasoning), 메모리(memory), 그리고 모든 다운스트림 도구 호출(downstream tool calls)을 통해 올바르게 전파되도록 보장하는 데 가치가 있습니다. 완벽한 결과를 반환하더라도, 그 결과를 무시하거나, 중복 계산하거나, 두 단계 뒤에 모순되는 에이전트에게 전달하는 검색 도구는 결국 마이너스 요소가 됩니다. 이것은 명백한 사실입니다.

시각화된 AI 조정 격차(AI Coordination Gap): 각 구성 요소는 개별적으로는 신뢰할 수 있지만, 구성 요소 간의 불일치가 시스템 실패로 이어집니다. 이것이 실시간 웹 검색을 추가하는 것만으로는 신뢰할 수 있는 에이전트를 보장할 수 없는 이유입니다.

AI 조정 격차 프레임워크: 반드시 일치해야 하는 6가지 계층

다음은 제가 프로덕션 에이전트를 감사하거나 설계할 때 사용하는 프레임워크입니다. AI 조정 격차는 6개의 뚜렷한 계층에 걸쳐 존재합니다. 대부분의 팀은 한두 개 계층만 수정하고 왜 신뢰도가 여전히 80% 수준에 머물러 있는지 의아해합니다. 모든 계층에서 격차를 해소해야 합니다. 부분적인 수정은 기대만큼 복합적인 개선 효과를 내지 못합니다.

명명된 프레임워크

AI 조정 격차 (The AI Coordination Gap)

이는 각각은 독립적으로 작동하지만 결합 시 서로 충돌하여 발생하는, 복합적인 신뢰성 손실 (reliability loss)을 의미합니다. 이를 해결한다는 것은 단순히 모델을 업그레이드하는 것이 아니라, 검색 (retrieval), 추론 (reasoning), 메모리 (memory), 도구 (tools), 오케스트레이션 (orchestration), 그리고 관측 가능성 (observability) 전반에 걸쳐 '합의 (agreement)'를 설계하는 것을 의미합니다.

Layer 1: 그라운딩 레이어 (The Grounding Layer, 실시간 검색)

이곳에 AgentCore Web Search가 위치합니다. 그라운딩 레이어 (grounding layer)는 단 하나의 질문에 답합니다: 지금 이 순간 세상에서 무엇이 사실인가? 이 레이어는 쿼리를 발행하고, 콘텐츠를 가져와 파싱하며, 순위가 매겨진 인용 가능한 결과를 반환합니다. 여기서는 지연 시간 예산 (latency budget)이 매우 중요합니다. 웹 검색의 왕복 시간 (round trip)은 보통 800ms~3s를 추가합니다. 만약 에이전트가 매 턴마다 검색을 수행한다면, 비즈니스 로직을 단 한 줄도 작성하기 전에 사용자 경험 (UX)을 사용할 수 없는 상태로 만들게 됩니다.

조정 요구 사항: 검색된 모든 사실은 출처 URL, 타임스탬프와 같은 출처 (provenance)를 반드시 포함해야 하므로, 하위 레이어에서 충돌을 해결할 수 있어야 합니다. AgentCore는 구조화된 결과를 반환함으로써 모델이 가공되지 않은 HTML을 파싱하지 않도록 합니다. 이는 LangChain에 로우 스크래퍼 (raw scraper)를 억지로 붙여서 직접 만든 설정에서 제가 목격한 가장 흔한 실패 모드입니다.

Layer 2: 추론 레이어 (The Reasoning Layer, 모델)

모델 — Bedrock의 Claude 또는 귀하가 선택한 다른 파운데이션 모델 (foundation model) — 은 언제 검색할지, 무엇을 검색할지, 그리고 결과를 어떻게 합성할지를 결정합니다. 여기서 발생하는 조정 실패는 미묘하며 과소평가되어 있습니다. 모델은 종종 정보를 검색한 뒤 그 결과를 무시하고, 결국 파라메트릭 (parametric, 학습된) 지식으로 되돌아가는 경향이 있습니다. 이는 Anthropic의 도구 사용 연구 (tool-use research)에도 기록되어 있으며, 제가 프로덕션 에이전트에서 보는 가장 흔한 버그 중 하나입니다. 검색은 실행되지만, 답변은 이를 무시합니다. 사용자가 이를 발견하기 전까지는 아무도 알아차리지 못합니다.

Layer 3: 메모리 레이어 (The Memory Layer)

에이전트가 세 번 전의 대화에서 학습한 내용이 방금 검색한 내용과 모순된다면 어떻게 될까요? 메모리(Memory) — 즉, 단기 대화 상태(short-term conversation state)와 장기적으로 유지되는 사실(long-term persisted facts) — 는 새로운 검색 결과(retrieval)와 일치해야 합니다. AgentCore는 관리형 메모리 프리미티브(managed memory primitives)를 제공하여 사용자가 이 과정을 처음부터 다시 설계할 필요가 없게 해주지만, 충돌 해결 정책(conflict resolution policy) (최신 정보 우선? 출처 권위 우선?)은 사용자의 설계 결정 사항입니다. 다른 누구도 이를 대신 결정해 줄 수 없으며, 명시적으로 결정하지 않으면 모델이 일관성 없게 처리하게 됩니다.

Layer 4: 도구 레이어 (The Tool Layer (MCP and Beyond))

검색은 하나의 도구일 뿐입니다. 실제 에이전트는 데이터베이스, 내부 API, 코드 실행, 다른 에이전트 등 수많은 도구를 호출합니다. Model Context Protocol (MCP)는 에이전트에 도구를 일관되게 노출하기 위한 사실상의 표준(de facto standard)이 되었습니다. AgentCore는 MCP 호환 도구 기능을 지원하므로, 사용자의 웹 검색 도구, 내부 CRM 도구, 코드 인터프리터가 모두 동일한 프로토콜로 통신할 수 있습니다. 이는 제가 지난 1년간 이러한 시스템을 출시하며 목격한 조정 오버헤드(coordination overhead)를 줄이는 가장 큰 단일 요인입니다.

Layer 5: 오케스트레이션 레이어 (The Orchestration Layer)

단계의 순서는 누가 결정할까요? 단일 에이전트 시스템(single-agent systems)에서는 모델이 루프를 돕니다. 멀티 에이전트 시스템 (multi-agent systems)에서는 오케스트레이터(orchestrator)가 전문화된 에이전트들 사이에서 작업을 라우팅합니다. LangGraph, AutoGen (GitHub 스타 3.8만 개 이상), CrewAI (스타 2.2만 개 이상)와 같은 프레임워크가 이 역할을 수행합니다. AgentCore 자체는 이러한 패턴들을 호스팅하는 런타임(runtime)입니다.

Layer 6: 관찰 가능성 레이어 (The Observability Layer)

보이지 않는 격차는 메울 수 없습니다. AgentCore에는 내장된 트레이싱(tracing) 기능이 포함되어 있어, 에이전트가 잘못된 답변을 내놓을 때 어떤 검색을 수행했는지, 무엇이 반환되었는지, 그리고 추론 과정의 어느 지점에서 문제가 생겼는지 정확히 재현할 수 있습니다. 이 레이어가 없는 팀은 눈을 가린 채 디버깅을 하는 것과 같습니다. 그들은 조정 격차(Coordination Gap)를 실제로 해결하는 것이 아니라, 그저 한동안 운이 좋았을 뿐입니다.

Bedrock AgentCore 실시간 에이전트 요청 흐름

  1

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

요청이 IAM 범위 권한(IAM-scoped permissions)을 가진 관리형 런타임(managed runtime)으로 진입합니다. 지연 시간(Latency): <50ms. 런타임은 세션 메모리(session memory)와 사용 가능한 도구 레지스트리(tool registry)를 초기화합니다.

↓

  2
...

모델은 파라미터 지식(parametric knowledge)만으로 충분한지, 아니면 실시간 검색(live retrieval)이 필요한지 결정합니다. 결정 지점(Decision point) — 검색/건너뛰기(retrieve/skip) 로직이 잘못될 경우 조정 격차(Coordination Gap)가 발생하는 지점입니다.

↓

  3
...

관리형 검색(Managed search)이 실행됩니다: 질의(query) → 실시간 웹 페치(live web fetch) → 파싱(parse) → 랭킹(rank) → 구조화된 인용 가능 결과(structured citable results). 지연 시간(Latency): 800ms–3s. 모든 사실과 함께 출처(provenance)를 반환합니다.

↓

  4
...

사용자의 충돌 정책(conflict policy, 최신 우선(newest-wins) / 권위 우선(authority-wins))을 사용하여 최신 결과들을 세션 및 장기 메모리(long-term memory)와 대조하여 조정합니다. 대화 턴(turns) 간의 모순을 방지합니다.

↓

  5
...

모델이 근거 있는 답변(grounded answer)을 합성하며, 선택적으로 다른 MCP 노출 도구(MCP-exposed tools: DB, CRM, 코드)를 호출합니다. 모든 도구는 하나의 프로토콜을 사용하므로 글루 코드(glue code)를 최소화합니다.

↓

  6
...