이전 기사(Claude in Chrome의 클릭 도달 불능 문제)에서, 일반적인 HTML 페이지라면 요소 기반 조작(find / read_page)이 가장 확실하다고 썼습니다. 하지만 이 방법이 근본적으로 통하지 않는 앱군이 있습니다.

Flutter Web이나 canvas로 UI를 그리고 있는 앱입니다. 화면에 보이는 버튼도 패널도 DOM 상에는 존재하지 않습니다. 전부가 하나의 canvas에 그려진 픽셀입니다. find로 찾아도 아무것도 반환되지 않으며, read_page의 접근성 트리(Accessibility Tree)도 실질적으로 비어 있습니다.

Rive 에디터(애니메이션 제작 도구, Flutter 제작)를 AI에게 조작시켜 에셋(Asset)의 익스포트(Export)까지 완료했던 경험을 바탕으로, 요소를 가져올 수 없는 앱을 좌표만으로 확실하게 조작하는 절차를 정리합니다.

전제: 좌표 조작 외에는 길이 없음을 먼저 받아들일 것

요소 참조를 가져올 수 없는 이상, 남은 수단은 "스크린샷을 보고 좌표를 클릭한다"뿐입니다. 좌표 조작은 본질적으로 깨지기 쉬우므로, 일반적인 웹 페이지에서는 권장하지 않습니다. 요소를 가져올 수 없다고 확인되었을 때만 이 방침으로 전환합니다.

판단은 간단합니다. read_page를 실행했을 때 눈에 보이는 UI에 대응하는 노드(Node)가 거의 반환되지 않는다면 canvas 드로잉 앱입니다.

절차의 원칙 4가지

1. 조작 전에 윈도우 사이즈 확정을 기다릴 것

이전 기사의 원인 1과 같습니다. 페이지 로딩 직후에는 뷰포트(Viewport) 너비가 확정되지 않아(실측 시 1664→1920으로 2~3초 소요), 확정 전의 스크린샷 좌표로 클릭하면 오른쪽으로 어긋납니다. javascript_tool로 innerWidth를 두 번 읽어 동일한 값이 될 때까지 기다린 후 조작을 시작합니다. 단, innerWidth의 일치만으로는 불충분하며, 스크린샷을 찍은 시점부터 devicePixelRatio가 변하지 않았는지도 함께 확인합니다(이전 기사의 추시를 통해 판명된 조건. DPI나 스케일링이 변하면 좌표계 전체가 리스케일(Rescale)되지만, 변경 후의 값은 금방 안정되기 때문에 innerWidth의 일치만으로는 찾아낼 수 없음). canvas 드로잉 앱은 요소 기반으로 퇴피할 수 없는 만큼, 이 확정 대기의 중요도가 일반 페이지보다 높습니다.

2. 텍스트는 zoom으로 읽을 것

canvas에 그려진 문자는 DOM에서 텍스트로 가져올 수 없습니다. 메뉴 항목이나 패널의 라벨을 확인하려면 해당 영역을 zoom으로 확대한 스크린샷을 찍어 이미지로서 읽을 수밖에 없습니다. 전체 스크린샷의 문자는 너무 작아서 오독하기 쉬우므로, 읽어야 할 영역은 반드시 zoom하는 것을 습관화합니다.

3. 클릭할 때마다 "선택된 증거"를 확인할 것

좌표 클릭은 헛스윙을 해도 아무런 에러가 발생하지 않습니다. 헛스윙을 인지하지 못한 채 다음 조작으로 넘어가면, 이후의 절차가 전부 전제부터 무너집니다.

따라서 클릭 → 스크린샷 → 선택 상태의 시각적 증거(Rive라면 오브젝트의 파란색 하이라이트, 다른 앱이라면 선택 테두리나 색상 변화)를 확인한 후 다음 단계로 넘어가는 것을 철저히 합니다. 증거가 확인되지 않으면 그 자리에서 좌표를 다시 따서 재시도합니다. 먼저 진행해서는 안 됩니다.

4. 더블 클릭은 "고속 싱글 2연속"으로 만들 것

double_click 액션은 두 타격 사이의 간격이 앱 측의 판정 시간을 초과하여 싱글 클릭 2회로 변질될 수 있습니다(이전 기사의 원인 2). canvas 앱에서는 계층(Hierarchy)으로 들어가는 조작에 더블 클릭이 필요한 경우가 많으므로, 이것이 통하지 않으면 막히게 됩니다. browser_batch로 동일 좌표에 대한 left_click을 2연속 발행하면 간격이 좁혀져 판정이 통과됩니다.

실제 공략 예시 (Rive 에디터)

위의 원칙을 조합하면 "에셋을 선택하여 익스포트하기"는 다음과 같이 진행됩니다.

• 에디터를 연다 → innerWidth 안정화까지 대기 - 전체 스크린샷 → 대상 패널의 위치를 파악
• 대상 오브젝트를 고속 2연속 클릭 → 스크린샷으로 파란색 하이라이트 확인
• 메뉴 좌표를 클릭 → 메뉴 영역을 zoom하여 항목명 읽기
• Export 항목의 좌표를 클릭 → 다이얼로그 출현을 스크린샷으로 확인

각 스텝 사이에 반드시 증거 확인이 끼어들기 때문에 조작 수는 인간의 두 배 이상이 됩니다.

느리지만, 확실하게 나아갑니다.

좌표 조작에서 속도를 추구하면 헛스윙의 연쇄로 인해 오히려 느려진다는 것이 실운용의 결론이었습니다.

제한 및 주의사항

이 수법은 화면 레이아웃이 안정적인 앱을 전제로 합니다. 광고나 알림으로 인해 레이아웃이 빈번하게 움직이는 페이지에서는 좌표의 신뢰성이 더욱 떨어집니다.

Rive 에디터를 포함한 개별 앱의 UI 배치는 앱 업데이트에 따라 변경됩니다. 이 기사에서 가져가야 할 것은 구체적인 좌표가 아니라, '확정 대기(確定待ち) → zoom 읽기(zoom読み) → 증거 확인(証拠確認) → 고속 2연(高速2連)'이라는 절차의 원칙입니다.

검증은 Windows / 1920x1080 환경에서 수행되었습니다. DPI 스케일링 (DPI scaling)이 다른 환경에서는 좌표계의 동작이 달라질 가능성이 있습니다.

검증 시기: 2026년 6월. 환경: Windows 11 / Chrome + Claude in Chrome 확장 / Rive 에디터 (Flutter/canvas 제작).

Discussion