내가 생각하는 항해에 들어온 가장 큰 이유가 시작된다.
모두가 중요한 프로젝트라고 생각하고 있을 것이고, 이야기는 신중하게 진행되었다.
오늘은 룰 정하기와 아이디어 모으기, 아이디어 1차 선정을 했고, 선정된 아이디어에 대해 조사하는 시간을 가질 것이다.
룰 정하기
위와 같은 룰이 나왔다 Commit 규칙은 항해에서 주어진 규칙과 같고 GitKraken을 사용하기로 했다.
시간적 룰은 빡빡하기 보다는, 오히려 무리하는 것을 방지하고, 더 효율적인 작업이 될 수 있게끔 작성했다.
아이디어 모으기
아이디어는 자유롭게 모았다. 다들 챌린지에 걸맞는 아이디어를 내려고 시도했고, 총 6개의 아이디어가 나왔다.
나는 아이디어 내는것을 좋아해서 3개의 아이디어를 내놓았다.
교통 정보, LoL 승률 예측, 다중 플레이어 카드 게임이 내 아이디어이다.
또한 각자 사용할 수 있는 기술, 또 쓰고 싶은 기술을 작성했고, 아직 많은 조사가 이뤄지지 않아 아주 많은 기술이 나오지는 않았다.
아이디어 선정
처음에는 각자 만들고 싶은 것을 이야기했다. 하지만 한번 더 안내를 받은 후, 다음과 같은 권장사항을 따르기로 했다.
바퀴를 만들고, 차체를 만들고, 엔진을 만들어 자동차를 만드는 방식이 아닌,
보드를 만들고, 킥보드를 만들고, 자전거를 만들고, 오토바이를 만들고, 자동차를 만드는 방식을 권장한다고 한다.
우리의 주제중 위 권장사항을 따를 수 있으며, 프론트에 너무 치중하지 않아도 되고, 챌린지 스러운 주제는
다중 화상채팅 뿐이였다.
이후에는 '만약 화상채팅 구현이 안되면 어쩌지?' 라는 걱정이 생겨 planB, planA-1등 차선책까지 고려하려 했으나,
우리에게는 알아볼 시간이 많고, 일단 알아봐서 정말 불가능 할것 같다면 주제를 바꾸기로 정했다.
고로 우리의 주제는 다중화상채팅 앱을 만들고 개선시키는 것이다!
아이디어 조사
개인별로 다중 화상채팅을 만들려면 어떻게 해야 하는지, 아니면 왜 힘든지를 조사해서 아이디어 결정에 기여할 것이다.
어떻게 해야하는지를 조사하다 보면, 왜 힘든지가 자동적으로 나올 것이기 때문에 화상채팅에 대해 조사해 보도록 하자.
화상채팅에 대해 조사하니 바로 WebRTC에 대해 접할 수 있었고, 웹의 유일한 화상통화 방식이라고 한다.
WebRTC
별도의 플러그인 설치 없이 실시간으로 미디어(오디오, 비디오, 텍스트, 파일 등)를 최대한 서버를 거치지 않고 Peer간 전송할 수 있는 오픈 소스 웹 기반 기술이다.
장점: 회사들이 좋아하는 것 같음
단점: 너무나 어려움.. 깊게 파고들면 끝이 없다고들 함.
그래도 겉핥기 식으로 구현은 가능할지도..?
P2P 방식이란?
컴퓨터들이 클라이언트와 서버의 기능을 하는 네트워크이다.
웹사이트의 트래픽을 많이 낮춰준다.
서버의 종류
- Mesh : 1대1 연결에 적합한 방식, 서버 부하 줄어듦, 하지만 Client 늘어날 수록 과부하 증가
- Signaling Server
WebRTC에서 가장 기본이 되는 서버라고 할 수 있다. 서로 다른 네트워크에 있는 Peer(통신 상대의 컴퓨터를 의미)들을 연결시키기위해서는 Session Control Messages, Error Messages 등 다양한 정보가 필요하다. 결국 이 정보들이 각각의 Peer들에게 전달이 된 후 Peer 끼리 연결이 되어야 하는데, 이 프로세스를 Signaling이라고 한다. 이 정보들을 중계해주는 서버가 바로 Signaling Server이다. Signaling Server는 직접 구축해야 한다. 일반적으로 WebSocket을 사용하여 통신한다. - Stun Server
위의 Signaling Server을 이용해서 우리는 Peer간 통신이 가능하다. 하지만 통신 중간에 방화벽, NAT 환경에 놓여 있는 Peer에 대해서는 직접적인 Signaling이 불가능하다. 이때 이어 설명할 STUN Server와 TURN Server가 필요하다. STUN Server는 클라이언트 자신의 공인 IP를 알려주는 서버이다. 이를 활용하여 Signaling 하게 된다. 단순 정보 제공을 위한 서버라 트래픽이 잘 발생되지 않고, 오픈 소스 사용하면 된다. - Turn Server
앞서 말한 STUN Server를 활용하면 대략 80% 정도는 Signaling을 통한 연결이 가능하다고 한다. 하지만, 그렇지 못한 20%경우를 위해 Turn Server를 사용한다. 대부분 보호정책을 우회하기 위한 기능이다. 결국 Turn Server가 Peer간의 통신 채널을 중계하며, P2P 방식에서 벗어나게 된다. 하지만 Peer간 모든 트래픽을 중계해줘 비용이 크게 늘어난다. 즉 최후의 수단으로 사용해야 한다.
- MCU (Multi-point Control Unit) 방식
- 다수의 송출 미디어 데이터를 Media Server에서 혼합 또는 가공하여 수신측으로 전달.
- Client 부하가 크게 줄어들며, N:M 구조에서 사용 가능
- 하지만 큰 서버의 자원이 필요, 기술 난이도도 어려움
- SFU(Selective Forwarding Unit) 방식
- 각각의 Client간 미디어 트래픽을 중계하는 Media Server를 두는 방식
- 하지만 P2P 방식은 아니며 Server와 Client간 peer을 연결한다.
- 소규모 N:M 형식의 실시간 스트리밍에 적합
- MCU와 Mesh의 중간점이라고 생각하면 됨
서버의 종류부터는 아래 블로그를 참조했다.
[개발] WebRTC & SpringBoot & Vue.js를 활용한 Group Video Call 1 : 이론
WebRTC & SpringBoot & Vue.js & Simple Peer을 활용한 그룹 화상 회의 개발하기 1 : 이론
velog.io
하지만 뒤엎기로 했다 ^^
공공 데이터 셋을 이용한 티캣팅 또는 도서 서비스로 방향을 잡았다.
성능 개선이 이뤄저야 하고 팀원들에게 작업이 잘 분배 되어야 한다.
'프로젝트 > RanDrive' 카테고리의 다른 글
| Docker와 EC2 사용한 배포 (0) | 2023.10.08 |
|---|---|
| Docker 적용 (1) | 2023.10.07 |
| SA 설계 마치기 (0) | 2023.10.06 |
| 주제 정하기 (1) | 2023.10.05 |
| MSA(Microservice Architecture) (0) | 2023.10.05 |
