Agent Browser는 미리 고정한 단계대로 실행하는 대신 모델이 웹페이지를 보고 다음 행동을 결정하게 합니다. 핵심 차이는 누가 판단하는지, 페이지를 어떻게 이해하는지, 행동을 어떻게 실행하는지, 그리고 현재의 실질적인 한계에 있습니다.
스크립트로 브라우저를 자동화하는 방식은 익숙합니다. 요소를 찾고, 경로를 정하고, 예외 처리를 추가하면 안정적으로 동작합니다. 다만 페이지가 개편되면 이야기가 달라집니다. 핵심 지점이 바뀌면 전체 스크립트를 다시 작성해야 할 수 있습니다. 코드는 구체적인 구조를 인식하고, 그 구조가 가장 쉽게 바뀌기 때문입니다.
Agent Browser는 다른 접근을 취합니다. 모델이 페이지 내용을 보고 다음에 무엇을 할지 결정하게 합니다. 그래서 페이지 개편에도 상대적으로 덜 민감합니다.
차이 1: 다음 단계를 누가 결정하는가
기존 스크립트에서는 사람이 경로를 작성합니다. 첫 번째로 어디를 클릭할지, 다음에 무엇을 입력할지, 그 뒤 얼마나 기다릴지까지 모두 미리 정해 둡니다. 실행할 때는 정해진 내용을 그대로 수행합니다.
Agent Browser는 의사결정을 모델에 맡깁니다. 예를 들어 특정 출처의 내용을 조건에 따라 표로 정리하라는 식으로 목표를 설명합니다. 어떤 페이지를 열지, 먼저 필터링할지 페이지를 넘길지, 팝업을 어떻게 처리할지는 실행 중에 결정됩니다.
이 차이는 과소평가되기 쉽습니다. 유지보수 비용이 코드를 작성하는 일에서 요구사항을 명확하게 설명하는 일로 옮겨갑니다. 기술적 난이도는 낮아지지만 목표 설명의 품질은 더 중요해집니다.
차이 2: 페이지에 무엇이 있는지 어떻게 아는가
스크립트는 selector로 요소를 인식합니다. XPath와 CSS selector는 구조 안에서 노드가 있는 위치를 가리킵니다. 그 위치가 바뀌면 selector가 동작하지 않습니다.
Agent Browser는 대신 페이지의 구조 정보나 스크린샷을 모델에 전달합니다. 모델이 이것은 로그인 버튼이고, 저것은 검색창이며, 다른 영역은 상품 가격이라고 판단합니다. 좌표보다 의미에 더 의존하는 방식입니다.
그에 따른 비용도 분명합니다. 모델이 페이지를 이해하려면 DOM 구조나 스크린샷을 보내야 하고, 페이지가 복잡할수록 전송할 데이터가 많아집니다. 긴 작업에서는 이 비용이 작지 않습니다. 각 단계마다 모델 추론 결과를 기다려야 하므로 전체 속도도 하드코딩된 스크립트보다 확실히 느립니다.
차이 3: 행동은 어떻게 실행되는가
판단을 내린 뒤에는 실제로 동작을 수행해야 합니다. 이런 도구는 보통 브라우저 기능을 호출 가능한 액션으로 감쌉니다. 페이지 열기, 클릭, 폼 입력, 로그인, 파일 업로드, 스크롤이나 페이지 이동, 데이터 추출 등이 있습니다. 모델이 어떤 액션을 어떤 파라미터로 호출할지 출력하면 브라우저가 실행하고, 결과를 다시 모델에 보내 다음 판단의 입력으로 사용합니다.
작업을 세분화하고 오류를 수정하는 일도 이 계층에서 일어납니다. 하나의 목표를 여러 단계로 나눠 순서대로 실행합니다. 중간에 잘못된 경로로 갔다고 판단하면 즉시 오류를 내고 멈추는 대신 다른 진입점을 시도할 수 있습니다. 구조가 불규칙한 페이지에서는 특히 중요하며, 완료율이 복구 방식에 크게 좌우됩니다.
지금 어느 정도까지 가능한가
결정성이 높고 단계가 명확한 작업은 이미 수행할 수 있습니다. 조건에 맞는 공개 정보를 수집해 구조화된 데이터로 만들기, 자체 시스템에서 반복 입력과 지정 형식 제출을 수행하기, 특정 페이지를 감시하다가 가격·재고·공지 변화가 생기면 알림을 보내는 작업이 대표적입니다. 이런 시나리오는 경로가 예측 가능하고, 오류를 재시도할 수 있으며, 사람이 결과를 확인할 수 있다는 공통점이 있습니다.
아직 안정적이지 않은 부분
문제가 가장 쉽게 생기는 곳은 의미 이해가 필요한 부분입니다. 어떤 버튼을 눌러야 하는지 판단하려면 모델이 먼저 그 버튼의 업무상 의미를 이해해야 합니다. 페이지 구조가 복잡하거나 문구가 직관과 다르면 오판이 생깁니다. 잘못된 진입점을 고르거나 다른 필드를 가져올 수 있습니다. 단계가 깊어질수록 오류가 누적되기 쉬워지고, 앞부분의 작은 오차가 뒤에서는 복구 불가능해질 수 있습니다.
강한 방어가 있는 상황은 더 어렵습니다. CAPTCHA, 위험 제어 차단, 로그인 상태 만료 같은 요소는 모델 자체보다 기반 환경에 더 크게 좌우됩니다. 모델이 아무리 뛰어나도 거부된 요청을 성공으로 바꿀 수는 없습니다. 클라우드 호스팅 실행과 서비스 제공자가 관리하는 프록시가 일부를 해결할 수 있지만, 사용량 기반 비용과 타사 인프라에 대한 의존이 생깁니다.
도구를 고를 때 볼 항목
실행 과정을 확인하고 재생할 수 있는지는 자주 간과되지만, 문제가 생겼을 때 원인을 찾는 핵심 수단입니다. 오류 수정 방식도 봐야 합니다. 오류가 나면 중단하는지, 다른 경로를 시도하는지 확인하세요. 모델 선택과 비용을 통제할 수 있는지도 중요합니다. 긴 작업은 예상보다 비용이 커지는 경우가 많습니다. 사용자 정의 도구와 워크플로를 연결할 수 있는지, 마지막으로 로그인 상태가 어떻게 유지되는지도 확인해야 합니다. 세션이 사라져 전체 작업을 다시 실행해야 하는 상황은 상당히 번거롭습니다.
사용 전에 규칙부터 확인하기
기술적으로 할 수 있는 일과 허용된 일은 같은 개념이 아닙니다. 먼저 대상 플랫폼의 이용약관이 자동 접근을 허용하는지, 요청 빈도가 상대 서비스에 부담을 주지 않는지 확인해야 합니다. 이런 도구로 계정을 대량 등록하거나 수익을 얻기 위해 플랫폼 작업을 자동으로 수행하는 것은 플랫폼 규칙을 위반하는 사용입니다. 플랫폼들은 작업 간격, 행동 경로, 환경 일관성을 식별하는 능력을 계속 높이고 있으며, 조치가 이루어질 때 여러 계정이 함께 영향을 받는 경우가 많습니다.
작업 자체는 규정에 맞지만 여러 계정의 로그인 상태를 서로 분리해야 한다면 환경 격리가 중요해집니다. 예를 들어 PurpleMark는 독립된 환경을 제공해 각 계정의 세션과 저장공간이 서로 보이지 않도록 할 수 있습니다.
현실적인 검증 방법은 자신이 잘 알고 단계가 명확한 작은 작업을 하나 고르는 것입니다. 도구가 처음부터 끝까지 수행하게 한 뒤 수동으로 한 결과와 비교하고, 오류가 났을 때 어떻게 반응하는지 기록하고, 실제 소요 시간을 계산합니다. 작은 작업 하나가 잘 돌아가면 그다음에 범위를 넓히면 됩니다. 처음부터 전체 프로세스를 자동화하려 하면 중간 단계 어딘가에서 막힐 가능성이 큽니다.
