파트너 정산 은행 자동화 UI 감지 로직 개선과 에러 분류

은행 자동화에서 만난 함정

파트너 정산 자동화 손볼 일이 있어서 특정 은행 웹 자동화 핸들러를 다시 깠음. 단순 셀렉터 교체겠거니 했는데, 막상 들어가보니 UI 감지 로직 자체가 깨져있었음.

문제 상황

기존 코드는 페이지 진입 후 고정 selector 하나로 "직접받기" 버튼을 찾고 있었음. 그런데 상대 사이트가 UI 를 살짝 바꾸면서 버튼이 여러 형태로 나타나게 됨.

• 케이스 A: 모달 안에 버튼이 바로 노출
• 케이스 B: 본인인증 단계가 한 번 더 끼면서 버튼 위치가 밀림
• 케이스 C: 점검 배너가 떠서 버튼 자체가 비활성

원래 로직은 케이스 A 만 전제로 짜여 있어서, B/C 가 들어오면 null 참조가 터지거나 자동화가 무한 대기에 빠졌음. 운영 알람만 시끄럽게 울리고 정작 어디서 깨졌는지 잡기 어려웠음.

어떻게 고쳤나

세 가지를 동시에 손봤음.

핵심은 "셀렉터 하나로 끝낸다"는 가정 자체를 버린 부분이었음.

1. 페이지 로드 대기
2. 점검 배너 감지 → 있으면 즉시 종료
3. UI 변종 A/B 둘 다 시도 (우선순위 순)
4. 클릭 가능 상태 체크 후 액션
5. 실패 시 스크린샷 저장 + 에러 코드 분리

기존엔 모든 실패가 "자동화 오류" 한 종류로 뭉개져 있었는데, 이번에 UI_CHANGED / SITE_MAINTENANCE / AUTH_EXPIRED 로 코드를 쪼갬. 운영팀이 보고 바로 어디 갈지 판단 가능해짐.

배운 것

• 외부 사이트 자동화는 상대방이 언제든 UI 를 바꾼다는 전제로 설계해야 함. 우리 쪽 코드 안 바뀌어도 깨지는 게 정상.
• 에러를 한 덩어리로 묶지 말고 분리해야 함. "어디서 깨졌나"를 코드에 남기는 게 결국 다음 장애 때 본인을 살림.
• 실패 시점 스크린샷 저장은 처음엔 귀찮아 보였는데, 직후 진짜 장애 한 건을 5분 만에 분석시켜줬음. 투자 대비 효과 압도적.
• 자동화에서 가장 위험한 건 "에러"가 아니라 "조용한 실패". 무한 대기보다 차라리 빨리 죽는 게 낫다는 걸 다시 체감함.

남은 숙제

점검 케이스를 메신저로 별도 분기해서 운영팀이 즉시 인지하도록 하는 작업이 남음. 자동화는 결국 "실패를 잘 알리는 것"이 절반 이상이라는 결론.

다음