32번째 서비스를 출시하며 느낀점

인사말

안녕하세요. 작년에 사이드 프로젝트에서 출시율을 높이는 방법 글을 작성하고 벌써 1년이 지났었네요. 처음 서비스를 만들었을 때가 생각이 납니다. 지금까지 출시한 앱 서비스만 세어보니 31개 였습니다.

서비스를 만드는 것을 정말 좋아하다보니, 이런 저런 동아리 활동도 많이 하게 되었는데요. CMC, 넥스터즈, 디프만 그리고 현재는 YAPP 이라는 IT 동아리에서 활동을 하고 있습니다.

제가 느끼기에 저는 뛰어난 사업가도 아니고, 아주 훌륭한 개발자도 아닙니다. 제가 참여한 프로젝트의 서비스들은 다 실패했다고 생각하는데요. 그 중에는 제가 기획한 것도 있고 개발자로 참여한 것들도 있습니다. 그렇다고 큰 실패를 해봤고 그것에서 배운점이 있었나? 저는 실패도 제대로 못해본 것 같습니다. 성공한 서비스의 스토리를 읽다보면, 서비스를 만들다 전 재산을 탕진할 정도로 돈을 잃거나 몇 번의 창업을 해보고 실패했던 경험이나 이런 것들을 해보진 못했습니다. 남들이 충분히 경험해볼 수 있는 범위 내에서의 실패 정도에 그칩니다. '아 그냥 잘 안됐네' 하고 넘길 수 있는 수준이었죠.

저의 회고글의 장점은 개발자 여러분들이 충분히 경험하고 한번 쯤 고민해볼 수 있는 수준의 글이라고 말씀드릴 수 있습니다.

그리고 회고글을 쓰는 본 목적은 이 프로젝트를 만들면서의 생각을 기록하여 다음번 프로젝트에서 더 나은 결과를 만들어가기 위함입니다.

다 쓰고나서 보니깐 너무 진지하게 글을 쓴 것 같은데요. 원래는 막 엄청 진지캐는 아닙니다.. ㅎ

왜 자꾸 잘 안될 것을 알면서 계속 만드나요?

계속 만들다 보면 계속해서 발전하는 것을 느낍니다. 예를 들면 저는 처음 프로젝트라는 것을 했을때 SW마에스트로 라는 곳에서 시작을 했었습니다. 그때는 가게 사장님들한테 세일즈가 중요한 서비스를 기획했었는데 제품이 다 만들어졌어도 사장님들을 직접 연락하기 꺼려하는 저의 문제가 있었고, 머뭇머뭇 거리다가 실패로 이어졌습니다. 지금은 제품이 만들어지지도 않았는데 먼저 외부와 컨텍을 진행하려는 모습이 달라졌습니다.

조금 더 자세하게 설명드리면, 이번에는 제품이 만들어지기 전에 64명 정도의 작가님과 먼저 컨텍을 시도 했습니다. 앗차차, 서비스 설명을 못해드렸네요. 저희는 뉴스레터 + 퀴즈 서비스 입니다. 읽다보시면 서비스는 알아서 이해될 거예요. (하하. 원래는 친절하게 설명도 해드립니다.)

아무튼 그래서 총 9분의 작가님과 함께하고 있는데요. 이중에는 서비스가 만들어지기도 전에 합류해주신 분도 계십니다. 왜냐면 금방 마치 만들어질 것처럼 허풍을 떨었습니다. 정확하게 말하면 허풍은 아니었어요, MVP 기간은 정확하게 지켰습니다.

하나를 집중해볼 생각은 없었나요?

매번 새로운 서비스를 만들고 주변에 홍보를 하면서 들었던 말 중 하나는, '너는 하나를 제대로 만들 생각을 해라.' 였습니다. 이번엔 잘 될거야, 왠지 대박이 날 것만 같아! 라고 주변 친구들한테 말하면 이제는 대충 들어줍니다. 오 그래 .. 이번에는 정말? 어떤 친구는 너는 문제가 뭐냐면 1개를 제대로 만들 생각은 없고 대충 뚝딱 100개를 만들 생각을 한다. 그말이 맞았을 수도 아니었을 수도 있겠지만 꾸준히 디깅 해본 서비스는 없었습니다.

(2022년 4월에 출시한 매매일지) 그렇다고 해서 아예 없었던 것은 없습니다. 제가 운영하고 있는 10개의 iOS 앱 중 하나는 다운로드 수가 꽤 괜찮게 나와서 1년 반 정도 뒤에 업데이트를 한 적도 있었습니다. 근데 새 기능을 추가한 것은 아니고, 기존 UIKit으로 되어있는 코드들을 SwiftUI로 변환 하는 작업이었습니다. (+ iOS 개발을 공부하고 싶었다.)

(2023년 10월에 출시한 매삼뉴) 제가 이 서비스를 설명드리는 이유는 뒤에 나올 진짜 서비스를 위해서 인데요. 사실 빌드업 중입니다. 대학교 캡스톤 디자인에서 만든 서비스인데요, 이때 한창 생성형 AI 난리였어서(현재도 진행중) 날먹을 한번 해보자! 였습니다. 매일 뉴스를 10개씩 크롤링해서 GPT로 문제를 만들어서 답과 해설을 제공해주는 퀴즈 서비스 였습니다.

위의 사진은 그때 받았던 실제 유저 피드백이었는데, 되게 깊숙한 곳에 피드백 창구가 있었는데도 유저 대비 피드백 수가 많았습니다. 앱스토어 무료 뉴스 카테고리 에서도 33위까지 올라갔었고 제가 써보니깐 꽤 흥미로웠습니다. 저는 뉴스도 잘 안읽고 퀴즈도 잘 안푸는 사람인데 나름 좀 읽게 되더라고요. 개인적으로 아쉬움이 많이 남았던 서비스였습니다. 뭔가 디벨롭을 조금 더 시켜나가면 꽤 재미있는 서비스를 만들 수 있지 않을까 생각했었어요.

그래서 차근차근 기획을 다시 해나갔습니다. 우선 본질적인 고민을 하게 되었습니다. 뉴스를 읽으면서 매일 3개의 문제를 푸는 것이 꽤 좋은 경험이었구나 라는 생각이 들었습니다. 여기서도 아쉬운 점을 피드백 하자면, 실제 유저의 인터뷰 같은거를 했었으면 더 좋았을 것 같긴 합니다. 제 생각에는 뉴스를 그냥 읽었을 때보다 문제를 풀어보며 읽는 경험은 더 가치가 있는 경험이었다는 결론을 내렸습니다.

좋았던 경험은 살리고 나머지의 것들은 버리자

학습지 링크

좋았던 경험만 집중하고 나머지의 것들을 버리기로 결정했습니다. 매삼뉴에서 좋았던 경험은 '문제 풀이'였고 그것을 제외한 나머지 경험을 변경하기로 했습니다.

첫번째는 컨텐츠 입니다. 재미없는 뉴스 보다는 내가 읽고 싶어하는 아티클이면 어떨까 라는 생각을 하였습니다. 그러다보니 현재는 뉴스레터 작가님들의 글을 모으는 것에 집중하고 있습니다. 나의 취향에 맞는 아티클에 문제까지 있으면 기존 경험보다 더 나은 가치를 제공할 것이라고 생각하였습니다.

두번째는 습관 입니다. 100개의 아티클을 하루에 집중해서 다 읽는 서비스를 만들고 싶지 않았습니다. 매일 조금씩 읽는 습관 더 나아가 학습의 습관을 제공하는 서비스를 만들고 싶었습니다. 100개의 아티클을 읽는데 100일이 걸리더라도, 꾸준함을 만들어주는 기능을 넣고 싶었습니다. 그래서 첫 기능으로 '학습지' 라는 개념을 만들었습니다. 여러개의 아티클을 하나의 학습지로 묶어서 하루에 하나씩 아티클을 읽도록 하였습니다.

(최초의 기획 문서) 처음 서비스 이름은 21일 학습지 였습니다. 현재는 FEW 라는 이름으로 변경되었습니다. 위의 사진은 처음 기획한 내용을 담은 문서입니다. 현재는 조금 더 디벨롭되긴 하였지만 근본적으로 컨텐츠와 습관 두가지가 저희 서비스의 핵심이라고 생각합니다.

• 초기 수작업 및 생성형 AI를 사용한 학습 컨텐츠 확보
• 컨텐츠 제공자를 확보하여, 깊이 있고 검증된 컨텐츠를 확보
• 유저 기반 학습 컨텐츠 플랫폼으로 도약하여 다양한 주제들에 대한 컨텐츠들을 확보

제가 처음 기획 할 때 고민했던 부분은 어떻게 컨텐츠를 확보할 것인가 였습니다. 그래서 저는 위의 3가지 단계가 있다고 생각했고, 각 단계는 매우 어려운 여정이 될 것이라는 것을 알고 있었습니다. 하지만, 완전히 불가능하다고는 생각하지 않았습니다. 열심히 하고자 하는 생각이 있다면 문제가 있더라도 해결해 나가면 된다고 생각하였습니다.

협업은 같이 고민하는 것

저희 서비스에 합류하신 작가님께 받은 답변 중 인상깊었던 말은 협업은 같이 일하는 것보다는 같이 고민하는 게 아닐까 였습니다. 협업을 진행하면서 굉장히 놓치고 있는 포인트였던 것 같습니다. 과연 나는 그렇게 하고 있었을까 다시 돌아보게 되었습니다.

어쩌면, 저희가 앞으로 계속 해야할 일도 협업 일텐데 이런 생각을 하고 있는 팀이랑 일하고 싶다는 생각이 들었습니다. 그리고 제가 리드를 하게 되는 상황이라면, 이런 가치관을 갖고 싶다는 생각이 들었습니다.

디프만 13기 iOS 파트 회고에서 느낀점과 비슷했던 것 같습니다. 같이 고민하는 시간이 주어진다는 것이 협업에서 어떤 의미로 다가오는지 정말 잘 알게 되었던 시간이었습니다.

그래서 다음에는 어떤 것을 만들거야?

저희는 다음으로 서비스의 완성도를 높이는 작업을 하고 있습니다. 그리고 그 다음으로는 어떤 것을 만들어야하고 어떤 기능을 추가해야할지 고민하고 있습니다.

저희 서비스가 학습에 기여했으면 합니다. 하지만 방법은 엄청 다양할 것 같습니다. 글만 있는 것에서 벗어나서 영상을 보며 짤막하게 학습 하고 문제를 풀도록 하거나, 문제를 잘 풀면 보상을 주거나, 글을 안읽는 사람들한테 패널티를 주거나, 뉴스레터가 아니라 종이 문제집을 온라인으로 제공한다거나 등등 여러가지 방법들이 존재할 것 같습니다.

내가 15년간 프로그래밍을 하면서 얻은 가장 중요한 것 이 글은 제가 다니는 회사의 CTO 님께서 작성해주신 글 입니다. 인터페이스 적 사고가 인상 깊었습니다. 또한 저의 사수도 비슷한 이야기를 해주었습니다. 개발을 하다보면 흔히 하는 실수가 있는데, 구현을 먼저 고민하고 인터페이스를 설계하는 일 입니다. 그런것과 매우 유사합니다.

우리는 우리가 생각한 유저의 문제를 해결한 제품을 곧 출시할 예정입니다. 이제는 다시 새롭게 문제를 정의 해야하는 단계이고, 어떤 문제가 있을지는 늘 그렇듯이 유저로 돌아가야 합니다. 인터페이스를 먼저 설계하고 구현에 대한 고민을 시작해야 합니다.

우리의 이탈률을 개선하는 것도 하나의 목표가 될 수는 있을 것 같습니다. 음 그런데 이것 역시도 구현에 조금 초점이 맞춰진 방법인 것 같습니다. 유저가 왜 우리 서비스를 사용하지 않는지 우리는 잘 모릅니다. 왜냐면 아직 아무도 안쓰니까요!

어떻게 하면 유저의 피드백을 관찰하고 분석할 수 있을지 트래킹과 피드백 창구에 신경을 써야겠습니다. 그리고 실제 유저를 모아봐야 합니다.

끝내면서

저희 서비스의 MVP를 구현한 학습지 하나를 공유드리려고 합니다 :) velog는 개발자분들이 많기 때문에 개발 관련 학습지를 하나 챙겨왔어요!

https://www.fewletter.com/workbook/7

이메일 구독을 해주시면 다음날 부터 아침 8시에 아티클과 문제를 이메일로 보내드립니다.
감사합니다 🙂

별첨
(임시) 메인 페이지: http://fewletter.notion.site
인스타그램: https://www.instagram.com/few.letter

긴글 읽어주셔서 감사합니다.