벨로그 워드클라우드
월간 사이드 프로젝트를 기획 진행하고 있다. 첫 시작인 5월에는 벨로그의 글을 워드클라우드 형태로 분석해서 보여주는 서비스를 만들어보았다.
웹 페이지에서 벨로그 아이디만 입력하면 최근에 작성한 3개 글을 분석하여 워드클라우드 형태로 보여준다.
내가 만든 워드클라우드는 불용어를 제외한 명사들만 분석하여 보여주는데, 예를 들어 ‘나는’, ‘는데’, ‘습니다’, ‘그리고’, ‘또한’, 같은 단어들을 제외하여 의미가 유효한 단어들만 보여준다.
개발 목적
예전부터 블로그를 단어 단위로 분석해보고 싶었다. 특히 개발자마다 어떤 단어들을 많이 사용하는지 확인해보고 싶었는데, 이번 기회에 글을 워드클라우드 형태로 보여주고자 했다.
워드 클라우드란? 쉽게 말해 글을 아래 이미지처럼 보여주는 것이다. 단어의 빈도수에 따라 크기가 대비되기 때문에 어떤 단어를 많이 사용하는지 한눈에 파악할 수 있다는 것이 장점이다.
개발 과정
1. 아이디어 선택
프로젝트를 진행하기에 앞서 여러 가지 아이디어들을 작성해두고 그중에 가장 관심이 가는 것에 도전했다. 그렇게 5월은 ‘벨로그 워드클라우드’를 진행하게 되었다.
아이디어 페이지에는 목표와 유저 스토리를 간단하게 적었다. 그리고 구현하는데 필요한 레퍼런스 자료들을 수집했다.
사실 처음에는 티스토리를 분석하고 싶었다. 하지만 티스토리는 개인마다 글을 스크래핑할 수 있는 html 태그가 달랐고, 태그가 일관된 벨로그로 도중에 타깃을 바꾸었다.
2. Task 생성
아이디어를 선택한 후에는 Task를 작성했다.
초기 세팅부터 백엔드, 프론트 각 포지션이 해야 할 일들을 세분화시키고 Task 안에는 다시 체크리스트를 만들어 차근차근 문제들을 해결할 수 있도록 설계했다.
3. 진행사항 공유
혼자 하는 프로젝트의 단점은 늘어지기 쉽다는 것이다. 처음에는 열정적으로 하다가도 문제가 생겨 삽질이 길어지면, 이게 다 무슨 소용인가 싶기도 하고 ‘나중에 해야지’라며 손을 놓기도 한다.
이런 상황을 대비해 프로젝트를 한 달 단위로 만들고 Task를 세분화해서 나눈 것이지만, 그럼에도 동기부여가 더 필요했다. 어떻게 하면 더 재밌게 작업할 수 있을까 고민하던 나는 주변 동료들에게 내 진행사항을 공유하여 외적 동기를 얻기로 했다.
‘사내 자기 계발 채널’이나 ‘개발 스터디 모임’을 통해 내가 만든 결과물을 공유하고 프로젝트를 소개했다. 내가 만든 결과물을 소개하니 스스로가 뿌듯하고 만족감이 들었다. 또한 내가 생각하지 못했던 피드백을 마감 전에 미리 받아볼 수 있어서 최종 결과물의 완성도를 더 높일 수 있었다.
‘함께 자리기’라는 책을 보면 ‘고객 참여’를 강조하는데, 이번 프로젝트에서 조금이나마 그 힘을 느낄 수 있었다.
마주친 문제들
많은 문제들을 만났지만 그중에 세 가지만 말해보겠다.
1. JAVA_HOME 경로 문제
앞서 언급한 불용어 처리를 위해서 konlpy 라이브러리를 사용했는데, 해당 라이브러리는 java 패키지를 필요로 했다. 하지만 m1의 경우 일반적인 java 버전을 konlpy 가 인식하지 못하는 문제가 있었다. 이 때문에 한참 헤매었었는데, 결국 m1에 적합한 java 패키지를 설치하여 해결할 수 있었다.
이에 대해서는 글로 남겨두었다.
konlpy _ m1 mac 에서의 JAVA_HOME 경로 문제
워드 클라우드 최근 토이 프로젝트로 '워드 클라우드'를 구현하고 있습니다. 워드 클라우드란 단어의 빈도에 따라 크기를 다르게 보여주는 데이터 시각화 기법 중 하나입니다. 워드 클라우드를
daco2020.tistory.com
2. 워드클라우드 구현 위치
처음에는 워드클라우드를 프론트에서 구현할 생각이었다. 때문에 js와 관련된 라이브러리를 찾아두었었는데, 막상 구현하려고 보니 어려웠다. 반면 파이썬으로 구현할 경우 더 쉽고 빠르게 구현할 수 있었는데 그러다보니 워드클라우드를 프론트에서 구현할지 백엔드에서 구현할지 고민이 되었다.
결국 5월 내에 프로젝트를 마치기 위해 백엔드에서 구현하기로 결정했다. 파이썬에는 ‘wordcloud’라는 라이브러리가 있어서 쉽게 워드클라우드 이미지를 생성할 수 있었다. 하지만 막상 이미지 파일을 프론트로 보내주는 방법을 몰랐다. 개발을 배우면서 json만 반환해보았지 파일 자체를 반환하는 것은 생각해보지 못했다..
문제를 해결하기 위해 외부 클라우드 서비스를 사용할 수도 있겠지만 인프라가 불필요하게 커지는 것은 지양하고 싶었다. 다행히 fastapi에서는 파일을 반환하는 간단한 방법이 있었고 프론트에서도 자체 이미지 url을 만들어 이미지를 브라우저에 보여줄 수 있었다.
3. 배포 문제
이번 프로젝트는 배포를 실패했다. 무언가 잘못된 것인지 도커나 aws 배포 과정에 에러가 많았고 서버를 열어도 프론트와 연결이 되지 않아 결국 배포를 하지 못했다. 데모 서비스를 공개하지 못한 게 이번 프로젝트에서 가장 아쉬운 점이다..
배포 실패의 가장 큰 원인은 두 가지인 것 같다.
- 패키지 관리 문제 - 패키지 관리를 한다고 했지만 누락된 것들이 있거나 java패키지나 폰트의 경우 수동 관리가 필요했다.
- 인프라에 대한 무지 - 도커나 aws에 대해 자세히 모르니 하나가 막힐 때마다 삽질을 많이 했다.
앞으로는 패키지 관리에 대해 좀 더 주의를 기울이고, 특히 인프라에 대해서는 제대로 된 공부가 필요해 보인다.
앞으로의 계획
‘벨로그 워드클라우드’는 서비스 자체의 문제들도 많이 가지고 있다. 벨로그만 분석할 수 있고, 글을 분석하는데 많은 시간이 걸린다. 에러 핸들링이 불명확하고, 원인을 알 수 없는 버그도 있다. 또한 스크래핑 기반 서비스이기 때문에 윤리적 문제를 가질 수 있고, 벨로그의 html tag가 변경되면 더 이상 서비스를 유지할 수 없다.
최근 ‘린 스타트업'을 읽다가 문득 내가 만들고 있는 서비스가 얼마나 가치 있는 것일까? 라는 의문이 들었다. 이왕 무언가를 만드는 것이라면 사용자에게 가치있는 서비스를, 자주 사용할 수 있는 서비스를 만들고 싶었다. 그런 관점에서 이번에 만든 서비스는 많이 부족해 보였다.
지금의 서비스를 개량해서 새로운 서비스를 만들 생각이다. 앞서 언급한 단점들을 보완 또는 우회하여 사용자에게 더 가치 있는 서비스를 제공하고 싶다. 예를 들어 단순히 스크래핑한 글을 분석하는 것이 아닌, 유저가 글을 직접 선택하여 글과 글을 비교 분석해주는 서비스, 워드클라우드 형태의 분석뿐만 아니라 어떤 경향성에 대한 정보를 제공하는 서비스, 비교한 정보를 저장 및 공유할 수 있는 서비스, 등 사용자에게 더 도움이 되고 활용도가 높은 서비스를 만들어보고 싶다.
6월에는 다른 프로젝트가 계획되어 있어 5월 프로젝트는 여기서 마감하지만, 가까운 시일 내에 다시 도전해보고 싶다.
마무리 소감
월간 사이드 프로젝트는 하나의 궁금증으로 시작하였다.
“2개월 차 신입 개발자가 사이드 프로젝트를 완성할 수 있을까?”
이러한 물음에 답을 얻기 위해선 역시 직접 해보는 수밖에 없었다. 그리고 5월 한 달간 직접 프로젝트를 진행하면서 내가 내린 대답은 ‘충분히 가능하다’이다. 프로젝트를 진행하며 몇 가지 우려도 있었는데 이에 대한 답도 얻을 수 있었다.
Q. “사이드 프로젝트를 할 시간이 있을까?”
A. 막상 집에서 개발한 시간보다 빈둥거리는 시간이 더 많았다. 즉 시간은 부족하지 않다.
Q. “회사 업무를 소홀히 하는 것은 아닐까?”
A. 현재 업무에 대해서는 긍정적 평가를 받고 있다. 오히려 사이드 프로젝트를 통해 리프레시도 되고 더 넓은 시야로 개발을 바라볼 수 있었다. 업무와 관련된 기술로 프로젝트를 한다면 오히려 업무에 도움이 될 것 같다.
배포는 하지 못했지만, 처음 궁금증에 대한 답을 찾았다는 점에서 이번 프로젝트는 성공했다고 말하고 싶다. 덕분에 자신감도 생기고 개발도 더 즐거워졌다. 이번 경험을 발판 삼아 앞으로도 매월 사이드 프로젝트를 진행할 것이다.