취업 지원을 하던 시기에 많이 받은 조언이 있다. 어필할 수 있는 경험/프로젝트는 선택에 이유가 있어야한다. 사실 부트캠프 프로젝트를 만들 때 고민할 시간이 없어서 힘들었고, 이력서를 작성할 때는 더욱 힘들었다. 돌이켜 생각해보면, 애초에 고민해서 둘 중에 뭐가 더 좋은지 판단하기엔 너무 많은 시간이 필요했겠나 싶기도 하지만 말이다.
아무튼 매 순간 선택으로 가득한 프로젝트에서도 프론트엔드 개발자가 가장 먼저 선택해야하는 것 중 하나가 브라우저가 허락한 유일한 언어 자바스크립트(파이스크립트는 언젠가..?)와 함께 라이브러리 혹은 프레임워크를 사용할 것인가. 이와 바로 맞닿아 있는 것이 SPA-MPA와 CSR-SSR이다.
SPA와 MPA
SPA와 MPA는 각각 Single Page Application과 Multi Page Application으로 브라우저가 다루는 페이지인 HTML문서가 하나인 웹 어플리케이션과 여러개인 어플리케이션을 가리킨다.
MPA는 기존 브라우저 주소창의 기능을 활용하거나, 하이퍼링크를 통해 이동할 때마다, 그에 해당하는 페이지를 그려서 보여주는 방식이다.
SPA는 주소가 바뀌어도 같은 페이지를 보여주되 주소값은 바뀌게 하고, 대신 DOM을 조작하여 같은 페이지임에도 다른 내용을 보여주는 방식이다.
SPA의 장점
- 유저의 조작에 대한 반응이 빠르다.
- 깜빡임이 없어, 좋은 사용성을 제공한다.
- 프론트엔드와 백엔드의 구분이 비교적 명확하여, 개발속도에 긍정적이다.
MPA의 장점
- 초기에 하나의 페이지만 가져오면 되므로, 로딩속도가 빠르다.
- 각 페이지 별로, JS코드의 동작과 상관없이 태그(메타태그, 시멘틱 등) 적용이 가능하여 검색엔진 우선순위를 차지하기에 유리하다.
- SPA의 동작원리를 몰라도 MPA로 페이지를 만들 수 있다.
평가
우리 프로젝트는 웹 앱으로써도 활용이 돼야하며, 사용성이 부드럽지 못하면 많은 유저 이탈을 야기할 수 있다고 생각한다. 또한 프론트엔드-백엔드 파트가 나뉘어져 있는 상태에서 백엔드가 장고로 구성될 것이므로, MPA로 개발할 경우 더 경계가 모호할 것으로 예측된다. 빠른 코드 개선 및 MPV개발이 필요한 것 역시 SPA로 개발해야하는 이유가 된다.
다만, SPA라 해서 반드시 웹 프레임워크를 사용해야하는 것은 아니다. JS로 개발하여, 어떠한 장점을 가질 수 있다면 Vanila JS SPA를 채택할 필요도 있어보인다. Vanila JS로 하면 예측되는 장점은 React를 모르는 다른 파트 개발자도 보수에 참여할 수 있을 것이다는 것과 SPA의 원리에 대한 이해, JS에 익숙해 질 수 있다는 것 정도로 보인다.
CSR과 SSR
CSR과 SSR은 각각 Client Side Rendering과 Server Side Rendering을 의미한다. CSR은 화면에 그릴 정적파일의 뼈대만 서버로부터 받아온 후 클라이언트의 브라우저가 해당 코드를 해석하면서 추가적으로 화면을 그리는 방식으로 작동하고, SSR은 코드를 해석한 결과물인 DOM트리를 형성하여 클라이언트로 전달해주는 방식으로 작동한다.
CSR의 장점
- 화면의 빠른 전환과 조작에 대한 반응을 보인다.
- 동작이 많아져도 최초 서버와의 통신 이후, 통신 횟수가 적어 비용적으로 유리하다.
- 검색엔진 우선도가 낮아, 노출을 원하지 않는 페이지에는 긍정적인 부분이 있다.
SSR의 장점
- 브라우저엔진의 동작 이전에 각 페이지의 정보가 담겨 있어, 검색엔진에 정보 노출이 용의하다.
- 처음 페이지 진입 시의 렌더링 속도가 비교적 빠르다.
평가
우리 프로젝트는 정말 많은 조작 반응이 있어야 한다. 또한, 아직 회사의 규모가 크지 않아 통신 비용에 대한 부담도 큰 고려사항 중 하나이다. 다만 검색엔진 우선순위의 경우 회사 사이트만 띄워지면 충분할 지, 웹 어플 역시 노출돼야 좋을 지 고민해볼 필요가 있다.
마무리
생각보다 이미 해봤던 것들이어서, 직관적인 내용이다. 하지만, Vanila JS로 SPA 구현하기와 React로 SSR 적용시키기는 반드시 해보아야겠다.
참고문서
