요소를 찾은 것은 누른 것이 아닙니다. 누른 뒤의 변화를 확인하세요.
브라우저 자동화가 막힐 때 대부분은 오류 메시지 없이 조용히 어긋납니다. 스크립트는 요소를 찾았고, 클릭 명령을 보냈고, 정상 종료했습니다. 그런데 화면에서는 아무 일도 일어나지 않았습니다. 원인은 세 가지 중 하나인 경우가 많았습니다. 클릭을 받는 방식이 서비스마다 다르거나, 화면이 아직 그 동작을 받을 준비가 안 됐거나, 찾은 요소가 사실 내가 노린 그 요소가 아니었습니다. 세 가지 모두 공통점이 있습니다. 동작 뒤의 변화를 확인하지 않으면 알 수 없다는 점입니다. 그래서 자동화를 고칠 때 클릭 코드보다 확인 코드를 먼저 손보는 편이 빠릅니다.
클릭을 받는 방식이 서비스마다 다르다
코드로 만들어 낸 이벤트만 받는 화면이 있고, 실제 마우스 동작만 받는 화면이 있습니다.
후자에 코드로 만든 이벤트를 보내면 아무 반응이 없습니다. 오류도 나지 않습니다. 요소를 정확히 찾았기 때문에 스크립트 입장에서는 성공입니다.
그래서 처음 다루는 서비스에서는 클릭 한 번을 두고 방식부터 확인합니다. 잘 되던 다른 화면의 방식을 그대로 복사해 오는 것이 가장 빠릅니다.
확인 방법은 단순합니다. 누르기 직전과 직후의 화면 글자를 통째로 받아 두고 무엇이 달라졌는지 비교합니다. 달라진 것이 없으면 눌리지 않은 것입니다.
이 한 번의 확인을 서비스마다 한 번씩만 해 두면 그다음부터는 같은 방식을 그대로 씁니다. 매번 할 일은 아닙니다.
| 보이는 결과 | 가능한 원인 | 먼저 해 볼 것 |
|---|---|---|
| 아무 반응 없음 | 클릭 방식이 안 맞음 | 다른 방식으로 한 번 눌러 본다 |
| 반응은 있는데 값이 안 들어감 | 입력 이벤트가 빠짐 | 값 입력 뒤 변경 신호를 함께 보낸다 |
| 가끔만 성공 | 화면이 아직 준비 전 | 변화가 생길 때까지 기다린다 |
| 항상 다른 곳이 눌림 | 찾은 요소가 다름 | 선택 조건에 상한을 둔다 |
누른 것과 요청된 것은 다르다
버튼을 누른 직후 바로 다음 단계로 넘어가는 스크립트가 많습니다. 이게 자주 실패합니다.
서비스에 따라 클릭 뒤에 검사나 처리를 몇 초에서 몇 분까지 돌리는 경우가 있습니다. 그 사이에 화면을 옮기면 요청 자체가 취소됩니다.
그래서 완료를 알리는 문구를 실제로 본 다음에만 다음으로 넘어가게 했습니다.
완료 문구가 무엇인지는 첫 한 건에서 사람이 직접 확인해 둡니다. 누르기 전후 화면 글자를 비교하면 어떤 문장이 새로 생겼는지 바로 보입니다.
기다리는 방법을 두 단계로 나눈다
"로딩 표시가 없어지면 끝"이라는 조건은 위험합니다. 시작 전에도 로딩 표시는 없기 때문입니다.
그래서 나타났다가 사라지는 것을 두 단계로 봅니다. 먼저 진행 표시가 생기는지 짧게 기다려 확인하고, 그다음 사라질 때까지 기다립니다.
결과 문구는 한 박자 늦게 뜨는 경우가 많으므로 여유를 조금 더 둡니다. 특히 확인 대화상자는 화면이 정리된 뒤에 나타납니다.
| 단계 | 무엇을 기다리나 | 건너뛰면 |
|---|---|---|
| 1단계 | 진행 표시가 나타나는 것 | 시작 전을 완료로 착각한다 |
| 2단계 | 진행 표시가 사라지는 것 | 처리 중에 화면을 옮긴다 |
| 3단계 | 결과 문구가 뜨는 것 | 실패 안내를 놓친다 |
| 예외 | 고정 시간만 기다리기 | 빠르면 낭비, 느리면 실패 |
찾은 요소가 그 요소가 아닐 때
목록에서 특정 항목을 찾을 때, 키워드가 들어 있는 상위 요소를 거슬러 올라가며 찾는 방식이 흔합니다.
여기에 상한을 두지 않으면 목록 전체를 감싸는 요소까지 올라갑니다. 그러면 늘 첫 번째 항목을 집게 됩니다.
증상이 고약합니다. 스크립트는 매번 성공하고, 결과만 조용히 틀립니다.
범위를 글자 수나 요소의 역할로 제한해 두면 대부분 해결됩니다. 예를 들어 항목 하나의 글자 수 범위를 정해 두고 그 밖으로 나가면 멈추게 합니다.
| 증상 | 의심할 곳 | 고치는 방향 |
|---|---|---|
| 항상 첫 항목만 처리된다 | 위로 올라가는 범위 제한 없음 | 글자 수·역할로 상한을 둔다 |
| 가끔 엉뚱한 항목이 걸린다 | 선택 조건이 너무 넓다 | 조건을 두 개 이상 겹친다 |
| 결과가 비어 있다 | 거른 조건이 틀렸다 | 원문 한 건을 눈으로 본다 |
| 개수가 기대보다 적다 | 일부만 걸렸다 | 기대 개수와 실제 개수를 비교한다 |
확인은 넣을 때와 같은 방법으로
값을 넣을 때 쓴 경로와 다른 경로로 확인하면 두 가지 사고가 생깁니다. 없는 문제를 만들거나, 있는 문제를 놓칩니다.
값이 분명히 들어갔는데 다른 방법으로 읽으니 비어 보이는 경우가 대표적입니다. 그러면 멀쩡한 작업을 다시 하게 됩니다.
화면에 안 보인다고 값이 없는 것도 아닙니다. 표시 설정이나 서식 때문에 그려지지 않을 수 있으므로 관리 화면에서 확인합니다.
외부에서 받은 글자를 그대로 넣을 때도 주의합니다. 꺾쇠 같은 기호가 섞여 있으면 화면에서 그 부분이 통째로 사라져 보입니다. 저장하는 단계에서 바꿔 두는 편이 안전합니다.
여러 건을 한꺼번에 처리했다면 마지막에 개수를 셉니다. 기대한 개수와 실제 개수가 다르면 성공으로 끝내지 말고 그 자리에서 멈추게 합니다. 실패를 세기만 하고 정상 종료하는 스크립트는 실패를 숨깁니다.
여러 개를 돌릴 때의 부하
창을 여러 개 띄우면 따로 도는 것처럼 보이지만, 뒤에서 일하는 것은 하나인 경우가 많습니다.
한꺼번에 무거운 페이지를 여러 장 열면 응답이 느려지다가 연결이 끊깁니다. 끊긴 뒤에 바로 다시 붙이면 또 끊깁니다.
그래서 한 번에 여는 페이지 수에 상한을 두고, 연속 작업 중간에 짧은 휴식을 넣었습니다. 끊겼을 때는 1분 남짓 기다렸다가 다시 연결합니다.
작업을 중간에 멈출 때 정리 대상을 넓게 잡지 않는 것도 중요합니다. 이름이 겹치는 다른 작업까지 같이 멈추면 원인을 찾는 데 더 오래 걸립니다.
자주 묻는 질문
Q. 오류가 안 나는데 왜 실패인가요?
A. 요소를 찾고 명령을 보내는 데까지는 성공했기 때문입니다. 화면이 그 명령을 받아들였는지는 별개이므로 동작 뒤의 변화를 따로 확인해야 합니다.
Q. 기다리는 시간을 늘리면 해결되나요?
A. 일부는 해결되지만 느려지고 여전히 불안정합니다. 시간 대신 화면의 변화를 조건으로 삼는 편이 빠르고 정확합니다.
Q. 첫 항목만 처리되는 문제는 왜 생기나요?
A. 찾는 범위가 목록 전체까지 올라갔기 때문입니다. 범위에 상한을 두면 대부분 해결됩니다.
Q. 자동화가 자주 끊깁니다
A. 동시에 여는 페이지 수를 줄이고 연속 작업 사이에 휴식을 넣어 보세요. 끊긴 직후 즉시 재연결하면 다시 끊기기 쉽습니다.
확인 자료
- 자체 개발 운영 문서 · 현장 부록 v1.3 중 조용한 실패 분류
- 같은 문서의 클릭 방식·비동기 대기·탐색 범위 규칙
- 같은 문서의 도구 부하와 프로세스 정리 규칙
이 글은 직접 겪은 작업 기록을 정리한 것입니다. 확인하지 못한 항목은 본문에 쓰지 않았습니다. 대표 이미지는 이해를 돕기 위한 참고용 이미지입니다.