클라이언트 빌드와 배포

---

클라이언트 빌드와 배포

학습 목표

* 정적 웹사이트와 동적 웹사이트의 차이

* 빌드의 의미

* 정적 웹사이트 형태로 만들어지는 웹 앱에서의 빌드 과정의 필요성

* 정적 웹사이트 배포

* 정적 웹사이트 배포시 발생하는 문제 해결

* 정적 웹사이트에서 사용하는 다양한 프론트엔드 기술 공부: Landing Page 등(스스로 찾아보기)

빌드

SSR과 CSR

SSR과 CSR의 차이점을 이해하기
→ SSR과 CSR의 정의와 차이점을 알아 보자

SSR(Server Side Rendering)

웹 페이지를 브라우저에서 렌더링하는 대신, 서버에서 렌더링한다

 

브라우저가 서버의 URI로 GET 요청(req)을 보내면, 서버는 정해진 웹 페이지 파일을 브라우저로 전송. 이 웹페이지가 브라우저에 도착하면 렌더링이 완료됨
→ 서버에서 웹 페이지를 브라우저로 보내기 전에 서버에서 완전히 렌더링을 하고 보내는 구조
→ Server Side Rendering(SSR)

 

데이터베이스의 데이터가 필요한 경우: 서버에서 데이터베이스의 데이터를 불러온 다음 웹 페이지를 렌더링된 페이지로 변환 후에 브라우저에 응답(res)함

 

사용자가 브라우저의 다른 경로로 이동하는 경우: 그 때마다 서버는 이 렌더링 작업을 다시 수행함

CSR(Client Side Rendering)

클라이언트(ex. 웹 브라우저)에서 웹 페이지를 렌더링 함

 

브라우저가 서버로 요청(req)을 보내면 서버는 렌더링을 하는 대신, 웹 페이지의 골격이 되는 단일 페이지를 클라이언트에 보내는데, 이때 서버는 웹 페이지와 함께 javaScript 파일을 보낸다

 

클라이언트가 웹 페이지를 받으면, 웹 페이지와 함께 전달된 javaScript 파일은 브라우저에서 웹 페이지를 완전히 렌더링된 페이지로 변환시키는 구조

 

데이터베이스의 데이터가 필요한 경우: 브라우저는 데이터베이스에 저장된 데이터를 가져와서 웹 페이지에 렌더링 해야함
→ 필요한 데이터를 API 요청으로 가져옴

 

브라우저의 다른 경로로 이동하는 경우: SSR과 다르게, 서버가 웹 페이지를 다시 보내지는 않는다.
브라우저가 페이지를 다시 렌더링하는데, 이때 보이는 웹 페이지 파일은 맨 처음 서버로부터 전달받은 웹 페이지 파일과 동일한 파일임

 

SSR과 CSR의 차이점

페이지가 렌더링되는 위치

* SSR: 서버에서 페이지를 렌더링
→ 사용자가 다른 경로를 요청할 때마다 페이지를 새로고침

* CSR: 클라이언트(브라우저)에서 페이지를 렌더링
→ 사용자가 다른 경로를 요청할 때마다 페이지를 새로고침하지 않고, 동적으로 라우팅을 관리함

SSR을 사용하는 case

SSR을 사용하는게 더 적합한 경우들

* SEO(Search Engine Optimization)이 우선순위인 경우(중요한 경우)

* 웹 페이지의 렌더링이 빠르게 필요한 경우
→ 단일 파일의 용량이 작은 SSR이 적합

* 웹 페이지가 사용자와의 상호작용이 적은 경우

CSR을 사용하는 case

CSR을 사용하는게 더 적합한 경우들

* SEO가 우선순위가 아닌 경우

* 사이트에 풍부한 상호작용이 있는 경우
→ CSR의 빠른 라우팅으로 강력한 사용자 경험을 제공

* 웹 애플리케이션을 제작하는 경우
→ 더 나은 사용자 경험(빠른 동적 렌더링 등)을 제공 가능

정적 웹 사이트 vs. 동적 웹 사이트

얼핏 보면 동적 웹사이트가 더 최신 기술처럼 보이지만,
현대의 2-tier Architecture 에서는 정적 웹사이트의 사용이 보편적임

* 정적 웹사이트: HTML 파일(코드) 자체로 배포되는 사이트(CSR)

→ 단지 정적인 호스트만 필요함(서버로부터 제공받은 HTML, JS, CSS)
→ 정적 웹사이트가 일반적으로 더 싸고, 설치가 쉬운 경향이 있다
→ 사용 예: AWS S3 , Firebase Hosting 등

* 동적 웹사이트: 서버에 의해 HTML 파일이  동적으로 생성되는 사이트(SSR)

→ 호스트가, 선택한 서버 사이드 언어(와 버전)을 지원해야 한다
→ 일반적으로 설치가 더 복잡하고 좀 더 비싼 경향이 있다
→ 사용 예: AWS EC2/ Elastic Beanstalk, Heroku 

웹 사이트 렌더링 방식의 변천

AJAX 이전에는 동적인 페이지를 만들기 위해서는 서버가 매번 동적으로 페이지를 생성해야만 했음
→ 서버가 HTML의 형태로 브라우저에 제공해 줘야만 했음
→ 페이지 구성 요소(헤더나 footer 등)의 중복 요청/응답이 빈번
→ 네트워크 패킷의 크기가 커짐

 

AJAX 이전에는 이런식으로 서버에서 웹페이지를 만드는 기술이 보편화(SSR)
→ 이러한 동적 웹 사이트를 만드는 기술로 PHP, JSP, ASP 등이 사용됨
(node.js로도 동적 웹페이지 구현이 가능)

// 동적 웹페이지 예제 (node.js)

const http = require('http');

const server = http.createServer((req, res) => {
  res.setHeader('Content-Type', 'text/html'); // HTML 문서의 형태로 전달됨
  res.end('<h1>동적 웹페이지</h1><p>with 랜덤한 값</p>' + Math.random()); 

// 서버에 의해서 동적으로 바뀜
});

server.listen(3000);

점차, 브라우저가 발달하고 AJAX 기술이 보편화되면서, 모든 동적인 정보들을 서버가 부담할 필요가 없게됨
→ 필요한 부분만 클라이언트가 요청(req)하는 식으로 되었고, 서버의 부하가 감소

 

이에 따라, 서버는 JSON과 같은 순수한 데이터 포맷만 제공해주는 형태로 흐름이 바뀜
→ Client Side에서는 웹페이지가 javaScript와 AJAX 기술을 활용한 고도화된 앱; SPA(Single Page Application)으로 변모함

 

→ 이는 정적 웹사이트의 형태가 된 것: 서버가 웹페이지를 렌더링하지 않으며, 웹 사이트가 HTML/CSS/JS 파일의 소스 코드 그대로(정적으로) 작동하는 특징을 가지므로...

동적 웹사이트는 더 이상 사용하지 않는가?

그렇지는 않다. 클라이언트 Side가 고도화되긴했지만, 앞서 봤듯이 SSR의 장점을 활용하여 동적 웹사이트를 사용하는 경우가 존재한다

 

또는 CCR, SSR의 하이브리드 형태로 구성하기도 함
→ 성능의 향상 극대화 목적

클라이언트 빌드

정적 웹사이트의 빌드

현대의 웹 앱은 정적 웹페이지, AJAX 등의 기술을 사용하여 SPA로 되면서 고도화됨
→ 웹사이트 구성요소를 각 파일로 분리하는 모듈화가 이뤄지면서, 단일 파일로 자바스크립트나 페이지를 만드는 작업이 더욱 고도화 됨

 

고도화된 클라이언트의 웹 앱은 수많은 모듈로 이루어져 있다
→ 이 수많은 모듈을 하나로 묶어주는 작업; 번들링(bundling)
→ 번들링 과정에서 JSX 파일과 같이 브라우저가 자체적으로 해석이 불가능한 기술들을 브라우저가 해석할 수 있도록 만들어 주는 작업이 필요; 소프트웨어 빌드

 

정리하자면, 소프트웨어 빌드 는 소스코드를 실행 가능한 결과물로 변환하는 작업

 

Create React App 으로 생성한 React 프로젝트는 npm build 명령어가 package.json 파일에 포함되어 있어서, 이 명령어로 모듈을 정적인 파일로 만들 수 있다.

 

이 파일을 정적 파일을 호스팅하는 서비스에 업로드하면 인터넷에 배포할 수 있는 것

주요 빌드 툴

React 프로젝트 생성 툴

다양한 프로젝트 생성 툴이 존재하는데 대표적으로

* Create React App
→ react-scripts 라는 모듈을 사용

* Next.js
→ next 모듈을 사용

빌드 툴

프로젝트 생성 툴의 구성을 보면 내부적으로 다양한 툴의 조합으로 이루어져 있다

* webpack: 모듈 번들러(번들링하는 메인 담당)

* babel: TypeScript, JSX 등과 같이 브라우저가 지원하지 않는 언어를
 JavaScript로 바꿔주는 컴파일러

* ESLint: 자바스크립트 Code convention 및 문법 검사기

* Sass, less: CSS 전처리기

...등...

이런 빌드 툴의 설정을 다 외울 필요는 없다. 그냥 이런 종류의 빌드 툴이 있음을 알고만 있으면 되고, 각각의 설정 파일을 수정/변경해야 할 때 공식 문서를 참고해서 해결할 수만 있으면 된다

 

배포

클라이언트 웹 앱 배포

로컬 환경에서 개발한 코드를 실제 서비스로 만들기 위해서는, 빌드 과정과 이를 웹에 노출시키는 배포 과정이 필요함
→ 빌드를 통해 만든 정적 파일이 웹을 통해 제공(serve)되려면 정적 파일을 제공할(업로드할) 웹 서버가 필요

 

호스팅 서비스: 정적 파일을 제공할 수 있도록 서버의 공간을 대여 해주는 서비스

호스팅 서비스를 통해서 단순(정적) 파일을 배포할 수 있다

동적 웹사이트나 API(express를 사용한) 서버를 제공하려면 별도의 클라우딩 컴퓨팅 서비스가 필요

다양한 웹 호스팅 서비스

개발자들이 선호하는, 비교적 낮은 가격에 사용한 다양한 웹 호스팅 서비스 목록들

* Amazon Web Service(AWS) S3

* Google Cloud Storage

* Vercel

* GitHub Pages

* Netlify

* Heroku

우선은, 코드 연결과 빌드, 배포의 과정을 매우 단순하게 만들어 주는 vercel로 연습해 보자

 

클라이언트 배포 연습하기

Vercel을 이용한 클라이언트 배포

Vercel

GitHub와 같은 코드베이스(저장소)를 연결하여, 즉시 빌드를 실행하고 배포까지 원클릭으로 할 수 있다는 장점
→ 실제로 배포는 Versel 서비스 내에서 이루어짐

 

Import Git Repository → Add GitHub Org or Account 로 내 계정에다가 설치하자
→ 연동하면 내 Repo 목록들이 표시됨
→ 원하는 Repo를 Import 하면 된다

 

프로젝트 설정

Build and Output Settings 의 세부 내용을 살펴 보면,

• build command: 빌드에 필요한 CLI 명령어를 의미
  → 기본값은 yarn run build 이대로 두어도 빌드는 잘 된다

 

• output directory: yarn run build 이후 빌드 결과물이 생기는 디렉토리
  → 기본값은 build

 

Deploy 버튼 누르면 배포가 시작됨

대시보드

빌드가 성공적으로 이루어지면, versel이 제공하는 url을 통해 내 프로젝트가 호스팅된다(배포)
→ 완료 화면에서 go to Dashboard를 눌러서 대시보드를 살펴 보자

 

대시보드에서는 개발환경이 아닌 프로덕션 환경에서의 배포 현황을 프로젝트 별로 볼 수 있다

Deployment: 배포 현황과 관련된 CLI 출력을 확인할 수 있다

Domain: 실제 배포된 URL

State: 현재 배포 상태

이렇게 작업(설정?)을 해두면, GitHub에 fork된 Repository에 변경사항을 만들고 push하면, 앞으로는 자동으로 빌드 및 배포 과정이 진행된다

 

---

추가 내용 정리

• SSR vs. CSR 의 비교
  → 기술 면접 단골 질문! 이니 잘 정리해 두기

 

• CSR: 하나의 틀이 유지되어 있는 상태에서 유저와의 상호작용에 따라 일부분만 변경되는 웹사이트

 

• SEO: 검색 엔진 최적화
  → 검색어에서 상위 노출을 중요시

 

• 동적 웹사이트 vs. 정적 웹사이트
  → 서버 입장에서 봤다고 생각하면 된다

 

• 동적 웹사이트: 서버는 늘 HTML 파일을 만들어서 응답해 줘야 함
  → 서버 자원에 따라 페이지의 형태가 바뀜

 

• 정적 웹사이트: 서버는 미리 만들어진 HTML, CS파일을 전달하기만 한다
  → 서버 자원과 무관함