웹 돌아다니는 에이전트, 안전장치가 먼저다
파이단틱 AI와 플레이라이트를 묶어 브라우징 에이전트를 만드는 방법과 그 안전 설정
에이전트에게 웹을 맡기는 순간 성능보다 먼저 정해야 할 것이 있다. 어디까지 가도 되고, 얼마나 읽어도 되며, 몇 초를 기다려 줄 것인가다. 개발자 파멜라 폭스가 8월 20일 자신의 블로그에 파이단틱 AI(Pydantic AI)와 플레이라이트(Playwright)를 결합해 웹을 탐색하는 에이전트를 만드는 과정을 공개하면서, 그 경계선을 어떤 설정값으로 긋는지 항목별로 짚었다.
무슨 일인가 / 배경
파이단틱 AI는 파이썬 데이터 검증 라이브러리로 유명한 파이단틱(Pydantic)이 내놓은 오픈소스 프레임워크다. 특정 모델 회사에 묶이지 않고, 타입 안정성과 오픈텔레메트리(OpenTelemetry) 관측을 지원해 실서비스용 에이전트를 짜기에 적합하다는 것이 소개의 골자다. 여기에 별도 라이브러리로 제공되는 플레이라이트 브라우저 기능을 붙이면 에이전트가 직접 페이지를 열고, 링크를 따라가고, 본문을 읽을 수 있게 된다.
플레이라이트는 원래 웹사이트가 제대로 동작하는지 확인하는 종단간 테스트용으로 만들어진 브라우저 자동화 도구다. 글쓴이는 그 자동화 능력이 그대로 에이전트의 손발이 된다고 설명한다. 자기 사이트를 만들고 있다면 에이전트에게 직접 열어 보게 해 수동 점검과 디자인 개선을 시킬 수 있고, 외부 사이트도 해당 사이트의 이용약관이 프로그램 접근을 허용하는 범위 안에서만 다룰 수 있다는 단서를 함께 달았다.
핵심 짚어보기
글에서 가장 실용적인 대목은 브라우저 기능을 켤 때 넘기는 설정값 목록이다. 접근 허용 도메인 항목은 최상위 페이지 이동뿐 아니라 데이터를 실어 나르는 요청까지 지정한 호스트로 제한한다. 에이전트가 엉뚱한 사이트로 튀거나 데이터를 밖으로 흘리는 사고를 막는 1차 방어선이다. 사설 주소 차단 항목은 기본값이 켜짐이며, 허용 도메인 목록에 들어 있더라도 로컬호스트와 사설·예약 IP로는 가지 못하게 막는 이중 잠금 구조다. 내부망에 붙여야 할 때만 명시적으로 풀라는 것이 권고다.
토큰 예산도 명시적으로 다룬다. 에이전트에게 돌려주는 페이지 본문의 양은 기본 4,000 토큰으로 잡혀 있는데, 글쓴이는 긴 문서를 다루기 위해 3만 토큰으로 올렸다고 밝혔다. 다만 되돌려 주는 양이 늘수록 컨텍스트 창을 잡아먹어 이후 모델 호출의 성능과 지연에 영향을 준다는 점도 함께 적었다. 시간 제한은 두 종류로 나뉜다. 클릭이나 입력 같은 동작은 기본 5초, 페이지 이동은 30초로 따로 잡았는데, 실패하는 이유가 서로 다르기 때문이다. 존재하지 않는 요소를 클릭하는 일은 빨리 실패해야 하고 페이지 로딩은 여유가 필요하다는 논리다.
페이지를 옮길 때마다 화면을 캡처하는 옵션은 기본적으로 꺼져 있다. 스크린샷이 컨텍스트를 크게 부풀리기 때문인데, 디자인 중심 작업이나 사람이 나중에 감사해야 하는 흐름에서는 켤 만하다고 안내한다. 크로미움 자동 설치 역시 기본 꺼짐이며, 실행 환경마다 미리 설치해 캐시를 재사용하는 편이 낫다고 본다.
1인기업 실전 적용 포인트
- 자사 랜딩페이지나 스토어를 배포한 직후 에이전트에게 열어 보게 하고, 결제 버튼·문의 폼·모바일 레이아웃을 점검시키는 야간 점검 루틴을 만들 수 있다. 접근 허용 도메인을 자기 사이트 하나로 묶어 두면 사고 위험이 거의 사라진다.
- 본문 반환량은 처음부터 크게 열지 말고 4,000 토큰에서 시작해 부족할 때만 올리는 편이 낫다. 페이지 한 장을 3만 토큰으로 읽어들이면 이후 대화 비용이 계단식으로 뛴다.
- 동작 제한 5초, 이동 제한 30초 같은 기본값을 그대로 쓰면 무한 대기로 크론 작업이 물리는 사고를 막을 수 있다. 자동화가 조용히 멈춰 있는 상황이 가장 비싼 실패다.
- 개발 단계에서는 브라우저 창을 보이게 켜 두고 에이전트가 실제로 어디를 클릭하는지 눈으로 확인한 뒤, 안정되면 화면 없이 돌리는 순서를 권한다.
전망 / 주의점
브라우징 에이전트는 검색 결과 요약처럼 겉보기 편한 용도보다, 사람이 매주 반복하던 확인 작업을 대신할 때 값어치가 커진다. 다만 남의 사이트를 자동으로 긁는 일은 기술 문제가 아니라 약관과 법의 문제다. 상대 사이트의 이용약관과 로봇 배제 규칙을 먼저 확인하지 않은 자동화는 언제든 차단이나 분쟁으로 되돌아온다. 스크린샷과 본문 토큰을 아무 생각 없이 늘리면 비용이 조용히 불어난다는 점도 실사용 전에 잡아 둘 부분이다.
출처: 파멜라 폭스 블로그 (http://blog.pamelafox.org/2026/08/browser-automation-with-pydantic-ai.html)
수집부터 발행까지 파이프라인이 해냈고, 지금 읽으신 기사가 그 증거입니다. 이 시스템을 키트로 판매합니다.