DayTrip 플로우차트 & 팔로우
[코드스테이츠 PMB 9기] 플로우차트와 팔로우(follow) 기능
들어가며
오늘은 지난 주에 작성했던 글을 회고하는 시간을 갖고자 합니다.
회고를 통해 서비스를 이용하는 유저 행동을 다시 한 번 정리해보고, 서비스에서 어떻게 설계하였는지 살펴보겠습니다. 회고 대상은 아래 글입니다. DayTrip이란 서비스의 유저플로우와 작동방식을 프론트엔드 중심으로 설명한 글입니다. 데이터에 관하여는 유저플로우에서 어떤 데이터를 수집하고 보관하는지 정도의 추측을 해보았습니다.
[DayTrip의 플로우와 작동방식]을 다시 읽으며 느낀 점을 정리하고자 합니다. 이 글은 제대로 끝맺음된 느낌이 아니었습니다. 데이터 수집에 관해 추측만 하고 마무리되었기 때문입니다. 그래서 회고 후 이전 글을 이어가는 방식으로 글을 전개해보려고 합니다.
먼저, 아래 세 가지는 이전 글을 읽으며 다시 든 생각 혹은 궁금했던 점 입니다.
1. 유저 이용 흐름
2. 어떤 데이터를 모으고 있을까
3. 서비스가 작동하는 구조 : 앱(클라이언트)와 서버의 상호작용을 역으로 추측해보기
1. 유저 이용 흐름
[DayTrip의 플로우와 작동방식]의 '유저들의 이용 흐름'우선, 이전 글의 부분을 캡처한 위 그림에서 네 가지 유저 행동 정의가 제한적이고, 순서가 뒤죽박죽이었습니다. 실제 서비스를 이용하기 위해선 로그인이 필수입니다. 따라서 회원가입 및 로그인을 시작으로 하단 메뉴(탭 바 Tab Bar)의 좌측에서 오른쪽 순서에 따라 게시물보기 > 목록 및 지도 보기 > 업로드 > 북마크 > 마이페이지로 이어지는 게 서비스 흐름을 파악하는데 용이하다고 생각합니다. 이는 유저들이 사용하는 것을 옆에서 지켜본다고 가정할 때 하단 메뉴를 중심으로 각 메뉴에 속해있는 세부 기능들을 사용하기 때문입니다. 마찬가지로, 네 가지로 한정 짓기 보다 하단 메뉴의 다섯 가지 메뉴를 중심으로 분석을 진행하는 것이 보다 '유저 중심의 이용 흐름'을 관찰할 수 있는 방법이라고 생각했습니다.
2. 어떤 데이터를 모으고 있을까
어떤 데이터가 수집되고 있는지 추측할 때 더 구체적으로 들여다보지 못했던 게 아쉬웠습니다. 대표적으로 회원가입 및 로그인은 구글, 애플의 간편 회원가입 및 로그인 만이 가능하기 때문에, 오픈 API를 사용할 경우의 데이터를 고려해야 합니다.
3. 서비스가 작동하는 구조 : 앱(클라이언트)와 서버의 상호작용을 역으로 추측해보기
앱(클라이언트)과 서버 간 상호작용을 보면 서비스 이용 흐름을 더욱 잘 파악할 수 있을 듯 합니다. 앱에서 사용자가 특정 행동을 했을 때 어떤 변화가 있는지 보는 것이죠. 예를 들어, 팔로우나 업로드와 같은 기능을 활성화 할 때 앱(클라이언트)과 서버는 어떤 상호작용을 하는지 알 수 있습니다.
DayTrip의 플로우차트
DayTrip 홈 화면하단 메뉴 탭 바를 기준으로 플로우차트를 구성해보겠습니다.
먼저 관련된 용어를 정의하는 게 좋을 것 같습니다.
- - - - - - - - - - - - - - - - - - - - - -
• 콘텐츠 : 한 유저가 업로드 한 하나의 게시물 (사진과 글로 구성)
• 콘텐츠 피드 : 여러 유저들이 제공하는 콘텐츠를 보여주는 피드. 팔로우 하는 계정들을 스크롤 다운(scroll-down)으로 보고, 각 계정의 콘텐츠들을 슬라이드(slide)로 확인
- - - - - - - - - - - - - - - - - - - - - -
• 큐레이션 : 한 유저가 업로드 한 여러 콘텐츠로 구성된 묶음
• 큐레이션 피드 : 여러 유저들이 제공하는 큐레이션을 보여주는 피드
- - - - - - - - - - - - - - - - - - - - - -
• 장소페이지 : 식당이름, 건물이름, 카페이름, 박물관 등의 정보가 담긴 페이지
• 데이트리퍼 : DayTrip에서 크리에이터를 부르는 호칭
- - - - - - - - - - - - - - - - - - - - - -
홈 Home
• 콘텐츠 피드 > TODAY > 콘텐츠(하나의 계정 슬라이드로 전체 콘텐츠 조회)
• 콘텐츠 피드 > FOR YOU > 추천 데이트리퍼 / 관심지역 / 콘텐츠 피드
• 최근 큐레이션 > 큐레이션 피드 > 큐레이션
• 상단 배너 > 큐레이션
검색 Search
• 지도 보기 > 현 지도에서 검색
• 목록 보기 > 장소이름 > 장소 상세 페이지
• 필터 > 정렬(인기순,거리순) / 공간 유형(키워드)
• 현 지도 중심 > 지역 검색
올리기 Upload
• 데이로그 > 공간 선택(검색,공간등록) > 스토리 작성(공개범위, 방문일, 사진, 유료 광고 포함 표기)
• 큐레이션 > 새로운 큐레이션(데이로그 추가)
북마크 Bookmark
• 공간 > 콘텐츠
• 큐레이션 > 큐레이션
마이페이지 My Page
• 공간 > 콘텐츠
• 데이로그 > 콘텐츠
• 큐레이션 > 큐레이션 / 소개된 공간
• 데이트리퍼 추가 > 데이트리퍼 검색 및 추가
• 알림
• 공유 팝업
• 기타 > 인사이트, 프로필 편집, 환경설정, 로그아웃
누군가를 팔로우 하면
소셜 기능의 강력한 파급력은 '연결'에 있습니다. 유저 입장에서 '연결'은 수많은 콘텐츠 중 원하는 콘텐츠만을 골라 볼 수 있는 편리함과 더불어 심리적 연결이라는 새로운 경험을 제공합니다. SNS 서비스에서는 '팔로우'가 연결 기능을 담당하고 있죠. 이는 네트워크 효과를 위한 기능이기도 합니다.
DayTrip에서도 팔로우(follow) 기능이 있습니다. 특정 유저의 콘텐츠가 마음에 들면 미래에도 그 유저의 콘텐츠를 보기 위해 팔로우를 합니다. 팔로우를 통해 유저들은 서로 연결되죠. 팔로우 버튼을 클릭하면 어떤 일이 일어나는 걸까요? 앱(클라이언트)과 서버 간 상호작용을 살펴보겠습니다.
DayTrip 서비스의 팔로우 작동원리를 확인하는 건 어려웠습니다. 대신 SNS 서비스들의 팔로우 기능들에 대해 알아보았는데 Facebook(현 Meta)와 Twitter에 관한 내용이 많았습니다. 이를 기반으로 데이터베이스에서 팔로우 기능이 어떻게 구현되는지 정리했습니다.
팔로우 기능_데이터베이스유저 테이블(User Table)에는 유저 정보가 담겨 있습니다. 유저들의 id, user_name, created_date가 저장되어 있습니다. 팔로우 버튼을 누르면 유저들의 데이터는 직접적으로 연결되지 않습니다.
데이터베이스에는 팔로우 테이블(Follow Table)이 생성되어 팔로워(follower), 팔로이(followee) 셀에 유저들의 아이디(id)를 저장합니다. 이때 팔로워(follower)는 팔로우를 신청하는 사람이고, 팔로이(followee)는 팔로우 신청을 받는 사람입니다. 이렇게 구분하는 이유는 팔로우 기능에는 방향성이 존재하기 때문입니다. 유저1과 유저2가 연결되더라도 누가 누구를 팔로우 신청하고 신청을 수락했는지 관계가 명백히 구분됩니다.
팔로우 테이블의 생성은 유저 간 연결을 효율적으로 만들면서, 동시에 보안에도 유용합니다. 유저의 모든 데이터가 서로 연결되어 있으면, 데이터가 무거워질 뿐 아니라, 부정적인 방법으로 개인정보에 접근할 수도 있기 때문입니다.
마치며
지난 글을 회고하며 유저 행동을 다시 정리보해고, 팔로우라는 특정 기능을 중심으로 데이터베이스 설계를 알아보았습니다. DayTrip에서 팔로우 기능이 유저 플로우에 '콘텐츠 피드'와 '콘텐츠'에 직접적인 영향을 미친다는 점에서 서비스 설계자가 어떤 의도로 데이터베이스를 설계하는지 어렴풋이 알 수 있는 시간이었습니다.
