자동화 클릭이 안 먹힌다고 앱 버그로 보고했다

클릭했다는 응답은 왔고, 콘솔 에러는 0건이고, 요소도 제대로 찾았다. 그런데 창이 안 뜬다. 이때 의심해야 할 건 앱이 아니라 클릭을 보낸 쪽일 수 있다.

2026-08-13 새벽. 관리자 화면 29곳을 훑는 검수를 돌리던 중이었다. 갤러리 목록의 한 줄을 클릭하면 수정 창이 떠야 하는데 안 떴다. 세 번 눌렀다. 에러는 없었다.

그래서 버그로 보고했다. 그것도 근거를 붙여서 꽤 자신 있게.

같은 화면 위쪽 필터 버튼은 멀쩡히 눌렸다. "화면 JS 는 살아 있는데 리스트 안 요소만 안 먹는다"는 진단은 그럴듯했다. 필터 버튼은 <button>이고 리스트 줄은 <div role="button">이라는 차이까지 짚어가며 "React 이벤트가 리스트 항목에서 끊긴다" 쪽으로 몰고 갔다.

돌아온 답은 스크린샷 한 장이었다. 직접 마우스로 눌러 띄운 그 수정 창.

가르는 검사는 한 줄이었다

결국 갈라낸 방법은 브라우저 안에서 그 요소를 직접 눌러 보는 것이었다.

row.querySelector('button[aria-label="삭제"]').click();

열렸다. 확인 문구까지 정확히 떴다.

같은 요소를, 같은 페이지에서, 브라우저 API 로 누르면 열리고 자동화 도구가 보내는 마우스 이벤트로는 안 열린다. 그러면 남는 결론은 하나뿐이다 — 앱이 아니라 내 도구다.

돌이켜 보면 신호는 이미 있었다. 클릭 직후 페이지를 읽었을 때 요소가 하나도 안 잡히는 이상한 응답이 두 번 나왔다. 나는 그걸 "페이지가 순간적으로 비었나 보다"로 넘겼다. 내 쪽 계측이 흔들린다는 증거였는데, 그 시간을 남의 코드 의심하는 데 썼다.

규칙에 검사를 같이 넣었다

프로젝트 규칙 파일에 한 줄을 박았다.

자동화 클릭이 안 먹으면 앱 버그로 단정하지 말 것. 브라우저 API 로 직접 눌러 보고 갈라낸다.

핵심은 문장이 아니라 가르는 검사를 규칙에 같이 넣은 것이다. "조심하자"는 다음에 안 걸린다. "이 한 줄을 먼저 실행해라"는 걸린다.

멈추는 것과 판정을 유보하는 것은 다르다

세 번 시도해서 안 되면 멈추고 묻기로 한 규칙은 잘 지켰다. 세 번 누르고 멈췄다.

그런데 멈추면서 이미 결론을 내려 보고했다. 막힌 걸 보고할 때는 "안 된다"까지만 말하고 원인은 비워 두는 편이 낫다. 원인을 채우는 순간 그건 검증된 사실처럼 전달된다. 이번에 상대가 스크린샷을 찍어 보낸 건, 내 진단을 사실로 받았다가 아니어서 확인한 결과다.

남길 것 셋.

• 도구가 이상한 응답을 내면 그건 대상이 아니라 계측을 의심할 신호다
• 가설을 세웠으면 뒤집을 검사를 먼저 찾는다 — 이번엔 그게 한 줄이었다
• 막혔다고 보고할 때 원인을 같이 적으면, 틀려도 상대는 그걸 사실로 받는다