프로젝트 컨셉 및 기획 의도
프론트
먼저, 소셜 네트워크 서비스와 맛집을 찾는 서비스를 동시에 제공할 수 있다는 아이디어가 독특했어요. 네이버나 카카오 지도에서도 친구와 맛집리스트를 공유할 수 있는 기능을 제공하고는 있으나, 그것이 URL을 공유하는 일회성 활동이라 조금 아쉬웠거든요. 또한, 내 친구가 갔던 맛집에 대한 정보를 쉽게 얻을 수 있다는 것은 정보에 대한 신뢰성이 확실히 존재하다는 점이 좋았어요. 요즘 같은 정보의 홍수 속에서 필요한 정보만 받을 수 있다는 것은 행운이니까요!
아쉬웠던 점은 와이어프레임에서 몇가지 존재하였어요.
•
나만의 비밀 맛집 리스트! 를 제공하는 서비스에서 네이버, 카카오지도에서 존재하는 다른 사람들의 별점을 불러와 표시해야 할 이유가 있을까요? 내가 좋아하고, 맛있다면 별점은 그닥 필요없을 것 같아요.
•
Back 버튼이 오른쪽에 존재하는 것이 조금 어색하게 느껴져요.
어짜피 바텀시트 형식으로 구현하였으니, 마우스 포인터를 아래로 내리면 바텀시트가 자연스럽게 내려가는 쪽으로 구현해도 되지 않을까요?
•
내가 만든 리스트에 누군가가 ‘싫어요’를 누른다면 사용자 입장에서는 기분이 좋지 않을 수 있을 것 같아요. “싫어요” 대신 , 긍정적인 피드백만을 남기는 것이 어떤가요 ? (ex. 내 취향이에요. 중식 맛집 컬렉터예요. 광기의 카페탐방가 등등..)
백엔드
광고나 이벤트 영향이 없는 맛집 공유 서비스라는 아이디어가 좋은 것 같아요. 기존 네이버 지도나 구글맵과 달리 추천한다는 개념이 있어서 믿을 수 있을 것 같아요. 프로젝트 소개를 작성한다면 ‘신뢰’라는 단어에 중점을 두고 작성하면 좋을 것 같아요.
‘정보화 사회에서 느낀 불편함’이라는 문제인식과 개인의 ‘비밀 맛집 지도’라는 접근 방식이 특히 좋은 것 같아요.
식당 목록을 다른 지도에서 크롤링 해와야 할 것 같은데, 크롤링을 할 때도 광고인해 상단에 노출되는 것들의 영향을 받지 않을 수 있도록 주의하면 좋을 것 같아요.
프로젝트 구조 및 설계
프론트엔드
아직까지는 프로젝트 세팅 및 초기단계인 것 같아서 프론트엔드 기술이나 코드 관련해서 피드백을 남길 만한 상황이 아닌 것 같아!요
백엔드
•
포맷터와 CI
Github Workflow로 CI를 하고 있는 것 같아요!
포맷터까지 잘 활용하고 있는 것 같습니다.
이제 추가로 CD까지 해보시면 좋을 것 같아요.
배포를 마지막에 하려고 하면, 백엔드 개발이 끝날 때까지 프론트에서는 화면만 만들고 할 수 있는게 없어집니다.
미리 CD를 구성해두고 이슈 하나 처리할 때마다 배포가 자동으로 이루어질 수 있도록 하면 좋을 것 같아요!
이왕 하는 김에 docker를 활용해보면 특히 더 좋을 것 같아요.
기술 스택 및 협업툴
프론트엔드
•
서버 상태관리는 react-query 를 선택하신 것 같던데, 클라이언트 상태관리는 Recoil을 추천하지 않아요. (차라리 Zustand나 Jotai 쓰시기를…!) 현재 Recoil은 2년째 더이상 새로운 개발을 하지 않아서, deprecated 된 상태입니다.
•
eslint : eslint는 아직 기본 초기 상태로 남겨져 있는 것을 확인하였어요. 이러한 것을 팀원들과 정하여서 어떤 룰을 허용할것인지 아닌지 결정해야 하는데, 라이브러리 이름으로 설정되어 있어 어떤 설정이 유리할지 잘 모르겠다면, 유명 개발 학회나 동아리에서 진행한 프로젝트의 eslint 세팅 룰을 참고하여 보는것도 도움이 될 거예요. (당연히, 참고 이후에는 어떤 라이브러리인지 명확히 확인할 필요가 있습니다!)
•
rebase 를 처음 접하는 분들은 많이 복잡하고 어렵다고 생각할 수도 있는데요, rebase가 그냥 다른 브랜치를 merge하는 것보다 좋은 점은 상대방과 나의 작업물이 무분별하게 섞이는 것을 어느정도 방지할 수 있다는 것이에요. 이번 기회에 습관을 들이면 아주 좋을 것입니다.
백엔드
•
MySQL을 사용하기로 한 특별한 이유가 있나요?
물론 그대로 사용하셔도 되지만, 장고 공식문서에서는 Postgresql을 ‘most capable’ 하다고 설명하고 있습니다.
두 db의 장단점을 비교해보고 적절한 것을 선택해보는 것도 좋은 경험이 될 것 같습니다.
•
코드 리뷰 문화를 도입하면 좋을 것 같습니다.
이미 여러 컨벤션을 만들어서 너무나도 훌륭한 팀 운영을 하고 있는 것 같아요.
여기에 딱 리뷰 문화만 추가하면 더 좋을 것 같아요.
팀원이 PR을 만들면 잘못된 부분은 없는지, 개선할 수 있는 부분은 없는지를 서로 검토함으로써 버그를 줄일 수 있을 것 같고 이후 QA 작업도 수월할 것 같아요!
•
깃허브 이슈를 활용해주세요.
Issue를 생성해 작업할 내용을 간단히 기록하면 프로젝트의 일정을 효율적으로 관리하고 협업을 강화할 수 있습니다.
어떻게 시작해야 할지 막막하다면, 다른 프로젝트들이 사용중인 템플릿을 활용하면 어렵지 않게 시작할 수 있을 것 같습니다.
이슈 템플릿 만드는 방법을 참고해서 필요한 템플릿을 만들어 사용해보면 좋을 것 같습니다.
일정 산정 및 관리 방법
프론트엔드
1,2,3차 MVP로 나누어 단계별로 구현하는 방식은 정말 좋은 방법같아요. 한번에 모든 것을 다 할 수 없으니, 꼭 구현해야 하는 부분부터 선택적으로 하는 것이죠
할 수 있는 부분부터 정리하고, 1,2,3차 MVP에 따라서 일정을 세세하게 나누신 부분도 잘 하신 것 같아요.
백엔드
기획서를 보니 7월 말까지 대부분의 기능을 구현하고자 하는 것 같아요.
기능이 적지 않기 때문에 지금처럼 매일 데일리스크럼을 하면 좋을 것 같아요.
추가로 하나 제안 드리고 싶은게 있다면 백엔드 팀만의 코어타임을 만드는거에요!
매일이 어렵다면 이틀에 한번씩이라도 코어 타임을 가지면 기한 내에 개발을 마칠 수 있을 것 같아요.
기능 구현 및 주요 개발 포인트
프론트엔드
프로토타입을 기준으로, 가장 개발이 어려울 것 같은 부분은 아래 두 가지라고 생각해요.
•
지도 구현 → 지도에 핀이 나타나게 하고, 해당 핀이 클릭되었을때 식당의 정보를 랜더링하는 부분
•
친구 신청 - 친구 수락 부분 → 이 부분이 특히, 백엔드 부분에서 구현하기 힘들어서 신경을 많이 쓰시게 될 거 같아요. 프론트 구현할 때에는 아래 상태들을 참고하시면 좋을 것 같아요.
◦
친구를 신청하고, 대기하는 상태
◦
친구 신청받고, 대기하는 상태
◦
친구 신청 전 / 신청 수락 상태 → 그리고 그 친구가 수락된 상태를 상대방에게 어떻게 알려줄 것인가?
◦
친구 차단 기능이 있다면, 차단한 친구는 어떻게 보여주어야 할까?
◦
친구를 끊고 싶다면 어떻게 구현해야 할까?
위 내용들을 한번 고민해보시면 좋을 것 같아요.
•
바텀시트 인터랙션 구현
네이버 지도의 바텀시트를 보면 사용자의 터치/스크롤에 의하여 움직여요. 도전할 수 있는 개발 포인트가 될 수 있을 것 같아 언급합니다!
백엔드
•
로그인
◦
아이디/비밀번호 혹은 소셜 로그인으로 구현을 하게 될 것 같아요.
로그인 후에 여러 api들을 호출할 때는 어떻게 인가할 것인지 생각해보면 좋을 것 같아요.
많이 사용하는 Jwt를 활용해보면 좋은 경험이 될 것 같아요.
•
내 리스트에 추가/제거
◦
내 리스트이므로 나만 수정할 수 있어야 해요.
다른 사람이 내 리스트를 수정할 수 없도록 할 수 있는 방법 생각해보시면 좋을 것 같아요.
•
한줄평 더보기
◦
굉장히 많은 리뷰를 보여주는 뷰가 될 것 같아요.
이 한줄평들을 한번의 api 요청으로 프론트에 전달하면 비효율적일 것 같아요.
페이지네이션을 적용해보면 좋을 것 같습니다!
•
검색 기능
◦
정확한 가게 이름 뿐만 아니라, 키워드로도 검색이 가능하도록 구현하면 좋을 것 같아요.
예를 들어 제순 식당이라면, 제순 만 입력해도 검색되도록이요!
협업 방식
프론트엔드
•
데일리스크럼을 꾸준히 운영 중에 계시군요. 매일 Todo를 공유하고 어떤 하루를 보냈는지 TMI도 공유하는 모습이 보기 좋아요. 7월 말 ~ 8월은 개발에 정말 집중해야 하는 시기이기 때문에, 스크럼을 커밋 링크를 올려서 진행하면 좋을 것 같기도 해요 (어떤 작업을 했는지 명시적으로 확인).
그리고 서로 도움이 필요할때 빠르게 도움을 주고받을 수 있도록 어려운 점도 자유롭게 이야기할 수 있는 분위기가 되면 좋을 것 같아요.
•
프론트엔드) 기본 브랜치를 develop으로 활용하셨던데, 주희님은 이전에 main에 커밋하셨던 적도 있는 것 같아서 이러한 규칙이 서로 잘 공유되면 좋을 것 같아요 ! (혼동을 줄이기 위하여 잠시 main에 커밋하지 못하도록 하던지 해도 좋을 것 같아용)
•
결정사항이 필요한 부분들을 노션 문서로 보기 좋게 정리하여 두셔서 결정을 위하여 어떤 의견이 오갔는지 확인할 수 있어서 좋았어요. 시간이 많이 부족하겠지만, 팀의 변경사항 중 중대한 것은 서로 논의하는 모습을 꾸준히 지켜 가면 좋을 것 같아요
백엔드
•
커밋 메시지 컨벤션까지 알아서 잘 운영하고 계신 것 같아요
•
기능이 많으니 매일 각자 PR 하나 올리기 같은 그라운드룰을 정하면 좋을 것 같아요.
원활한 진행을 위해서는 하루에 최소 한 번은 PR 리뷰하기 같은 룰도 좋아요!
•
기존 api 스펙이 바뀌는 일이 생긴다면 바로바로 프론트 쪽에도 전달해주시면 좋을 것 같아요.
기타
프론트엔드
•
package.json에 packageManager 명시해두시면 좋을 것 같아요.
•
rebase 이후에는 force push를 해야 나의 커밋 내역이 중복으로 들어가지 않아요.
팀 워크스페이스를 둘러보니, 벌금제도를 운영하고 있는 것으로 확인했어요. 만약 돈을 모으면 어느 곳에 사용할지도 궁금합니다!
백엔드
•
사용한 브랜치는 PR을 merge하자마자 지워주세요.
브랜치는 재활용하지 않을거라서 바로 지워야 나중에 잔뜩 쌓이지 않아요.
•
PR을 머지할 때 squash and merge를 하면 한 브랜치에서 쌓인 여러 커밋들을 하나로 묶어서 머지할 수 있어요.
현재는 squash and merge를 하지 않고 있는 것 같은데 커밋 로그를 깔끔하게 관리하려면 squash and merge 추천합니다!
•
settings.py에 secret key가 노출되어 있습니다.
.env 파일이나 json 파일 등으로 분리하고 github에는 올라가지 않도록 하는게 좋습니다.
참고 자료
•
settings.py에서 time zone을 수정해주세요.
데모데이 상호평가 결과 공유
아래 내용은 7월 22일에 진행한 데모데이에서 프로젝트 트랙 참가자분들이 작성한 설문조사 피드백을 요약한 결과입니다.
전반적인 점수
우리 팀이 보완해야 하는 부분에 대해 나타내는 전반적인 평가 점수예요! 참고용으로만 봐주세요
1.
발표 진행 과정 : 4.7/5.0
2.
문제상황과 해결과정의 정당성 : 4.8/5.0
3.
독창성 및 기획 완성도 : 4.0/5.0
4.
협업 및 Github 활용도 : 4.8/5.0
율리없는 율리팀의 강점
•
주제 관련 이야기
◦
비밀맛집지도를 만드는 점에서 광고로 인한 피해를 입지 않을 수 있다는 점이 좋은 것 같습니다. 신뢰도를 나타낼 수 있게 한 것이 강점이라고 생각합니다.
◦
맛집 리스트에 대해 평가할 수 있다는 것이 신뢰도를 높일 수 있는 좋은 방법인 것 같습니다
•
기획 단계 이야기
◦
전체적으로 당근마켓+맛집어플+블로그 이웃 기능이 합쳐진 듯한 기획이었다.
◦
로고가 귀엽다.
◦
MVP 단계 별로 마감 일자를 명확하게 정하고, 구현할 내용을 구체적으로 정해놓아서 체계적이다.
◦
프로토타입 모델의 디자인 양식이 매우 깔끔하게 정렬되어 있어 개발 시 참고하기 좋을 것 같다는 인상을 받았다.
◦
Git과 노션페이지를 참고한 일이 있었는데, 이를 확인하고 협업시스템이 촘촘하다고 느꼈다. 또한 앱의 디자인적인 측면에서도 완성도가 가장 있었다.
◦
팀 노션 워크스페이스를 둘러보면 팀 협업 방식이 좋았다.
◦
사소할 수 있는 주황색에도, 식감을 돋운다라는 코멘트를 통해 선정이유를 강조한 부분이 좋았다.
•
개발 이야기
◦
개발 환경에 대한 고민을 많이 한 것이 드러났다.
◦
커밋 컨벤션을 설정해서 지키지 않았을 경우 커밋 못하게 한다는 점이 협업한다는 점이 인상깊다.
◦
Git과 노션페이지를 참고한 일이 있었는데, 이를 확인하고 협업시스템이 촘촘하다고 생각하게 되었다.
율리없는 율리팀의 아쉬운 점
•
기획
◦
서비스 초기에 사용자 모집 방법에 대해서 조금 더 보완이 필요할 것 같다.
◦
로고가 살짝 당근마켓과 상당히 유사한 것 같습니다.
예상되는 문제점에 대한 조언
•
기획
◦
사람들이 이 서비스를 사용하게 만드는 더 매력적인 이유가 있으면 좋겠다. 광고성 정보가 많다고 하더라도 리뷰가 이미 다 쌓여있는 네이버 지도나 카카오맵을 두고 이 서비스를 선택할 이유가 더 명확해야 한다고 생각한다.
◦
맛집을 sns에 공유할 수 있는 기능이 있었으면 좋겠다.
◦
친구의 리스트 평가 방식에 '싫어요'보다는 완곡한 표현으로 바꿔도 좋을 것 같다고 생각한다.
◦
찾고자 하는 음식에 대해 카테고리별로 볼 수 있으면 좋겠다.
◦
회원가입할 때 회원에 대한 정보를 받아, 비슷한 음식을 좋아하는 유저를 추천하는 기능이 있으면 어플리케이션 이용에 대한 접근성이 증가할 것 같다.