[E.P 01] - Rilog. 기획 회고

안녕하세요, 러로입니다.
새로운 개발자 블로그 플랫폼 Rilog.? 라는 글을 올린 지 어느덧 3주가 지났습니다. 짧다면 짧은 시간이지만, 그동안 제게는 정말 많은 일이 있었습니다. 그 이야기를 꺼내기에 앞서, 시간을 조금 더 거슬러 올라가 Rilog. 라는 블로그 플랫폼을 처음 기획하게 된 순간부터 이야기해 보려 합니다.

기획

[서론]

저는 우아한테크코스 8기 Backend 분야에서 러로라는 닉네임으로 활동하고 있습니다. 저희는 지난달 7월부터 Level 3가 시작되었습니다. Level 3는 본격적으로 팀 프로젝트를 시작하는 첫 번째 레벨입니다. Level 3의 첫 한 달은 분야 상관없이 모든 인원이 각자 자신만의 불편함을 해결하는 서비스를 기획해보는 것 이었습니다. 한 달 동안 자신이 만들고자 하는 서비스에 대한 가설을 검증하고, 실제로 사용자를 모을 수 있는 서비스인지 수치로 증명해야 했습니다.

가장 먼저 떠올랐던 것은 블로그 플랫폼이었습니다. 오랫동안 직접 불편함을 느껴왔던 분야이기 때문이죠. 기존 서비스의 사용 경험에서 아쉬운 점이 많았고, 언젠가는 이 문제를 직접 해결해 보고 싶다는 생각을 지속적으로 해왔었습니다. 그리고, 저는 실제로 사용자가 유입되고 트래픽이 발생하는 서비스를 만들어보고 싶다는 목표가 강했습니다. 그래서 프로젝트 주제 역시 제가 꾸준히 관심을 가져왔고, 사용자 입장에서 문제를 깊이 고민해볼 수 있는 도메인으로 선정하고자 했습니다.

[가설 검증 - 1 주차]

1 주차에는 개발 블로그를 열심히 운영하는 주변 크루들을 찾아가 인터뷰를 요청했습니다.

현재 어떤 블로그 플랫폼을 사용하고 있는지, 왜 그 플랫폼을 선택했는지부터 시작해 실제로 블로그를 이전해 본 경험이 있는지, 사용하면서 만족했던 점과 불편했던 점은 무엇인지 등을 물었습니다. 인터뷰를 통해 기존 블로그 서비스들의 장단점을 정리할 수 있었고, 어떤 기능이 사용자를 끌어들이는지, 반대로 어떤 불편함이 사용자를 떠나게 만드는지 조금씩 윤곽이 잡히는 계기가 되었습니다.

저 역시 평소 여러 블로그 플랫폼을 사용해봤기 때문에 어느 정도 사용자들의 불편함을 알고 있다고 생각했습니다. 하지만 실제로 다양한 사람들을 인터뷰해보니, 더 다양한 관점에서 사용자들이 실제로 중요하게 느끼는 문제들을 수집할 수 있었습니다. 실제 사용자들의 경험을 바탕으로 Rilog.가 어떤 문제를 해결해야 하는지 구체화했던 주차였습니다.

[가설 검증 - 2 주차]

2 주차에는 조금 더 범위를 좁힌 초기 타겟을 선정하는 데 집중했습니다. 그렇게 어렵진 않았던 게 주변에서 가장 쉽게 만날 수 있으면서, 저 역시 포함되는 집단은 단연 개발자였습니다.

개발자들은 꽤 자주 글을 씁니다. 개발자에게 매우 중요한 역량이기도 하죠. 새롭게 배운 내용을 자신의 것으로 만들기 위해 정리하기도 하고, 개발하면서 겪었던 문제와 해결 과정을 기록하기도 합니다. 누군가에게 자신의 경험을 공유하기도 하고, 그렇게 쌓인 기록은 자연스럽게 자신의 기술적 관심사와 성장 과정을 보여주는 포트폴리오가 되기도 합니다.

초기 타겟을 개발자로 정한 뒤, 이들에게 가장 매력적으로 다가갈 수 있는 기능이 무엇일지 고민했습니다. 제가 주목한 것은 Markdown 기반의 글쓰기 경험이었습니다. 사용자 경험을 함축한 입력 자동 완성 + Markdown 단축키가 완벽하게 제공되는 플랫폼은 현재 존재하지 않고, 그래서 개발자들이 블로그 글을 작성할 때 곧바로 글쓰기 화면에서 시작하기보다, 다른 노트 에디터에서 초안을 작성한 뒤 옮겨오는 경우가 생긴다고 생각했습니다.

가장 완벽한 Markdown editor를 만들어야겠다.

이 질문에서 Rilog.의 첫 번째 기능 가설이 시작되었습니다. 우선 글 작성 화면만 담은 간단한 프로토타입을 만들었습니다. 그리고 실제 사용 경험을 확인하기 위해 Markdown에 빠삭한 몇몇 사람들(일명 Markdown 장인)에게 지속적인 피드백을 받으며, 불편한 지점을 하나씩 찾아갔습니다. “이 단축키도 있으면 좋겠다”, “여기서는 자동으로 이렇게 입력돼야 한다”, "커서가 이때는 여기로 옮겨져야 한다" 같은 피드백이 나올 때마다 하나씩 정리했습니다. 그렇게 사용자들이 원하는 온갖 단축키와 입력 자동 완성 기능을 모아, 일단 하드코딩하며 빠르게 구현해나갔습니다.

고생한만큼 사용자 경험 측면에서 제가 봐도 글 작성 경험이 좋긴 했습니다. 하지만, 결론적으로 이 가설은 실패였다고 말할 수 있을 것 같습니다. 이 가설은 몇 가지 문제가 있었습니다.

• 정말 Markdown editor 가 블로그 플랫폼에서 가장 중요한 부분일까?
• 이미 기존 플랫폼 Markdown editor 의 불편함을 알고 그것을 보완해서 만들었기에 당연히 더 좋을 수 밖에.. -> 엎드려 절받기?

[가설 검증 - 3 주차]

3 주차에는 가설 검증 마지막 주차로, 이 서비스가 실제로 사용자를 모을 수 있는 서비스인지 증명해야 했습니다. 앞으로 저와 이 프로젝트를 함께할 사람들을 모으려면 이는 제가 책임지고 증명해내야하는 과제와 같았습니다. 하지만, 이전 주차에서 느꼈듯이 기능 하나에 대한 반응이 좋다고 해서, 사람들이 이 서비스를 실제로 사용하고 싶어 한다는 뜻은 아니었습니다. 그렇다면 이 둘 사이의 간극을 어떻게 검증해야 할까?

이때 정말 고민이 많았습니다. 특히 "값싼 검증이란 무엇일까?"

• 그맘때쯤 별다른 해결책을 찾지 못했을 때 제가 작성했었던 글입니다. 많은 고민을 한 흔적이 느껴지네요..

  ...
  구현하고자 했던 기능 중 하나인 글 작성 경험(Markdown 기능 고도화)을 최소한의 MVP로 설정하고, 해당 기능만 구현해 정량적인 가설 검증을 진행했다. 실험을 통해 글 작성 과정의 불편을 줄일 가능성은 확인할 수 있었지만, 사용자가 블로그 플랫폼을 선택할 때 글 작성 기능 하나만을 기준으로 판단하지는 않는다는 한계가 있었다. 특히, 블로그 플랫폼은 많은 기능들이 복합적으로 기여해 사용자의 선택을 받게 된다. 따라서 최소한의 기능만 구현한 이번 실험만으로는 사용자가 실제로 내 서비스를 이용할 것인지까지에 대한 검증은 충족하지 못했다고 생각한다.

  그렇다고 기존 서비스와의 차별점으로 생각한 기능들을 모두 구현한 뒤 프로토타입을 제공하기에는 시간과 비용이 너무 많이 든다. 가설을 값싸고 빠르게 검증해야 한다는 점은 이해하지만, 여러 기능이 복합적으로 작용하는 서비스의 경우 이를 어떤 방식으로 검증해야 할지 모르겠다. 사실 가장 쉬운 방법으로는 “이러한 기능이 추가되거나 개선된다면 편리할 것 같은가?, 기존 서비스에 어떤 불편함을 느꼈는가?”와 같은 설문을 진행하는 방법이 떠올랐다. 그러나 이러한 설문은 응답자가 얼마나 진지하게 참여하는지에 따라 결과가 크게 달라질 수 있고, 실제 사용 경험이 아닌 가정에 기반한 답변을 어디까지 신뢰할 수 있을지도 의문이다. 그리고, 무엇보다 이런 식으로 사용자를 모을 수 있다는 가장 중요한 가설을 얼렁뚱땅 넘어가고 같이 프로젝트를 진행할 팀원을 구인하는 책임감없는 짓은 하고 싶지 않다.

  과연 값싼 검증의 본질은 무엇일까..
  ...

• 사실 위 글을 적을 때 쯤만 해도 "사용자를 모을 수 있는 서비스" 인지에 대한 검증을 하지 못할 것 같아 주제를 피벗할 생각도 조금은 갖고 있었습니다.

그런 상태로 주말을 맞았습니다. 토요일과 일요일, 이틀 동안 지금의 가설을 끝까지 검증해볼지, 아니면 과감하게 피벗하고 다른 크루의 서비스에 합류할지 결정해야 했습니다. 그래서 주말 내내 자료를 찾아보았습니다. 유튜브에 올라와 있는 PO 세션, IT 서비스 가설 검증 관련 영상은 거의 다 찾아본 것 같습니다. 그러다 이번 한 달의 분기점이 된 영상 하나를 만났습니다.

바로 「토스는 이렇게 시작했습니다」 라는 제목의 PO 세션이었습니다. 정말 큰 동기부여를 받았습니다. (서비스를 기획하고 있는 사람이 아니더라도 한 번쯤 봐두면 훗날 인생을 살아가는 데 있어서도 도움이 될 것 같은 그런 신뢰도를 이 영상으로부터 얻게 됐습니다.) 불확실한 상황에서 무엇을 먼저 확인하고 어떻게 다음 행동을 결정해야 하는지에 대한 관점을 얻을 수 있었습니다.

영상을 보고 든 생각은 "아, 바로 이거다." 였습니다. 그동안 계속 고민했던 ‘값싼 검증의 본질’에 가장 가까운 방법을 찾았다는 생각이 들었습니다.

랜딩 페이지를 통한 Fake Door Test를 진행해보자.

제가 제안하고 싶은 핵심 기능들은 제 나름대로 이미 다 정리가 되어있었습니다. 다만, 이것을 지금 당장 구현하여 사용자 피드백을 통해 검증할 수 없다는 점. 이 가장 큰 병목을 가장 값싸게 해결해주는 검증 방식이었습니다. 여기서 저의 타겟층이 실제로 관심을 보인다면, 적어도 제가 제안한 기능들이 정말 흥미로운 게 사실이고, 사용자를 유치해 볼 만한 가치가 있는 주제라는 확신을 얻을 수 있겠다는 기대가 있었습니다.

목표는 사전 신청 10명이었습니다. 베타 테스트를 진행하기에 여러 변수를 고려했을 때도 충분하면서, 실제로 의미 있는 피드백을 얻을 수 있는 최소한의 규모라고 생각했습니다.

[가설 검증 - 결과]

결과는 대성공이었습니다. 우아한테크코스 내부에서도 그리고, 외부에서도 이 랜딩 페이지를 기점으로 사람들이 제 서비스에 관심을 보이기 시작했습니다.

트렌딩 1위에 올랐습니다. 그리고, 사전 신청은 96명을 기록했습니다.

사전 신청해주신 분들 정말정말 감사합니다! 😊

Rilog. 를 시작하고 현재까지 상황

팀원이 생겼습니다.

팀원 모집을 위한 나의 호소 글..

결국 저는 Rilog. 라는 서비스의 팀장으로서 팀을 꾸리는 데 성공하였습니다. 내부적으로 크루들에게 가장 큰 관심을 받았던 서비스라고 봐도 무방할 것 같습니다. 아무것도 아닌 제가 크루들을 면접까지 보며 함께할 팀원을 뽑았습니다. 굉장히 신기한 경험이었습니다.

저희 Rilog. 팀은

• 프론트엔드 2명(아지, 파라디)
• 백엔드 2명(러로, 송송)

총 4명으로 결성되었습니다. (아마도(?) 엄청난 슈퍼팀 결성)

팀 결성 후, 팀원들과 스프린트 목표를 정하고 스크럼과 코어 타임 같은 팀 내 규칙을 하나씩 만들어갔습니다. 동시에 1차, 2차 MVP의 기능 요구사항을 정의하고, 정리된 것들은 곧바로 구현에 들어가며 빠르게 서비스를 만들어가고 있습니다.

이전에는 혼자 고민하던 아이디어였는데, 이제는 함께 고민하고 만들어가는 팀원들이 있어 든든합니다. 그와 동시에 책임감도 부단히 느껴지는 요즘입니다. 그래서 바쁘다는 생각보다도, 지금 이 과정 자체가 꽤 즐겁다는 생각을 더 많이 합니다. 살아있음이 느껴지네요..

1차 MVP 스포

디자인 초안 스포

1차 MVP에서 가장 보여드리고 싶은 핵심 기능은 팀 블로그(a.k.a. Co-log)입니다.

Co-log를 1차 MVP의 핵심 기능으로 선정한 이유

제가 Co-log의 1차 타겟으로 가장 적절하다고 생각한 집단은 주변에서 흔히 이루어지는 개발 스터디 입니다. 개인적인 경험과 관찰을 통해 느낀 점은 스터디 내에서 굉장히 양질의 자료들이 많이 만들어집니다.

저는 ‘기술부채스터디’ 라는 스터디를 진행한 적이 있습니다. 이 스터디는 자신이 개발하면서 해결했던 트러블 슈팅을 정리하거나, 평소 공부, 실험하고 싶었지만 시간이 없어 미뤄두었던 기술 부채를 하나 골라 학습해 약 30분 정도의 발표를 하는 식으로 진행됩니다. 따라서, 자연스럽게 발표를 위한 자료도 만들어야 했죠. 그러다 보니 다른 사람에게 설명할 수 있을 정도로 내용을 정리하게 되었고 스터디원들의 퀄리티 높은 글과 자료들이 계속해서 쌓여갔습니다. (무려 4일 간격으로 발표를 진행했습니다.) 이 자료들을 저희는 Notion에 템플릿을 만들어 서로의 스터디 자료를 공유할 수 있는 환경을 만들었습니다. 자료를 정리하고 한곳에 모아보기에는 정말 편리했지만, 결국 내부에서만 소비되는 private한 공간이라는 점이 다소 아쉬웠습니다. 그만큼, 자료들이 정말 좋았고 퀄리티적으로 자신있었기 때문이죠. 그래서 아쉬운 사람들은 스터디에서 만든 자료를 각자의 개인 블로그에 다시 올리기도 했습니다.

하지만 이 과정은 생각보다 잘 이어지지 않았습니다. 이미 발표를 위해 한 번 정리한 내용을 다시 블로그 형식에 맞게 다듬고, 제목과 태그를 붙여 별도로 발행하는 과정이 꽤 번거로웠기 때문입니다. 처음 몇 번은 의욕적으로 올리더라도, 시간이 지나면서 점점 귀찮아졌고 결국 몇몇 사람만 간헐적으로 글을 올리게 되었습니다. 무엇보다 스터디를 위해 자료를 만드는 것과, 개인 블로그에 다시 발행하는 것이 서로 분리된 작업처럼 느껴진다는 점이 문제였습니다.

• 스터디원들의 자료를 외부에 공개할 방법이 전혀 없었던 것은 아닙니다. 저희가 선택했던 방법 중 하나는 GitHub Organization이었습니다. 각자의 자료를 Repository에 정리하고 한곳에서 모아볼 수 있다는 점은 좋았습니다. 하지만 GitHub은 애초에 글을 더 많은 사람에게 노출하고 읽히게 만드는 플랫폼은 아니었습니다. 찾아오면 볼 수는 있지만, 우리가 만든 좋은 자료가 자연스럽게 다른 사람들에게 발견되기는 어려웠습니다.

• Youtube에 발표 영상을 올리는 방법도 고민했습니다. 하지만 촬영부터 편집, 업로드까지 생각하면 단순히 공부한 내용을 공유하려던 일이 지나치게 커지는 느낌이었습니다. 발표 영상을 공개한다는 것 자체에 부담을 느끼는 사람도 있었습니다.

그래서 저희가 정의한 팀 블로그의 첫 번째 문제는 다음과 같았습니다.

“스터디에서 만들어지는 양질의 자료들을 팀 단위로 모아 Public하게 공개할 만한 플랫폼이 마땅히 없다.”

이 문제를 해결하기 위해 Co-log라는 팀 블로그 기능을 만들기로 했습니다. 각 스터디원이 자신의 글을 작성하면 그것들이 하나의 팀 공간에 모이고, 스터디 내부에서만 소비되는 것이 아니라 Rilog.의 피드를 통해 더 많은 사람들에게 공유될 수 있는 형태입니다. 결국 개인이 글을 쓰는 방식은 그대로 유지하면서도, 각자의 기록이 모여 하나의 스터디 기록이 되고, 그 기록이 자연스럽게 외부로 공유되는 공간을 만드는 것이 목표입니다.

• Rilog. 는 Markdown editor 뿐만 아니라, 발표 자료로서 최적화된 Canvas editor까지 제공함으로써, 별도의 수정없이 발표에 사용했던 자료를 그대로 블로그에 발행할 수 있습니다.
• 또한, Co-log 라는 팀만의 공간에 내 글이 올라가기 때문에 글을 올려야 한다는 어느 정도의 긍정적인 강제성과 많은 사람에게 노출된다는 동기부여도 생기게 됩니다.

그리고 이 기능을 1차 MVP에 포함한 또 하나의 이유는 검증할 사용자를 바로 주변에서 찾을 수 있었기 때문입니다. 현재 주변에는 팀 프로젝트나 스터디를 진행하고 있는 크루들이 많습니다. 이미 팀 단위로 기록을 만들고 있고, 이를 함께 모아 공개하고 싶어 하는 수요도 확인할 수 있었습니다. 따라서 1차 MVP에서는 이들을 초기 사용자로 확보해, 실제로 팀 블로그를 만들고 글을 함께 올리는지, 그리고 팀 단위 기록을 한곳에 모아 공개하는 경험에 정말 가치를 느끼는지를 검증해보려고 합니다.

1차 MVP는 5명 정도의 외부 베타 테스터를 뽑았으며, 17일 공개 완료 후, 현재 베타 테스트 중입니다. (사전 신청해주신 분들은 2차 3차때도 테스트 참여 요청 메일을 보낼 예정이니, 앞으로도 Rilog.에 많은 관심주시면 부탁드립니다.)

이상으로 긴 글 읽어주셔서 감사합니다. 앞으로 이 [Rilog. on Top] 시리즈에서 저희 Rilog. 의 성장 과정을 담아보려고 합니다. 다음 글은 1차 MVP 소개와 실제 테스터들의 피드백을 담아 돌아오겠습니다. 앞으로도 많은 관심과 피드백 부탁드립니다. 🙇🏻‍♂️