[Kernel360] Boot-Up : TwoStar

개요

Kernel360 과정에 합격하여 진행하며 처음 진행했던 Boot-Up project인 TwoStar에 대해 소개하고자 합니다. Boot-Up project는 실제로 개발을 진행하는 것보다 기획 과정 중 일어나는 협업에 초점을 둔 프로젝트입니다. 3일 차에 팀장을 제외한 나머지 팀원들이 랜덤으로 다른 프로젝트에 배정되기 때문에 더 많은 사람과의 기획간 협업을 진행할 수 있었습니다. TwoStar는 Instagram과 같은 사진 / 영상 미디어 기반의 소셜 미디어 플랫폼을 기획하고자 하는 의도를 갖고 기획을 진행하였습니다. 이렇게 진행한 프로젝트 기획 및 협업 방식을 통해서 앞으로 과정 중 진행 될 프로젝트에서 어떤 방식을 통해 기획을 하고 개발을 진행하는 것이 좋을지 배울 수 있었습니다.

 

아래의 Notion과 Github 링크에서 프로젝트에 대한 더 자세한 문서와 결과물의 세부 내용들을 확인하실 수 있습니다.

TwoStar 팀 노션 : https://www.notion.so/TwoStar-09427804baab4c1089149f8b2900d82d?pvs=4

TwoStar 팀 Github : https://github.com/Kernel360/boot-up1-twoStar

기획

본 프로젝트 진행 중 팀장을 맡게 되어서, 앞으로 사용할 Github 저장소를 만들고 다른 팀원들에게 역할을 부여했습니다. 다음으로 팀원들과 함께 다양한 문화와 시차를 고려하고, 실제로 개발을 진행하지는 않지만 실제로 상용되는 서비스처럼 많은 기능을 포함한 주제를 선정하고자 설계 토의를 진행했습니다. 이 과정에서 모든 팀원들의 의견을 수렴하여 주제 목록을 만든 결과는 아래와 같습니다.

• Aliexpress - 글로벌 이커머스
• Paypal - 결제 서비스
• Skyscanner - 항공권 예약 서비스
• Instagram - 소셜 네트워크 서비스
• Spotify - 음원 스트리밍 플랫폼

이 중에서 Instagram과 같은 소셜 미디어 서비스를 선정한 이유는 많은 기능을 가지고 있지만 모든 기능들이 쉽게 이해할  수 있고 다양한 문화 / 시차에서 동시에 사용되는 서비스 중 하나이기 때문입니다. 또한 3일이라는 제한적인 시간 내에 기획에 대한 산출물을 만들어야 했고 따라서 더더욱 기획을 끝낼 수 있는 서비스를 참고하는게 이상적이라고 판단되어 Instagram을 주제로 고르고 실제 서비스를 참고하여 기능 설계를 진행하였습니다. 

 

실제 서비스를 참고하여 만든 초기 기능 설계는 다음과 같습니다.

• 사용자
  • 회원 가입 및 로그인
  • 프로필 수정
  • 관심사 분석
  • 알림 설정
  • 위치 정보 설정
  • 언어 설정
• 피드
  • 추천 피드 조회
  • 팔로우 피드 조회
  • 메시지 목록 조회
  • 아이템 조회
• 게시글
  • 게시글 작성
  • 게시글 수정
  • 게시글 삭제
  • 게시글 조회
  • 좋아요
  • 북마크
• 메시지
  • 메시지 송신
  • 이전 메시지 내역 출력
• 기타
  • 라이브 방송
  • 프로필 공유

이때까지만 해도 프로젝트 기획이 완료되면 어떤 문서들이 완성되어 있어야 하는지에 대한 개념이 부족했습니다. 기능 설계 토의 중 비슷한 기능끼리 묶어서 나타내려고 하였으나 이로 인해 너무 많은 시간이 소모되었고 따라서 To do가 필요하다는 생각이 들었습니다. 따라서 저는 아침마다 팀의 Notion 페이지에 당일의 To do를 추가하고 데일리 스크럼을 진행하여 오늘의 목표가 무엇인지 팀원들과 공유하였습니다. 또한 문서 목록을 가장 최근 상태로 유지하여 3일차에 새로 들어오는 팀원들이 더 쉽게 프로젝트를 이해할 수 있도록 하였습니다.

 

모든 To do가 완료되었습니다!

 

위 기능 설계를 기반으로 1일 차에는 프로젝트의 UseCase,  API 명세, ERD에 대한 초안을 만들 수 있었습니다. 2일 차에 앞서 만들어둔 산출물을 수정하고 다른 산출물을 추가하는 과정에서 많은 시행착오가 있었습니다.

 

• API 명세 초안이 있었지만 Restful한 API Endpoint 형식을 띄지 않고 있었고, 요구 사항 명세가 작성되지 않은 부분들이 존재해 수정에 참고할 수 있는 자료가 없었습니다.
• 1일 차에 분업하여 산출물을 작성했기 때문에 각자가 만든 산출물에 대한 이해가 부족했습니다.
• 와이어프레임이 존재하지 않고 실제 앱을 참고하며 기획했기 때문에 실제로 저희 서비스에 어떤 점들이 부족할지 혹은 더 필요할지에 대한 추정이 불가했습니다. 

위를 바탕으로 기존에 초안이 존재하는 산출물은 작업을 진행했던 팀원들에게 설명을 부탁드리고, 2일차에서는 각 산출물 (요구 사항 명세서, API 명세서)를 함께 작성하면서 실시간으로 피드백을 주고 받을 수 있도록 했습니다. 기존에 요구 사항 명세가 작성이 완료되지 않은 부분들이 많았기 때문에 이를 2일 차 최우선 목표로 지정해서 함께 끝낼 수 있도록 했습니다. 데일리 스크럼을 통해 To do를 설정하고 시작했지만 실제 프로젝트 기획 진행 속도와는 간극이 있다는 것을 알게 되었습니다. 따라서 이를 3일차 To do 목록을 작성하는데 반영하여 새로운 팀원들이 실제로 끝낼 수 있는 목표를 설정하였습니다.

 

일정계획은..???

3일차에도 데일리 스크럼을 진행하고 기술스택을 정하고자 팀원들과 토의를 진행하였습니다. 어떤 기술스택을 사용할지 정확한 기준이 없어 아래를 참고하여 작성하되 실제 서비스와 개발을 고려하였습니다. 

https://stackshare.io/instagram/instagram

 

따라서 아래와 같은 기술 스택을 선정했습니다. 

• Front End : HTML, CSS, JavaScript - 팀원들이 모두 기본적인 html, css, javascript 정도는 이해하고 있고 검색을 통해 부족한 부분들을 충분히 채우면서 진행할 수 있을 정도의 기술이라 판단
• Back End : SpringBoot - 경험을 해본 팀원들이 존재했기 때문에 경험이 없는 팀원들과 함께 개발을 진행할 수 있고 그냥 SpringBoot만 본다면 러닝커브가 높지 않기 때문에 선택
• Database : PostgreSQL - 경험을 해본 팀원들은 없었지만 관계형 데이터베이스이고, 수직, 수평 확장에 용이함, 또한 사용자가 많아진다면 같은 데이터에 대한 쓰기 읽기가 많아 질텐데 MVCC를 통한 병렬적 데이터 쓰기 가능. 
• Cache : Redis - 경험을 해본 팀원들은 없었지만 사용자가 서비스를 사용할때 빨리 떠야하는 정보들을 저장하고 굳이 DB에 저장되지 않아도 되는 정보들이 서비스에 존재하기 때문에 이를 캐시를 통해 해결하기 위해 선택

실제로 개발을 진행하지 않았기 때문에 어떤 식으로 기술 스택을 정해야할지에 대한 경험을 얻은 것으로 만족해야만 했지만 어떤 이유 때문에 특정 기술을 선택하는지에 대한 이해가 늘었습니다.

 

회고

본 과정의  첫 프로젝트인 만큼 더 완벽하게 기획을 마치고 다음에 진행하는 프로젝트에서 배운 경험을 토대로 기획과 개발에 참여하고자 하는게 제 주 목표였습니다. 또한 아무리 팀이 시간 계획을 완벽히 짠다고 하더라도 끝내지 못하는 일들이 존재하기 때문에 시간 계획을 잘 세우지 않으면 프로젝트 진행 뿐만 아니라 완성도 힘들어진다고 생각했습니다.