기술 선정 이유

• 아토믹 디자인

리액트는 컴포넌트를 중심으로 만들어진 라이브러리로, 컴포넌트의 재사용성이 매우 중요하다.

개발 중에 공통으로 사용되는 컴포넌트를 빼야 하는데, 개발 중에 일일히 작업하는 것이 어렵다고 판단이 되었다.

그래서 Top-bottom 방식이 아닌, bottom-top 방식으로 개발 초기 단계에서 재사용 될 컴포넌트를 분석하고 조립하는 방식을 찾고 있었고, 아토믹 디자인이 이와 매우 부합하였다.

• Storybook

  컴포넌트 개발 중에 현재 이 컴포넌트가 어떤 UI를 가지고 있는지, props에 따른 렌더링을 어떻게 되는지, 이벤트가 발생했을 때 변화는 어떠한지 확인 하기 위해서 실제 상태를 설정하고 실제 렌더링 영역으로 호출하여 확인을 하여야 했습니다.

  이런 과정에서 컴포넌트와 상태에 따른 의존성이 생기어 그 컴포넌트만을 파악하기 어려웠다. 그래서 컴포넌트 뷰를 개발할 때 다른 관심사를 분리 하여 view 개발에 집중 할 수 있도록 해주는 도구인 storybook을 사용하게 되었습니다.

• mongoDB

  서비스에서 대부분 read/write 동작으로 구성이 되어 있다. 그렇기 때문에 DB에서 빠른 read/write 를 지원하는 것을 선호하였다. mongodb는 RDBMS에 대비하여 key,value 를 사용하여 빠른 속도를 제공하고 있다. 그리고 검색 중에서 정규식을 사용 한 검색도 가능하기 때문에 검색 필터링에 유용하게 사용 할 수 있을 것이라고 판단하였다.

  RDBMS와 달리 견고한 스키마 구조가 없기 때문에 개발에 유동적으로 대응 할 수 있다는 장점을 가지고 있다. 그래서 개발 초기에 스키마 구조를 추상적으로 구현하여 에자일에 가까운 개발을 할 수 있을 것으로 기대 하고 있다.

• Styled components

  컴포넌트 재사용이 용이하다

  아토믹 디자인 패턴을 도입하면서 한 Atom 컴포넌트가 가진 스타일 속성을 상속받아 새로운 컴포넌트를 만들어야 하는 상황이 많습니다. 이렇게 생성되는 컴포넌트를 쉽고 직관적이게 만들 수 있어서 도입했습니다.

  Style 속성을 props로 전달할 수 있다.

  컴포넌트가 가지고 있는 고유한 스타일 특성을 props로 전달해서 수정하면 코드가 직관적이고 재사용성이 높아지기 때문에 도입했습니다. 또 동적으로 스타일이 바뀌는 상황도 css 로 스타일 하는 것 대비 잘 표현할 수 있어서 도입했습니다.

• Typescript

  JS로 대규모 웹 어플리케이션을 개발할 때 종종 경험하는 어려움 중 하나는 바로 여러 모듈에 걸쳐있는 객체의 리팩토링 작업이다. 개발 중에 테스트를 통해서 발견할 수 있다면 다행이지만, 프로덕션 레벨에서 발견되면 장애로 이어진다. 타입스크립트를 사용하는 경험자들이 뽑는 타입스크립트의 가장 큰 장점 중 하나는 리팩토링의 용이함이다. 사전에 정의된 객체의 인터페이스를 여러 모듈에 걸쳐서 빈틈없이 적용해두었다면, 인터페이스 정의 한군데만 수정해도 해당 객체의 수정된 부분이 사용되는 모든 파일에서 경고를 띄워주고 컴파일도 되지 않는다.

  특히 어플리케이션의 상태관리를 할 경우 하부 State 객체들이 여러 React 컴포넌트에서 참조하게 되는데, 단순한 State 필드 이름 변경부터 실제 값의 타입을 변경하는 변경까지 TS의 도움으로 안전한 리팩토링을 진행할 수 있다.

  프로젝트 규모에 따라 타입스크립트는 도움이 될 수도, 안 될 수도 있다. 프론트엔드에서는 SPA의 코드 규모가 MPA보다 크기 때문에 정적 타이핑에 유리하며, 프로젝트가 더 대규모일수록, 그리고 더 장기간 유지보수할 가능성이 높아질 수록 타입스크립트의 장점이 부각된다.

• 배포

  • PM2

    백엔드 API서버를 쉽고 안정적으로 서비스하기 위해 도입했습니다. 사용법이 간단해서 쉽게 사용할 수 있습니다. 서비스 중 비정상적인 종료가 일어났을 때 안정적으로 재시작해 주는 기능이 강력합니다. 또 클러스터모드를 지원해서 한정된 서버자원을 최대한 사용할 수 있는 장점이 있어서 도입했습니다.

  • nginx

    저희는 서버와 클라이언트를 각각 WAS(Web Application Server)와 웹 서버로 나누어 배포하기로 하였습니다. 저희가 웹 서버를 따로 두기로 선택한 이유는 먼저 WAS가 동적인 컨텐츠만 제공하도록 하여, 서버에게 정적 컨텐츠까지 제공해야한다는 부담을 줄이기 위합니다. 또한, Webserver와 WAS를 분리하여, 하나의 WAS에 오류가 발생하더라도, 다른 WAS가 요청을 처리해주므로 서비스의 무중단 운영이 가능하다는 장점이 있습니다.

    웹서버는 주로 아파치와 nginx가 사용되는데, 저희는 nginx를 선택하였습니다. nginx는 다중 처리 모듈 방식으로 처리되는 Apache와 달리 Event Driven 방식으로 구동이 됩니다. Event Driven 방식은 모든 IO를 Event Listner에 전달하고 또 다른 요청을 받는 식이다. 이런 방식으로 운영이 되면 요청에 대한 흐름은 끊기지 않고, 응답은 빠르게 진행이 되어 1개의 프로세스로 더 빠른 작업이 가능합니다. 이 때문에 메모리를 좀 더 효율적으로 처리할 수 있게 해줍니다.

• Husky

  개발 환경에서 git hook을 손쉽게 제어하도록 도와주는 매니저이다. git hooks는 git에 관련된 이벤트가 발생 하거나 하려 할 때, 사용자가 필요한 조작을 스크립트로 작성하여 추가 할 수 있다.

  저희 프로젝트에서는 husky + lint-saged 조합으로 커밋 전에 prettier, eslint 검사를 하게 하여 코딩 컨벤션을 맞추기 위해 사용을 하였다.