발표 (10분) 순서

1. 팀 소개

   • 안녕하세요 Web36조
   • 이게최선일까요 조의 프로젝트 자파리의 발표를 맡은 김형준입니다.
     • 저희는 발표 순서를 돌아가면서 한 명씩 경험해보기로 해서 이번 주는 제가 하기로 했습니다.
     • 이름이 이게최선일까요인 이유는 팀 이름을 계속 서로 고민해보다가
     • 팀 이름 후보들 중에서 정했어야 했는데, 이게 최선일까라는 의견이 나왔어서
     • 이게최선일까요가 되었습니다.
   • 팀원 소개
     • 저희 팀은 ~
     • 000님 이렇게 이루어져 있습니다.
     • FE, BE 나누지 않고 모두가 풀스택으로 작업하고 각각의 기능에서 협업점을 찾으려고 하고 있습니다.
   • 저희는 멘토님과의 미팅 그리고 아침 회의록을 매 번 기록하고 있는데요.
     • 아침에 시작하자마자 기획과 개발을 하면 피곤하고 지루할 수 있기 때문에
     • 어제 일과 시간 이후에 무엇을 했는지, 오늘은 어떠한 자세로 임할건지 이야기를 매번하고 있습니다.
   • 그라운드 룰
     • 그리고 저희만의 소통 규칙인 그라운드 룰을 만들어 소통을 원활히 하고자 했습니다.

2. 자파리란?

   • 다음으로 저희 프로젝트 이름은 자파리인데요,
   • 자파리는 ‘소꿉놀이’, ‘장난’, ‘장난하다’ 등과 같은 의미를 갖고 있는 제주도 말로, 얼굴을 보며 함께 게임을 즐길 수 있는 플랫폼을 지향하는 저희 프로젝트에 어울리는 단어라고 생각해 프로젝트 이름으로 정했습니다.
   • 우리 프로젝트는~ socket과 WebRTC를 활용한 실시간 음성, 화상을 지원하는 멀티 게임 플랫폼 서비스입니다.
   • 사용자 현황 분석
     • 저희가 타겟으로 하는 사용자는
       • 같이 게임을 하면서 어색한 분위기를 풀어보고 싶은 현대인들
       • 잠깐 시간을 내서 얼굴을 보며 같이 게임을 하고 싶은 현대인들
     • 타겟의 특징은
       • 게임을 가볍게 즐기고 싶어 한다
       • 상대방과 소통하며 게임하고 싶어할 것 같다
     • 타겟은 다음과 같은 문제점을 가지고 있습니다.
       • 기존 온라인 게임에서 서로의 반응을 보지 못하는 아쉬움을 가지고 있다.
       • 목소리, 얼굴을 보려면 따로 프로그램을 사용해야 되는 불편함을 가지고 있다.
     • 타겟은 우리의 서비스를 통해
       • 편한 모습으로 집에서 친구들과 모여 게임하는 상황 또는 환경에서 플레이하게 될 것 이라고 예측했습니다.

3. UI 레이아웃 설계

   • 저희는 필수 기능을 다음과 같이 정의해 봤는데요.
   • 이를 바탕으로 UI 레이아웃 프로토타입을 설계해봤습니다.
     • 우선 컴포넌트들의 위치만 고려한 레이아웃이고, 디자인은 추가적으로 진행할 예정입니다.
     • 랜딩 페이지
       • 다양한 소셜 로그인을 지원함으로써 쉽게 이용자가 회원가입과 로그인을 진행할 수 있도록 구상하였습니다.
     • 로비 페이지
       • 유저 목록, 게임방 목록, 프로필, 채팅창 등의 컴포넌트가 들어있습니다.
       • 방 생성, 초대 수락 등 여러 종류의 Modal이 필요한 페이지입니다.
     • 게임 대기 페이지
       • 로비 페이지의 방 목록에 있는 게임방에 입장하게 되면 이동하는 페이지입니다.
       • 로비 페이지와 공통되는 컴포넌트가 많고, 대기 중인 인원들끼리 화상, 음성 대화가 가능합니다.
       • 최소 인원이 채워지면 누구나 게임시작을 누를 수 있습니다.
     • 인게임 페이지
       • 양쪽에 유저들의 비디오가 위치하고 가운데에 게임, 아래에는 채팅창이 위치할 예정입니다.
       • 게임은 나중에 말씀드리겠습니다.
   • ERD
     • 유저와 친구 게임의 테이블을 바탕으로 ERD를 설계했습니다.

4. 게임 기획

   • 다음과 같이 회의를 통해 저희가 구현할 게임을 선정했습니다.
   • 게임은 처음에는 캐치마인드와 배틀쉽을 지원할 예정입니다.
     • 각 게임에 대한 자세한
       • 인원이나 진행 방식, 구현 사항과 모티브 등을 정리해 보았고,
   • 추가적으로 시간이 충분하다면 마피아 게임과 기타 미니게임을 지원할 예정입니다.

5. 컨벤션

6. 기술 스택

   • 저희는 다음과 같은 기술을 사용하고자 했습니다.

기술 고려 및 선택 이유

• 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