Post

웹 자동화의 ‘은탄환’은 존재할까? Page Agent가 설계하는 선언적 브라우징의 미래

웹 자동화의 ‘은탄환’은 존재할까? Page Agent가 설계하는 선언적 브라우징의 미래

셀렉터와의 전쟁, 그 지긋지긋한 연대기

자, 솔직해져 봅시다. 웹 개발자나 데이터 엔지니어로 살면서 ‘스크래핑’이나 ‘브라우저 자동화’ 업무를 반갑게 맞이한 적이 단 한 번이라도 있었나요? 저는 없었습니다. 어느 날 갑자기 잘 돌아가던 크롤러가 죽었다는 슬랙 알림을 받고 코드를 열어보면, 십중팔구는 서비스 측에서 클래스 명을 btn-primary에서 sc-1f3a2z 같은 난독화된 값으로 바꿨거나, 뜬금없는 팝업창이 앞을 가로막았기 때문이죠.

우리는 지난 십수 년간 Puppeteer, Playwright, Selenium이라는 훌륭한 도구를 손에 쥐었지만, 본질적인 문제는 해결하지 못했습니다. 우리는 여전히 ‘어떻게(How)’에 매몰되어 있었습니다. “두 번째 div 밑에 있는 세 번째 span을 클릭해”라고 브라우저에게 구구절절 설명해야 했죠. UI가 1픽셀만 틀어져도 깨지는 이 ‘절차적’인 방식은 유지보수의 지옥을 선사했습니다.

그런데 최근 LLM(거대언어모델)의 부상과 함께 등장한 Page Agent(페이지 에이전트) 개념은 이 판도를 완전히 바꾸려 하고 있습니다. 이제는 “내일 서울에서 제주도 가는 가장 저렴한 비행기 표 예약해줘”라는 ‘의도(Intent)’만 던지면 에이전트가 알아서 웹을 유영합니다. 이게 과연 우리 개발자들의 고통을 끝내줄 구원투수일까요, 아니면 또 다른 형태의 기술적 부채일까요? 10년 차 개발자의 삐딱한, 하지만 애정 어린 시선으로 뜯어보겠습니다.

TL;DR: Page Agent는 고정된 셀렉터 대신 LLM의 추론 능력을 이용해 웹의 구조와 시각 정보를 동적으로 이해하고 조작하는 지능형 자율 에이전트입니다. 유지보수 비용을 획기적으로 낮추지만, 비용과 속도라는 명확한 트레이드오프를 가지고 있습니다.


Deep Dive: Under the Hood

Page Agent가 기존의 Playwright 기반 스크립트와 결정적으로 다른 지점은 ‘인지(Perception)’와 ‘계획(Planning)’ 단계의 존재입니다. 기존 방식이 Find Element -> Click의 단순 루프였다면, Page Agent는 다음과 같은 복합적인 아키텍처를 가집니다.

1. DOM의 추상화와 토큰 최적화 (The Semantic Bridge)

LLM에게 원본 HTML 전체를 던지는 것은 자살행위입니다. 수만 줄의 <div> 태그는 모델의 컨텍스트 윈도우를 금방 채워버릴뿐더러, 비용도 감당할 수 없죠. Page Agent의 핵심 기술은 ‘Semantic Snapshot’을 만드는 과정에 있습니다.

대부분의 에이전트는 현재 페이지의 DOM 트리에서 인터랙션이 가능한 요소(버튼, 입력창, 링크 등)만 추출합니다. 이때 Role, Aria-label, Inner Text 등을 조합해 모델이 이해하기 쉬운 Markdown 형태나 JSON 트리로 단순화합니다. 최근에는 단순히 텍스트만 보는 게 아니라, 브라우저 화면을 스크린샷으로 찍어 멀티모달(Vision) 모델에 전달함으로써 “저기 빨간색 취소 버튼 눌러” 같은 시각적 지시를 수행하기도 합니다.

2. Self-Correcting Loop (추론과 수정)

가장 흥미로운 부분은 피드백 루프입니다. 에이전트가 ‘구매하기’ 버튼을 누르려고 시도했는데, 만약 로그인 창이 떴다면 어떻게 할까요? 기존 스크립트는 예외 처리가 안 되어 있다면 거기서 멈춥니다. 하지만 Page Agent는 현재 상태(State)와 목표(Goal)를 끊임없이 대조합니다.

  • Action: click('#buy-button') 시도
  • Observation: “로그인이 필요합니다”라는 알림창 발생
  • Reasoning: “아, 구매를 하려면 먼저 로그인을 해야 하는구나. 아이디 입력창을 찾자.”
  • Next Step: 로그인 프로세스로 즉시 전환

이런 동적 계획 수립(Dynamic Planning)이야말로 Page Agent를 단순한 매크로와 차별화하는 핵심 엔진입니다.

3. 하이브리드 아키텍처의 등장

최근에는 성능을 위해 모든 과정을 LLM에 맡기지 않습니다. 초반의 복잡한 로직은 LLM이 짜주고, 실제 반복적인 실행은 생성된 Playwright 코드를 로컬에서 돌리는 ‘Code Generation & Execution’ 방식이 각광받고 있습니다. 이는 매 단계 LLM을 호출하는 비용과 지연시간을 줄이기 위한 현명한 절충안이죠.


실무 적용 시나리오: 단순 자동화를 넘어

“그래서 이걸 어디다 써먹냐?”라고 물으신다면, 저는 단순히 데이터 긁어오는 용도로만 쓰기엔 아깝다고 답하겠습니다.

  1. 지능형 E2E 테스트: 기획서가 바뀌어서 버튼 위치가 옮겨질 때마다 테스트 코드를 수정하시나요? Page Agent 기반의 테스트 도구는 “회원가입 프로세스가 정상 작동하는지 확인해”라는 문장만으로 테스트를 수행합니다. UI의 소소한 변경은 에이전트가 스스로 판단해 무시하죠.
  2. 레거시 시스템의 API화: API가 제공되지 않는 20년 된 사내 ERP 시스템이 있나요? Page Agent를 이용해 자연어로 명령을 내리면 내부적으로 브라우저를 조작해 데이터를 입력하고 결과값을 뱉어주는 ‘임시 API 레이어’를 순식간에 구축할 수 있습니다.
  3. 개인화된 웹 비서: 여러 쇼핑몰의 장바구니에 담긴 물건들의 가격을 비교해 최저가인 곳에서 결제 직전 단계까지 세팅해두는 등의 복잡한 워크플로우를 자동화할 수 있습니다.

솔직한 고찰: 장점 뒤에 숨은 그림자

하지만 제가 10년 동안 이 바닥에서 구르며 배운 진리가 하나 있습니다. ‘모든 기술은 등가교환이다’라는 점이죠. Page Agent도 예외는 아닙니다.

  • 치명적인 레이턴시(Latency): LLM이 화면을 분석하고 다음 행동을 결정하는 데 짧게는 2~3초, 길게는 10초 이상 걸립니다. 실시간 반응이 중요한 서비스에는 절대 못 씁니다. 성격 급한 한국 사용자들은 그사이에 새로고침을 다섯 번은 누를 겁니다.
  • 할루시네이션(Hallucination)의 공포: 에이전트가 존재하지 않는 버튼을 클릭하려고 시도하거나, 엉뚱한 데이터를 입력할 가능성이 0%가 아닙니다. 특히 결제나 데이터 삭제 같은 민감한 작업에서는 ‘Human-in-the-loop(사람의 승인 단계)’가 반드시 필요합니다.
  • 토큰 빌(Bill)의 압박: 페이지를 한 번 분석할 때마다 수천 개의 토큰이 나갑니다. 대량의 데이터를 수집해야 하는 작업이라면, 차라리 고전적인 셀렉터 기반 크롤러를 짜는 게 비용 측면에서 수천 배 저렴합니다.
  • 보안과 프라이버시: 에이전트가 내 브라우저 세션에 접근해 DOM을 긁어 서버(OpenAI 등)로 보낸다는 사실은 보안 팀에게는 재앙과 같습니다. 온프레미스 LLM을 쓰지 않는 이상 기업 내부용으로 도입하기엔 허들이 높습니다.

마치며: 에이전트와 공존하는 법

Page Agent는 기존의 웹 자동화 도구를 대체하는 것이 아니라, 그 위에 얹어지는 지능형 레이어라고 보는 것이 맞습니다. 정형화된 구조의 데이터 수집은 여전히 BeautifulSoup이나 Playwright의 몫입니다. 하지만 비정형적이고 맥락 이해가 필요한 복잡한 워크플로우에서 Page Agent는 대체 불가능한 가치를 발휘할 것입니다.

우리는 이제 셀렉터를 잘 따는 법을 공부할 게 아니라, 어떻게 하면 웹 페이지의 구조를 에이전트가 이해하기 쉽게 설계할지(AIA: Agent-Interactive Accessibility)를 고민해야 할지도 모릅니다. 웹 표준과 시맨틱 마크업의 중요성이 검색 엔진 최적화(SEO)를 넘어 ‘에이전트 최적화’를 위해 다시금 강조되는 시대가 오고 있습니다.

지금 당장 여러분의 프로젝트에 Page Agent를 전면 도입하라고 하지는 않겠습니다. 다만, 사내에서 반복되는 지루한 운영 업무나 깨지기 쉬운 테스트 코드 한두 개에 ‘실험적’으로 적용해보세요. 그 속에서 발견하는 통찰이 여러분의 다음 아키텍처를 결정짓는 열쇠가 될 테니까요.

결국 기술은 사람의 불편함을 해결하기 위해 존재합니다. Page Agent가 그 지긋지긋한 ‘셀렉터 전쟁’에서 우리를 해방해 줄지, 아니면 새로운 형태의 ‘프롬프트 전쟁’으로 몰아넣을지는 지켜봐야겠지만요. 자, 여러분은 이 기술을 환영하시나요, 아니면 경계하시나요?

References

  • https://www.browserbase.com/blog/what-is-a-browser-agent
  • https://github.com/nat/natbot
  • https://python.langchain.com/docs/integrations/toolkits/playwright
  • https://www.multion.ai/blog/introducing-multion-agentic-web-browsing
This post is licensed under CC BY 4.0 by the author.