개발일지 (12월 4주차 회고)

 

Overview

새로 입사한 회사에서 사용하는 프레임워크 및 코드 관습들을 익히는데 주로 많은 시간을 사용했었던 한 주였다고 정리할 수 있을 것 같다. 기본적으로 React + Django를 사용해서 개발하는 스타일이지만, SPA 방식이 아닌 SSR (Server Side Rendering) 방식을 주로 사용하고 있었기 때문에 React에서 손쉽게 SSR을 지원해주는 Nextjs에 대해 공부하고 이것저것 정리하는 시간을 가졌다.

 

또한 상태관리 라이브러리로는 기존에 익숙했던 Redux가 아닌 Observable 기반의 Mobx를 사용하고 있었기 때문에 이에 대해서도 공식문서를 읽으며 간단한 튜토리얼을 진행했다.

 

Nextjs & Mobx

 

Nextjs는 리액트에서 Server Side Rendering에 필요한 여러 복잡한 설정들을 대신해주는 일종의 보일러 플레이트 같은 프레임워크이다. 적용이 간편하고, 사용 방법 또한 간편하다 (공식문서를 20분 ~ 30분 정도면 읽을 수 있다.)

 

리액트를 통해 웹 서비스를 개발해 본 경험이 있다면 Nextjs를 프로젝트에 도입하는 것은 크게 어렵지 않을 것 같다는 생각이 들었다. 다만 언제 SSR을 사용할 것인지, 언제 CSR을 사용할 것인지에 대한 명확한 견해를 가지고 있어야 하겠구나라는 생각이 들어서 이번 주 내로 Nextjs + Mobx + Firebase를 이용해서 간단하게 토이 프로젝트를 하나 진행해보고 CSR과 비교했을 때 갖는 장단점을 제대로 비교해 보려 한다. 

 

Mobx는 Redux와는 다르게 간편하게 프론트엔드에서 상태 관리를 할 수 있도록 도와준다. 현재 React에서 가장 많이 사용되는 상태 관리 라이브러리는 Redux인데, Redux는 개발자들의 자유도를 최대한 지원하다 보니 처음에 Learning Curve가 꽤 높다는 느낌을 받았다. 공식적인 BoilerPlate코드가 없고, API Call 등의 Side Effect를 처리하기 위해서 Saga, Thunk와 같은 라이브러리들을 추가로 선택해야 한다. 하지만 Mobx는 이에 비해 상당히 간편한 Interface를 지원한다는 느낌이 들었다.

 

 

Front End Optimization

자바스크립트 코드의 성능

 

생각보다 자바스크립트 코드의 성능을 높이기 위해서 프론트엔드 개발자가 관여할 부분이 적다는 것을 배웠다.

스크립트 언어가 '알아서' 해주는 부분들이 많아서 무한루프를 도는 코드 등 누가 봐도 심각한 퍼포먼스 저하를 일으키는 코드가 없다면 CPU 점유율에 대해서는 굳이 신경 쓸 필요가 없고, 전력 소비량이나, 스토리지 용량에 대해서도 굳이 프런트엔드 개발자가 관여할 필요가 없는 경우가 대부분이다. 결국 퍼포먼스 최적화를 위해 신경 써야 할 사항은 다음 두 가지 사항으로 정리된다.

 

메모리

 

자바스크립트는 C나 C++처럼 메모리를 사용하기 위해서 이를 명시적으로 할당하고 반환하는 과정이 필요하지 않다. 변수를 선언하고, 그 변수의 사용이 끝나면 GC(Garbage Collector)가 더 이상 참조되지 않는 메모리들을 반환한다. 기존에는 Reference만 체크하는 방식이었기 때문에 순환 참조의 경우에는 더 이상 사용되고 있지 않음에도 불구하고 참조가 있어서 메모리 누수가 생겼지만, 이제는 Mark & Sweep 알고리즘을 통해 이를 보완하고 있어서 사실상 웬만한 경우에서는 메모리 누수가 발생하지 않는다.

 

다만 자바스크립트의 실행 컨텍스트의 특성상 Lexical Environment에 참조가 있다면 이는 여전히 지워지지 않는다. 따라서 전역 변수의 사용을 최소화하고, 클로저가 생성되었을 때 이 클로저가 참조하는 변수들에 대해서 주의하는 것이 중요하다. (어쩔 수 없이 상위 콘텍스트의 변수들을 참조하는 경우가 있겠지만, 이를 주의하여 코드를 작성하는 것과 그렇지 않은 것은 다르다.)

 

 

네트워크

 

사실상 네트워크 트래픽을 줄이는 것이 프론트엔드 개발자가 자바스크립트 코드의 성능을 최적화하기 위해 할 수 있는 것의 '전부'다. JS, CSS파일의 크기를 최소화하고 (최소화 + 난독화), 파일의 개수를 줄이기 위해 가급적 프레임워크를 하나만 사용하고, 캐시를 최대한 사용해야 한다. 특히 의도치 않게 파일 url뒤에 파라미터를 붙이는 것은 캐시를 사용하지 않고 네트워크를 사용하는 일종의 '캐시 버스터'가 될 수 있으므로 사용에 유의해야 한다.