22년 1월 현재 한 스타트업에서 인턴십을 하면서 웹 크롤러를 담당하는 중인데. 지난 몇 개월간 웹크롤러 개발을 경험해보니 작업시간의 대부분은 동적으로 가져오는 데이터를 처리하는데 쓰인다는 것을 몸으로(?) 배울 수 있었다
그럴 땐 개발자도구의 네트워크 탭을 하나하나 뒤져서 필요한 값을 가져오기 위해 서버 측 API가 보낸 response를 찾아야 한다. 이 방법은 구글링하면 금세 찾을 수 있는데 문제는 그걸 따라해도 원하는 정보를 찾기 힘든 경우들이 제법 있었다 인생... 고작 검색 한 번에 풀릴 줄 알았더냐?
그중에서도 매우 자주 겪은 문제는 이런 경우였다
첫번째 옵션을 클릭했을 때 이벤트가 발생하면서 두번째 옵션의 데이터를 로드하여 태그를 동적으로 생성하는 경우인데
이런 경우 기본 두 번째 옵션의 데이터를 얻을 수 있는 경우의 수는 다음과 같다
-
html 파일의 두 번째 옵션 태그의 attribute에서 상품의 정보를 가져온다
-> 없는 경우 >>>>>> 있는 경우감사합니다ㅜㅜ -
html 파일에 해당 페이지에 필요한 데이터를 모두 담은 tag나 json객체가 있어 거기서 가져온다
-> domain이 호스팅 서비스를 이용할 경우 높은 확률로 있다. 하지만 곧 언급될 A호스팅 서비스의 경우 데이터가 실제와 다른 경우가 많았다 (특히 재고수량) -
option정보 API가 보낸 response가 있기를 기도하며 개발자 도구 네트워크 탭의 xhr 파일들을 뒤져본다
-> 그러나 없다면?... -
이벤트 발생시에 option정보 API를 호출하는 request의 형식을 파악하기 위해 js파일을 뒤져본다
-> API key를 알려줄리가...아 망했어 역시 안 될 거야
있었다
A 호스팅 서비스(서비스명은 비공개)를 이용하는 한 domain(인터넷쇼핑몰)의 html 태그에서 찾은 category정보가 상품의 유형을 파악할 수 없는 것이었는데 지금 참여중인 프로젝트에서 상품의 유형 정보는 꼭 필요했다
그래서 이를 해결하고자 js파일에서 category 정보를 호출하는 ajax 요청을 살펴보던 도중 api key 변수에 값을 할당할 때 특정한 이름의 변수를 사용하는 것을 발견하고 이를 html파일에서 검색했더니 다른 api를 요청하는 uri에서 검색 결과가 나와버렸다 띠용
나중에 안 것이지만 같은 이름의 변수를 A 호스팅 서비스 뿐만 아니라 instagram이나 google등의 외부 API를 호출할 때도 사용하는 domain이 많았는데, 그걸 몰랐음에도 우연의 일치로 검색된 값이 하필 또 정확한 key여서 API가 보낸 response를 받는 데 성공하고 만다
하지만 슬프게도 option별 재고정보 API가 보낸 response조차 재고수량이 정확하진 않았다.
아니?...A 호스팅 서비스의 경우 쇼핑몰측에서 재고관리 옵션을 사용하지 않을 수도 있어서 그런 것 같았다
이 부분은 결국 팀원이 js 파일에서 찾아낸 'html 파일의 특정 script 태그(앞서 언급한 3번째 경우의 수)안 의 몇 가지 변수들을 사용한 if문'이 실제 재고수량과 더 일치하는 것으로 판단되어 후술할 super class에서도 이를 최종적으로 적용하였다
이후에 다른 domain에서도 똑같은 방법을 사용해보니 A 호스팅 서비스의 API를 이용하여 개발된 쇼핑몰들 중 이렇게 Front API key가 html파일에 노출되어 있는 곳이 상당히 많았다. 심지어 해당 uri를 갖고 있는 script 태그의 위치마저 같은 경우도 많았다
이렇게만 들으면 큰 보안 위협처럼 느껴지지만, 다행히 노출되어있는 key는 데이터의 read만 가능한 Front API key여서 이를 이용해 DB의 데이터를 직접 수정할 수 있는 일은 없다 하지만 그럼에도 역시 보안에 좋은 상태는 아닐 것 같다
A 호스팅 서비스 기반의 쇼핑몰 개발대행업체들 중 일부 혹은 특정 업체가 이를 간과하고 작업하지 않았을까 조심스레 추측해본다. 그러므로 이를 A 호스팅 서비스 운영업체의 과실로 볼 순 없을 것이라 생각한다
그렇지만 덕분에 크롤러 개발자인 나는 일이 편해졌다. 이를 이용해 해당 key가 노출된 크롤링 domain들에 사용할 super class를 만들 수 있었기 때문이다. 최근 수십개의 크롤러를 새로 작성해야하는 업무를 진행중이었는데 super class를 작성한 이후 그 중에서 대다수를 차지했던 A 서비스로 호스팅된 도메인들을 상속을 통해 훨씬 빠르고 정확히 처리할 수 있었다
이 작업 이후 나는 크롤러를 프로그래밍할 때 html태그 보다는 가장 먼저 네트워크 탭에서 xhr 파일과 js파일을 뒤져보면서 상품 정보 API를 호출하는 uri와 그때 필요한 key가 노출되어 있는 지를 먼저 살펴보게 되었다
나의 크롤러 개발 원칙
: 가능하면 html 태그를 select 하지 말자. 도저히 안 될 때만 하자
이렇게 직접 html 태그를 select하지 않아야 코드의 재사용성이 높아져서 유지보수가 쉽고 신규 크롤러를 작성할 때 새로 작업해줘야 할 부분도 줄어들어서 확장성도 높아진다
특히 각 쇼핑몰들의 자잘한 업데이트 때마다 수시로 변경될 수 있는 html 태그와는 달리 여러 고객들이 동시에 사용중인 호스팅 서비스의 API를 호출하는 uri의 경우 상대적으로 훨씬 긴 주기로 변경될 것이기에 이 방법은 더 효율적이리라 예상한다
이번에 인턴십을 통해 크롤러 개발을 경험해 보니 그 기술적 난이도에 비해 도메인마다 우리가 필요한 데이터를 처리하는 방식이 달라 은근히 시간이 오래 걸리고 까다로웠다
하지만 그런 한계 속에서도 최대한 패턴을 찾아내서 작업을 단순화하려면 html 태그를 select하지 않고 데이터를 가져올 수 있는 방법을 찾아야 한다는 것을 A호스팅 업체의 케이스를 작업하면서 배울 수 있었다
