항해99 14기 실전 프로젝트
BE : 신동현 박다솜 변희준 정종현 / FE : 신주영 신희제 조현정
DE : 임현서

23.05.19 ~ 23.06.29

• 1차 릴리즈 : 23.06.17
• 2차 릴리즈 : 23.06.26
• 3차 릴리즈 : 23.06.29

모여서 각자 코딩, `모각코`라는 말이 생겨날 정도로 개발자들에게 중요한 문화로 자리 잡은 함께 모여 코딩하기 코드 리뷰를 조금 더 재밌게, 색다르게, 더 편하고 쉽게 할 수는 없을까? 도대체 모각코 어디서 구하지? 온라인 모각코 서비스 플랫폼 `모각코 ON:`에서 모든 것이 가능하다구 😀 내 근처에 있는 이웃 개발자들과 온라인에서 모여서 각자 코딩하고 정말 맘에 드는 친구가 생겼다면 집 앞 카페에서 슬리퍼 신고 만나 편하게 코딩해보자구!! 커뮤니티 문화가 중요한 개발자들의 편안한 코드 모임을 위해 개발자의, 개발자에 의해, 개발자를 위해, [모각코 ON:]이 탄생하였습니다.

화상 채팅 + 음성 채팅 + 일반 채팅 + 화면공유가 가능한 모각코 룸

간단한 코드를 작성하고 싶다면? 모각코 룸 내에서 코드에디터 제공

모각코 룸에서 만났는데 불량유저라면? 신고기능 혹은 헤어지기 아쉽다면, 친구 신청

내가 얼마나 공부했더라? 마이 페이지에서 볼 수 있는 나의 통계 데이터

친구와 쪽지를 주고 받으며 함께 모각코 인연을 이어갈 수 있도록 지원

모각코룸에서 만나지 않았던 유저라도 닉네임이나 친구코드로 친구신청을 할 수 있어요!

다른 사람은 얼마나 하나? 오늘의 Best 유저 조회 기능

최근 일주일 공부시간과 코딩온도(ON°)로 베스트 유저 8인을 보여줘요! 모각코온 베스트유저에 도전하세요.

• 채팅방에 입장 후 화면 공유 시 접속한 사람은 스크린으로 공유 되는 것으로 보이나 다른 유저들에겐 공유가 되지 않는 문제
  원인	스크린 publish는 잘 생성되나, 접속한 다른 사람들에게 모두 공유되는 subscribers 배열의 내부 publish는 기존 publish를 가지고 있고 업데이트를 하지 않았기 때문에 발생한 문제.
  시도	스크린 publish가 생기면 useEffect를 통해 subscribers를 최신 상태로 업데이트 함.
  해결	간혈적으로 스크린 publish가 성공했다가, 실패하는 현상이 발생함. subscribers를 업데이트 하는 useState의 setSubscribers를 함수형으로 처리하여서 배치처리를 막고 동기처리 되도록 수정하여 해결.

• 신규 실시간 알림 표시가 랜더링되고 유저가 확인하면 사라지지만, 컴포넌트가 재랜더링 되면 다시 신규 실시간 알림 표시가 나타나는 문제.
  원인	유저가 접속해서 서비스를 사용하는 동안 신규 알림이 발생할때마다 전역 상태의 배열에 추가해서 관리하고 있음. 컴포넌트 내부 상태값으로 알람 건수를 가지고 있는데 전역 상태에 있는 알림 건수를 초기값으로 세팅해주고 있었기 때문에 유저가 알람을 확인해서 내부 알람 건수 상태값을 0으로 초기화 하더라도 컴폰너트가 재 랜더링 되면 다시 내부 상태값을 전역에서 읽어오기 때문에 신규 알람이 발생한것 처럼 알람 표시가 나타남.
  시도	유저가 알람 컴포넌트에서 알람을 확인하면 내부 알람 건수 스테이트를 0으로 초기화하고 전역상태의 알람 건도 초기화 하였음. 이렇게 하자 컴포넌트가 재 랜더링 되어도 전역의 상태값도 바뀌어있기 때문에 신규알림이 발생한것처럼 표시가 되는 문제는 해결되었지만 알람을 확인하기 위해 알람 창을 열자마자 알람 내역이 사라지는 문제가 발생함.
  해결	유저가 알람 컴포넌트에서 알람을 확인하고 나면 내부 알람 건수 스테이트를 0으로 초기화하여서 신규 알림 표시 랜더링을 없애고 유저가 알람 확인창을 닫으면 전역에 저장되어있던 알람 건수도 초기화해줌으로서 해결.

• 채팅 메세지를 보낼 경우 방을 생성한 방장이 보낸 메세지는 정상적으로 보여지나, 기존에 생성된 방에 입장한 게스트가 보낸 메세지는 두번씩 보이는 문제.
  원인	게스트로 입장한 사람은 실시간 채팅 구독이 두번씩 되는 것이 원인이었음.
  시도	기존 코드에서는 의존성 배열에 ‘화상채팅방 세션 ID’값을 둔 useEffect에서 실시간 채팅 구독을 시도하고있었다. 게스트로 입장한 유저의 경우 최초 랜더링 될때와 화상채팅방이 연결되면서 화상채팅방 세션 ID이 생성될 때 총 두 번 useEffect가 실행되는 것으로 파악하고 의존성 배열의 값을 비운채로 구독을 시도하는 것으로 변경하였다. useEffect의 의존성 배열때문에 두번 구독되는 것이라고 생각하였는데 수정을 하여도 문제는 계속 되었다.
  해결	openVidu 화상 채팅 ID 값과 동일한 값으로 실시간 채팅을 구독하는 형태로 로직을 구현해야했었기 때문에 화상 채팅을 위한 ID 상태값 (mySessionId)와 그 값을 담아 실시간 채팅을 구독하기 위한 ID 상태값(openviduSessionId)을 두어 두개의 상태로 관리하였다. 둘 중 하나의 값이 존재할 경우 해당 값으로 실시간 채팅을 구독하도록 로직을 작성하였으나, 방장의 경우 화상채팅 ID 값만 존재하여 한번만 실시간 채팅을 구독하지만 방이 생성된 뒤에 입장하는 게스트의 경우 방에 입장하기위해 사용한 화상채팅 ID값과 이를 복사하여 가지고있는 실시간 채팅을 구독하기 위한 ID 상태값이 모두 존재하여 실시간 채팅이 두번 구독되는 문제가 발생하였다. 이를 해결하기 위해 방을 만든 유저인지, 게스트로 입장한 유저인지 구분하는 상태값을 두어 각각의 경우에도 모두 한번만 실시간 채팅을 구독하도록 변경하여 해결하였다.

• monaco-editor
  • 개발 공부를 하는 서비스 이기 때문에 코드 에디터의 필요성을 느껴서 도입
  • Monaco Edito,를 사용하게된 이유는 CodeMirror, Ace Editor와 같이 다양한 코드 에디터들이 있지만 우리 프로젝트는 많은 언어와 호환이되고 자동완성 기능도 적용이 되는 Monaco Editor를 선택
• char.js
  • 사용자의 마이페이지에서 모각코를 함에 있어서 동기부여를 해줄 수 있는 정보들을 시각화 해서 보여주기 위해 도입
  • 매일매일 기록되는 모각코 참여시간을 차트의 형태로 한눈에 쉽게 볼 수 있도록 하도록 결정.
  • 다양한 차트 라이브러리 중에서 최근까지 계속해서 업데이트 되고, 많은 사용 레퍼런스가 있는 chart.js가 빠른 개발 기간 내에 적용하기 좋을 것이라고 판단하여 도입함.
• react-toastify
  • 커스텀 모달을 사용해서 사용자에게 alert 와 confirm 메세지를 안내하나 사용자의 액션이 별도로 필요없는 메세지를 보여줄때는 스낵바 형태의 메세지가 필요하기 때문에 도입.
• Geolocation Api, KakaoLocal, KakaoMap Api
  • Geolocation api 를 사용해 사용자의 접속위치를 받아올 수 있기 때문에 도입.
  • 생성된 방 정보들을 지도에 표시해주기 위해 카카오 로컬과 카카오 맵 api 도입.
• redux-thunk
  • 사용자가 전역의 상태값을 바꿀때마다 해당 좌표로 접속한 동네명을 받아오는 외부 api 요청 처리가 필요했다. 매번 요청을 하기전에 다른 요청을 하는 것보다 청크로 중간에 외부 api 요청을 하는 단계를 둘 필요성을 느껴 도입.
• react-query
  • 쿼리 캐싱 처리 및 클라이언트 단에서 관리해야 할 상태값을 줄이기 위해 도입
  • 데이터 로딩, 에러 처리 등이 용이하여 유지보수가 편하여 도입
• styled-component
  • 스타일을 컴포넌트화 하여 프롭스로 값을 내려주어 조건부 스타일을 하기에 용이하여 도입.
• react-router-dom
  • React Router dom을 통해 페이지 이동을 구현하였고 outlet을 통해 전체 레이아웃을 쉽게 설정할 수 있어 도입.
• react-redux-toolkit
  • 리액트 전역 상태관리 라이브러리로 프롭스 드릴링 현상을 대비하고 전역으로 상태를 관리하기 위해 도입.
  • 리덕스 보다 설정이 간단하고, 리코일을 새로 배우는거보다 팀원 전체가 러닝커브가 짧을것 같아서 도입
• vercel
  • git 커밋을 트리거로 자동으로 빌드되고 배포되기 때문에 AWS S3 보다 배포 과정이 빠르고 용이해서 적용하였음.
  • .env등 환경설정파일을 쉽게 등록하고 관리할 수 있다.

1. webRTC - OpenVidu
2. 실시간 프로토콜 - 웹소캣, SSE
3. 코드 최적화 - redux-thunk
4. 웹사이트 최적화 - Lighthouse
5. 상태 관리 라이브러리 - redux toolkit

최적화 전	최적화 후

• 웹사이트 구현 후 라이트 하우스로 웹페이지 성능을 측정 해보았다.
• Perfomance는 웹페이지의 로딩 과정에서 발생하는 성능 지표이다.
• 사용자가 느끼기에 가장 성능의 차이가 확실하게 드러날것 같은 부분이라 빠른 기간 내에 성능 개선을 위해 Perfomance 개선을 집중하였다.
• First Contentful Paint(FCP)
  • 페이지가 로드될 때 브라우저가 DOM 첫번째 부분을 랜더링 하는데 걸리는 시간
  • 최적화 전 : 2.2초
  • 최적화 후 : 0.9초
• Speed Index (SI)
  • 페이지 로드 중 컨텐츠가 시각적으로 나타나는 속도
  • 전체적으로 더욱 빨리 로드 될 수록 개선됨
• Largest Contentfull Paint(LCP)
  • 화면 내에 있는 가장 큰 이미지나, 텍스트 요소가 랜더링되기까지 걸리는 시간 지표
  • 전체 점수에서 25%의 가중치를 가지는 중요한 지표
  • 최적화 전 : 19.8초
  • 최적화 후 : 2.5초
  • 최적화 전 헤더 백그라운드 이미지는 PNG 확장자로 용량이 비교적 큼
  • 폰트 역시 ttf로 적용되어 있어서 메인의 가장 큰 텍스트 요소의 랜더링 속도가 다소 느렸음
  • 최적화 후 헤더 백그라운 이미지를 webp 확장자로 변경하였음
  • 폰트도 woff로 변경하였으나 개선이 미비하여 다시 subset font를 적용하였다.

• 쪽지 기능 강화 (삭제 추가)
• 유저 신고 기능
• 친구 추가 강화 (채팅, 유저검색 추가)
• 관리자 기능
• 튜토리얼
• 보안 강화 - 리프레쉬 토큰
• 메인 검색 속도 개선
• 화면 공유 기능 안정성 강화
• 검색 기능 분리 - 지역, 모각코 제목
• 상태코드 이해 어려움 - 툴팁 추가
• 모각코룸 내에서 참여 인원 확인 기능
• 실시간 채팅 편의성 강화 - 욕설 필터링, 공백입력 방지
• 회원가입 인증 이메일 추가
• 디자인 라이트모드
• 반응형 웹

FRONT-END

BACK-END