on
클라이언트 빌드와 배포
클라이언트 빌드와 배포
클라이언트 빌드와 배포
학습 목표
* 정적 웹사이트와 동적 웹사이트의 차이 * 빌드의 의미 * 정적 웹사이트 형태로 만들어지는 웹 앱에서의 빌드 과정의 필요성 * 정적 웹사이트 배포 * 정적 웹사이트 배포시 발생하는 문제 해결 * 정적 웹사이트에서 사용하는 다양한 프론트엔드 기술 공부: 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('동적 웹페이지with 랜덤한 값' + 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파일을 전달하기만 한다
→ 서버 자원과 무관함
from http://lesil.tistory.com/62 by ccl(A) rewrite - 2021-11-08 15:00:43