연락처이체 자동화 오류 13건을 조건 대기와 이중 검증으로 해결

13개가 한꺼번에 터졌다

연락처이체 웹 자동화가 또 깨졌음. 은행별 페이지 구조가 미묘하게 달라서 한 곳 고치면 다른 데서 터지는 두더지잡기. 이번엔 분산해서 잡지 말고 13개 케이스 한꺼번에 모아서 정리함.

증상은 비슷했음:
- "이체 성공"으로 찍혔는데 실제 거래는 미체결
- 페이지 전환 도중 다음 step 클릭해서 element not found
- 보안 모달이 늦게 떠서 selector miss
- 완료 페이지 미노출인데도 success 판정

진짜 원인은 "기다림이 부족했다"

waitForTimeout(2000) 같은 고정 sleep으로 버티고 있던 코드가 절반 이상이었음. 네트워크 지연이나 은행 서버 응답이 느려질 때 그대로 깨짐. 시간으로 막으면 시간으로 부족할 수밖에 없음.

정리한 패턴은 두 가지:

핵심은 waitForFunction. 시간이 아니라 조건이 만족될 때까지 폴링하니 빠른 환경에서는 빨리, 느린 환경에서는 느리게 자동 적응함.

await page.waitForFunction(
  () => document.querySelector('.complete-msg')?.innerText.includes('정상처리'),
  { timeout: 30000 }
)

완료 검증을 한 번 더

가장 골치 아픈 건 "성공처럼 보였는데 실제로는 미체결"인 케이스였음. 이체 직후 거래내역 조회를 한 번 더 호출해서 금액·수취인이 일치하는지 검증하는 단계를 추가. 응답상 success여도 거래내역에 안 잡히면 실패로 떨어뜨림. 운영에서 "이체됐다고 떴는데 안 갔다"는 CS가 가장 신뢰를 깎아먹는데, 이중 확인 한 줄로 거의 사라짐.

회고

• 외부 시스템 자동화에서 sleep은 결국 부채. waitForCondition이 정답.
• 성공 응답을 믿지 말고 "결과 상태"로 한 번 더 검증. 두 번 보면 한 번은 보임.
• 비슷한 버그는 모아서 한 번에 정리하는 게 효율적임. 분산해서 고치면 공통 패턴이 안 보이고, 각자 다른 방식으로 미봉책 박힘.
• 추상 베이스에 검증 훅을 박아두니 새 은행 추가할 때 빼먹기 어려운 구조가 됨. 결국 버그 13개가 베이스 리팩터링의 명분이 됨.

다음