22 11 11 회의록

스크럼

오늘 할 일

• 오전에 발표 준비
  • 스크립트 작성
  • 발표 흐름 준비
• 오후에 다른 팀 설계 참고 및 피드백 작성
• 오후 발표

오늘의 한 마디

• 강수홍: 어제 의미있는 날(2000일)이여서 잘 일과 끝나고 7시 저녁에 즐거운 시간 보내고 왔습니다. 알고리즘 스터디를 있어서 그것도 했습니다.
• 김형준: 어제 끝나고 과거를 반복해버렸습니다. 저녁을 꼬들 목살에 밥 두그릇 먹고 잠깐 안피곤한거 같아서 누워서 휴대폰을 잠깐 봤다가 기절하고 눈을 뜨니 새벽 4시여서 그냥 그때 일어나서 코테 문제 하나 풀고 씻고 롤토체스 한판 돌렸습니다. 오늘은 의미있는 하루를 보내야겠네요. 오늘은 운동해야지
• 이승재: 어제는 간단한 알고리즘 문제 하나를 풀고 Nest.js 기본 강의를 들으면서 간단한 CRUD app 만드는 부분까지 공부를 해봤습니다. Nest.js 구조가 제가 어깨 너머로 배워서 써오던 Express.js 구조랑 크게 다르지 않아서 생각보다 어렵지 않았습니다.
• 최성호: 금요일 최고로 좋아

회의 내용

주말에 할 일

• 강수홍: nest.js 학습 하려고 생각 중, 할 시간이 있을까?
• 김형준: nest.js / StoryBook 학습, 인프런에서 TypeScript 강의 나머지 듣고, 코테보고 운동좀 해야겠습니다.
• 이승재: nest.js 학습, 시간이 남는다면 Storybook도 학습
• 최성호: nest.js / TypeScript => type들을 그때 그떄마다 썼어서 공부를 해보려고 한다.

발표 (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
  • 추가적인 설치없이 사용할 수 있으며 환경에 대한 호환성 등 Jenkins에 비해 유연성이 높은 github action을 선택했습니다.