지난 1년간 겪은 모든 장애는 로직이 아니라 내비게이션 계층에서 발생했다
Everything I've had break in the last year broke at the navigation layer, not the logic
핵심 요약
UI 자동화의 취약성을 지적하며, API 엔드포인트 직접 호출과 데이터 검증의 중요성을 논의합니다.
- UI 자동화 한계 — 웹 페이지 구조 변경으로 인한 스크립트 오류가 잦음
- API 호출 대안 — UI 대신 백엔드 엔드포인트를 직접 호출하여 안정성 확보
- 데이터 검증 난제 — 스키마는 정상이지만 값은 틀린 '의미론적 오류' 탐지 어려움
- 자동화 전략 — 웹사이트별 최적화 전략을 사용하는 도구 활용
지난 1년간 겪은 실패 사례를 되돌아보니 로직 버그는 거의 없었어. 전부 작동하던 스크립트에서 페이지가 바뀌어 발생한 문제들이었지. 클래스 이름이 바뀌거나, div 이름이 변경되거나, 셀렉터가 아무것도 매칭하지 못해서 스크립트가 빈 값을 반환하는 식이었어. 3일 뒤에야 알게 된 적도 있고.
살아남은 스크립트들은 UI를 건너뛰고 프론트엔드가 호출하는 엔드포인트를 직접 때린 것들이야. 설정하기는 더 지저분하지만 훨씬 안정적이지. 요청 형태는 마크업보다 훨씬 덜 변하니까.
최근에는 이걸 위해 webcmd를 써보고 있어. 브라우저를 기본값으로 쓰는 대신 사이트별로 전략을 선택하거든. 공개 엔드포인트 우선, 그다음 세션 쿠키, 그다음 가로챈 요청 재실행, 그리고 다른 선택지가 없을 때만 클릭하는 식이지. 내가 직접 수동으로 하던 방식과 같은 아이디어인데, 수동이 아닐 뿐이야. Apache-2.0 라이선스고, npm install로 설치하는 초기 단계 프로젝트야.
그래도 근본적인 문제는 해결 안 돼. 빈 값을 반환하는 스크립트는 쉽지, 비어있으면 알림을 보내면 되니까. 진짜 아픈 건 뭔가 잘못된 값을 반환하는 스크립트인데, 아직 좋은 탐지 방법을 못 찾았어. 스키마 체크는 형태가 바뀌면 잡아내지만, 형태는 정상인데 값이 쓰레기일 때는 아무것도 못 잡아내거든.
매주 눈으로 확인하는 것보다 더 나은 방법 쓰는 사람 있어?
