### 부캠 프로젝트 예상질문 (12/23 및 면접)

#### 나영균

- **일반**
- **무슨 기술 스택을 사용하였나요**
- 프론트엔드는 react hooks api, context api와 useReducer를 병합한 globalState와 dispatch, 또 material-ui를 사용하였습니다.
- 백엔드는 node express.js와, mysql, nginx를 사용하였습니다.
- 기타로는 socket.io와 webRTC를 data transfer로 사용하였고 docker를 환경관리 및 배포를 위하여 사용하였습니다.
- **가장 어려웠던 부분은 어떤 부분이었나요**
- 기술적인 부분은 역시 처음 접하는 webRTC라는 부분이 가장 어려웠습니다.
- 협업의 영역에서는
- **가장 어려웠던 부분을 어떻게 해결했나요**
-

- **프로젝트 / 팀**
- **프로젝트 운영 방법은 어떻게 했나요**
- **왜 이 프로젝트를 선정하였는지**
- **어떻게 이 프로젝트를 선정하였는지 (방법)**
- **팀 업무 배분은 어떻게 했나요**
- **이슈관리는 어떻게 했나요**

- **WebRTC**
- **WebRTC를 선정한 이유는 무엇인가요**
- **WebRTC에서 여러 인터넷 환경의 Bandwidth를 어떻게 측정하고 어떻게 대응했나요**
- **모든환경에서 접속이 가능한가요**
- **안전한가요**
- 브라우저의 Protection
- 어떠한 플러그인도 없는 브라우저간의 연결로 브라우저의 악성코드 방지 기술을 이용하고 유해할 가능성이 있는 애드온을 설치할 필요가 없다. 또한 브라우저의 업데이트로 webRTC의 업데이트 또한 이루어진다.

- 암호화
- WebRTC의 모든 부분에서 암호화는 필수적으로 이루어진다.
- 표준에서 권장되는 방법은 Datagram Transport Layer Security(DTLS) 핸드쉐이크의 Perfect Forward Secrecy (PFS) cipher로 key 데이터를 교환한다.
- 위의 key 데이터는 미디어를 AES key를 생성되는데 이용되는데 이 AES key를 이용해서 미디어를 암호/복호화한다.

- FE
- **리액트 상태관리는 어떻게 구성했나요**
- **컴포넌트는 어떻게 관리했나요**
- **hooks API를 사용한 이유가 무엇인가요**
- **IE를 지원하나요**

- BE / Socket:io
- **Socket.io를 선택한 이유가 있나요**
- **MySQL을 사용한 이유가 무엇인가요**
- **몇명까지 접속이 가능한가요**

---

#### 조정현

- 가장 어려웠던 부분은 무엇인가
- WebRTC의 기본 로직을 이해하는 것이 어려웠다. 영상의 P2P 전달을 하기 위해서는 거쳐야 하는 단계들이 있는데, 이 단계들의 원리를 이해하는 과정이 필요했다.

- 무슨 단계가 있는가?

- 먼저 P2P 연결을 하기 위해 클라이언트가 자신의 IP를 알아야 한다. 보통 일반적으로 클라이언트들은 NAT(네트워크 주소 변환)를 통해 공용 IP 뒤의 사설 IP를 할당받는데, 이는 클라이언트가 스스로 알 수 없다. 그래서 외부에서 이를 보고 알려주는 서버가 필요하고, 이것이 STUN 서버이다.

- STUN 서버에서는 어떻게 클라이언트의 IP를 아는가?

- 확실히는 모르지만 네트워크 3계층에서 source IP와 destination IP가 명시되는데, 해당 부분을 읽어서 클라이언트의 IP를 아는 것이라 생각한다.

- WebSocket과 Socket.io의 차이점은 무엇인가
- WebSocket은 ws URL 스키마를 활용하는 통신 프로토콜이다. socket.io는 WebSocket을 기반으로 한 라이브러리로, room과 broadcast 등 편리하게 쓸 수 있는 api를 제공한다.

- socket.io를 사용한 이유는 무엇인가?

- socket.io를 사용한 이유는 방에 대한 개념과 방에 있는 사용자 모두에게 알림을 날리는 기능이 우리가 구현하고자 한 게임과 유사하기 때문이다.

- 실시간 스트리밍에서 화질 조절은 어떻게 했는가

- 직접 하지는 않았지만 WebRTC에서 조절을 하는 것으로 알고 있다. 구현 방법에 대해 자세히 설명드려도 되겠는가?
- 해보라
- RTCP(RTP(Realtime transport protocol) Control Protocol)라는 프로토콜을 WebRTC에서 지원한다. 해당 프로토콜의 역할은 주기적으로 전송받은 패킷과 예상 패킷의 값을 송출자에게 보냄으로 패킷 유실률과 전송 속도를 전달하고, 해당 값을 전달받은 송출자 측에서 이에 맞춰 전송 속도를 조절한다.
- 게임 흐름은 어떻게 만들었는가
- mysql을 사용한 이유가 무엇인가
- 최대 몇 명의 사용자를 수용 가능한가
(node 자체에 대한 대답을 하면 될듯)
- 정확한 인원수는 모르지만 node에서는 512mb를 기본 메모리로 사용한다. 이를 설정을 변경하면서 늘릴 수는 있으나, 사용 가능한 cpu 코어의 개수가 1개이기에 근본적인 해결책은 node cluster와 같이 여러 코어를 돌릴 수 있도록 변경하는 것이 좋을 것으로 생각한다.
- node cluster로 전환되면 예상되는 문제점이 있는가
- 현재 게임룸에 대한 정보를 로컬의 socket에서 관리한다. 다른 클러스터와 공유되지 않기에 해당 부분을 redis DB와 같이 소켓 정보를 공유해서 관리하는 부분이 필요할 것이라고 생각한다.
- tcp 연결은 어떻게 연결되는가?
- tcp 연결은 어떻게 끊어지는가?
- 연결 종료를 선언하거나, 일정 시간 아무런 패킷이 도착하지 않을 때 연결을 종료한다.
- socket.io가 끊어지는 조건은 무엇인가?
- tcp 연결 종료와 동일한 것으로 알고 있다.
- 사용자 간의 udp 연결을 지원하는데, udp와 tcp의 차이점은 무엇인가?
- udp 연결에서는 정보 전달의 순서와 도달에 대해 보장할 수 없다. 그렇지만 이에 반해

#### 권기웅

- 일반
- 프로젝트에 대해서 소개해주세요
- 레크레이션 게임인 몸으로 말해요를 영상 스트리밍과 실시간 채팅을 통해 구현한 웹 서비스입니다. 간단하게 게임 방식을 설명드리자면, 자신의 차례가 되면 캠을 통해 선택한 단어를 몸으로 표현하고, 나머지 플레이어들은 그것을 보고 단어를 유추해서 채팅으로 맞히는 방식으로 진행된다.

- 어떤 기술 스택을 사용하였나요?
- 프론트엔드: react hooks를 사용해서 컴포넌트를 구현했고, context api와 useReducer, useState등을 통해 상태를 관리했습니다.
- 백엔드: node express프레임워크를 사용해서 백엔드 서버를 구축했고, DB로는 MySQL을 사용했습니다.
- 실시간 데이터 통신: 실시간 영상 스트리밍을 구현하기 위해서 WebRTC를 사용했고, 채팅과 WebRTC초기 데이터 교환을 위해 socket.io를 사용했습니다.

- WebRTC를 선택한 이유가 무엇인가요?
- 저희가 실시간 영상 스트리밍을 구현하기 위해서 조사를 해본 결과, 가장 대표적으로 나온 기술이 WebRTC였습니다. 그만큼 참고할 수 있는 자료도 굉장히 많았습니다. 또한 아자르나 구글의 행아웃등 대형 프로젝트에서 이미 WebRTC를 채택해서 사용하고 있었기 때문에, 기술의 신뢰성또한 이미 검증된것이라 생각하여 WebRTC를 선택하게 되었습니다.

- socket.io를 선택한 이유가 무엇인가요?
- socket.io를 선택한 이유는 3가지가 있습니다.
- 첫번째는 node에서 socket통신을 구현할 수 있는 가장 유명한 라이브러리이고 참고 자료또한 매우 많았기 때문입니다.
- 두번째는 socket.io에서 자체적으로 room이라는 개념을 제공하기 때문에 저희가 직접 구현을 할 필요없이 room별로 채팅 및 게임을 구현하기 용이했기 때문입니다.
- 세번째는 기본적으로 socket.io는 websocket을 이용해 실시간 통신을 진행하지만, websocket이 지원되지 않는 브라우저에서도 폴링과 롱폴링 방식을 이용해서 실시간 통신이 가능하도록 내부적으로 구현되어있습니다. 따라서 사용하는 입장에서 크로스브라우징을 신경쓰지 않고 편리하게 개발할 수 있다는 장점이 있었습니다.

- 가장 어려웠던 부분은 어떤 것이었나요?
- 개인적으로 이번에 프로젝트를 진행하면서 어려웠던 부분은 2가지가 있었다.

- 첫번째는 저희 게임에는 실시간 영상 스트리밍 기술이 필요했기에 그것을 구현하기위한 기술인 WebRTC를 이해하고, 공부해서 저희 프로젝트에 녹여내는 부분이 어려웠다.

- 두번째는 저희 게임이 실시간성 게임이기때문에 게임 진행중에 이탈하는 유저에 대한 처리가 매우 중요했고, 그 부분을 처리하는것이 까다로웠다.
- 가장 어려웠던 부분을 어떻게 해결했나요?
- 첫번째 : PDF를 보면서 WebRTC통신 원리 설명. 로직을 이해한 뒤에 1:1통신 방식에서 우리 게임에 필요한 형태인 1:N방식으로 로직을 변경했다.

- 두번째 : 유저 이탈을 처리하는 과정에서 고려해야될 부분은 2가지가 있었다. 유저가 이탈하는 시점*과 이탈한 유저의 타입*에 따라 다른 예외 처리를 해줘야 했다. (wiki보면서)그래서 저희는 먼저 게임의 진행 상태에 대해서 명확하게 정의를 해줬다. 그리고 게임 진행 상태와 이탈한 유저의 타입을 고려해서 예외처리를 어떻게 해줘야할 지 정리했다. 그리고, 유저의 이탈이 발생하는 상황이 굉장히 다양했는데(뒤로가기, 브라우저 종료, 새로고침등) 이러한 이탈 상황을 감지하는 핸들러마다 이탈에 대한 처리 코드를 넣게 될 경우 유지 보수성과 로직의 복잡도가 증가할 것이라고 생각되었다. 저희가 찾아낸 해답은 기본적으로 client는 server와의 socket연결을 유지하고 있는 상태이기 때문에 이탈할 경우 disconnecting이벤트가 호출된다. 그래서 유저 이탈을 처리하는 코드를 disconnecting핸들러쪽에 넣어서 통합적으로 처리할 수 있도록 구현했다.

- 프로젝트 / 팀
- 왜 이 프로젝트를 선정하였는지
- 부스트캠프에서 공부하면서 경험해보지 못했던 도전적인 기술을 담고있는 주제를 선정하고 싶었다. 팀 회의를 통해 나온 주제가 "영상 스트리밍"이었고, 이를 게임과 접목시키면 재밌고 도전적인 주제의 프로젝트를 진행할 수 있을 것 같아서 선정하게 되었다.

- 팀 업무 배분은 어떻게 했나요?
- 저희는 회의를 통해 주 단위로 목표를 세우고 그 목표를 달성하기 위해서 어떤 기능들을 구현해야 하는지 목록을 도출했다. 그리고, 팀원마다 자신이 맡고싶은 기능을 담당해서 개발하는식으로 진행했다.

- 협업은 어떤식으로 진행했나요?
- 저희가 협업을 해본 경험이 많이 없기도했고, 또 저희 프로젝트의 주요 기능들이 굉장히 덩어리가 컸기 때문에, 처음에는 4명이 함께 페어프로그래밍을 진행했다. 그 과정에서 팀원 모두가 프로젝트의 핵심 로직을 이해할 수 있었다. 이후에는 기능의 크기에 따라서 2인 페어프로그래밍을 하거나 1인으로 개발을 진행했다.

#### 장기원

- 어떤 기술을 사용했나?
- FE: react hooks를 사용했으며 context api와 hooks에서 제공하는 useReducer를 사용하여 상태관리를 했습니다.