감사하게도 취업을 준비한지 1달 만에 그래도 원했던 괜찮은 회사에 프론트엔드 엔지니어로 취업을 하게되었다.

취업을 한 회사는 React, Typescript를 쓰는 회사였는데 SSR을 위해서 Next.js를 사용하고 거의 모든 코드는 Next로 쓰여있다고 CTO님이 말씀해주셨다. 그래서 나는 앞으로 2주간 Next.js에 대해서 세 단계로 나눠서 공부하기로 했다. 하루 3시간씩 Basics, Intermediate, Advanced로 구성되는 과정을 적어볼까 한다.

Study Materials

• Next.js documentation(main)
• Udemy(main)
• Traversy Media(Next.js Tutorial)
• Medium and Blog posts

공부를 할때 그리고 특히나 정리해서 Post를 할때는 될수있으면 많은 머티리얼을 참고하는 것이 좋지만 현재는 일과 공부를 병행해야하기 때문에 일단은 베이스는 Next.js문서와 udemy 영상에 두기로 했다.

먼저 공부하기 전에 간단한 웹에서의 용어를 정리하고 갈 필요가 있다.

CSR SSR SSG

각각은 다음의 약자이다.

• CSR(Client Side Rendering)
• SSR(Server Side Rendering)
• SSG(Static Side Generation)

Render라는 영어 말은 여기서 "그리다"라는 뜻으로 쓰이고 의미는 그리는 것, "나타냄"의 의미를 가지고 있다. 따라서 프론트엔드를 얘기할때 "~를 렌더한다"라는 것은 "~를 그린다"로 이해하면 된다.

그렇다면 위의 세 가지 용어는 모두 ~ Side Rendering 또는 Generation(생성)이렇게 되어 있는데 이를 이해하기 위해서 간단하게 웹어플리케이션이 어떻게 사용자의 화면에 보여지는지(Render)되는지 알고 있어야 한다.

지금부터의 설명은 아주 간단하게 설명한 것이므로 엔지니어라면 더 깊게 이해하고 있어야 한다. (특히나 프론트엔드 엔지니어라면 더 자세히 공부해야할 것이다.)

사용자의 화면에 웹어플리케이션이 보여지는 과정

브라우저의 렌더링과정은 다음과 같이 몇가지 단계로 구성된다. 만약 google.com을 렌더한다고 가정한다면

1. 사용자는 브라우저의 주소창에 www.google.com를 입력한다.

2. 먼저 브라우저는 DNS(Domain Name System)서버로 가서 도메인에 해당하는 아이피주소를 받아온 다음 해당 아이피주소(서버)로 요청(Request)을 보내게 된다.

3. 서버에서는 응답으로 Resource를 보내주게 되는데 보통 index.html을 default로 보내주고 받아온 index.html은 사용자의 RAM에 올라간다.

4. 브라우저는 이때부터 받아온 index.html을 파싱(parsing) 한다. (parsing이라는 용어가 생소하다면 "해석하다, 해석할 수 있는 단위로 자른다"로 이해하면 된다.) 아무튼 이 index.html을 파싱하는데 중요한 것은 그 결과물로 브라우저는 DOM 트리라는 Document Object Model 트리를 만든다는 것이다.

   DOM은 브라우저에서 굉장히 큰 역할을 하고 중요한 주제이기 때문에 이것만 공부해도 시간이 굉장히 많이 걸리기 때문에 웹에 대해서 이해하고 싶다면 DOM공부는 필수다. 이 DOM은 브라우저가 이해할 수 있는 자료구조라고 간단히 생각할 수 있다.

5. DOM을 만들어가는 과정에서 link 태그와 script 태그처럼 css파일이나 js파일을 load하는 태그를 만나면 다시 서버에 이 파일들을 자동으로 요청하고 받아와서 이 파일들을 먼저 파싱한다. (이때 DOM트리를 만드는 과정은 잠시 중단된다. 참고로 CSS파일을 파싱해서 만든 자료구조는 CSSOM 트리라고 한다.)

6. DOM트리와 CSSOM트리의 형성이 완료되면 그것으로 렌더트리라는 것을 만든다.

7. 렌더트리는 렌더링을 위한 트리의 자료구조다. 렌더트리는 각 HTML 요소의 위치와 크기를 계산하는데 이것을 "레이아웃을 계산한다"고 말한다.

8. 마지막으로 레이아웃이 계산되면 paint라고 하는 과정을 통해 화면에 있는 픽셀의 밝기와 색상을 조절하여 사용자의 눈에 보여지게 된다.

위의 8가지 단계는 굉장히 간략하게 과정을 적어 놓은 것이다. CSR, SSR, SSG는 이 사용자 화면에 보여지는 방법들의 세 가지 방법인 것이다.

Client Side Rendering

CSR은 Create React App을 사용하게 될 경우 가장 기본적으로 사용자 화면에 render되는 방식이기도 하다.

이 방식은 비어있는 index.html과 엄청 큰 Javascript파일(Bundle파일)이 같이 와서 사용자의 컴퓨터에서 이 Javascript로 쓰여진 일종의 프로그램이 돌아가면서 DOM을 계속적으로 조작하고 사용자 화면에 무엇인가를 보여주는 방법이다.

이 방법은 굉장히 효율적이긴 하다. index.html 하나와 엄청 큰 Javascript파일 하나만 보내면 되기 때문이고 사용자의 컴퓨터를 render하는데 이용하기 때문에 Server의 부하를 줄일 수도 있다.

하지만 치명적인 단점이 하나 있는데 바로 처음 화면에 보여지는 것이 많이 느려질 수 있다는 것이고, 이것은 JS파일이 크면 클수록 더욱 그렇다. 또한 인터넷이 느리면 사용자의 화면에는 빈 화면만 계속 보여서 User Experience에 안좋을 수 있다. 마지막으로 SEO에 굉장히 취약하다.

Server Side Rendering

SSR방식은 서버로 요청이 들어오면 사용자 단에서 필요한 HTML파일을 서버 단에서 자료를 모으고 생성해서 보내주는 방식이다. 이 방식을 사용하면 CSR와는 다르게 첫페이지 로딩이 매우 빠르기 때문에 User Experience에 좋다.

그리고 모든 컨텐츠는 HTML문서 자체에 다 담겨있기 때문에 SEO에 취약한 CSR보다는 매우 좋다.

그러나 이후 사용자가 다른 요청(클릭, 타이핑, 등)을 할 때에 다시 서버에서 전체 html 파일을 가져와야 하기 때문에 통신이 자주 일어나야하고 이는 비효율적이다.또한 화면 이동시 화면이 깜빡이는 현상이 일어난다.

또한 사용자가 많고, 데이터 정보가 많은 서비스일 경우 서버에 부담이 커서 서버에 과부하가 걸리기 쉽다.

Static Site Generation

CSR 방식과 SSR에 대해서 알아보았다. 둘 모두 장단점이 명확하다. 이를 해결하기 위해서 웹개발자 선배님들이 많은 날들을 고민하고 연구와 도전을 계속적으로 한 끝에 많은 부분들이 개선이 되었고 그 방법 중 하나가 지금부터 알아볼 SSG방식이기도 하고 React+Next, React+Gatsby방식으로 2021현업에서 많이 쓰이고 있는 방식이다.

이 방식의 작동원리는 React로 만들어진 웹앱의 경우 Next.js나 Gatsby같은 Framework의 도움을 받아서 Server쪽에서 요청이 들어오기 전에 정적인 웹페이지를 먼저 만들어 놓는 것이다. 그리고 요청이 들어왔을때 바로 만들어 놓은 Resource들을 보내준다.

그렇기 때문에 사용자의 화면에 빨리 보이게 된다. 그리고 SSR처럼 요청이 들어오면 만드는 것이 아니기 때문에 server의 부하도 줄일 수 있다. 그러면서 이미 정적으로 html이 생성이 되어있기 때문에 CSR처럼 SEO에 취약하지도 않다.

이러한 SSG가 이 모든 것의 해결책으로 보이지만, 이런 SSG에도 단점이 존재하는데 Next.js를 사용하는 경우 현시점에서 웹사이트가 굉장히 크다면 Rebuild시 시간이 오래걸릴 수 있다는 점이고 다른 하나는 특정 UI라이브러리는 사용할 수 없다는 것이다. 이런 이유는 Server쪽에서 동작하는 node에는 DOM을 조작하기 위한 document나 window가 존재하지 않기 때문이다.

그렇다면 어떻게 할 것인가?

각각의 서비스에 맞게 render방식은 선택하면된다. 현재의 회사에서는 Next.js를 이용해서 SSG방식을 채택했다.

처음 접하는 Next

공부를 할때 가장 좋은 방법은 공식문서를 읽는 것이다.

• Next.js 공식문서

Next.js에서 제공하는 몇가지 기능들을 살펴보면 다음과 같다.

• An intuitive page-based routing system (with support for dynamic routes)
  (직관적인 페이지 기반 라우팅 시스템, 그리고 동적인 라우팅도 지원한다.)
• Pre-rendering, both static generation (SSG) and server-side rendering (SSR) are supported on a per-page basis
  (먼저 렌더하는 방식, SSG, SSR는 페이지 단위로 지원한다.)
• Automatic code splitting for faster page loads
  (빠른 페이지 불러오기를 위한 자동화된 코드 분할)
• Client-side routing with optimized prefetching
  (최적화된 prefetching을 통한 클라이언트 사이드 라우팅)
• Built-in CSS and Sass support, and support for any CSS-in-JS library
  (CSS, Sass 지원, 그리고 빌트인 CSS-in-JS 라이브러리를 지원한다.)
• Development environment with Fast Refresh support
  (빠른 Refresh를 지원하는 개발환경을 지원한다.)
• API routes to build API endpoints with Serverless Functions
  (API 엔드포인트가 있는 서버리스 함수들을 위한 API 라우트를 지원한다.)
• Fully extendable
  (확장가능성)

다음 포스트에서는 Next.js 공식문서의 Tutorial을 직접 따라하면서 그것을 적고, Udemy강의를 들으면서 알게되는 것들을 포스팅할 것이다. Stay Tuned!!