Amazon Nova Act는 웹 페이지를 이해하고 그에 따라 행동할 수 있습니다. 2026년에 프로덕션 웹 에이전트의 어려운 부분은 모델이 아니라 웹 액세스입니다. 즉, 올바른 지역 타겟팅과 규정 준수를 유지하면서 라이브 웹에 안정적으로 접근하는 것입니다. 이 글은 Nova Act와 Bright Data의 AI 에이전트용 웹 액세스 레이어를 결합하며, 여기서 제시된 측정값은 실제 실행에서 나온 것입니다.
TL;DR
프로덕션 AI 웹 에이전트의 병목은 모델이 아닌 웹 액세스입니다. 해결책은 분리입니다. Amazon Nova Act는 다단계 브라우저 결정을 담당하고, Bright Data의 웹 액세스 레이어는 접근, 규정 준수, 확장성을 처리합니다. Bright Data의 Data for AI 2026 보고서에 따르면 AI 조직의 97%가 실시간 웹 데이터에 의존하며, 90%는 접근 제한이 AI 이니셔티브를 제한하고 있다고 말합니다.
모든 임포트, 스키마, 헬퍼를 포함한 완전히 실행 가능한 스크립트는 companion repo에 있습니다. 실행하려면 여기서 복사-붙여넣기하지 말고 해당 저장소를 클론하세요.
따라 하려면 Python 3.10+, pip install nova-act, 그리고 nova.amazon.com/act에서 Nova Act API 키가 필요합니다. 또한 Browser API 존이 있는 Bright Data 계정과 데이터 레이어 호출을 위한 API 키도 필요합니다. Node.js는 Web MCP 섹션에서만 필요합니다.
브라우저 에이전트 기본값이 부족한 이유
브라우저 에이전트의 명확한 접근 방식은 모든 것을 직접 처리하게 하는 것입니다. 페이지를 열고, 쿠키 배너를 닫고, 스크롤하고, 추출합니다. 데모에서는 좋아 보이지만, 대부분의 데이터 작업에서는 잘못된 기본값입니다.
- 무겁습니다. 실제 소비자 페이지 하나(eBay 검색)가 브라우저를 통해 약 3.4 MB를 전송했습니다. 수백만 페이지에 곱하면 세 개의 필드를 추출하기 위해 이미지를 포함한 렌더링된 전체 웹을 이동하는 비용을 지불하게 됩니다.
- 실행 시 불안정합니다. booking.com을 대상으로 했을 때, Nova Act는 팝업과 지연 로딩 콘텐츠와 씨름하면서
ActActuationError를 발생시켰습니다. 페이지는 정상적으로 로드되었음에도 불구하고요. 단순 읽기는 보통 안정적입니다. 무거운 다단계 실행은 그 곳에서 무너집니다. - 비결정적입니다. 신뢰성이 빠르게 떨어집니다. 90% 신뢰성의 10단계는 계획하지 않으면
0.9¹⁰ ≈ 35%에 가까운 결과가 나옵니다.
이것이 브라우저 에이전트를 쓸모없게 만들지는 않습니다. 따라서 오직 그것만 할 수 있는 것(다단계 행동과 결정)에 사용하고, 나머지는 모두 인프라로 넘기세요.
Amazon Nova Act란 무엇이고, 무엇이 아닌가
Nova Act는 2026년 중반 버전 3.4.x로, 리서치 프리뷰에서 프로덕션으로 이동 중인 AWS SDK로, Python으로 브라우저 에이전트를 구축하기 위한 것입니다. 설계 아이디어는 하나의 거대한 프롬프트와 반대입니다. 워크플로를 작고 원자적이며 신뢰할 수 있는 명령으로 나누고 일반 Python으로 연결합니다. 두 가지 명령은 액션과 타입된 읽기입니다:
from nova_act import NovaAct
from pydantic import BaseModel
class Product(BaseModel):
title: str | None = None
price: str | None = None
availability: str | None = None
with NovaAct(starting_page="https://example.com/product/123") as nova:
nova.act("search for wireless headphones") # an action
data = nova.act_get( # a typed read
"Return the product title, price, and availability.",
schema=Product.model_json_schema(),
)Pydantic 스키마를 사용하면 act_get이 취약한 셀렉터 없이 페이지를 타입된 데이터로 변환할 수 있습니다. Nova Act는 내부적으로 Playwright를 통해 실제 Chromium을 구동합니다. 이는 연결에 중요한 세부 사항입니다. Nova Act는 추론, 탐색, 구조화된 추출을 제공합니다. 하지만 열린 웹의 적대성에 대한 답은 제공하지 않습니다. 지역 도달, 대규모 차단 해제, 내장된 규정 준수가 없습니다. 그것은 Nova Act의 역할이 아닙니다. 인프라 레이어의 역할입니다.
Bright Data, 웹 액세스 레이어
이 레이어는 하나의 아이디어를 중심으로 구축되었습니다: AI를 위한 웹 잠금 해제. Web MCP는 모델 컨텍스트 프로토콜 서버로, 에이전트에게 직접 호출할 수 있는 구조화된 웹 도구를 제공합니다. Web Unlocker와 SERP API는 깔끔한 페이지와 검색 결과를 반환합니다. Web Scraper API와 데이터셋은 대량 구조화 검색을 수행합니다. Browser API는 에이전트가 행동해야 할 때 원격으로 구동하는 클라우드 Chrome입니다. 내부에는 195개국에 걸친 4억 개 이상의 주거용 IP 네트워크가 있으며, 일반적인 CAPTCHA 챌린지, 지문 관리, 지역 타겟팅이 처리됩니다.
Bright Data의 Data for AI 2026 설문조사에서 조직의 87%가 “이중 인터넷”이 등장하고 있다는 데 동의했으며, 이는 인간의 인터넷과 나란히 운영되는 자동화된 트래픽의 에이전트 웹입니다. 그리고 65%는 이미 자체 구축 대신 전용 웹 데이터 인프라 제공업체에 의존하고 있습니다.
이것은 도구가 아닌 레이어입니다. 에이전트 스택은 변합니다. 그 아래의 웹 액세스 레이어는 변하지 않습니다. 따라서 엔지니어링 질문은 추상적으로 브라우저 대 API가 아닙니다. 작업을 둘로 나눕니다: 에이전트는 결정을 처리하고, 인프라는 액세스를 처리합니다.
아키텍처, 상단의 두뇌와 하단의 인프라
Nova Act는 액션을 아래로 전송하고, 구조화된 데이터가 반환됩니다.
Nova Act는 결정과 액션을 담당합니다. Bright Data의 웹 액세스 레이어는 액세스, 규정 준수, 지역, 확장성을 처리한 다음 라이브 웹에 접근합니다.
액션 모드의 경우, Nova Act는 Chrome DevTools Protocol (CDP)을 통해 Bright Data의 Browser API에 연결합니다. 이는 Playwright(따라서 Nova Act)가 이미 사용하는 동일한 프로토콜입니다. 브라우저를 교체하고 에이전트는 유지합니다.
연결 설정과 예상되는 설정 오류
Browser API 존을 생성하면(기본적으로 CAPTCHA 솔버가 켜져 있음) 대시보드가 URL을 제공합니다:
wss://brd-customer-<id>-zone-<name>:<password>@brd.superproxy.io:9222해당 문자열은 존의 개요 탭, 액세스 세부 정보에서 확인할 수 있습니다.
Browser API 존의 액세스 세부 정보입니다. 대시보드는 인라인 자격 증명이 포함된 wss:// 문자열을 제공합니다. 패널 상단에 표시된 auth+@host 형식입니다. 최신 Playwright는 해당 인라인 형식을 거부하므로 split_cdp()가 자격 증명을 Authorization: Basic 헤더로 이동합니다. 왼쪽의 IP 허용 목록은 또 다른 함정입니다. IP가 목록에 없으면 호출이 빈 본문을 반환하고 이유가 상태 코드가 아닌 응답 헤더에 도착합니다.
Invalid URL 오류: Playwright가 인라인 wss:// 자격 증명을 거부합니다
그것을 Nova Act에 직접 붙여넣으면 실패합니다:
playwright._impl._errors.Error: BrowserType.connect_over_cdp:
Invalid URL: wss://brd-customer-...:[email protected]:9222이것은 일반적인 첫 실행 실패입니다. Nova Act 3.4에 번들된 최신 Playwright 버전 1.56은 WebSocket URL에 내장된 자격 증명을 거부합니다. 대시보드가 인라인 형식을 표시하는 것은 이전 클라이언트에서 작동하기 때문이지, Nova Act 내부의 Playwright에서는 아닙니다. 수정 방법은 자격 증명을 제거하고 cdp_headers를 통해 Authorization: Basic 헤더로 전달하는 것입니다.
import os
import base64
def split_cdp(raw_url: str) -> tuple[str, dict | None]:
"""Bright Data gives an inline-credential wss URL; Playwright rejects that.
Move credentials into a Basic auth header. (Parsed manually because
Python 3.14's urlsplit also rejects the multi-colon netloc.)"""
scheme, sep, rest = raw_url.partition("://")
if not sep or "@" not in rest:
return raw_url, None
creds, _, hostport = rest.rpartition("@")
user, _, pwd = creds.partition(":")
token = base64.b64encode(f"{user}:{pwd}".encode()).decode()
return f"{scheme}://{hostport}", {"Authorization": f"Basic {token}"}
endpoint, headers = split_cdp(os.environ["BRIGHTDATA_CDP_URL"])
with NovaAct(starting_page=URL, cdp_endpoint_url=endpoint, cdp_headers=headers,
logs_directory="runs/demo") as nova: # NOTE: logs dir must already exist
...간헐적 InvalidScreenResolution 함정
또 다른 큰 함정은 뷰포트입니다. Bright Data의 원격 브라우저는 Nova Act에 약 1280×585 창을 제공하는데, 이는 Nova Act가 예상하는 약 1600×900보다 작습니다. Nova Act는 우아하게 저하되지 않습니다. 간헐적으로 하드 InvalidScreenResolution ActError를 발생시킵니다. 각 클라우드 세션이 약간 다른 크기를 얻기 때문에 간헐적입니다. 이로 인해 진단이 어렵고, 재시도가 필요한 불안정한 에이전트로 잘못 읽기 쉽습니다. 연결된 페이지에 지원되는 크기를 강제로 설정하세요:
with NovaAct(starting_page=URL, cdp_endpoint_url=endpoint, cdp_headers=headers,
screen_width=1600, screen_height=900, logs_directory="runs/demo") as nova:
nova.page.set_viewport_size({"width": 1600, "height": 900}) # force a supported size to stop InvalidScreenResolution
...두 가지 작은 함정: StartFailed와 누락된 logs_directory
cdp_endpoint_url과 함께 headless=True를 전달하지 마세요. 원격 브라우저는 이미 헤드리스이며 StartFailed가 발생합니다. 그리고 logs_directory는 시작 전에 존재해야 합니다. Nova Act가 경로를 검증하며 생성하지 않기 때문입니다.
에이전트의 용도
연결이 완료되면, 에이전트에게 무엇을 시킬지가 문제입니다. 단순 읽기는 에이전트가 제공하는 가장 덜 독특한 기능이며, Bright Data의 Web Scraper API가 더 잘하고 저렴하게 처리합니다. 에이전트는 행동할 수 있기 때문에 스크레이퍼보다 더 가치 있습니다.
가장 유용한 액션은 폼 뒤의 데이터에 접근하는 것입니다. 미리 알 수 있는 정적 URL도 없고 API도 없으므로 스크레이퍼가 접근할 방법이 없습니다. 에이전트는 폼을 채우고 결과를 읽을 수 있습니다. 그래서 우리는 Nova Act를 미국의 공식 약물 승인 데이터베이스인 Drugs@FDA에 지정하고 약물 기록을 검색하도록 요청했습니다:
nova.act("Search for the drug named ibuprofen") # fill the form, submit
drug = nova.act_get("Return the brand name, active ingredient, application number, "
"and marketing status of the first result.", schema=Drug.model_json_schema())자체 추적은 어떤 URL도 캡처할 수 없는 4단계 흐름을 보여줍니다. 검색 상자에 입력하고 Enter를 눌렀고, 첫 번째 결과가 접힌 상태로 발견되어 클릭하여 펼쳤고, 세부 정보 페이지로 이동한 다음 필드를 읽었습니다:
{'drug_name': 'ACETAMINOPHEN AND IBUPROFEN', 'active_ingredient': 'ACETAMINOPHEN; IBUPROFEN',
'application_number': '214836', 'marketing_status': 'Over-the-counter'} # all 4 DOM-grounded브라우저에서의 4단계:
프레임별 실제 실행 녹화입니다. Nova Act는 Drugs@FDA에서 “ibuprofen”을 검색하고, 첫 번째 결과를 열고, 실행이 반환한 동일한 신청 번호인 ANDA #214836을 읽습니다.
일관성을 확인하기 위해 다른 약물들로도 실행했습니다. aspirin은 8-HOUR BAYER (#016030)를, metformin은 ACTOPLUS MET (#021842)를 반환했습니다. ibuprofen을 포함하면 3/3, 모든 필드가 근거 있음. 이것이 에이전트가 비용을 정당화하는 부분입니다. 에이전트는 스크레이퍼가 접근할 수 없는 폼으로 보호된 공개 데이터에 접근하기 위해 폼을 채우고 탐색합니다. AI를 딥 웹 공개 데이터에 근거시키는 것은 실제 문제입니다. 협력적이고 잘 구조화된 사이트에서는 신뢰할 수 있습니다.
롱 테일
동일한 접근 방식이 롱 테일, 즉 사전 구축된 스크레이퍼가 없는 틈새 사이트를 다룹니다. Bright Data의 Web Scraper API는 이미 100개 이상의 고가치 사이트를 다룹니다. BoardGameGeek을 대상으로 했을 때, Nova Act는 깔끔한 6개 필드 레코드를 반환했습니다. Catan / 1995 / 3,4 players / 60,120 min / rating 7.1 / lowest price. 같은 세션에서 Playwright 핸들인 nova.page를 통해 라이브 DOM에 대해 검증할 수 있습니다:
assert game.parsed_response["bgg_rating"] in nova.page.inner_text("body") # 7.1 -> present두 가지 근거 교훈이 나왔습니다. 비교 전에 정규화하세요. 페이지의 en-dash 3,4와 에이전트의 하이픈 3-4는 환각이 아닌 잘못된 불일치입니다. 그리고 세션 내에서 검증하고, 나중에는 절대로 하지 마세요. 라이브 마켓플레이스 가격은 추출 시점에 근거가 있었지만 새로고침 시 사라졌으므로, 휘발성 데이터의 두 번째 검사는 틀릴 수 있습니다. 이를 통해 6개 필드 모두 근거가 확인되었습니다. 5개의 동시 실행에서도 유지되었습니다.
경계는 작업이 아닌 지형에 관한 것입니다. Nova Act는 eBay나 booking.com 같은 적대적인 소비자 사이트에서 어려움을 겪습니다. 쿠키 벽, 맞춤형 변형 위젯, 지연 로딩 콘텐츠가 있는 봇 방어 이커머스입니다. 이러한 사이트에서 다단계 액션은 느려지고 불안정해지며, 무거운 체인은 타임아웃됩니다. 공개 데이터베이스, 내부 앱, 잘 구축된 폼과 같은 협력적이고 구조화된 사이트에서는 신뢰할 수 있습니다. 적대적인 소비자 사이트에서는 취약합니다. 액션을 적게 유지하고, nova.page로 모든 필드를 검증하고, 재시도하고, 적대적이고 대용량 케이스는 Bright Data의 데이터 레이어가 처리하도록 하세요.
지역 라우팅이 실제로 변경하는 것
동일한 라우팅 인프라 없이는 어떤 로컬 브라우저도 이를 수행할 수 없습니다. Bright Data 사용자 이름에 -country-XX를 추가하여 세 국가를 통해 라우팅하면서 주요 예약 사이트에서 동일한 호텔 검색을 실행했습니다:
| 라우팅 국가 | 통화 | 샘플 1박 요금 |
|---|---|---|
| 미국 | US$ | US$30, US$128, US$171 |
| 영국 | £ | £30, £167, £194 |
| 독일 | € | €40, €194, €225 |
통화가 깔끔하게 전환되고 가격은 변환이 아닌 실제 시장 차이를 반영합니다. 지역은 인프라의 역할이지 에이전트의 역할이 아니기 때문에, 이 세 가지를 원시 브라우저로 읽었습니다. 에이전트는 US 라우팅 eBay 실행과 동일하게 지정된 시장에서 추출합니다. 이것은 경쟁적 가격 모니터링, 운임 집계, 또는 현지 고객처럼 볼 필요가 있는 모든 경우에 중요합니다.
실행에서 중요한 것은 어떤 IP에서 나가는지이므로, 각 라우팅 세션을 확인했습니다. 출구 IP는 데이터센터 범위가 아닌 실제 소비자 ISP로 반환되었습니다: 미국 주요 케이블 제공업체, 영국 브로드밴드 통신사, 독일 모바일 네트워크, 일본 통신사, 브라질 지역 ISP.
이것이 현지처럼 보이는 것과 실제로 현지인 것의 차이입니다. 요청은 해당 국가의 실제 주거용 사용자로 도착합니다. 따라서 가격, 재고, 봇 방지 처리가 표시된 데이터센터 범위가 받는 것보다 현지 고객이 보는 것에 훨씬 가깝습니다.
규정 준수, 90% 문제
여기서 액세스 제한이 중요합니다. 90% 문제 자체: 대부분의 AI 조직은 해당 제한이 AI 이니셔티브를 제한하고 있다고 말합니다. 여기서 Bright Data가 가드레일 역할을 합니다. 항공권 메타검색 사이트를 지정했을 때 에이전트가 거부당했습니다:
Page.navigate: Requested URL (kayak.com/flights/...) is restricted in accordance
with robots.txt. Ask your account manager to get full access (brob)로컬 원시 브라우저는 조금 전에 문제 없이 동일한 사이트를 스크레이핑했습니다. Bright Data는 거부했습니다. 거부하는 것이 더 약한 동작이 아닌 더 유능한 동작입니다. Bright Data는 기본적으로 robots.txt를 적용하고 민감한 대상을 Know Your Customer (KYC) 검사 뒤에 게이팅합니다. 이는 기업 법무팀이 승인할 수 있는 접근 방식입니다.
대부분의 기업 대상에서는 문제없습니다. 확인에서 booking.com, Expedia, Hotels.com, Airbnb, eBay, Best Buy, Tripadvisor가 모두 통과했습니다. 제한된 것들은 우회 방법이 아닌 계정 관리자와의 대화입니다. 인프라가 액세스 측 규정 준수를 처리하므로 코드가 처리할 필요가 없습니다.
비용 및 신뢰성 예산
구매 검토자는 두 가지 질문을 합니다: 얼마나 신뢰할 수 있는지, 그리고 비용이 얼마인지입니다.
신뢰성
신뢰성에는 하나의 주요 레버와 하나의 하드 상한이 있습니다. 레버는 뷰포트 수정입니다. 설정 전에는 모든 실행의 약 절반이 InvalidScreenResolution으로 실패했으며, 이 하나의 버그가 불안정한 에이전트처럼 보였던 대부분의 원인이었습니다.
수정 후 샌드박스가 아닌 실제 사이트에서 측정했습니다. 5개의 동시 eBay 읽기는 5/5를 반환했으며, 모든 값이 nova.page를 통해 라이브 DOM에서 확인되었고, 순차적 약 198초 대비 47초, 4.2배였습니다. 각 세션은 새로운 Bright Data IP에서 실행되어 단일 IP에 요청이 집중되는 것을 방지합니다.
이것이 무료 선형 확장이 아닙니다. 12개의 동시로 밀었을 때 12개 중 8개가 깨끗하게 반환되었습니다. 이것은 에이전트가 아닌 무료 및 종량제 티어의 동시성 상한입니다. 실제 기업 볼륨은 아무것도 없이 5개 세션이 5천 개로 확장된다고 가정하지 않고, 존의 동시성 제한을 높이고 재시도를 예산에 포함하는 것을 의미합니다.
동시성의 이득은 실제이지만 선형이 아닙니다. 플랜의 동시성 상한을 넘으면 12개의 동시 읽기 중 8개가 깨끗하게 반환되었습니다.
단일 경량 액션(정렬 후 읽기)은 가끔 재시도가 필요했으며, 남은 실패는 세션 시작 시 일시적인 StartFailed였습니다. 따라서 작업을 작은 멱등성 단계로 나누고, 재시도로 감싸고, 약 1.2~1.5배를 예산에 포함하고, 모든 출력을 nova.page로 검증하세요.
나머지 제한은 지형입니다. 구조화된 측에서는 신뢰할 수 있습니다. 세 번의 Drugs@FDA 조회는 각각 동일한 흐름을 실행했습니다: 채우기, 제출, 클릭-펼치기, 탐색, 추출. 각각 약 50~90초로 느리지만 세 번 모두 3/3, 모든 필드 근거 있음으로 반환되었습니다. 소비자 측에서는 다단계 체인이 여전히 느려지고 타임아웃됩니다.
하나의 뷰로 본 신뢰성 수치:
| 시나리오 | 결과 | 의미 |
|---|---|---|
| 뷰포트 수정 전 | ~절반의 실행 실패 | InvalidScreenResolution, 지배적 실패 |
| 수정 후 5개 동시 읽기 (eBay) | 5/5 근거 있음 | 순차적 ~198초 대비 47초, 4.2배, 세션당 새 IP |
| 12개 동시로 확장 (원시) | 8/12 | 에이전트가 아닌 종량제 동시성 상한 |
| 단일 경량 액션 (정렬 후 읽기) | 가끔 재시도 | 실패는 재시도 가능한 StartFailed |
| 다단계 FDA 폼, 약물 3개 | 3/3 근거 있음 | 협력적 사이트이나 각각 ~50~90초로 느림 |
비용
대역폭 비용은 측정 가능하며, 모델 비용은 미결 질문입니다. Browser API는 GB당 과금되며, 종량제 기준 약 $8/GB입니다(여기의 모든 가격은 2026년 중반 기준). 실제 페이지 무게를 측정했습니다:
| 페이지 유형 | 무게 | Browser API @ $8/GB |
|---|---|---|
| 무거운 소비자 페이지 (eBay 검색) | ~3.4 MB | ~$0.027/페이지 → ~$27 / 1,000페이지 |
| 가벼운 페이지 (샌드박스 제품) | ~0.2 MB | ~$0.0016/페이지 → ~$1.60 / 1,000페이지 |
재시도 배수를 더한 다음 Nova Act의 추론 비용을 추가합니다. 오늘날 공개적으로 가격이 책정되지 않았습니다. 무료 티어는 수집량을 측정하며, 프로덕션은 공개된 가격 없이 AWS를 통해 실행됩니다. 따라서 예산은 두 줄로 나뉩니다. Browser API 대역폭은 알려진 예측 가능한 항목입니다. 에이전트의 추론은 확장 전에 AWS에서 확인해야 하는 비용입니다.
세 개의 필드를 추출하기 위해 3.4 MB를 이동하는 것은 대량 작업에서 브라우저를 전혀 구동하지 않는 이유이기도 합니다. 데이터 레이어는 GB당이 아닌 요청당 과금됩니다. SERP API와 Web Unlocker는 브라우저를 통한 무거운 페이지 1,000개당 ~$27 대비 1,000개당 약 $1.50입니다.
에이전트를 언제 사용하고, 데이터 레이어를 언제 사용할지
Bright Data는 모든 것에 브라우저를 구동하지 않도록 Web MCP와 Web Scraper API를 제공합니다. 구분선은 결정 복잡성입니다:
- 고정된 알려진 스키마 풀, 예를 들어 100,000개 SKU의 가격과 재고. 에이전트를 사용하지 마세요. Web Scraper API는 3.4 MB 페이지 없이, 추론 비용 없이, 훨씬 적은 일시적 실패로 레코드만 반환합니다. 더 저렴하고 더 신뢰할 수 있습니다.
- 스크레이핑이 캡처할 수 없는 추론: 다단계 탐색, 조건부 로직(예: 제약 조건을 충족하는 가장 저렴한 환불 가능 운임), 폼 제출, 웹 앱 QA, 또는 사전 구축된 스크레이퍼가 없는 낯선 포털. 여기가 Nova Act와 Browser API가 비용을 정당화하는 곳입니다.
규칙: 고정 스크레이핑이나 API 호출로 표현할 수 있다면 그렇게 하세요. 실제 시스템에서는 두 가지가 구성됩니다. Nova Act가 결정 흐름을 구동하고 대량 검색을 Bright Data의 구조화된 API로 전달합니다.
실제 데이터 레이어
“대량 작업에는 데이터 레이어를 사용하라”는 것이 일반적인 조언입니다. 동일한 Bright Data 계정으로 실행한 세 번의 호출, 브라우저 없음, 에이전트 없음입니다.
한 번의 호출로 구조화된 검색 (SERP API), AI를 근거시키기 위한 신선한 파싱된 검색 결과, JSON으로 반환:
requests.post("https://api.brightdata.com/request",
headers={"Authorization": f"Bearer {BRIGHTDATA_TOKEN}"},
json={"zone": "serp_api2", "format": "raw", # gl/hl pin the locale so results are stable
"url": "https://www.google.com/search?q=amazon+nova+act+sdk&brd_json=1&gl=us&hl=en"})9 organic results → 1. github.com/aws/nova-act · 2. nova.amazon.com/act · 3. docs.aws.amazon.com/nova-act …모든 URL을 깔끔한 LLM 준비 마크다운으로 (Web Unlocker), 에이전트가 폼을 채워 접근한 동일한 FDA 약물 기록을 직접 가져옴:
json={"zone": "web_unlocker", "format": "raw", "data_format": "markdown",
"url": "https://www.accessdata.fda.gov/.../ApplNo=214836"}→ 8.4 KB의 깔끔한 마크다운, 한 번의 호출, 브라우저 없음, CAPTCHA 처리 없음, 파싱 없음.알려진 소스에서 구조화된 레코드만 (Web Scraper API), 사전 구축된 수집기를 트리거하고 깔끔한 필드를 얻음, 페이지 없음. 한 회사에 대해 Crunchbase 스크레이퍼를 실행했습니다:
requests.post("https://api.brightdata.com/datasets/v3/trigger?dataset_id=gd_l1vijqt9jfj7olije",
headers={"Authorization": f"Bearer {BRIGHTDATA_TOKEN}"},
json=[{"url": "https://www.crunchbase.com/organization/anthropic"}]) # -> snapshot_id, then poll→ 89개의 구조화된 필드 (직원 수, 본사, CB 순위, 상태, 자금 조달…),
~70초 내 준비 완료, 브라우저 없음, 에이전트 없음, 3.4 MB 페이지 없음, 파싱 없음.대조가 아키텍처입니다. 에이전트는 여기서 데이터에 접근하기 위해 행동해야 했기 때문에 적합한 도구였습니다. URL이 존재하지 않았으므로 폼을 검색하고 신청 214836으로 탐색했습니다. URL이 존재하거나 검색 결과 또는 대량의 알려진 스키마 레코드가 필요한 경우 브라우저를 구동하지 않습니다. 데이터 레이어를 호출합니다. 더 결정론적이고, 더 빠르고, 더 저렴하며, 에이전트의 신뢰성 예산이 훨씬 적게 필요합니다. Nova Act는 발견하고 행동합니다. Bright Data의 데이터 레이어는 대규모로 검색합니다.
에이전트가 Bright Data의 도구를 직접 호출합니다
지금까지의 통합은 수동으로 조율되었습니다. SERP와 Web Unlocker를 호출한 다음 에이전트에게 브라우저를 전달했습니다. 더 긴밀한 통합이 있습니다. Nova Act에 Bright Data의 Web MCP 서버를 도구로 제공하면, 에이전트 자체가 언제 검색하고, 스크레이핑하고, 발견할지 결정합니다. Nova Act는 AWS의 Strands 프레임워크에서 실행되므로 MCP 도구를 직접 수락합니다:
from strands.tools.mcp import MCPClient
from mcp import StdioServerParameters
from mcp.client.stdio import stdio_client
bd_mcp = MCPClient(lambda: stdio_client(StdioServerParameters(
command="npx", args=["-y", "@brightdata/mcp"], env={"API_TOKEN": BRIGHTDATA_TOKEN})))
with bd_mcp:
tools = bd_mcp.list_tools_sync() # search_engine, scrape_as_markdown, discover, batch…
with NovaAct(starting_page="https://example.com", tools=tools,
cdp_endpoint_url=endpoint, cdp_headers=headers) as nova:
nova.act_get("Use the search_engine tool to find 'Amazon Nova Act SDK'; "
"return the top result's URL.", schema=Out.model_json_schema())실행했을 때 에이전트 자체 추적이 보여줍니다. “도구 호출이 성공적으로 완료되었고 검색 정보를 반환했습니다. 상위 유기적 결과는 ‘https://github.com/aws/nova-act’입니다…” 그리고 {'top_result_url': 'https://github.com/aws/nova-act'}를 반환했습니다. 에이전트가 Bright Data의 search_engine 도구를 스스로 선택했고, Bright Data가 검색을 실행했으며, 에이전트가 결과를 사용했습니다. 약 32초에 하나의 act 호출이 필요했으며, 브라우저 에이전트가 어차피 차단될 가능성이 높은 검색 페이지의 스크레이핑 없이 완료되었습니다.
이것이 두 도구를 함께 사용하는 것과 다른 도구를 직접 호출하는 하나의 에이전트의 차이입니다. 에이전트는 이 실행에서 직접 5개의 도구를 얻습니다: search_engine, scrape_as_markdown, search_engine_batch, scrape_batch, discover. 브라우저 에이전트가 가장 못하는 작업인 검색과 대량 가져오기를 위한 깔끔하고 규정 준수된 경로입니다.
결합된 파이프라인, 폭과 깊이
지금까지의 각 구성 요소는 독립적으로 작동합니다. 결합하면 주제에 대한 근거 있는 구조화된 인텔리전스 레코드를 구축합니다. 열린 웹에서 폭을 가져오고, 폼으로 보호된 권위 있는 소스에서 깊이를 가져옵니다. 주목받는 제약 카테고리인 GLP-1 약물로 실행했습니다:
# 1. BREADTH , Bright Data SERP API discovers authoritative sources (no browser)
sources = serp_api("Ozempic semaglutide")[:3]
# 2. FETCH , Bright Data Web Unlocker pulls the top source as markdown (no browser)
context = web_unlocker(sources[0])
# 3. DEPTH , Nova Act fills the Drugs@FDA form for the authoritative record (agent)
fda = nova_act_fda("semaglutide") # verified against the live DOM실제 엔드 투 엔드 출력:
{
"web_sources": ["ozempic.com", "mayoclinic.org/…semaglutide…", "accessdata.fda.gov/…/209637lbl.pdf"],
"web_context_chars": 59270,
"fda_authoritative": {"drug_name": "OZEMPIC", "active_ingredient": "SEMAGLUTIDE",
"application_number": "209637", "marketing_status": "Discontinued"},
"fda_grounded": true
}각 절반은 다른 절반이 할 수 없는 것을 했습니다. 데이터 레이어는 두 번의 API 호출로 열린 웹을 검색하고 세 개의 권위 있는 소스와 59 KB의 깔끔한 LLM 준비 컨텍스트를 반환했습니다. 브라우저 없이, 에이전트 없이. 에이전트는 데이터 레이어가 혼자 접근할 수 없는 곳으로 갔습니다. FDA 검색 폼을 채우고 권위 있는 규제 레코드인 신청 209637로 탐색했습니다. URL이 없는 폼 뒤의 데이터인 해당 제품 행의 상태는 Discontinued입니다.
그리고 두 가지가 서로를 확인합니다. 데이터 레이어는 에이전트가 행동하여 접근한 동일한 신청 번호에 대해 독립적으로 FDA 라벨 209637lbl.pdf를 반환했습니다. 폭이 깊이를 확인합니다.
이 실행은 또한 계획해야 할 실패를 보여줍니다. 에이전트의 FDA 단계는 브랜드명 “Ozempic”에서 세 번 ActAgentFailed로 실패했고, 활성 성분 “semaglutide”에서 성공했습니다. 그것이 지형의 신뢰성 비용입니다. 그래서 fda_grounded: true로 검증하고 재시도를 예산에 포함합니다.
동일한 파이프라인, 다른 산업
이것은 제약을 넘어서도 작동하며, 우리가 검증했습니다. 다른 산업인 금융 규정 준수에서 동일한 파이프라인을 실행했습니다. SERP는 회사의 웹 존재, 자체 사이트와 금융 데이터 프로필을 찾았습니다. 에이전트는 (FDA 폼보다 더 어려운 Angular 앱인) FINRA의 BrokerCheck를 탐색하여 브로커-딜러의 권위 있는 규제 레코드를 찾았습니다: 회사명, CRD 번호, 규제 기관, 공시 수. 한 번의 재시도로 근거가 확인되었습니다.
제약에서 금융까지, 동일한 파이프라인이 쿼리와 스키마 외에 코드 변경 없이 작동했습니다. 경쟁 가격 책정, 시장 조사, 제품 안전 모니터링에도 동일한 방식으로 확장되어야 합니다. 데이터 레이어는 폭과 규모를 처리하고, 에이전트는 게이팅된 깊이를 처리하며, 에이전트의 필드는 라이브 페이지에 대해 근거가 확인됩니다.
하나의 레코드에서 시장으로
하나의 레코드에서 시장으로도 확장됩니다. GLP-1 약물 시장에서 동일한 파이프라인을 실행하여 구조화된 경쟁 데이터셋을 얻었습니다. 데이터 레이어가 폭을 처리하는 동안 에이전트가 각 약물의 권위 있는 FDA 레코드를 제공했습니다:
| 활성 성분 | FDA 브랜드 | 신청 # | 상태 | 상위 소스 (SERP) |
|---|---|---|---|---|
| semaglutide | OZEMPIC | 209637 | Prescription | drugs.com |
| tirzepatide | MOUNJARO | 215866 | Prescription | ncbi.nlm.nih.gov |
| liraglutide | LIRAGLUTIDE | 212552 | Prescription | drugs.com |
시장 실행은 심지어 라이브 불일치를 드러냈습니다. 신청 209637은 위의 단일 레코드 실행에서 Discontinued로 읽혔고, 이 표에서는 Prescription으로 읽혔습니다. FDA 신청은 다른 상태를 가진 여러 제품 레코드를 보유할 수 있으므로, 각 에이전트 읽기는 하나의 행의 스냅샷입니다. 그것이 바로 모든 읽기를 검증해야 하는 이유입니다.
스크립트에 없던 reCAPTCHA
스크립트에 없던 한 순간이 아키텍처의 사례를 스스로 증명했습니다. 세 번의 조회 중 두 번에서 FDA 사이트가 에이전트에게 reCAPTCHA를 제시했습니다.
에이전트가 Drugs@FDA에서 마주친 실제 reCAPTCHA로, 실행 중에 캡처되었습니다. Nova Act의 가드레일이 이를 풀기를 거부했습니다. 세션은 Bright Data의 Browser API에서 실행되기 때문에 여전히 레코드에 접근했습니다.
Nova Act의 가드레일은 이를 풀어야 할 퍼즐로 취급하기를 거부했습니다. 추적에서 그대로, “저는 인간을 사칭하거나 캡차나 다른 챌린지를 풀어서 인간인 척 오도해서는 안 됩니다.” 그것이 자율 에이전트에게 원하는 동작입니다.
세션이 Bright Data의 Browser API에서 실행되기 때문에 여전히 통과했습니다. 로컬 원시 브라우저는 FDA 사이트를 로드조차 할 수 없었습니다. 해당 브라우저는 90초에 두 번 타임아웃되었지만, 동일한 실행에서 example.com은 정상적으로 접근했습니다. CAPTCHA도, 데이터도 접근하지 못했습니다. Bright Data 세션은 레코드에 접근했습니다.
따라서 역할 분담은 실제이고 검증되었습니다. 에이전트는 CAPTCHA를 풀지 않습니다. 하지 않을 것이며, 해서도 안 됩니다. 데이터 레이어는 폼을 탐색할 수 없습니다. Bright Data에서 에이전트만이 작업을 완료합니다.
CAPTCHA는 간헐적이며, 이후 원시 실행에서는 없었습니다. CAPTCHA가 있는 두 번의 에이전트 조회는 약 1분 50초와 2분 37초의 실제 마찰이 있었습니다. 데이터셋은 세 행이지만, 패턴은 전체 시장에도 적용됩니다.
그것이 Nova Act와 Bright Data의 결합입니다. 어떤 도구도 혼자서는 해결하지 못합니다.
제한 사항
- Nova Act는 아직 초기 단계입니다. 2026년 중반 기준으로 영어 전용 리서치 프리뷰이며, 인터랙션을 제한하는 무료 티어가 있습니다. 모든 실행에서 “Amazon은 이 버전의 인터랙션 데이터를 수집합니다”를 출력합니다. 프로덕션은 IAM, S3, Bedrock AgentCore와 함께 AWS에 결합되어 있습니다. 중요한 것을 구축하기 전에 AWS에서 프로덕션 티어 약관과 가격을 확인하세요.
- 에이전트는 팝업이 많은 소비자 사이트에서 취약합니다. booking.com에서
ActActuationError는 Bright Data가 서비스 제공에 실패한 것이 아니라 에이전트가 페이지와 씨름한 것이었습니다. 직접 결과 URL을 선호하고, 팝업을 명시적으로 닫고, 재시도 예산에 의존하거나 데이터 레이어로 오프로드하세요. - 규정 준수에는 두 가지 측면이 있습니다. 원하는 가드레일이지만, 제한된 대상은 계정 관리자 또는 KYC 단계를 의미하므로 리드 타임을 계획하세요. 그리고 AI를 위한 스크레이핑 합법성은 2026년에도 논쟁 중입니다. 랜드마크 공개 데이터 판결, EU AI 법, 저작권 소송이 여전히 진행 중입니다. 공개 데이터가 자동으로 허가를 의미하지 않으므로 법무팀을 참여시키세요.
- 감지는 군비 경쟁입니다. 에이전트 핑거프린팅과 크롤링당 지불이 계속 증가하고 있습니다. 앞서 나가는 것은 지속적인 작업이며, 이것이 레이어가 일회성 수정이 아닌 관리되는 의존성인 이유입니다.
- 자율 브라우저는 공격 표면입니다. 페이지에는 에이전트를 유도하는 프롬프트 인젝션이 포함될 수 있으며, Nova Act 자체 문서도 이를 표시합니다. 제한하세요. URL 허용 목록과 차단 목록을 사용하고, 필요하지 않은 페이지에서는 멀리하세요. 자격 증명과 결제 같은 민감한 입력은 모델이 입력하게 하는 대신
nova.page를 통한 직접 Playwright로 구동하세요.
다음 단계
Nova Act를 내년의 에이전트로 교체해도 분리는 여전히 적용됩니다: 아래의 레이어가 내구성 있는 부분입니다. 따라서 도구가 아닌 작업을 분류하는 것부터 시작하세요. 대상에 안정적인 URL이나 사전 구축된 수집기가 있다면 데이터 레이어로 보내고 브라우저를 건너뛰세요. Nova Act는 행동이 필요한 것에 예약하세요: 채울 폼, 다단계 경로, 스크레이퍼가 없는 포털.
두 번 이상 실행할 계획이 있다면 첫 번째 세션부터 다음을 설정하세요:
- 존의 인라인 자격 증명을
Authorization: Basic헤더로 이동하고, IP를 존 허용 목록에 추가하세요. 둘 중 하나를 건너뛰면Invalid URL또는 응답 헤더에 이유가 있는 빈 본문이 나타납니다. - 연결된 페이지에 1600×900 뷰포트를 강제로 설정하고, 실행 시작 전에
logs_directory를 생성하세요. - 동일한 세션에서
nova.page로 모든 추출 필드를 근거시키고, 재시도를 위해 1.2~1.5배를 예산에 포함하세요.
하나의 존이 따라오지 못할 때, 에이전트를 탓하기 전에 동시성 제한을 높이세요. 대량 검색은 SERP API, Web Unlocker, 또는 Web Scraper API로 이동하세요. Browser API와 Web MCP 모두 무료 티어가 있으므로 커밋하기 전에 분리를 테스트할 수 있습니다. 제한된 대상은 우회 방법이 아닌 계정 관리자와의 대화입니다.
여기 모든 데모의 실행 가능한 스크립트는 companion repo에 있습니다. 클론하고, 자신의 대상에 지정하고, 분리의 어느 절반이 실제로 필요한지 확인하세요.
자주 묻는 질문
Amazon Nova Act란 무엇인가요?
Amazon Nova Act는 Python으로 브라우저 에이전트를 구축하기 위한 AWS SDK입니다. 워크플로를 작고 신뢰할 수 있는 명령으로 나눕니다: 액션을 위한 act()와 타입된 추출을 위한 act_get(). Playwright를 통해 실제 Chromium을 구동합니다. 2026년 중반 기준으로 리서치 프리뷰입니다.
Nova Act는 Bright Data와 함께 작동하나요?
네, Chrome DevTools Protocol을 통해 작동합니다. Nova Act는 cdp_endpoint_url과 cdp_headers를 통해 Bright Data의 Browser API에 연결합니다. 설정 시 주의할 점은 최신 Playwright가 인라인 자격 증명 wss:// URL을 거부한다는 것입니다. 따라서 자격 증명을 Authorization: Basic 헤더로 이동하고 1600×900 뷰포트를 강제로 설정하세요.
Nova Act에서 프록시를 사용할 수 있나요?
CDP를 통해 연결할 때 네이티브 proxy 매개변수로는 사용할 수 없습니다. Nova Act는 Cannot specify a proxy when connecting over CDP 메시지와 함께 ValidationFailed를 발생시킵니다. 대신 CDP를 통해 Bright Data의 Browser API에 연결하세요. 차단 해제, 지역 라우팅, CAPTCHA 처리가 Bright Data 측에서 이루어집니다.
Nova Act는 프로덕션 준비가 되어 있나요?
2026년 중반 기준으로 영어 전용 리서치 프리뷰이며, 종량제 무료 티어가 있습니다. 프로덕션은 IAM, S3, Bedrock AgentCore와 함께 AWS에서 실행됩니다. 실행에서 협력적이고 구조화된 사이트에서는 신뢰할 수 있었고, 적대적인 소비자 사이트에서는 취약했습니다. 구축하기 전에 AWS에서 프로덕션 약관과 가격을 확인하세요.
이 방식으로 브라우저 에이전트를 실행하는 비용은 얼마인가요?
Bright Data의 Browser API는 종량제 기준 약 $8/GB를 청구합니다(2026년 중반). 무거운 페이지는 약 3.4 MB를 이동했습니다: 재시도 전 1,000페이지당 약 $27. 1.2~1.5배를 추가로 예산에 포함하세요. 가벼운 페이지는 1,000페이지당 약 $1.60에 가깝습니다. Nova Act의 추론 가격은 공개되지 않았으므로, 대량 작업에는 브라우저가 아닌 데이터 레이어를 사용하세요.
자체 헤드리스 브라우저와 프록시를 사용하지 않는 이유는 무엇인가요?
측정된 실패 모드는 답의 절반에 불과합니다. 브라우저를 구동하는 것은 무겁고, 다단계 실행에서 취약하며, 비결정적입니다. 하지만 직접 실행하기 더 어려운 절반은 지역, 규정 준수, 확장성입니다. 이는 절대 끝나지 않는 군비 경쟁입니다. 인프라 레이어가 이를 실행하므로 엔지니어링이 처리할 필요가 없습니다.
데이터 레이어가 아닌 에이전트를 언제 사용해야 하나요?
작업이 고정된 알려진 스키마 풀이라면 Web Scraper API를 사용하세요. 페이지 없이, 추론 비용 없이 레코드를 반환합니다. 스크레이핑이 캡처할 수 없는 추론이 필요하다면(다단계 탐색, 폼 제출, 조건부 로직), 에이전트를 사용하세요. 실제 시스템에서는 두 가지가 구성됩니다.
