웹 자동화 기술의 발전과 브라우저 작업 방식
Web Automation Technology and Browser Scripting
목차 (9개 섹션)
2019년 어느 개발자가 셀레니움으로 크롤러를 돌리다가 사이트 구조가 바뀔 때마다 스크립트가 통째로 깨지는 경험을 한 번쯤은 해봤을 것이다. 버튼 하나의 CSS 클래스명이 바뀌면 자동화 코드 전체가 멈춰 서는 이 취약함이야말로 웹 자동화 기술이 지난 20여 년간 극복해야 했던 근본 문제였다.
웹 자동화의 역사는 생각보다 길다. 2004년 셀레니움(Selenium)이 등장하면서 브라우저를 프로그래밍적으로 제어하는 표준이 처음 자리 잡았다. 당시 목적은 단순했다. 사람이 매번 클릭해서 확인하던 웹사이트 테스트를 자동화하자는 것이었다. 이후 2011년 PhantomJS 같은 헤드리스(headless) 브라우저가 나오면서, 화면을 실제로 띄우지 않고도 브라우저 엔진을 서버에서 돌릴 수 있게 됐다. 화면 렌더링 비용을 아낀다는 이유로 크롤링 업계에서 특히 환영받았다.
전환점은 2017년 구글이 크롬 헤드리스 모드와 함께 퍼펫티어(Puppeteer)를 공개하면서 찾아왔다. 퍼펫티어는 개발자 도구(DevTools) 프로토콜을 직접 활용해 셀레니움보다 빠르고 안정적인 제어를 가능케 했다. 2020년에는 마이크로소프트가 후원한 플레이라이트(Playwright)가 나오며 크롬·파이어폭스·사파리 엔진을 하나의 API로 동시에 다루는 시대를 열었다. 이 두 도구는 지금도 QA 자동화, 가격 비교 크롤러, 웹 모니터링 서비스의 근간을 이루고 있다.
문제는 여전히 남아 있었다. "특정 위치의 버튼을 클릭하라"는 식의 좌표·선택자 기반 자동화는 사이트 디자인이 리뉴얼되는 순간 무력화됐다. 이른바 '깨지기 쉬운 셀렉터(brittle selector)' 문제다. 실제로 전자상거래 업체들이 매년 UI를 개편할 때마다 사내 QA팀의 자동화 스크립트 유지보수 비용이 만만치 않다는 보고가 여러 개발 컨퍼런스에서 꾸준히 제기돼 왔다.
2023년 이후 대형 언어 모델(LLM)이 화면 텍스트와 구조를 이해하고 스스로 다음 행동을 판단하는 '에이전틱(agentic) 브라우저 자동화'가 새 흐름으로 떠올랐다. 미리 정해진 셀렉터 대신, 모델이 스크린샷이나 접근성 트리(accessibility tree)를 읽고 "로그인 버튼처럼 보이는 요소를 찾아 클릭하라"는 식의 자연어 지시를 실행한다. 앤스로픽의 컴퓨터 사용(computer use) 기능이나 여러 스타트업의 브라우저 에이전트가 이 방식을 상용화하고 있다.
다만 논쟁도 뚜렷하다. 첫째는 속도와 비용이다. 셀렉터 기반 자동화는 밀리초 단위로 끝나지만, 모델이 화면을 매번 해석하는 방식은 초 단위로 느려지고 API 호출 비용도 붙는다. 둘째는 신뢰성이다. 모델이 화면을 오독해 엉뚱한 버튼을 누르는 사례가 보고되면서, 결제나 계정 설정처럼 되돌리기 어려운 작업에 에이전트를 그대로 맡겨도 되느냐는 우려가 나온다. 셋째는 이용약관과 법적 회색지대다. 다수 플랫폼이 자동화 접근을 약관으로 금지하고 있어, 기술적으로 가능해진 일과 허용된 일 사이의 간극이 오히려 넓어졌다는 지적도 있다.
결국 현재의 웹 자동화는 '정확한 반복 작업은 전통적 셀렉터 기반 도구로, 예측 불가능한 탐색과 판단이 필요한 작업은 AI 에이전트로' 역할을 나누는 혼합 구조로 수렴하는 중이다. 완전한 대체보다는 도구함이 하나 늘어난 셈이라는 게 업계의 대체적인 평가다.
기술 개요
웹 자동화는 브라우저를 프로그래밍 방식으로 제어하여 웹사이트 테스트, 데이터 크롤링, 웹 모니터링을 수행하는 기술이다. 이 기술은 품질 검증(QA) 자동화와 가격 비교 크롤러 및 웹 모니터링 서비스의 기반 기술로 쓰인다. 웹 자동화는 사람이 수동으로 브라우저를 조작하던 작업을 자동화하여 기능 검증과 데이터 수집을 처리하는 데 활용된다.구성 도구의 특징
셀레니움은 브라우저를 프로그래밍 방식으로 제어하는 표준 도구다. 헤드리스 브라우저는 화면을 실제로 띄우지 않고 서버 환경에서 브라우저 엔진을 실행하여 화면 렌더링 비용을 절감하는 도구다. 퍼펫티어는 개발자 도구(DevTools) 프로토콜을 직접 활용하여 브라우저를 빠르고 안정적으로 제어하는 도구다. 플레이라이트는 크롬, 파이어폭스, 사파리 엔진을 하나의 응용 프로그램 프로그래밍 인터페이스(API)로 동시에 제어하는 도구다.작동 원리
셀렉터 기반 자동화의 작동 순서
셀렉터 기반 자동화는 특정 위치의 좌표나 선택자(CSS 클래스명 등)를 입력으로 받는다. 도구는 웹사이트 문서 구조에서 입력된 선택자와 일치하는 요소를 탐색하고 제어 명령을 처리한다. 처리가 완료되면 지정된 버튼 클릭이나 데이터 수집과 같은 실행 결과가 도출된다. 셀렉터 기반 자동화는 밀리초 단위로 동작을 완료하는 성능을 나타낸다.에이전틱 브라우저 자동화의 작동 순서
에이전틱 브라우저 자동화는 자연어 지시와 함께 화면 스크린샷 또는 접근성 트리(accessibility tree)를 입력으로 받는다. 대형 언어 모델(LLM)은 입력된 화면 텍스트와 구조를 해석하여 다음 수행 행동을 스스로 판단한다. 브라우저는 모델이 판단한 조작 명령을 전달받아 목표 요소를 조작하는 결과를 실행한다. 에이전틱 브라우저 자동화는 미리 정해진 선택자 없이도 자연어 지시를 수행할 수 있는 특징을 가진다.방식별 한계 및 논쟁
셀렉터 기반 방식의 한계
셀렉터 기반 자동화는 웹사이트 디자인이나 CSS 클래스명이 변경되면 스크립트가 중단되는 한계를 가진다. 이러한 취약성은 '깨지기 쉬운 셀렉터' 문제로 정의된다. 전자상거래 업체의 사용자 인터페이스(UI) 개편 시 사내 QA팀의 자동화 스크립트 유지보수 비용이 증가한다는 보고가 제기되어 왔다.에이전틱 방식의 논쟁과 과제
에이전틱 브라우저 자동화는 모델이 화면을 매번 해석하는 과정에서 처리 속도가 초 단위로 지연된다. 또한 대형 언어 모델 호출에 따른 API 비용이 발생한다. 모델이 화면을 오독하여 의도하지 않은 요소를 조작하는 사례가 보고되면서 결제나 계정 설정과 같은 비가역적 작업 위임에 대한 우려가 나온다. 아울러 다수 플랫폼이 자동화 접근을 이용약관으로 금지하고 있어 기술적 실행과 허용 범위 사이의 간극에 대한 지적이 제기된다.운용 구조
현재의 웹 자동화는 전통적 셀렉터 기반 도구와 인공지능(AI) 에이전트의 역할을 분담하는 혼합 구조로 수렴하는 중이다. 정확성이 요구되는 반복 작업은 전통적 셀렉터 기반 도구가 담당한다. 예측하기 어려운 탐색과 판단이 필요한 작업은 AI 에이전트가 담당한다. 업계에서는 AI 에이전트 도입이 기존 도구의 완전한 대체가 아닌 보조 도구의 추가라는 평가가 나온다.관련 문서
문서 정보
- 최초 작성
- 최종 갱신
- 분류
- 기술
HANGUL.WIKI가 정리·작성한 문서입니다. 정확성을 위해 노력하나 오류가 있을 수 있으므로, 중요한 내용은 공식 출처를 통해 확인하시기 바랍니다. 내용의 오류나 정정 요청은 오류·정정 신고로 알려주시면 검토 후 반영합니다.