콘텐츠기획자의 IT입문서

모지또의 플로우차트를 그려 DB를 짜보자! | 코드스테이츠 PMB 14기 본문

PM

모지또의 플로우차트를 그려 DB를 짜보자! | 코드스테이츠 PMB 14기

lazy_cat 2022. 9. 28. 17:30

'다이어리 쓰는 것은 꾸준히 못 할 것 같고, 간단하게 내 기분을 기록해보고 싶은 데 괜찮은 다이어리 앱 없나?'라는 마음으로 앱스토어를 켰다. 다이어리 앱을 검색하니 생각보다 다양한 서비스들이 있었는데, 그중 나의 눈을 사로잡은 '모지또' 앱! 간단하게 기분을 입력하면 칵테일로 하루를 표현해준다는 점이 재미있어 보였다. 매년 다이어리 작심삼일의 주인공인 나도 꾸준히 나의 하루를 기록할 수 있을 것 같았달까?

모지또, 칵테일로 표현하는 오늘의 기분

검색해보니 사이드 프로젝트로 개발된 서비스였다. 아래 링크에서 모지또의 기능에 대해서 보다 자세하게 알 수 있다. 서비스 기획에 관심이 있다면 해당 프로젝트 제작 과정부터 모지또 NFT 만들기란 끌까지 쭉 정주행하길 추천한다!

(사이드 프로젝트로 이런 매력적인 서비스를 오픈한 것을 넘어 유료화까지 시키다니 그저 감탄👏)

다이어리 앱 모지또 제작기

Team Blender | 이번에 이모지 다이어리 모지또를 출시했다. 멋진 팀원들과 함께 하며 배운 점이 참 많고 결과도 만족스럽다. 이 뿌듯한 감정 그대로 프로젝트에 대한 간략한 후기를 남기려고 한다.

brunch.co.kr


어떤 사람이 모지또를 사용할까?

하루를 기록하고 싶지만 본격적으로 일기를 쓰는 것은 귀찮아 일기를 쓰지 않는 사람이 타겟일 것이라 생각했다. (바로 나처럼...ㅎ) 위의 제작과정을 보니 내 생각이 맞았다. 기획 목적이 이와 같다보니 다른 다이어리 앱들에 비해 하루를 기록하는 과정이 굉장히 간소하다. 오늘 하루 느낀 감정을 선택하기만 하면 끝이다! 물론 추가적으로 기록을 하고 싶다면 '스토리 작성하기'를 통해 일기를 작성할 수도 있다.

출처 : 이준우의 기획 노트 - 다이어리 앱 모지또 제작기中

모지또 Flow Chart

서비스의 각 화면을 확인하며 해당 서비스를 사용 중인 나의 행동을 고려하여 플로우 차트를 그려보았다. 수정, 삭제 기능까지 추가하면 더 복잡한 플로우 차트가 될 것 같아 우선은 일기를 작성하는 행동의 흐름 한정 도식화하였다.

모지또 플로우 차트


👉 화면 흐름이 궁금하다면 아래 더보기 클릭!

더보기

모지또 사용 화면 흐름 UI

앱 실행 ‣ 감정 선택 (감정을 담을 때마다 카피가 달라짐) ‣ 선택한 감정 확인 쉐킷
폰을 흔든다 ‣ 결과 화면 ‣ 자세한 설명은 유료회원만 확인 가능 스토리 기록 (SKIP 가능) 이달의 리포트 확인 (SKIP 가능)


모지또의 DBMS와 DB를 예측해본다면...

클라이언트와 서버가 상호작용하며 데이터가 전달되는 과정은 아래 이미지 한 장으로 이해할 수 있다. 깊게 들어가기에 우리는 개발자가 아니므로 클라이언트에서 입력한 데이터가 웹/앱 서버를 지나가서 DB에 저장되고, 정보를 불러올 땐 DB에 저장된 데이터 값을 웹/앱 서버를 거쳐서 클라이언트의 눈, 즉 화면에 보인다 정도만 이해해도 충분할 것 같다 :)

DBMS (데이터 베이스 관리 시스템)

DBMS는 DB를 운영하고 관리하는 소프트웨어다. 계층형, 망형, 관계형으로 나뉜다는 데 대부분의 DBMS는 관계형으로 RDBMS 형태로 사용된다고 한다. (참고)
RDMBS의 경우 데이터 관리를 효율적으로 할 수 있다는 장점이 있지만 관계가 복잡해지면 여러가지 문제가 발생할 수 있단 단점 또한 지니고 있다. 이를 보완하기 위해 관계형 DB와 SQL을 사용하지 않고 데이터를 관리하는 NoSQL이 생겼다.

SQL NoSQL
장점
- 사용하고 구성하기 용이
- 범용적으로 사용됨 높은 트래픽을 감당하기에 용이
- 구조화된 데이터를 다루기에 용이

단점
- 구조와 디자인을 이해하는데 시간이 걸림 확장성이 떨어짐
장점
- 디자인 절차가 필요 없음
- 빠른 개발 주기
- 일반적으로 SQL보다 빠름
- 클라우드 서비스에 적합

단점
- 데이터간 관계가 중요한 경우 적합하지 않음
- 기술적으로 성숙도가 낮다 응답시간이 느린편

 

💡 모지또는 데이터가 복잡하지 않고, 사이드 프로젝트로 개발되었던만큼 빠르게 개발되어야 했으므로 NoSQL DMBS인 MongoDB를 사용하여 데이터 베이스를 구축했을 것이라 예상된다.


DB (데이터 베이스, 저장소)

DBMS를 예측해봤으니 이제 DB를 짜보자! DB에 담겨야 할 정보의 테이블을 크게 2가지라고 보았다.

  • 유저 정보 (ID, PW, 닉네임)
  • 일기 내용 (날짜, 선택된 감정 이모지 각각의 갯수, 결과값, 스토리 제목, 스토리 내용)

조금 더 구체적으로 데이터의 속성을 생각을 해보자면 크게 필수 값과 선택 값이 있을 것이다.
* 필수 값은 초록색으로 강조하였다. 강조하지 않은 것은 선택 값.

  • 유저 정보 Data
    • ID (Primary Key)
    • PW - 암호화 필요
    • 닉네임
  • 일기 내용 Data
    • 입력 날짜
    • 선택된 감정 - 감정 16개를 각각의 Data로 취급하여 각각의 갯수를 Data로 저장
    • 칵테일명(결과값)
    • 스토리 제목(일기 제목)
    • 스토리 내용(일기 본문)

추가적으로 일기 작성하는 화면에서 노출되는 카피라이트가 계속 교체되는 데, 이 부분은 따로 데이터가 DB에 쌓여있다기 보단 프론드엔드단에서 내용이 랜덤으로 바뀌도록 설정되어 있을 듯하여 제외하였다!


오늘 과제를 마치며

다양한 프로덕트 중 데이터 규모가 작은 서비스를 이번 과제의 프로덕트로 정했기에 큰 어려움은 없었다. 하지만 모지또가 정말 심플한 다이어리 앱임에도 제작 과정을 봤을 때 기능을 추가하려다 보니 겉으로는 간단해 보이는 것도 DB를 갈아엎어야 할 수도 있다는 것을 알게되었다. 그래서 애초에 DB를 계획(?)할때 꼼꼼하게 작성해야겠단 생각이 들었다!
+) 오랜만에 SQL을 접했다. 분명 배웠는데 테스트해보니 기억나는게 거의 없었다. 가장 기본적인 것만 기억나서 나의 기억력이 걱정되기 시작됐다^_ㅠ

Comments