브라우저 에이전트가 화면의 버튼을 잘못 눌렀습니다. 스크린샷 좌표와 DOM 정보를 어떻게 사용하고 실행 후 무엇을 확인하나요?

화면에서 보인 위치와 실제 클릭 시점의 대상이 같다는 보장이 없기 때문에 관찰·대상 선택·행동·결과 확인을 짧은 주기로 연결하겠습니다. 가능하면 접근성 트리나 안정적인 DOM 식별자를 사용하고, 좌표 기반 조작이 필요한 경우 화면 크기·스크롤·현재 UI 상태를 함께 확인합니다. 요소를 찾았다는 사실과 사용자 의도에 맞는 행동을 했다는 것은 다릅니다.

오래된 관찰로 실행하지 않습니다

목록이 정렬되거나 팝업이 뜨면 방금 본 삭제 버튼의 좌표가 다른 항목을 가리킬 수 있습니다. 대상의 이름·행 ID·주변 문맥을 확인하고 중요한 행동 직전에 최신 상태를 읽습니다. DOM selector도 화면 구조가 바뀌거나 동일 이름 버튼이 여러 개면 오동작할 수 있으므로 단순 첫 번째 매치보다 대상 범위를 좁힙니다. 테스트 환경에서는 안정적인 test ID가 유용하지만 외부 사이트에서는 그 존재를 가정하지 않습니다.

폼을 채운 뒤 전송하기 전에 수신자·금액·첨부를 검토하고 비가역 동작은 사용자 승인을 거칩니다. 클릭 API가 성공했다는 응답은 입력 이벤트가 전달됐다는 뜻일 수 있으며 실제 예약·전송 성공은 결과 페이지나 권위 있는 상태 조회로 확인합니다. 네트워크 대기 중 재클릭하면 중복 실행될 수 있으므로 진행 상태와 논리 요청을 추적해야 합니다.

화면도 비신뢰 입력입니다

웹페이지의 텍스트·이미지·다운로드 파일은 에이전트에게 지시를 주는 권한이 없습니다. 로그인된 브라우저 세션은 이미 큰 권한을 가질 수 있어 허용 사이트와 행동 범위를 제한합니다. 별도 프로필과 격리 환경을 사용하고 인증정보 입력은 신뢰할 수 있는 사용자·자격 처리 경로에 맡깁니다. CAPTCHA나 접근 제한을 자동 우회하는 것을 정상적인 복구 단계로 보지 않습니다.

평가에서는 화면 크기·레이아웃 변화·동적 팝업·느린 응답·중복 버튼·접근성 정보 부족을 포함합니다. 성공한 클릭 수보다 실제 최종 상태와 잘못된 대상 변경이 없었는지를 봅니다. API가 제공되는 사이트에서는 UI 조작보다 명시적인 API가 안정적일 수 있지만 인가와 의미가 같은지 확인해야 합니다. 브라우저 에이전트의 최신성은 화면을 볼 수 있다는 기능보다 불완전한 관찰 아래에서 안전한 실행과 검증을 연결하는 능력에 있습니다.

실행 사례로 확인합니다

예를 들어 목록 행에 같은 '삭제' 버튼이 여러 개 있으면 행의 문서 제목과 고유 ID를 확인한 뒤 그 행 안의 버튼을 선택합니다. 확인 대화가 뜨면 대상 이름을 다시 대조하고, 실행 뒤 목록에서 사라진 것만 아니라 서버의 삭제 상태를 확인할 수 있으면 확인합니다. 필터 때문에 숨겨진 것과 실제 삭제는 다르기 때문입니다. 드래그·캔버스처럼 DOM 의미가 부족한 동작은 시각 관찰의 오차를 인정하고 작은 단계로 수행합니다. 화면 스냅샷에는 개인정보가 포함될 수 있어 관측 저장소로의 저장 범위도 제한합니다. 시각 에이전트는 API보다 범용적일 수 있지만 더 불완전한 관찰과 대상 확인 비용을 지불합니다.