안녕하세요! 취향에 기반한 솔직한 장소 추천 서비스 “라이킷” 입니다!
사용자의 취향을 수집한 후, 이를 반영한 음식점, 카페, 놀거리를 제안해 주며,
“라이킷만의” 장소 검증 시스템과 세분화된 필터를 통해 서비스 사용자들의 장소 정보 탐색의 불편함을 줄여주는 서비스입니다.
R&R
분야 | 이름 | 포지션 |
---|---|---|
기획 | 박시은 | PM, 서비스 기획, BM담당 |
기획 | 문서현 | 서비스 기획, 리서치 담당 |
기획 | 조수연 | 서비스 기획, 와이어프레임 담당 |
디자인 | 나태진 | 프로토타입, 서비스 디자인 담당 |
개발 | 신민서 | 프론트엔드 개발 담당 |
개발 | 정채현 | 프론트엔드 개발 담당 |
개발 | 김수민 | 백엔드 개발 담당 |
개발 | 장진우 | 백엔드 개발 담당 |
2-30대를 대상으로 한 유저 리서치 결과, 만남을 위한 장소를 선정할 때 어려움을 겪었던 사용자가 81% 로 많은 비율을 차지하고 있다는 점을 파악하였습니다. 장소에 대한 객관성 없는 리뷰에 대해 피로를 느끼는 사람들이 많았고, 새로운 장소에 대한 정보의 부족이 가장 큰 이유였습니다.
이에 저희는 해당 서비스를 기획함으로써, 장소 선정 과정에서 어려움을 겪는 사람들의 이러한 페인포인트를 해결하고자 합니다.
- 유저리서치 (14:00 기준 79명 참)
- 2-30대를 타겟으로 잡은 유저 리서치 결과
→ 다소 고른 분포를 나타내고 있긴 하나, 30대 초반이 가장 많은 수치를 나타내고 있음.
-
장소 선정 과정 중, 어려움을 겪었던 리서치 참여자가 81%로 나타남.
→ 각각의 참여자들이 사용하는 기존 방식이 장소 선정에 어려움을 주고 있으며, 새로운 서비스의 필요성을 뒷받침하는 근거로 사용될 수 있음.
- 장소 선정에 있어서, 광고성 컨텐츠로 장소 정보의 질적인 문제(장소 정보의 객관성 문제)가 40.6%으로 가장 문제로 대두되었으며, 새로운 장소에 대한 정보 부족이 37.5%, 장소 수집에 대한 어려움이 12.5%로 나타났음.
→ 장소 정보리뷰의 객관성 확보에 대한 “라이킷” 서비스 내에 해결 방안이 필요해보임
더욱이, 응답자의 58.5 %는 네이버 지도를 통해, 장소에 대한 정보를 얻고 있었지만, 해당 매체에 대해 73.8%
의 사람들이 정보 검색에 대해 어려움을 겪고 있다고 응답함.
- 장소를 검색할 때 활용했던 기존의 매체를 활용했을 때, 45.3%의 사람들이 세분화된 필터를 통해 장소 검색의 기능을 원했으며, 31.3%의 사람들이 사용자의 취향을 반영한 장소 추천 서비스 기능을 선호한다고 응답함.
추가적으로, 단답형으로 해당 매체를 활용했을 때의 불편함을 받았을때, 장소에 대한 광고 리뷰가 너무 많아 객관성이 떨어진다는 이야기를 전달 받았으며, 정확하지 않은 필터로 원하는 정보 탐색이 어렵다(ex: 식당 필터를 눌렀지만, 카페가 섞여나왔다)는 두 의견이 대표적.
→ 기존의 정보 매체가 필터 기능을 보유하고 있으나, 필터기능으로서의 효용성이 떨어진다고 볼 수 있음. 이는 세분화된 필터를 보유한 “라이킷”이 다른 서비스와의 차별성으로도 분석 가능함.
-
96.3%의 참여자가 취향에 맞는 장소를 추천해주는 서비스를 사용할 의향이 있다고 답함
→ 취향에 맞는 장소를 추천해주는 서비스에 대한 니즈가 분명히 존재하며, 기존에 이미 이러한 기능을 제공하고 있는 서비스로도 충족이 되지 않는 다는 근거로 활용 가능함. ( EX. 네이버 지도에서 키워드로 장소 검색 가능한 기능 )
서비스 차별성
라이킷 | 데이트팝 | 완벽한 하루 | 다이닝 코드 | |
---|---|---|---|---|
서비스 분야 | 장소 콘텐츠 추천 | |||
서비스 | 데이트코스 추천 서비스 | 라이프스타일 | 빅데이터 맛집검색 서비스 | |
제공 기능 | 리뷰/콘텐츠의 객관성 | 컨셉에 따른 공간 추천 (위치기반), 특정 점포 이용권할인(shop), 장소별 유저 리뷰 | 나만의 코스 제작, 타 유저의 코스 추천, 커뮤니티를 통한 장소 추천 | 위치기반 추천 맛집, 지역기반 실시간 유저 소식, 유저간 팔로우, 상황에 따른 맛집 추천 |
장소/코스 추천 방식 | 앱 자체 추천 및 광고 | 사용 유저 직접 추천 / 앱서비스 자체 등록 장소 | 사용 유저 직접 추천 | |
추천 코스 평가 | <조회수, 찜하기, 다녀옴> 을 수치로 명시, 자체별점 및 리뷰 | 좋아요, 평점, 네이버블로그 리뷰 연동 | 평점 및 자체리뷰 / 네이버블로그와 연동 검색 가능 | |
필터 | 필터1. 분위기 필터2. 지역/음식/카페/놀거리 |
필터1. 지역 필터2. 전체/놀거리/맛집/카페 |
필터1. 전체/먹기/마시기/놀기보기/걷기 → ‘현 위치기반’, ‘찜’에 위치 필터2. 전체글/추천하기/추천받기/자유게시판→ 커뮤니티 위치 |
필터1. 현 위치기반(지역검색) 필터2. 카테고리별 필터3. 편의기능 (좌석, 반려동물동반, 주차 등등) 필터4. 방문목적 필터5. 분위기 필터6. 점수순/평점순/리뷰많은순/좋아요순 |
- 약속 장소/데이트 장소를 선정하는데 어려움을 겪는 2-30대
- 자신의 취향을 반영한 장소를 한눈에 보고 싶은 사용자
- 객관성 없는 광고성 장소 리뷰에 피로감을 느끼며, 객관성 있는 유저 리뷰를 기반으로 장소를 선정하고 싶은 사용자
페르소나 1
이름: 김수민
나이: 23살
직업: 대학생
요약: 매번 어디갈지 고민하는 것에 대해 스트레스 받는 대학생
수민이는 매주 친목 동호회에서 활동하고 있다. 모임장을 맡으며 서울에서 모일 장소들을 찾는다. 서울에서 놀러 갈 곳을 항상 찾으며 방대한 장소 리뷰와 콘텐츠들에 피로를 느끼고 객관적인 데이터를 알고싶다. 특히 가고싶은 장소를 찾는데 너무 많은 시간을 할애하고있다.
- 가는 장소를 기반으로 맛집, 카페, 엑티비티를 나눠서 보고싶다.
- 객관적인 콘텐츠를 보고싶다.
- 키워드를 중점으로 한눈에 장소를 찾고싶다.
기능 | 설명 |
---|---|
리뷰/콘텐츠 객관성 스티커 | 장소에 대한 다른 사용자의 리뷰나 콘텐츠의 객관성을 파악할 수 있도록, 장소에 방문해본 사람들이 스티커를 부여할 수 있도록 함 (ex. 스티커 종류 : ‘리뷰와 달라요’, ‘리뷰와 비슷해요’, ‘리뷰와 같아요’ , ‘만족해요’ 등등 ) |
취향 기반 장소 추천 | 초기 사용자 취향 필터 설정에 대한 정보를 기반으로 장소를 제시해줌. (1차 필터) |
세분화된 필터 | 지역별, 종류별, 정렬 순 세분화된 필터를 통해 원하는 최적의 장소를 보여줌. (2차 필터) |
장소 추천 플로우 : 로그인 → 취향 설정 (1차 필터)→ 1차 필터가 적용된 장소가 홈화면에 노출 (gps기준) → 그 내에서 세분화된 필터 설정 가능
[객관성 판별 정책] - 리뷰/ 콘텐츠 객관성 스티커 기능
-
콘텐츠 글 관련 객관성 확보를 위한 방안
- ‘콘텐츠 내용과 달라요’, ‘콘텐츠 내용과 비슷해요’, ‘만족해요’ 스티커 도입
- 실제 장소 방문해본 사람들에게 스티커 부여할 수 있는 권한 제공
-
일반적인 장소 리뷰의 객관성 확보를 위한 방안
- ‘리뷰와 달라요!’ ‘리뷰와 같아요’ 스티커 도입
- 실제 장소 방문해본 사람들에게 스티커 부여할 수 있는 권한 제공
- 해당 스티커를 5회 이상 받을 시, 라이킷 자체 에디터가 검증을 나감!
검증에 문제가 있을 시, 장소 등록이 안되게 경고 제재
라이킷은 검증을 위해 다니는 느낌…! →광고가 아닌, 실제 검증된 장소만 다니세요!
HOME 이전 취향 설정 (로그인 과정 중 선택하는 필터)
- 취향 설정(1차 필터) → [[정책] 전체 카테고리 8개 중 최대 2개만 선정 가능]
- 취향
# 조용한 | # 색다른 |
---|---|
# 전통적인 | # 모던한 |
# 화려한 | # 로맨틱한 |
#활기찬 | # 트렌디한 |
→ 세분화된 필터 (0)→ HOME
대메뉴 (기존의 메뉴 구조도에서 변경 사항 있습니다)
음식점 / 카페 / 놀거리/ 취향 공유(내 취향, 콘텐츠 부분 )
-
음식점 필터
- 음식종류 : 한식,양식, 일식, 중식, 기타( 브런치 등등 )
- 술집 : 이자카야, 와인바, 위스키바, 칵테일바
- 정렬 → 저장순 , 인기순
- 지역 선택 → 일단 MVP는 서울 지역 내 가게들
-
카페 필터
- 디저트 종류: 빵 /와플/케이크/빙수/아이스크림/도넛/브랜드명…(상의요함)
- 정렬 → 저장순 , 인기순
- 지역 선택 → 일단 MVP는 서울 지역 내 가게들
-
놀거리 필터
- 놀거리 종류 : 실내체험(공방 , 전시회, 박람회 등 ) , 액티비티(놀이공원, 스케이트, 롤러장, 스포츠몬스터) , 스파, 인생네컷(하루필름)
- 정렬 → 저장순 , 인기순
- 지역 선택 → 일단 MVP는 서울 지역 내 가게들
Frontend
Android Studio (kotlin)
-
Retrofit2
REST API 통신을 위해 빠른 성능과 간단한 구현을 자랑하는 Retrofit을 사용했습니다.
-
Jetpack
쉽고 빠른 화면 구성을 위해 Jetpack 라이브러리를 사용했습니다.
-
Dagger-Hilt
인스턴스 생명주기 관리를 위해 Dagger보다 러닝커브가 훨씬 낮고, 초기 DI 환경 구축 비용을 절감할 수 있으며 안드로이드 앱에 최적화되어 있습니다.
-
Coroutines
메모리 누수 및 블라킹 방지 등 효율적인 Context Switching을 위해 Coroutine을 사용합니다.
Backend
Springboot
-
Redis
주 서버에 장애가 발생하는 경우 요청이 여러 서버로 분산될 수 있으므로 향상된 읽기 성능과 더 빠른 복구 기능을 제공할 수 있습니다.
-
AWS S3
사용자가 인스턴스를 완전히 제어할 수 있으며 보안 및 네트워크 구성, 스토리지 관리에 효과적입니다.
-
AWS RDS
간편한 복제를 통해 프로덕션 워크로드의 가용성과 신뢰성을 높일 수 있습니다.
-
Mysql
오픈 소스 라이센스를 따르기 때문에 무료로 사용 가능하고 대용량 데이터 세트를 빠르고 효율적으로 처리할 수 있습니다.
-
JPA
SQL 중심적인 개발에서 객체중심적인 개발이 가능하며 유지보수 및 리팩토링에 유리합니다.
네이밍룰
- 패키지명: all lowercase
- 클래스명: UpperCamelCase
- 함수/변수명: CamelCase
- 상수명: UpperCamelCase
커밋 컨벤션
feat
: 새로운 기능 추가fix
: 버그 수정docs
: 문서 수정style
: 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우refactor
: 코드 리펙토링test
: 테스트 코드, 리펙토링 테스트 코드 추가chore
: 빌드 업무 수정, 패키지 매니저 수정
깃 플로우
☝🏼 기본적으로 Git Flow 전략을 이용한다. 작업 시작 시 선행되어야 할 작업은 다음과 같다.- Issue를 생성한다.
- Feature Branch를 생성한다.
- Commit - Push - Pull Request 과정을 거친다.
- Pull Request가 작성되면 작성자 이외의 다른 팀원이 Code Review를 한다.
- Code Review가 완료되면 Pull Request 작성자가 Develop Branch로 merge 한다.
- merge된 작업이 있을 경우, 다른 브랜치에서 작업을 진행 중이던 팀원은 본인의 브랜치로 merge된 작업을 Pull 받아온다.
- 종료된 Issue와 Pull Request의 관리한다. (Label 수정 등)
깃 브랜치 관리