Inddy Buddy - 인디 게임 커뮤니티

📌인디 게임 커뮤니티, Inddy Buddy

커뮤니티 형식의 프로젝트를 진행하게 되었다. 팀은 프론트엔드 3인, 백엔드 3인으로 이루어져있고, 기본 기술 스택은 프론트엔드 REACT, 백엔드는 JAVA, SPRING을 이용할 것이다.

📖 첫 회의 내용

주제 : 게임 커뮤니티 형식

📍 필수 구현

1. 유저 간 커뮤니케이션

   1. 메시지 (실시간채팅이 아닌 채팅)

2. 게시글

   1. 게임을 선택해서 게시글올리기
   2. 카테고리 등록
   3. 댓글
   4. 좋아요 기능
   5. 정렬 기능 - New, 인기글, 활발한 글,,,이용자 많은걸로 게임을 정렬
   6. 게임 카테고리와는 별개로 게시글 태그(스토리, 등등)
   7. 태그 시스템 : 게임에 대한 의견 및 피드백 제안하는 게시글 + 유저 및 개발자와 소통하기

3. 게임 등록

   1. 기본 인디 게임 등록 (게임 주소만 보내는 것??)
   2. 유저가 원하는 게임을 등록해달라고 관리자에 요청
   3. 배포
   4. 대용량 게임 클라우드 배포
   5. 게임 카테고리별로 게임을 분류
   6. 다운로드 링크로 옮기기?
   7. 게임 찜 하기

4. 유저 기능

   1. 로그인 회원가입
   2. 유저 정보에 플레이시간 설정할 수 있게 하기
   3. 유저 정보에 게임 카테고리 선호도 설정할 수 있게 하기
   4. 유저페이지 수정 회원탈퇴
   5. 관리자 (관리자가 어떤 기능을 할 수 있는지 정해야할 듯(커뮤니티 허용 기능, 유저 강퇴 기능, 신고 관리)
   6. 유저 팔로우 언팔로우
   7. 유저 신고 기능 (메시지, 댓글, 게시글을 작성한 사람을 신고 → 유저)
   8. 유저 추천(플레이시간, 카테고리 종합해서 추천) → (MBTI 형식으로 특징, 배지)
   9. 당근지수 같은 느낌(유저 좋아요) → 기준을 명확하게 해야할 것 같음

5. 추천기능

   1. 유저 추천 기능(비슷한 플레이시간 + 비슷한 게임 선호 카테고리)
   2. 게임 추천 기능(비슷한 게임 선호 카테고리) → 관심있을 만한 항목을 상단에 보이게끔(알고리즘)

6. 수다방 자유게시판

   1. 스크롤 내리면 (’원하는 게임이 없으신가요?’ 요런느낌으로 - 그냥 의견입니다)

📍선택

1. 다크 모드(like 껌)

2. 알림기능 (공지/Hot 게시글/팔로우한 게임 소식?업데이트?)

3. 비속어 필터링 기능

   1. 비속어가 너무 많다
   2. 어렵긴 하지만 조금이라도? 너무 강한 것들만 → 채팅에서 안보이게

4. 결제 관련

   1. 결제 시스템
   2. 결제 모듈 ( 굉장히 복잡하다고 함 )
   3. 포인트 제도 도입 (웹 사이트 내 재화)
   4. 결제 서비스를 한다면 -> 카카오페이, 네이버페이, 토스 기능?
   5. 게임 리소스 판매 기능

5. 채팅 기능

   1. 1 대1 채팅
   2. 다대다 채팅

6. 활동중인 유저 보이게 → 로그인을 유저의 상태 online → 로그아웃이 되면 offline(토큰)

7. 기타 신고 (사유를 포함한) : 게임 신고 기능

8. 게임 클라우드 배포 (서버 S3)

   • 적절하게 분산해서 저장하고 유저들한테 순차적으로 다운받게하는 로직 구성 필요

📍어려운 것들(Challenge)

1. AI 기능 !!!!!
   1. 유저의 채팅을 분석해서 비슷한 성향끼리 추천?
2. 펀딩 시스템
3. 메타버스 미술관?? ?-? ZEP 같은 느낌?
4. 광고 기능 !! 광고 차단 ?! 스팸 차단 ?!
   1. 데이터 분석이 어려울 것 같다
5. 웹 재화를 블록 체인으로 하기
6. 포인트 공유해서 메타버스 형식 유저 커뮤니티 공간(2d) 생성
7. 게임 플레이 시간이 뜨도록
   1. 모든 게임과 연동을 해야되나?
8. 유저 게임 키워드 닉네임 옆에 자동으로 달기

📢 추가 토의 내용

• 게시글 작성 시 이미지 중간에 삽입하는 거

  → 서버에 어떻게 넘겨줄까 → url.creat…로 생성한 url은 임시로 탭이나 브라우저가 종료되면 사라진다.-> 텍스트 자체를 넘겨주는 방식 불가 → formdata로 만들어 이미지를 넘겨주는 방법( 이미지를 넘겨주면 서버에서 s3에 저장하고 다음에 넘겨줄 때 url을 준다 ) → 위 방법은 클라이언트에서 텍스트와 이미지 url을 따로 받게 될 것이고, 이를 어느 위치에 삽입할 지 생각해야 한다. → 삽입할 위치를 표시하는 방법이 있을 수 있다. 텍스트니까 아마 문자 형식 -> 만약 유저가 텍스트 입력 시 삽입 위치를 표시하는 문자를 입력하게 된다면 문제가 생길 수 있다 ( 원래 위치에 삽입되지 않고 다른 곳에 삽입 / 이미지를 올리지 않아 데이터를 받지 않았는데 삽입할 위치는 있는 문제) → base64로 인코딩해서 이미지를 넘겨주는 방법 -> 안해봐서 모른다.

• 로그인 이후 메인 페이지에서 팔로우 목록, 북마크 등 마이페이지에서 필요한 데이터들을 받아와야하는데 메인 페이지 마운트 될 때 요청을 한 번 보내서 받아올 지 아니면 아이콘과 같은 인터렉션이 있을 때 요청을 보내서 받아올지

  → 인터렉션이 있을 때마다 요청을 보내고 받는 것이 효율적일까? → 만약 그렇게 하지 않으면 초기상태만 보여지니까 중간에 팔로워가 추가되거나 하는 경우에는 어떻게 할 것인가? → 이전 상태를 먼저 보여주고(캐싱) 백그라운드에서 패칭을 하고 반영을 하는 방법을 해야할 것 같다 -> 그렇다면 인터랙션이 있을 때 요청을 보내고 받는 식으로 진행되어야 한다. -> 결론

• 마이페이지 타 유저 페이지 보이는 걸 어떻게 할 건지

  → 북마크만 막는다. -> 결론

• 메인 페이지에서 팔로우, 인기, 신규 게임을 요청해야할까?

  → 팔로우 : 팔로우한 목록을 보여주는 것은 어렵지 않다. → 인기 : 팔로워 수를 기준으로 -> 최대 10개 → 신규 : 신규 생성된 게임 -> 최대 10개 → 프로미스 all을 할 때 프론트는 비동기로 동시에 처리를 할 수 있는데, 서버는 비동기로 처리가 될까? 아마 그럴 거 같다 -> 자바 스레드 풀을 알아서 조정하니까 신경쓰지 않아도 된다. → 만약 동시 처리가 가능하다면 api주소를 따로 만드는 게 더 좋을 수 있다. → 각 api를 나눌 것인지 아니면, 메인 페이지에서만 받을 수 있는 데이터를 만들어서 다른 api를 구현할 것인지 → 각 api를 나눌 때 문제는 요청을 여러 번 보내야한다. (팔로우한 게임, 인기, 신규 총 3번) → 이건 promise all로 동시에 요청을 보내면 되지 않을까? → 만약 된다면, 서버에서는 동시에 들어온 요청을 멀티 스레드로 동시에 처리가 가능할까? 그렇다면 문제가 되지 않는다. 그렇지 않다면 동시에 요청을 보내는 것이 의미가 없다.(서버에서 순차적으로 처리되면 요청을 3번 보내는 거랑 다를 바가 없기 때문) → api를 따로 만들고 클라이언트에서 동시에 요청을 보내는 방식으로 진행한다. → 결론

• OAuth

  → 회원가입 로그인이 어떻게 이루어지는지 확실히 알아야한다.

• 게임 채널 내 필터링은

  → 해당 카테고리 게임들을 전체로 받고 클라이언트에서 필터링을 해서 상단에 인기 게임을 보여주는 방식으로 한다. (메인 페이지와 다르게)

• 로그아웃

  → 로그아웃을 jwt로 구현하려면 redis로 구현해서 블랙리스트에 추가하는 거다. → 이걸 안할거면 그냥 클라이언트에서 토큰 만료나 삭제하는 방식으로 구현하자. → 요청을 안한다. -> 결론

• 신고 모달

  → 내용은 포스트로 보내면 된다. 선택된 내용만 보내면 될 것 같다. → 복수 선택 불가

• 게임 등록 시 카테고리 / 신고 모달 내 신고 유형 / 게시글 태그

  → 배열에 담아서 보내준다.

• 게임 채널

  → 게시글 보여줄 때, 페이지네이션 → 페이지, 사이즈를 쿼리스트링에 담아서, 태그도 쿼리로 담아서 보낸다. (태그로 필터링 할 때)

• 개별 게시글

  -> 북마크, 좋아요, 싫어요

• 유저 팔로워, 팔로잉, 내가 쓴 글, 북마크, 게임 팔로잉

→ 탭을 누를 때마다 요청해서 받아오는 방식으로 구현

• 쪽지

→ 유저를 누를 때마다 새로운 데이터를 가져오는 방식으로 구현이 될 거 같다. // 만약 하면 알림도 이런 방식으로 구현될 거 같다. -> 알림을 할거면 소켓을 구현하는게 좋을 것 같다.

• s3에서 삭제 시 어떻게 해야하나?

→ 이미지의 경우 url을 이용해서 삭제? → 일단 delete요청으로 보내면, s3에서 삭제하는 방법이 있을 것 같다. 방법 찾기…

• 메시지는 이미지 첨부 없이 그냥 텍스트만 주고받을 수 있게 하자.

• 추가 논의 : 첨부파일, 이미지를 서버에 넘겨줄 때 어떻게 할지?

→ 드래그앤드랍을 할 때는 바로 요청이 가는 건 어떤가? -> 다른 사이트는 그렇게 동작을 한다. → 요청 시 formdata로 이미지를 넘겨주고 바로 s3에 저장 후 url을 응답으로 보낸다. -> 클라이언트에서는 그 주소로 이미지를 보여주면 된다. → 이미지를 넘겨받는 api가 필요할 거 같다. → 해결이 될 수 있을 것 같다. → 이미지는 s3에서 바로 주소를 받아와서 content에 넣으면 문제가 없다. → 첨부파일은 s3에 넣으면 주소로 응답을 받을 수 있나? → 추후 구현 단계에서 해보고 논의해봐도 늦지 않을 것 같다. 너무 깊게 고민하지 않고 추가하는 방식으로 해도 된다.

• 조회수

→ 들어올 때마다 조회수를 증가시키게 하고, 만약 필요하다면 이미 본 게시글은 조회수 증가하지 않게.. 이건 추후에 기능을 추가해도 좋다.

• 모든 게시글 조회 시 유저 정보를 그대로 객체로 담아줄까?

→ 응답 데이터가 너무 복잡할 것 같다 -> 그냥 유저 이름만 받는 걸로 -> 유저 이름, 유저 상태도 필요할 것 같다.

• 전체 게시글 조회할 때 업데이트 날짜를 사용할 것인가?

→ 이건 프론트에서 정하면 되고, 정렬할 때는 어떻게 할 것인가 → 최신순의 경우 최근에 생성된 게시글이니까… → 최신순 정렬 시에는 createdAt을 기준으로 정렬해서 넘겨준다.

• 응답을 보내줄 때 이미 있는 dto를 활용할 수 있게 하는 것 vs 응답을 좀 더 가볍고 알기 쉽게 만들기 위해서 새로운 dto를 만드는 방법 어떤 게 좋을까

→ get요청마다 응답을 다르게 하면 dto가 너무 많아진다. → 또, 응답마다 다르게 하는 것이 과연 유의미한 최적화가 되는 것일까 고민해봐야 한다. → 필드가 많이 빠지는 경우가 아니면 굳이 dto를 만들어서 응답을 다르게 줄 필요가 없을 것 같다…

⏰ 되돌아보기

회의를 진행하면서 당장 필요없는, 구현 단계에서 발생할 문제를 너무 깊게 고민하고 계속해서 의견을 제시하다보니 회의 시간이 길어져 모두 지치게 만들었다. 지금 당장 해결해야 진행되는 문제가 아니면 문제 상황만 인식하고 추후에 얘기를 해보거나 도움을 요청하는 것이 좋은 방법이라는 것을 깨달았다. 프로젝트 부팀장으로 너무 피해를 준 것 같다.