기술 선정 이유

• TypeScript
  • 예측하기 어려운 오류들을 컴파일 단계에서부터 확인하여 오류 발생 방지
  • 동적 타입이 아닌 정적 타입 지원
  • 강력한 도구 지원 → 인텔리센스, 코드 어시스트, 타입 체크, 리팩토링
• ESlint, Prettier
  • 협업과 분업 간에 코드 포맷의 통일화 및 가독성 증가
• React
  • 유저와 상호작용이 많은 프로젝트다 보니 Next.js와 같은 SSR을 함으로써 얻는 것보다 잃는 것이 더 많을 것이라고 생각되어 CSR을 위한 React을 선택했습니다.
  • SSR을 하면 얻을 수 있는 이점에 대해 찾아 봤는데 초기 페이지 로딩 속도가 빠르고 검색 엔진 최적화가 된다는 이점이 있었다.
  • 우리 프로젝트에서는 페이지 이동마다 HTML 파일을 불러온다면 사용자 경험을 낮출 수 있고 검색 엔진도 고려할 필요 없어서 굳이 SSR을 할 이유가 없다고 생각했다.
• Recoil
  • 처음에는 Redux를 고려했지만 프로젝트에서 관리해야 할 전역 상태 규모가 작은데 비해 Redux의 boilerplate가 크고 러닝커브가 높은 것 같아서 제외하였습니다.
  • zustand, jotai 도 고려했지만 개발 생태계가 상대적으로 크고 러닝커브가 낮은 Recoil을 선택했습니다.
• Nest.js
  • 러닝커브가 높을 것 같다는 고민이 있었는데 맛보기로 조금 공부해보니 생각만큼 어렵지는 않았다.
  • 자유로운 Express와 달리 제약사항이 늘어났지만 통일성 생겨 다른 개발자들과 협업하기에 용이합니다.
    • 팀원들이 백엔드 경험이 많이 부족해서 코드 패턴이 중구난방일 수 있는데 Nest.js 쓰면 코드 패턴이 일치되면서 생산성을 향상시켜줍니다.
  • 공식문서가 잘되어 있고 학습 측면에서 정석적인 백엔드 구조를 배워볼 수 있다는 장점이 있다.
  • 초보자들이 써도 어느 정도 이상의 품질이 보장된다는 장점이 있다.
• MySQL
  • 데이터 무결성 면에서 메인 DB는 NoSQL보다 SQL을 사용하는 것이 좋다고 생각하였습니다.
• redis
  • 게임 방 목록, 유저 목록 등 수시로 바뀌는 데이터들을 DB에 저장하게 되면 DB I/O가 과도하게 많아지기 때문에 이런 데이터들은 메모리에 저장해야 한다고 생각했습니다.
  • 데이터를 메모리에 저장하고 조회하기 때문에 빠른 Read, Write 속도를 보장하고 또 다양한 자료구조를 지원하는 redis를 서브DB로 사용하게 됐습니다.
• prisma
  • SQL 쿼리를 직접 작성하면 작성 단계에서 오류를 확인하기 위해 매번 검사를 할 필요가 있어 생산성이 다소 낮을 것이라 판단하여 ORM 사용을 결정하였습니다.
  • sequelize, typeorm 도 고려했으나 프로젝트 기간이 짧은 만큼 러닝커브가 낮고 생산성이 높은 prisma를 선택했습니다.
• github action
  • 추가적인 설치없이 사용할 수 있으며 환경에 대한 호환성 등 Jenkins에 비해 유연성이 높은 github action을 선택했습니다.