자동화 에이전트의 LLM이 아무것도 클릭하지 않게 만든 이유

저는 브라질 마나우스의 컴퓨터 공학 학생이며, 연구 프로젝트를 위해 웹 자동화 에이전트인 ANCHOR를 구축하고 있습니다. 사용자가 일반 언어로 작업("마리아 실바 등록, IT 부서, 계약직, 약관 동의 및 저장")을 설명하면, 이 에이전트가 브라우저에서 해당 작업을 실행합니다. 모든 과정은 로컬 환경에서 진행되며, GTX 1050 Ti (4GB)를 사용하여 Ollama를 통해 작은 모델(Qwen 3.5, 4B 및 9B)들을 구동합니다.

이번 게시물에서는 가장 큰 차이를 만든 하나의 설계 결정과, 모든 것을 측정하면서 배운 몇 가지 내용에 대해 다루겠습니다.

문제점 (The problem)

전통적인 RPA는 개발자가 작성한 고정된 셀렉터(fixed selectors)에 의존합니다:

page.locator('[data-test="add-to-cart"]').click()

이 방식은 페이지가 변경되면 작동을 멈추며, 모든 자동화 작업에는 실제 작업을 아는 사람과는 거리가 먼 코더가 필요합니다.

최근 유행하는 해결책은 LLM(Large Language Model)을 제어에 투입하는 것입니다. LLM은 페이지를 보고 어디를 클릭할지 결정합니다. 하지만 작은 모델들을 사용할 경우 심각한 문제가 발생하는데, 제가 측정해 본 바로는 그 모델이 실제로는 완료되지 않았는데도 완료했다고 말한다는 점입니다.

결정: 모델은 오직 계획만 세운다 (The decision: the model only plans)

ANCHOR에서 모델은 절대 아무것도 클릭하지 않습니다. 모델은 요청과 페이지에 대한 요약(요소들, 번호가 매겨짐)을 받으면, 목표와 단계로 구성된 계획을 반환합니다. 이 계획은 요소의 이름("전체 이름 입력", "계약직 체크", "등록 저장 클릭")을 사용합니다.

이후 AI가 아닌 결정론적 엔진(deterministic engine)이 이를 실행합니다:

1. 휴리스틱(heuristic)이 단계 설명으로부터 각 요소를 찾아냅니다. 이 과정에서 텍스트, 레이블, 역할, 그리고 문맥(동의어, 근처 텍스트)을 결합하며, 확신하지 못할 경우 거부합니다.
2. 거부될 경우, 사용자가 결정합니다: 후보 요소들은 페이지에 번호가 매겨져 있으며, 사용자는 그중 하나를 선택하거나 올바른 요소를 클릭합니다.
3. 선택은 기억됩니다, 따라서 다음 실행 시에는 다시 묻지 않습니다.
4. 각 동작의 효과가 확인됩니다 (페이지가 변경되었는가? 필드 값이 유지되었는가? 오류가 나타났는가?), 그리고 실행의 끝이 원래 요청과 일치하는지 확인합니다.

GIF에서 자동화가 저장된 후 사이트가 변경되었습니다("장바구니에 담기"가 "백에 추가하기"로). ANCHOR는 추측하는 대신 어떤 버튼을 사용할지 물어보고, 그 답변을 기억하며, 다음 실행은 스스로 진행됩니다.

모델 없이 한 번 학습하고 다시 재생하기

작동했던 작업은 저장할 수 있습니다. 첫 번째 실행에서는 모델과 함께 계획을 세웁니다(제 GPU에서 약 70초 소요). 이후의 실행들은 모델 호출 없이 승인된 계획을 재현하며, 스프레드시트 행 하나당 심지어 3초 만에 처리됩니다. 사이트가 변경되어 저장된 단계가 깨질 경우, 자동화는 복구하고 변경된 내용을 기록하며, 이 기록은 검토하고 되돌릴 수 있습니다.

측정 결과가 보여준 것들

저는 복원력 벤치마크를 구축했습니다: 5가지 수준으로 변경된 페이지에서 수행되는 30가지 작업(ID 이름 변경, 동의어 사용, 레이아웃 재구성, 쿠키 배너 및 숨겨진 섹션, 주입된 지침을 가진 유사한 미끼)에 대해 실행기별로 150회씩, 사용자 도움 없이 진행했습니다:

ANCHOR의 약점은 콘텐츠 일부가 "더 보기(Show more)" 버튼 뒤에 숨겨진 페이지입니다 (LLM이 제어하는 경우 57–60% 대비 47%). 그리고 솔직히 말씀드리자면, 이 수치들은 제가 작업을 보면서 시스템을 조정했던 개발 단계의 수치들입니다. 1.0 버전에서는 동료들이 프로젝트를 본 적이 없는 분들이 작성한 80개의 요청으로 구성된 폐쇄형 세트가 있으며, 이는 마지막에 단 한 번만 실행됩니다.

세 가지 교훈

1. 모든 변경 사항 이후에는 모든 것을 재측정하세요. 첫 번째 전체 벤치마크 실행에서 테스트가 포착하지 못한 네 가지 버그를 발견했습니다 (예를 들어, 파괴적 행동에 대한 방어 장치가 요청이 "Bruno Lima 삭제"일 때 "모두 삭제(Delete all)"를 허용하는 경우). 그리고 제가 처음 적용한 두 가지 수정 사항은 새로운 문제를 만들었고, 이는 다른 평가들을 다시 실행해 보았기 때문에 비로소 드러났습니다.

2. 프롬프트 변경은 그것과 전혀 관련 없는 작업에 영향을 미칩니다. 테이블 추출 기능을 추가했을 때, 저는 새 행동을 설명하는 두 줄을 프롬프트에 넣었습니다. 4B 모델은 상자에 내용을 채운 후 검색을 중단하기 시작했고, 9B 모델은 등록 과정에서 계약 유형(contract type)을 빠뜨렸습니다. 해결책은 해당 라인들을 요청이 데이터를 읽는 것과 관련될 때만 표시하도록 한 것입니다. 다른 모든 요청에 대해서는 프롬프트가 이전 버전과 바이트 단위로 동일합니다.

3. 절대로 비밀번호를 AI의 요청에 넣지 마세요. LinkedIn에서 테스트할 때, 저는 이메일 주소와 비밀번호를 요청에 작성했고, 그것이 타이핑했습니다. 비밀번호는 제 컴퓨터를 떠나지 않았지만, 모델을 거쳤고, 이는 발생해서는 안 되는 일입니다. 이것이 버전 0.3.1이 되었습니다: ANCHOR는 절대로 비밀번호를 타이핑하지 않으며, 모델에 도달하기 전에 비밀번호가 포함된 요청을 거부하고, 작업에 로그인이 필요한 경우 중단하고 사용자가 수동으로 로그인할 때까지 기다립니다 (세션은 다음 실행을 위해 유지됩니다).

직접 사용해 보세요

프로젝트는 GitHub에 있으며, 설정 단계는 README에 있습니다:

https://github.com/LucasDantas2701/ANCHOR

테스터들의 의견은 언제나 환영합니다. 특히 실제 사이트에서 발생한 실패 사례가 가장 유용한 피드백입니다. 다음 버전(0.4)에는 파일 다운로드 및 업로드가 추가되고, 새로운 탭과 iframe도 지원됩니다.

고지: 이 코드는 AI 어시스턴트(Claude)의 도움을 받아 작성되었으며, 해당 AI가 이 게시글 작성을 돕는 데에도 도움을 주었습니다. 프로젝트 자체, 의사 결정 및 평가는 모두 저의 것입니다. 코드는 소스 사용 가능(PolyForm Strict)합니다. 즉, 읽고 사용할 수는 있지만 수정하거나 재배포할 수는 없습니다.