CS겸 취준까지

Proxy(Object.defineProperty와 비교)

H.E — Wed, 12 Jun 2024 20:43:21 +0900

프록시(Proxy)

Proxy는 특정 객체를 감싸 프로퍼티 읽기, 쓰기와 같은 객체에 가해지는 작업을 중간에서 가로채는 객체로,

가로채진 작업은 Proxy 자체에서 처리되기도 하고, 원래 객체가 처리하도록 그대로 전달 되기도 함

Proxy의 사전적 뜻은 '대리인', '대리'라는 뜻으로 자바스크립트에서도 대리인의 역할을 수행함

프록시 객체(Proxy object)는 대상 객체(Target object) 대신 사용됨

대상 객체를 직접 사용하는 대신, 프록시 객체가 사용되며 각 작업을 대상 객체로 전달하고 결과 다시 코드로 돌려줌

이러한 방식을 통해 프록시 객체는 자바스크립트의 기본적인 명령에 대한 동작을 사용자 정의 가능하도록 함

객체 자체가 처리하는 특정 명령을 정의할 수 있게 되는 것

이런 명령의 종류는 속성검색, 접근, 할당, 열거, 함수 호출 등이 대표적

▶ Proxy 사용법

// 대상 객체(Real Subject)
let target = { ... }

// target의 동작을 가로채어 제어하는 미리 정의된 메서드 내부를 구현한 핸들러
let handler = {
    get(target, prop) { ... },
    set(target, prop, value) { ... },
    ...
}

// 프록시 생성 및 등록
const proxy = new Proxy(target, handler)

프록시 객체를 생성하기 위해 new를 붙여 생성자를 호출해야 함

Proxy는 필수적으로 2개의 인자를 받음

target : Proxy의 대상이 되는 객체(감싸질 객체, 함수를 포함한 모든 객체가 가능)
handler : target의 동작을 제어하는 메서드를 정의한 객체(get, set 등 메서드를 정의한 것을 볼 수 있는데 이 메서드들은 target 객체의 동작을 중간에 가로채서 제어 로직을 가미하게 하는 미리 정의된 메서드, 트랩(trap)이라고 부름)
- ex) get 트랩은 target의 프로퍼티를 읽을 때, set 트랩은 target의 프로퍼티를 쓸 때 활성화됨

proxy에 작업이 가해지고, handler에 작업과 상응하는 트랩이 있으면 트랩이 실행되어 프록시가 이 작업을 처리할 기회를 얻게 됨(트랩이 없으면 target에 작업이 직접 수행됨)

Proxy 예제

// 대상 객체 (target)
const user = {
    firstName: 'John',
    lastName: 'Doe',
    email: 'john.doe@example.com',
}

// 핸들러 (handler)
const handler = {
	// 대상 객체에 프로퍼티 값을 할당하려는 동작(get)을 가로채어 실행
    get(target, property) {
        console.log(`Property ${property} has been read.`);
        return target[property];
    }
}

const proxyUser = new Proxy(user, handler);

console.log(proxyUser.firstName);
// Property firstName has been read
// John

이때 주의할점은 클라이언트는 프록시 객체인 proxyUser를 통해 접근해야 된다는 점

user 객체를 프록시 객체가 감싸고 있는 형태이기 때문에 외부 포장과 같은 프록시를 통해 대상 객체인 user와 통신하게 되기 때문(콘솔 로그를 실행하면 원래는 값만 나와야 되는것이 다음과 같이 추가적으로 코드(콘솔)가 가미됨을 볼 수 있음)

Proxy 트랩 핸들러 종류

Property 가로채는 트랩	작동 시점
get	프로퍼티를 읽을 때
set	프로퍼티에 값을 쓸 때
has	in 연산자가 작동할 때
deleteProerty	delete 연산자가 작동할 때

Method 가로채는 트랩	작동 시점
apply	함수를 호출할 때
constructor	new 연산자가 작동할 때

Object 가로채는 트랩	작동 시점
getPrototypeOf	Object.getPrototypeOf 작동할 때
setPrototypeOf	Object.setPrototypeOf 작동할 때
isExtensible	Object.isExtensible 작동할 때
preventExtensions	Object.preventExtensions 작동할 때
getOwnPropertyDescriptor	Object.getOwnPropertyDescriptor 작동할 때
ownKeys	Object.getOwnPropertyNames 작동할 때 Object.getOwnPropertySymbols 작동할 때

▶ Proxy 해제하기

쓸모없어진 프록시 객체를 해체하여 메모리 측면에서 여유공간을 얻고싶다면 Proxy를 해제하면 됨
Proxy 객체의 Target 원본 객체를 null로 해버리면 자동으로 해체될것 같아 보이지만 반영되지 않음

따라서 직접 명시적으로 프록시 객체를 제거할 필요가 있음

프록시를 해지하지 위해선, 처음 부터 취소 가능 프록시(Revocable Proxy)로 정의할 필요가 있는데, Proxy.revocable()를 통해 얻을 수 있는 revoke를 이용해서 Target 객체를 참조하던 Proxy 객체를 해제할 수 있음

let obj = {
    name: '홍길동',
};

let handler = {
    get(target, key) {},
    set(target, key, value) {},
};

// 취소 가능한 프록시 객체를 구조분해로 얻기
const { proxy, revoke } = Proxy.revocable(obj, handler);

try {
    revoke(); // 프록시 해제
    proxy.name = "임꺽정"; // !프록시 사용 불가
} catch (err) {
    console.error(err.message); // Cannot perform 'set' on a proxy that has been revoked
}

▶ Proxy를 사용하는 이유

객체에 어떤 작업을 할 땐 자바스크립트 명세서에 정의된 '내부메서드'가 깊숙한 곳에서 관여함

프로퍼티를 읽을 땐 [[Get]]이라는 내부 메서드가, 프로퍼티에 쓸 땐 [[Set]]이라는 내부 메서드가 관여하게 됨

이런 내부 메서드들은 명세서에만 정의된 메서드이기 때문에 개발자가 코드를 사용해 호출할 순 없음

프록시 기능 활성화 예제(get 가로채기)

let numbers = [0, 1, 2];

numbers = new Proxy(numbers, {
  get(target, prop) {
    if (prop in target) {
      return target[prop];
    } else {
      return 0; // 기본값
    }
  }
});

객체에 없는 프로퍼티를 호출했을 때, undefined가 아닌 0이 출력
자바스크립트의 내부 메서드 GET을 통해, 객체에 없는 프로퍼티를 읽으면 undefined가 출력되게 되어있음
하지만, 프록시로 0이 출력되도록 한 것

이것이 프록시의 기능

Proxy와 Object.defineProperty

▶ Object.defineProperty

Object.defineProperty()는 JavaScript에서 객체의 프로퍼티를 정의 또는 수정하는 메서드

메서드를 사용하면 객체에 새로운 프로퍼티를 추가하거나 기존 프로퍼티의 속성을 변경할 수 있음

즉, 객체에 새로운 속성을 직접 정의하거나 이미 존재하는 속성을 수정한 후 해당 객체를 반환함

defineProperty 인수

Object.defineProperty(obj, prop, descriptor);

const person = {};
Object.defineProperty(person, 'firstName', {
	value: 'Ungmo',
  	writable: true,
  	enumerable: true,
  	configurable: true
}

obj: 속성을 정의할 객체(반환값으로 obj 객체를 반환함)
prop : 새로 정의하거나 수정하려는 속성의 이름 또는 Symobl
descriptor: 새로 정의하거나 수정하려는 속성을 기술하는 객체
- value(속성값) : undefined
- get(속성 접근자 함수) : undefined
- set(속성 설정자 함수): undefined
- writable(속성의 값 변경 가능 여부) : false
- enumerable(열거 가능 여부) : false
- configurable(속성 값 변경/삭제 여부) : false

- [value, writable]과 [get, set]은 동시에 사용할 수 없음

즉, [value, writable] 중 하나(또는 전체)와 [get, set] 중 하나(또는 전체)를 함께 사용할 수 없음

특징	Proxy	Object.defineProperty
문법	new Proxy(target, handler)	Object.defineProperty(obj, prop, desc)
유형	메타 프로그래밍 도구	속성 설명자 도구
호환성	ES6 이상	ES5 이상
직접적 상호작용	대상에 대한 모든 작업을 가로챔	객체의 단일 속성에만 영향을 줌
사용	전체 객체의 동작 수정	단일 속성의 동작 수정
성능	가로채리고 인한 일반적으로 느림	직접 속성을 수정하므로 더 빠름
확장성	동작에 대한 세부적인 제어 제공	기본 속성 설명자로 제한됨
사용 사례	고급 객체 조작, 유효성 검사	특정 동작을 가진 새로운 속성 추가

- 메타 프로그래밍: 프로그램이나 언어를 조작하는 것을 의미

메타 프로그래밍 도구는 프로그램의 동작이나 구조를 변경하고 확장하기 위해 사용되는 도구들을 가리킴

Proxy를 사용하면 객체의 동작을 가로채거나 수정하여 객체에 대한 접근을 제어하거나 변경 이를 통해 객체의 동작을 수정하거나 확장하여 메타 프로그래밍 작업을 수행할 수 있음

Reference

[JS] 자바스크립트의 Proxy

자바스크립트 Proxy & Reflect 고급 기법

Object.defineProperty()

프로퍼티 정의(object.defineProperty) 마스터 하기

정규화(Normalization)

하계동물고기 — Wed, 12 Jun 2024 19:36:11 +0900

정규화 란?

정규화는 관계형 데이터베이스에서 데이터를 구조화하고 중복을 줄이며 데이터의 일관성을 유지하기 위한 과정이다.

이를 통해 데이터베이스의 성능을 향상시키고 데이터의 무결성을 확보할 수 있다.

정규화는 주로 엔티티 간의 관계를 분석하여 데이터를 논리적인 단위로 나누는 작업이다.

정규화의 기본 목표는 테이블 간에 중복된 데이터를 허용하지 않는다는 것이다.

중복된 데이터를 허용하지 않음으로써 무결성을 유지할 수 있으며, DB용량 역시 줄일 수 있다.

정규화 단계

정규화는 여러 단계로 진행되며, 각 단계는 정규형(Normal Form)이라고 불리는 기준을 충족해야 한다.

각 정규형은 데이터의 구조를 조금씩 변경하여 중복과 종속성을 제거하며, 더욱 높은 수준의 일관성을 유지한다.

제 1 정규화

제 1 정규화란 테이블의 컬럼이 원자값(Atomic Value, 하나의 값)을 갖도록 테이블을 분해하는 것이다.

예를 들어 아래와 같은 고객 취미 테이블이 존재한다고 하자.

위의 테이블에서 추신수와 박세리는 여러 개의 취미를 가지고 있기 때문에 제 1 정규형을 만족하지 못하고 있다.

그렇기 때문에 이를 제 1 정규화하여 분해할 수 있다. 제 1 정규화를 진행한 테이블은 아래와 같다.

제 2 정규화

제 2 정규화란 제 1 정규화를 진행한 테이블에 대해 완전 함수 종속을 만족하도록 테이블을 분해하는 것이다.

  Info. 완전 함수 종속 : 완전 함수 종속이라는 것은 기본키의 부분집합이 결정자가 되어선 안된다는 것을 의미한다.

예를 들어 아래와 같은 수강 강좌 테이블을 살펴보자.

이 테이블에서 기본키는 (학생번호, 강좌이름)으로 복합키이다.

그리고 (학생번호, 강좌이름)인 기본키는 성적을 결정하고 있다.

(학생번호, 강좌이름) --> (성적)

그런데 여기서 강의실이라는 컬럼은 기본키의 부분집합인 강좌이름에 의해 결정될 수 있다.

(강좌이름) --> (강의실)

즉, 기본키(학생번호, 강좌이름)의 부분키인 강좌이름이 결정자이기 때문에 위의 테이블의 경우 아래와 같이 기존의 테이블에서

강의실을 분해하여 별도의 테이블로 관리하여 제 2 정규형을 만족시킬 수 있다.

제 3 정규화

제 3 정규화란 제 2 정규화를 진행한 테이블에 대해 이행적 종속을 없애도록 테이블을 분해한 것이다.

  Info. 이행적 종속 A → B, B → C가 성립할 때 A→ C가 성립되는 것을 의미한다.

예를 들어 아래와 같은 계절 학기 테이블을 살펴보자.

기존 테이블에서 학생 번호는 강좌 이름을 결정하고 있고, 강좌 이름은 수강료를 결정하고 있다.

그렇기 때문에 이를 (학생 번호, 강좌 이름)테이블과 (강좌 이름, 수강료)테이블로 분해해야 한다.

이행적 종속을 제거하는 이유는 비교적 간단하다.

예를 들어 501번 학생이 수강하는 강좌가 스포츠경영학으로 변경되었다고 하자.

이행적 종속이 존재한다면 501번 학생은 스포츠경영학이라는 수업을 20,000원이라는 수강료로 듣게 된다.

물론 강좌 이름에 맞게 수강료를 다시 변경할 수 있지만, 이러한 번거로움을 해결하기 위해 제 3 정규화를 하는 것이다.

즉, 학생 번호를 통해 강좌 이름을 참조하고, 강좌 이름으로 수강료를 참조하도록 테이블을 분해해야 하며 그 결과는 아래 그림과 같다.

브라우저 살펴보기 - 컴포지터가 사용자 입력을 받았을 때(3)

H.E — Sat, 8 Jun 2024 20:54:12 +0900

기술글을 보고 정리하였음(https://d2.naver.com/helloworld/6204533)

이 글은 사용자 입력(input)을 받았을 때 컴포지터가 어떻게 부드러운 상호작용이 이루어지게 하는지 알아보고 있음

기술글이 2019년도에 작성된 글이기 때문에 현재와는 많이 다른점이 있을것이기에 이런 흐름으로 만들어졌다고 이해하고 현재와 다른점이 있다는것을 생각하면서 봐야함(크롬에 많은 버전 업데이트가 있었기 때문)

컴포지터가 사용자 입력을 받았을 때

▶ 브라우저 관점에서 입력 이벤트

'입력 이벤트(input event)'라는 말을 들었을 때 입력란에서 일어나는 값 입력이나 마우스 클릭만 생각할 수 있음

하지만 브라우저의 관점에서 입력이란 모든 사용자의 제스처를 의미

마우스 휠을 스크롤하는 것도 입력 이벤트이고, 화면을 터치하거나 마우스 포인터를 화면 위에 올리는 것도 입력 이벤트 해당

브라우저 프로세스를 통해 렌더러 프로세스(Renderer Process)로 라우팅되는 입력 이벤트

화면 터치와 같은 사용자 제스처가 발생했을 때 가장 먼저 제스처를 수신하는 것은 브라우저 프로세스

브라우저 프로세스는 제스처가 어디에서 발생했는지만 알고 있음

탭 내부의 콘텐츠는 렌더러 프로세스가 처리해야 함

그래서 브라우저 프로세스는 이벤트 유형(예: touchstart )과 이벤트가 발생한 좌표를 렌더러 프로세스로 보냄

렌더러 프로세스는 이벤트 대상을 찾고 해당 대상과 연결된 이벤트 리스너를 실행해 이벤트를 적절하게 처리

▶ 컴포지터는 입력 이벤트를 받는다

웹 페이지에 이벤트 리스너가 연결되어 있지 않으면 컴포지터 스레드는 메인 스레드와 상관없이 새로운 합성 프레임을 만들 수 있음 하지만 이벤트 리스너가 웹 페이지에 연결되어 있다면, 이벤트를 처리해야 하는지 컴포지터 스레드가 어떻게 알 수 있을까?

▶ 고속 스크롤 불가 영역의 이해

고속 스크롤 불가 영역에서 발생한 입력 이벤트를 설명하는 다이어그램

JavaScript 실행은 메인 스레드의 작업이므로 웹 페이지가 합성될 때 컴포지터 스레드는 이벤트 핸들러가 연결된 영역을 '고속 스크롤 불가 영역(non-fast scrollable region)'이라고 표시

웹 페이지의 이 영역에서 이벤트가 발생했을 때 컴포지터 스레드가 입력 이벤트를 메인 스레드로 보내야 하는지를 이 정보로 확인할 수 있음

입력 이벤트가 고속 스크롤 불가 영역 밖에서 발생했다면 컴포지터 스레드는 메인 스레드를 기다리지 않고 새 프레임을 합성(컴포지터 스레드가 메인 스레드를 기다리지 않을 수 있는 이유는 컴포지터 스레드가 메인 스레드의 레이어 트리를 복사해서 별도로 가지고 있기 때문)

▶ 이벤트 핸들러를 작성할 때 주의한다

웹 개발에서 이벤트를 처리하는 흔한 패턴은 이벤트 위임(event delegation)

이벤트 버블링 덕분에 하나의 이벤트 핸들러를 최상위 요소에 연결하고 이벤트 대상을 고려해 처리를 위임할 수 있음

전체 웹 페이지가 고속 스크롤 불가 영역일 때 입력 이벤트의 처리를 설명하는 다이어그램

모든 요소에 대해 이벤트 핸들러를 하나만 작성하면 되므로 이런 이벤트 위임 패턴이 무척이나 편해 보이지만 브라우저의 관점에서 이 코드(body에서 이벤트 처리)를 보면 이제 웹 페이지의 모든 영역이 고속 스크롤 불가 영역으로 표시됨

즉, 애플리케이션이 신경 쓰지 않는 부분에 입력이 들어와도 컴포지터 스레드는 입력 이벤트가 들어올 때마다 메인 스레드와 통신해야 하고 메인 스레드가 일을 끝내기를 기다려야 함 그래서 컴포지터가 스크롤을 부드럽게 할 수 없게 됨

이런 문제를 방지하기 위해 이벤트 리스너에서 passive: true 옵션을 전달

여전히 메인 스레드에서 이벤트를 받지만 컴포지터가 메인 스레드의 처리를 기다리지 않고 새 프레임을 만들어도 된다는 힌트를 브라우저에 주는 옵션

document.body.addEventListener('touchstart', event => {  
    if (event.target === area) {
        event.preventDefault();
    }
});

document.body.addEventListener('touchstart', event => {  
    if (event.target === area) {
        event.preventDefault()
    }
 }, {passive: true});

▶ 이벤트를 취소할 수 있는지 확인한다

가로 스크롤만 가능한 영역이 있는 웹 페이지

어떤 박스 영역의 스크롤 방향을 가로로만 제한하고 싶은 경우

포인터 이벤트에서 passive: true 옵션을 사용하면 부드럽게 스크롤됨

하지만 스크롤 방향을 제한하기 위해 preventDefault() 메서드를 호출하기 전에 이미 수직 스크롤이 시작되었을 수도 있음 event.cancelable() 메서드(이벤트위 취소가 가능한지 나타냄)를 사용하면 수직 스크롤 시작 여부를 확인할 수 있음

document.body.addEventListener('pointermove', event => {  
    if (event.cancelable) {
        event.preventDefault(); // block the native scroll
        /*
        *  do what you want the application to do here
        */
    }
}, {passive: true});

또는 touch-action과 같은 CSS 규칙을 사용해 이벤트 핸들러를 아예 안 쓸 수도 있음

#area {
  touch-action: pan-x;
}

▶ 이벤트 대상 찾기

x, y 지점에 무엇이 그려졌는지 확인하기 위해 페인트 기록을 보는 메인 스레드

컴포지터 스레드가 입력 이벤트를 메인 스레드로 보낼 때 가장 먼저 하는 일은 이벤트 대상을 찾는 히트 테스트(hit test)

이벤트가 발생한 좌표에 무엇이 있는지 확인하기 위해 히트 테스트는 렌더링 프로세스에서 생성된 페인트 기록의 데이터를 사용( clip, opacity, transform 등의 속성을 반영해야 이벤트 대상을 정확히 알 수 있기 때문인것으로 보임)

▶ 메인 스레드로 이벤트를 전송하는 것을 최소화하기

일반적인 디스플레이 장치가 화면을 초당 60번 새로 갱신하며 애니메이션을 화면 갱신 주기에 맞춰야 부드럽게 움직임

입력의 경우에는 일반적인 터치스크린 장치는 터치 이벤트를 초당 60~120회 전달

마우스는 이벤트를 초당 100회 전달. 입력 이벤트의 전달 주기가 화면 갱신 주기보다 짧음

웹 페이지의 애니메이션 타임 라인에 넘쳐나 버벅거림을 유발하는 이벤트

touchmove 이벤트(하나 이상의 터치 포인터가 터치 표면을 따라 이동하면 이벤트 시작)처럼 연속적인 이벤트가 초당 120회씩 메인 스레드로 보내지면 화면이 갱신되는 정도보다 훨씬 많이 히트 테스트를 하거나 JavaScript를 실행할 수도 있음

이전과 같은 타임 라인에서 합쳐지고 지연된 이벤트

메인 스레드 호출이 과도해지는 것을 막기 위해 Chrome은 연속적인 이벤트(예를 들어 wheel , mousewheel , mousemove , pointermove , touchmove)를 합쳐서 바로 다음번 requestAnimationFrame() 메서드 실행 직전까지 전송(dispatch)하지 않고 기다림

keydown, keyup, mouseup, mousedown, touchstart, touchend와 같은 비연속적인(discrete) 이벤트는 즉시 전달

▶ 한 프레임 안에서 합쳐진 이벤트(intra-frame events)를 얻으려면 getCoalescedEvents() 메서드를 사용한다

매끄러운 터치 제스처 경로(왼쪽)와 합쳐진 경로(오른쪽)

window.addEventListener('pointermove', event => {  
    const events = event.getCoalescedEvents();
    for (let event of events) {
        const x = event.pageX;
        const y = event.pageY;
        // draw a line using x and y coordinates.
    }
});

대부분의 웹 애플리케이션에서는 이벤트를 합쳐서 처리해도 사용자가 만족스럽게 사용할 수 있음

하지만 드로잉 앱 같은 것에서 touchmove 이벤트의 좌표를 기반으로 경로를 만들어야 할 때에는 사이사이에 경로가 누락돼서 선을 매끄럽게 그리지 못할 수 있음

이런 경우에 포인터 이벤트의 getCoalescedEvents() 메서드를 사용하면 합쳐진 이벤트에 대한 정보를 얻을 수 있음

▶ Lighthouse를 사용한다

브라우저에 잘 맞춰진 코드를 작성하고 싶은데 어디서부터 시작해야 할지 모를 때에는 Lighthouse를 사용

Lighthouse는 웹 사이트의 잘 된 점과 개선할 점을 파악한 결과를 보고서로 보여 주는 도구

평가 항목에 무엇이 있는지 읽어 보는 것으로도 브라우저가 무엇을 신경 쓰는지 알 수 있을 것

▶ 성능 측정 방법을 배운다

성능 개선 방법은 사이트마다 다르기 때문에 웹 사이트의 성능을 측정하고 가장 적합한 방식을 결정할 수 있어야 함

Chrome 개발자 도구 개발 팀이 작성한 튜토리얼은 웹 사이트의 성능을 측정하는 여러 방법을 알려줌

▶ 사이트에 기능 정책을 추가한다

기능 정책(Feature policy)은 웹 플랫폼의 새로운 기능으로, 프로젝트를 구축할 때 최소한의 방어책이 될 수 있음

기능 정책을 사용하면 앱의 특정 동작을 보장하고 실수를 방지할 수 있음

예를 들어 앱이 파싱을 차단하지 않도록 보장하려면 동기 스크립트 정책(synchronous scripts policy)하에 앱을 실행할 수 있고 sync-script: 'none' 값을 적용하면 파싱을 막을 수 있는 JavaScript는 실행되지 않음

이렇게 하면 코드가 파서를 차단하는 것을 방지할 수 있고, 브라우저는 파서가 멈추는 것을 걱정할 필요가 없어짐

마무리

코드 작성과 생산성도 중요하지만 작성한 코드가 브라우저에서 어떻게 작동하는지도 생각해 보는 것이 좋음

최신 브라우저는 사용자에게 더 나은 웹 경험을 제공하기 위해 여러 방법을 개발해 왔고 앞으로도 그럴 것임

코드를 체계화해 브라우저에서 잘 작동하게 하면 사용자에게 좋은 경험을 제공할 수 있음

브라우저 살펴보기 - 렌더러 프로세스의 내부동작(2)

H.E — Sat, 8 Jun 2024 20:53:26 +0900

기술글을 보고 정리하였음(https://d2.naver.com/helloworld/5237120)

이 글은 렌더러 프로세스가 HTML 문서를 받았을 때 어떤 절차를 거쳐 화면을 구성하는지 설명하고 있음

렌더러 프로세스의 내부 동작

렌더러 프로세스는 여러 측면에서 웹 페이지의 성능에 영향을 끼침

▶ 렌더러 프로세스는 웹 콘텐츠를 처리

메인 스레드와 워커 스레드, 컴포지터 스레드, 래스터 스레드가 있는 렌더러 프로세스

렌더러 프로세스는 탭 내부에서 발생하는 모든 작업을 담당

렌더러 프로세스의 메인 스레드가 브라우저로 전송된 대부분의 코드를 처리

간혹 웹 워커나 서비스 워커를 사용하는 경우에는 워커 스레드가 JavaScript 코드의 일부를 처리

웹 페이지를 효율적이고 부드럽게 렌더링하기 위해 별도의 컴포지터 스레드(웹 페이지의 시각적 요소들을 결합하여 최종 화면에 렌더링하는 작업 담당)와 래스터 스레드(웹 페이지의 각 레이어를 실제로 래스터화하는 작엄 담당, 벡터 그래픽을 픽셀 단위의 비트맵 이미지로 변화하는 과정을 처리)가 렌더러 프로세스에서 실행됨

렌더러 프로세스의 주요 역할은 HTML과 CSS, JavaScript를 사용자와 상호작용을 할 수 있는 웹 페이지로 변환하는 것

▶ 파싱

DOM 구축

페이지를 이동하는 내비게이션 실행 메시지를 렌더러 프로세스가 받고 HTML 데이터를 수신하기 시작하면 렌더러 프로세스의 메인 스레드는 문자열(HTML)을 파싱해서 DOM(document object model)으로 변환하기 시작

DOM은 브라우저가 내부적으로 웹 페이지를 표현하는 방법일 뿐만 아니라 웹 개발자가 JavaScript를 통해 상호작용을 할 수 있는 데이터 구조이자 API

HTML 문서를 DOM으로 파싱하는 방법은 HTML 표준에 정의되어 있음

브라우저에서 HTML 문서를 열었을 때 오류를 받지 않는데 이유는 오류를 우아하게 처리하도록 HTML 명세가 설계됐기 때문(ex. 닫는 태그 누락, 먼저 닫힌 잘못된 마크업)

하위 리소스(subresource) 로딩

HTML을 파싱하고 DOM 트리를 만드는 메인 스레드

웹 사이트는 일반적으로 이미지, CSS, JavaScript와 같은 외부 리소스를 사용

이러한 파일은 네트워크나 캐시에서 로딩해야 함

DOM을 구축하기 위해 파싱하는 동안 이런 리소스를 만날 때마다 메인 스레드가 하나하나 요청할 수도 있을 것임

하지만 속도를 높이기 위해 '프리로드(Preload) 스캐너'가 동시에 실행됨

HTML 문서에 <img> 또는 <link> 와 같은 태그가 있으면 프리로드 스캐너는 HTML 파서가 생성한 토큰을 확인하고 브라우저 프로세스의 네트워크 스레드에 요청을 보냄

자바 스크립트가 파싱을 막을 수 있다

<script> 태그를 만나면 HTML 파서는 HTML 문서의 파싱을 일시 중지한 다음 JavaScript 코드를 로딩하고 파싱해 실행해야 함 DOM 구조 전체를 바꿀 수 있는 document.write() 메서드와 같은 것을 사용해 문서의 모양을 변경할 수 있기 때문 HTML 파싱을 재개하기 전에 HTML 파서는 JavaScript의 실행이 끝나기를 기다려야 함

리소스를 어떻게 로딩하길 원하는지 브라우저에 힌트를 주는 방법

JavaScript에서 document.write() 메서드를 사용하지 않는다면 <script> 태그에 async 속성이나 defer 속성을 추가할 수 있음. 이 속성이 있으면 브라우저가 JavaScript 코드를 비동기적으로 로딩하고 실행하면서 HTML 파싱을 막지 않음

또한 JavaScript 모듈을 사용할 수도 있음

<link rel="preload">는 현재 내비게이션을 실행하기 위해 리소스가 반드시 필요하다는 것을 브라우저에 알려서 리소스를 가능한 한 빨리 다운로드하려는 경우에 사용할 수 있음

▶ 스타일 계산

계산된 스타일을 추가하기 위해 CSS를 파싱하는 메인 스레드

DOM만으로는 웹 페이지의 모양을 알 수 없음. CSS로 웹 페이지 요소의 모양을 결정할 수 있기 때문

메인 스레드는 CSS를 파싱하고 각 DOM 노드에 해당되는 계산된 스타일(computed style)을 확정

계산된 스타일은 CSS 선택자(selector)로 구분되는 요소에 적용될 스타일에 관한 정보

CSS를 전혀 적용하지 않아도 DOM 노드에는 계산된 스타일이 적용되어 있음

<h1> 태그는 <h2> 태그보다 크게 표시되며 바깥 여백(margin)이 모든 요소에 적용됨

브라우저에 기본 스타일 시트가 있기 때문(html.css 파일을 보면 Chrome의 기본 CSS를 알수 있음)

▶ 레이아웃

원과 사각형만을 듣는것만으로는 그림이 전체적으로 어떻게 생겼는지 알수 없음

레이아웃은 요소의 기하학적 속성(geometry)를 찾는 과정

메인 스레드는 DOM과 계산된 스타일을 훑어가며 레이아웃 트리를 만듬

레이아웃 트리는 x, y 좌표, 박스 영역(bounding box)의 크기와 같은 정보를 가지고 있음

레이아웃 트리는 DOM 트리와 비슷한 구조일 수 있지만 웹 페이지에 보이는 요소에 관련된 정보만 가지고 있음

- display: none 속성이 적용된 요소는 레이아웃 트리에 포함되지 않음(visibility: hidden 속성이 적용된 요소는 포함)

이와 비슷하게 p::before{content:"Hi!} 속성과 같은 의사 클래스(pseudo class = 가상 클래스)의 콘텐츠는 DOM에는 포함되지 않지만 레이아웃 트리에는 포함

계산된 스타일이 있는 DOM 트리를 돌며 레이아웃 트리를 생성하는 메인 스레드

웹 페이지의 레이아웃을 결정하는 것은 어려운 작업

줄 바꿈이 변해 이동하는 단락의 박스 레이아웃

가장 단순하게 위에서 아래로 펼쳐지는 블록 영역 하나만 있는 웹 페이지의 레이아웃을 결정할 때에도 폰트의 크기가 얼마이고 줄 바꿈을 어디서 해야 하는지 고려해야 함(단락의 크기와 모양이 바뀔 수 있고, 단락의 위치에 영향이 있기 때문)

CSS는 요소를 한쪽으로 흐르게(float) 하거나, 크기를 벗어난 부분을 보이지 않게 하거나, 글이 쓰이는 방향을 변경할 수 있음

▶ 페인트

어느 도형을 먼저 그려야할지 알수 없음

DOM, 스타일, 레이아웃을 가지고도 여전히 페이지를 렌더링할 수 없음

요소의 크기, 모양, 위치를 알더라도 어떤 순서로 그려야 할지 판단해야 함

z-index 속성이 적용되었다면 HTML에 작성된 순서로 요소를 그리면 잘못 렌더링된 화면이 나옴
즉, DOM에 선언된 노드 순서와 페인트 순서는 많이 다를 수 있음

레이아웃 트리를 순회하며 페인트 기록을 생성하는 메인 스레드

페인트 단계에서 메인 스레드는 페인트 기록(paint record)을 생성하기 위해 레이아웃 트리를 순회

페인트 기록은 '배경 먼저, 다음은 텍스트, 그리고 직사각형'과 같이 페인팅 과정을 기록한 것

렌더링 파이프라인을 갱신하는 데는 많은 비용이 든다

DOM 트리 및 스타일, 레이아웃 트리, 페인트 트리의 순서로 생성

렌더링 파이프라인에서 파악해야 할 가장 중요한 점은 각 단계에서 이전 작업의 결과가 새 데이터를 만드는 데 사용되는 것

예를 들어 레이아웃 트리에서 변경이 생겨 문서의 일부가 영향을 받으면 페인팅 순서도 새로 생성해야 함

애니메이션 타임라인에서 애니메이션 프레임과 JavaScript 때문에 렌더링이 막힌 프레임

요소에 애니메이션을 적용하면 브라우저는 모든 프레임 사이에서 이러한 작업을 해야 함

대부분의 디스플레이 장치는 화면을 초당 60번 새로 고침(60fps)

요소의 움직임이 모든 프레임에 반영되어야 사람이 볼 때 부드럽게 느껴짐

애니메이션에서 프레임이 누락되면 웹 페이지가 '버벅대는(janky)' 것처럼 보임

애니메이션 타임라인에서 애니메이션 프레임과 JavaScript 때문에 렌더링이 막힌 프레임

화면 주사율에 맞추어 렌더링 작업이 이루어져도 이 작업은 메인 스레드에서 실행되기 때문에 애플리케이션이 JavaScript를 실행하는 동안 렌더링이 막힐 수 있음

애니메이션 프레임에 맞춰 애니메이션 타임라인에서 실행되는 더 작은 JavaScript 덩어리

JavaScript 작업을 작은 덩어리로 나누고 requestAnimationFrame() 메서드를 사용해 프레임마다 실행하도록 스케줄을 관리할 수 있음

Reflow와 Repaint 최소화하여 브라우저 렌더링 최적화하기

렌더링이 반복되는 경우

자바스크립트에 의한 노드 추가 또는 삭제
브라우저 창의 리사이징에 의한 뷰포트 크기 변경
HTML 요소의 레이아웃에 변경을 발생시키는 스타일 변경

Layout 계산과 Paint 과정이 재차 실행되어 리렌더링이 발생

Layout 계산을 다시 수행하는 것을 Reflow, 픽셀을 렌더링하는 Paint 작업을 다시 하는 것을 Repaint라고 함

여기서 주의해야할 점은 Reflow가 발생하면 Repaint까지 발생하게 되므로 큰 비용이 발생한다는 점

만약 발생시킨다면 paint부터 시작될 수 있도록 Repaint만 발생하게 되는것이 훨씬 비용적 이점이 있음

Reflow와 Repaint 최소화

영향받는 노드 최소화하기 (position fixed, absolute)
- 상위 노드의 스타일을 변경하면 하위 노드에 모두 영향을 주게 됨
- 따라서 다른 엘리먼트 레이아웃에 영향을 주지 않는 fixed와 absolute 속성을 사용하면 비용을 줄일 수 있음
숨겨진 엘리먼트 수정
- display: none의 경우 Reflow와 Repaint가 발생하지 않음
- 많은 수의 엘리먼트를 변경해야 할 경우, 숨겨진 상태에서 변경하고 다시 보이도록 display: none 속성을 설정하여 레이아웃 발생을 최대한 줄일 수 있음
- 주의: visibility: hidden의 경우 보이지 않고 존재는 하기 때문에 layout 발생
transform, opacity 속성 사용
- 두 속성은 reflow와 repaint가 일어나지 않는 속성
- left, right 대신 transform 속성을 사용
- visibility, display 대신 opacity 속성을 사용하면 reflow, repaint 발생을 최소화 할 수 있음
애니메이션 최적화
- 한 프레임의 처리는 16ms(60fps) 내로 완료되어야 끊기는 현상 없이 자연스럽게 처리
- 자바스크립트에서 setTimeout을 이용하여 애니메이션을 구현한다면 이벤트 루프에 의해 딜레이가 생길 수 있고, 16ms 안에 실행하지 못 한다면 해당 프레임은 유실됨
- 이를 도와주는 것이 requestAnimationFrame() 메서드(리페인트 바로 전에 브라우저가 애니메이션을 업데이트 할 지정된 함수를 호출하도록 요청함 즉, 리페인트 이전에 호출할 인수로 콜백을 받)
  - 장점: 지연 및 블로킹 없이 일정한 간격으로 애니메이션을 수행할 수 있음
  - 브라우저 프레임 속도(60fps)에 맞춰 애니메이션을 실행할 수 있도록 함
  - 페이지가 비활성 상태일 때 렌더링을 중지(CPU의 리소스와 배터리 수명을 낭비하지 않아도 됨)
    - 이와 달리 setTimeout은 백그라운드 상태일 때도 계속 실행됨

▶ 합성

페이지는 어떻게 그려질까

가장 단순한 래스터화 과정

정보(브라우저는 문서의 구조와 각 요소의 스타일, 요소의 기하학적 속성, 페인트 순서)를 화면의 픽셀로 변환하는 작업을 래스터화(rasterizing)라고 함

가장 단순한 래스터화는 아마 뷰포트 안쪽을 래스터하는 것일 것

사용자가 웹 페이지를 스크롤하면 이미 래스터화한 프레임을 움직이고 나머지 빈 부분을 추가로 래스터화함

이 방식은 Chrome이 처음 출시되었을 때 래스터화한 방식이지만 현재는 브라우저는 합성(compositing)이라는 보다 정교한 과정을 거침(렌더링 파이프라인에서는 이단계부터 GPU가 많이 사용됨)

합성이란 무엇인가

합성과정

합성은 웹 페이지의 각 부분을 레이어로 분리해 별도로 래스터화하고 컴포지터 스레드(compositor thread)라고 하는 별도의 스레드에서 웹 페이지로 합성하는 기술

스크롤되었을 때 레이어는 이미 래스터화되어 있으므로 새 프레임을 합성하기만 하면 됨

애니메이션 역시 레이어를 움직이고 합성하는 방식으로 만들 수 있음

여러 레이어로 나누기

레이어 트리를 만들면서 레이아웃 트리를 순회하는 메인 스레드

어떤 요소가 어떤 레이어에 있어야 하는지 확인하기 위해 메인 스레드는 레이아웃 트리를 순회하며 레이어 트리를 만듬

뷰포트로 미끄러져 들어오는 들어오는 슬라이드인 메뉴처럼 별도의 레이어여야 하는 웹 페이지의 어떤 부분이 별도의 레이어가 아니라면 CSS의 will-change 속성을 사용해 브라우저가 레이어를 생성하게 힌트를 줄 수 있음

모든 요소에 레이어를 할당하면 좋을 것 같지만 수많은 레이어를 합성하는 작업은 웹 페이지의 작은 부분을 매 프레임마다 새로 래스터화하는 작업보다 더 오래 걸릴 수 있음(확인하기 위해 애플리케이션의 렌더링 성능은 직접 측정해 봐야 함)

레이어가 많으면 합성 비용이 높을 뿐만 아니라 레이어를 메모리에 가지고 있어야 하는 부담도 있음(Chrome은 레이어가 과도하게 많아지는 것(layer explosion)을 막기 위해 특정한 경우에는 레이어를 생성하지 않거나 합치기도 함)

메인 스레드 이후 래스터화와 합성

타일 단위로 비트맵을 만들고 GPU로 보내는 래스터 스레드

레이어 트리가 생성되고 페인트 순서가 결정되면 메인 스레드가 해당 정보를 컴포지터 스레드에 넘김(commit)

그러면 컴포지터 스레드는 각 레이어를 래스터화함

어떤 레이어는 페이지의 전체 길이만큼 클 수 있음

그래서 컴포지터 스레드는 레이어를 타일(tile) 형태로 나눠 각 타일을 래스터 스레드로 보냄

래스터 스레드는 각 타일을 래스터화해 GPU 메모리에 저장

컴포지터 스레드는 래스터 스레드간의 우선순위를 지정할 수 있어서 뷰포트 안이나 근처의 것들이 먼저 래스터화될 수 있음 또한 레이어는 줌인 같은 동작을 처리하기 위해 여러 해상도별로 타일 세트를 여러 벌 가지고 있음(타일 세트의 모든 타일이 래스터화되어 있지는 않기 때문에 최대한 구멍을 메울 수 있는 방식으로 여러 타일 세트의 타일을 조합해서 사용. 래스터화하지 못한 영역은 체스판의 하얀색 부분처럼 빈곳으로 둠 → 이 단계의 큰 목표는 이 하얀 빈곳을 줄이는 것)

타일이 래스터화되면 컴포지터 스레드는 '합성 프레임'을 생성하기 위해 타일의 정보를 모음

이 타일의 정보를 '드로 쿼드(draw quads)'라고 부름

드로 쿼드: 메모리 타일의 위치와 웹 페이지 합성을 고려해 타일을 웹 페이지의 어디에 그려야 하는지에 관한 정보를 가지고 있음
합성 프레임: 웹 페이지의 프레임을 나타내는 드로 쿼드의 모음

이후에 합성 프레임이 IPC를 통해 브라우저 프로세스로 전송

이 시점에 브라우저 UI의 변경을 반영하려는 UI 스레드나 확장 앱을 위한 다른 렌더러 프로세스에 의해 합성 프레임이 더 추가될 수 있음 이러한 합성 프레임은 GPU로 전송되어 화면에 표시됨

스크롤 이벤트가 발생하면 컴포지터 스레드는 GPU로 보낼 다른 합성 프레임을 만듬

- 기술글(2019년 작성)에서는 ' 합성 프레임이 브라우저 프로세스를 거치지 않고 GPU 프로세스로 바로 보내지는 형태로 변경될 예정'이라고 되어있었는데 검색으로 해보니 현재 크롬의 합성 아키텍처는 성능과 효율성을 개선하기 위해 많은 변화가 있었다고 함 주요 목표는 중간 단계를 거치지 않고 직접 GPU 프로세스로 합성하는 것 따라서 현재는 합성 단계가 많이 다를꺼라고 생각함 찾아보니 이 2023년 작성된 블로그글을 확인해보니 '프로세스를 가속화하기 위해 래스터 스레드는 IPC를 통해 타일을 GPU 프로세스로 보낸다'고 되어있음 좀더 현재에 가까운 동작방법을 알기 위해서 이 글을 참조하며 이해하는것이 훨씬 좋아 보임

합성의 이점은 메인 스레드와 별개로 작동할 수 있다는 점

컴포지터 스레드는 JavaScript 실행이나 스타일 계산을 기다리지 않아도 됨

이것이 합성만 하는 애니메이션이 성능상 가장 부드럽다고 보는 이유

레이아웃이나 페인트를 다시 계산해야 할 경우에는 메인 스레드가 관여해야 함

브라우저 살펴보기 - 내비게이션 과정에서 일어나는 일(1)

H.E — Sat, 8 Jun 2024 20:52:41 +0900

기술글을 보고 정리하였음(https://d2.naver.com/helloworld/2922312)

저번에 이어 웹 사이트를 표시하기 위해 각 프로세스와 스레드가 어떻게 통신하는지 좀 더 깊게 알아보고 있음

기술글이 2019년도에 작성된 글이기 때문에 현재에는 사용되지 않는 이벤트등이 기재되어있어 이런 흐름으로 페이지 이동을 한다고 생각하면 될듯 (크롬에 많은 버전 업데이트가 있었기 때문)

내용을 알기 전에 브라우저 동작과정과 프로세스와 쓰레드에 대한 기본 지식을 가지고 읽어야 이해하기 좋음

내비게이션 과정에서 일어나는 일

브라우저의 주소 표시줄에 URL을 입력하면 브라우저가 인터넷에서 데이터를 가져와서 페이지를 표시함

이 동작에서 사용자가 사이트를 요청하고 브라우저가 페이지 렌더링을 준비하는 과정(= 내비게이션 = 사이트간의 이동)에 초점을 맞춰 살펴볼것임

▶ 브라우저 프로세스에서 시작

브라우저 UI와 브라우저 프로세스(UI 스레드와 네트워크 스레드, 스토리지 스레드 )

브라우저 프로세스가 탭 영역 밖에 있는 모든 부분을 제어

브라우저 프로세스에는 UI 스레드와 네트워크 스레드, 스토리지 스레드 등이 있음

UI 스레드는 브라우저의 버튼과 입력란을 그림

네트워크 스레드는 인터넷에서 데이터를 가져오기 위해 네트워크 스택을 다룸

스토리지 스레드는 파일에 대한 접근을 제어함

주소 표시줄에 URL을 입력하면 브라우저 프로세스의 UI 스레드가 입력을 처리

▶ 간단한 내비게이션

1단계: 입력 처리

입력되는 내용이 검색어인지 URL인지 확인하는 UI 스레드

사용자가 주소 표시줄에 타이핑을 시작하면 UI 스레드는 먼저 입력되는 내용이 검색어(search query)인지 URL인지 확인

Chrome에서 주소 표시줄은 검색창이기도 함

UI 스레드는 입력되는 내용을 파싱해서 검색 엔진으로 이동할지 요청한 사이트로 이동할지 결정해야

- 사용자가 입력한 문자열이 '검색어'라면 문자열을 사용자가 선택한 검색 엔진의 URL과 조합해 새로운 URL 형태로 변환함. 이런 변환을 위해 Chrome은 검색 엔진의 URL 주소를 관리
입력된 문자열이 검색어인지 URL인지 판별하는 것은 어려운 일이기 때문에 브라우저는 이를 도와줄 서버와 통신하거나 DNS Lookup(도메인 네임 시스템 조회)을 실행하기도 함 네이버에서 개발한 브라우저인 Whale의 '사이트 곧장 가기' 기능도 이 단계에서 실행되는 기능

2단계: 내비게이션 시작

mysite.com 으로 이동하기 위해 네트워크 스레드와 통신하는 UI 스레드

사용자가 Enter 키를 누르면 사이트의 콘텐츠를 가져오기 위해 UI 스레드가 네트워크 호출을 시작

로딩 스피너가 탭의 모서리에 표시되고, 네트워크 스레드는 요청에 대한 DNS Lookup 및 TLS 연결 설정과 같은 적절한 프로토콜을 거쳐 요청을 처리

이때 네트워크 스레드가 HTTP 301과 같은 서버 리디렉션 헤더를 수신할 수도 있음

이런 경우에는 네트워크 스레드가 UI 스레드와 통신해 서버가 리디렉션을 요청했다는 것을 알림

그런 다음 새로운 URL 요청이 시작됨

3단계: 응답 읽기

Content-Type을 포함하는 응답 헤더와 실제 데이터인 페이로드

응답 본문인 페이로드가 들어오기 시작하면 네트워크 스레드는 필요에 따라 스트림의 처음 몇 바이트를 확인

페이로드가 어떤 형식의 데이터인지는 응답 헤더의 Content-Type 헤더가 알려 주지만 정보가 없거나 잘못된 정보가 있을 수 있음 그래서 이때 MIME 스니핑(리소스를 보고 올바른 MIME 타입(파일 형식)을 추측)을 실행해 데이터의 실제 형식을 알아냄(매우 까다로운 작업이기에 브라우저가 다양한 방법으로 Content-Type 헤더와 페이로드를 처리)

응답 데이터가 안전한 사이트의 HTML 문서인지 확인하는 네트워크 스레드

응답이 HTML 파일이라면 데이터를 렌더러 프로세스에 전달하는 단계로 넘어감

하지만 응답이 ZIP 형식 파일이나 다른 형식의 파일이라면 다운로드 요청이므로 다운로드 매니저에 데이터를 전달하는 단계로 넘어가야 함(렌더러 프로세스가 다룰 수 있는 데이터 형식일때와 렌더러 프로세스가 다룰 수 없는 데이터 형식일때로 구분 - ex. PDF파일을 반환하는 주소로 접근했을 때 다운로드가 아닌 브라우저에서 문서를 바로 표시)

이 단계는 또한 Safe Browsing의 검사가 실행되는 단계

도메인과 응답 데이터가 악성 사이트로 알려진 사이트와 일치하는 것 같다면 네트워크 스레드는 경고 페이지를 표시하라고 알림

이에 더해서 CORB(Cross-Origin Read Blocking) 기능이 서로 다른 사이트(cross-site)의 민감한 데이터가 렌더러 프로세스에서 실행되지 않게 검사

3단계: 렌더러 프로세스 찾기

UI 스레드에게 렌더러 프로세스를 찾으라고 알리는 네트워크 스레드

모든 검사가 끝나고 브라우저가 요청된 사이트로 이동해야 한다고 네트워크 스레드가 확신하게 되면 네트워크 스레드는 UI 스레드에 데이터가 준비되었음을 알림. 그러면 UI 스레드는 웹 페이지의 렌더링을 수행할 렌더러 프로세스를 찾음

네트워크 요청이 응답을 받기까지 수백 밀리초가 걸릴 수 있기 때문에 이 과정을 더 빨리 진행하기 위한 최적화가 적용되어 있음. 2단계에서 UI 스레드가 네트워크 스레드로 URL 요청을 보낼 때 UI 스레드는 어느 사이트로 이동할지 알고 있음

UI 스레드는 렌더러 프로세스를 먼저 찾거나 네트워크 요청과 동시에 렌더러 프로세스를 시작

이런 방식에서는 모든 것이 예상대로 잘 진행된다면 네트워크 스레드가 데이터를 받을 때 이미 렌더러 프로세스는 준비 상태에 있게 됨. 만약 다른 사이트로 리디렉션이 이루어져 다른 프로세스가 필요하게 되면 미리 준비한 프로세스가 사용되지 않을 수도 있음

4 단계: 내비게이션 실행

브라우저 프로세스와 렌더러 프로세스 간의 IPC 통신. 페이지 렌더링을 요청

데이터와 렌더러 프로세스가 준비되었으므로 내비게이션을 실행하도록 브라우저 프로세스에서 렌더러 프로세스로 IPC 메시지를 전송

또한 렌더러 프로세스가 HTML 데이터를 계속 수신할 수 있도록 브라우저 프로세스는 데이터 스트림(데이터가 지속적으로 흐르는 방식으로 전달되는 것을 의미)을 전달

렌더러 프로세스에서 내비게이션이 실행되었다는 것을 브라우저 프로세스가 확인하고 나면 내비게이션이 완료되고 문서 로딩 단계가 시작

- 로딩은 프로그램 동작에 필요한 프로그램 그 자체와 리소스를 보조 기억장치(가령 하드디스크)에서 주기억장치(메모리)로 불러들이는 과정

이 시점에 주소 표시줄이 업데이트되고 보안 표시와 사이트 설정 UI도 새 페이지의 사이트 정보를 반영해 갱신

탭에 대한 세션 기록이 업데이트되어 뒤로 가기 버튼과 앞으로 가기 버튼도 방금 이동한 사이트를 반영해 작동

탭이나 창을 닫은 이후 탭과 세션을 복원할 수 있게 세션 기록이 디스크 드라이브에 저장

추가 단계: 초기 로드 완료

렌더러 프로세스가 브라우저 프로세스에 페이지가 '로딩되었다'는 것을 알리기 위한 IPC 통신

내비게이션이 실행되면 렌더러 프로세스는 계속 리소스를 로딩하고 페이지를 렌더링

렌더러 프로세스가 렌더링을 '끝내면' 브라우저 프로세스로 IPC 메시지를 보냄(이 시점은 페이지의 모든 프레임에서 onload 이벤트(문서의 모든 콘텐츠가 로드된 후 발생하는 이벤트)의 실행까지 끝낸 이후)

그러면 UI 스레드는 탭에서 로딩 스피너의 작동을 중지

'끝낸다(finish)'라고 표현한 이유는 클라이언트 사이드의 JavaScript가 여전히 추가적인 리소스를 로드하거나 이후에 새로운 뷰를 렌더링할 수도 있기 때문

▶ 다른 사이트로 내비게이션

브라우저 프로세스가 렌더러 프로세스에 다른 사이트로 이동한다는 것을 알려주는 IPC 통신

사용자가 주소 표시줄에 다른 URL을 다시 입력하면 브라우저 프로세스는 동일한 단계를 거쳐 다른 사이트로 이동을 처리함. 하지만 그전에 현재 렌더링된 사이트에서 beforeunload 이벤트(리소스가 언로드 되려고 할때 시작)를 확인해야 함

beforeunload(꼭 필요한 경우 사용. 이벤트 핸들러를 실행해야하기 때문에 대기 시간이 늘어남) 이벤트는 탭을 닫거나 이동하려고 할 때 "이 사이트를 떠나시겠습니까?"라는 경고창을 만들 수 있음

JavaScript 코드를 포함해 탭 안의 모든 것은 렌더러 프로세스에 의해 처리되므로 브라우저 프로세스는 새로운 내비게이션 요청이 들어오면 현재 렌더러 프로세스를 확인해야 함

브라우저 프로세스가 새로운 렌더러에는 프로세스에게 페이지를 렌더링하라고 알리는 IPC 통신과 브라우저 프로레스가 이전 렌더러 프로세스에 웹 페이지를 떠나라고 알리는 IPC 통신

사용자가 링크를 클릭하거나 클라이언트 사이드 JavaScript에서 window.location = "https://newsite.com" 코드를 실행하는 것과 같이 렌더러 프로세스에서 내비게이션이 시작되면 렌더러 프로세스는 먼저 beforeunload 이벤트 핸들러를 확인

이후에는 브라우저 프로세스가 내비게이션을 시작했을 때와 동일한 과정을 거침

유일한 차이점은 내비게이션 요청이 렌더러 프로세스에서 시작되어 브라우저 프로세스로 넘어간다는 점이다.

현재 렌더링된 사이트와 다른 사이트로 이동하는 새로운 내비게이션이 발생하면 별도의 렌더러 프로세스가 새로운 내비게이션을 처리

현재 렌더링된 사이트를 처리한 렌더러 프로세스는 unload와 같은 이벤트를 처리하기 위해 유지

▶ 서비스 워커

최근에 서비스 워커가 도입되며 내비게이션 과정에도 변화가 생겼음

서비스 워커는 애플리케이션의 코드에 네트워크 프록시(클라이언트와 서버 간의 중계 역할을 하는 컴퓨터 시스템이나 응용 프로그램)를 작성할 수 있는 수단

서비스 워커를 통해 웹 개발자는 무엇을 로컬 캐시에 저장할지, 언제 네트워크에서 새 데이터를 가져올지 제어할 수 있음

서비스 워커가 캐시에서 페이지를 로드하도록 설정되었다면 네트워크에서 데이터를 가져오도록 요청할 필요가 없음

기억해야 할 중요한 점은 서비스 워커가 렌더러 프로세스에서 실행되는 JavaScript 코드라는 점

그렇다면 내비게이션 요청이 들어왔을 때 브라우저 프로세스는 사이트에 서비스 워커가 있다는 것을 어떻게 알 수 있을까?

1. 서비스 워커의 범위를 찾는 브라우저 프로세스의 네트워크 스레드 2. 서비스 워커를 처리할 렌더러 프로세스를 시작하는 브라우저 프로세스의 UI 스레드. 렌더러 프로세스의 워커 스레드가 네트워크에서 데이터를 요청

서비스 워커가 등록되면 서비스 워커의 범위는 참조(reference)로 유지됨

내비게이션이 발생하면 네트워크 스레드는 도메인을 등록된 서비스 워커의 범위와 비교함

해당 URL에 등록된 서비스 워커가 있으면 UI 스레드는 서비스 워커 코드를 실행하기 위해 렌더러 프로세스를 찾음

서비스 워커를 이용하여 네트워크에 데이터를 요청하지 않고 캐시에서 데이터를 가져오거나 네트워크에 새 리소스를 요청할 수 있음

내비게이션 프리로드

서비스 워커를 처리할 렌더러 프로세스를 시작하면서 동시에 병렬로 네트워크 요청을 시작하는 브라우저 프로세스의 UI 스레드

브라우저 프로세스와 렌더러 프로세스 사이를 왕복해야 하는 상황에서 서비스 워커가 결국 네트워크에서 데이터를 요청하기로 하면 지연이 발생하게 됨을 알 수 있음(이리 저리 확인하다 시간을 낭비하는 것)

내비게이션 프리로드는 서비스 워커의 시작과 병렬로 리소스를 로딩해 내비게이션 과정의 속도를 높이는 메커니즘

이 요청은 헤더에 표시되어 서버가 이러한 요청에 대해 다른 콘텐츠를 보낼 수 있게 함

예를 들어 전체 문서를 보내지 않고 업데이트된 데이터만만 보낼 수 있음

헤더에 표시되는것은 처음부터 서비스 워커를 등록할때 내비게이션 프리로드 기능을 사용한다고 명시하면 내비게이션 프리로드가 활성화되어 브라우저가 알아서 내비게이션 요청 헤더를 추가해준다고 함(고마워요 gpt웨건)

ArrayList vs LinkedList

하계동물고기 — Fri, 7 Jun 2024 23:52:11 +0900

ArrayList 란?

ArrayList는 배열의 상위호환 버전 정도로 이해하면 된다.

기존의 배열만으로는 자료를 담고 관리하는데 약간 불편함이 있어서 나온 것이 ArrayList이기 때문이다.

ArrayList는 내부적으로 배열을 사용하여 구현되어 있지만, 동적으로 배열의 크기를 바꿀 수 있다.

ArrayList는 초기에는 일정한 크기의 배열을 생성하고, 요소를 추가할 때마다 내부 배열의 크기를 자동으로 조정한다.

요소를 추가할 때 내부 배열이 가득 차게 되면, ArrayList는 현재 배열의 크기를 늘려 더 많은 요소를 수용할 수 있는

새로운 배열을 생성한다.

그리고 기존의 요소들을 새 배열로 복사하고, 새로운 요소를 추가한다.

이렇게 배열의 크기를 동적으로 조정하여 ArrayList가 동적으로 요소를 추가, 제거할 수 있는 구조를 갖게 된다.

LinkedList 란?

LinkedList는 데이터가 연속된 위치에 저장되지 않고 모든 데이터가

데이터 부분(= 노드)과 주소 부분(= 포인터)을 가지고 한 줄로 연결되어 있는 방식으로 데이터를 저장한다.

LinkedList는 노드끼리의 주소 포인터를 서로 가리키며 링크(참조)함으로써 이어지는 구조다.

위 그림을 보면 LinkedList는 각기 노드마다 화살표로 연결되어 리스트 형태로 나열되어 있는 것을 볼 수 있다.

즉, 객체를 만들면 객체의 주소가 생기게 되는데, 노드마다 각기 객체의 주소를 서로 참조함으로써 연결 형태를 구성하는 것이다.

ArrayList vs LinkedList 특징 비교

LinkedList가 각기 노드를 두고 주소 포인터를 링크하는 식으로 자료를 구성하는 이유는

ArrayList가 배열을 이용하여 요소를 저장함으로써 발생하는 단점을 극복하기 위해 고안되었기 때문이다.

	ArrayList	LinkedList
컬렉션 구성	배열을 이용	노드를 연결(linked)
데이터 접근 시간	모든 데이터 상수 시간 접근	위치에 따라 이동시간 발생
삽입 / 삭제 시간	삽입 / 삭제 자체는 상수 시간
삽입 / 삭제 시간	삽입 / 삭제 시 데이터 이동이 필요한 경우, 추가시간 발생	삽입 / 삭제 위치에 따라 그 위치까지 이동하는 시간 발생
리사이징 필요	공간이 부족할 경우 새로운 배열에 복사하는 추가 시간 발생	-
데이터 검색	최악의 경우 리스트에 있는 아이템 수 만큼 확인

ArrayList의 문제점

ArrayList는 배열 공간(capacity)이 꽉 차거나, 요소 중간에 삽입을 행하려 할 때,
기존의 배열을 복사해서 요소를 뒤로 한칸씩 일일히 이동해야 하는 작업이 필요하다.

이런 부가적인 연산은 시스템의 성능 저하로 이어져 삽입/삭제가 빈번하게 발생하는 프로세스의 경우, 치명적일 수 있다.

그리고 자료들이 지속적으로 삭제되는 과정에서 ArrayList에서는 그 공간만큼 낭비되는 메모리가 많아지게 되고

또한 리사이징 처리에서 시간이 소모된다.

LinkedList의 장단점

장점

LinkedList는 불연속적으로 존재하는 데이터를 서로 연결한 형태로 구성되어있기 때문에 공간의 제약이 존재하지 않으며,

삽입 역시 노드가 가리키는 포인터만 바꿔주면 되기 때문에 배열처럼 데이터를 이동하기 위해 복사하는 과정이 없어

삽입/삭제 처리 속도가 빠르다.

따라서, 삽입/삭제가 자주 발생하는 프로세스의 경우 LinkedList를 사용하여 시스템을 구현하는 것이 바람직하다.

단점

하지만 LinkedList에도 만능이 아니며 단점이 존재한다.

요소를 get하는 과정에서 ArrayList와 굉장한 성능 차이를 보이는데, ArrayList에서는 무작위 접근(random access)이 가능하지만,

LinkedList에서는 순차 접근(sequential access)만이 가능하기 때문이다.

예를 들어 n개의 자료를 저장할 때, ArrayList는 자료들을 하나의 연속적인 묶음으로 묶어 자료를 저장하는 반면

LinkedList는 자료들을 저장 공간에 불연속적인 단위로 저장하게 된다.

이를 그림으로 표현하자면, 아래 빌딩 그림을 메모리(RAM)으로 비유하고 각기 방을 데이터라고 비유하면

ArrayList는 연속적인 묶음으로 되어있지만, LinkedList는 각기 다른 방에 저장되어 있고 링크로 연결되어 있음을 볼 수 있다.

그래서 LinkedList는 메모리 이곳저곳에 산재해 저장되어 있는 노드들을 접근하는데 있어

ArrayList보다 당연히 긴 지연 시간이 소모되게 된다.

LinekdList의 또 다른 단점은 참조자를 위해 추가적인 메모리를 할당해야 한다는 점이다.

배열 같은 경우 그냥 데이터 그대로만 저장하면 되지만, LinkedList의 노드 같은 경우 데이터 이외에

next나 prev 같은 참조자도 저장해야 되기 때문에 추가적인 공간이 더 필요할 수 밖에 없다.

- LinkedList 장단점 표.

LinkedList 장점	LinkedList 단점
자료의 삽입과 삭제가 용이	포인터의 사용으로 인해 저장 공간의 낭비
리스트 내에서 자료의 이동이 불필요	알고리즘이 복잡
사용 후 기억 장소의 재사용이 가능	특정 자료의 탐색 시간이 많이 소요
연속적인 기억 장소의 할당이 불필요	-

ArrayList vs LinkedList 성능 비교

시간 복잡도 비교

LinkedList에 대해 착각하는 것이 요소를 추가하는 것과 요소가 삭제하는 것의 시간 복잡도가 오로지 O(1)이라는 점이다.

맨 압이나 맨 뒤 요소만 추가하고 삭제한다고 가정하면 맞지만, 중간에 요소를 추가/삭제한다면

그 중간 위치까지 탐색을 해야 하므로 최종적으로 O(N)이 된다.

연산	양방향 LinkedList(doubly)	ArrayList	추천
첫번째 위치에 insert / remove	O(1)	O(N)	LinkedList
마지막 위치에 insert / remove	O(1)	O(1) / O(N)	LinkedList
중간에 insert / remove	O(N) / search time + O(1)	O(N)	LinkedList
값으로 search	O(N)	O(N)	ArrayList
인덱스로 값 get	O(N)	O(1)	ArrayList
값으로 remove	O(N)	O(N)	LinkedList

위의 표에서 ArrayList에서 첫번째 삽입이 O(N)인 이유는 무조건적으로 요소들을 뒤로 이동해야 되기 때문이다.

그리고 마지막 위치 삽입이 O(1) 또는 O(N)이 되는 이유는 만일 공간 부족으로 인해 배열 복사가 일어나면 시간이 소요되기 때문이다.

실제 성능 측정

조회(get) 시에는 ArrayList가 우위지만 삽입 / 삭제(add/remove) 시에는 LinkedList가 뛰어난 성능을 보여준다.

[순차 추가] LinkedList

: LinkedList가 우위인 이유는 ArrayList는 공간 부족으로 인한 배열 복사가 일어나기 때문이다.

[중간 추가] LinkedList

: LinkedList가 우위인 이유는 ArrayList는 배열 복사 및 데이터 이동이 발생하기 때문이다.

[접근 시간] ArrayList

: ArrayList가 우위인 이유는 메모리 저장 구조상 배열은 연속된 공간에 저장되고 인덱스로 단번에 엑세스하기 때문이다.

[중간 삭제] LinkedList

: LinkedList가 우위인 이유는 요소 이동없이 그저 노드의 포인팅만 교체만 하면 되기 때문이다.

[순차 삭제] ArrayList

: ArrayList가 우위인 이유는 노드의 링크를 끊고 하는 작업보단 배열에서 요소를 삭제하는게 더 빠르기 때문이다.

LinkedList는 의외로 잘 사용되지 않는다.

보통 ArrayList와 LinkedList 중에 어느걸 사용하면 되냐고 묻는다면

삽입/삭제가 빈번하면 LinkedList를, 요소를 가져오기가 빈번하면 ArrayList를 사용하면 된다고 하지만,

사실 성능면에서 둘은 큰 차이가 없다.

예를 들어, ArrayList는 리사이징 과정에서 배열 복사하는 추가 시간이 들지만,

배열을 새로 만들고 for문을 돌려 기존 요소를 일일히 대입하는 것이 아닌 내부적으로 잘 튜닝이 되고

최적화가 되어있어 생각하는 것처럼 전혀 느리지 않다.

ZUSTAND

jay-dev — Wed, 22 May 2024 18:37:14 +0900

ZUSTAND에 관심을 갖게 된 이유

npm trends에 따르면 redux 다음으로 가장 핫한 상태관리 라이브러리,

꾸준하게 상승중이고 상승폭도 가장 커 다음 프로젝트에는 Zustand를 사용해보려고 한다.

왜 ZUSTAND가 핫할까?

https://zustand-demo.pmnd.rs/

Zustand

zustand-demo.pmnd.rs

1. 직관적이고 간편한 사용법

ZUSTAND 메인페이지와 Documentation에서 사용법을 살펴보면

npm install zustand

import { create } from 'zustand'

const useStore = create((set) => ({
  count: 1,
  inc: () => set((state) => ({ count: state.count + 1 })),
}))

function Counter() {
  const { count, inc } = useStore()
  return (
    <div>
      <span>{count}</span>
      <button onClick={inc}>one up</button>
    </div>
  )
}

이게 끝.

정말 쉽게 사용할 수 있다.

2. 작은 크기

Redux, Recoil 보다 훨씬 작은 사이즈를 가져 가볍고 빠르다.

3. 중복 렌더링 최소화

ZUSTAND는 상태 업데이트 시 중복 렌더링을 최소화하여 성능 최적화에 유리,

상태가 변경되더라도 관련된 컴포넌트만 업데이트 한다.

하루가 멀다하고 바뀌는 프론트엔드 기술..

핫한 것만 따라갑시다이-

저는 이번에 포폴 만들 때 요걸 사용해볼까 생각 중

사용법은 제가 실제로 사용해보고 요기다가 업데이트 할게요

jquery를 사용하지 않게 된 이유

H.E — Mon, 20 May 2024 22:20:46 +0900

[ jQuery ]

jQuery는 JS를 작성하는것은 재밌어야 한다는 모토를 가진 JS 라이브러리

적게 쓰고 많은 일을 하게(write less, do more) 도와주는 JS 라이브러리라고 생각하면 됨

일반적으로 반복적인 작업을 수행하고 불필요한 마크업을 제거, 짧고 이해하기 쉬운 코드를 작성할 수 있게 해줌

예를 들어 jQuery가 등장하기 이전에는 XMLHttpRequest를 사용하여 비동기 통신을 처리해야 했음

let xhr = new XMLHttpRequest();
xhr.open('POST', '/test');
xhr.send();
xhr.onload = function () {
  if (xhr.status != 200) {
    console.error(`${xhr.status}: ${xhr.statusText}`);
  } else {
    console.log(xhr.response);
  }
};
xhr.onprogress = function (event) {
  if (event.lengthComputable) {
    console.error(`Received ${event.loaded} of ${event.total} bytes`);
  } else {
    console.error(`Received ${event.loaded} bytes`);
  }
};
xhr.onerror = function () {
  console.error('Request failed');
};

하지만 jQuery의 Ajax를 이용하면 코드가 훨씬 간단해짐

$.ajax({
  type: 'post',
  url: '/test',
  async: true,
  headers: {
    'Content-Type': 'application/json',
  },
  dataType: 'text',
  data: JSON.stringify({
    id: id,
    name: name,
  }),
  success: function (result) {
    console.log(result);
  },
  error: function (request, status, error) {
    console.error(error);
  },
});

▶ jQuery 특징

HTML/DOM 조작: HTML 요소를 쉽게 선택하고 조작할 수 있음
이벤트 처리: 다양한 이벤트를 간단하게 처리할 수 있음
크로스 브라우징: 다양한 브라우저 간 호환성 문제를 해결해 줌
애니메이션: 간단한 애니메이션 효과를 쉽게 구현할 수 있음
메소드 체이닝(Method chaining) 등 짧고 유지관리가 용이한 코드 작성을 지원
플러그인: 플러그인을 쉽게 구현하거나 확장할 수 있음

▶ jQuery를 사용하지 않게 된 이유

jQuery는 초기 웹 개발 환경에서 큰 혁신을 가져왔으나, 시간이 지나면서 몇 가지 한계가 드러남

성능 최적화 문제와 유지보수의 어려움이 그 주요 원인

성능 문제: jQuery는 Vanilla JS에 비해 로드해야 할 패키지가 많아 간단한 코드를 작성하더라도 성능적으로 떨어짐
유지보수 어려움: jQuery는 모듈화나 컴포넌트화와는 거리가 있어 대규모 애플리케이션에서 유지보수하기 쉽지 않음
브라우저 성능 저하: 현대의 웹 애플리케이션에서는 사용자에 의한 동적인 DOM 조작이 잦음 jQuery를 이용하면 배치와 화면 표시 과정에서 많은 연산이 발생해 브라우저 성능이 저하되는 문제가 있음

이 외에도

웹 표준 API의 확장 : 제이쿼리가 없어도 쉽게 사용 가능해진 웹 api

웹 표준이 개선되어 여러 브라우저는 표준을 지키는 방향으로 나아가고 있음 이런 노력으로 WEB API가 발전하였음

fetch API, DOM API(classList, querySelector, querySelectorAll)와 같은 jQuery의 대체제가 등장함

예를 들어 위에 비동기 통신 예시를 fetch를 사용하면 훨씬 간단해짐

fetch('/test', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    id: id,
    name: name,
  }),
})
  .then(response => console.log(response))
  .catch(error => console.error(error));

웹브라우저 환경의 변화 : 빨라진 자바스크립트 성능과 브라우저 호환성이 좋아짐

초기 웹 개발에서 jQuery는 다양한 브라우저 간의 호환성 문제를 해결하는데 큰 역활을 했지만 최신 브라우저들은 대부분 ECMScript 표준을 잘 준수하고 있어 이러한 호환성 문제가 크게 감소하게 됨

제이쿼리가 본격적으로 인기를 얻기 시작했던 2007~2008년에는 인터넷 익스플로러가 웹브라우저 시장에서 점유율이 가장 높았고, 인터넷 익스플로러는 버전 업데이트 속도가 느리고 데스크톱 기반의 윈도우 운영체제에 주력했다는 특징이 있어 생산성과 가독성이 높은 코드를 작성하기 위해 제이쿼리가 사용되었음

하지만 윈도우, 맥 등 데스크톱 OS와 모바일 OS까지 지원하는 크롬이 등장하며 점유율을 높게 장악했는데 크롬은 빠른 버전 업데이트를 추구하여 웹 표준을 신속하게 반영함

가상 돔을 사용하는 라이브러리의 등장 : 성능적으로 개선된 방법인 가상돔을 사용하는 라이브러리

React와 같은 라이브러리는 가상 DOM을 사용하여 웹 애플리케이션의 성능을 크게 향상시켰음

가상 DOM은 실제 DOM 조작을 최소화하여 애플리케이션의 성능을 높이며, jQuery가 제공하지 못하는 선언적이고 모듈화된 프로그래밍 패러다임을 제공함 이를 통해 개발자는 더 효율적이고 유지보수하기 쉬운 코드를 작성할 수 있음

▶ React와 jQuery 비교

React와 jQuery의 가장 중요한 차이는 가상돔 사용과 컴포넌트 기반 아키텍처

DOM 컨트롤

React는 가상 DOM을 사용하여 실제 DOM 조작을 최소화하고 성능을 향상시킴

jQuery는 우선 최초로 DOM 을 찾으려면 document 에서부터 쭉 타고 내려오면서 찾아야함

이렇게 되면 원하는 태그를 찾을 때까지 최상단 엘리먼트에서 트리 탐색을하며 내려오니까 더 많은 검색이 발생함

실제 DOM을 직접 조작하므로 더 많은 DOM 조작이 필요한 등의 성능 저하가 발생함

예를들어 document.getElementById('myDiv')로 간단하게 찾는 한줄코딩이라면, jQuery는 수없이 많이 랩핑된 소스에서 $('#myDiv')을 찾게 됨으로써 불필요한 리소스로 인한 동작의 저하가 발생 할 수 있음

컴포넌트 기반 아키텍처

React는 컴포넌트를 사용하여 UI를 작성하고 관리하며, 각 컴포넌트는 독립적으로 작동하며 재사용 가능함

이를 통해 코드 모듈화와 유지 보수를 용이하게 함

jQuery는 이러한 컴포넌트 기반 아키텍처를 제공하지 않으며, 코드는 주로 이벤트 핸들러와 DOM 조작 함수로 이루어져 있음 따라서 모든 로직이 한 곳에 집중되어 있어 코드가 길어지고 유지보수하기 어려움

처음에는 단순히 jQuery가 무엇인지, 왜 요즘에는 덜 사용되는지를 알고 싶었지만, 실제로 조사해보니 웹 개발 환경의 변화와 기술 발전이 얼마나 빠르고 다채롭게 이루어지고 있는지를 알게 됨

jQuery는 처음에는 웹 개발에 혁신을 가져온 도구였음 단순하고 직관적인 API로 복잡한 DOM 조작을 쉽게 만들고, 다양한 브라우저 간의 호환성 문제를 해결해주었기 때문 하지만 웹 표준 API의 발전과 브라우저 성능의 향상, 그리고 React와 같은 가상 DOM을 사용하는 라이브러리의 등장은 jQuery를 뒤편으로 보내버림

React의 컴포넌트 기반 아키텍처와 가상 DOM의 도입은 코드의 재사용성과 유지보수성을 크게 향상시켰음 이러한 기술적 발전은 단순히 새로운 도구를 사용하는 것을 넘어, 전체적인 개발 패러다임의 변화를 가져옴 예를 들어, React의 컴포넌트 기반 구조는 대규모 애플리케이션에서도 코드의 모듈화와 재사용을 용이하게 하고, 선언적 프로그래밍 스타일은 상태 관리와 UI 갱신을 더욱 직관적으로 만들어 줌

결국, 기술은 끊임없이 발전하고 변화함 jQuery가 혁신적이었던 시절이 있었듯이, 현재는 React와 같은 가상 돔을 사용하는 라이브러리가 그 자리를 차지하고 있음 이러한 변화 속에서 중요한 것은 트렌드를 새롭게 갱신하고 새로운 기술을 배우고 적응하며, 이를 통해 더욱 효율적이고 생산적인 개발을 할 수 있는 능력이 필요하다는 것을 다시 한번 느낌 앞으로도 계속해서 변화하는 웹 개발 환경을 주시하며, 최신 기술을 습득하고 적용할 수 있도록 노력해야 겠음

Jotai

H.E — Wed, 8 May 2024 20:15:00 +0900

Jotai

Jotai는 React State Management Libarary 중 하나이고 Recoil, Redux와 같이 상태 관리에 필요한 편의 기능을 제공하는 라이브러리

Jotai는 Recoil과 같은 Atomic 접근 방식으로 React에서 사용되는 state와 비슷하게 리액트 트리 안에서 상태를 저장하고 관리하는 방법임

Jotai 특징

https://jotai.org/

Jotai, primitive and flexible state management for React

Jotai takes a bottom-up approach to global React state management with an atomic model inspired by Recoil. One can build state by combining atoms and renders are optimized based on atom dependency. This solves the extra re-render issue of React context and

jotai.org

Jotai 공식문서에 따르며 Recoil에서 영감을 받아 React 상태 관리에 대한 원자적 접근 방식을 취하는 도구이며 원자 종속성에 따라 자동으로 최적화되고 매우 최소한의 API를 가지고 있으며 useState의 간단한 대체부터 복잡한 요구 사항이 있는 엔터프라이즈 TypeScript 애플리케이션까지 확장 가능하며, 다양한 유틸리티와 통합 기능을 제공한다고 나와있음

특징을 정리해보면

작은 번들 크기
Recoil에서 영감을 받아 아토믹( Atomic) 모델과 함께 상향식 접근(Bottom-up) 방식으로 접근
아톰과 함께 상태를 생성하고 렌더링 최적화
- 리액트 context의 Re-rendering 이슈를 해결하고 메모이제이션(memorization)의 의존도를 줄일 수 있음
React의 Context(useState + useContext) 기반 상태관리 모델에서 발생한 주요 이슈들의 개선에 초점을 맞춤

Recoil보다 선호되는 이유

경량화된 API
String key의 미사용
TypeScript 기반
utils 함수들의 제공

Jotai는 언제 사용할까?

작은 규모의 프로젝트
- Redux나 MobX와 같은 다른 상태 관리 라이브러리보다 상대적으로 작음
간단한 상태 관리
- Redux나 MobX와 같은 상태 관리 라이브러리에 비해 보다 단순하고 직관적인 API를 제공
별도의 라이브러리를 사용하지 않아도 됨
- Context API와 함께 작동하며, Context API의 간편한 사용법을 이용하여 상태관리를 할 수 있음

Jotai 사용

atom()

import { atom } from 'jotai';

const priceAtom = atom(10); // number
const messageAtom = atom('hello'); // string
const productAtom = atom({ id: 12, name: 'good stuff' }); // object
const citiesAtom = atom(['Tokyo', 'Kyoto', 'Osaka']); // array

jotail의 내장 API
상태의 단위(조각)이자 state를 생성하는 함수
Recoil과 달리 key값(string)을 설정하지 않음

읽기 / 쓰기 전용 atom

import { atom } from 'jotai';

const priceAtom = atom(10);

const readOnlyAtom = atom((get) => get(priceAtom) * 2);
const writeOnlyAtom = atom(
  null, // 첫 번째 인자로 전달하는 초기값은 null
  (get, set, update) => {
    // update는 atom을 업데이트하기 위해 받아오는 값
    set(priceAtom, get(priceAtom) - update.discount)
  }
);

const readWriteAtom = atom(
  (get) => get(priceAtom) * 2,
  (get, set, newPrice) => {
    set(proceAtom, newPrice / 2)
    // set 로직은 원하는 만큼 지정할 수 있음
  }
);

// 읽기(read)
import { useAtomValue } from 'jotai';
const count = useAtomValue(countAtom);

// 쓰기(write)
import { useSetValue } from 'jotai';
const count = useSetValue(countAtom);

읽기 전용(Read-only)
쓰기 전용(Write-only)
읽기,쓰기 전용(Read-Write)

useAtom()

useAtom 훅은 atom을 인자로 받아, [atom, setAtom] 값과 세터함수를 튜플로 반환

상태를 적용하고자 하는 컴포넌트 내에서 useAtom을 import해서 상태 & 세터함수를 선언해주면 됨

import { useAtom } from 'jotai';
import { countAtom } from '../store';

function Counter() {
  const [count, setCount] = useAtom(countAtom)
  return (
    <div>
      {count}
      <button onClick={() => setCount(c => c + 1)}>+1</button>
    </div>
  )
}

Async

Jotai는 atom이 동기/비동기를 모두 담당

초기 fetch를 위해 write 함수인자를 활용하면 됨

const fetchUrlAtom = atom(async (get) => {
  const response = await fetch(get('https://my-api.com'));
  return await response.json();
})

비동기 상태 fetch간 노출할 목적으로, <Suspense> 컴포넌트로 감싸서 fallback을 설정해줘야 함

const App = () => (
  <Proveider>
    <Suspense fallback="Loading...">
      <Layout />
    </Suspense>
  </Provider>
)

Utils

Jotai에서 유용한 유틸을 제공해줌

리셋이나 스토리지 저장 등 다양한 메서드가 들어있음

import { atom, useAtom } from 'jotai';
import { useAtomValue, useUpdateAtom } from 'jotai/utils';

const exampleAtom = atom(0);

const Example = (0 => {
  // 기존 useAtom
  const [myAtom, setMyAtom] = useAtom(exampleAtom);
  
  // useAtomValue, useUpdateAtom 각각 적용
  connst myAyom = useAtomValue(exampleAtom);
  const setMyAtom = useUpdateAtom(exampleAtom);
  
  return <div>atom: {myAtom}</div>
}

AtomWithStorage

atom 상태값을 스토리지에 저장하는 유틸리티 함수. 토큰 등 스토리지와 연관되는 전역상태에 유용

인자는 키네임, 값, 옵션을 받으며, 옵션의 기본값은 localStorage

const anAtom = atomWithStorage('Is_key', [], {
  ...createJSONStorage(() => localStorage),
  delayInit: true,
})

AWS S3 + CloudFront 배포

고래강이 — Wed, 8 May 2024 18:17:55 +0900

개요

1. AWS IAM 설정
2. S3 생성 및 설정
3. CloudFront 설정
4. Github Action으로 CI / CD 구축

✅ AWS IAM 설정

IAM(Identity and Access Management)이란?

AWS리소스에 대한 엑세스를 안전하게 제어할 수 있는 웹 서비스로 AWS 계정을 최초로 생성할 때 만들어지는 루트 사용자는 모든 엑세스 권한을 가지기에 보안에 주의해서 사용해야하므로 IAM을 통해 리소스를 사용할 수 있는 인증 및 권한 부여된 대상을 제어한다.

리소스에 대해 여러 사람에게 다양한 권한을 부여할 수 있다.
사용자에게 직접 정책을 설정할 수도 있지만 그룹에 대해서도 부여할 수 있다.

IAM 사용자 추가하기

AWS > IAM > 사용자 생성 > 1 ~3단계 수행 > 생성

IAM 생성 + 그룹에 사용자 추가하기

S3FullAccess, CloudFrontFullAccess 두개의 권한 옵션을 설정해준다.
IAM을 통해 발급 받는 access key는 추후에 자주 사용되므로 꼭 발급 받자
이때 그룹은 권합 옵션을 공유해주는 집단이므로 프로젝트 팀명으로 구분이 쉽게 하였다.

access key 발급

✅ S3 생성 및 설정

S3(Simple Storage Service)란?

인터넷 스토리지 서비스로 데이터를 객체 형태로 저장하는 파일 저장 서비스이며, 주로 이미지, 동영상 파일 저장을 위해 사용된다.

SSL을 통해 데이터를 전송 및 암호화하여 높은 내구성과 보안성을 가지고 있다.
EC2보다 이미지, 영상을 저장할 때 비용이 저렴하다.
파일 저장에 최적화 되어 업로드 / 다운로드 속도가 빠르고 정적 웹페이지의 경우 성능을 높이고 비용을 절감할 수 있다.
저장 용량이 크다.

S3 버킷 생성

AWS > S3 > 버킷만들기 > 생성

ACL 활성화 여부는 외부 노출을 원천 봉쇄하기 위함

버킷 생성 과정

버킷에 대한 접근을 CloudFront에서 할 것이기에 퍼블릭 엑세스 차단
버킷 버전에 대한 관리 필요성이 없기에 비활성화

S3 버킷 설정

AWS > S3 > [버킷 네임] > 속성

정적 웹 사이트 호스팅을 활성화하여 S3 버킷을 웹사이트로 이용할 수 있게끔 할 수 있다. 이는 S3 버킷에 저장된 파일을 웹 브라우저에서 직접 엑세스할 수 있게 해주기 때문이다.

설정을 완료하면 버킷 웹 사이트 엔드포인트가 부여가 되지만 정책 설정 및 프로젝트를 올리지 않았기에 접속시 403Error가 발생한다

AWS > S3 > [버킷 네임] > 권한

버킷 정책 설정을 하기 위해서는 기존에 퍼블릭 엑세스 차단을 비활성화로 바꾼 뒤 진행하면 된다.
버킷 정책은 버킷을 사용할 권한을 가진 여러 명의 사용자 별로 각각의 행위에 대한 권한 범위를 설정하는 것이다. 이를 통해 읽기, 쓰기 등 행동에 대한 제한을 가할 수도 있고 허용할 수도 있다.
정책 생성기를 통해 간편하게 정책을 생성할 수 있으며 아래와 같은 방식으로 정책을 생성해보자.

정책 생성

정책 생성기

4가지를 설정하면 된다

Select Type of Policy에서 S3 Bucket Policy를 선택한다.
Effect는 Allow 설정
Principa은 * 설정
Action은 GetObjcet 설정
Amazon Resorce Name에 복사해놓은 ARN에 끝에 /*를 붙인다.

이 정책 문서는 IAM의 정책으로 사용되어 특정 사용자 또는 그룹, 리소스가 S3 버킷에 대한 어떤 작업을 수행할 수 있는지를 제어하고 일반적으로 다음과 같은 내용을 포함한다.

어떤 작업이 허용되는지 (GetObject ...)
어떤 리소스에 대한 엑세스가 허용되는지 (특정 버킷, 버킷의 모든 객체 ...)
엑세스를 요청할 수 있는 조건 (IP 주소, IAM 역할 ...)

이 정책은 S3 버킷 자체에 직접 연결되지 않고 IAM 사용자, 그룹 또는 역할에 연결되어 AWS의 엑세스 제어 매커니즘을 통해 사용자의 권한을 관리하고 제어할 수 있다.

AWS CLI를 통한 S3 버킷에 프로젝트 업로드

- Install

가이드 내용에 따라 설치 후 aws에 대한 설치 상태를 확인

- User setting (CLI)

aws configure --profile [IAM 사용자 이름]
Key ID : IAM 사용자 추가할 때 다운받았던 CSV 파일의 Access key ID
Access Key : IAM 사용자 추가할 때 다운받았던 CSV 파일의 Secret access key
region name : ap-northeast-2output
format : json

- Uploading

// package.json

{
	...
    "script": {
    	...
        "deploy": "aws s3 sync ./dist s3://[S3 버킷 이름] --profile=[IAM 사용자 이름]"
    }
}
// ./dist는 vite를 사용해서 그런거고 CRA를 이용했다면 ./build로 나올 것임

✅ CloudFront에 배포하기

CloudFront의 이점?

성능
정적 리소스에 대해 캐시를 사용하여 데이터를 관리할 수 있으며 캐시를 짧게 하거나 날리는 등 적절하게 설정한다면 성능상 많은 개선을 할 수 있다.
보안
CloudFront만을 통해서 유저가 S3로 접근할 수 있어 보안을 높일 수 있다(public Access를 비활성화할 수 있다.)
글로벌 서비스
CloudFront는 생성한 region에 속하지 않고 엣지 로케이션이라는 캐싱 서버에 캐싱되기에 전 세계 사용자들에게 빠르게 응답할 수 있다.

CloudFront 배포 생성

AWS > CloudFront > 배포 > 생성

Origin domain에 대해 S3 버킷을 선택한 뒤 버킷을 CloudFront에서만 접근할 수 있게 하기위해 원본 엑세스 설정 후 OAC를 생성하자

Origin Shield를 활성화함으로 엣지 로케이션에서 가져오는 콘텐츠의 요청을 최적화할 수 있다.

Origin Shield

Origin Shield의 유무

여러 지역에 엣지 로케이션이 존재하고 요청하는 객체를 캐시에 가지고 있지 않을 때에는 각 엣지 로케이션이 동시에 Origin으로 요청을해서 S3 버킷에 대해 과부화가 일어날 수 있다. 이때 Origin Shield가 있다면 요청은 Shield로 가게되고 Origin Shield가 S3 버킷에서 객체를 가져오게 된다. 모든 엣지 로케이션은 Shield로 요청을 하므로 S3에 대한 부하를 줄일 수 있고 이를 통해 전번적인 성능과 신뢰성을 향상시킬 수 있다.

기본 캐시 동작은 뷰어 프로토콜 정책만 변경 후 나머지는 기본값으로 사용한다.
WAF는 악의적인 HTTP/S 트래픽을 필터링, 모니터링 및 타단하여 웹 앱을 보호하고, 승인되지 않은 데이터가 앱에서 나가는 것을 방지하지만 비용이 청구되는 옵션이기에 비활성화

배포 완료 후 사용자 정의 오류 응답편집을 설정하여 마무리를 하면 된다.
이후 CloudFront의 배포 도메인을 통해서 접근할 수 있다.

✅ Github Action으로 CI / CD 구축

CI / CD(Continuous Integration / Continuous Deployment)란?

지속적 통합은 개발 팀이 코드를 지속적으로 통합하고 이를 자동으로 테스트하여 버그를 최소화하는 프로세스이다. 코드 변경 시(push)에 자동으로 빌드 및 테스트를 진행하여 프로덕트 품질 관리 및 버그 발견이 빨라질 수 있으며, 지속적 배포를 통해 새로운 기능을 사용자에게 빠르게 전달하고 구축 시간을 단축시킬 수 있습니다.

github aciton뿐만아니라 Jenkins, Travis... 여러 CI / CD 툴이 존재한다.
위와 같은 도구를 통해서 배포에 대한 파이프라인을 설정한다.
파이프라인 구축을 통해 불필요한 비용도 줄이고, 개발에만 집중할 수 있는 환경을 조성할 수 있다.

.github/workflows/cicd.yaml 만들기

name: front-dev-deploy

on:
  push:
    branches: main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout source code
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v3

      - name: Install Dependencies
        run: pnpm

      - name: Build
        run: pnpm run build

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ap-northeast-2

      - name: S3 Deploy
        run: aws s3 sync ./dist s3://${{ secrets.AWS_S3_BUCKET }} --acl bucket-owner-full-control

      - name: Invalidate CloudFront Cache
        run: aws cloudfront create-invalidation --distribution-id ${{secrets.CLOUD_FRONT_ID}} --paths "/*"

secret 설정하기

Build 및 Deploy 환경에 사용될 환경 변수를 등록하는 것으로 각 환경변수가 무슨 값인지 헷갈리지 않도록 주의해야한다.