LeeHyojin Blog

블로그 이전 중입니다.

Lee_hyojin — Fri, 21 Jul 2023 02:44:34 +0900

새 블로그에 적용될 로고

블로그 이전 중입니다!

그래프 VS 트리 / 실생활 예시

Lee_hyojin — Tue, 24 May 2022 21:27:03 +0900

❗️그래프의 방향 VS 무방향 / 트리의 종류들을 나누어서 설명하지는 않습니다.
각각의 자세한 설명은 여기에서 각각 확인하실 수 있습니다.

트리와 그래프 참고 이미지

위의 그림을 통해 그래프와 트리가 어떻게 생겼는지 눈으로 먼저 익혀보고, 쉽게 받아들이고 공감할 수 있도록 우리의 실생활에서

어떤 경우와 관련이 있는지 그림과 함께 연관 지어 설명해 보도록 하겠습니다.

먼저, 그림 그대로를 설명해 보면 트리는 방향(화살표)이 있고, 그래프는 방향(화살표)이 없이 선으로만 이어져 있는 것을 볼 수 있습니다.

방향이 있는 것으로 보아 트리는 계층형 모델이라는 것을 알 수 있을 것이고, 그래프는 양방향이라는 것을 알 수 있을 것이고 트리는 동그라미와 동그라미 사이에 반드시 1개의 경로만 가지고 있지만 그래프는 화살표가 따로 없는 것으로 보아 동그라미와 동그라미(이하 노드) 사이에 2개(N개)의 경로(이하 간선)를 가지고 있다는 것을 알 수 있습니다.

정리하면 트리는 노드가 N개이면 간선은 N-1개이며 비순환이기 때문에 사이클이 존재하지 않고 맨 위에 있는 노드가 루트 노드입니다.

그래프는 방향성이 없고 계층형 모델이 아니기 때문에 루트 노드의 개념이 없습니다.

그래프는 2개 이상의 경로가 가능하여 N개의 간선을 가질 수 있으며 방향성이 없고 계층형 모델이 아니기 때문에 루트 노드의 개념이 없습니다. 하지만 때에 따라 그래프도 순환/비순환 구조가 가능하며 방향성도 무방향/방향/양방향이 가능합니다.

트리보다 관계가 좀 더 자유로워서 좋은 것 같기도 하지만 방향성이 없어서 뒤죽박죽 복잡할 것 같다는 느낌이 들기도 하네요!

실생활과 연관 있는 경우 알아보기

그래프

네비게이션 / 길찾기

서울에 사는 A가 차를 타고 대전에 사는 B를 태워서 부산에 사는 C에게 놀러 가려고 합니다.
이 경우를 그래프로 나타내면 다음과 같습니다.

참고 이미지

노드 : 서울, 대전, 부산
간선
- 서울 - 대전
- 대전 - 부산
- 부산 - 서울

부산에서 서울로 바로 갈 수도 있고, 서울에서 부산으로 바로 갈 수도 있으며, 대전에서 서울, 서울에서 대전 이렇게 양방향으로 모두 이동이 가능합니다.

꼭! 대전을 들린 후에 부산으로 가야만 한다면 방향이 있는 경우가 될 수도 있겠죠.

SNS 팔로우 / 친구 추천

페이스북이나 인스타그램 등등 SNS를 하다 보면 친구의 친구가 알 수도 있는 사람 또는 친구 추천에 뜨기도 하고 팔로우 하지 않았는데도 팔로우 한 사람을 통해 건너건너 다른 사람의 피드를 볼 수 있는 경우를 경험한 적이 있을 거예요.
이 또한 그래프의 특성을 이용한 경우인데요, 그림을 통해서 나타내면 다음과 같습니다.

참고 이미지

A는 B를 팔로우하고 있고, B는 A, C, D와 서로 팔로우 하고 있습니다.

D는 A와 B를 팔로우하고 있으며 C는 B만 팔로우하고 있는 그림입니다.

A는 C와 직접적으로 팔로우를 하지 않았지만(연결된 간선이 없기 때문) B를 통해서 C를 건너 볼 수 있습니다.

D 또한 C와 직접적으로 팔로우 하지 않았지만 A를 건너 B를 건너 C를 볼 수도 있고, B를 통해서도 C를 볼 수 있습니다.

검색 엔진

유튜브나 네이버 같은 곳에서 어떠한 키워드를 검색하면 연관검색어에 비슷한 검색어나 관련된 콘텐츠들이 연관 지어 뜨는 것을 본 적이 있으실 거예요. 요즘 검색 엔진은 똑똑해서 내가 최근에 관심 있게 검색하는 것이 무엇인지 파악하고 관련된 콘텐츠나 광고들을 귀신같이 알고 여기저기 띄워주기도 하죠! 이것도 그래프의 특성을 이용한 사례입니다.

참고 이미지

포도를 검색했다고 해서 포도만 검색되는 것이 아니라 연관 검색어나 관련 콘텐츠에 포도와 관련된 다양한 키워드가 포함된 콘텐츠들이 같이 노출되고 있습니다.

마찬가지로 청포도, 과일, 거봉 등등 무엇을 검색해도 내가 검색한 콘텐츠만 나오는 것이 아니라 그래프의 특성에 따라 다양한 콘텐츠들이 함께 노출될 거예요!

트리

‍ ‍ 지휘계통(가족관계도) / 대진표

운동 경기나 체육대회 등에서 겨룰 차례를 정해 놓은 표를 보면 트리구조와 비슷한 것을 볼 수 있습니다.

참고 이미지

대진표는 월드컵을 예로 생각해 보면 쉽게 트리와 비슷하다는 것을 알 수 있습니다.
또한 위와 비슷한 구조인 지휘계통에도 사용하는데 가족관계도를 떠올리면 쉽게 이해하실 수 있습니다.

파일 시스템

컴퓨터의 파일시스템을 보면 트리구조로 구성되어있다는 것을 알 수 있습니다.

참고 이미지

Root 폴더 아래 A, B, C 폴더가 자식 노드로 있고 A 폴더 아래에는 a.txt, b.txt 파일 노드가 존재합니다.
B와 C 폴더 아래에는 자식 노드가 존재할 수도 하지 않을 수도 있습니다.

그 외

HTML Tag 구조
- HTML에 대해 아직 모르실 수 있으니 제가 정리해놓은 링크에 가시면 HTML 태그 구조를 포함하여 웹의 전체적인 렌더링 과정에 대한 설명을 통해 더 쉽게 이해할 수 있으며 트리구조와의 연관성까지 자세히 알 수 있습니다.
  알아보러가기
도 → 시군구 → 읍면동 의 주소 체계
DBMS (Database Management system)
검색 엔진
- 검색 엔진은 그래프에서 나왔는데 트리에서 왜 또 쓰이지? 언제 사용한다는 거야? 라는 생각이 들 것 같습니다! 그래프에서 사용된 것처럼 사용될 수도 있지만 여기서 말하는 검색 엔진은 그래프에서 예로 들었던 것과는 조금 다릅니다.
  말 그대로 “검색 엔진" 자체에 대한 알고리즘입니다.
  이 트리구조는 종류가 여러 가지 있는데 검색과 연관 지어 이해할 수 있도록 정리해놓은 자료가 있으니 아래의 링크에서 검색 엔진에 대한 트리구조를 자세히 알아볼 수 있습니다.
  알아보러가기

비동기처리 작동 원리, Microtask Queue & Task Queue

Lee_hyojin — Sat, 2 Apr 2022 14:29:13 +0900

Q: JS에서의 비동기처리의 작동 원리를 알고있나?

A

JS의 런타임에 메모리 할당을 담당하는 메모리 힙과 코드가 호출될 때 스택으로 쌓이는 콜스택이 있고, 콜스택은 후입선출 방식으로 실행됩니다.

JS 작동 원리에서 비동기 함수일 경우를 설명해보자면 SetTimeOut이라는 함수가 콜백함수를 가지고 호출되어 콜스택에 쌓이면 이 함수는 Web API를 호출하는 함수라서 얘가 실행되는 순간 Web API의 타이머를 호출합니다.
그 후, 타이머가 SetTimeOut의 콜백함수를 가지고 Web API에 등록을 하고 콜스택에 있는 SetTimeOut 함수는 어찌됐든 실행완료가 되었기 때문에 콜스택에서 빠져나갑니다.

이어서 다음 줄의 코드들을 콜스택에 넣고 할일을 이어서 합니다. 그리고 타이머가 가지고 있는 콜백함수는 인자에 있는 해당 초만큼의 시간이 지나면 타이머가 Callback Queue로 이 콜백함수를 넘겨주고 Event Loop는 콜스택과 콜백큐를 항상 지켜보고 있다가 콜스택이 비어있을 때, 콜백큐에 있는 이 함수를 콜스택으로 넘겨주어 콜스택에 해당 콜백함수 스택이 쌓이고 그 스택 위에는 이 콜백함수를 실행을 해야하므로 이 함수를 실행 한 스택이 쌓이게 됩니다.

Q: JS가 비동기 처리가 가능한 이유? 멀티스레드가 가능한 이유?

A

자바스크립트 언어는 기본적으로 싱글스레드 언어지만 런타임이 가지고 있는 Web API를 활용해서 멀티스레드와 같이 동기와 비동기 작업을 분류하여 진행하는 작업들을 수행할 수 있게 되어서 싱글스레드이지만 논블로킹이 가능한 이유입니다.

Web API ( DOM / AJAX / Timeout ) : 브라우저에서 가지고있고 Call Stack에서 실행된 비동기 함수는 Web API를 호출하고, Web API는 콜백함수를 Callback Queue에 밀어 넣는다.

Q: Microtask Queue VS Task Queue [ 큐에도 순서가 있다 ]

A

이벤트 루프가 스택에서 처리할 작업이 없을 경우 우선적으로는 Microtask Queue를 확인하고, Microtask Queue에 작업이 있다면
Microtask에 있는 작업을 꺼내서 콜스택에 넣고 만약 비어서 더 이상 처리할 작업이 없으면 그때 Task Queue를 확인하고 콜스택에 넣습니다.

비동기 작업으로 등록되는 작업은 task와 microtask, animationFrame 작업으로 구분된다.
microtask는 task보다 먼저 작업이 처리된다.
microtask가 처리된 이후 RequestAnimationFrame이 호출되고 이후 브라우저 렌더링이 발생한다.

Task
task는 비동기 작업이 순차적으로 수행될 수 있도록 보장하는 형태의 작업 유형입니다. 순차적으로 보장한다는 의미는 Task 사이에 브라우저 렌더링과 같은 작업이 일어 날 수 있기 때문에 Task 다음에 바로 다음 Task가 실행된다는 의미보다는 작업이 예약되어있는 순서를 보장한다는 의미가 더 적합합니다.
• setTimeout, setInterval, setImmediate, requestAnimationFrame, I/O, UI 렌더링

Microtask
microtask는 비동기 작업이 현재 실행되는 스크립트 바로 다음에 일어나는 작업이고 Task보다 항상 먼저 실행됩니다.
• process.nextTick, Promise, Object.observe, MutationObserver

CSR VS SSR / 크로스 브라우징 QA

Lee_hyojin — Fri, 1 Apr 2022 13:38:43 +0900

Q: CSR, SSR 무엇인가?

A

CSR

사용자가 Website 요청을 보내면 CDN이 HTML파일이랑 JS로 접근할 수 있는 링크를 클라이언트로 보내고 클라이언트는 이 파일들을 받아서 실행하고 데이터를 위한 API가 호출됩니다. 서버사이드렌더링 때와는 다르게 클라이언트가 파일들을 받아서 실행하는 그 사이에 사용자는 아무것도 볼 수가 없고, 데이터를 위한 API가 호출 됐을 때는 placeholder 의 정보들이 보입니다. 서버가 API로부터 요청에 응답하고 API로부터 받아온 data를 placeholder자리에 넣음으로써 상호작용이 시작됩니다.

[ 서버에서 처리 없이 클라이언트로 보내주기 때문에 자바스립트가 모두 다운로드 되고 실행이 끝나기 전까지 사용자는 볼 수 있는게 없습니다 ]

SSR

사용자가 Website 요청을 보내면 Server는 즉시 렌더링 가능한 HTML파일을 만들어서 클라이언트에 전달을 합니다. 클라이언트에 전달 되면 HTML은 즉시 렌더링 가능하기 때문에 렌더링이 되고 클라이언트가 JS를 컴파일하는데 그 동안은 JS는 컴파일하기 전이기 때문에 사이트 조작은 불가능한 상태입니다. 아, 그리고 JS 컴파일하고 있는 사이에 사용자는 컨텐츠는 볼 수 있지만 조작만 불가능한 상태라서 사용자의 조작을 기억하고 있다가 브라우저가 JS를 실행하면 기억하고 있던 사용자의 조작이 실행되면서 웹페이지랑 상호작용이 가능하게 되는게 서버 사이드 렌더링 입니다.

Q: CSR, SSR 차이점은 무엇인가?

A

웹페이지를 로딩하는 시간에서 첫 페이지일 경우에는 CSR의 경우 모든 파일들을 한번에 불러오기 때문에 필요한 부분의 파일만 불러오는 SSR보다 CSR이 평균적으로 더 느립니다.

하지만 나머지 로딩 시간은 CSR은 이미 첫 페이지 로딩할 때 다 받아놓았기 때문에 빠른데, SSR은 첫 페이지 로딩 과정을 다시 실행해야 해서 더 느립니다.

SEO 대응에서도 차이가 나는데 크롤러로 웹사이트를 읽으면서 CSR은 JS를 실행시켜 동적으로 컨텐츠가 생성되기 때문에 자바스크립트가 실행되어야 메타데이터가 바뀌는데 SSR은 애초에 서버 사이드에서 컴파일되어 넘어오기 때문에 크롤러에 대응하기 용이합니다.

Q: 언제 어떤걸 사용해야 하는가?

A

CSR

네트워크가 빠를 때
서버 성능이 좋지 않을 때
사용자에게 보여줄 데이터의 양이 많을 때
메인 스크립트가 가벼울 때

SSR

네트워크가 느릴 때
검색 엔진 최적화가 필요할 때
최초 로딩이 빨라야 하는 사이트 개발이 필요할 때

Q: 크로스 브라우징은 무엇이며 해야하는 이유는?

A

크로스 브라우징은 브라우저마다 렌더링 엔진이 다 다르기 때문에 웹페이지 제작 시 의도한 대로 나오지 않거나 깨지는 현상들을 웹 표준 기술을 이용하여 모든 브라우저에서 깨지지 않고 의도한 대로 나올 수 있게 하는 작업 입니다.

크로스 브라우징을 해야하는 이유는 크롬이나 익스플로러 외에도 파이어폭스나 사파리, 엣지 등등의 여러 브라우저들은 저마다 각각 다른 속성들을 가지고있기 때문에 동일하게 코드를 작성한다해도 브라우저마다 다르게 보일 수 있어서 적어도 표준 웹기술을 사용하여 비슷하게 맞춰주어 사용자가 방문했을 때 정보로서의 소외감을 느끼지 않도록 해야하기 때문입니다.

OOP와 함수형 프로그래밍 QA

Lee_hyojin — Fri, 1 Apr 2022 08:13:37 +0900

Q: OOP 특징에 대한 설명이 가능한가?

A

OOP란 Object Oriented Programming으로 객체지향 프로그래밍이라고 하며, 4가지의 특징이 있습니다.
상속은 클래스 개념에서 부모 클래스로부터 자식 클래스가 유산을 물려받는것과 같이 부모의 메소드나 변수를 사용할 수 있는 것을 말하고, 다형성은 같은 함수가 있다고 가정하면 그 함수가 매개변수에 따라 다른 역할을 할 수 도 있는 것이고, 캡슐화는 보통 데이터를 은닉 시킨다고 표현하는데, 외부에서 쉽게 데이터를 접근할 수 없게 만들기도 하고, 데이터 구조와 데이터를 다루는 방법들을 한곳에 묶는 것을 말합니다.

추상화는 공통적인 속성이나 기능을 묶어서 이름을 붙이는 것입니다. [ 예: a,b,c가 있다면 이것은 영어로 묶을 수 있습니다 ]

Q: 함수형 프로그래밍에 대해 설명이 가능한가?

A

함수형 프로그래밍은 같은 입력 값이라면 항상 같은 결과 값을 반환하며 side-effects를 가지지 않고, 공유되는 스코프안에 존재하는 모든 변수, 객체, 메모리 공간 또는 스코프 간에 전달되는 객체의 속성으로 공유 상태, 그리고 생성된 이후에도 변경 가능한 데이터와 side-effects를 피하려는 프로그래밍 입니다.

또한, 함수형 프로그래밍은 명령적이라기보단 선언적이며 어플리케이션의 상태의 흐름이 순수함수를 통해 흐릅니다.

Q: 함수형 프로그래밍 개념에서 순수함수가 무엇인가?

A

순수함수는 같은 입력이 주어지면, 같은 출력을 반환해야하고, side effect(부작용) 가 없어야 합니다.

결국, 함수형 프로그래밍은 순수함수를 통해 sideeffect를 최대한 억제하여 오류를 피하고 프로그램의 안정성을 높이려는 노력의 한 방법입니다.

Q: OOP와 함수형 프로그래밍의 가장 큰 차이점은 무엇인가?

A

객체지향은 객체 안에 상태를 저장하고, 이 상태를 이용해서 메소드를 추가하고 상태변화를 설정하고 조정하기위해 다양한 기능을 사용하고 함수형 프로그래밍은 상태를 제어하는것보다 상태를 저장하지 않고 없애는데 더 주력합니다.
예를들면, 객체 지향은 상태를 저장하는 필드와 그 필드들을 이용해 기능을 제공하는 메소드를 만들고 클래스를 만드는 반면에 함수형은 몇몇 자료구조(list, map, set) 등을 이용해 최적화된 동작을 만들어냅니다.

클로저와 호이스팅에 대한 QA

Lee_hyojin — Thu, 31 Mar 2022 18:11:22 +0900

Q: 클로저가 무엇이며 장단점은 무엇인가?

A

A라는 함수가 있고 B라는 함수가 있다고 가정하고 A함수는 B함수 자체를 값으로 넘김으로써 B함수를 참조하는 함수 객체 자체를 반환합니다. B함수는 함수가 선언된 Lexical Environment 밖에서 실행 됐고 B함수가 선언된 위치 때문에 A함수의 Environment에 대한 Lexical Environment 클로저를 가지고, A함수는 B함수가 나중에도 참조할 수 있도록 Environment를 살려두어서 B함수가 계속 참조를 가지게 되는데 이 참조를 클로저라고 부릅니다.

예를들어 A를 실행하여 변수 C에 할당했는데 다른 코드를 실행하다가 어느 순간 C를 또 실행해야 하면 A는 B가 리턴되려면 C를 실행해야하기 때문에 GC에 의해 사라지면 안되는 것입니다.

** 장점 **

전역 변수의 남용을 막을 수 있고 (잦은 함수 호출로 인한 퍼포먼스 손해 등등) 변수 값을 은닉(캡슐화)할 수 있다.
특정 데이터를 스코프 안에 가두어 둔 채로 계속 사용할 수 있게하는 폐쇄성을 이용하여 데이터를 보존할 수 있다.
클로저 함수를 각각의 변수에 할당하면 각자 독립적으로 값을 사용하고 보존할 수 있기 때문에 재사용성에 좋고, 함수 하나를 독립적인 부품의 형태로 분리할 수 있다. (모듈화)

** 단점 **

메모리를 소모한다. 특정 데이터를 계속 사용할 수 있는 장점이 단점이 될 수도 있다. 메모리의 소모는 리턴하거나 타이머, 콜백 등으로 위에 있는 코드처럼 등록했던 함수들이 메모리에 계속 남아있게 되면 해당하는 클로저도 같이 메모리에 계속 남아있기 때문에 지속적으로 루프를 돌면서 클로저를 생성한다.
environment(scope) 생성에 따른 퍼포먼스 손해가 있다. 클로저는 하나의 새로운 environment(scope)를 생성하여 내부의 함수에 링크 시키기 때문에 이에 따른 퍼포먼스 손해도 감수해야한다. 즉, 자신이 선언될 당시의 환경을 기억하는 함수이기 때문에 퍼포먼스 저하가 있을 수 있다.

Q: 호이스팅이 무엇인가?

A

함수와 변수가 코드를 실행하기 전에 실행컨텍스트를 위해서 메모리에 저장되는 것을 호이스팅이라고 합니다.

함수같은 경우는 전체 함수에 대한 참조와 함께 저장되고 var키워드가 있는 변수는 undefined, let과 const는 초기화되지 않은 상태로 메모리에 저장됩니다.

단지, 실행 전에 어떠한 과정을 거쳐서 변수와 함수에 대한 전체적인 정보를 미리 알고있을 뿐인 것 같아요.
함수와 변수가 다른 것은 선언된 함수와 var는 상단에서 참조, 호출이 가능하고, 선언된 let, const는 불가능하다는 것입니다.

함수 호이스팅은 가장 먼저 이루어지는데, 이 함수 호이스팅은 선언문에만 해당됩니다. 그래서 표현식은 결국 어떠한 변수에 함수를 할당하는 것이라서 변수 호이스팅으로 봅니다.

최적화에 대해 알아보며 나한테 묻는 QA

Lee_hyojin — Thu, 31 Mar 2022 17:27:05 +0900

Q: 애니메이션의 최적화와 Reflow / Repaint 개선 방법은?

A

먼저, 컨텍스트 관점에서의 최적화는 CSS 애니메이션 중에 Transform과 Opacity와 같은 속성 변경은 컴포지터 스레드에서 처리되어서 메인 스레드와 병렬 처리가 가능하지만, JS 애니메이션은 항상 메인 스레드에서 처리되기 때문에 블로킹이 발생할 수 있습니다.
따라서, JS에서 처리되고 있는 애니메이션 중 CSS로 처리가 가능한 애니메이션을 CSS에서 처리함으로써 성능 개선이 될 수 있습니다.

리플로우 개선으로는 애니메이션이 들어간 요소의 Position은 Fixed나 absolute로 지정한다거나, 인라인 스타일을 최소화시키고 ClassName의 변화에 따라 스타일이 변경될 경우 Reflow를 완전히 피할 수는 없지만 DOM 구조상 말단에 위치한 노드에 해당 ClassName을 주어 리플로우의 행동반경을 전체가 아닌 일부 노드로 제한 시켜줄 수 있습니다.

Q: RequestAnimationframe을 사용한 성능개선

A

자바스크립트로 애니메이션을 구현할 때, 1초에 60프레임정도를 찍어내면 되는데 이 프레임을 찍어내기 위해 사용할 수 있는 방법은 SetInterval과 RequestAnimationFrame이 있습니다.
SetInterval 보다 RequestAnimationFrame이 더 좋은 이유는 브라우저가 프레임 생성 초기 단계에 맞춰서 애니메이션 코드를 실행시키기 때문에 더 부드럽게 동작하고, 타임아웃이나 인터벌은 프레임을 신경쓰지 않고 동작해서 뚝뚝 끊기는 현상이 일어날 수 있는데 RequestAnimationframe을 사용하면 프레임 생성 시작시간에 맞춰 코드를 시작하기 때문에 최적화된 부드러운 속도로 표현할 수 있고 성능도 개선할 수 있습니다.

Q: 함수를 분리함으로써 얻는 이점은?

A

하나의 함수에 비즈니스가 너무 몰려있고 그래서 그 안에 변수 혹은 함수가 너무 많아져서 생기는 문제들을 함수를 분리해 줌으로써 react에서 제공하는 Hooks API를 통해 최적화가 가능하며 재사용성도 높아지고 콜스택의 부담도 덜어줄 수 있습니다.

또한 비즈니스가 몰리다보니까 함수 안에 함수가 구현되어 호출되는 경우도 있을 수 있는데 GC로 처리되어야 하는 함수임에도 불구하고 참조가 계속 발생되어 GC가 처리하지 못해서 메모리 누수가 발생하는 경우도 해결할 수 있습니다. [ 클로저의 단점 ]

Execution Context 알아보며 나한테 묻는 QA

Lee_hyojin — Wed, 16 Mar 2022 08:38:27 +0900

Q: Execution Context은 왜 필요한가?

A: 코드가 실행되는 환경이자 실행 가능한 코드가 되기 위해서 필요한 환경입니다.

실행 컨텍스트(Execution Context)는 함수를 호출했을 때 생성됩니다.
JS엔진은 코드를 실행하기 위해서 실행에 필요한 여러가지 정보를 알고 있어야 하는데 실행 컨텍스트가 활성화 될 때, JS엔진은 해당 컨텍스트의 코드를 실행하는데 필요한 환경 정보들을 수집에서 실행 컨텍스트에 저장합니다.

제가 생각하기에 실행 컨텍스트로 인해 얻을 수 있는 장점(필요성)을 몇가지 정리해보았습니다.

전체 코드의 환경과 순서를 보장하기 위해 필요합니다.
코드가 여러번 실행되어도 정보들을 저장해둔 덕분에 동일한 환경을 구성할 수 있습니다.
선언에 의해 생선된 모든 식별자들의 변화들을 지속적으로 관리하기 위해 스코프를 구분하여 등록하여 스코프 체인을 통해 상위 스코프로 이동하여 식별자 검색이 가능해지며, 실행 순서를 변경할 수도 있고 다시 되돌아갈 수도 있습니다.

Q: Lexical Environment 가 생성되는 시점은 언제인가?

A: Execution Context가 생성되는 시점에 Lexical Environment가 생성됩니다.

var a = 10;
var b = 20;

function foo(){
  console.log('bar');
}

// Global Lexical Environment
LexicalEnvironment = {
  a: 10,
  b: 20,
  foo: <function object>
}

Q: Lexical Environment가 수집하는 정보와 가지고 있어야 하는 이유는?

A: 수집하는 정보는 현재 실행 컨텍스트에 대한 변수나 참조에 대한 정보를 갖고있습니다.

이 정보들을 가지고 있어야하는 이유는 현재 실행 컨텍스트에서 변수나 어떤 값들을 가져올 때 어디서 가져올 것이냐를 판단하기 위해서입니다. 또 다른 이유로 현재 실행 컨텍스트를 기준으로 외부 컨텍스트를 참조하는 공간에 대한 정보도 들어있게 되는데 유효범위가 중첩되었을 때, 상위 유효범위를 참조해야하기 때문에 이 정보들을 가지고 있어야 합니다.

(지금 실행되고있는 컨텍스트 내부에서 찾고자하는 식별자가 없을 경우 상위 컨텍스트로 올라가 검색하기 위함 : 스코프체인)

DOM 알아보며 나한테 묻는 QA

Lee_hyojin — Tue, 15 Mar 2022 21:41:22 +0900

Q: DOM과 HTML의 차이점은?

A: DOM은 HTML 문서로부터 생성이 되지만 항상 동일하지는 않습니다.

HTML은 화면에 보이고자 하는 구조를 문서화 한 것으로 단순 텍스트로 구성되어 있고,
DOM은 HTML 문서의 내용과 구조가 Object Model로 변화되어 실제 화면에 나타나는 인터페이스 입니다.

<!DOCTYPE html>
<html>
  DOM과 HTML의 차이점은?
</html>

&amp;lt;head&amp;gt; 태그와 &amp;lt;body&amp;gt; 태그가 채워져 있고, Text 또한 잘 출력되고 있다.

위와 같이 HTML 규칙의 필수 사항인 요소들이 빠져있지만 DOM트리에는 올바르게 교정되어 나타난 것을 보아 유효하지 않은 HTML 코드들을 DOM을 생성하는 동안 규칙에 맞게 교정하고 있는 것을 알게 되었습니다.

또한 JavaScript로 DOM을 수정할 때에도 마찬가지입니다.

let p = document.createElement('p');
let PText = document.createTextNode('DOM과 HTML의 차이점은?');
p.appendChild(pText);
document.body.appendChild(p);

이유는 DOM은 HTML문서의 내용을 볼 수 있는 인터페이스 역할을 하는 동시에 동적 자원이 되기도 해서 수정이 가능합니다.

따라서 DOM에 노드를 추가하는 코드로 업데이트는 했지만 HTML에 직접 작성한 것은 아니므로 문서의 내용을 변경한 것은 아닙니다.

Q: DOM은 브라우저에서 볼 수 있을까? 있다면(없다면) 이유는?

A: DOM 브라우저에서 보이는 것이 아닙니다.

Render Tree는 DOM과 CSSOM의 조합으로 최종적으로 브라우저에 나타낼 노드들만 선별되어 트리가 생성이 됩니다.

때문에 시각 적으로 보여지지 않는 요소들은 제외되기 때문에 DOM과는 다릅니다.

이런 이유가 DOM Tree와 Render Tree의 차이점이기도 합니다.

Q: DOM은 개발자도구에서 볼 수 있을까? 있다면(없다면) 이유는?

A: 엄밀히 말하면 DOM은 개발자도구에서 보이는 것이 아닙니다.

개발자도구 요소 검사기는 DOM과 가장 가까운 근사치를 보여주긴 하지만 DOM에 없는 추가적인 정보까지도 포함하고 있습니다.

예를들어 CSS의 가상요소를 사용하여 생성된 요소는 CSSOM과 Render Tree의 일부를 구성하지만 DOM은 오직 원본 HTML 문서로부터 빌드되고, 요소에 적용되는 스타일은 포함되지 않기 때문에 DOM의 일부는 아닙니다.

브라우저의 렌더링 과정 & Render Tree와 DOM Tree의 차이점

Lee_hyojin — Tue, 15 Mar 2022 20:36:18 +0900

렌더링 트리 생성 과정

1. 객체 모델 (Object Model) 생성

<< DOM 객체를 구성하는 과정 >>

DOM 객체를 구성하는 과정

변환
HTML 코드가 있으면 렌더링 엔진은 HTML의 원시 바이트를 디스크나 네트워크에서 읽어와서, 해당 파일에 대해 개별 문자로 변환한다.
토큰화
개별 문자로 변환된 것을 HTML5 표준으로 지정된 고유 토큰으로 변환한다. 각 토큰은 고유한 의미와 규칙을 가진다.
DOM 생성
마지막으로 HTML 마크업이 여러 태그 간의 관계를 정의하기 때문에 생성된 객체는 트리 데이터 구조 내에 연결된다.
이 트리 데이터 구조에는 마크업에 정의된 상위-하위 관계를 포함한다. (ex: HTML 객체는 body 객체의 상위라는 관계다.)
이렇게 구성된 DOM 트리는 HTML 문서 마크업의 속성과 각 노드의 관계에 대한 정보를 가지고 있지만, 아직 이 요소들이 렌더링 될 때 어떻게 표시할지에 대해서는 알 수가 없다. 이는 CSSOM의 역할이다.

<< CSSOM 객체를 구성하는 과정 >>

렌더링 엔진이 HTML DOM을 생성하면서 외부 CSS StyleSheet 파일을 참조하는 <head> 섹션에서 링크 태그를 접하면, 이 리소스에대한 요청을 네트워크 레이어에 즉시 발송하고 요청의 결과로 css 파일을 응답받는다.
HTML과 마찬가지로 수신된 CSS규칙을 렌더링 엔진이 이해하고 처리할 수 있는 형식으로 변환해야 한다.

HTML처럼 CSS도 바이트가 문자로 변환되고 -> 토큰으로 변환 -> 노드로 변환 -> 마지막으로 CSSOM이라는 트리 구조에 링크가 된다. CSSOM이 트리구조를 가지는 이유는, 최상의 노드에서 하위로 내려갈수록 더욱 구체적인 규칙을 적용하는 방식이기 때문이다.

즉, 스타일을 하향식으로 구체화한다. 또 여기서 구성된 CSSOM 트리는 개발자가 스타일시트에서 정의하도록 직접 작성한 스타일만 표시가 된다.

2. Rendering Tree 구축, 배치, 그리기

DOM 트리와 CSSOM 트리는 독립적인 객체다. 이 두 가지를 결합하여 렌더링 트리를 형성해야 브라우저가 화면에 픽셀을 렌더링 할 수 있다.

<< 렌더링 트리 구축 >>

DOM 트리의 루트에서부터 시작하여 페이지를 렌더링하는데 필요한 노드만 남긴다.
스크립트 태그나 메타 태그 같은 요소는 렌더링에 반영되지 않고, css의 display: none; 속성도 렌더링 트리에 포함되지 않는다.
하지만 visibility: hidden;은 보이지는 않지만 공간을 차지하기 때문에 렌더링 트리에 포함된다.
화면에 표시되는 모든 노드의 컨텐츠 및 스타일 정보들을 포함하는 구조로 이루어진 렌더링 트리가 최종적으로 구축된다.

<< 렌더링 트리 배치 >>

사용자의 뷰포트 기준으로 렌더링 트리가 그려질 위치와 크기들을 계산하는 단계이다.
페이지에서 각 객체의 정확한 크기와 위치를 파악하기 위해 렌더링 엔진은 다시 렌더링 트리의 루트에서부터 계산에 들어간다.
각 노드들의 정확한 위치와 크기가 계산되어 레이아웃이 완료되면 렌더링 엔진은 Paint Setup 및 Paint 이벤트를 발생시킨다.

<< 렌더링 트리 그리기 >>

이 과정에서 스타일이 복잡할 수록 페인팅에 걸리는 시간이 늘어난다. 이렇게 렌더링 과정을 거치게 되며 만약 DOM이나 CSSOM이 수정되면 화면에 다시 렌더링할 필요가 있는 픽셀을 파악하려면, 전부 처음부터 반복해야한다.

브라우저 렌더링 과정 ( Browser Rendering Process )

사용자가 주소표시줄에 URL을 입력하고 엔터를 치는 순간부터 브라우저의 각 요소는 상호작용을 하며 웹페이지를 화면에 띄운다.

1. 브라우저 엔진이 사용자 인터페이스로부터 URI를 받아 자료 저장소를 찾는다.

** URI 와 URL의 차이점 **
URI: URI는 특정 리소스를 식별하는 통합 자원 식별자(Uniform Resource Identifier)를 의미한다. 웹 기술에서 사용하는 논리적 또는 물리적 리소스를 식별하는 고유한 문자열 시퀀스다.
URL: URL은 흔히 웹 주소라고도 하며, 컴퓨터 네트워크 상에서 리소스가 어디 있는지 알려주기 위한 규약이다. URI의 서브셋이다.

사용자가 주소창에 입력하는 순간 브라우저 엔진에게 전달하고, 브라우저 엔진은 주소 값에 해당하는 데이터를 먼저 자료 저장소에서 찾아본다.

사용자가 URI를 입력할 때마다 항상 서버로 가서 똑같은 데이터를 받아 오는게 아니라, 불필요한 통신을 줄이기 위해 자료 저장소에 자주 방문하는 사이트의 데이터를 저장해둔다. 이것을 캐싱이라고 한다.

캐시에 대해 더 알아보기 위해 참고할 링크

따라서, 브라우저 엔진은 URI에 해당하는 자료를 자료 저장소에서 찾고, 있으면 그대로 렌더링 엔진에게 준다.

2. 렌더링 엔진이 브라우저 엔진 또는 네트워크 레이어로부터 자료를 받는다.

캐싱된 자료가 있다면 ? 렌더링 엔진은 브라우저 엔진으로부터 자료를 받아 HTML, CSS, image 등을 파싱.

캐싱된 자료가 없다면 ? 서버에 요청해서 자료를 찾아온다.

이 경우 렌더링 엔진에게 사용자가 입력한 주소값(URI)를 전달하고 렌더링 엔진은 통신 레이어에 전달한다.
통신 레이어는 URI 주소 값으로 서버에 요청을 보내고, 응답으로 주소 값에 해당하는 HTML, CSS, JS 값을 받으면 렌더링 엔진에게 준다.

3. 렌더링 엔진이 자바스크립트 해석기 및 네트워크와 소통하며 렌더링 구조를 그려 UI 백엔드에 넘긴다.

UI 백엔드란?
렌더링 엔진에서 생성된 렌더 트리를 브라우저에 그리는 역할을 한다. (페인트 작업)

렌더링 과정의 중추 역할을 하는 렌더링 엔진이 HTML과 CSS를 파싱하여 렌더링 트리로 변환하는 과정을 거친다.
렌더링 엔진은 브라우저 엔진으로 받거나 통신 레이어로부터 넘겨받은 리소스 중, HTML과 CSS는 직접 파싱하고, JS는 크롬 기준 V8엔진으로 파서에게 전달하여 파싱한다. 파싱한 결과를 렌더링 엔진에게 다시 전달하여, 파싱한 HTML의 결과인 DOM Tree를 자바스크립트로 조작한다. 조작이 완료된 DOM 트리 구성요소는 렌더링 트리 구조로 변환되고, 이렇게 최종적으로 만들어진 Render Object를 렌더링 엔진이 UI 백엔드에 주어서 화면에 페인팅해준다.

Render Tree와 DOM Tree의 차이점

Render Tree는 DOM과 CSSOM을 합한 후에 최종적으로 브라우저에 표기할 노드들만 선별되어 트리가 생성이 된다.
DOM은 브라우저에 보이는 것이 아니고 Render Tree는 브라우저에 보이는 것이다.
뷰포트에 무엇을 렌더링할지 결정하기 위해 사용되는 것이 DOM이고 Render Tree는 뷰포트에 무엇을 렌더링할지 결정된 최종적인 트리다.