기술 스택
React에서 컴포넌트는 독립적인 로직을 가지고 있어 다른 컴포넌트와 분리되어 있습니다. 따라서 프로젝트가 커질수록 컴포넌트를 특별한 요구사항에 맞게 재사용을 할 가능성이 높아집니다. 기획 단계에서 우리 프로젝트에서 재사용 할 수 있는 컴포넌트들이 많다고 판단하였기 때문에 리액트가 우리 프로젝트에 적합하다고 판단하였습니다.
우리 팀원들은 모두 지난 학습 스프린트 기간에서 타입스크립트를 경험하였습니다. 타입스크립트에 대한 공통된 의견은 환경 설정이 어렵고 타입에러가 짜증나지만 좋다 였습니다
이전 프로젝트에서 팀원들은 타입스크립트가 다음과 같이 생산성을 높여주는 것을 경험하였습니다.
- 자바 스크립트였다면 실행 후 디버깅을 통해 찾아냈어야 할 에러들을 코드 작성시점에서 미리 파악해 제거할 수 있었으며,
- 개발자가 정의한 Object Property를 코드 자동완성을 통해 빠르게 작성할 수 있었습니다. 또한 협업함에 있어 다른 팀원들이 작성한 Object Property를 쉽게 파악할 수 있을 것이라고 생각되었습니다.
위와 같은 장점 때문에 우리 팀은 타입스크립트를 프로젝트에서 활용하기로 결정하였습니다.
다른 상태관리 라이브러리인 Redux, Mobx처럼 복잡한 상태관리 구조를 가지지 않고 짧은 러닝커브를 가지고 있어 짧은 기간안에 학습과 개발을 진행해야 하는 우리 프로젝트에 적합하다고 판단되었다. 또한, 프로젝트에서는 클래스형 컴포넌트를 사용하지 않고 리액트 훅을 이용한 함수형 컴포넌트를 사용할 예정이어서 함수형 컴포넌트를 위해 탄생한 상태관리 라이브러리인 Recoil을 사용하기로 결정하였습니다.
css를 파일로 작성하여 사용하게되면
파일의 수가 기존 파일의 수에 비례하게 증가하게되어 개발하는데 큰 불편함을 발생할 수 있다고 판단하였습니다.
또한, class 네이밍에 규칙을 정하여 공통적인 class명을 피해야하는 불편함이 발생한다고 판단하였습니다.
뿐만아니라, Atomic 디자인을 사용하는 우리 프로젝트에서는 컴포넌트(파일) 하나에 역할과 책임감을 부여하며 구현을 하였기에 해당 CSS를 찾기 위해서는 컴포넌트를 찾아 수정해주면 된다는 장점이 있습니다.
React에서 사용하는 스타일링 라이브러리에는 Emotion뿐만아니라, Styled-Component가 존재합니다. 그럼에도 Emotion을 사용한 이유에 대해서는 번들링 파일 크기가 Emotion이 비교적 더 작기 때문입니다.
우리 팀원들의 주 사용 언어는Javascript이며 모두 풀스택으로 프로젝트에 참여하고 있습니다. 또한 6주라는 짧은 시간에 프로젝트를 완성해야 하기 때문에 빠르고 쉽게 API 서버를 구축할 수 있는 장점이 있으며 더불어Javascript를 사용할 수 있는 Express를 API 서버 구현을 위한 프레임 워크로 채택하였습니다.
MySQL을 Database로 사용한 첫번째 이유는 MySQL이 무료이기 떄문에 부담이 없었기 때문입니다. 두번째 이유는 팀원 모두 MySQL을 사용해본 경험이 있어 어렵지 않게 모든 팀원이 적은 부담으로 기여할 수 있을 거라 생각되어 채택하였습니다.
협업을 진행하는데 있어서 코드의 통일성과 문법적인 오류를 줄이고 코드의 가독성을 높이기 위해 사용하였습니다.
프로젝트에서 실시간 화상 채팅을 지원하기 위해 WebRTC기술을 저희 프로젝트에 도입하였습니다.
WebRTC서버를 구현하는 방법에는 Mash(P2P) , SFU, MCU 3가지 방법이 존재했습니다.
3가지 방법중 저희는 토론하여 SFU 를 선택했습니다.
MCU 방법은 성능은 3 방법중에 제일 뛰어났지만 서버의 성능이 뛰어나야 했습니다. 저희 프로젝트에서는 저사양의 클라우드 인스턴스를 쓸 예정이었으므로 MCU 방법은 저희 프로젝트에 적합하지 않다는 결론을 냈습니다.
Mash 방법은 서버가 부담하는 자원이 거의 없습니다. 따라서, 저희가 사용할 저사양 인스턴스에 맞는 방법이었지만 그 대신, 클라이언트에게 주는 부담이 어마무시하다는 것을 알게되었습니다.
저희 프로젝트는 최대 8명이 같인 방에서 화상 채팅을 진행해야 했고 Mash 방법으로는 거의 불가능하다고 판단하였습니다.
위와 같은 이유로 MCU 방법과 Mash 방법의 절충안이라고 생각되는 SFU 방법을 저희 프로젝트에 적용하기로 하였습니다.
SFU 방법을 사용하면 저사양 클라우드 인스턴스로도 충분히 괜찮은 성능을 제공할 수 있을것이라고 생각되었으며 클라이언트 부담도 크게 크지 않을것이라 판단되었습니다.
react를 사용하여 개발하면서 파일 구조 및 디자인 패턴에 고민을 하였습니다.
이전react에서 사용하는 디자인 패턴에 대해서 Container-Presentational Components Pattern이 존재하지만, Hook의 발달로 지양하게 되었습니다.
그렇다고 아무런 구분 없이 하나의 폴더에 모든 컴포넌트를 담는 것은 난잡해보이고 정리가 안돼보였습니다.
뿐만 아니라, 협업을 진행하면서 컴포넌트 파일이 팀원 각양각색의 파일로 분리가된다면 협업을 진행하는데 코드 이해하기가 어려워진다고 생각하였습니다.
때문에Atomic패턴을 적용하기로 하였습니다.
Atomic 디자인은 재사용성이 높아지고, 컴포넌트 하나 하나에 그 역할과 책임을 실을 수 있다는 장점이 존재합니다.
동시에, 파일의 수가 많아진다는 단점이 존재합니다.
우리 프로젝트에서 6주차에 유닛 테스트를 진행할 예정이다. 유닛 테스트를 하기 위해선 함수 하나 하나를 분리하여 함수 단위로 테스트를 할 필요가 있다고 판단하였습니다. 또한 Express API 서버의 모든 코드를 router에 넣게 된다면 가독성이 떨어질 것이라고 판단된다. 그리고 MVC 패턴을 적용하면 M-V-C 를 분리하여 작업 가능하기 때문에 생산성도 높아 질것 같다고 판단되어 해당 패턴을 적용하기로 하였습니다.
API는 프론트엔드 및 백엔드 에서 모두 사용되기 때문에 API를 관리를 해야 했습니다.
그래서 api를 문서화하여 관리를 해주려하였으나, 기본 WIKI에 문서화하여 관리하기보다는 api 요청에 대한 테스트가 가능한 Swagger라는 툴을 사용하기로 하였습니다.
또한 어떤 프로그램이 언어에도 사용할 수 있도록 yaml 확장자를 사용한 API 문서를 작성하였습니다.
우리 프로젝트에서 6주차에 유닛 테스트를 진행할 예정이다. 유닛 테스트를 하기 위해선 함수 하나 하나를 분리하여 함수 단위로 테스트를 할 필요가 있다고 판단하였습니다. 또한 Express API 서버의 모든 코드를 router에 넣게 된다면 가독성이 떨어질 것이라고 판단된다. 그리고 MVC패턴을 적용하면 M-V-C 를 분리하여 작업 가능하기 때문에 생산성도 높아 질것 같다고 판단되어 해당 패턴을 적용하기로 하였습니다.
깃 전략