데이터 분석가로 업무를 수행한지 두 달이 되었습니다.
신입으로서 사수 없이 다양한 과제를 수행하다보니 다사다난했던 2개월이었습니다.

UI

초기엔 Airflow와 태블로를 위주로 데이터 수집 및 분석을 계획했지만,
네이버 등 대상 사이트 크롤링을 구현하는데 소비하는 시간이 크다보니
서버를 통한 체계적인 자동화를 구현할 여유가 없었습니다.

대신, Streamlit과 PyInstaller를 통해 UI를 구성하고
각각의 메뉴와 엑셀 설정 파일을 정의하여 자동화 서비스를 구현했습니다.

개발 환경이 짜여짐을 전제로 프로그램을 제작했던 이전과는 정반대로
아무것도 없는 윈도우 환경에서도 돌아가는 프로그램을 만들려다보니 적잖은 고민을 했습니다.
밑바닥부터 UI를 개발하려 했으면 그 자체로 많은 시간이 걸렸겠지만,
다행히 이전 교육 과정에서 활용해본 Streamlit을 도입하면서
UI에 대한 걱정을 일체하지 않고 크롤링 기능만을 구현할 수 있었습니다.

하지만, Streamlit도 마냥 편하게 사용할 수는 없었던 것이,
무료 배포 서비스의 제한된 자원 때문에 크롤링이 안정적이지 못했고
여러 사람이 하나의 서버에 붙다보어 크롤링이 진행되다 보니
대상 사이트로부터 차단당하는 경우도 있었습니다.

더욱이 Streamlit의 배포 서버가 해외 소재였기 때문에
쿠팡 크롤링 또는 그외 사이트의 로그인 등이 해외 IP 차단의 이유로 원활하게 이루어지지 않았습니다.

결국 로컬 환경에서 돌아가는 실행 프로그램이 필요했고,
초기에는 개인적으로 활용하던 Bittorrent Web 프로그램처럼
Streamlit을 로컬 브라우저에서 실행시키는 방안을 구상했지만,
생각만큼 쉽지 않아 단순히 크롤링 기능을 실행 프로그램으로 변환하는 것으로 타협했습니다.

사용자 편의성을 고려했을 때 GUI가 포함된 실행 프로그램이 좋을 수 있지만,
윈도우 작업 스케줄러를 통해 자동으로 돌아가는 방식을 고려 중에 있었기 때문에
최대한 사람 손을 거치지 않게 모든 설정을 엑셀 파일로 제어하게 하고
터미널에서 진행상황만 표시하도록 개발했습니다.

향후 Airflow와 같은 웹 서버 설계를 기대하지만,
현재로서는 위와 같은 실행 방식이 가장 개발 효율적이라 생각하여 진행 중입니다.

크롤링

이전까지 배운 크롤링은 HTML을 파싱하는 굉장히 단순한 수준이었고
파이썬 자체를 깊이 다뤄볼 일도 없었기에 requests 라이브러리로 크롤링을 시도했습니다.
하지만, 1주 정도가 크롤링 기능을 개발하면서 유지보수 대비 및 시간 개선의 필요성을 느끼고
다른 방안을 탐색했습니다.

당시부터 지금까지 집중하고 있던 것이 네이버 크롤링이었는데,
우연히 네이버 내 데이터는 Open API와는 별개의 내부 API로 전달되는 것을 파악했습니다.
이때부터 크롬 개발자 도구의 네트워크 탭에서 모든 데이터의 소스를 파악했고
네이버 쇼핑 한정해서는 보이는 모든 데이터를 가져올 수 있는 기반을 다졌습니다.

또한, 시간 개선을 위해 멀티 쓰레딩 방식을 알아보았고,
이와 유사한 비동기 방식이 파이썬에서 가장 효율적임을 인식하고
requests로 이루어진 코드를 asyncio 및 aiohttp로 변경했습니다.

이 과정에서 Scrapy의 Spider 및 Pipeline 구조를 참고해
기존의 함수 위주의 코드도 Spider, Parser, Pipeline으로 구분된 클래스 위주로 변환했습니다.
초기보다 훨씬 다양한 크롤링 기능이 생긴 지금도 위와 같은 구조 덕분에
코드 관리 및 재활용을 편리하게 수행하고 있습니다.

한편, 네이버 외에 이지어드민이라는 종합 쇼핑몰 관리 솔루션 내에서
데이터를 가져오는 과정에서 로그인을 requests로 처리하기 위해 많은 자료를 참고했습니다.
그 중에서 가장 도움이 되었던 것은 네이버 로그인을 requests로 구현한 네이버 블로그 자료였는데,
해당 내용을 통해 POST 요청 및 RSA 암호화에 대해 이해할 수 있었습니다.

덕분에 개발자 도구 네트워크 탭에서 로그인 과정을 역추적하는 식으로
이지어드민과 11번가 셀러오피스의 requests 로그인을 구현할 수 있게 되었고,
네이버 스마트스토어센터를 위한 2차 인증 또한 다소의 시간이 걸렸지만 해결할 수 있었습니다.
특히 네이버 2차 인증을 구현하면서 세션과 쿠키에 대한 개념을 잡을 수 있었습니다.

업무와는 별개로 개인적으로 크롤링에 고전하고 있는 jQuery 기반의 웹사이트가 있는데,
이런 특수한 경우를 제외하고는 대부분의 웹사이트 크롤링에 자신이 들었습니다.
또한, 여러 사이트의 소스를 뜯어보면서 자바스크립트에 대한 흥미가 생겼습니다.

대시보드

한달 전쯤, 외부 업체를 통해 외주를 맡기면서 구글 데이터 스튜디오 교육을 들었는데,
최근들어서는 이를 활용한 대시보드 제작에 개발하는 것보다 많은 시간을 쓰고 있습니다.

대시보드 제작 자체는 이미 예상된 일이었기 때문에 태블로를 공부한 이력이 있는데,
예상과 다른 BI 툴을 사용하게 되었습니다.

태블로와 비교했을 때 구글 데이터 스튜디오는 무료라는 장점과 함께
구글 플랫폼 내에서 쉽게 온라인으로 접근할 수 있다는 편의성이 있지만,
태블로 대비 많이 부족한 기능과 투박한 그래프 디자인의 단점이 있습니다.

태블로의 Fixed LOD나 툴팁 커스터마이징과 같은 기능이 없는 것이 다소 답답하지만,
최대 장점인 구글 플랫폼 내 연동성의 장점을 살려 순위 비교와 같은 설정을
구글 시트 내에서 구현하고 구글 데이터 스튜디오 내에 필드로 연동시키는 방식을 활용했습니다.

덕분에 구글 시트의 ARRAYFORMULA 등의 함수에 익숙해지게 되었고,
구글 시트의 매크로라고 할 수 있는 앱 스크립트도 조작해보았습니다.
앱 스크립트의 경우 자바스크립트 기반이기 때문에 크롤링 과정에서 느낀
자바스크립트에 대한 흥미를 가지고 재밌게 활용했습니다.

구글 데이터 스튜디오도 1주 이상 사용해보면서 업무현황을 관리하거나
매출 등을 참고할 수 있는 다양한 대시보드를 제작할 수 있게 되었습니다.
간단한 것은 테이블 계산식으로, 어려운 것은 구글 시트로 떠넘기다보니
태블로 대비 부족한 기능의 단점을 어느정도 보완할 수 있었습니다.

회사 차원에서는 향후 대시보드와 연계할 데이터 적재를 위해 빅쿼리 도입을 고려하고 있는데,
당장의 저는 구글 시트 API를 통한 업로드를 통해 다음 발전에 대비하고 있습니다.

앞으로

이 글을 작성하고 있는 시점의 저는 한 주 가까이 감기에 걸린 것과 함께
현재 진행 중인 업무가 대부분 마무리되면서 무료한 상태를 보내고 있습니다.
밤낮없이 하루종일 일만 했던 이전과 대비해서 편해진 것은 있지만,
갑작기 할일이 줄어든 것과 함께 감기로 인한 심경의 변화로 다소 의욕이 줄어들었습니다.

슬럼프보다는 약한 수준의 일시적인 현상이라고 생각하지만,
향후 흥미를 돋굴 새로운 일거리를 찾지 못한다면 좋지 못한 방향으로 갈 것이라 생각합니다.

개인적인 차원에서 평소 기획하고만 있던 크롤링을 개발하고는 있지만,
이보다 더욱 발전해서 팀 단위의 사이드 프로젝트를 기대하고 있습니다.
야근의 불확실성도 많이 개선되었기에 이제는 개발자끼리의 스터디를 통해
기술적 발전과 네트워킹을 같이 챙겨보려 합니다.