개발 slecs

입금 크롤링을 HTTP 직접 호출로 교체해 응답 10배 빠르게

목차

출발점

입금 내역 확인용 유틸이 헤드리스 브라우저로 은행 사이트를 띄워서 DOM 긁는 구조였음. 의존성 무겁고, 셀렉터 한 번 어긋나면 통째로 멈춤. 새벽에 알람 받고 일어난 적이 한두 번이 아니라서 진짜로 한 번 갈아엎고 싶었음.

무엇을 바꿨나

실제 동작을 패킷 캡처로 까보니 결국 로그인 토큰 받고 거래내역 조회 엔드포인트 두세 번 때리는 게 전부였음. 굳이 렌더링 엔진을 띄울 이유가 없었음. 그래서 직접 HTTP 호출로 다시 짬.

  • 로그인: 폼 파라미터 그대로 POST, 세션 쿠키 보관
  • 인증 단계: 응답 토큰 파싱해서 후속 요청 헤더에 실어 보냄
  • 거래내역: 응답 본문 받아서 도메인 객체로 매핑
  • 폴백: 직접 호출이 깨질 때만 헤드리스 경로로 떨어지게 유지

삽질

응답이 EUC-KR에 iframe 안에 또 form이 박힌 진짜 레거시 구조였음. Content-Type 헤더만 믿고 UTF-8로 파싱했다가 한글 전부 깨짐. HTTP 클라이언트 단에서 캐릭터셋을 강제 지정해서 해결함.

쿠키도 함정이었음. 일반 로그인 쿠키 외에 별도 보안 토큰을 hidden input 으로 넘기는데, 이걸 빼먹으면 조회 응답이 200으로 빈 배열만 돌아옴. 에러도 안 뱉어서 한참 헤맸음. 결국 응답을 신뢰하지 말고 한 줄 단언을 박는 게 답이었음.

응답이 200이라고 성공이 아님
- size > 0
- 첫 행 금액 > 0
- 거래일자 파싱 가능

효과

구분 변경 전 변경 후
평균 응답 8~12초 0.6~1.2초
컨테이너 메모리 약 1GB 약 250MB
외부 의존 헤드리스 + 드라이버 바이너리 HTTP 클라이언트만
새벽 호출 빈도 주 2~3회 0 (한 달째)

회고

제일 큰 교훈은 "브라우저 자동화는 마지막 카드"라는 것. 트래픽 까보면 의외로 평범한 HTTP 호출인 경우가 많고, 굳이 비싼 추상화를 쓸 이유가 없었음. 헤드리스 도구는 강력한 만큼 운영 비용도 정직하게 따라옴.

다만 직접 호출로 가면 상대 사이트 개편 한 번에 직격탄을 맞으니, 응답 구조 변화 감지용 헬스체크를 한 줄이라도 박아두는 게 정신건강에 이로움. 깨질 때 시끄럽게 깨지는 게 조용히 빈 배열로 깨지는 것보다 백 배 나음.

폴백으로 남겨둔 헤드리스 경로는 한 달 더 지켜보고 호출 카운트가 계속 0이면 지울 예정. 코드 한 줄 줄이는 게 또 한 번의 회고감이 될 듯.

다음

댓글 0

첫 댓글 달아줘.