🐔 나만 모른 닭

내 머리에 있는 거 뭐야? 나만 몰라?
”양세찬 게임” 혹은 “콜 마이 네임”으로 불리는 키워드 맞추기 게임!
스무고개처럼 상대 플레이어에게 질문하면서 나의 키워드를 맞춰보세요🐤
최대한 헷갈리게 답변하고 최대한 날카롭게 질문하세요!

🔗 나만 모른 닭 서비스 및 노션

🐔나만 모른 닭 바로가기🐔

🐔팀 노션🐔

🐔브로슈어🐔

📢 주요 서비스 기능

• 런닝맨에 나온 양세찬 게임(aka. call my name game)을 온라인에서도 즐길 수 있게 웹으로 구현하였습니닭🐔
• 텍스트 채팅뿐만 아니라 음성/화상 채팅으로도 서로 대화를 나누며 게임을 즐길 수 있습니닭🐔
• 게임도 하고 게시판을 이용해 다른 유저들과 소통도 할 수 있습니닭🐔
• 소셜 로그인이 있어 별도의 회원가입이 필요하지 않습니닭🐔

📽 시연 영상

⚙️ 서비스 아키텍쳐

🖌 ERD

ERD

📌 핵심 기술

• 실시간 채팅을 위한 Web Socket
  • 화상 및 음성 채팅을 위한 WebRTC
  • 다양한 브라우저 환경을 지원하기 위한 SockJS
  • pub/sub 기반의 편리한 웹소켓 관리를 위한 메세징 프로토콜 STOMP
• Refresh Token의 생명 주기 관리를 위한 서브 데이터베이스로의 Redis 사용
• Github Actions/AWS CodeDeploy를 통한 자동 배포 환경 구축
• Intersection-observer API를 사용한 댓글 무한 스크롤
• OAuth 2.0 소셜 로그인을 통한 편리한 접근성

📝 기술적 의사 결정

기술적 의사 결정

기술	도입 이유	후보군	의견 조율 및 기술 결정
Web Socket	실시간 통신을 위해 도입	Polling / Long Polling / Web Socket	- 실시간성이 중요한 서비스이므로 한쪽에서 송신을 하면 반대쪽에서는 수신만 할 수 있는 Polling 및 Long Polling은 Web Socket에 비해 실시간성이 떨어짐. - Web Socket을 사용하면 서버와 브라우저 사이에 양방향 소통이 가능함(= 전 이중 통신, 양방향 통신 (Full-Duplex)). 즉, 클라이언트가 먼저 요청하지 않아도 서버가 먼저 데이터를 보낼 수 있고 상대방의 송신 상태와 상관없이 메세지를 보낼 수 있음. 때문에 30초의 제한 시간 내에 많은 질문이 오가는 실시간 채팅이 중요한 우리 서비스에 Web Socket이 더 적절하다고 판단
WebRTC (Mesh)	실시간 화상 및 음성 채팅	Mesh / SFU / MCU	- 실시간성이 가장 낮고 중앙 서버에서 데이터 혼합 및 가공에 많은 비용이 요구되는 MCU는 제외하고 Mesh와 SFU 방식을 놓고 고민 - 서비스 특성 상, 한 게임룸의 최대 인원이 4명인 점을 고려했을 때 peer간의 직접 연결이 클라이언트에 부하를 심하게 주지 않을 것이라고 판단했고, 서버를 거치는 일 없이 바로 peer끼리 정보를 주고 받는 것이 실시간성이 중요한 게임 서비스에 적합하다고 판단
Redis	Refresh Token을 저장하기 위한 DB 선정	Redis / MySQL	- 일정 시간 이후 만료되어야 하는 Refresh Token이므로 기본적으로 데이터의 유효기간(time to live)을 지정할 수 있는 Redis에 저장하는 게 적합하다고 판단 - 토큰 생명 주기 관리에 용이한 Redis를 Refresh Token 전용 서브 DB로 선정
Github Action & AWS CodeDeploy	지속적 통합과 지속적 배포를 통한 업무 효율 상승을 위해 도입	Jenkins / Github Action / Travis CI	- 현재 프로젝트 관리를 깃허브를 통하여 진행하고 있고, 소규모 프로젝트이고 추가적인 설치 과정 없이 Github에서 제공하는 환경에서 CI 작업이 가능하기 때문에 Github Action을 사용하는 것이 용이할 거라 생각함 - 프로젝트 규모를 생각했을 때 초기 설정이 적고 편의성이 높아 리소스를 줄이는 방향으로 진행. 따라서 Github Action과 AWS에서 제공하는 Code Deploy를 이용하여 자동화 배포를 하기로 결정
Refresh Token	유저 정보 보안	클라이언트에 저장(local storage vs cookie) / 서버에 저장	- 리프레시 토큰이 클라이언트에 노출된다면 리프레시 토큰의 장점인 보안적인 이점이 없다고 판단하였고, 액세스 토큰 만으로도 서버에 리프레시 발급 요청이 가능한 로직이기 때문에 서버에만 저장하는 방향으로 의견 조율 - 리프레시 토큰을 서버(Redis)에 저장하고, 액세스 토큰 만료 10분 전에 재발급 요청을 보내는 api를 액세스 토큰을 담아 요청하는 방식으로 구현
STOMP & SockJS	텍스트 채팅 및 다양한 브라우저에서의 일관성	Only WebSocket / SockJS + STOMP	- 여러 브라우저에서 동일한 기능을 안정적으로 제공할 수 있어야 하기에 SockJS를 사용하고, 여러 방을 생성하여 그 방마다의 채팅을 관리해야 하기 때문에 Topic을 구독함으로 별도의 세션 관리가 필요없는 STOMP를 사용해 채팅을 구현하는 것으로 의견 조율 - WebSocket Configuration에서 Endpoint에 SockJS를 사용할 수 있게 설정하고, 메시지 브로커를 통해 pub/sub 엔드포인트를 설정하여 url로 간단히 공급과 구독을 적용할 수 있게 구현함. 또한 대상 Topic(게임 방)을 구독한 사람들을 대상으로 게임 진행에 관련한 메세지를 공급하는 방식으로 구현

⚽ 트러블 슈팅

자동화 배포 시 jar 파일 실행 이슈

• 문제 상황

  • EC2 인스턴스에 배포 파일이 들어가나 실행되지 않음, 우분투 서버에 들어간 배포 파일을 수동 실행시켜도 실행되지 않음

• 이유

  • EC2 로그와 Github Actions, Code Deploy내역, S3에 정상적인 저장을 모두 정상 작동 확인했으나 쉘 스크립트 로그에서 실행된 프로세스 ID가 안 찍히는 것을 확인하여 실행에 문제가 있는 것을 인식. 확인을 위해 자동 배포된 파일을 수동으로 실행해보니 실행되지 않았음. local에서 build한 파일을 서버에 올려 돌렸을 땐 정상 작동 하는 것으로 보아 배포 과정에서 파일 처리에서 문제가 생겼을 거라 추측
  • 배포 로직을 하나하나 확인해 보니 Github secret에 들어간 properties 파일이 빌드 전 들어갔어야 하는데 순서가 빌드 후 적용으로 밀려 있어서 배포할 파일에 properties가 적용되지 않았다. 당연히 properties에 들어가 있는 키들이 적용이 안 되어 우분투에 있는 배포 파일을 수동 실행시켜도 오류가 떴음

• 해결 방법

  • steps 순서를 빌드 전 github secret에 있는 properties가 먼저 적용되게 변경
  
  

동시성 제어를 위한 Pessimistic Lock

• 문제 상황

  • 최대 인원이 4명인 게임 방에서 한 자리가 남았을 때 동시적으로 입장하기를 하면 최대 인원을 넘어서 입장하는 이슈 발생

• 이유

  • 여러 개의 트랜잭션이 동시적으로 DB에 접근 후, 업데이트 되기 전 데이터를 불러와서 실행됐기 때문

• 해결 방법

  • 해당 이슈를 위해서 select for update 구문을 이용하여 특정 데이터 ROW에 대해 Pessimistic Lock을 걸어 해결
  • Optimistic Lock도 고려했지만 Optimistic Lock은 충돌이 발생할 때마다 오버헤드가 발생하기 때문에 충돌이 많을 것으로 예상되는 이번 이슈에는 적합하지 않다고 판단
  
  

비정상적으로 종료 시 새로운 방장이 업데이트 되지 않는 이슈

• 문제 상황

  • 방장이 비정상적인 요청으로 방을 나갔을 때 세션 스토리지에 저장된 방장 정보가 업데이트 되지 않는 이슈

• 이유

  • 비정상적 요청으로 방을 나갔을 경우, 게임룸의 방장 정보가 변경되는 로직보다 방장 정보를 업데이트 하는 로직이 먼저 실행되었기 때문에 발생
  • 정상적으로 방을 나갈 때에는 방장 권한 부여가 남아있는 참여자에게 전달이 잘됐는데 비정상적으로 방을 나갔을 때 같은 메소드로 방장 권한을 부여함에도 정상처리 되지 않음. 이에 차이를 비교하니 정상처리 경우 방 나가기 로직이 API로 바로 요청되어 메소드가 실행되나 비정상처리의 경우 세션 연결의 연결끊김이 감지되면 실행되는 afterConnectionClosed에 연계로 메소드가 실행되는 차이가 있었음. 해당 메소드는 DB를 변경하는 사항이 있어 @Transactional을 붙여 사용하고 있었는데, 비정상처리로 실행시 방나가기 메소드에 선행되는 afterConnectionClosed에는 @Transactional이 붙지 않아 데이터 저장이 정상적으로 처리가 되지 않았음.

• 해결 방법

  • 프론트에서 방장 정보를 불러오는 요청이 DB에 저장되는 로직보다 선행되도록 코드 순서 변경
  • 상위 메소드에 @Transactional을 붙여주어 하위 메소드에 방장을 업데이트 하는 데이터가 정상적으로 처리되도록 변경
  
  

🗨️ 유저 피드백

유저 피드백

1. 닉네임 변경
   • 기존에 닉네임을 cookie 에 담아 관리하고 있었는데 닉네임 변경 api를 호출하고 변경된 닉네임을 주기로 함
2. 카메라 기본 상태 off로 설정
   • 각각의 유저 정보를 객체로서 저장하여 요소로 가지는 배열에 유저 객체를 처음 할당할 때 카메라 On/Off를 설정하는 프로퍼티의 값을 true에서 false로 변경
3. 게임 종료 시 키워드 알림
   • 컴포넌트 최상단 scope에 키워드를 저장할 let 변수 선언 후 게임 시작 시 서버로부터 받아온 키워드 데이터를 해당 변수에 할당하여 게임종료시 해당 변수 사용하여 키워드 화면에 출력
4. 커뮤니티 페이지 카테고리 설정 방식 변경
   • 카테고리의 경우 [자유게시판]과 [내가 쓴 피드백]은 drop down으로, [내가 쓴 게시판]의 경우엔 버튼으로 따로 구성되어있어서 불편하다는 피드백을 받음
   • 모든 카테고리를 drop down으로 변경
5. 카카오톡 회원탈퇴 (서비스 연결 끊기)
   • 카카오 로그인 시 백엔드 서버에서 전달하는 토큰에 카카오 access token을 추가하고, 카카오톡 연결 끊기 api로 해당 토큰을 전송하여 서비스 연결 끊기 요청
6. 버튼 중복 클릭 방지
   • debounce와 동일한 기능을 하는 커스텀 훅을 만들어서 버튼을 여러 번 눌렀을 때 특정 시간(0.3초)동안 액션이 없는 경우 함수가 호출되도록 변경
7. 게임 플레이 시 효과음
   • howler.js 라이브러리를 사용하여 삽입한 src가 플레이되는 커스텀 훅을 만들어서 게임 중 효과음이 나오도록 변경
8. 카카오 로그인 이용시 게임룸 입장이 안되고 ‘만료된 JWT 토큰입니다 ’ 라는 메세지와 함께 튕기는 오류
   • 카카오 로그인시 이메일 허용을 하지 않은 유저들에게 발생한 문제
   • kakao developers 애플리케이션 - 카카오로그인 - 동의항목 에서 email 설정을 필수선택으로 수정

⌛ 시간이 더 있었다면 도전했을 기술들

• 대용량 트래픽 처리
• 새로고침 없이 실시간 방 리스트 업데이트를 위한 SSE
• 추가적인 소셜 로그인(네이버, 구글)
• docker를 활용한 서버 scale-out
• 무중단 배포
  
  

🛠 기술 스택

Backend Tech Stack

Infrastructure

Team Collaboration Tool

🧑🏻‍💻 개발 기간 & 조원

✔️ 2022.12.30 - 2022.02.09
✔️ 멤버 이름 클릭 시, 해당 멤버의 깃허브를 방문하실 수 있습니다.

김아영	조소영	차이진	홍윤재
SPRING	SPRING	SPRING	SPRING