Amazon Bedrock AgentCore 웹검색 2026, 도메인 필터·보안·비용 기준

Amazon Bedrock AgentCore 웹검색 도메인 필터와 보안 게이트웨이 검토 장면 — 사내 AI 에이전트의 웹검색은 검색 품질보다 출처 경계, 날짜 범위, 비용 경보를 먼저 고정해야 한다.

Amazon Bedrock AgentCore 웹검색을 붙일지 검토한다면 질문은 단순하다.

에이전트가 웹을 검색해도 되는 업무와 검색하면 안 되는 업무를 먼저 나눠야 한다.

이번 AWS 업데이트의 핵심은 도메인 필터와 게시일 필터다.

사내 에이전트가 아무 웹 결과나 주워 오지 않도록 호출 단위와 게이트웨이 단위에서 출처 범위를 좁힐 수 있다.

이 글은 신기능 소개가 아니라 사내 AI 플랫폼 담당자가 배포 전에 적어야 할 검토 메모 형식으로 정리했다.

비용, 보안, 출처 인용, 운영 로그를 같은 표에서 확인한다.

핵심 요약

Web Search Tool은 AgentCore Gateway에 붙는 MCP 호환 관리형 커넥터이며, 에이전트는 tools/list와 tools/call 흐름으로 검색 도구를 발견하고 호출한다.
connector version 1.2.0 이후에는 요청마다 include·exclude domain list와 publishedDateFilter를 넘길 수 있고, 각 domain list 한도는 100개다.
AWS 가격 페이지 기준 Web Search는 검색 쿼리 1,000건당 7달러이며, 모델 입력 토큰과 출력 토큰 비용은 선택한 foundation model 가격표에서 따로 계산해야 한다.
규제 산업, 보안 공지 분석, 경쟁사 모니터링처럼 출처 통제가 필요한 업무는 target-level include list와 요청 단위 날짜 필터를 함께 써야 한다.

이 글이 필요한 사람

사내 LLM 또는 AI 에이전트에 최신 웹검색 기능을 붙이려는 AI 플랫폼 담당자.
검색 쿼리와 응답 출처가 외부 검색엔진으로 흘러가는 구조를 피하려는 보안팀.
AWS Bedrock 기반 RAG와 실시간 웹검색을 어디서 나눌지 정해야 하는 아키텍트.
Web Search Tool 가격과 모델 토큰 비용을 분리해 월 예산표를 만들려는 FinOps 담당자.
에이전트 답변에 출처 링크와 게시일 조건을 강제하려는 제품 오너.

AWS 업데이트에서 실제로 바뀐 것

AWS 공지 기준으로 Web Search in Amazon Bedrock AgentCore는 도메인 필터링과 게시일 필터링을 새로 강화했다.

에이전트는 호출마다 포함 도메인, 제외 도메인, 게시일 시작과 끝 범위를 넘길 수 있다.

관리자는 게이트웨이 target 수준에서 allowlist를 둘 수 있고 domain list cap도 목록당 최대 100개까지 늘었다.

이 값은 검색 품질보다 보안 리뷰에서 더 큰 의미가 있다.

리전도 US East, Europe Ireland, Asia Pacific Tokyo로 넓어졌다.

한국 사용자는 Tokyo 리전이 열렸다는 점 때문에 지연시간과 데이터 경로 검토를 다시 할 수 있다.

항목	공식 문서 기준 값	실무 해석	검토 질문	보류 조건
도구 형태	AgentCore Gateway에 붙는 managed connector	검색 API 키와 결과 파싱 코드를 직접 운영하지 않는다	기존 MCP 도구 목록과 충돌하지 않는가	게이트웨이 운영자가 없을 때
호출 흐름	tools/list 후 tools/call	에이전트가 표준 MCP 도구처럼 검색 기능을 발견한다	도구 권한을 agent별로 제한하는가	모든 agent에 일괄 노출할 때
query	최대 200 characters	긴 질문은 검색용 질문과 답변용 프롬프트로 분리해야 한다	검색어 변환 로직을 누가 관리하는가	사용자 원문 전체를 그대로 검색할 때
maxResults	1-25 range, 기본 10	검색 결과 수가 모델 컨텍스트와 비용에 영향을 준다	상위 몇 건만 인용하게 할 것인가	25건을 기본값으로 고정할 때
domainFilter	include·exclude 각각 최대 100 domains	신뢰 출처를 명시하고 원치 않는 도메인을 차단한다	업무별 allowlist가 있는가	include list가 빈 상태일 때
publishedDateFilter	from·to inclusive ISO-8601 UTC	최신 공지와 기간 제한 검색을 안정화한다	게시일 없는 결과를 어떻게 처리하는가	최신성 기준이 문서화되지 않을 때

비용 구조는 검색 쿼리와 모델 토큰을 분리해서 봐야 한다

AWS 가격 페이지 기준 Web Search on AgentCore는 검색 쿼리 1,000건당 7달러로 공개되어 있다.

선불 약정과 최소 요금이 없다는 설명도 같은 가격 페이지에 있다.

다만 웹검색 비용이 전체 에이전트 비용은 아니다.

검색 결과를 읽고 답변하는 foundation model의 입력 토큰과 출력 토큰 비용, Runtime이나 Gateway 사용량, 네트워크 전송비를 따로 잡아야 한다.

비용 항목	공식 숫자 또는 청구 축	예산 계산 방식	입력/출력 토큰 관계	주의할 점
Web Search Tool	$7 per 1,000 queries	월 검색 쿼리 수 ÷ 1,000 × 7달러	검색 자체는 query 기준이고 모델 입력·출력 토큰과 별도다	사용자 질문 하나가 여러 검색으로 쪼개지면 비용이 늘어난다
검색 결과 수	maxResults 1-25, 기본 10	결과 수가 커질수록 모델 입력 context가 늘 수 있다	결과 snippet은 입력 토큰 비용을 밀어 올린다	무조건 25건을 요청하면 비용과 지연시간이 커진다
Runtime microVM	1초 minimum, 128MB minimum memory billing	세션별 active CPU와 peak memory를 추적한다	모델 대기 시간과 도구 호출 시간이 섞인다	장시간 agent loop는 메모리 피크가 예산 변수가 된다
Runtime session	microVM 최대 8시간, Instances 최대 14일	긴 리서치 에이전트는 세션 수명과 저장소 비용을 본다	긴 대화는 입력 토큰 누적도 같이 본다	대화 기록을 무제한 보관하면 비용과 보안 리스크가 늘어난다
Gateway data path	customer-owned VPC egress data processing $0.006 per GB	VPC 연동과 외부 시스템 호출량을 GB 단위로 본다	검색 이후 도구 호출 결과가 입력 토큰으로 들어갈 수 있다	Web Search와 Knowledge Base 요금은 별도 항목이다
Foundation model	선택 모델 공식 가격표 기준 입력 token·출력 token 별도	검색 snippet, 시스템 프롬프트, 대화 기록을 입력 토큰으로 계산한다	출력 길이와 citation 설명이 출력 토큰 비용이다	Web Search 가격만 보고 전체 비용을 승인하면 실패한다

예산표는 사용자를 기준으로 만들면 안 된다.

실제 비용은 사용자 수보다 하루 검색 횟수, 에이전트가 한 질문을 몇 번의 검색으로 쪼개는지, 답변에 넣는 snippet 길이에서 갈린다.

이 조건이면 파일럿을 진행한다.

월 검색 쿼리 예산, 검색 결과 수 기본값, 모델 입력 토큰 상한, 답변 최대 길이를 모두 숫자로 적을 수 있을 때다.

보안팀이 먼저 봐야 할 지점

AWS 문서의 Private by design 설명은 고객 쿼리가 AWS 인프라 안에서 처리되고 제3자 검색엔진으로 보내지지 않는다는 점을 강조한다.

이 문장은 보안 검토의 출발점이지 면제권은 아니다.

사내 업무 질문에는 고객명, 취약점 이름, 미공개 프로젝트, 가격 협상 문구가 섞일 수 있다.

그래서 검색 허용 업무와 차단 업무를 target 단위로 나누는 설계가 필요하다.

target-level include list는 호출 agent가 볼 수 없는 관리 정책으로 둬야 한다.

요청 단위 include list는 편리하지만 agent prompt가 잘못되면 넓은 도메인을 요청할 수 있다.

통제 항목	권장 기본값	로그 필드	담당자	실패 시 영향
도메인 allowlist	업무별 20-50개 trusted domain부터 시작	include_domains, exclude_domains	보안 아키텍트	가짜 출처와 SEO 스팸 결과가 답변에 섞인다
게시일 범위	보안 공지는 최근 30-90일 기준을 명시	published_date_from, published_date_to	업무 오너	오래된 CVE 해설이나 이전 가격표를 최신처럼 인용한다
인용 링크	최종 답변에 URL과 제목 표시를 강제	citation_urls, citation_titles	제품 오너	검색 결과를 근거 없이 요약해 책임 소재가 흐려진다
쿼리 보존	원문 저장 대신 hash와 분류 태그 중심	query_hash, data_classification	개인정보 보호 담당	민감 질의가 로그에 남아 2차 유출 지점이 된다
대량 추출 방지	bulk extraction과 competing index 사용 금지 고지	request_count_by_agent	법무·보안팀	허용 사용 범위를 벗어난 크롤링 도구가 된다

도입 전 아키텍처 순서

업무를 세 종류로 나눈다. 공개 기술 문서 검색, 규제·보안 공지 확인, 경쟁사·시장 모니터링을 같은 gateway target에 섞지 않는다.
각 업무별로 target-level include list와 exclude list를 먼저 작성한다. 요청 단위 필터는 이 관리 정책을 넓힐 수 없다는 원칙을 문서화한다.
검색 쿼리 생성 로직을 별도 함수로 둔다. 사용자 원문 전체를 검색하지 말고 200 characters 제한에 맞는 짧은 검색 질문으로 축약한다.
maxResults 기본값을 5 또는 10으로 시작한다. 답변 품질이 부족할 때만 15, 20, 25로 늘린다.
publishedDateFilter가 필요한 업무는 UTC 날짜 범위를 고정한다. 한국 업무 기준 날짜와 UTC 변환을 로그에 남긴다.
모델 답변에는 citation URL을 반드시 표시한다. 출처가 없거나 허용 도메인 밖이면 답변을 보류한다.
월 쿼리 예산과 모델 입력·출력 토큰 예산을 분리한다. 둘 중 하나가 70%를 넘으면 경보를 보낸다.
PoC 종료 기준을 정한다. 정확도보다 잘못된 출처, 오래된 문서, 비용 초과, 민감 쿼리 로그를 먼저 판정한다.

실무 시나리오 1: 보안 공지 분석 에이전트

보안팀이 취약점 공지를 추적하는 에이전트를 만든다면 allowlist는 벤더 공식 보안 페이지와 CISA 같은 공공 출처부터 시작해야 한다.

커뮤니티 글은 빠르지만 패치 우선순위 근거로 쓰기에는 위험하다.

이 조건이면 검토한다.

publishedDateFilter를 최근 90일로 제한하고, 답변마다 원문 URL과 게시일을 표시하며, CVE 번호와 제품 버전을 별도 검증 단계로 넘길 수 있을 때다.

이 경우는 보류한다.

에이전트가 블로그 글과 포럼 글을 같은 신뢰도로 요약하거나, 허용 도메인 밖의 결과를 근거로 패치 우선순위를 제안할 때다.

실무 시나리오 2: 개발자 지원 문서 검색

개발자 지원 에이전트는 공식 문서, 릴리스 노트, SDK 레퍼런스를 빠르게 찾아주는 용도로 맞다.

여기서는 검색 범위보다 최신성과 버전 조건이 더 중요하다.

이 조건이면 검토한다.

include list를 docs와 release note 도메인으로 좁히고, 답변에 버전명과 확인일을 넣으며, 코드 예제는 공식 문서 링크와 함께 제시할 때다.

이 경우는 보류한다.

에이전트가 Stack Overflow류 답변을 최신 SDK 공식 절차처럼 보여주거나, 문서 버전이 다른 예제를 배포 스크립트에 섞을 때다.

실무 시나리오 3: 시장·경쟁사 모니터링

경쟁사 모니터링은 Web Search Tool의 도메인 필터가 특히 잘 맞는 업무다.

경쟁사 공식 블로그, 가격 페이지, 릴리스 노트만 include하면 신호가 더 깨끗해진다.

다만 이 업무는 bulk extraction 금지와 경쟁 인덱스 구축 금지 조건을 검토해야 한다.

결과를 장기 저장해 내부 검색 DB로 만드는 구조는 법무 검토 없이 진행하면 안 된다.

이 조건이면 검토한다.

요약 결과만 저장하고 원문 URL, 제목, 게시일, 확인일을 남기며, 원문 본문을 대량 복제하지 않는 구조일 때다.

운영 체크리스트

Gateway target별 owner, reviewer, allowed domains, excluded domains, connector version을 CMDB나 IaC 저장소에 기록한다.
검색 쿼리 원문은 기본 저장하지 않고 hash, 업무 분류, domain filter, 날짜 범위, 결과 URL만 남긴다.
사용자에게 보여주는 답변에는 최소 2개 이상의 citation URL을 요구하고, citation이 없으면 답변을 보류한다.
모델 입력 토큰 상한과 검색 결과 수 상한을 동시에 둔다. 한쪽만 제한하면 비용 예측이 빗나간다.
월 1회 allowlist를 재검토한다. 인수합병, 도메인 변경, 문서 이관이 있으면 include list가 오래될 수 있다.
Tokyo 리전 사용 시 조직의 데이터 분류와 리전 정책을 다시 확인한다. 리전이 가깝다는 이유로 보안 승인을 생략하지 않는다.

실무 스켈레톤: 정책과 비용 경보를 같이 둔다

아래 YAML은 바로 배포하는 설정이 아니라 검토 기준을 고정하기 위한 정책 스켈레톤이다.

실제 필드명, IAM 권한, CLI 명령은 AWS 공식 문서와 배포 리전에서 다시 확인해야 한다.

# agentcore-web-search-governance.yaml
# 목적: 사내 AI 에이전트가 Web Search Tool을 호출할 때 출처, 날짜, 비용, 로그 기준을 먼저 고정한다.
# 실제 필드명과 IAM 권한은 AWS 공식 문서와 배포 리전 기준으로 다시 확인한다.

gateway_target:
  connector_id: web-search
  connector_version: '1.2.0-or-later'
  admin_domain_policy:
    include:
      - aws.amazon.com
      - docs.aws.amazon.com
      - vendor.example.com
    exclude:
      - untrusted-forum.example
  max_domains_per_list: 100

request_policy:
  query_max_characters: 200
  max_results_range: '1-25'
  published_date_filter:
    from: '2026-08-01T00:00:00Z'
    to: '2026-08-20T23:59:59Z'
  require_source_citations: true
  block_bulk_extraction: true

cost_guardrail:
  web_search_price: '$7 per 1,000 queries'
  monthly_query_budget: 30000
  alert_threshold_ratio: 0.7
  separate_model_token_cost: true

security_review:
  owner: ai-platform-team
  reviewer: security-architecture
  log_fields:
    - agent_id
    - user_id_hash
    - query_hash
    - include_domains
    - exclude_domains
    - published_date_range
    - citation_urls
  hold_when:
    - target-level include list is empty for regulated workflow
    - citation URLs are not shown to the end user
    - model prompt can override domain policy

요청 단위 필터는 agent가 직접 넓힐 수 있는 권한이 아니다.

target-level include list가 있으면 요청 include list와 교집합만 결과로 돌아온다는 점을 테스트 케이스에 넣는다.

{
  "query": "vendor product security advisory August 2026",
  "maxResults": 10,
  "filters": {
    "domainFilter": {
      "include": ["vendor.example.com", "docs.example.com"],
      "exclude": ["community.example.com"]
    },
    "publishedDateFilter": {
      "from": "2026-08-01T00:00:00Z",
      "to": "2026-08-20T23:59:59Z"
    }
  }
}

비용은 Web Search 쿼리 수와 모델 입력·출력 토큰을 분리해 계산해야 한다.

아래 예시는 1,000 queries당 7달러 기준의 경보 틀이다.

# agentcore_web_search_budget_check.py
# 목적: Web Search Tool 호출량과 모델 토큰 비용을 분리해서 월 예산 경보를 계산한다.
# 실제 모델 입력/출력 토큰 단가는 선택한 foundation model의 공식 가격표에서 별도 입력한다.

from dataclasses import dataclass

@dataclass
class Workload:
    name: str
    users: int
    searches_per_user_per_day: int
    business_days: int = 22

WEB_SEARCH_USD_PER_1000_QUERIES = 7.0
MODEL_INPUT_USD_PER_1M_TOKENS = 0.0
MODEL_OUTPUT_USD_PER_1M_TOKENS = 0.0

workloads = [
    Workload('support-knowledge-agent', users=45, searches_per_user_per_day=8),
    Workload('security-advisory-agent', users=8, searches_per_user_per_day=25),
]

for workload in workloads:
    queries = workload.users * workload.searches_per_user_per_day * workload.business_days
    web_search_cost = queries / 1000 * WEB_SEARCH_USD_PER_1000_QUERIES
    print(workload.name, queries, round(web_search_cost, 2))