첫 번째, TL;DR

TL;DR

코드로 하루를 빛내며, 미래를 채워가는 여정에 함께하세요.

내가 놓치고 있던 개발 경험을 데이터화 해보자!

처음 이 프로젝트를 구상한 단계에서 내가 겪은 문제는 파편화된 개발 경험을 관리하기 어려웠던 것이다. 예를 들어서 jira, wakatime, github commit, 알고리즘 문제 등등 내가 했던 경험들이 모두 파편화되어서 이 문제를 어떻게 해결하면 좋을까? 라는 생각이 들었다.

1. 타켓 유저 선정

개발 경험을 가장 외부에 들어냈으면 하는 유저층은 개발 직군으로 취업을 희망하는 관련 학과 학생, 취준생 등등으로 유추했다. 관련해 에브리타임, 카카오톡 IT 직군 취업 준비생, 국비 수강생 등을 대상으로 설문조사를 진행했다.

많은 인원은 아니지만, 총 32명의 설문 결과를 기반으로 서비스를 기획해봤다. 하지만 여기서 첫 번째 실수를 한 것 같다.

1.2 설문조사 결과

일단 설문을 진행하기 전 어떤 플랫폼을 통해 서비스를 제공하는 것이 좋을지 생각했다. 현재 내 서비스를 매일 접속해야할 이유를 만들기 어려워, 한 번 등록하면 자신이 가장 잘 이용하는 서비스에서 확인만 하면 되는 형태로 생각했다. 그 중 개발자 공통적으로 가장 잘 알려진 깃허브를 선택했다.

1.3 가설1. 취업 준비생 또는 평균 개발자는 깃허브 활용도가 높다.

설문조사 결과 의외로 활용도는 극면했다. 사용하지 않는 경우는 없지만, 활용하는 사람은 거의 매일 사용하고, 반대의 경우는 거의 사용하지 않는 사람들이 많았다. 회고에서 다루겠지만 이부분에서 아쉬운 점은 학생/취업준비생/국비수강생 각 그룹을 구분했다면 좀 더 의미있는 설문이 됐지 않았을까 생각든다.

1.4 가설2. 설문조사 대상 그룹의 깃허브 활용 목적은 구직 목적이다.

이 그래프를 봤을 때 활용 빈도가 높은 유저가 채용에 연관이 높다고 생각됐지만, 개별 설문 조사를 확인한 결과 의외로 활용 빈도가 높은 사용자는 채용에 관련이 없다고 답변했다. 반대로 깃허브 활용 빈도가 낮은 사용자는 채용에 도움이 된다고 답변했다.

이 설문을 어떻게 해석해야할지 고민했는데, 가설2에 또 다른 가설은 깃허브 활동에 적극적이지 못한 유저는 깃허브 활동이 중요하다는 것은 알지만, 어떤 활동을 해야하는지 모르는 상황이라고 추측할 수 있다.

이 부분에서 내가 해결하고자 한 사소한 개발 경험을 데이터화 하자는 비전과 연결될 수 있다.

이어서 잔디밭. 즉, 깃허브 활동이 채용에 어떤 이점을 가지는지에 대해서 압도적인 비율로 꾸준함을 선택했다. 이 문항은 어쩌면 당연한 결과인데, 아직 현업 개발 경험이 없는 상황에서 큰 프로젝트에 기여하거나, 수준 높은 오픈소스 프로젝트를 리드하는 경험에 대해서 현실적인 허들이 존재하기 때문일 것이라 생각된다.

1.5 가설3. 1일 1커밋의 허들은 번거로움이다.

마지막 3 문항은 앞서 기획한 서비스 tldr의 하루동안 쌓은 개발 경험을 정리해 깃허브로 관련 내용 저장하는 것에 대한 유저의 의견을 듣기 위함이다. 먼저 가설을 세우기 전 1일 1커밋을 실천하지 못한 이유에 대해서 추측했다.

• 매일 1일 1커밋을 신경쓰기 번거로움
• 커밋할 내용이 없음

진행한 설문에서 가장 다양한 의견이 나온 항목이다. 큰 틀에서 내용을 정리하자면 다음과 같다.

• 필요성이 없음
• 어떤 활동을 했는지가 중요함
• 커밋할 내용이 없음
• 시간이 없거나, 번거로워서

이 중 tldr은 아래 두 항목에 대한 해결책으로 기획됐다. 앞서 설문에서 나타났듯이 학생 또는 취업 준비생 입장에서 깃허브에서 들어나야 하는 것은 꾸준한 개발관련 활동이다. 이 프로젝트에서 내가 정의한 개발관련 활동은 작성한 코드를 github에 올리는 것을 넘어, 기술 게시글 작성, 알고리즘 문제 해결, 그리고 코드 작성, jira 티켓 처리 등등 직간접적으로 활동하는 모든 활동이 들어나기를 바랐다.

2. 디자인

인프라, 백엔드, 프론트 모든 구성을 혼자 해야하기 때문에 경험이 없는 프론트 영역은 최대한 단순하게 구성했다. 서비스 내 제공되는 기능으로 일기장 형태를 구상했다. 연결된 외부 서비스(github, wakatime, boj...)에서 수집한 내용을 기록하고 그날 작성한 일기와 함께 노출하도록 구성했다.

3. MVP

하지만 모든 서비스를 구현하기 전에 빠르게 유저의 반응을 보기 위한 최소 스펙으로 선정한 기능은 활동 내역을 일 별 깃허브에 기록해주는 기능이다. 이 기능을 먼저 선정한 또 다른 이유는 작성된 일기에 대해서 서비스에 인입될 수 있는 링크가 추가되면 자연스럽게 마켓팅적인 요소로 활용이 가능할 것이라는 이유도 있다.

4. 회고

4.1 시장성

4.1.1 좁은 사용자 선정

이번 프로젝트에서 첫 번째 문제는 너

~

무 특정된 사용자를 대상으로 선정했는 것이다. 대상으로 선정한 사용자는 '학생 또는 취업 준비생' 더 나아가 개발 또는 알고리즘, 블로그 활동에 적극적인 사용자이다.명 이상인 플러그인이다.

예전에 교수님에게 이런 말을 들은 적이 있다. "어떤 제품을 만들 때 시작을 특정 집단에 맞춰서 만들면 안된다."였다. 지금까지 이 말에 대해서 크게 공감하지 못했다. 내가 어떤 제품을 고를 때 내가 가진 문제를 가장 잘 해결해주는 제품인 맞춤형 제품을 고르지 않을까? 라는 생각이었기 때문이다. 그러면 내 제품을 쓸 것이고 입소문이 나오면 성공하는게 아니야? 같은 생각을 한 것 같다.

4.2 더 좋은 해결책이었을까?

4.2.1 기존 제품보다 떨어진 활용성

이 프로젝트를 만들며 중간 결과로 사용자들에게 전달했을 때, 자주 언급되던 제품이 있었다. 바로 백준허브인데, 알고리즘에 한정되어 있지만, 사용자들이 느낀 문제를 정확히 파악해 단순한 기능이지만 다운로드 횟수가 무려 20,000+명 이상인 플러그인이다.

프로젝트를 시작하기 전에도 이 확장자에 대해서 알고 있었지만, 나는 더 많은 정보를 더 간단하게 보여주는 것이 차별점으로 여겼다.

4.3 맞춤형 문제 해결사? 🤔

내가 회사를 나온 이유는 제품을 고민할 줄 아는 개발자가 되기 위한 경험치를 쌓기 위함이였다. 사용자들이 어떤 제품을 만들어야 좋아하는지를 모르면 내가 만들어야 할 코드가 어떻게 진화할지도 모르고 유명한 개발자, 큰 회사가 했던 구조를 따라가며 _예쁜 코드 잘만드는 개발자_가 되는 것이 아닐까? 하는 걱정이였다.

내가 걱정했던 문제를 고스란히 경험한 대목이다. 나는 내가 재밌을 것 같은 것을 찾아 그것을 문제라고 여기고 풀려고 했다. 그리고 그 문제는 나의 맞춤형 문제였다.

4.4 기준없는 기획성

처음 MVP를 선정하고 개발 과정에서 기존 제품과 대비되는 차별화를 고민하다 2. 디자인에서 처럼 일기장 형태로 데이터를 제공하는 영역을 생각했다. 하지만 이 부분은 MVP 출시 전, 부족한 프론트엔드 지식과 디자인 과정에서 일정에 많은 영향을 주게 된 것 같다.

처음 MVP 선정 기준이 빠른 출시와 부족한 리소스를 보완하기 위해 자체 서비스에서 노출하는 것이 아니라, 외부 서비스에서 노출하는 점을 고려했지만, 명확한 강점을 가지지 못한 상태에서 진행해 많은 리소스를 낭비하게 된 것 같다.