Moli에서 좌표 문제를 조사할 때는 디버깅용 스크린샷도 실행 순서에 기록해야 합니다. 스크린샷을 추가하는 동작이 화면 배치를 갱신해, 다음 위치 조회값을 바꿀 수 있기 때문입니다. 평소에는 실패하던 자동화가 캡처를 넣은 실행에서만 달라진다면, 애플리케이션 동작뿐 아니라 관찰 단계도 비교할 필요가 있습니다.
이 글은 2026년 10월 17일 공개된 Moli 1.1.18의 고정 소스를 검토한 설명입니다. 직접 설치하거나 실행해 얻은 벤치마크가 아닙니다. 아래 필터 화면은 동작 차이를 설명하기 위한 가상 사례입니다.
공식 소스의 배치 갱신 규칙과 테스트 기대값을 단순화한 AI 제작 개념도입니다. 직접 실행한 결과나 실제 스크린샷이 아닙니다. 오른쪽의 스크린샷과 PDF는 화면 배치가 80으로 남아 있는 같은 상태에서 각각 시작하는 별도 경로입니다.
이 도구를 살펴볼 계기는 최근의 관심 증가입니다. 프로젝트가 관리하는 별 이력 데이터의 2026년 10월 18일 갱신본에는 10월 10일 15,468개, 17일 19,262개로 기록돼 있어 두 날짜 사이 차이는 3,794개입니다. 이는 현재 남아 있는 별의 부여 시점으로 재구성한 이력입니다. 각 날짜에 독립적으로 보관한 집계나 실제 도입·품질을 뜻하는 수치는 아닙니다.
필터가 펼쳐진 뒤에도 같은 좌표를 눌러도 될까?
상품 목록에서 ‘필터 더 보기’를 누르면 추가 항목이 펼쳐지고, 아래쪽의 ‘적용’ 버튼이 밀려나는 화면을 생각해 보겠습니다. 버튼의 이름과 DOM 요소는 그대로입니다. 따라서 버튼을 찾는 검색은 성공할 수 있습니다. 그러나 이전에 읽은 버튼 위치까지 유효하다고 결론내리면 안 됩니다.
Moli의 비용 제어 문서에 따르면 기본 모드는 실제 배치 계산 대신 모의 기하 정보를 사용합니다. 실제 배치와 좌표 입력, 스크린샷이 필요한 작업에는 --layout을 켭니다. 그 상태에서도 배치는 계속 갱신되는 화면이 아니라 필요할 때 만든 스냅샷입니다. 일반적인 기하 정보 조회는 페이지가 바뀐 뒤에도 기존 배치를 재사용할 수 있고, 스크린샷은 현재 상태로 배치를 다시 만듭니다.
이미지와 폰트 등 선택적 리소스의 수집은 --resource 또는 개별 리소스 옵션으로 별도로 제어합니다. --layout만 켰다고 실제 사용자의 화면에 필요한 모든 리소스까지 가져오는 것은 아닙니다.
공식 테스트가 구분하는 80px와 120px
고정 버전의 layout_policy.py는 이 차이를 숫자로 표현합니다. 처음 너비가 80px인 요소의 배치를 만든 뒤 DOM에서 너비를 120px로 바꿔도, 기존 배치를 조회하는 경로에서는 80px를 기대합니다. 스크린샷을 새로 만든 뒤에는 갱신한 120px 배치가 남는 것을 검사합니다.
여기서 80과 120은 테스트 코드에 쓰인 기대값입니다. 이 글에서 실행해 확인한 측정값이 아닙니다. 테스트는 스크린샷 뒤 요소를 다시 160px로 바꾸고도 조회값이 120px로 남는지 확인합니다. 즉, 스크린샷 한 번으로 이후의 모든 변경까지 따라가는 구조를 기대해서는 안 됩니다.
PDF도 주의할 부분입니다. 같은 테스트는 Page.printToPDF를 화면 배치를 갱신해 남기지 않는 경로로 분류합니다. ‘렌더링 결과를 하나 만들었다’는 공통점만으로 PDF 출력을 스크린샷과 같은 새로고침 단계로 바꾸면 안 됩니다. 이는 PDF를 만들 수 없다는 뜻이 아니라, 화면 좌표 갱신과 문서 출력의 역할이 다르다는 뜻입니다.
일반 실행과 디버그 실행을 나란히 읽기
앞의 가상 필터 화면에 대입하면 두 흐름을 비교할 수 있습니다. 일반 실행은 ‘처음 위치 조회 → 필터 확장 → 위치 재조회’입니다. 디버그 실행은 ‘처음 위치 조회 → 필터 확장 → 스크린샷 → 위치 재조회’입니다. 두 번째 흐름에는 화면 배치를 다시 만드는 단계가 하나 더 있습니다. 따라서 조회값의 차이를 곧바로 우연한 타이밍 문제나 애플리케이션 수정의 효과로 해석하면 안 됩니다.
이것은 문서와 테스트에서 추론한 진단 방법입니다. 해당 필터 화면에서 잘못된 클릭을 재현한 결과는 아닙니다. 재현 기록에는 페이지에서 한 행동과 함께, 스크린샷·PDF 같은 관찰 호출의 종류와 순서, --layout 사용 여부를 남기는 것이 좋습니다. 장애 경로에 캡처를 추가했다면 그 추가 자체를 변경점으로 취급하세요.
목표가 상품명·가격·링크 추출이라면 필요한 데이터와 완료 조건을 검증하는 경로를 유지할 수 있습니다. 화면 좌표로 버튼을 눌러야 한다면 변경 뒤의 배치를 확인하고 클릭 뒤 실제 필터 적용 여부까지 봐야 합니다. 스크린샷 직후에도 애니메이션이나 비동기 응답으로 버튼이 움직일 수 있으므로, 캡처 한 번을 다음 클릭의 정확성 보증으로 쓰지는 마세요.
기존 브라우저를 남겨 둘 작업
처음 옮길 작업은 로그인이나 복잡한 화면 조작이 없는 공개 목록 추출처럼 결과를 직접 비교하기 쉬운 것으로 고르는 편이 낫습니다. 같은 입력에서 기존 수집 경로와 필요한 필드·누락 여부를 대조하고, Moli에서 지원하지 않는 상호작용이나 화면 재현이 필요한 작업은 기존 브라우저 경로로 돌립니다. 새 엔진에서 시간 초과가 났다는 이유로 같은 좌표 클릭을 계속 반복하는 방식은 피해야 합니다.
Moli는 Rust로 만든 독립적인 헤드리스 브라우저이며 Linux, macOS, Windows용 사용법을 제공합니다. CLI와 CDP, WebDriver 계열 연결을 지원하지만, 이것이 기존 브라우저의 모든 동작과 픽셀 표현이 같다는 보장은 아닙니다. 별도의 관리형 서비스인 Lexmount Browser 없이도 오픈소스 브라우저를 사용할 수 있습니다.
라이선스는 별도 표기가 없는 부분에 Apache-2.0 또는 MIT를 선택하는 방식이며, 제3자 구성요소와 자료에는 각각의 조건이 적용됩니다. 도입 전에는 라이선스 메타데이터와 배포에 포함할 구성요소의 고지를 함께 확인하세요.
Moli의 좌표 문제를 재현할 때는 관찰 순서까지 같아야 비교가 됩니다. 스크린샷을 넣은 실행에서만 조회값이 달라졌다면, 그 캡처가 새 화면 배치를 남겼는지부터 확인하세요.
댓글
댓글 쓰기