이찬

webRTC - 기술 선택의 이유

• webRTC는 서로 다른 네트워크 환경에 있는 사용자를 어떻게 연결할지 / 클라이언트와 서버의 부담을 어떻게 나눌지를 고민해야 하는 기술입니다.
• 클라이언트와 서버의 부담을 나누는 방법은 대표적으로 Mesh / SFU / MCU가 있습니다.
• 최대 6명이 접속해야 하는 서비스의 특성 상 Mesh / SFU 방식 중 어떤 것으로 정해야 하는 지 고민했습니다.
• Mesh 방식이 클라이언트의 부담이 크지만 서버의 부담을 크게 줄여줘서 webRTC의 장점을 가장 잘 살린 방식이라 생각했고, 실제로 서비스에서 부하가 느껴지면 SFU로 개선하기로 정했습니다.
• 화상 회의에서는 딜레이 시간이 200ms 미만이 되어야 원활한 의사소통이 가능합니다.
• 서비스 배포 후 딜레이 테스트 결과 50~150ms 정도의 딜레이가 안정적으로 나오는 것을 확인했습니다.

화상 통화 접근성 개선

• 프로젝트 특성 상 화상 통화를 사용하는 사용자를 대상으로 개발을 진행했습니다.
• 실제 서비스 배포 후, 다음과 같은 2가지 사용자 피드백에 직면했습니다
  • 미디어 장치가 없거나 사용 권한을 거부한 사용자는 서비스 이용이 불가능하다.
  • 다중 장치 이용자의 경우 서비스에서 OS의 기본 설정 장치만 이용 가능하다.
• 미디어 트랙이 없는 사용자의 경우 Offer와 Answer 과정에서 ice candidate이벤트가 발생하지 않는 문제가 있었습니다.
  • 이 경우 Data Channel를 생성하는 예외 처리 로직을 구현하여 미디어 트랙이 없는 사용자도 게임에 참가할 수 있게 개선하였습니다.
• getUserMedia는 사용자의 기본 설정된 미디어 스트림을 가져오는 한계가 있습니다.
  • 사용자의 모든 미디어 스트림을 목록화하여 설정할 수 있는 기능을 구현했습니다.

김태윤

1️⃣ Socket.io 를 선택한 이유 - 기술 선택의 이유

실시간 서비스를 구현하는 과정에서 Polling, Long Polling, WebSocket, Socket.io등에 대해 알아보았습니다.최종적으로 Socket.io를 선택하기로 했습니다.

2️⃣ 컴포넌트마다 소켓을 연결하여 발생한 에러 -> 하나의 소켓을 사용하자

3️⃣ 채팅 영역 UX 개선

기존에는 채팅 영역의 채팅 메세지들에 대해, 사용자가 최신 메세지를 바로 확인할 수 없는 상태였습니다.

즉 새로운 채팅은 계속해서 올라오는데 사용자는 이전의 채팅 영역에 머물러 있던 것이죠.