네부캠 그룹프로젝트 - 1. 서비스 기획

date
Nov 27, 2022
thumbnail
slug
naver-camp-project1
author
status
Published
tags
Project
summary
네이버 부스트캠프 그룹프로젝트(깃허브 랭킹 서비스) 기획하면서 고려한 사항들
type
Post
updatedAt
Jan 23, 2023 02:52 PM
1️⃣ 배경2️⃣ 기능적인 목표3️⃣ 목표가 아닌 것4️⃣ 고려사항5️⃣ 디자인6️⃣ 그라운드룰 및 컨벤션7️⃣ 백엔드 기술스택 선정NestJSRedisMongoDBMongooseJest
boostcampwm-2022/web21-devrank

1️⃣ 배경

Github 활동을 시각화하여 제공함으로써 재미와 성취감을 더해줄 수 있는 서비스가 필요하다고 생각했다.
이와 관련한 유사한 서비스들(OPGC, CODUCK)이 이미 존재하나, 현재 서비스의 유지 보수가 제대로 이루어지지 않고 있어 Devrank 서비스를 기획하게 되었다.

2️⃣ 기능적인 목표

Github의 데이터를 기반으로 우리만의 점수 산정 방식을 설정하여 사용자들의 순위를 산정하여 보여준다.
  • 기여한 repo에 따라 commit의 중요도가 다르다고 생각했다. 따라서 기여한 repo의 크기, star 및 fork수, repo의 전체 크기 중 프로그래밍 언어의 비율 등을 반영하여 commit에 가중치를 주기로 결정했다.
국제화 기능을 통해 사용자가 영어와 한국어 중에 언어를 선택할 수 있게 한다.
  • next.js에서 제공하는 internationalized routing를 사용한다.
  • header에 언어를 설정할 수 있는 svg 아이콘을 두고, 클릭 시 한국어 또는 영어를 선택할 수 있도록 한다. (기본언어는 한국어)
사용자의 github 관련 정보를 통합적으로 제공한다.
  • 프로필 사진, 아이디, 이름, 위치, 팔로워 수, 팔로잉 수, 소속, 링크, organization, pinned repository
순위를 여러가지 기준으로 필터링하여 보여준다.
  • 지역별, 프로그래밍 언어별, 랭크별

3️⃣ 목표가 아닌 것

수동 회원가입 기능은 제공하지 않는다.
  • 서비스의 타겟을 Github 유저로 제한하므로, 굳이 수동으로 정보를 입력하는 회원가입은 제공하지 않아도 된다고 판단했다.
그룹 프로젝트 실제 개발 기간이 4주 뿐이므로 아래 기능들은 여유가 있는 경우 혹은 그룹 프로젝트 기간이 끝나고 구현하도록 한다.
  • 모바일(반응형) 대응
  • 사용자 검색 시 자동 완성 및 최근 검색 내역
  • 커뮤니티 기능
  • 이력서 관리 기능

4️⃣ 고려사항

  • Github Oauth 로그인 시 private repository 접근 동의 여부를 사용자가 선택하게 한다.
  • 클라이언트와 백엔드API 서버 사이의 인증은 JWT를 사용한다
  • 정보 제공 서비스인만큼 SEO가 중요해보인다. 따라서 초기 로드속도에 이점이 있어야 할 것 같아 (SSG, SSR) 도입이 필요해보인다.

5️⃣ 디자인

한 주의 기획 기간이 참으로 힘들었다. 특히 figma로 디자인을 뽑는 작업이 가장 어려웠던 것 같다. 그래도 혼자가 아니라 팀원들과 즐겁게 떠들면서 함께 밤샘을 하니 죽을만큼 힘들 지는 않았다.
notion image
notion image

6️⃣ 그라운드룰 및 컨벤션

  • Issue 템플릿을 이용하여 Issue 형식을 통일
  • PR 템플릿을 이용하여 PR 형식을 통일
  • develop 브랜치의 protection rule
    • 직접적으로 develop 브랜치로 push되는 commit들을 방지한다
    • 팀원 3명 중 2명이 Approve를 해야 Merge가 가능하다
  • 코드에 대한 컨벤션은 prettier와 ESLint를 통해 충분히 커버가 가능했다. 그 외 디테일한 네이밍 규칙은 따로 정했다.
  • 일정 관리를 위해 repo와 jira, slack을 연동하려 했지만, 네부캠측에서 권한을 열어두지 않았다. 따라서 그냥 Github Project를 통해 하기로 했다.
  • Github Actions를 이용해 PR에 self-assign이나 label, Project에 추가하는 등 번거로운 작업들을 자동화한다.

7️⃣ 백엔드 기술스택 선정

NestJS

  • 관련한 미들웨어를 모두 구현해야하는 Express에 비해 프레임워크가 내장하고 있는 자체 기능들(Guard, Interceptor, Pipe, Filter 등)이 편의성을 많이 제공해준다. 따라서 비지니스 로직에 집중이 가능하다.
  • 프레임워크가 제한해주는 구조가 협업 시 코드 파악을 용이하게 해준다.
  • 기본적으로 타입스크립트 기반이기 때문에 객체지향이 제공하는 장점을 최대한 활용할 수 있다.

Redis

  • 인메모리 DB로 디스크I/O에 비해 병목이 적다.
  • TTL 기능이 refresh token의 만료나 API 캐싱에 유용하다고 생각된다. 단순히 서버측 메모리에 저장하는 것보다 scale-out시 공유가 편하다.
  • 무엇보다 여러 자료구조를 지원한다. 따라서 비지니스 로직에 집중이 가능하다.

MongoDB

  • Github 유저 정보를 보면 company, location, email 정보 등 사용자마다 갖는 정보의 구조가 다르다. 따라서 스키마리스한 구조가 적합하다.
  • 각 유저의 데이터 사이의 연관 관계 및 종속 관계가 존재하지 않는다. 즉 정규화가 필요하지 않다.
  • 트랜잭션을 지원한다. 따라서 ACID 보장이 RDBMS와 같이 보장이 가능하다.차후에 수평 확장의 가능성이 RDBMS보다 편리하다.
  • replica set을 통한 고가용성도 좋아보인다. 물론 mysql도 replication이 있지만, 샤딩같은 수평 확장에서 상대적으로 불편하다.

Mongoose

  • MongoDB와 가장 호환이 잘 되는 ORM 프레임워크라 판단했다. TypeORM은 MongoDB 버전에 따라 호환성 이슈가 존재한다고 한다.
  • Prisma는 GraphQL과의 호환성을 강조해서, 굳이 안전성이 입증된 Mongoose의 대안으로 선택할 필요성을 느끼지 못했다.

Jest

  • 팀원 모두가 테스트 프레임워크로 Jest를 사용했던 경험이 있다. 평소 쓰던 도구에 대한 익숙함에서 오는 생산성, 다른 프레임워크를 학습하는 데 드는 비용을 감수하면서 굳이 다른 테스트 프레임워크를 선택할 필요성을 느낄 수 없었다.