프로젝트 로그 #10: 스크린샷을 버리기로 했습니다. 그 이유는 다음과 같습니다.

Day 10. OCR(광학 문자 인식)과 템플릿 매칭 (Template matching)이 한계에 부딪혔습니다. UI 계층 구조 검사 (UI hierarchy inspection)가 진정한 해답일지도 모릅니다.

9일 전, 저는 스크린샷 기반의 비전 시스템이 자랑스러웠습니다. 텍스트를 위한 ML Kit, 아이콘을 위한 템플릿 매칭 (Template matching). 대부분의 경우 작동하는 영리한 폴백 체인 (fallback chain)이었습니다.

오늘, 저는 그 중 대부분을 뜯어내고 있습니다.

임계점 (The Breaking Point)

지난주, 친구의 휴대폰에서 에이전트를 테스트했습니다. 템플릿 매칭 (Template matching)이 실패했습니다. 제 기기에서 크롭(crop)했던 동일한 아이콘들이 그의 기기에서는 일치하지 않았습니다. 화면 밀도(screen density)가 다르고, 렌더링이 다르고, 픽셀 배열이 달랐기 때문입니다.

다중 해상도 아이콘 라이브러리를 구축하는 방법을 탐색했습니다. 모든 아이콘을 5가지 다른 DPI로 크롭한다고요? 너무 지루한 작업입니다. AI 기반 아이콘 탐지 (AI-based icon detection)도 탐색했습니다. 모양으로 버튼을 인식하도록 모델을 학습시킨다? 휴대폰 CPU에게는 너무 무거운 작업입니다.

그러다 무언가 떠올랐습니다. 안드로이드 (Android)는 이미 화면에 무엇이 있는지 알고 있습니다. UI를 렌더링하고 있으니 당연히 알고 있어야 합니다. 그리고 그 정보를 직접 읽을 수 있는 방법이 있습니다.

UI 계층 구조 검사 (UI Hierarchy Inspection)의 도입

ADB에는 uiautomator dump라는 명령어가 있습니다. 이 명령어는 화면에 보이는 모든 UI 요소—버튼, 텍스트 필드, 아이콘, 이미지 등 모든 것—를 포함하는 XML 파일을 출력합니다. 각 요소는 다음을 가집니다:

• 클래스 이름 (예: android.widget.Button, android.widget.ImageView)
• 경계값 (Bounds, 요소가 위치한 정확한 픽셀 좌표)
• 텍스트 (Text, 존재하는 경우)
• 콘텐츠 설명 (Content description, 접근성 레이블, 주로 아이콘에 사용됨)
• 클릭 가능 여부, 스크롤 가능 여부, 포커스 여부

이것은 스크린샷이 아닙니다. 이것은 앱의 내부 설계도입니다.

이것이 모든 것을 바꾸는 이유

스크린샷 기반 (기존 방식)	UI 트리 (새로운 방식)
스크린샷에 OCR 실행 (1.5–2초)	ADB 명령어 하나 실행 (0.5–1초)
...

첫 번째 실험

제 휴대폰에서 adb shell uiautomator dump를 실행한 다음, XML 파일을 가져왔습니다.