(후기) 키워드 크롤러를 만들고 나서...
왜 만들었나?
수작업을 줄여보자.
과거 어떤 사람이 프론트 엔드 개발자 채용 공고에서 직접 수집한 키워드를 빈도수 별로 모은 자료를 보여준 적이 있다.
이후에 크롤러의 존재에 대해 알고 나서 물어보니 수작업으로 했다고 한다. (그렇기 때문에 신뢰도가 좀 더 높은 것 같다.)
이런 수작업(노가다성)을 어떻게 하면 줄일 수 있을까 고민을 하면서 만들어보고 싶다는 막연한 생각만 가지고 있었다.
백엔드 개발자가 되려면 뭘 공부해야하는지 알고 싶었다.
작년부터 같은 고민을 했지만 백엔드 개발자가 되고 싶었다. HTML/CSS를 만지는 시간은 행복하지 않았고,
오로지 자바스크립트 하나 때문에 프론트 엔드 개발 공부를 계속 했고, 쉽게 쉽게 취업하자는 생각에 프론트 엔드 개발자로 취업을 하였다.
(프론트 엔드 개발자로 취직하는 게 쉽다는 게 아니라 내 기준에서 프론트 엔드 개발 공부만 1년 가까이 했기 때문에 백엔드보다 더 쉽다는 뜻이다.)
하지만 작업하면서 역시나 행복하지 않았다. 그래서 그런지 작업 속도도 느리고, 내 코드 자체에 만족하지 못했다.
백엔드도 직접 경험해본 건 아니어서 재미없다고 생각할지 모르겠지만 후회하더라도 직접 경험 해보고 후회하고 싶었다.
다른 사람들은 목표로 정한 회사가 있느냐고 물었지만, 나는 그냥 개발이 중심이고, 대우받는 그러한 환경에서 작업을 한다면 다른 건 크게 신경쓰지 않는 타입이다.
어찌보면 어리석고 철이 덜 들은 건지 모르겠지만 개발 이외에는 하기가 싫다는 생각이 들었다. (물론 고쳐야할 생각이다.)
따라서 일단은 회사를 목표로 하기 보다는 여러 기업에서 백엔드 개발자라면 어떤 걸 알고 있어야하는지 알아내는 게 중요했다.
최대한 많은 회사에서 요구하는 것들부터 집중적으로 배워나가면 된다고 생각했기 때문이다.
좋았던 점
배웠던 걸 써먹을 수 있었다.
자바스크립트와 Node.js를 이용한 웹 크롤링 테크닉란 책으로 스터디를 한 적이 있었다.
책의 구성은 큰 덩어리 덩어리로 나눠져 있지만, 그 내부의 작은 덩어리로 봤을 때는 되게 비슷한 내용들끼리 묶여져있어서
스터디를 할 때도 계속 비슷한 예제 타이핑하고 실행해보고 하느라 다소 지루한 감이 없지 않았고, 후딱 끝내버리자는 의견도 나왔었다.
책 안의 내용 자체는 좋았지만 ‘이걸 일일이 타이핑하고 실행해봐야하나’라는 의문이 들 정도였다.
그래도 해당 주제로 스터디를 한 바람에 크롤러, 헤드리스 브라우저, 형태소 분석기 등등 어떤 키워드로 검색해야할지,
샘플 코드는 뭘 참조해야할지에 대해 힌트를 많이 알고 있었기 때문에 크롤러를 만들어보는데 훨씬 수월하였다.
비동기 작업을 동기식으로 작성해 볼 기회가 많았다.
- 무한 스크롤을 하기 위해서는 순차적으로 스크롤을 아래로 계속 내려야하는 점.
- 채용 공고 하나 들어가서 수집하고 다시 다른 공고 들어가서 수집하고 순차적으로 이뤄져야한다는 점.
위 코드들을 작성하면서 async/await를 제대로 써본 것 같다.
그러면서 Async/Await는 배열 표준 메소드에서 작동하지 않는다.라는 점도 알게 되었다.
아쉬웠던 점
타입스크립트 넘나 어려운 것
맨 처음에는 타입스크립트를 도입하려고 했다.
하지만 팬텀 자체도 phantomjs에서 phantomjs-prebuilt라고 이름을 바꿀 만큼 변화가 많았는데
phantomjs에 대한 d.ts는 있었는데 phantomjs-prebuilt에 대한 d.ts는 없었다.
새로 만들자니 시간도 오래 걸릴 것 같고… 이거 때문에 너무 시간을 지체하는 느낌이 많이 들었다.
약 만 하루동안 타입스크립트를 가지고 뻘짓을 해보다 과감히 포기하였다.
나중에… 나중에는 기필코 타입스크립트를 다른 라이브러리들과 함께 써봐야겠다.
테스트 코드의 부재
역시나 테스트 코드를 작성하는 건 감을 잡기 어렵다.
테스트 코드를 작성하는 것보다 무엇을 테스트 해야할지를 감을 못 잡겠다.
그러다보니 그냥 코드만 계속 작성하고 결국 테스트 코드는 작성하질 못했다…
하… 나 혼자 스스로 능동적인 공부를 해 본 경험이 적다보니 역시 이런 쪽은 쥐약이다 ㅠㅠ…
외국어 형태소 분석의 부재
mecab-ko-dic에는 한국어 단어만 들어가있어서 외국어의 형태소 분석이 되질 않는다.
따라서 이 예제는 외국어로 작성된 채용 공고에는 부적합하다.
형태소 분석을 두 번 돌려야하는 것 같은데… 넘나 어려워보여서 시도도 하지 않았다 ㅜㅜ
하지만 역으로 국내 쪽 채용 공고는 기술 스택들만 영어로 기재하는 경우가 있어서 오히려 신뢰도가 높다는 장점도 존재한다.
이상한 키워드까지 분류된다
형태소 별로 분석하다보니 구두점이나 쓸 데 없는 기호들, 을/를과 같은 조사 등등은 빠져서 참 좋다.
명사만 필터링해서 좋긴 좋은데… 아래와 같은 단점이 존재한다.
- 웹 표준 이라는 키워드가 있으면 웹 따로 표준 따로 분류해버린다.
- 프론트 엔드 개발 같은 경우에도 세 가지를 따로 따로 분류해버린다.
- 기업이 채용 공고에 기술 스택만 올리는 게 아니다보니 관련 없는 단어들까지 분류돼서 나온다.
아직 실력이 많이 모자라서 일일이 수작업으로 해야하는데 손이 너무 많이 가는 작업이라 엄두도 못 내고 있다.
차트나 그래프로 표시하기에 부적합하다.
이상한 키워드들이 너무 많이 뽑혀져 나오다보니… 차트나 그래프로 표시하면 알아보기 힘든 경우가 굉장히 많다.
화면은 한정적인데 키워드들이 너무 많아서 렉이 걸리거나 마우스를 올려도 원하는 곳으로 올리기 힘든 경우도 있고…
그렇다고 표로 표시하기에는 너무 길어지고 이쁘지도 않아서… 이 문제점은 확실히 이상한 키워드들을 전부 필터링해야 어느정도 해결이 될 것 같다.
특정 사이트에 한정적이다.
이 예제만 하더라도 페이지네이션 페이지에는 부적합하고 무한 스크론 페이지에만 적합하다.
또 내가 만든 원티드 크롤러만 하더라도 원티드의 마크업 구조가 달라지면 해당 내용을 제대로 크롤링하지 못할 수도 있다.
원래 크롤러가 그런 건지 모르겠지만… 이거는 도저히 내 머릿 속에서는 해결이 불가능한 난제로 남을 것 같다.
남은 숙제들
서버 구현하기
매일 매일 정보를 크롤링해서 업데이트 하려면 24시간 켜져있는 서버 혹은 수동으로 매일 매일 해줘야한다.
하지만 수동으로 하는 것은 비효율적이고 서버를 한 대 구동해야하는데 집에 남아있는 컴퓨터가 없다.
이를 위해서 한 번 라즈베리 파이를 사서 리눅스도 올려보고, 웹 서버도 올려보고 이것저것 해보고 싶다.
좀 더 검토해보고 라즈베리 파이를 사서 직접 서버를 구현해보면서 백엔드의 이것 저것을 공부해봐야겠다.