Qiita 30만 개 글을 집계한 기술서 랭킹이, 개설 3주 만에 10만 엔이 된 이야기

개인 개발 이야기는 억 단위 투자를 받은 창업자이거나, 수익 제로인 채 멈춘 사이트라는 양극단에 치우치기 쉽다. 2018년 5월 Qiita에 게시된 “개설 후 3주 만에 수익 10만 엔을 얻은 개인 개발 사이트에서 한 것을 전부 공개한다”는 그 중간에 있는 숫자를 내놓은 기사다. 저자(@jabba)는 스스로 “대략 1개월이면 iPhoneX를 살 수 있을 정도의 사이트 규모”라고 표현한다. 화려하지는 않지만, 손이 닿는 범위의 도달점으로서 윤곽이 뚜렷하다.

무엇을 만들었는가

대상은 techbookrank.com(테크·북·랭크)이라는 기술서 랭킹 사이트다. Qiita의 API에서 기술서를 언급하는 글을 추출해, 그 집계 결과로 서적을 나열한다. “많은 기술 블로그 글에서 소개되는 책일수록 좋은 책이다”라는 발상이다.

“좋은 책”의 판정은 3가지 조건으로, 많은 Qiita 글에서 소개되는 책, 인기 있는 Qiita 글에서 소개되는 책, 새로운 글에서 소개되는 책이다. 저자는 “자의적으로 특정 책의 순위를 올리거나 하는 일은 절대 하지 않는다”고 명기하고 있다.

흥미로운 것은 태그 처리 방식이다. Qiita 글에 붙은 태그를 그대로 서적의 태그로 계승시키고 있다. 태그→글→서적이라는 간접적인 연결이므로, 서적의 내용과 태그는 엄밀하게는 일치하지 않는다. 예로 든 것이 『인공지능은 인간을 뛰어넘는가』인데, 이 책에는 Python이나 TensorFlow 태그가 붙는다. 본문에는 그러한 기술에 대한 언급이 없지만, “이 책을 소개하는 엔지니어는 대체로 Python이나 TensorFlow 관련 글을 쓰고 있습니다”라는 의미가 된다. 저자는 이 느슨한 연결을, Amazon의 판매 순위에는 없는 “책과의 만남”을 만드는 장치로서 의도적으로 남기고 있다.

수익 10만 엔에 대해, 기사가 쓰지 않은 것

먼저 밝혀둘 점이 있다. 이 기사에는 수익원의 내역이 쓰여 있지 않다. “사이트의 수익화”라는 절은 있지만, 거기서 이야기되는 것은 금액을 평가 기준으로 중시하는 이유이며, 괄호 안에 “여기서 말하는 것은 어디까지나 평가 기준이며, 웹사이트의 수익 모델이 유료 과금인지 무료 광고 수익 모델인지 하는 것이 아닙니다”라고, 수단의 이야기가 아님을 일부러 명시하고 있다. 따라서 “3주 만에 10만 엔”의 획득 수단은 본 글에서도 특정하지 않는다. 판명된 것은 금액과 기간뿐이다.

그 대신 쓰여 있는 것은, 왜 수익에 집착하는가라는 논리 쪽이다. “돈이라는 지표가 가장 엄격하게 그 사이트의 좋고 나쁨을 재는 척도가 된다”. 좋아요 수로는 “오, 좋은 거 만들었네”로 끝나버리지만, “＊엔을 내고서라도 갖고 싶은가”를 들이밀면 평가는 한층 엄격해진다는 사고방식이다.

결정타는, 전작에서 “자신의 생각”을 다 쏟아낸 것이었다

궤도가 바뀐 지점은 명확하다. 테크·북·랭크 전에 만든 사이트는 “꽤나 자신의 생각과 열정으로 밀어붙여 만든 것인데, 결과적으로는 실패했다”. 거기서 저자는 방침을 뒤집어, “일단 자신의 생각은 내려놓고, 성공 사례를 트레이스함으로써 기획 입안을 다시 배운다”는 것으로 정했다. 본인이 “이 방침이 매우 좋았다고 생각한다”고 쓰는, 그 한 지점이 전작과 이번 작을 가르고 있다.

새로운 기획의 절차는 3줄로 제시되어 있다. 대상 사용자를 특정한다. 그 사용자가 원하는 것, 마음에 들어 하는 다른 제품을 철저히 조사해서 복사한다. 마지막의 마지막에 아주 조금만 자신의 색을 더한다. 타깃은 좁힐수록 좋으며, “이과 사람 대상”보다 “IT 엔지니어 대상”, 나아가 “IT 엔지니어이면서 기술서를 좋아하는 사람 대상”이라면 더 좋다는 식으로 좁혀져 있다.

성장한 이유를 분해한다

첫째, 콘텐츠를 먼저 준비했다는 것이다. 저자는 “사용자는 시스템 따위에 관심이 없다”, “사이트에 접속했을 때 눈앞에 있는 것은 콘텐츠뿐이다”라고 쓴다. 투고형 서비스가 실패하는 전형은, 뛰어난 시스템을 만들고 투고를 기다리다가 내부인들의 글만으로 끝나는 형태다. 테크·북·랭크는 Qiita의 약 30만 개 글을 API로 가져옴으로써, 개설 첫날부터 4,000권분의 서적과 게시물 수가 “실제로는 없어도, 이미 그곳에 있는 것처럼” 늘어선 상태를 만들었다. 첫 방문자가 빈 서비스를 보는 일이 없다.

둘째, 독자가 이미 있는 장소에서 홍보했다는 것이다. 유입의 기점은 사이트 그 자체가 아니라, 먼저 공개한 소개 글 “기술서 랭킹을 Qiita 글 집계로 만들었더니, 약 4000권의 기술서가 좋은 느낌으로 늘어섰다”였다. 집계원과 홍보처가 같은 Qiita이므로, 글을 읽는 층과 랭킹의 이용자층이 완전히 겹친다. 저자도 “이 글에 꽤 반향이 있어서, 거기서 사이트로 접속이 흘러들어와서”라고 쓰고 있다. 데이터 공급원과 집객 채널을 일치시킨 설계가 효과를 내고 있다.

셋째, 무료 인프라로 비용을 제로에 가깝게 만든 것이다. 이유가 “서비스를 최대한 오래 존속시켜 기회를 늘리기 위해서”라는 점에 주목하고 싶다. 월 몇천 엔이라도 몇 개월 지속되면 철수의 구실이 된다는 운영 심리를 미리 앞서서 막고 있다. 구성은 Rails·GraphQL·React+Redux·MongoDB·GCP·Netlify·Heroku·CloudFlare이며, Heroku는 무료 Dyno, Add-on도 무료 범위, GCP는 영구 무료 범위, MongoDB는 500MB까지 무료, Redis는 25MB. 그 25MB의 Redis에 가능한 한 데이터를 두고, 모든 응답을 캐시에서 반환해 Heroku 로그상 5ms 이내를 유지한다. DB가 갱신될 때만 Redis로 다시 써넣는 방식으로, 평상시에는 데이터베이스를 거의 움직이지 않는다. 첫 표시에 필요한 정보는 Netlify에 정적으로 두고, 이후는 GraphQL로 비동기 취득해 Redux에 실어둔다. 무료 범위의 제약을, 설계로 속도로 변환하고 있다.

저자 스스로 꼽는 실패 요인

기사에는 “개인 개발에서 3대 해서는 안 되는 것”이 나열되어 있다. “수익화는 나중에 생각한다”며 일단 만든다. “콘텐츠(사용자 투고 수 확보)는 나중에 생각한다”며 일단 만든다. “먹힐지 어떨지는 내놓아 보지 않으면 모른다”며 일단 만든다. 각각을 권장하는 사람이 있음을 인정하면서도, “적어도 제게는 이 세 가지가 최대의 실패 요인이었습니다”라고 쓰고 있다. 전작이 실패한 이유에 대한 자기 진단으로 봐도 좋다.

한계도 명시적이다. 저자는 기술력과 기획력에 상관관계가 없다고 말하며, 자신의 기술력을 “머리로 생각한 기획을 어느 정도 비율로 코드를 짜서 구현할 수 있는가”로 9할 이상으로 자평하면서도, 그것이 좋은 기획으로 직결되지 않는다고 구분한다. 도달점에 대해서도 “고작 10만 엔”이라고 표현하며, 다음은 100배를 목표로 한다고 쓰고 있다.

재현할 수 있는 부분과, 할 수 없는 부분

방법론은 지금도 쓸 수 있다. 타깃을 한 단계 더 좁힌다, 선행 사례를 분해해서 모방한다, 공개 첫날에 콘텐츠가 채워진 상태를 만든다, 집객 채널과 데이터 공급원을 겹친다——여기에 추가 자본은 필요 없다.

재현하기 어려운 것은 조건 쪽이다. 우선, 무료로 쓸 수 있는 약 30만 건의 글이라는 재고가 외부에 존재했다는 것. 개방된 API를 갖고 있으면서 이용자가 진하게 모여 있는 플랫폼은 많지 않다. 다음으로, 그 플랫폼 위에서 소개 글이 반향을 얻었다는 것. 저자는 Qiita에 지속적으로 게시하고 있으며, 수익 기사 자체도 6,000개가 넘는 좋아요를 모으고 있다. 무명 계정이 같은 도선을 그을 수 있다고는 할 수 없다. 그리고 인프라 환경 그 자체가 바뀌었다. 당시 전제였던 Heroku의 무료 Dyno는 2022년에 폐지되어, 같은 구성을 그대로 짤 수는 없다.

마지막으로, 이것은 2018년의 기록이다. 저자는 그 후, 개인 구독 미디어를 분석하는 뉴스레터를 자체 플랫폼으로 주 1회 배포하는 등 활동을 옮기고 있다. 숫자는 당시의 스냅샷으로 읽는 것이 타당할 것이다.

함께 읽으면 좋은 글

• 히토데 씨 — 검색과 콘텐츠로 쌓아 올린 개인 미디어의 수익 추이
• Carrd — 운영 비용을 극한까지 줄인 솔로 운영 프로덕트