이쯤 읽으셨다면 이제 항해를 하면서 제때 WIL 을 쓰지 못했다는 사실을 다들 아실 것 같다. 절대 게을러서... 가 맞을지도 몰라요. 킹치만 INFP 는 게으른 완벽주의자 랍니다... 뭐가 어떻게 됐든 제때 쓰지 못했다는 사실은 변하지 않는다. 그럼에도 불구하고 여유가 어느 정도 있는 상태에서 내가 걸어왔던 시간을 제대로 곱씹고 기록으로 남기고 싶은 마음이 컸기 때문이라고 이해해 주실 거라 믿는다.
실전 프로젝트에서는 그 동안의 프로젝트와는 다르게 팀장과 부팀장이 항해 측에서 선별하는 것이 아니라 지원을 받는 형식으로 이뤄졌다. 클론 프로젝트를 진행하면서 만났던 부팀장이 굉장히 열정적일 뿐 아니라 실력적으로도 부족함이 없다고 생각해 다른 조에 뺏기고 싶지 않았다. 그리고 무엇보다 내가 팀장을 하고 싶었다.
팀장이 하고 싶었던 이유에는 다양한 이유가 있었지만 팀장을 하면서 팀원들 보다 더 고생하면서 배우고 도움이 되고 싶은 마음, 한두 가지의 기술에 몰두하는 것이 아니라 팀 전체적으로 전반적인 내용을 공부하고 싶은 마음이 있었다. 그리고 개발뿐 아니라 대학부터 회사까지 다양한 프로젝트를 해왔기 때문에 잘 할 수 있을 것이라 생각했기 때문이다.
어쨌든 실전 프로젝트의 팀장으로서 6주라는 짧다면 짧고 길다면 긴 프로젝트의 첫 주차에 내가 가장 많이 신경 쓴 부분에 대해서 말해보고자 한다.
1) 서비스 기획
가장 공을 많이 들인 부분이라고 해도 부족함이 없는 부분이 이 부분이었다. 어떤 프로젝트를 어떻게 할 것인가? 에 대한 부분이었다. 기획이 잘못되어 다들 개발했던 것을 모두 엎어야 되는 상황이 오는 것은 피하고 싶었다. 이런 마음가짐으로 다양한 의견들을 모으다 보니 장장 이틀에 걸친 기획 회의를 할 수밖에 없었다. 빡센 회의에 모두가 학을 뗐지만 결국엔 디자이너, 프론트엔드, 백엔드 모두가 만족할 수 있는 기획을 할 수 있었다고 자부한다.
1-1) 방향 설정
정말 부끄러운 얘기지만 나는 팀장을 맡을 만한 리더십이나 카리스마를 가진 사람은 아니다. 대신 구성원들의 얘기를 잘 듣고 우리가 나아가고자 하는 방향성과 맞는가에 대한 고민을 하는 사람에 가까운 것 같다.
그래서 나의 입맛대로 어떤 주제의 프로젝트를 하자! 라고 확실하게 밀어 붙이지 않았고 다른 구성원들의 아이디어를 적극적으로 듣고 반영하고자 했다. 그러기 위해서 주제보다는 하나의 비전을, 그리고 우리가 앞으로 나아가야할 방향을 설정하는 것이 중요하다고 생각했다. 이 부분에 대해서는 다행히 모든 팀원들이 동의를 해주어 첫 단추가 잘 끼워질 수 있었다.
결국 기획 회의를 시작하면서 구성원 모두가 가장 중요하게 생각한 부분은 아래와 같다.
- MVP 관점에서 개발할 수 있는가?
- 기본 CRUD 기능부터 Challenge 기능까지 다양하게 경험할 수 있는가?
- 우리가 하고 싶은가?
MVP 관점에 대한 건 지난 7주차 WIL 에서 포스팅 했기 때문에 여기서 다루진 않겠다. 우리가 하고 싶은가에 대한 것도 너무 당연하기 때문에 넘어가도록 하겠다. 여기서 기본 CRUD 부터 차근차근히 나아가고자 하는 이유는 따로 있었다.
부트캠프, 특히 항해99의 특성 상 짧은 시간 내에 기능을 구현해야 하는 경우가 굉장히 많다보니 기본 CRUD 를 제대로 이해하지 못하고 넘어간 팀원들도 있었다. 반면, 기본 CRUD 를 넘어 Challenge 기능에 도전하고 싶은 사람들도 있었다.
결국엔 MVP 관점과 연결되는 얘기이긴 하지만 화상 채팅 서비스와 같이 Challenge 기능이 주 기능인 서비스가 아니라 기본에 충실하되 Challenge 기능도 풍성한 서비스를 하고 싶다는 것이 나를 포함한 모든 팀원들의 의견이었다.
1-2) 주제 선정
다행히도 브레인스토밍을 할 때 팀원들의 아이디어가 정말 많았다. 우리 동네 카페 리뷰 서비스, 스토리 플레이를 오마쥬 한 서비스, 각종 영양제 성분 및 리뷰 서비스, 여행지 코스 추천 서비스 등 여러가지가 나왔다.
그러나 모두 위의 조건을 만족할 순 없었다. 카페 리뷰는 주제가 너무 뻔할 것 같고, 영양제 성분 리뷰는 우리가 전문적인 지식이 없다는 점, 여행지 코스 추천 서비스는 메인 기능이 Challenge 기능이 될 것 같다는 점이 걸렸다.
결국 정해진 주제는 프론트엔드에서 질리도록 해왔던 TO DO LIST 였다. 그러나 이 TO DO LIST 에 차별성을 주고자 내가 완료한 TO DO LIST 를 피드 형식으로 공유할 수 있는 SNS 를 만들고자 했다. 이 경우에 MVP 관점에서 개발을 할 수 있을 뿐 아니라 기본 CRUD 부터 Challenge 기능까지 다양하게 경험할 수 있었다.
특히나 좋았던 것은 운동, 공부, 업무 등 내가 오늘 달성한 과제를 SNS 에 올리는 사람들이 있기 때문에 이에 대한 확실한 니즈가 있다는 것이었다.
그러나 이런 SNS 가 사용자들에게 뻔하게 느껴지지 않게 우리 만의 아이덴티티를 입혀 확실히 각인 시키는 것이 굉장히 중요했다. 결국엔 브랜딩이 문제였는데, 그래서 이를 위한 네이밍이 굉장히 중요했다.
네이밍을 위한 후보들은 아래와 같았다.
- Grow Share (함께 나누며 성장하자는 뜻)
- 다잇수할 (할 수 있다를 거꾸로 함)
- 스윋 (Study With - 를 한글로 씀)
- 내가해냄 (최고심 이모티콘 느낌)
- 페이스메이커(같이 달리며 페이스를 조절해주는 동료)
- 두블럭 (Do! Block 이라는 뜻, 피드 대신 블럭을 쌓는다고 표현)
자칫 경쟁을 유도하는 SNS 서비스처럼 느껴질 수 있기 때문에 최대한 함께 성장하는 쪽에 포커싱을 했다. 물론 경쟁이 성장을 일으키는 요소는 맞지만 SNS 의 역기능보다는 순기능에 초점을 맞추고자 했기 때문이다. 결국 위의 후보들 중에서 치열한 투표를 통해 선정된 네이밍은 Do! Block 이었다. 내가 아이디어를 냈다 (｡･∀･)ﾉﾞ
도전을 유도하는 이름이며, 피드 대신 블럭을 쌓는다고 표현하여 마케팅하기도 좋고 컨셉도 확실해 사용자의 뇌리에 쉽게 박히리라 생각했기 때문이다. 특히나 디자이너도 함께하는 프로젝트였기 때문에 이런 확실한 컨셉이 있을 때에 디자인하기에도 훨씬 수월할 것이기 때문이었다.
능력있는 부조장 덕분에 귀염뽀짝한 로고도 만들 수 있었다. 저 하찮은 웃음... 하앜
1-3) 기능 설정
선정된 주제에 맞게 기능을 설정했다. 피드형 TO DO LIST SNS 이기 때문에 이에 맞는 기능들이 필요했다. 주제 선정은 다 함께 정하는 느낌이 강했다면 기능 쪽에는 자신이 개발해보고 싶은 기능에 대한 어필이 강하게 들어왔다.
정말 기본 기능인 투두 리스트 기능, 그룹 투두, 그룹 투두 오프라인 모임을 위한 지도 기능, 드래그 앤 드롭 기능, 파일 공유 및 업로드 등등 여러가지 아이디어가 들어왔지만 결국 길고 긴 토론을 통해 정말 핵심적인 기능에만 집중하기로 했다.
이 또한 지난 포스팅에서와 마찬가지로 기본 기능, 추가 기능, Challenge 기능으로 묶어 보려 한다. 물론 1주 짜리 클론 프로젝트와 6주 짜리 실전 프로젝트는 갭이 있기 때문에 이 부분을 염두하고 봐주셨으면 좋겠다.
- 기본 기능
- 회원 관리 (Spring Security 로그인, 이메일 중복체크, 닉네임 중복체크, 회원가입)
- 프로필 (프로필 페이지, 정보 변경, 비밀번호 변경, 팔로우 / 팔로우 취소, 팔로잉 / 팔로워 리스트)
- 투두 리스트 (투두 작성 / 완료 / 수정 / 삭제, 투두 일별 조회)
- 피드 (피드 작성 준비 / 작성 완료 / 수정 / 삭제 / 단건 조회 / 팔로잉 피드 조회)
- 리액션 (LIKE, HEART, SMILE, PARTY, FIRE 작성 / 수정 / 삭제 / 조회 / 리스트 조회)
- 댓글 (피드 댓글 작성 / 수정 / 삭제 / 조회)
- 추가 기능
- 회원 관리 (소셜 로그인 - 카카오 / 네이버 / 구글, AccessToken 재발급)
- 프로필 (내 피드 보기, 뱃지 생성 / 조회 / 설정, 관심사 태그 설정)
- 투두 리스트 (드래그 앤 드롭으로 일별 투두 순서 변경)
- 피드 (추천 피드, 팔로잉 피드, 피드 무한 스크롤, 피드 태그 설정)
- 검색 (태그 검색 - 피드 Response, 유저 검색 - 유저 프로필 Response, 검색 결과 무한스크롤)
- Challenge 기능
- 이스터 에그 (카카오 페이 기능, Mock-up 결제 완료 시 뱃지 획득 및 피드 특수 스킨 오픈)
- 뱃지 획득 시 알림 팝업 기능 및 이벤트 피드 생성 (SSE 활용, 사용자가 원할 시 뱃지에 맞는 이벤트 피드 자동 생성)
- 유저 간 채팅 기능 (채팅방 생성 / 목록 조회 / 메세지 조회 / 메세지 송신)
기본 기능 만으로도 정말 풍성하고 꽉 찬 기능이라고 생각된다. 리액션의 경우에는 좋아요만 넣지 않고 여러 가지 항목을 넣고 싶다고 하여 LIKE, HEART, SMILE, PARTY, FIRE 와 같이 피드 작성자와 조회자 간의 긍정적인 피드백을 유도할 수 있도록 했다.
피드 부분에 피드 작성 준비 API 가 조금 특이한 부분이라고 여겨질 수 있을 것이다. 그러나 주제 자체가 내가 완료한 투두를 피드에 공유하겠다는 취지이기 때문에 내가 오늘 완료한 투두가 피드에서 선택될 수 있도록 만들어야 했다. 그랬기 때문에 이 부분이 들어가야만 했고, 피드 작성 완료와 다른 API 가 추가로 들어갔다.
추가 기능으로 보자면 역시나 소셜 로그인, 내 피드 보기, 드래그 앤 드롭 기능, 추천 피드 등으로 유저의 편의성 개선을 목적으로 했다. 여기에서는 유저의 활동을 촉진시키고자 투두 완료, 피드 작성, 댓글 작성 등 유저의 활동에 따라 뱃지를 부여하는 기능을 만들었다. Steam 의 메달이나 달성 과제 같은 느낌이다. 특히 이 뱃지를 자신의 대표 뱃지로 설정하여 피드를 작성하면 이것을 자랑할 수 있도록 하였고, 프로필 창에서 유저가 획득한 뱃지를 확인할 수 있도록 하였다.
또한 유저 별 자신의 관심사 태그를 설정하면 그에 맞게 추천 피드를 보내주는 기능을 추가했다. 팔로잉 피드만 있다면 누군가의 추천이나 친구 추가에 의해서만 피드를 볼 수 있다는 얘기가 되는데, 그럴 경우 내가 볼 수 있는 피드의 수가 너무 한정적일 거라는 계산이었다. 그래서 유저가 관심사 태그를 설정하면 피드에 설정된 태그에 맞게 추천해주는 기능을 넣은 것이다.
검색 기능도 넣어서 이런 부분을 충족시켜주고자 했다. 다양한 관심사를 가진 많은 사람들이 소통할 수 있는 SNS 를 만들고 싶었기 때문이다. 다만 내용으로 검색하는 것은 효율성이 떨어진다고 판단하여 태그 검색과 유저 검색으로만 범위를 한정시켰다. 인스타그램도 내용 검색은 없다. 물론 인덱싱을 걸진 못했지만 인덱싱하는 데에도 문제가 있을 수 있다고 생각했기 때문이다.
Challenge 기능에는 정말 있으면 좋고 없어도 기능에는 전혀 지장이 없으며, 구현하는 데에 난이도가 높은 기능을 선정했다. 사용자가 이스터에그를 찾으면 카카오 페이 Mock-up 결제를 하는 창이 띄워지며 결제를 완료하면 뱃지가 획득되고 감사의 뜻을 담은 피드 스킨을 지급하는 방식의 기능이었다. 물론 결제 전에 사용자에게 충분히 취지를 설명하는 팝업을 띄울 예정이었다.
유저가 뱃지를 획득하게 되면 SSE 로 바로 획득 알림 및 이벤트 피드를 남길 것인지 묻는 팝업을 띄워주는 기능도 이에 넣었다. 이벤트 피드를 남기겠다고 하면 뱃지 종류에 따라 이벤트 피드가 자동으로 생성되며 이 이벤트 피드에 팔로워들이 리액션 및 댓글을 남기며 유저의 성장과 피드백, 활동을 촉진시키고자 한 장치였다. 여기서 이벤트 피드 만의 독특한 피드 스킨이나 효과로 이를 더욱 촉진하고자 했다.
유저 간 채팅 기능도 마찬가지로 유저 간 소통을 높이기 위한 기능으로, 달성한 목표의 노하우를 나누거나 친목을 강화하고자 한 기능이었다.
이렇게나 기획을 열심히 했음에도 불구하고 시간 부족과 잦은 디자인 변경에 의해 프론트엔드에서 Challenge 기능에는 손도 대지 못했다. 이 부분은 디자이너 개인의 문제인지 디자이너 피드백을 해주는 멘토의 문제인지 항해99 측의 운영 미숙인지 아직도 잘 모르겠다. 어쨌든 이 부분에 대해서는 추후에 포스팅을 남기도록 하겠다.
2) Git 전략
누워서 침 뱉는 얘기긴 하지만 마지막 실전 프로젝트에 들어왔지만 여전히 Git 을 제대로 쓰지 못하는 사람들이 수두룩 했다. 어디선가 Push 가 되지 않아요! 어디서 꼬인지 모르겠어요! Conflict 가 났는데 이거 어떻게 해야돼요! 라는 말이 들려오기 일쑤였다.
그래서 팀원들에게 많이 강조한 부분이 Git 전략과 사용법이었다. 절대 Main 이나 Master Branch 에는 PR 을 않는다. Release Branch 에서 Feature 별 Branch 를 따로 두어 개발 후 코드 리뷰 후 Release Branch 에 PR 및 Merge 를 진행한다. Conflict 를 두려워하지 않는다. Pull, Push, Commit 전에 항상 Patch 를 진행한다. 등등 많은 부분을 얘기했다.
아래의 블로그 들을 공유하며 Git 전략과 코드 리뷰 문화를 정착시키려 했다. 알아볼 수 없는 Commit 메세지와 보기만해도 머리가 아픈 Git Flow 들이 더 이상 우리를 괴롭히지 않도록 하기 위해서였다.
그 외에 Issues, Project 의 칸반보드, Wiki 등도 적극 사용할 수 있도록 권장했다.
특히나 코드 리뷰를 적극 권장하였는데, 내가 배운 것을 정리하며 한 번 더 공부할 수 있을 뿐 아니라 상대방이 배운 내용을 함께 습득할 수 있는 기회이기 때문이었다. 각자 맡은 부분만 공부하다보면 다른 부분에 대한 갈증이 생기기 마련이다. 코드 리뷰가 이를 해결해줄 수 있을 것이라 믿었다.
우린 Git-flow를 사용하고 있어요 : https://techblog.woowahan.com/2553/
브랜치 전략 수립을 위한 전문가의 조언들 : https://blog.hwahae.co.kr/all/tech/tech-tech/9507
코드리뷰 문화 정착하기 : https://blog.cowkite.com/blog/2003062358/
GitHub으로 협업하기: 클론부터 코드 리뷰까지 : https://xo.dev/github-collaboration-guide/
3) ERD 설계
프로젝트를 위한 모든 판은 깔렸다. DDD 에 대해선 제대로 이해하지 못하고 있지만 각 Entity 설계가 완성되어야 기능 개발이 원활할 것이라고 생각되어 내가 주도적으로 설계를 마쳤다.
물론 이 ERD 는 최종판으로, 중간에 많이 바뀌었지만 여기에서 가장 신경을 많이 쓴 부분은 가급적 양방향 관계를 지양한다는 것과 Tag 부분 설계였다.
필요에 의해서 양방향 관계를 쓸 수도 있었겠지만 워낙에 양방향 관계를 극혐하시는 분에게 심하게 대인 경험과 딱히 필요한 곳이 없다는 이유에서 이렇게 만들었다.
지금 보니 화살표 모양에 다른게 들어가는게 맞았을 것 같긴 하지만 어쨌든 관계도와 대략적인 Entity Field Type 까지 잘 들어있는 ERD 인 것 같다. 이때는 SQL 지식이 많이 부족해서 관련 데이터 타입을 넣지 못했다.
Tag 에 관한 얘기를 해보자면, 유저가 설정한 관심사 태그로 해당 피드를 Response 해줘야하는 상황이 생겼다. 그렇다면 여기서 과연 태그와 피드, 태그와 유저의 관계는 어떻게 될 것인가?
정말 많은 고민을 했지만 결국엔 동일한 태그를 가진 피드, 유저가 발생할 수밖에 없다고 생각했다. 그렇다면 N:M 관계가 형성될 것인데, 이를 해결할 수 있는 방법은 1:N:1 로 Mapper Class 를 둬야한다는 것이었다.
따라서 MemberTagMapper, FeedTagMapper 를 두어 유저가 설정한 태그로 FeedTagMapper 를 불러와 해당 피드를 Response 하는 것으로 설계를 마쳤다. 그러나 이 부분이 초기 개발에 있어, 특히 무한 스크롤 기능에 꽤나 애를 먹게 하는 요소로 작용했는데 이는 추후에 포스팅하도록 하겠다.
이렇게 포스팅을 보고나니 사실 나는 개발자보다 PM 으로서의 재능이 더 있는건 아닐까......? 라는 생각이 들긴 하는데 이 부분은 추후 코드와 기능 관련 포스팅에서 완전히 박살나는 건 나였고^^ 검증하도록 하겠다.
어쨌든 첫 단추가 잘 꿰어졌으니 진짜 앞으로 달려나갈 차례이다. 다들 화이팅!
