[전산공부] 렌더링, 그리고 리액트(React) (1)

리액트를 많이 써봤음에도 

리액트를 왜, 어째서, 무슨 이유로 사용하는가에 대해 생각해 본 적이 없다

 

그래서 차근차근 정리해보기!

 

 

1) 렌더링(Rendering)

 

렌더링이란 컴퓨터 프로그램을 사용하여 모델로부터 화면을 만들어내는 과정을 말한다

쉽게 얘기하면, 사용자로부터 Request를 받은 다음 그것에 대한 Response를 브라우저에 뿌려주는 행위임

 

브라우저 구조

간단하게 순서를 생각해보면 

로더(Loader)라는 놈이 서버로부터 전달받는 Response의 정체를 읽어낸다

그래서 이 Response가 파일인지, 데이터인지, 다운로드를 받아야하는지 등등을 파악한다

 

만들어진 트리, DOM 트리라고 함

그리고 나서 파싱(Phasing:받은 소스를 해석한다고 생각하면 됨)의 절차를 거쳐 렌더링 트리를 만든다

DOM 트리를 바탕으로 화면을 그리는 것!

얘를 로드하고나서 자바 스크립트를 다운로드 및 파싱을 한다

CSS의 경우 해당 트리에 영향을 주지 않으므로 동시에 파싱을 진행(스타일 구조체라고도 한다더라)

 

이렇게 다 하고 나면

 

이녀석이 렌더트리, 실제로 화면에 나타날 녀석들이라고 보면 된다

바로 이런 렌더트리(Render tree)가 만들어진다. 

분홍색 박스를 보면 알겠지만, 요 렌더트리에 따라 페이지에 그림을 배치한다

이 과정을 Reflow라고 한단다

 

 

 

2) 서버-사이드-렌더링 vs 클라이언트-사이드-렌더링

 

 

사족이 좀 길었다...

 

무튼, 요런방식으로 브라우저에 그림을 그리는 행위를 렌더링이라고 한다

렌더링은 렌더링 요소가 어느쪽에 있느냐에 따라 서버/ 클라이언트로 분류된다

 

이를 설명하려면 SPA(Single Page Web Application)기법에 대한 이해가 필요하다

SPA는 브라우저에 로드되고 난 뒤에 페이지 전체를 서버에 요청하는 것이 아니라, 

처음 한번만 페이지 전체를 로딩하고 이후에는 데이터만 바꿔서 사용하는 웹을 뜻한다

 

전통적인 방식은 매번 렌더링 절차를 따라 유저의 요청을 들어주는 것

이 방식을 서버-사이드-렌더링이라고 하고, 얘를 사용하면 새로고침때마다 아주 헬게이트

 

하지만 SPA의 방식을 통하면 서버는 그냥 JSON파일을 보내는 역할만 한다

그럼 HTML은 어디서 그리나?

자바스크립트가 ㄱㄱ한다.

이게 바로 클라이언트-사이드-렌더링이다 

나 중학교때만 하더라도 다음 카페 대문에 온갖 HTML 소스를 가져다 붙여서 눈내리고 반짝이게 하는 효과를 줬었지만

이제는 아주 간단하게 사용자의 복잡한 입력을 처리할 수 있기 때문에 클릭 한방으로 눈내리게 할 수 있다.

또한 데이터, UI변경, 입력값검증 등등이 모두 브라우저 단에서 처리되므로 Fat client라고도 한다

 

그림으로 보면 다음과 같다

 

 

하지만 항상 클라이언트-사이드-렌더링이 좋은 것은 아니다

물론 이녀석이 빠르다. 그러나 이녀석도 처음 구동할때에는 자바스크립트와 각종 웹서버 콘텐츠들을 가져와야 하니

초기 구동속도가 느리다는 단점이 있다.

그리고 무엇보다 치명적인 보안문제도 동시에 가지고 있다.

이쪽은 세션이 아닌 쿠키같은 가벼운 장치로만 사용자에 대한 정보를 저장하기 때문이다.

 

 

3) MVC모델

 

이렇게 장단이 엇갈리기때문에 어느 한쪽이 좋다고 하긴 힘들다

 

이를 아키텍쳐 관점에서 비교하기 위해선 MVC모델에 대한 이해가 필요하다

MVC(Model - View - Controller)패턴은 기본적인 소프트웨어 공학 모델이다.

예전에 자바 디자인 패턴이라는 책을 산 적이 있는데(단 한 글자도 안봤지만...) , 이놈이 대표적인 패턴 중 하나란다

 

 

MVC 패턴 구조도

대충 이렇게 생겼다

 

모델(Model)은 데이터베이스나 파일을 담는 친구다. 사용자가 컨트롤러를 통해 데이터를 바꾸고 싶다면, 이 요청을 모델이 듣고 컨트롤러가 시키는대로 데이터를 조절한다.

 

뷰(View)는 사용자에게 데이터를 보여주는 녀석이다. 사용자가 데이터를 조회하는 것은 항상 이녀석을 통하는 것이라 보면 된다. 뷰는 요청받은 그대로 모델에게 전달하고, 모델이 알맞은 데이터를 뷰에게 뿌려준다.

 

컨트롤러(Controller)는 사용자의 요청을 들어주는 친구다. 보통 브라우저를 이용한다면 url을 통한다. 

 

이 패턴은 존나 많이 사용된다. 지금은 구리다고 욕먹지만 한때 프론트를 장악한 Angular.js가 대표적. 장고도 그렇고.

 

 

그렇다면?

서버-사이드-렌더링과 클라이언트-사이드-렌더링은 각각 이 모델을 어떻게 구성하고 있을까?

 

 

 

자, 차이가 보이는가?

이렇게 MVC모델의 관점에서 보면 둘의 차이를 확실히 알 수 있다.

 

 

 

4) 리액트(React)

 

자, 그럼 이제 우리의 주인공이 등장할 차례다.

왜 리액트가 현시대 프론트의 1인자인가?

 

일단 재미있는 개발사 이야기를 해보자

 

왜 Ajax가 없던 시절에는 웹페이지가 허접했는가?

얘가 없던시절만 하더라도, 서버가 HTML까지 다 만들었다

요것이 앞서 말한 전통의 웹 구현방식인 서버-사이드-렌더링 되겠다.

근데 구글 형님들이 추천검색어라는 기능을 브라우저에 쳐넣으면서 Ajax라는 것을 선보였고

수많은 개발자들이 탄성을 내질렀단다.

비슷한 시기에 Jquery까지 등장하여, 웹사이트는 자바스크립트가 다 해먹는 시대가 도래했다.

 

근데 문제는 이렇게하니 보안이 숭숭 뚫려버렸단다

그도 그럴것이 온갖 코드가 클라이언트단에 다 들어가게 되었고 개발자들은 더 많은 야근을...

무튼 이렇게 보안상의 문제가 넘넘 크더란다

 

특히 MVC중 View의 문제가 컸다

이놈은 예전엔 서버에 찰싹 달라붙어있었지만, 이제 자바스크립트를 이용한 동적생성의 대상이 되었기때문에 반드시 중간 레이어가 필요하게 되었다.

 

Template Engine이는 매개를 이용하여 클라이언트에서 View를 쉽게 다루게 되었다.

 

그래서 이를 해결하고자 클라이언트-사이드-렌더링이라는 친구가 등장했다

Backbone.js나 각종 템플릿 모델같은 별별 툴들이 성행하던 이 시장을 바로....

 

AngularJS라는 형님이 천하통일했다

 

이 형님은 기존의 프레임워크처럼 DOM을 조작하거나 제어하지 않고, 데이터의 변화에만 포커싱하였다

변수만 할당하여 양방향 데이터 바인딩을 지원했고, 별도의 템플릿 코드가 없이 View와 데이터를 묶어냈다

또한 이 형님덕에 백엔드를 100퍼센트 API 서버로만 이용하여, 알앤알도 명확하게 나눴다

 

그러나 이렇게 대단한 형님도 부끄러운 부분이 있었으니...

바로 속도와 러닝커브의 문제였다.

모바일에서는 너무너무 느렸고, Directive라는 핵심 함수의 공부 난이도가 너무 높았던 것.;

그외에도 자잘한 문제들이 여럿 존재했다.

 

사실 이건 AngularJS의 문제라기보단, 웹앱의 문제였다. 

그럼에도 불구하고 개발자들은 "갓구글이 다 해결해주실거야"라는 소신을 가지고 AngularJS를 무지하게 쓰기 시작했다

그러나 너무너무너무 느리다는 단점은 계속해서 발목을 잡았다....

 

바로그때...

 

 

ReactJS

 

드디어 이 형님이 등장했다.

 

이 형님은 매우 빠르고, API가 몇개 없기 때문에 쉬웠다.

그리고 무엇보다 서버-사이드-렌더링 까지 지원하기가 용이했다.

DOM대신에 Virtual DOM이라는 요소가 DOM을 직접 계산하지 않고 내부적으로 diff만 계산하여 필요한 부분만 찾아 더니기 때문이다.

이전 포스팅에서 얘기했던 DOM Tree를 Virtual DOM이 모두 가지고 있어, 변경이 생기면 diff로 변경사항만 찾아서 던지는 것.

대신 서버-사이드에서 생성된 HTML은 이벤트 속성이 없었기 때문에 ReactDOM.render()와 같은 클라이언트-렌더링이 다시한번 필요하긴 했다

 

이렇게 서버-사이드-렌더링을 지원했기 때문에 AngularJS같은 속도 문제가 없었고 유지보수도 매우 훌륭했다

이렇게 끝판왕이 등장한 것이다.

 

실제로 서버가 Node.js라면

 

이렇게 바로 renderToString 메소드를 실행하여 view에 던져버린다

 

요런식으로 기존 다른 백엔드서버가 존재한다면, Node.js를 앞에 두고 기존 서버를 API서버로 사용할 수 있다.

 

무엇보다 React는 이제껏 등장했던 거인들과 다르게 단방향으로 데이터가 흘렀다.

양방향 데이터 바인딩을 하게 되면 장기적으로 흐름을 이해하기가 어려워 진다

React에서는 무조건 상위 컴포넌트에서 하위 컴포넌트로 데이터가 흐른다

 

사실 이러한 특징은 MVC 모델의 약점을 보완한 것이기도 하다

 

 

그림처럼 MVC는 확장할수록 괴랄해지기 때문이다

그래서 시총 5위에 빛나는 페이스북에서 

 

FLUX라 불리는 단방향 시스템 아키텍쳐를 제안한다