전자책 출판사 '작가와' 공동집필 서비스
지난 이야기 요약
어쩌다보니 스타트업(?) 우리 회사가 IT 사업을 시작한 이야기 (스타트업_우리 회사가 스타트업에 된 이야기)
주니어 경영 컨설턴트의 웹 서비스 기획 (스타트업_시장조사, 웹 서비스 기획하기)
팀내에 IT 기술이 없었지만 노코드로 어떻게든 사업을 시작했다! (스타트업_노코드로 웹 서비스 만들기)
노코드 끝판왕 버블(Bubble.io)를 배우고 첫 프로덕트를 만들기까지 (스타트업_노코드 Bubble.io로 첫 프로덕트 런칭)
일을 받아서 하는 것보단 대표님께 앞으로 할 프로젝트를 제안하면서 지금까지 왔었다. Bubble.io 기초를 다잡았으니 이를 토대로 아래 프로젝트를 해보면 좋겠다고 제안했다.
CMS 반응형 디자인, UI/UX 보완, 데이터 관리 방법 개선 등
버블(Bubble.io, 이하 '버블')로 작가와 웹사이트 리뉴얼
버블로 공동집필 서비스 리뉴얼
CMS는 일단 고객이 보는 데에 큰 문제가 없으니 패스(반응형 디자인은 최근에 작업함. PC 전용이었다가 이젠 모바일로도 도서 판매 데이터를 확인할 수 있음)
작가와 웹사이트 리뉴얼을 했다면 가장 좋았겠지만... 데이터베이스 서버를 같이 개발해야 한다는 점에서 탈락(팀내에 능력자가 없어서 외주를 맡겨야 했고... 인건비 외에 추가지출이 발생하기 때문)
결국 버블로 공동집필 서비스를 리뉴얼 하는 방향으로 결정이 됐다.
작가와 공동집필 서비스란, 정해진 주제/질문에 답변만 작성하면 이걸 모아 책으로 출판해주는 서비스다. 글을 쓴만큼 그 기여도에 따라 정산비율이 달라지며, 책이 팔리게 되면 소소하게 인세가 들어오는 즐거움을 맛볼 수 있다.
그러나 문제는... 글쓰러 가는 단계가 너무 길고 복잡했다. 우선 작가와 웹사이트에 접속해야 했고, 메뉴를 클릭하고 서브메뉴를 찾아 '공동집필' 페이지에 도달해야했다. 여기서 원하는 주제를 찾아 클릭하면 상세페이지로 전환이 된다. 이 상세페이지에 와야만 답글을 작성할 수가 있다.
문제는 더 있었다. Softr로 만든 웹사이트는 속도가 빠른 편이 아니다. PC 최적화된 웹사이트였지만 Google Analytics 분석 결과 모바일 접속자가 40% 이상이었다. '책 만들기' 서비스는 거의 PC에서만 이루어지는 걸 고려하면 꽤나 높은 수치였다. 또 Softr에서 제공하는 Form 블록은 장문의 텍스트를 입력할 수는 있지만... 장문을 쓰기엔 UI가 매우 구리다(?).
여러모로 우리 공동집필 서비스는 고객이 가벼운 마음으로 들러서 글을 쓰고 가는 공간은 아니었던 것 같다.
따라서, 공동집필 서비스 리뉴얼 방향은 ' UX 개선 ' 이었다.
첫 페이지에서 바로 글을 쓸 수 있도록 만들자!
모바일 화면을 고려하여 만들되 PC에서도 불편함이 없도록!
빠르게 MVP(Minimum Viable Product) 런칭하고 고객 피드백 받기!
공동집필 서비스 리뉴얼 컨셉에 결정됐다. 하지만 컨셉만 가지고는 개발을 할 수가 없다. 구체적으로 어떤 기능이 필요하고, 그 기능을 구현하는 UI, 필요한 데이터베이스, 운영 방법 등 상세한 기획이 필요했다. 기존에 있던 서비스를 개선하는 만큼, 이전에 했던 방법을 그대로 따라서는 안 되겠다 싶었다. 그렇다고 더 좋은 방법을 당장 알지도 못했고 알려줄 사람도 없었다.
더 나은 개발 프로세스가 필요하다!
어려워진 작업, 그러나 기댈 곳은 없었다
버블 개발은 Softr, Airtable, Zapier 개발보다 복잡했다(그리고 아직 내 지식이 부족했다)
기획, 개발, 디자인, 유지보수를 도맡아 하다 보니... IT 서비스를 바라보는 눈높이가 팀원들과 차이나게 됐다. 실무에 직접적으로 도움을 받을 수가 없었다.
피드백을 요청해도 진정성 있는 답변을 얻기 어려웠다. 다들 각자 업무에 바빴기 때문에 '너 알아서 해' 분위기였다.
'메모앱'과 '기억력'으로 감당할 수 없는 작업 규모
같은 기능을 구현하더라도 Softr에선 5분만에 끝날 것을 버블에선 10분 이상 작업해야 한다. 시간이 오래 걸린다는 것은 곧 작업량이 많다는 뜻이다. 자유도가 높은만큼 세세하게 설정해야 할 것들이 많기 때문.
이전에 Softr, Airtable, Zapier를 활용했던 것처럼 기획하는 것이 곧 개발인 속도로 작업이 불가능했다.
기존에 활용하던 '메모앱'으로는 작업 전체를 조감하기가 버거웠다.
그래서 실제 개발팀이 작업하는 방식을 가져오기로 했다
먼저 기획자가 UI/UX (화면 설계, IA, Flowchart 등) 를 기획한다.
그리고 DB 서버 개발자 ERD를 기획한다.
마침내 기획한 것을 토대로 개발자가 개발을 진행한다.
-> 수정사항이 있거나 추가 개발이 필요한 경우 위 프로세스 반복.
먼저 다른 글쓰기기 앱, 메모 앱 등을 여러 개 다운로드 받아서 분석해보았다. 기존 서비스를 본떠서 IA, Flowchart 등을 그려보았다. 그리고 깨달았다. IA, Flowchart는 기획자-가발자 간의 '소통방식'이었다. 나처럼 기획자가 개발을 하는 경우엔 UI만 그려도 상세 기능 파악이 되니까 굳이 필요 없는 작업이었던 것.
처음 벤치마킹을 하고 붕 뜬 시간이 생겼다. 다른 업무에 투입되는 바람이 프로젝트가 잠시 중단됐다고 볼 수 있겠다. 이 기간 동안 회사에서 진행하는 기업 교육 업무를 지원하거나 직접 진행하곤 했다. (서울대학교 노코드 교육 진행)
그리고 다시 본격적인 기획을 시작한 것이 9월 말이었다. 다운로드 받았던 글쓰기 앱을 다시 사용해보고 좋았던 UI/UX를 참고해서 기획을 시작했다. 가장 인상깊었던 앱은 PenCake(안드로이드 기준)라는 앱이었다. 작업을 덜 한 느낌이 들 만큼 심플한 UI, 그리고 버튼 한 번으로 바로 글쓰기를 시작할 수 있다는 점이었다. 이 앱보다 단계를 더 줄여서 '앱에 들어오는 순간 바로 글을 쓰도록' 랜딩페이지를 기획했다.
랜딩페이지는 '추천 글감'이라는 탭으로 기획했다. 랜덤으로 주제, 질문이 정해지면 사람들이 바로 답변을 달 수 있도록 유도했다. 두 번째 탭은 '주제 찾기'라는 탭이었고, 미리 등록된 주제를 찾아서 글을 쓰거나 다른 사람들의 글을 볼 수 있는 공간이다. 세 번 째 탭은 '내 글 보기'로 말 그대로 내가 쓴 글을 모아볼 수 있는 공간이었다. 이외 자질구레한 기능들은 모두 메뉴버튼을 클릭하면 보이도록 설정해두었다. (Figma UI 기획 링크)
이때는 Figma 다루는 게 익숙하지 않아 유튜브에서 배우고 적용하며 작업했다. 디자이너 만큼 잘 다루지는 못하지만, CSS flex 규칙에는 익숙해졌다. 사실 이 방식은 버블 개발에도 똑같이 적용되기 때문에 쉽게 배울 수 있었다. (그냥 Figma가 기초 기능 익히기 너무 쉬운 도구인 것...)
UI 기획은 눈에 바로 보이기 때문에 '좋고, 나쁨'을 직관적으로 알 수 있다. 그러나 데이터베이스는 어떻게 만들었는지 눈에 잘 보이지 않는다. 아무것도 모르던 시절에 데이터베이스를 설계할 땐 '이렇게 하면 되겠지~'라고 생각했었다. 실제로 잘 작동해서 다행이었지만 서비스 확장이나 운영을 하다보니 데이터베이스가 더러워지는 현상이 나타났다. 어쩔 수 없는 것 같으면서도... 뭔가 '처음에 잘 만들면 더 좋겠거니...' 생각을 했다. 그래서 데이터베이스 공부도 할겸 ERDCloud로 데이터베이스를 기획했다. (ERD DB 기획 링크)
UI, 데이터 저장 및 처리, 운영 등을 고려하여 ERD(Entity Relation Diagram)을 기획했다.
ERD를 그리기 위해선 데이터베이스 기초 지식이 필요했다. 유튜브를 보면서 ERD 그릴 만큼의 지식만 골라서 습득했다.
필드가 많아질수록 필드명을 짓는 게 매우 중요한 일인 것을 깨달았다. 필드명은 ChatGPT 도움을 받아 Postgre SQL에서 대중적으로 활용하는 필드명을 활용했다.
스터디한 시간을 제외하면 ERD 기획 기간은 정말 빨랐다. 아무래도 Entity가 몇 개 없으니...
작가와 CMS라는 프로덕트를 하나 만들긴 했지만, 여전히 버블엔 모르는 기능 투성이었다. 다행히 기초는 익혀둔 상태였기 때문에 구글링, 유튜브 검색으로 기능을 구현할 수는 있는 수준이었다. 또한 UI/UX 기획, 데이터베이스 기획이 된 상태였기 때문에 필요 기능도 명확했다. 할 일이 딱 보이니 이젠 스터디와 개발을 반복만 하면 결과가 나올 것이었다. .... 그럴 줄 알았다.
막상 개발을 시작하니 예상치 못했던 문제들을 마주하게 됐다. 내가 알던 버블 지식이 매우 좁았기 때문에 어쩌면 당연한 일이었다. 예를 들면, 기존 데이터를 버블 데이터베이스로 옮기는 과정에서 겪는 무수한 문제들... 기획할 때 생각하지 못했던 '필수 기능' 그리고 추가 페이지... 뒤늦게 좋은 방법을 깨닫고 보완했던 수많은 기능들! 너무 구체적인 내용들이라 여기서 열거하기엔 좀 그렇다. 어쨌든 다음 사항들을 고려하며 개발하려고 노력했다.
서비스 속도를 고려하여 SPA(Single Page App)으로 만들었다.
화면과 기능별로 하나씩 구현하고 테스트를 하면서 차근차근 기능을 구현했다.
버블 작업자가 똑같은 타이핑 하는 일이 없도록 Option set을 많이 활용하려고 노력했다.
스터디나 개발에 몰입하다보면 '내가 지금 뭘 하고 있지?'라는 생각이 들며 어리둥절한 순간이 온다. 밭에 씨앗을 뿌리는 데에 열중하다보면 옆집 밭으로 넘어가서 씨를 뿌리게 되는 경우가 있(을 수도 있)다. 그래도 다행인 것은 중간중간 길을 잃더라도 UI/UX, DB 기획이 잘 되어있으니 궤도를 크게 벗어나지 않을 수 있었다는 점.
추석 전에 기획을 하고, 12일 간의 긴 추석 연휴를 마치고 개발을 진행했다. 추석 전-후로 초기 MVP 런칭하기까지 working-day만 계산하면 15일이었다. Figma 스터디, 데이터베이스 스터디, 버블 스터디를 하면서 작업한 것을 생각하면 정말 결과물이 빨리 나왔다. (아니면 말고) 매월 중순, 말. 인세 정산 작업에 반일 혹은 종일씩 썼던 걸 감안하면 실제 개발 working-day는 더 짧았을 듯.
MVP엔 정말 '글쓰기' 기능만 있었다. 회원가입, 로그인, 메일 인증 + 글쓰기가 끝이었다. 가장 핵심 기능만 런칭하고 나머지 필요한 기능은 차근차근 보완해나갔다. 우선 팀원이 앱을 관리할 수 있도록 관리자 페이지가 필요했다. (막상 개발하고 나니, 고객 서비스 페이지만큼 관리자 페이지가 많았다 ㄷㄷ...) 고객이 제공하는 피드백도 하나씩 반영했다. 대표님이 요구하시는 추가 기능들도 하나씩 개발해나갔다.
관리자 페이지에 딱 들어가면 대시보드 형태로 '일/월별 답변 수' 그래프를 볼 수 있다. 지난 몇 달을 관찰하면 공동집필 서비스 리뉴얼 전엔 경향을 찾기 어려웠다. 그때 그때 흥미로운 주제가 있었거나, 회사 이벤트에 영향을 많이 받았던 것 같다. 10월 중순 리뉴얼 후엔 월별로 답변 수가 지속 상승하는 추세를 확인할 수 있다. 회사에서 공동집필 참여를 유도하는 어떤 행사도 없었는데 과거에 비해 꾸준히 증가하는 추세를 보니 기분이 뿌듯하다. (결과물 - 공동집필 서비스 리뉴얼 링크)
(관리자 페이지, 통계 자료 등은 공개할 수 없으니 양해 부탁)
이상 비개발자가 기획부터 버블 개발까지 경험해본 기록이었습니다.
클래스101에서 Softr, Airtable, Zapier 기초 교육을 런칭했습니다. 할인 코드 받고 제 거 말고도 다른 분들의 좋은 강의도 들어보세요. (할인 코드 받기)
노코드 랜딩페이지/웹사이트 제작, 업무 자동화 등 문의는 hamster.the.merciless@gmail.com로 주세요
TMI. 2023-12-01 부로 퇴사했습니다. 자유의 몸이 된 김에 저를 위한 서비스를 하나 만들어볼까 합니다. 시간이 되면 진행상황을 브런치 글로 남기겠지만...
나는 왜 퇴사 후에 더 시간이 부족한 것일까...?