HANGUL.WIKI

웹 자동화 기술의 발전과 브라우저 작업 방식

Web Automation Technology and Browser Scripting

2026-07-05
목차 (0개 섹션)

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 에이전트로' 역할을 나누는 혼합 구조로 수렴하는 중이다. 완전한 대체보다는 도구함이 하나 늘어난 셈이라는 게 업계의 대체적인 평가다.

문서 정보

최초 작성
최종 갱신
분류
기술

HANGUL.WIKI가 정리·작성한 문서입니다. 정확성을 위해 노력하나 오류가 있을 수 있으므로, 중요한 내용은 공식 출처를 통해 확인하시기 바랍니다. 내용의 오류나 정정 요청은 오류·정정 신고로 알려주시면 검토 후 반영합니다.