🏅 최종 발표 준비

✔️ 발표 (15분)

💡 **그룹프로젝트 6주간 쌓아온 문제 해결 경험의 기승전결을 발표합니다.** 프로젝트 과정에서 있었던 팀과 개인의 핵심 경험을 중심으로 발표 내용을 정리해보세요. 청중들이 우리 팀의 문제 해결 과정과 기술적 성장을 쉽게 이해하고, 좋은 질문과 피드백이 들어올 수 있어야 합니다.

• 팀의 **문제 해결 경험**과 **기술적 완성도**에 집중하여 발표합니다.
  • 전체 과정을 모두 읊는 것이 아니라, 그 중 우리 팀의 핵심적이었던 내용을 중심으로 발표합니다.
  • 서비스의 완성도를 높이기 위해 선택한 기술의 이유, 과정에서 발생한 주요 이슈, 이슈를 해결한 과정, 새롭게 배운 점 등 기승전결을 담아보세요.
  • 짧은 시간 안에 여러분이 무엇을 위해 얼마나 무엇을 시도했는지가 보여야 합니다.
• 서비스 기획 & 기능 소개, 동작 데모 등은 발표의 맥락이 되는 내용을 중심으로 최소화하여 공유합니다.

최종 발표 흐름

• 팀소개 → 서비스소개 → FE/BE 문제해결 경험?
• 팀/서비스 소개(데모) 5분 / 기술적 문제해결 경험 10분정도 하는거 같아요(이전 기수 보니까)
  • 좋습니다.
• 주요 기능, 기술 스택, 서비스 아키텍쳐

https://www.youtube.com/watch?v=_u_GTshHPMs&list=PLzUx59pIXJDwdgQf6dNXFEOeG9792HGpX

팀 소개

• 간단한 팀원 리스트

서비스 소개

• 서비스 기획 계기
• 간단한 서비스 소개
• 데모 (영상)

⚠️ 배경 지식 너무 자세히 소개하지 말기

FE 문제 해결 경험 - 2개

1. WebRTC API 사용해서 구현하면서 어려웠던 것 모아서 정리한 다음에 적어도 좋을 것 같습니다.

   1. 상대방 스톱워치를 실시간으로 공유하기 위해 DataChannel을 이용

      예상 질문

      • 스톱워치를 프론트엔드 단에서 관리했을 때의 자원 소모?
      • 스톱워치가 업데이트 될 때마다(1초 마다) dataChannel send를 보내는 것의 부담?
        • 테스트 결과 Chrome Performance Monitor 기준, 약 1~2%의 CPU 사용량 증가 외에 별다른 자원 소모가 보이지 않음 → 더 테스트해보기

   2. 저희 WebRTC 처음 써보는 것 강조

   3. 피어 커넥션 메모리 누수

   4. 카메라⋅마이크 자원 소모 → 카메라는 꺼두는 게 낫다.

      • 기존 방식은 브라우저 탭(OS 상태바)에 카메라가 사용 중이라는 표시가 계속 나타남 (카메라 off인 상태여도) 그에 따른 심리적 압박감 → UX 개선
2. 카메라⋅마이크 권한 부여

   1. 문제: 개발자가 아닌 사람이 봤을 때, 무슨 문제로 카메라/마이크가 안 켜지는 지 명시적이지 않음

      • 카메라/마이크 연결이 되지 않았을 때는 비디오가 하나 보이다가 연결 후 다른 사람들 비디오가 보이는 것이 연결 문제/에러라고 인식

   2. 사용자가 권한 거부 시에는 브라우저 정책으로 인해서 다시 권한 요청을 할 수 있는 방법이 없기 때문에 공부방에 입장할 때마다 권한 부여 페이지에서 경고를 보여주고, 공부방 페이지에서 사용 못 하는 디바이스가 명시적으로 표현됨

BE 문제 해결 경험 **- 2개

1. 자동 배포(서버 구조?) → 서버 구조 + github actions 자동 배포, eslint prettier 확인

   1. 이걸로 시각화하기? ← 오 좋아요

   https://www.cloudcraft.co/ → AWS/ncloud 제품은 서버만 쓰고 있어서 어려움

   • 서버 구조 먼저 그림으로 설명
   • 배포를 매번 수동으로 빌드하는데 시간이 많이 들어서 github actions으로 자동 배포 구현
   • 협업할때 코드 스타일 통일을 위해서 github actions으로 eslint, prettier 확인 과정 구현

2. 테스트 코드

   1. 테스트 코드를 적용한 배경
   2. 맨 처음 단순 모킹한 과정
   3. 근데 이게 아니라서 단위 테스트 취지에 맞게 모킹한 과정

3. turn 서버 인증?

   1. 재영님 P2P 연결이 안되서 TURN 서버 구축 → 데모때 인증정보 보안 문제 제기 → 인증정보 발급 API로 방식 변경

공통 문제 해결 경험

1. mesh → sfu

• mesh의 한계점 측정

  PeerN Camera On N: Peer N명 접속, N명이 카메라 활성화

  Peer3 Camera On 3: 연결되는 비디오스트림 트랙 12개 (업스트림 6개, 다운스트림 6개)

  Peer4 Camera On 2: 연결되는 비디오스트림 트랙 12개 (업스트림 6개, 다운스트림 6개)

  Peer4 Camera On 3: 연결되는 비디오스트림 트랙 18개 (업스트림 9개, 다운스트림 9개)

  Peer4 Camera On 4: 연결되는 비디오스트림 트랙 24개 (업스트림 12개, 다운스트림 12개)

  Peer5 Camera On 3: 연결되는 비디오스트림 트랙 24개 (업스트림 12개, 다운스트림 12개)

  Peer5 Camera On 4: 연결되는 비디오스트림 트랙 32개 (업스트림 16개, 다운스트림 16개)

  Peer5 Camera On 5: 연결되는 비디오스트림 트랙 40개 (업스트림 20개, 다운스트림 20개) → 컴퓨터 사망☠️ㄷㄷㄷ

  M1 Macbook Air 배터리 용량 50Wh… 16명 접속한 방에서 2시간 30분이면 배터리 100% → 0%

  비디오 한 명 전송 당 평균 ~1.8Mbps

  16개 스트림 업로드/다운로드 전송 시 = 58Mps

  Mesh 방식에서 네트워크 부담 문제는 아닌듯하다.

• mesh 방식에서 브라우저 부하 성능 측정 → mesh 방식에서 최대 접속자수 한계

• sfu 방식에서 브라우저 / 서버 부하 성능 측정

• sfu 단방향 5명(upload 1, download 4) 서버 성능 측정