툰덕 서비스 오픈 부터 폐업까지
툰덕이라는 웹툰 검색 서비스 오픈 부터 폐업까지 느낀점을 기록(쓰고보니 일기 수준)합니다. 기록 편의를 위해 존댓말과 반말이 섞여있고 출퇴근 길에 서서 쓰다보니 두서 없고 오타 난무한점 양해부탁드립니다.
개발배경
티비를 보지 않는 나의 취미는 영화 감상, 웹툰 감상이다.
이미 완결난 작품된 작품이나 연재중인 작품도 여러번 재 정주행 할정도로 웹툰을 좋아하는 편이다.
웹툰을 보기 시작한것은 고등학교 때 부터였던것 같다 당시 학교에서 기능경기 대회 출전을 위한 대회준비반에 있엇는데, 쉴때 주로 웹툰을 봤다.
핵심 아이디어는 네이버와 다음 웹툰중 완결 된 작품 중에서도 재밌는게 정말 많다, 그런데 이 완결작을 본사람이 많지 않다는게 아쉬웠다.
만약 연재중, 완결 작품들의 정보를 한번에 볼수있고, 무료 웹툰만 보는 사람이라면 무료만 검색 하거나, 내가 웹툰을 위해 이정도 돈은 쓸수있다 하는 사람을 위해 가격으로 검색(마치 부동산 매물 검색하듯이)을 제공하면 어떨까? 라는 아이디어로 정리가되었다.
진행
돈을 벌려는 목적도 아니고, 우선 이런 서비스 있으면 쓸까? 가 궁금했기 때문에 가벼운 마음으로 개발을 진행했다.
핵심은 다양한 검색 제공이였다, 이를위해 총 에피소드 수, 무료 에피소드 수, 유료 에피소드 수, 전체 유료 회차 가격, 한편당 유료 단가 등등이 핵심 정보가 되도록 크롤링 처리했다.(메타 데이터만 추출하고 만화 이미지는 쓰지않았다)
또한 플랫폼 별로 분리되어있는 작가의 작품 정보를 통합 제공하기 위해 작가 정보 통합 작업을 했다.
기술
Back-End
가장 익숙한 SpringBoot + JPA 조합으로 개발했다.
(사실 개발 기간 중에서 도메인 설계, 인프라 구성, API 개발, 검색 성능 개선은 정말 순식간에 마무리 했는데,, 문제는 내가 평소에 관심이 없던 Front-End 쪽 작업에서 엄청난 병목이 발생했다.)
Front-End
가장 큰 문제로는 나의 경우 js 는 어느정도 경험을 통해 사용(동작하도록 작업)할수 있으나 html, css 를 거~의 하지 못한다.
물론 찾아보면서 한땀 한땀 하면 당연히 할수 있기도하고, bootstrap 같은거로 만들어도 되고 하니까 우선 진행해보려 노력했다.
처음에는 freemaker+jquery (이렇게 쓴다 할때 주변에서 정말 소름끼치는 올드한 선택이라고 디스당했다)로 슥슥 진행을 했는데 영 결과 물의 생산성도 안나오고, 개발 생산성도 안나오더라.
결국은 최근 트렌드 라던가 기술 스택에 대해 학습을 해야겠다는 결정을 하고 리서치를 진행했다.
리서치 중 Vue.js 가 눈에 들어왔고 훑어보니 금방 적응 할수 있을것 같았다.
추가 리서치를 해보니 Vuetifyjs 를 알게 되었고 cli 로 기본 프로젝트 구성을 만들수 있었고, 필요한 부분을 수정해서 작업했다. 디자인 컴포넌트 또한 상당히 높은 수준으로 제공해줘서 굉장히 효과적으로 작업을 진행할수 있었다.
사실 조금 놀랐던 부분은 $ npm run dev 로 실행해서 개발 결과를 바로바로 확인 할수 있는 환경이였다. mock data 를 기반해서 빠르게 개발 한 후 proxy 설정을 해서 API 와 연동 체크까지 편하게 할수있었기에 개발 생산성이 매우 높아졌다.
인프라
기본적으로 AWS 에서 환경 구성하였으며 매우 단순하고 서비스간에 느슨한 결합을 맺은 형태로 되어있다.
코드 또한 특정 AWS 서비스에 의존되어 있지 않도록 개발하였고, 필요 시 요구 사항만 만족하면 다른 플랫폼으로 옮겨갈수있다.
실제로 운영중에 배치 프로세스 부분은 인프라 및 코드가 여러번 바뀌었다, 초기에는 별도의 EC2 Instance 에서 동작하였는데, cron 동작 이기 때문에 instance 가 상주하지 않아도 될것으로 판단되어 별 수정없이 lambda 로 이전하였다.
테스트
backend 코드의 경우 테스트 주도적으로 개발을 진행하였다. 서비스 기능 자체가 적어서 ‘뭐 이런걸 굳이~ 테스트 먼저 만드나~’ 할수있지만, 이번에도 테스트는 옳았다.
중간에 내가 바보 같이 실수하는것도 아주 똑똑하게 알려주고 가이드 해주었다.
또한 단순 API를 떠나 크롤링, 데이터 정제 부분도 테스트 먼저 만들면서 내가 생각했던 설계 대로 개발을 빠르고 안정적으로 진행하였다.
(여담으로 크롤링에 대한 통합 테스트 묶음을 주기적으로 돌려서 데이터 수집에 장애가 있는지 체크할수 있엇다, 테스트 만만세!)
성능 테스트 및 개선
오픈 후에 트래픽이 생각 보다 덜 나왔다, 생각도 작게 했는데 더더더 작았다. 그래도 가끔 사용하는 이용자가 있기도 했고, 성능상으로 지금 구성으로 얼마나 버티는지 궁금해서 nGrinder 로 간단히 부하 테스트 해봤다.
사실 데이터 자체가 매우 적고(컨텐츠-1,400개, 에피소드-100,000개 .. 그 외 부수 정보) 핵심 기능 자체가 ReadOnly 여서 큰 의미는 없었다.
그래도 데이터야 긁어 모으면 늘어날수 있으니 강제로 데이터를 증폭 시킨 다음 다시 진행을 하였다.
데이터를 강제 증폭 시키고 어느 정도 로드가 걸리니 응답 속도가 느려지는게 보였고 DB쪽의 부하가 나타났다.
물론 그 정도 데이터가 있으려면 전 세계 웹툰을 다~ 크롤링 해도 모자랄것 같아서 의미 없긴 하지만 그래도 상상력을 동원해 이 위급한 상황을 한번 개선 해보고자, 코드 레벨의 설계 개선 을 통해서 성능 이슈를 처리하였다. (이때도 기존에 만들어논 테스트들이 나를 열심히 가르치며 버그가 없도록 도와줬다.)
홍보
자아성취를 위해 만든 서비스 지만 다른 사람들이 쓰는지 궁금하기도 해서 커뮤니티 2군데 정도에 홍보성 글을 적어봤다. 이게 또 내가 뭘 본격적으로 하는게 아니기 때문에 막 뿌리고 다니기에는 ‘굳이 그래야하나’ 싶어서 추가적으로 홍보하지 않았다.
기존에 서비스 런칭할때에는 마케팅 팀이 있거나 이미 기존 서비스를 리뉴얼 한 형태였기에 홍보에 대해서 다시한번 생각해본 경험이였다.
개발시 홍보 개념에 대해 생각하지 않았다 보니 중요한 포인트를 놓친것 같다. 홍보 채널이 어느정도 확보되야 초기 유저를 모을수있고 반응을 정확히 확인해야할수있을것 같다.
추후 진행할 프로젝트는 홍보 또는 유입에 대한 부분을 고려하면서 가능성에 대해 고민하려한다
얻은것
회사 관련일이 아닌 개인의 자아성취를 위한 첫 서비스 런칭이였고 시도로 끝나지않고 어쨋든 결과(망ㅎ)를 냈다는것을 얻어낸것 같다.
또한 프론트엔드 지식도 기존보다 향상시킬수있엇다.
음 앞으로 아이디어 테스트를 할때 진행에 대하여 좋은 가이드가 되준 프로젝트였다, 다음 프로젝트는 더 기민한 템포로 진행 할수 있을것같다.
마케팅 관련해서도 흥미가 조금 생기게 되었다, 아무리 좋은 서비스(툰덕이 말고)라도 마케팅의 힘 없이는 쉽지 않을것 같다라는 생각이 들었다.
반대로 마케팅을 경계해야겠단 생각도 들었다, 구린 서비스도 마케팅으로 살려낼수도 있으니까.
폐업
아쉽게도 최근 트래픽이 전멸인 형태로 확인되었고 버전2의 아이디어로 회생시켜보려고 했으나. 생각 했던 서비스의 형태가 웹툰가이드, 웹툰인사이트 에 이미 지원을 하고있었다.
툰덕이는 지금 접게되었지만 어쨋건 국내 웹툰사업이 잘되길 바란다. 개인적으로 웹툰을 보면서 여러가지 생각을 많이한 작품도 있엇고 단순한 만화 이상의 가치를 가지고 있는 대작들이 많다.
다음서비스
툰덕이는 SPA 였는데 다음엔 SSR 처리해서 컨텐츠 검색 노출도 잘 되게 해보고, API랑 데이터 가공은 golang으로 한번 해봐야겠다.
