TRACK C�

부스트캠프 웹∙모바일 6기 네트워킹데이

​

좌충우돌 실시간 �팀 협업 플랫폼 개발기

Web29_BoostTeams

강민지. 이명재. 이원주. 장수용

목

차

소

개

- WEB29_SCC

BoostTeams는 Microsoft Teams에서 영감을 받은 팀 커뮤니케이션 플랫폼입니다.

팀 관리�팀/구성원 관리 기능

팀 보드

팀 공유 보드 기능

팀 일정�팀 공유 달력 기능

팀 채팅�팀 실시간 채팅 기능

소

개

1. 6주 동안 달리기 위해선 휴식이 필수
• 휴식을 권장하기보다는 강요하는 분위기 "쉬면서 하세요~"
• 50분 개발, 🌟 10분 휴식 🌟
2. PR 마감시간 준수
• 데일리 스크럼, 마스터 클래스, 이슈 토론 등 다양한 변수 존재
• 매주 회고 후 9시 → 10시 → 12시 → ... 로 변경 중
3. 소통을 위한 노력
• Daily TMI: 매일 스크럼 전에 본인의 TMI 한가지씩 공유
• 금지어 지정
• 전 다 좋아요~ ❌
• 아무거나 상관없어요~ ❌
4. 주간 스프린트 회고
• 한 주를 되돌아 보는 시간
• 개발에 대한 회고 보다는 그라운드 룰에 대한 회고 중심으로

협

업

• 팀 그라운드 룰

을 위한 노력

• Github 프로젝트 활용

전체 프로젝트 진행 상황 관리

Epic 단위

협

업

을 위한 노력

• Github 프로젝트 활용

Epic 각각의 진행 상황 관리

협

업

을 위한 노력

협

업

을 위한 노력

• PR 리뷰와 아침 스크럼

PR에 리뷰를 남기고

이를 바탕으로 스크럼 진행

​

단위 서비스 개발기

• 여러 기능에서 공통으로 필요한 정보

1. 현재 접속한 나의 정보 전역적 사용

2. 팀 유저 정보 전역적 사용

상태관리 라이브러리의 필요성을 인식

​

• 왜 Recoil을 선택했는가?

1. Props Drilling에서 탈출

2. ‘React’스러움

React Hook API와 비슷한 사용법

React Suspense와 잘 어울림

3. 낮은 Learning Curve

Boiler plate가 적음 -> 바로 사용 가능

팀

• namespace / room

nsp: /team-1

room: board

socket userB

room: chat-1

socket userC

room: chat-2

socket userD

socket userE

socket userA

단위 서비스 개발기

팀

socket userF

socket userG

room: users

…

nsp: /team-2

room: board

socket userI

room: chat-3

socket userJ

socket userK

socket userL

socket userH

socket userM

socket userN

room: users

socket userO

• custom team route
• 팀 내부 서비스인 유저 온라인 상태, 보드, 채팅 기능을 이용하기 위해서는 팀별 소켓 연결을 유지하여야 함
• nav바에서 팀을 변경하면 소켓 연결이 변경되어야 함
• 각각의 기능 페이지에서 소켓을 연결하는 것은 중복된 코드 발생 & 유저 온라인 상태 유지 어려움
• 소켓의 연결/해제는 어디서 수행해야할까?

단위 서비스 개발기

팀

상위 path가 /team/:teamId와 일치하는 경우 custom route인 TeamRoute를 거쳐가도록 구현

TeamRoute에서 teamId에따른 소켓 연결

why redis ?

• 실시간 서비스 채팅, 보드의 특성상,

1. 데이터 처리 요청이 엄청 많다!

2. 빠른 데이터 처리가 요구된다!

3. 자주 변경되지 않는 데이터, 중복되지 않는 데이터이다!

​

• 어떻게 해야 데이터를 빠르고! 정확하게! 처리할 수 있을까?

1. Redis는 In-Memory 저장 방식

MySQL보다 데이터 처리 속도가 빠르다

2. Redis는 Key : Value 구조

팀 단위 서비스에 적합한 데이터 구조 ( 팀 id : 팀 데이터 )

=> Redis를 도입하자!

실

시

서비스 개발기

간

실

시

서비스 개발기

간

실

시

서비스 개발기

간

{

“포스트잇 개수”: 120;

“초당 메시지”: 120;

}

실

시

서비스 개발기

간

{

“포스트잇 개수”: 40;

“초당 메시지”: 40;

}

실

시

서비스 개발기

간

실

시

서비스 개발기

간

실

시

서비스 개발기

간

Performance Improvement

​

Problem#1: Socket Event가 너무 많이 발생한다.

Problem#2: 데이터가 늘어날 수록, Socket Event 처리 시간이 길어진다.

Problem#3: 서버를 살 돈이 없다. (성능 === Money)

실

시

서비스 개발기

간

Problem#1: Socket Event가 너무 많이 발생

Drag Event가 발생할 때 마다 Socket Event를 전송

실

시

서비스 개발기

간

Solve#1: Throttling으로 Socket Event 양을 줄이자

특정 시간 간격으로 Socket Event를 전송하자

실

시

서비스 개발기

간

더 고민할 문제: Throttling 시간�

if 목표 동접자 수 == 10

한 사람 당 보낼 수 있는 최대 메시지 개수 = 30 / 10 = 3

Throttling 시간 = 1 / 3 sec

​

실

시

서비스 개발기

간

더 고민할 문제: UX�throttling을 적용하면, 사용자가 많아도 소켓 요청량을 줄일 수 있음�

하지만,�사용량이 적어도 소켓 요청량을 줄임 -> 사용자 경험 악화

�사용자 수에 따라, 실시간으로 throttling 정도를 조절할 수 있으면 좋겠음

실

시

서비스 개발기

간

Problem#2: 데이터가 늘어날 수록, Socket Event 처리 시간이 길어진다.

​

데이터 개수가 늘어날 수록, 업데이트할 데이터 Search가 느려진다.

​

기존의 Array.find()에서 Custom Binary Search로

​

O(n) => O(log(n))으로 개선!

실

시

서비스 개발기

간

Solve#2: Search 알고리즘을 개선하자

실

시

서비스 개발기

간

Solve#2: Search 알고리즘을 개선하자

실

시

서비스 개발기

간

Race Condition

​

Problem#1: 포스트잇을 동시에 Drag

​

Problem#2: 포스트잇을 동시에 Update

실

시

서비스 개발기

간

whoIsDragging, whoIsUpdating 속성을 일종의 ‘Lock’으로 사용

동시 접근, 동시 수정 방지 & 사용자 경험 개선

실

시

서비스 개발기

간

더 고민할 문제

​

whoIsDragging, whoIsUpdating은 not atomic operation�-> lock, unlock이 socket 성능에 영향을 받음

-> socket 최적화

CRDT ?

결

론

Issue

​

Problem#1: Github Action을 통한 FE Build 불가

Problem#2: 너무 긴 로딩 시간

F

E

최적화 이야기

F

E

최적화 이야기

F

E

최적화 이야기

F

E

최적화 이야기

F

E

최적화 이야기

Solve

​

#1: react-icons 패키지 통일

#2: React.lazy() 도입

#3: 그 외 Lighthouse가 시키는 대로

F

E

최적화 이야기

F

E

최적화 이야기

F

E

최적화 이야기

F

E

최적화 이야기

End of Document

Thank You.

ⓒ NAVER Connect Foundation