01. 웹 1.0 / 웹 2.0 / 웹 3.0
● 웹 (World Wide Web)
- 인터넷 위에서 동작하는 서비스
- 사용자들이 정보를 나누는 정보의 공간을 웹이 제공
- 하이퍼텍스트 (hypertext) 구조를 활용해서 인터넷상의 방대한 양의 정보를 서로 연결해 줌
● 웹 1.0
- 키워드 : 읽기 전용 (Read-only)
- 사용자가 주어진 정보를 받아들이기만 하는 수동적인 웹
- 정보는 소유권자가 가지고 있고, 상대방은 정보를 열람만 할 수 있는 형태
● 웹 2.0
- 키워드 : 참여형
- 읽기에 쓰기가 더해져 사용자와 정보 간 상호작용이 가능
● 웹 3.0
- 키워드 : 탈중앙화, 맞춤형
- 정보가 중앙으로 몰리는 서버 - 클라이언트 관계가 아닌 탈중앙화를 지향함
- 탈중앙화는 정보를 분산하여 저장하는 블록체인 기술을 통해 실현 가능
- 방대한 정보 중에서 필요 없는 것들은 거르고 사용자에게 알맞은 자료를 제공
02. 웹 표준 / 웹 접근성
● 웹 표준
- 웹상에서 지켜야 하는 표준 규칙
- 웹 표준을 잘 준수한 사이트는 국제 표준화 단체인 W3C (World Wide Web Consortium) 에서 지정한 표준안을 지키며 제작된 사이트를 의미
- 인터넷 익스플로러, 크롬, 사파리 등 웹 브라우저의 종류에 상관없이 동일하게 이용할 수 있다면 웹 표준을 준수해서 개발한 웹 사이트
- 예시
-- 문서 구조 : 해당 페이지의 기본 정보를 포함하는 헤드 (head) 와 본문을 포함하는 보디 (body) 를 가짐
-- 표준 엘리먼트 (element) 사용 : 모든 요소는 완벽하게 중첩 (시작 태그와 종료 태그) 되어야 하고, 모든 요소와 속성은 소문자여야 함
-- 인코딩 선언 : 모든 HTML 문서는 utf-8 을 기본 인코딩으로 사용
● 웹 접근성
- 장애인과 비장애인 모두가 웹 사이트를 이용할 수 있게 하는 방식
- 사이트가 올바르게 설계되어 개발, 편집되었을 때 모든 사용자가 정보와 기능에 동등하게 접근 가능
03. 웹 서버 / WAS
● 웹 서버 (Web Server) 와 WAS (Web Application Server)
- 사용자 (클라이언트) 의 요청을 받아들여 그에 맞는 결과를 사용자에게 전달해 주는 프로그램
● 웹 서버
- 하드웨어, 소프트웨어 두 가지 개념으로 살펴볼 수 있음
-- 하드웨어 : 웹 서버가 설치된 컴퓨터를 의미
-- 소프트웨어 : 웹 브라우저에서 HTTP (HyperText Transfer Protocol) 요청을 받아 HTML, CSS, 자바스크립트, image 등과 같은 정적인 파일을 제공해 주는 프로그램
- HTTP 프로토콜 (protocol) 을 기반으로 사용자의 요청에 응답하는 역할
- 동적인 콘텐츠를 제공하기 위한 요청을 WAS 에 전달
- 대표적인 웹 서버 : Apache, Nginx, Microsoft IIS
● WAS
- 데이터베이스 조회나 다양한 로직 처리를 요구하는 동적인 콘텐츠를 제공하기 위해 만들어진 앱 서버
- 비지니스 로직을 처리하는 것이 핵심
- 대부분의 WAS 는 웹 서버를 내장하고 있음
- 대표적인 WAS : Tomcat, JBoss, Jeus, Web Sphere
● 서버의 구조
- 일반적으로 웹 서버, WAS, DB 로 구성
- 클라이언트에서 정적인 콘텐츠를 요청 시
-- 웹 서버에서 해당하는 파일을 클라이언트로 반환하고 요청이 종료
- 클라이언트에서 동적인 콘텐츠를 요청 시
-- 먼저 웹 서버로 요청이 들어오고 웹 서버는 요청을 WAS 로 넘겨줌
-- WAS 에서는 다양한 로직을 처리하고 필요한 경우에는 DB 를 조회하고 삽입하는 등의 명령을 수행
-- WAS 에서 로직이 처리되면 해당 페이지를 다시 웹 서버로 전달하고 웹 서버는 마지막으로 클라이언트에게 페이지를 전달함
● 웹 서버와 WAS 를 함께 사용하는 이요
- 업무를 분담하여 서버의 부하를 방지
- 여러 대의 WAS 를 둘 경우에는 WAS 가 처리해야 하는 요청을 여러 개의 WAS 로 분산시켜 처리하도록 로드 밸런싱 가능
- 보안 측면에서 장점 : 사용자로부터 동적 콘텐츠에 대한 요청이 들어오면 실제 WAS 를 외부에 노출하지 않고도 웹 서버가 WAS 로 연결해 줌 (리버스 프록시)
● 웹 서버와 WAS 를 구성하는 환경 종류
- 온프레미스 (On-premise)
-- 클라우드 같은 원격 환경이 아닌 자체적으로 서버를 설치하여 운영하는 방식
- 클라우드
-- 특정 회사에서 운영하는 고성능 컴퓨터에 서버를 구축하는 방식
04. UI / UX
● UI (User Interface)
- 정보 기기와 소프트웨어의 화면 같은 사용자와의 접점
- 스마트폰의 터치스크린이나 키오스크의 스크린 등이 해당
- 세부적으로는 화면의 레이아웃, 색상, 그래픽, 글씨체, 크기 등 시각적으로 체감할 수 있는 요소들을 포함
- UI 의 구성이 어떻게 되어 있는지에 따라 사용 후에 느끼는 만족감이 달라짐
● UX (User eXperience)
- 정보 기기와 서비스를 사용하는 사람이 느끼는 경험
- 사용자와 회사, 회사의 서비스 또는 제품 사이의 상호 작용에서 발생하는 모든 측면을 아우르는 것
- 제품이나 서비스를 소비하면서 사용자가 얻는 경험
05. 디자인 시스템
● 디자인 시스템
- 웹이나 앱과 같은 서비스 디자인에 적용되는 디자인 원칙, 규격을 의미
- 일관적인 디자인을 위해 UI 가이드라인, UX 가이드라인, 컴포넌트들을 모아놓은 것
- 우리가 사용하는 대부분의 서비스에서 접할 수 있음 (ex. 카카오 노란색, 네이버 초록색)
- 기업이 추구하는 목표나 이미지 등을 다지인을 통해 나타냄으로써 소비자에게 강력한 인식을 남김
- 디자인 시스템은 디자이너가 여러 명이라도 제품과 인터페이스가 일관성을 유지할 수 있게 도와줌
● 디자인 시스템을 만드는 도구
- 인비전 DSM / 피그마 / 액슈어 / 스케치 / 어도비 XD / 제로헤이트
06. 반응형 웹 디자인
● 반응형 웹 디자인
- 하나의 웹 사이트가 사용자의 디바이스 (데스크톱, 모바일, 태블릿) 해상도에 반응하여 사용자 디바이스 화면에 콘텐츠의 크기 및 배치를 최적화하여 제공하는 기술
- 창의 크기가 동적으로 변경되더라도 현재 화면에 맞게 레이아웃이 변경됨
- 장점 : 비용 절감 / 검색에 유리 / 모든 해상도에 대응 / 유지 보수
- 단점 : 로딩 시간 증가 / 콘텐츠가 많고 복잡한 웹 페이지에 부적합
● 적응형 웹 디자인
- 사전에 몇 가지의 디바이스를 정하고 각각에 맞게 제작한 서로 다른 정적인 레이아웃
07. DOM / Virtual DOM
● DOM (Document Object Model)
- HTML, XML (eXtensible Markup Language) 문서에 접근하기 위해 웹 브라우저에 내장된 API
- DOM 을 사용해서 HTML 문서의 각 항목을 생성, 변경, 수정, 삭제 가능
- 이 객체 모델은 문서 내의 모든 요소를 정의하고, 각각의 요소에 접근하는 방식을 제공함
- DOM 기반 시스템은 변경된 부분뿐만 아니라 변경되지 않은 부분까지 다시 렌더링하여 매번 전체 화면을 처음부터 다시 생성하기 때문에 비효율적
- 모든 웹 브라우저는 내장된 DOM API 를 사용해 HTML 문서를 읽어 웹 화면에 보여줌
- 자바스크립트가 HTML, CSS 를 조작하는 역할도 함 (웹 브라우저 내의 DOM API 가 이러한 것들을 가능하게 함)
- HTML 과 자바스크립트는 다른 언어이기 때문에 서로 이해하지 못함
-- HTML 을 조작하기 위해서는 자바스크립트가 HTML 의 언어를 이해하게 해 줘야 하는데, 그 역할을 하는 것이 DOM
-- 자바스크립트가 HTML 을 조작해서 DOM 에 접근하는 것이지, HTML 문서 자체를 수정하는 것은 아님
- 웹 브라우저의 개발자 도구에서 보이는 코드가 DOM
● DOM 의 특징
- 웹 문서의 부모와 자식 요소인 각 노드가 트리 구조 (계층 구조) 로 되어 있음
- document node 는 트리의 최상위에 위치하며, 각각의 하위 노드에 접근하기 위한 시작점임
● Virtual DOM
- DOM 의 구조를 간략히 흉내 낸 자바스크립트 객체
- React.js, Vue.js 는 Virtual DOM 을 사용하는 대표적인 라이브러리와 프레임워크
- 자바스크립트 객체로 표현되고 메모리상에서 동작하므로 DOM 보다 속도가 빠름
- 실제 렌더링되는 것이 아니어서 연산 시간이 짧음
- 브라우저 내에 존재하는 API 가 아니기 때문에 브라우저 환경이 아니더라도 사용 가능
- DOM 의 구조가 복잡해지면 최적화와 유지 보수가 어려워짐
-- DOM 을 조작할 때마다 렌더링되는 과정이 많아지면 브라우저에 과부하가 오기도 쉽고, 자원을 많이 소모함
-- 이런 비효율성 때문에 내용이 변경될 때마다 렌더링하지 않고 변경된 내용만 파악하여 그 부분만 렌더링하는 것이 Virtual DOM 의 기술
- 현업에서 Vanilla.js (라이브러리나 플러그인을 사용하지 않는 순수한 자바스크립트) 를 사용하는 곳은 많지 않음
08. SEO
● SEO (Search Engine Optimization)
- 검색 엔진 최적화
- 웹 사이트가 검색 결과에 더 잘 노출되도록 최적화하는 과정
-- 검색 엔진의 작동 원리는 사용자가 검색창에 키워드를 입력하고 검색했을 때 크롤러가 수집한 정보를 바탕으로 최적의 정보를 제공하는 것
-- 구글 (SEO 기본 가이드), 네이버 (서치 어드바이서) 와 같은 검색 포털 사이트는 자체 개발한 알고리즘에 의해 크롤러가 매일 인터넷에서 정보를 수집하고 있음
09. 크롤링
● 크롤링 (crawling)
- crawl : 엎드려 기다 / Web 이라는 단어가 생략됨
- 하나의 페이지에서 웹 링크를 반복적으로 찾고 가져오는 행위
● 스크래핑 (scraping)
- 웹 페이지의 정보를 가져오는 행위
● 크롤링 과정 (ex. 검색 엔진이 정보를 수집하고 사용자에게 제공하는 과정)
1. 정보 수집 (crawling)
- 검색 서비스들은 크롤러를 이용해 다른 웹 사이트에 있는 정보들을 수집
- 이때 robots.txt (크롤러에게 웹 페이지의 정보를 수집하도록 허용하거나 제한하는 국제 권고안) 에 작성된 규칙을 준수함
2. 수집된 정보 색인화 (indexing)
- 크롤링된 정보들은 색인화해서 저장해 놓음
3. 자료의 순위 매기기 (ranking)
- 검색 서비스들은 높은 품질의 서비스를 제공하기 위해 사용자의 위치, 시간, 언어 등과 입력한 검색어를 조합하여 사용자에게 알맞은 정보를 제공함
● 적용 사례
- 실시간 최저가 / 코로나 19 확진자 수를 알려주는 사이트 / 고객의 소리
10. CSR / SSR
● CSR / SRR
- 웹 페이지의 렌더링 방식은 렌더링 과정을 수행하는 위치에 따라 CSR 과 SSR 로 나뉨
- 각각의 장단점이 분명하기 때문에 만들고자 하는 웹 사이트의 특성을 고려하여 렌더링 방식을 선택하는 것이 중요
● 렌더링
- 웹 페이지를 구성하는 HTML, CSS 등의 파일을 브라우저상에 그려주는 것을 의미
● CSR (Client Side Rendering)
- 클라이언트 단에서 렌더링을 수행하는 것을 의미
- 사용자가 최초로 웹 사이트에 접근할 때 웹 사이트에서 제공하는 모든 페이지에 대한 HTML, CSS 등의 리소스를 클라이언트에 다운로드하고 클라이언트 사이드에서 페이지 전환을 처리함
- 서버는 페이지가 맨 처음 그려질 때 웹 리소스 파일을 제공하는 역할과 페이지 로딩 이후 클라이언트 측에서 요청한 데이터를 전송해 주는 역할만을 수행함
● SSR (Server Side Rendering)
- 서버에서 렌더링 과정을 수행하는 것을 의미
- 사용자가 웹 페이지에 접속하면 서버로 해당 페이지에 대한 요청이 이루어지고, 서버에서 필요한 HTML, CSS 등을 이용해서 페이지를 렌더링한 후 클라이언트로 반환함
| 구분 | CSR | SSR |
| 정의 | Client Side Rendering | Server Side Rendering |
| 장점 | ● 렌더링 속도 빠름 (초기 로딩 제외) ● 서버 부담 ▼ |
● 첫 페이지 로딩이 빠름 ● SEO 에 적합 |
| 단점 | ● 첫 페이지 로딩이 느림 ● SEO 가 어려움 |
● 화면 전환시 깜빡임 문제 ● 서버 부담 ▲ ● 클릭해도 페이지가 반응하지 않는 문제 |
11. 캐시 / 쿠키 / 세션
● 캐시 (Cache)
- 이전에 사용했던 데이터들을 보관하는 사용자의 저장 공간
-- 웹 사이트나 앱에서 서비스를 이용할 때 재사용할 수 있는 데이터 (이미지, HTML 파일 등) 들을 캐시에 저장
-- 서버에 재요청했을 때 이 캐시를 이용하면 시간과 비용을 절약 가능
- 컴퓨터 CPU, 웹, 앱 서버 등 여러 곳에서 사용됨
-- 컴퓨터의 캐시 메모리 : 컴퓨터의 처리 속도를 더 빠르게 하기 위해 탄생
-- 웹, 앱에서의 캐시 : 데이터를 사용자에게 저장하게 함으로써 서버에서는 데이터 전송 부하를 낮출 수 있음
-- 글로벌기업에서 사용되는 캐시서버 : 데이터 저장소를 여러 나라에 만들어서 비용과 시간을 절감
- 사용자가 웹 사이트나 앱에 처음 접속한 이후에 다시 접속할 때 좀 더 빠르게 로딩되도록 도와줌
● 쿠키 (Cookie)
- http 통신의 특성 (무상태 (Stateless) 와 비연결성 (Connectionless)) 때문에 서버가 기억하지 못하는 사용자의 정보를 알기 위해 사용자에게 저장하는 크기가 작은 문자열 파일
- 사용자의 정보를 서버에서 알 수 있도록 도와줌
-- ex. 온라인 쇼핑몰에서 상품을 검색하고 장바구니에 넣을 때 로그인을 하지 않아도 장바구니에 상품이 담기고 페이지를 이동해도 그대로 상품이 담겨 있음
- 속성 및 특징
-- 최대 4KB 문자열
-- 도메인당 최소 50개까지 지원, 브라우저당 최소 3000개 보관 가능 (브라우저마다 차이는 있음)
-- 도메인과 경로는 사용자가 사이트에 접속했을 때 쿠키 정보에 있는 도메인과 경로의 하위 경로에서만 접속이 가능하도록 허용하는 것
-- 유효 날짜와 만료 시간
-- 안전 설정
-- HttpOnly : 쿠키를 http 에서만 사용하게 하여 XSS (Cross Site Scription) 같은 자바스크립트를 이용한 쿠키 탈취를 방지
-- Samesite : 다른 도메인에 쿠키 전송 허용 설정 가능 ▶ CSRF (Cross Site Request Forgery) 같은 공격을 방지
● 세션 (Session)
- 사용자가 사이트에 로그인했을 때 일정 기간 동안 서버에서 사용자에 대한 정보를 기록하고 보관하여 사용자를 관리하는 서버의 저장 공간
- 사용자를 관리하는 서버 쪽에서 접할 수 있음
-- ex. 서버에서는 사용자가 로그인을 하면 로그인한 사용자의 정보를 세션에서 관리하고 사용자에게 세션값을 제공함
12. 웹 스토리지
● 웹 스토리지 (Web Storage)
- 웹 브라우저 (클라이언트 단) 에 데이터를 저장하는 기술
-- 기존의 쿠키 방식으로 데이터를 저장할 때 발생하는 여러 문제점을 보완하여 HTML5 에서 새롭게 등장함
- 일시적으로 쓰이거나 보안이 중요하지 않은 데이터까지 모두 서버에 저장하면 트래픽과 서버 공간상 낭비가 발생
-- 이렇게 클라이언트 단에만 데이터를 저장하고 싶을 때 웹 브라우저 내에서 데이터 저장을 가능하게 해 주는 것이 웹 스토리지
- ex. 쇼핑몰 사이트에서의 최근 본 상품 기록
- 특징
-- 데이터에 접근 가능한 유일한 키 (key) 와 해당 키로 저장하는 값 (value) 형태로 데이터를 저장함
-- 따라서 키 값을 이용해 저장된 데이터를 참조하거나 가져올 수 있음
-- 이때 반환되는 데이터 값은 문자열 (String)
-- 객체 형태의 데이터도 문자열로 변환하여 저장 가능
- 쿠키와의 차이
-- 쿠키의 여러 단점을 보완하고자 등장한 데이터 저장 기술이므로, 저장 가능한 데이터 용량이나 개수, 보안 측면에서 쿠키보다 더 나은 성능을 보여줌
-- 저장 용량이 도메인별로 약 5MB 이상
-- 저장 가능한 데이터 개수에 제한이 없음
-- 데이터를 자동으로 서버에 전송하지 않기 때문에 서버에 부담이 적고 보안상으로도 쿠키보다 안전함
● 로컬 스토리지 (Local Storage) / 세션 스토리지 (Session Storage)
- 데이터가 유지되는 기간에 따른 분류
● 로컬 스토리지 (Local Storage)
- 로컬 스토리지에 저장한 데이터는 사용자가 삭제하지 않는 이상 영구적으로 저장됨
- 따라서 탭을 닫더라도 유지되어야 하는 정보를 로컬 스토리지에 저장하는 것이 적합
-- ex. 자동 로그인 설정처럼 브라우저 창을 닫아도 유지해야 하는 사용자 설정값
● 세션 스토리지 (Session Storage)
- 각 세션마다 데이터를 저장하는 것
- 데이터의 영구 저장이 불가능함
- 세션 스토리지에 데이터를 저장하는 경우, 페이지의 세션이 끝나면 데이터가 자동으로 삭제됨
- 즉, 브라우저 창을 닫으면 저장되어 있던 데이터가 삭제됨
- 다만 새로고침을 하면 데이터는 그대로 유지되므로, 브라우저를 사용하는 동안만 유지하면 되는 데이터를 세션 스토리지에 저장하는 것이 적합
● 웹 스토리지 사용 방법
- setItem(key, value)
-- localStorage.setItem(key, value);
-- sessionStorage.setItem(key, valu);
- getItem(key)
- removeItem(key)
- clear()
- 크롬 개발자도구 > Application 탭 > Storage 항목 > 로컬 스토리지와 세션 스토리지 확인 가능
- HTML5 에서 새롭게 등장한 저장 기술로, 일부 브라우저에서는 웹 스토리지 지원하지 않음
13. 모듈 / 웹팩
● 모듈 (Module)
- 한 파일에 들어가는 코드의 줄 수가 많아지면 가독성을 위해 복잡한 코드들을 여러 파일로 분리시켜야 함
- 이렇게 나눠진 여러 파일 각각을 모듈이라 부름
● 웹팩 (Webpack)
- 최신 프런트엔드 프레임워크에서 가장 많이 사용되는 모듈 번들러 (Module Bundler)
-- 모듈 번들러는 웹 앱을 구성하는 자원 (HTML, CSS, 자바스크립트, Images 등) 을 모두 각각의 모듈로 보고 이를 조합해서 병합된 하나의 결과물을 만드는 도구
14. MVC
● MVC (Model-View-Controller)
- 앱 개발을 세 개의 영역으로 분할하고 각 요소에 고유의 역할을 부여하는 방식
-- M (Model) : 데이터 영역
-- V (View) : 사용자에게 보여지는 UI 영역
-- C (Controller) : 비지니스 로직 처리 영역
- 소프트웨어 디자인 패턴 중 하나
-- 디자인 패턴 : 개발 방식을 공식화한 방법론
-- MVC 패턴을 도입하면 UI 영역과 도메인 (비지니스) 처리 영역이 분리되므로 서로 영향을 주지 않고 유지 보수 가능
- 확장과 유지 보수가 용이한 덕분에 복잡한 웹 개발을 할 때 실무에서 자주 접함
- MVC 의 구조 자체를 개발하는 데는 꽤 많은 시간이 소요되므로 MVC 웹 프레임워크를 활용함
-- Java : 스프링 (Spring) 프레임워크
-- Python : 장고 (Django) 프레임워크
-- PHP : 라라벨 (Laravel) 프레임워크
● 각 컴포넌트의 역할 (모델)
- 앱이 무엇을 할 것인지 정의하는 역할을 수행
- 데이터 저장소와 직접 연동하여 데이터를 어떻게 처리할지 결정함
- 모델을 통해 나온 결과 값은 컨트롤러 또는 뷰에 제공함
● 각 컴포넌트의 역할 (뷰)
- 모델로부터 받아온 데이터와 사용자가 원하는 결과값을 화면 (UI) 으로 보여주는 역할을 수행
- 우리가 웹 브라우저를 통해 보는 것들이 모두 뷰에 해당
- 뷰를 구현할 때 중요한 점은 뷰는 출력하는 역할만 수행해야 함
-- 즉, 데이터 로직을 다뤄서는 안 됨
-- 데이터를 저장하고 관리하는 클래스, 변수, 인스턴스 변수가 필요 없음
● 각 컴포넌트의 역할 (컨트롤러)
- 모델과 뷰 사이를 연결하는 다리 역할
- 프로그램의 작동 순서나 모델에게 데이터를 어떻게 처리해야 할지 지시하고, 받아온 결과값을 뷰에 전달하는 역할
- 컨트롤러에는 사용자의 요청을 직접 받고 모델과 뷰를 업데이트하는 로직이 포함됨
-- 모델과 뷰는 다른 컴포넌트가 무슨 역할을 수행하는지 알 필요가 없음
-- 하지만 컨트롤러는 뷰와 모델의 역할과 책임을 알고 있어야 함
- MVC 에서 컨트롤러는 상황에 따라 여러 개의 모델, 뷰와 연결될 수 있음
● MVC 의 한계
- MVC 의 가장 큰 특징은 구성요소를 독립시킴으로써 개발 효율성을 높인다는 것
- 이런 특징은 장점이 되기도 하지만 한편으로는 한계도 됨
- 다수의 모델 또는 뷰가 하나의 컨트롤러에서 수행되기 때문에 모델과 뷰는 완전히 분리되기가 쉽지 않음
- 특히 프로그램 구조가 커질수록 모델과 뷰가 복잡하게 연결되는 상황이 발생함
15. SPA
● SPA (Single Page Application)
- 웹 사이트의 전체 페이지를 하나의 페이지로 구현하고, 새로운 콘텐츠를 요구할 때마다 하나의 페이지 안에서 필요한 부분만 동적으로 처리하는 개발 방법
- 웹에서도 모바일과 같은 사용자 경험을 제공하기 위해 등장함
- 여기서 단일 페이지는 한 페이지 안에서 모든 것을 한다는 의미
-- 기존 방식의 웹 앱은 서버가 클라이언트의 요청에 응답할 때마다 새로운 페이지를 로드함
-- SPA 는 기존 방식과 다르게 새로운 페이지를 로드하지 않고 필요한 부분만 변경하는 것
● SPA 장점
- 서버 사이드 렌더링 (SSR ) 방식과 비교했을 때 배포가 간단해짐
- 웹 앱에 필요한 모든 정적 리소스를 최초로 받기 때문에 새로운 페이지를 요청했을 때 따른 속도로 갱신함
-- 덕분에 전체적인 트래픽도 감소함
- 다양한 운영체제로 웹 앱을 만들 때도 용이함
-- 서버에서 제공하는 데이터를 각 운영체제의 기술에 맞게 브라우저에서 가공하면 되기 때문
- SPA 는 주로 많은 콘텐츠를 제공하는 웹 페이지를 개발할 때 사용함
- 프런트엔드와 백엔드의 역할을 명확하게 구분하기 때문에 다양한 운영체제로 서비스를 제공할 때 사용하기도 함
● SPA 단점
- 웹 페이지를 최초로 열었을 떄 모든 정적 리소스를 받아야 하기 때문에 초기 콘텐츠 로딩 속도가 기존 웹 개발 방식에 비해 느림
- 사용자가 방문하지 않을 수도 있는 페이지의 리소스까지 모두 받아오기 때문에 상황에 따라서는 오히려 비효율적일 수도 있음
- SEO 에 적합하지 않음
-- 구글에서 어떤 페이지를 노출시키려면 해당 페이지의 HTML 에 검색 엔진에 유리한 정보를 기록해야 하는데, SPA 는 단일 페이지여서 각 페이지에 최적화된 정보를 기록할 수 없기 때문
● SPA 프레임워크
- SPA 를 쉽고 확장성 있게 구현하기 위해 SPA 프레임워크가 존재함
-- ex. 앵귤러, 리액트, 뷰
-- 공통적으로 브라우저와의 불필요한 상호 작용을 최소화하면서 동적인 웹 사이트를 만드는 것을 도와줌
- 앵귤러
-- 구글에서 만든 프레임워크
-- 타입스크립트를 기반으로 해 매우 안정적이고 탄탄한 프런트엔드 앱을 만들 수 있음
-- 다른 프레임워크에 비해 무겁고 다루기 어렵다는 단점
- 리액트
-- 페이스북에서 만든 프레임워크
-- 자바스크립트 (혹은 타입스크립트) 를 기반으로, 자료가 다양해서 어떤 개발 설계에도 유연하게 사용 가능
- 뷰
-- 개인 개발자가 만든 프레임워크
-- 앵귤러와 리액트의 장점을 수용함
-- 코드가 깔끔하고 배우기 용이
16. PWA
● PWA (Progressive Web App)
- 네이티브 앱 (Native App) 수준으로 웹 기술이 발전해 나갈 수 있게 방향성을 제시하는 최신 웹 앱 개발 방법
- 궁극적으로는 웹에서 네이티브 앱 수준의 사용자 경험을 제공하는 것이 목적
- 어떤 웹 사이트에 접속했는데 '앱을 설치하시겠습니까?' 라는 팝업창이 떠서 앱을 설치하면, 앱 스토어를 거치지 않고 바로 컴퓨터 바탕화면 혹은 스마트폰 홈 화면에 설치됨
- 이렇게 설치한 PWA 는 앱스토어나 플레이스토어에서 설치한 네이티브 앱과는 다름
● PWA 특징
- 서비스 워커 (Service Worker)
-- 웹 브라우저의 뒤편에서 항상 실행되고 있는 백그라운드 프로그램
-- 서비스 워커가 실행되어 있으면 클라이언트인 브라우저와 서버 사이에 상태 변경을 감지할 수 있음
-- 따라서 서버가 전송한 메시지가 있다면 클라이언트에 푸시 알림을 보내는 것도 가능함
-- 오프라인 상태에서도 항상 실행되고 있기 때문에 오프라인 상태에서 브라우저가 서버로 전송할 요청을 저장했다가 인터넷 연결이 활성화되었을 때 즉시 서버로 전송하는 것도 가능함
- 웹 앱 매니페스트 (Web Application Manifest)
-- 앱의 이름, 아이콘, 화면 방향, 배경 색 등 기본 정보 및 설정을 저장한 JSON (JavaScript Object Notation) 파일을 말함
-- 다양한 기기에서 PWA 가 설치될 때 꼭 필요한 가이드라인이 됨
- HTTPS
-- PWA 는 여러 운영체제의 권한을 필요로 하기 때문에 웹 서버와의 보안이 중요함
-- 따라서 HTTPS 를 통해 배포되고 실행되어야 함
● PWA 핵심 기능
- 푸시 알림
-- 네이티브 앱의 성공에 꼭 필요한 기능
-- 이 기능의 유무에 따라 앱의 재방문율, 실행 시간이 크게 달라짐
-- 웹 API 의 푸시 알림 관련 API 들을 사용할 수 있다는 점이 가장 큰 매력
-- 이 API 들은 서비스 워커와 마찬가지로 백그라운드에서 동작하기 때문에 사용자가 다른 앱을 사용 중이거나 앱을 완전히 종료한 상태에서도 푸시 알림을 보낼 수 있음
- 앱 설치 가능
-- PWA 에서 '홈 화면에 추가' 는 기존 모바일 웹에서 일종의 즐겨찾기 책갈피를 홈 화면에 추가하는 것과 다르게 네이티브 앱처럼 운영체제에 설치됨
-- 네이티브 앱과 거의 유사한 사용자 경험을 제공함
-- 네이티브 앱에 비해 설치 용량이 적다
- 네트워크 독립성과 캐싱 (caching)
-- 네트워크가 끊어져도 서비스 워커와 캐싱 API 의 도움으로 404 에러 페이지가 표시되지 않고 오프라인 상태에 표시할 커스텀 오프라인 페이지와 오프라인 기능들을 정의할 수 있음
-- PWA 에서의 캐싱은 브라우저 자체의 캐싱 (cache-control) 이 아니라 브라우저의 캐시 저장 공간 (cache storage) 을 활용하는 자원 관리 방법
참고문헌
● 개발자가 되기 위해 꼭 알아야 하는 IT 용어 : https://product.kyobobook.co.kr/detail/S000061352646
