에이전트를 위한 웹 검색은 증거의 경계이다

대규모 언어 모델 (LLM)에 대해 가장 솔직한 사실은 그것들이 항상 약간은 뒤처져 있다는 점입니다.

이것은 모욕이 아닙니다. 그것은 단지 기술의 형태일 뿐입니다. 모델은 훈련되고, 배포되고, 업데이트되고, 라우팅되고, 튜닝되고, 도구로 감싸지며, 결국 어제 일어난 일에 대해 질문을 받게 됩니다. 때로는 모델이 알고 있습니다. 때로는 절반만 알고 있습니다. 때로는 6개월 동안 열어보지 않은 시스템을 설명하는 시니어 엔지니어와 같은 자신감으로 글을 쓰기도 합니다.

그러므로 당연히 에이전트 (Agents)에게는 웹 검색이 필요합니다.

AWS는 이번 주 Amazon Bedrock AgentCore에서 웹 검색 (Web Search) 기능을 발표했습니다. 기본적인 제안은 간단합니다. 고객의 AWS 환경 외부의 외부 검색 제공자에게 쿼리를 보내지 않고도, MCP를 사용하여 AgentCore Gateway를 통해 현재의 웹 결과, 스니펫 (snippets), 소스 URL, 제목 및 발행 날짜를 검색할 수 있는 관리형 도구를 에이전트에게 제공하는 것입니다.

그것은 유용합니다.

하지만 그것이 흥미로운 부분은 아닙니다.

흥미로운 부분은 웹 검색이 "모델이 그렇게 말했다"를 "에이전트가 이 증거를 사용했다"로 바꾼다는 점입니다.

그리고 일단 증거를 확보하게 되면, 새로운 프로덕션 경계 (production boundary)를 갖게 됩니다.

[

]

신선함은 신뢰가 아니다

사람들은 종종 웹 그라운딩 (web grounding)에 대해 이야기할 때 마치 주요 문제가 신선함 (freshness)인 것처럼 말합니다.

모델이 최신 API 변경 사항을 모른다면, 검색하게 하세요. 모델이 오늘의 보안 권고 사항을 모른다면, 검색하게 하세요. 모델이 어제 발표된 제품의 버전을 모른다면, 검색하게 하세요.

그것은 명백한 유스케이스 (use case)이며, 중요합니다.

하지만 신선함은 단 한 종류의 실패만을 해결할 뿐입니다.

에이전트는 신선한 정보를 검색할 수 있지만, 여전히 잘못된 출처를 사용할 수 있습니다. 최신 블로그 게시물은 찾아낼 수 있지만 공식 문서 (official documentation)를 놓칠 수 있습니다. 실제 제약 조건이 가격 페이지 (pricing page)에 있음에도 마케팅 페이지를 인용할 수 있습니다. 기술적으로는 최신이지만 사용자의 계정, 지역, 라이선스 또는 컴플라이언스 경계 (compliance boundary)와는 무관한 뉴스 기사의 스니펫 (snippet)을 가져올 수도 있습니다.

신선함이 정확함을 의미하지는 않습니다.

신선함이 충분함을 의미하지도 않습니다.

신선함이 감사 가능함 (auditable)을 의미하는 것은 절대 아닙니다.

이것이 바로 검색 결과 주변의 메타데이터 (metadata)가 검색 결과 그 자체만큼 중요한 이유입니다. 소스 URL, 제목, 스니펫, 발행 날짜, 검색 시간, 쿼리 (query), 랭킹 (ranking), 그리고 도구의 정체성은 단순한 구현 세부 사항이 아닙니다. 그것들은 답변의 출처 (provenance)의 일부입니다.

에이전트는 단순히 무언가를 "알고" 있었던 것이 아닙니다. 어딘가를 찾아본 것입니다.

그 '어딘가'는 세션 (session)이 종료된 후에도 유지되어야 합니다.

증거는 내구성이 있어야 합니다

에이전트가 일상적인 질문에만 답하는 것이라면, 증거는 일시적 (ephemeral)이어도 괜찮을지 모릅니다.

하지만 에이전트가 엔지니어링 작업, 법률 검토, 고객 지원, 보안 분류 (security triage), 가격 책정, 조달 또는 사고 대응 (incident response)을 돕고 있다면, 증거는 나중에 검토할 수 있을 만큼 충분한 내구성 (durable)을 갖추어야 합니다.

에이전트가 "이전 버전이 최근의 취약점 (vulnerability)에 영향을 받습니다"라는 이유로 의존성 (dependency)을 업그레이드하기 위해 풀 리퀘스트 (pull request)를 여는 상황을 상상해 보십시오. 그것이 맞을 수도 있습니다. 하지만 그것은 지나치게 광범위한 권고 사항이거나, 논란이 있는 CVE, 도달 불가능한 전이적 의존성 (transitive dependency), 또는 패키지 이름 충돌일 수도 있습니다.

디프 (diff)만으로는 충분하지 않습니다.

검토자는 다음과 같은 증거 추적 경로 (evidence trail)를 볼 수 있어야 합니다:

에이전트가 어떤 쿼리를 실행했는지
어떤 결과가 돌아왔는지
어떤 결과를 선택했는지
결과가 언제 검색되었는지
소스가 공식적인지, 제3자인지, 또는 사용자가 생성한 것인지
최종 권장 사항의 어느 부분이 해당 소스에 의존했는지
나중에 해당 소스에 여전히 접근 가능한지

그렇다고 해서 모든 PR에 거대한 인용문의 벽을 세울 필요는 없습니다. 제발 그러지는 마세요.

하지만 플랫폼은 이를 저장해야 합니다. PR(Pull Request)은 그것을 링크할 수 있습니다. 트레이스(Trace)는 그것을 드러낼 수 있습니다. 감사 로그(Audit log)는 그것을 보유할 수 있습니다.

왜냐하면 6주 뒤에 누군가가 에이전트가 왜 특정 완화 조치를 선택했는지 물었을 때, "웹을 검색했습니다"라는 말은 답변이 될 수 없기 때문입니다.

"이 권고안, 이 벤더 페이지, 이 변경 로그(Changelog), 그리고 이 타임스탬프를 사용했습니다"라고 말하는 것이 정답에 더 가깝습니다.

검색은 권한이 부여된 도구가 된다

AWS 발표 내용 중에는 올바른 의미에서 지루하게 느껴지는 또 다른 세부 사항이 있습니다. 바로 웹 검색(Web Search)이 관리형 AgentCore Gateway 도구 타겟(tool target)으로 노출된다는 점입니다.

그것이 바로 제가 프로덕션(Production) 환경에서 기대하는 형태입니다.

웹 액세스는 에이전트가 플랫폼의 나머지 부분에 감지되지 않은 채 무엇이든 묻고, 무엇이든 보내고, 무엇이든 받을 수 있는 마법 같은 사이드 채널(Side channel)이 되어서는 안 됩니다. 그것은 제어 표면(Control surface)을 갖춘 권한이 부여된 도구여야 합니다.

어떤 에이전트가 웹을 검색할 수 있는가? 어떤 리포지토리(Repository)가 해당 도구를 사용할 수 있는가? 어떤 환경이 이를 허용하는가? 프롬프트(Prompt)와 검색 쿼리(Search query)가 로그에 기록되는가? 고객 데이터가 쿼리에 포함될 수 있는가? 허용 목록(Allowlist)이나 차단 목록(Denylist)이 있는가? 도구가 페이지의 원문 콘텐츠, 스니펫(Snippet), 또는 구조화된 메타데이터(Structured metadata)를 반환하는가? 결과가 캐싱(Caching)되는가? 팀이 의사결정에 근거가 된 검색(Retrieval) 과정을 재현할 수 있는가?

에이전트에게 요구되는 작업들을 떠올려 보기 전까지는 이 모든 것이 무겁게 느껴질 수 있습니다.

만약 에이전트가 블로그 포스트를 초안을 작성하고 있다면, 웹 검색은 위험도가 낮습니다. 만약 장애 발생 중에 지원 엔지니어에게 조언을 하고 있다면, 웹 검색은 중간 정도의 위험도를 가집니다. 만약 에이전트가 복구 코드(Remediation code)를 작성하거나, 패키지 버전을 선택하거나, 법률/보안 지침을 해석하고 있다면, 검색은 작업 결과물의 일부가 됩니다.

그 시점에서 웹 검색은 더 이상 단순한 검색(Retrieval)이 아닙니다.

그것은 자동화된 의사결정의 입력값(Input)입니다.

자동화된 의사결정에 들어가는 입력값에는 통제(Control)가 필요합니다.

인용(Citations)만으로는 충분하지 않다

저는 AI 답변에 포함된 인용(Citations)을 좋아합니다. 인용은 환각(Hallucination)을 더 잘 보이게 만들고, 인간이 조사를 시작할 수 있는 지점을 제공합니다.

하지만 인용은 또한 하나의 보여주기식 행위(Theater)가 될 수도 있습니다.

링크가 포함된 답변이라 할지라도 여전히 틀릴 수 있습니다. 링크가 해당 주장의 아주 약한 버전만을 뒷받침할 수도 있습니다. 모델이 잘못된 문장에 대해 올바른 출처를 인용할 수도 있습니다. 검색(Retrieval) 이후에 페이지 내용이 변경되었을 수도 있습니다. 스니펫(Snippet)이 중요한 제한 사항을 누락했을 수도 있습니다. 인용된 출처가 한 번도 확인되지 않은 다른 출처의 요약본일 수도 있습니다.

따라서 기준이 "답변에 링크가 있는가?"가 되어서는 안 됩니다.

더 나은 질문은 이것입니다: 인간이 막연한 느낌(Vibes)으로부터 전체 세션을 재구성하지 않고도 추론 경로(Reasoning path)를 검증할 수 있는가?

에이전트 플랫폼의 경우, 이는 검색 도구가 모델이 답변에 섞어 쓸 텍스트만을 생성하는 것이 아니라 구조화된 증거(Structured evidence)를 생성해야 함을 의미합니다. 주장(Claims)을 출처와 연결할 수 있어야 합니다. 공식 문서와 포럼 게시물을 구분할 수 있어야 합니다. 에이전트가 웹 증거를 사용했는지, 아니면 내부 문서, 메모리, 코드 검색 또는 도구 호출(Tool call)을 사용했는지 확인할 수 있어야 합니다.

이는 웹 그라운딩(Web grounding)이 기업 컨텍스트(Enterprise context)와 만날 때 특히 중요합니다.

에이전트는 공개된 AWS 공지사항을 귀사의 내부 계정 정책과 결합해야 할 수도 있습니다. 또는 Kubernetes 릴리스 노트와 귀사의 클러스터 버전을 결합해야 할 수도 있습니다. 혹은 벤더의 가격 페이지와 귀사의 계약 내용을 결합해야 할 수도 있습니다. 공개된 웹 사실은 단지 하나의 재료일 뿐입니다.

어려운 부분은 사실을 검색(Retrieving)하는 것이 아닙니다.

어려운 부분은 사실 사이의 경계를 가시적으로 유지하는 것입니다.

이것은 리뷰를 변화시킬 것입니다

에이전트가 외부 증거를 더 많이 사용할수록, 리뷰에는 증거의 품질이 포함되어야 할 필요성이 커질 것입니다.

오늘날 리뷰어는 주로 다음과 같이 질문합니다: diff가 정확한가? 테스트를 통과하는가? 설명이 말이 되는가?

웹 그라운딩된 에이전트의 경우, 리뷰어는 다음과 같이 질문해야 할 수도 있습니다: 근거가 되는 증거가 좋았는가?

이것은 짜증스럽게 들릴 수 있는데, 실제로 그렇기 때문입니다. 하지만 새로운 일은 아닙니다. 인간은 이미 이를 비공식적으로 수행하고 있습니다. 우리는 문서를 읽고, 변경 로그(Changelog)를 훑어보고, 이슈를 검색하고, Stack Overflow를 확인하고, 동료에게 물어본 다음, 최종 커밋 메시지에 모든 이야기가 담겨 있는 척합니다.

에이전트는 그 보이지 않는 조사 과정을 제품화할 수 있을 만큼 명시적으로 만들어 줍니다.

플랫폼이 이를 포착할 수 있다면 그것은 좋은 일입니다.

하지만 플랫폼이 세련된 요약(summary) 뒤로 이를 숨겨버린다면 그것은 나쁜 일입니다.

나는 요약도 원하지만, 증거(receipts) 또한 원합니다.

내가 가장 먼저 구축할 것

만약 내가 내부 에이전트 플랫폼에 웹 검색(web search) 기능을 추가한다면, 나는 좁은 범위의 증거 모델(evidence model)부터 시작할 것입니다.

에이전트가 사용하는 모든 검색 결과는 안정적인 ID를 가진 증거 기록(evidence record)이 됩니다. 이 기록에는 쿼리(query), 소스 URL(source URL), 제목(title), 가능한 경우 발행 날짜(publication date), 검색 시간(retrieval time), 스니펫(snippet), 도구 식별자(tool identity), 에이전트 세션(agent session), 그리고 해당 검색이 필요했던 작업(task)이 포함됩니다.

그런 다음, 에이전트가 단순히 산문(prose) 속에 URL을 붙여넣는 것이 아니라, 내부적으로 증거 기록을 인용(cite)하도록 만들 것입니다.

풀 리퀘스트(pull request)나 티켓(ticket)에는 다음과 같이 친숙한 요약이 표시될 수 있습니다:

"2026년 6월 17일의 AWS 출시 게시물과 Bedrock AgentCore Gateway 문서를 사용함."

하지만 추적(trace) 데이터에는 전체 검색 체인(retrieval chain)이 나타날 것입니다.

또한 나는 웹 증거(web evidence)와 내부 증거(internal evidence)를 분리할 것입니다. 공개 블로그 게시물, 비공개 런북(runbook), 코드 검색 결과, 그리고 프로덕션 로그 라인(production log line)은 서로 다른 종류의 진실입니다. 이것들을 구분되지 않은 하나의 컨텍스트 수프(context soup)로 섞어버리는 것이 바로 팀들이 잘못된 이유로 잘못된 것을 신뢰하게 되는 방식입니다.

마지막으로, 나는 증거의 품질을 측정할 것입니다. 에이전트가 어떤 소스를 가장 자주 사용하는가? 어떤 소스가 거부된 작업(rejected work)으로 이어지는가? 어떤 워크플로(workflow)가 권위가 낮은 페이지에 너무 많이 의존하는가? 어떤 에이전트가 내부 문서를 사용해야 할 때 검색을 수행하고 있는가?

이것은 학술적인 논의가 아닙니다.

이것은 "웹 기능이 탑재된 에이전트(web-enabled agent)"가 "더 나은 근거(better grounded)를 갖춘 것"을 의미하는지, 아니면 단지 "링크를 달고 더 자신만만해진 것(more confident with links)"뿐인지를 알아내는 방법입니다.

핵심 결론

에이전트를 위한 웹 검색은 분명히 유용합니다. 모델에는 최신 정보가 필요하며, 팀들은 모든 에이전트 개발자가 무작위적인 검색 API를 프로덕션 워크플로에 직접 연결하는 것을 원하지 않습니다.

AWS가 Bedrock AgentCore Gateway 뒤에 관리형 웹 검색(managed web search)을 배치하는 것은 에이전트 툴링(agent tooling)이 일반적인 플랫폼 인프라(platform infrastructure), 즉 도구(tools), 식별자(identities), 게이트웨이(gateways), 리전(regions), 로그(logs), 정책(policies), 그리고 청구(bills)로 변모하고 있다는 또 다른 신호입니다.

하지만 진짜 제품은 검색이 아닙니다.

진짜 제품은 증거(evidence)입니다.

에이전트가 웹을 기반으로 자신의 작업을 근거(ground)를 둘 수 있게 되면, 플랫폼은 다음과 같은 지루한 질문들에 답해야 합니다: 무엇을 검색했는가, 어디에서 가져왔는가, 언제 가져왔는가, 어떤 신원(identity)으로 가져왔는가, 그리고 그 증거(evidence)가 최종 출력물에 어떻게 영향을 미쳤는가?

그것이 없다면, 웹 검색은 그저 더 최신 방식의 오류를 범하는 수단일 뿐입니다.

그것이 있다면, 웹 검색은 훨씬 더 유용한 무언가가 됩니다. 즉, 에이전트의 행동을 조사(inspect)하고, 이의를 제기(challenge)하며, 개선(improve)하고, 궁극적으로 신뢰(trust)할 수 있는 경계(boundary)가 됩니다.

맹목적으로 믿는 것이 아니라.

영수증(receipts)과 함께 말입니다.

references

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작할 때 20달러(USD)를 받고 싶다면, 이 링크를 사용하세요.