[코드잇 스프린트] 6주차 위클리 페이퍼

티스토리 뷰

코드잇 스프린트/Weekly paper

[코드잇 스프린트] 6주차 위클리 페이퍼

무화과(Fig) 2024. 4. 13. 10:49

1. 예시의 코드를 실행할 때, 콘솔에 출력될 값과 그 이유를 설명해 주세요.

// 1번
let num = 1;

// 2번
setTimeout(() => {
  num = 2;
}, 0);

// 3번
num = 3;

// 4번
console.log(num);

답: 3

동기 실행은 코드가 순차적으로 실행되는 방식이다.

console.log("1st");
console.log("2nd");
console.log("3rd");

// '1st'
// '2nd'
// '3rd'

위와 같은 코드를 작성하고 실행해 보면 예상했던 것처럼 1st, 2nd, 3rd가 차례대로 찍히는 것을 알 수 있다.
이처럼 코드가 위에서부터 아래로 내려오면서 하나가 끝나면 다음 코드가 실행되는 방식을 동기적 처리 (Synchronous)라고 한다.

비동기 실행은 코드가 순차적으로 실행되지 않고, 다른 작업을 동시에 수행할 수 있는 방식이다. 자바스크립트에서는 콜백이나 프로미스와 같은 매커니즘을 사용해서 비동기 코드를 작성한다.

console.log('1st');
setTimeout(() => {
  console.log('2nd');
}, 0);

console.log('3rd');

비동기와 동기의 개념을 문제에 적용해보면, setTimeout() 메소드는 비동기적 API이기 때문에 비동기적 API를 제외한 모든 코드가 실행 된 이후 결과를 출력한다.

전체적인 과정은 다음과 같다.
1. 맨 처음 num 이 1 로 할당된다.
2. 두번째 코드 setTimeout() 메소드는 동기 코드가 모두 실행될 때 까지 다른 프로그램에 맡긴다.
3. num이 3으로 할당된다.

- setTimeout()의 지연 시간이 0이더라도 setTimeout()는 비동기적 API이기 때문이 동기적 코드가 전부 실행되고 나서 값을 반환한다.

2. 리액트에서 Virtual DOM이 무엇인지, 이를 사용하는 이유는 무엇인지 설명해 주세요.

Virtual DOM을 이해하기 전에 DOM이 무엇인지 아는 것이 중요하다. 따라서 DOM에 대해 먼저 알아보자.

1. DOM (Document Object Model)

DOM의 개념은 다음과 같다.

Document 문서
Object 객체
Model 모델

한국어로 표현하면 문서 객체 모델이다.

문서 객체란 <html>이나 <body>같은 html 문서의 태그들을 JS가 이용할 수 있는 객체(object)로 만든 것을 말한다. 여기에 Model이라는 단어가 붙는데 여기서는 문서 객체를 인식하는 방식 이라고 해석하면 된다.

조금 더 명확하게 정의해보자면, DOM은 넓은 의미로 웹 브라우저가 HTML 페이지를 인식하는 방법을 의미한다. 좁은 의미로 본다면 document 객체와 관련된 객체의 집합을 의미한다.

DOM을 제대로 이해하기 위해서는 tree라는 자료구조를 이해해야 한다. 이유는 DOM이 tree 형식의 자료구조를 가지고 있기 때문이다.

tree의 자료구조를 간단하게 살펴보자.

tree는 이름에서 알 수 있듯이 하나의 root node에서 시작된다. tree는 위쪽의 node를 부모(parent)노드, 아래쪽 노드를 자식(child) 노드 라고 한다. 그리고 children(자식)이 없는 node를 leaf node라고 한다.

위 그림은 DOM에 포함된 <p> 태그를 더 자세히 본 그림이다.

<p> 태그에서도 자식 노드 (childNode) 들과 속성 (attribute) 들이 트리 형태로 자료구조를 형성하고 있는 것을 알 수 있다.

그렇다면 JavaScript로 문서 객체를 생성한다는 것은 어떤 의미일까?

우선 문서 객체가 생성되는 방식은 두 가지로 나눠볼 수 있다.

1. 정적 생성: 웹 브라우저가 HTML 페이지에 적혀 있는 태그를 읽으면 생성하는 것

2. 동적 생성: HTML 페이지에 없던 문서객체를 JS를 이용해서 생성하는 것

따라서 JavaScript로 문서객체를 생성한다는 것은 처음에는 HTML 페이지에 없던 문서객체를 동적으로 생성하는 것이 된다.

정리하자면, DOM은 웹 페이지나 웹 앱에 있는 HTML 요소들을 구조적으로 표현한 것이며 DOM은 트리 데이터 구조로 표현된다.

2. DOM의 문제점

앞서 말했듯이 DOM은 트리구조로 되어 있어서 이해하기 쉽다.

그러나 노드의 수가 많아질 수록 속도가 느려지고 DOM 업데이트로 인해 오류가 잦아질 수 있다.

또한 최근 대부분의 웹은 SPA(Single Page Application)을 사용한다.

하나의 웹 페이지를 어플리케이션처럼 구성하는 SPA에서는 HTML 문서 자체가 하나이며 여러 동적인 기능이 들어간다. 때문에 안그래도 리소스가 모두 합쳐진 무거운 HTML 문서를 지속적으로 재랜더링 해줘야한다는 문제점이 발생하게 되었다.

따라서 DOM 트리가 수정될 때마다 렌터 트리가 계속해서 실시간으로 갱신되어 성능에 좋지 못한 영향을 미치게 되고, 이러한 이유를 해결하고자 Virtual DOM이 등장한다.

- MPA와 SPA 란?

SPA(Single Page Application)는 한 개(Single)의 Page로 구성된 Application이다.
MPA(Multiple Page Application)는 여러 개(Single)의 Page로 구성된 Application이다

MPA는 새로운 페이지를 요청할 때마다 정적 리소스가 다운로드된다.따라서 매번 전체 페이지가 다시 렌더링 된다.

반면 SPA는 웹 에플리케이션에 필요한 모든 정적 리소스를 최초 한 번에 다운로드한다.그 이후 새로운 페이지 요청이 있을 때, 페이지 갱신에 필요한 데이터만 전달 받아서 페이지를 갱신한다.

그래서 SPA를 CSR(Client Side Rendering) 방식으로 렌더링한다고 말하며, MPA를 SSR(Server Side Rendering) 방식으로 렌더링한다고 말한다.

각각의 특징을 좀 더 자세히 알아보자.

1. MPA(Multiple Page Application)
- 여러 개(Single)의 Page로 구성된 Application이다.
- MPA는 SSR(Server Side Application) 방식으로 렌더링한다. 새로운 페이지를 요청할 때마다 서버에서 렌더링된 정적 리소스(HTML, CSS, JavaScript)가 다운로드된다. 페이지 이동하거나 새로고침하면 전체 페이지를 다시 렌더링한다.

1) MPA장점
1. SEO 관점에서 유리하다.
MPA는 완성된 형태의 HTML 파일을 서버로부터 전달받는다.따라서 검색엔진이 페이지를 크롤링하기에 적합하다.

2. 첫 로딩 매우 짧다.
서버에서 이미 렌더링해 가져오기 때문이다.
그러나 클라이언트가 JS 파일을 모두 다운로드하고 적용하기전 까지는 각각의 기능은 동작하지않는다.

2) MPA단점
1. 새로운 페이지를 이동하면 ‘깜빡’인다. (UX)
매 페이지 요청마다 리로딩(새로고침) 발생한다.새로운 페이지를 요청할 때마다전체 페이지를 다시 렌더링하기 때문이다.
2. 페이지 이동시 불필요한 템플릿도 중복해서 로딩 (성능)
2. 서버 렌더링에 따른 부하
4. 모바일 앱 개발시 추가적인 백엔드 작업 필요 (생산성)개발이 복잡해질 수 있다.

2. SPA(Single Page Application)
- 한 개(Single)의 Page로 구성된 Application이다.
- SPA는 CSR(Client Side Rendering) 방식으로 렌더링한다.
- 단 한 번만 리소스(HTML, CSS, JavaScript)를 로딩한다.그 후에는 데이터를 받아올 때만 서버와 통신한다.
즉, 첫 요청시 딱 한 페이지만 불러오고 페이지 이동 시 기존 페이지의 내부를 수정해서 보여주는 방식이다.
- 이를 클라이언트 관점에서 말하자면 최초 페이지를 로딩한 시점부터는 페이지 리로딩 없이 필요한 부분만 서버로 부터 받아서 화면을 갱신하는 것이다.필요한 부분만 갱신하기 때문에 네이티브 앱에 가까운 자연스러운 페이지 이동과 사용자 경험(UX)을 제공할 수 있다.
- Angular, React, Vue 등 프론트엔드 기술들이 나오면서 크게 유행하고 있다.
- 그런데 CSR 방식으로 만든 SPA 앱은 검색엔진최적화(SEO)가 어렵다.

1) SPA 장점
1. 자연스러운 사용자 경험 (UX)
전체 페이지를 업데이트 할 필요가 없기 때문에 빠르고 ‘깜빡’ 거림이 없다.
2. 필요한 리소스만 부분적으로 로딩 (성능)
SPA의 Application은 서버에게 정적리소스를 한 번만 요청한다.그리고 받은 데이터는 전부 저장해놓는다. (캐시=Cache)
3. 서버의 템플릿 연산을 클라이언트로 분산 (성능)
4. 컴포넌트별 개발 용이 (생산성)
5. 모바일 앱 개발을 염두에 둔다면 동일한 API를 사용하도록 설계 가능 (생산성)

2) SPA 단점
1. JavaScript 파일을 번들링해서 한 번에 받기 때문에 초기 구동 속도가 느리다. (Webpack의 code splitting으로 해결 가능)
2. 검색엔진최적화(SEO)가 어려움 (SSR로 해결 가능)
3. 보안 이슈 (프론트엔드에 비즈니스 로직 최소화)
SSR에서는 사용자에 대한 정보를 서버측에서 세션으로 관리를 하지만 CSR 방식에서는 클라이언트측의 쿠키말고는 사용자에 대한 정보를 저장할 공간이 마땅치 않다.

MPA 작동방식과 SPA 작동방식

+) 왜 CSR 방식으로 만든 SPA 앱은 검색엔진최적화(SEO)가 어려울까?

일반적인 SPA 앱을 검색로봇 입장에서 보면 모든 페이지의 소스가 아래와 같이 보인다.
검색엔진이 색인을 할 만한 컨텐츠가 존재하지 않는 것이다.

<html>
<head>
  <title>Single Page Application</title>
  <link rel="stylesheet" href="app.css" type="text/css">
</head>
<body>
  <div id="app"></div>
  <script src="app.js"></script>
</body>
</html>

3. Virtual DOM(가상 돔)

Virtual DOM은 실제 DOM과 같은 내용을 담고 있는 복사본이라고 생각하면 쉽다.

이 복사본은 실제 DOM이 아닌 JS 객체 형태로 메모리 안에 저장되어 있으며 실제 DOM의 모든 element와 속성을 공유한다. 그러나 브라우저에 있는 문서에 직접적으로 접근할 수는 없기 때문에 화면에 보여지는 내용을 직접 수정할 수 없다.

그렇다면 리액트는 어떤식으로 Virtual DOM을 활용해서 실제 DOM을 조작하는지 알아보자.

리액트는 항상 두 개의 Virtual DOM객체를 가지고 있다.

1. 렌더링 이전 화면 구조를 나타내는 가상돔

2. 렌더링 이후에 보이게 될 화면 구조를 나타내는 가상돔

리액트는 state가 변경될 때마다 Re-Rendering이 발생하는데 이 시점마다 새로운 내용이 담긴 가상돔을 생성하게 된다.

렌더링 이전에 화면의 내용을 담고있는 첫번째 가상돔과 업데이트 이후에 발생할 두번째 가상돔을 비교해 정확히 어떤 Element가 변했는지를 비교한다. 이를 리액트에선 Diffing이라고 표현한다.

Diffing은 효율적인 알고리즘을 사용해 진행되기 때문에 어떤 Element에 차이가 있는지를 매우 신속하게 파악할 수 있게 된다. 리액트는 이를 통해 차이가 발생한 부분만을 (브라우저상의) 실제 DOM에 적용하게 되며 이 과정을 Reconciliation(재조정)이라고 한다.

이 과정이 매우 효율적인 이유는 변경된 모든 Element들을 집단화시켜 이를 한번에 실제 DOM에 적용하는 방식인 Batch Update 때문이다.

ex. 만약 리스트안에 10개의 항목이 바뀌었다면 실제 DOM을 10번 반복해 수정하는 것이 아니라 한 번에 집단화시켜 이를 적용한다. 따라서 연산 횟수를 줄여주기 때문에 실제 DOM 보다 효울적이다

+) 그렇다면 Virtual DOM은 무조건 빠른것일까?

Virtual DOM을 사용한다고 해서 사용하지 않을 때와 비교하여 무조건 빠른 것은 아니다.

Virtual DOM의 등장배경을 보면 인터렉션이 많은 현대의 웹을 효율적으로 관리하기 위해 등장한 것을 알 수 있다. 따라서 정적인 페이지나 매우 간단한 작업에서는 오히려 리액트를 사용하지 않는 편이 더 나은 성능을 보일 수 있다.

저작자표시

'코드잇 스프린트 > Weekly paper' 카테고리의 다른 글

[코드잇 스프린트] 8주차 위클리 페이퍼 (1)	2024.04.27
[코드잇 스프린트] 7주차 위클리 페이퍼 (1)	2024.04.20
[코드잇 스프린트] 5주차 위클리 페이퍼 (이벤트 버블링, 캡쳐링, 위임 / HTTP 메소드, 멱등성) (0)	2024.04.06
[코드잇 스프린트] 4주차 위클리 페이퍼 (0)	2024.03.30
[코드잇 스프린트] 3주차 위클리 페이퍼 (0)	2024.03.23

공지사항

최근에 올라온 글

최근에 달린 댓글

Total

Today

Yesterday

링크

TAG more

« 2025/02 »
일	월	화	수	목	금	토
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28

글 보관함

I'm a Fig, Not a Pig

티스토리 뷰