[27] 5주차 기술멘토링 피드백 정리

• 최종발표회 준비에 많은 시간을 쏟기 보다 그 이후에 면접을 보고 개발자로 커리어를 시작하는게 중요
• 따라서 추가기능이나 구현을 먼저 하는 방향으로
• 그리고 이력서를 미리 준비할 것 ! ( 포맷 미리 잡고 준비하기 )
• 최종발표회는 기술적으로 까다롭게 물어보지 않는 편, 다음주는 이력서 작성법, 모의면접 잘 활용해서 취업에 집중 하기 !

---

• 우리 프로젝트에서 기술적으로 강점을 삼을 만할 항목을 정리해 주세요. (최종 발표 및 면접에서 프로젝트를 진행할 때 어떤 도전을 했는지 말할 수 있는 좋은 소스가 됩니다)
  • [ FE ] : 더 나은 유저 경험을 위한 무한 스크롤 기능
  • [ FE / BE] : 잦은 로그아웃 방지를 위한 Refresh Token 사용
  • [ FE / BE ] : WebSocket을 이용한 채팅 서비스 구현 및 화상 채팅을 위한 WebRTC 사용
  • [ BE ] : 서비스 로직 동시성 제어를 위한 DB 비관적 락 및 동기화 작업
  • [ BE ] : S3 엔드포인트 노출을 방지하기 위한 CloudFront 사용
  • [ BE ] : 개발 환경에 집중하기 위한 CI / CD 인프라 구축
  • [ BE ] : SockJS와 STOMP를 이용한 텍스트 채팅

---

• 프로젝트에 적용했던 핵심 기술 목록을 작성해 주시고, 각 기술을 도입하게된 의사결정 과정을 정리해주세요.구분 요구사항 선택지 핵심 기술을 선택한 이유 및 근거

구분	요구사항	선택지	핵심 기술을 선택한 이유 및 근거
FE / BE	화상 채팅 기능 구현을 위한 WebRTC (SFU / MESH / MCU)	MESH (P2P) vs SFU	실시간성이 중요한 게임 서비스임을 고려했을 때, 실시간성이 가장 낮고 중앙 서버에서 데이터 혼합 및 가공에 많은 비용이 요구되는 MCU는 제외하기로 했다. Mesh와 SFU 방식을 놓고 고민하게 됨.   나몰닭 서비스 특성 상 한 방에 최대 인원이 4명인 점을 고려했을 때 클라이언트의 부하가 심하지 않을 것이라고 판단했고, 서버에 거치는 일 없이 바로 peer끼리 정보를 주고 받기 때문에 실시간성이 중요한 게임 서비스에 적합하다고 판단했다. 또한 서버의 부하를 줄일 수 있다는 장점까지 포함하여 Mesh 방식을 선택했다.
FE / BE	유저에게 잦은 로그인을 요구하지 않기 위한 Refresh Token 사용	Redis를 활용한 Refresh Token	Access Token의 유효 시간을 길게 설정하면 유저에게 잦은 로그인을 요구하지 않아도 되지만 토큰이 탈취되었을 때 남은 유효 기간 동안 탈취자가 마음대로 사용할 수 있다는 단점이 있다. 이를 극복하기 위하여 Access Token의 유효 기간은 2시간, Refresh Token의 유효 기간은 1주일로 설정하여 Access Token이 만료되면 자동으로 재발급 해줄 수 있도록 설계했다.   Refresh Token을 저장할 DB로는 Redis를 선정했는데, Redis 자체의 TTL 기능으로 토큰 생명 주기 관리가 용이하기 때문에 선정했다. Refresh Token을 client 쪽에서는 Cookie에 저장했다. local / session stor
BE	방 입장 시 트랜잭션이 겹쳐서 최대 인원을 초과하는 이슈를 발생. 동시성을 해결하기 위한 DB락이 필요	Pessimistic Lock vs Optimistic Lock	나몰닭의 메인 서비스인 게임을 하기 전에 필수적으로 이루어져야하는 방 입장하기 로직이기 때문에 동시적으로 여러 트랜잭션이 DB에 접근하는 상황이 많을 것이라고 생각.   충돌이 발생했을 경우 오버헤드가 생기는 Optimistic Lock보다 충돌이 발생하지 않았을 경우 오버헤드가 발생하는 Pessimistic Lock이 더 효율적이라고 판단했다.
BE	웹 시그널링 서버 연결 시 간헐적으로 끊기는 이슈	synchronized	한 개의 스레드만 활용하고 있어서 동시에 메소드를 여러번 실행하면 간헐적으로 서버가 다운되는 상황이 발생. synchronized를 통한 동기화 작업으로 동시에 여러번 실행되지 않도록 수정
BE	S3 이미지 다운로드 시 엔드포인트가 그대로 노출되는 이슈	CloudFront, Route53	AWS CloudFront를 이용하요 속도 개선 및 엔드포인트를 감추는 용도로 사용. CloudFrontd의 배포 도메인을 감추기 위해서 Route53을 이용하여 도메인 변경
BE	문자 채팅을 위한 SockJS와 STOMP 사용	SockJS & STOMP, Only Websocket	메시징 전송을 효율적으로 처리하기 위해 pub/sub 구조로 메시지를 공급하는 STOMP를 사용하여 기존 WebSocket만을 사용 했을 때 보다 쉽게 메세징 처리. WebSocket을 지원하지 않는 브라우저에서도 기능을 사용할 수 있도록 도우며, 낮은 대기 시간과 크로스 브라우징을 지원하는 SockJS를 선택해서 사용

---

멘토님이 주신 질문 ( 면접 활용 )

질문1) 왜 낙관적 락 대신 비관적 락을 사용했는지?

- 우리 서비스는 여러명이 동시에 입장할 경우 무조건 충돌이 발생할 것으로 예상했다.

- 따라서 미리 락을 걸어주는게 더 적합하다고 판단.

- 충돌이 발생했을 경우 오버헤드가 생기는 Optimistic Lock보다 충돌이 발생하지 않았을 경우 오버헤드가 발생하는 Pessimistic Lock이 더 효율적이라고 판단했다.

 

질문2) 어떤 방식으로 CI/CD를 구현 했는지?그 과정에서 어떤 트러블 슈팅이 있었는지?

( - 문제를 해결했던 경험은 사소하더라도 잘 정리를 해놨다가 어필을 하는게 좋다.

 - 면접의 80프로는 문제 해결 경험을 묻는 경우이다. )

- 깃헙 액션과 AWS의 Code Deploy 를 사용하여 구현했다.

- EC2 인스턴스에 배포 파일이 들어가나 실행되지 않는 이슈가 있었다.

- 원인은 gradle.yml 파일 순서가 잘못되어 있었다. 빌드 전 암호화된 properties 파일이 들어갔어야 하는데 순서가 빌드 후에 작성되어 있었다. 당연히 properties에 들어가있는 키들이 적용이 안 되어 우분투에 있는 배포 파일을 수동 실행시켜도 오류가 떴음. gradle.yml 파일 내 스텝 순서 변경해서 이슈를 해결했다.

 

질문3) 리프레시 토큰을 어디다 저장하고 있는지 ? 

- 현재 클라이언트는 쿠키에 서버에는 Redis DB에 저장하고 있다.

- 리프레시 토큰을 클라이언트에 보낼 필요가 없다. 서버에만 저장하면 됨.

- 액세스 토큰으로만 인증요청이 가능하기 때문, 따라서 클라이언트에 리프레시토큰을 제외하고 액세스토큰만 담아주는 로직으로 변경할 것, (클라이언트 단에는 리프레시 토큰을 들고있으면 안된다. 노출이되면 안됨.) 

 

 

질문4) 싱크로나이즈드 성능 저하 문제가 있는데 최선의 방법이었는지?

-웹소켓 끊기는 이슈는 다른 원인이 있을 것이다. ( 문제 코드 전달 드리기 ) 

   

추가 조언

• 보통 서비스가 커지면 scale up 보다는 scale out을 많이 하기 때문에 도커를 사용을 권장함. ( 경험해 보기 )
• 다음주(마지막)에 취업과 관련한 정보를 알려줄 예정 - 이력서, 면접, 좋은회사 고르는 법, 책 추천 등