JavaScript의 모든 객체는 프로토타입이라는 객체를 참조합니다. 프로토타입은 객체가 공유할 속성이나 메서드를 정의하는 데 사용되며, 새 객체가 생성될 때 해당 객체는 자신의 프로토타입을 상속받습니다.

예시

function Person(name) {
  this.name = name;
}

Person.prototype.sayHello = function() {
  console.log(`Hello, my name is ${this.name}`);
};

const Hong = new Person('Hong');
Hong.sayHello(); // 출력: Hello, my name is Hong

• 여기서 Person.prototype에 정의된 sayHello 메서드는 Hong 객체가 상속받아 사용합니다.
• 이는 메모리 절약에도 유리합니다. 메서드를 공유하므로 각 객체마다 동일한 메서드를 복사하지 않아도 됩니다.

프로토타입 체인

프로토타입 체인은 객체가 속성이나 메서드를 찾는 과정을 설명합니다. 객체에서 특정 속성이나 메서드를 찾으려고 할 때, 자바스크립트는 다음 단계를 따릅니다

1. 해당 객체에 속성이 있는지 확인합니다.
2. 없다면 그 객체의 프로토타입을 확인합니다.
3. 계속해서 상위 프로토타입으로 검색을 이어갑니다.
4. 최상위 Object.prototype까지 확인하며, 거기서도 찾지 못하면 undefined를 반환합니다.

   console.log(Hong.toString()); 
   // `Hong` 객체에는 `toString` 메서드가 없음 → `Person.prototype` 확인
   // `Person.prototype`에도 없음 → `Object.prototype`에서 찾음 → 실행
   

### 프로토타입과 상속
JavaScript에서는 프로토타입 기반 상속을 통해 객체 간에 속성과 메서드를 공유할 수 있습니다.
ES6의 `class` 문법도 결국 내부적으로는 프로토타입을 활용한 상속을 활용합니다.

function Animal(name) { this.name = name; }

Animal.prototype.move = function() { console.log(${this.name} is moving); };

function Dog(name, breed) { Animal.call(this, name); // Animal의 생성자 호출 this.breed = breed; }

Dog.prototype = Object.create(Animal.prototype); // 프로토타입 상속 Dog.prototype.constructor = Dog;

Dog.prototype.bark = function() { console.log(${this.name} says: Woof!); };

const myDog = new Dog('Buddy', 'Golden Retriever'); myDog.move(); // Buddy is moving (Animal의 메서드) myDog.bark(); // Buddy says: Woof! (Dog의 메서드)

**코드 설명**

**1. Animal 생성자 함수**

function Animal(name) { this.name = name; }

- `Animal`은 생성자 함수로, `new` 키워드로 호출하면 새로운 객체를 생성합니다.
- `name`이라는 속성을 초기화하며, 생성된 객체마다 고유의 값을 가질 수 있습니다.

**2. Animal의 프로토타입 메서드**

Animal.prototype.move = function() { console.log(${this.name} is moving); };

- `Animal.prototype`에 정의된 `move` 메서드는 모든 `Animal` 객체가 상속받아 사용할 수 있습니다.
- 프로토타입에 메서드를 정의하면 메모리를 절약할 수 있습니다. 모든 인스턴스가 이 메서드를 공유합니다.

**3. Dog 생성자 함수**

function Dog(name, breed) { Animal.call(this, name); // Animal의 생성자 호출 this.breed = breed; }

- `Dog`는 또 다른 생성자 함수입니다.
- `Animal.call(this, name)`를 사용해 `Animal`**의 생성자**를 호출하고, Dog 생성자에서 초기화 작업을 수행합니다.
  - 여기서 `this`는 `Dog` 인스턴스를 가리키며, 이를 통해 `name` 속성을 `Animal` 생성자에서 초기화합니다.
- `breed`라는 속성을 추가로 정의해 `Dog`에 고유한 속성을 설정합니다.

**4. Dog의 프로토타입 상속**

Dog.prototype = Object.create(Animal.prototype); // 프로토타입 상속 Dog.prototype.constructor = Dog;

- `Object.create(Animal.prototype)`
  - `Animal.prototype`을 프로토타입으로 가지는 새로운 객체를 생성합니다.
  - 이를 통해 `Dog`는 `Animal`의 프로토타입 체인을 상속받아 `move` 메서드를 사용할 수 있습니다.
- `Dog.prototype.constructor = Dog`
  - 프로토타입을 새로 설정하면 `constructor`가 기본적으로 `Animal`을 가리킵니다.
  - 이를 다시 `Dog`로 명시적으로 설정하여 정확한 생성자 정보를 유지합니다.


**5. Dog의 프로토타입 메서드**

Dog.prototype.bark = function() { console.log(${this.name} says: Woof!); };

- Dog.prototype에 bark 메서드를 추가합니다.
- 이 메서드는 Dog의 인스턴스에서만 사용 가능한 고유 메서드입니다.

**6. 객체 생성 및 메서드 호출**

const myDog = new Dog('Buddy', 'Golden Retriever');

- `new Dog('Buddy', 'Golden Retriever')`
  - 새로운 `Dog` 객체를 생성합니다.
  - `Animal` 생성자를 호출하여 `name` 속성을 `Buddy`로 초기화하고, `breed` 속성을 `Golden Retriever`로 설정합니다.

myDog.move(); // Buddy is moving (Animal의 메서드) myDog.bark(); // Buddy says: Woof! (Dog의 메서드)

- `myDog.move()`
  - `move` 메서드는 `Animal.prototype`에서 상속받은 메서드입니다.
  - `this.name`은 `myDog` 객체의 `name` 속성`(Buddy)`를 참조합니다.
- `myDog.bark()`
  - `bark` 메서드는 `Dog.prototype`에서 정의된 메서드입니다.
  - `this.name`은 역시 `myDog` 객체의 `name` 속성을 참조합니다.


JavaScript의 프로토타입은 객체 지향 프로그래밍을 이해하는 데 핵심적인 개념이며, 효율적인 코드 작성과 메모리 관리의 기반이 된다.

프로토타입 기반 상속은 클래스 문법으로도 사용되지만, 내부적으로는 동일한 동작 방식을 따르니 이 개념을 정확히 이해하는 것이 중요하다.

자바스크립트 콜 스택은 자바스크립트 엔진에서 코드 실행 흐름을 관리하는 메커니즘으로, 함수 호출과 실행을 추적하는 데 사용됩니다.

콜 스택은 LIFO(Last In, First Out)방식으로 작동하는 데이터 구조입니다. 즉, 가장 마지막에 추가된 작업이 가장 먼저 제거됩니다.

아래에 코드가 실행되면 콜 스택에는 어떤 변화가 생길까요?

function first() {
  console.log("First function start");
  second();
  console.log("First function end");
}

function second() {
  console.log("Second function start");
  third();
  console.log("Second function end");
}

function third() {
  console.log("Third function");
}

first();

실행 흐름

1. first() 호출 → first 함수가 콜 스택에 푸시.
2. console.log 실행 → 메시지 출력.
3. second() 호출 → second 함수가 콜 스택에 푸시.
4. third() 호출 → third 함수가 콜 스택에 푸시.
5. console.log 실행 → 메시지 출력 후 third 함수가 스택에서 팝.
6. second 함수가 나머지 실행을 마친 후 팝.
7. first 함수도 실행을 완료한 뒤 팝.

콜 스택 변화

여기서 확인했듯이 자바스크립트 엔진은 한 번에 하나의 태스크만 실행할 수 있는 싱글 스레드 방식으로 동작하기 때문에 단 하나의 실행 컨텍스트 스택(콜 스택)을 갖습니다.

싱글 스레드 방식은 한 번에 하나의 태스크만 실행할 수 있기 때문에 처리에 시간이 걸리는 태스크를 실행하는 경우 블로킹(작업중단)이 발생한니다.

아래의 코드를 실행시키면 two 함수는 sleep 함수의 실행이 종료된 이후 호출되므로 3초 이상 호출되지 못하고 블로킹됩니다.

이렇게 현재 실행 중인 태스크가 종료할 때까지 다음에 실행될 테스크가 대기하는 방식을 동기처리라고 합니다. 실행 순서가 보장된다는 장점이 있지만, 앞선 태스크가 종료될 때까지 이후 태스크들이 블로킹되는 단점이 존재합니다.

function sleep(func, delay) {
  const delayUntil = Date.now() + delay;

  while (Date.now() < delayUntil);

  func();
}

function one() {
  console.log("one");
}

function two() {
  console.log("two");
}

sleep(one, 3 * 1000);
two();

// 출력 결과
one
two

아래는 sleep 함수와 비슷한 기능을 수행하는 setTimeout 함수를 사용해보겠습니다. 출력 결과를 보면 setTimeout을 사용한 코드는 코드를 블로킹하지 않고 곧바로 실행합니다. 이러첨 현재 실행 중인 태스크가 종료되지 않은 상태라 해도 다음 태스크를 곧바로 실행하는 방식을 비동기처리라고 합니다.

function one() {
  console.log("one");
}

function two() {
  console.log("two");
}

setTimeout(one, 3 * 1000);
two();

// 출력 결과
two
one

그런데 위에서 자바스크립트 엔진은 싱글 스레드 방식으로 동작한다고 했는데 어떻게 비동기처리가 가능한걸까요? 이어서 알아보겠습니다.

타이머 함수인 setTimeout과 setInterval, HTTP 요청, 이벤트 핸들러는 비동기 처리 방식으로 동작합니다. 비동기 처리는 이벤트 루프와 태스크 큐와 깊은 관계가 있습니다.

앞서 살펴본 것처럼 싱글 스레드 방식은 한 번에 하나의 태스크만 처리할 수 있다는 것을 의미합니다. 하지만 브라우저가 동작하는 것을 보면 많은 태스크가 동시에 처리되는 것처럼 느껴집니다. 프로그램을 다운 받으면서 웹툰을 본다던가 노래를 들으면서 친구와 대화를 나눌수도 있습니다. 이처럼 자바스크립트의 동시성을 지원하는 것이 바로 이벤트 루프입니다. 이벤트 루프는 브라우저에 내장되어 있는 기능 중 하나입니다.

자바스크립트 런타임 환경

위 그림에서 Js Engine(자바스크립트 엔진) 부분을 보겠습니다. 자바스크립트 엔진은 크게 2개의 영역으로 구분할 수 있습니다.

** 힙(Heap)**

설명: 힙은 자바스크립트 엔진에서 사용하는 메모리 영역으로, 동적으로 할당된 객체와 데이터를 저장하는 공간입니다.

• 동적으로 생성된 변수나 객체(예: 배열, 객체 등)의 메모리 관리를 담당합니다.

• 힙에 저장된 데이터는 고정된 크기가 아니며, 필요에 따라 크기를 동적으로 조정할 수 있습니다.

• 가비지 컬렉터(Garbage Collector)에 의해 더 이상 참조되지 않는 데이터는 자동으로 제거됩니다.

콜 스택(Call Stack)

설명: 콜 스택은 자바스크립트 함수 호출과 실행 순서를 관리하는 LIFO(Last In, First Out) 방식의 데이터 구조입니다.

• 함수가 호출되면 해당 함수의 실행 컨텍스트가 스택에 쌓이고, 실행이 완료되면 스택에서 제거됩니다.

• 코드의 실행 흐름을 제어하며, 동기적으로 작동합니다.

콜 스택과 힙으로 구성되어 있는 자바스크립트 엔진은 단순히 태스크가 요청되면 콜 스택을 통해 요청된 작업을 순차적으로 실행할 뿐입니다. 비동기 처리에서 소스코드의 평가와 실행을 제외한 모든 처리는 자바스크립트 엔진을 구동하는 환경인 브라우저 또는 Node.js가 담당합니다. 예를 들어, 비동기 방식으로 동작하는 setTimeout의 콜백 함수의 평가와 실행은 자바스크립트 엔진이 담당하지만 호출 스케줄링을 위한 타이머 설정과 콜백 함수의 등록은 브라우저 또는 Node.js가 담당한다. 이를 위해 브라우저 환경은 태스크 큐와 이벤트 루프를 제공합니다.

태스크 큐와 이벤트 루프

태스크 큐(Task Queue)

• 태스크 큐는 브라우저에서 실행 대기 중인 비동기 작업의 콜백 함수를 저장하는 대기열입니다.

• 브라우저가 제공하는 Web APIs(ex. setTimeout, setInterval, DOM Events 등)를 통해 비동기로 처리해야 할 작업이 완료되면, 해당 작업의 콜백 함수가 태스크 큐에 추가됩니다.

동작 방식

1. 브라우저는 특정 비동기 작업(ex. 타이머, 이벤트 리스너)의 실행이 완료되면 그 콜백을 태스크 큐에 넣습니다.

2. 태스크 큐에 담긴 함수들은 콜 스택이 비었을 때 실행됩니다. (즉, 현재 실행 중인 코드가 끝난 후 실행)

console.log('1');

setTimeout(() => {
  console.log('2'); // 태스크 큐에 들어감
}, 0);

console.log('3');

// 출력 결과
1
3
2

setTimeout의 콜백은 태스크 큐에 추가되므로 1, 3이 먼저 출력되고, 이후 콜 스택이 비었을 때 2가 출력됩니다.

이벤트 루프(Event Loop)

• 이벤트 루프는 자바스크립트 런타임의 핵심 메커니즘으로, 콜 스택(Call Stack)과 태스크 큐(Task Queue)를 연결하여 비동기 작업을 관리합니다.

• 이벤트 루프는 계속 실행되면서 다음을 반복합니다: 콜 스택이 비어 있는지 확인. 비어 있다면, 태스크 큐에서 대기 중인 작업을 가져와 콜 스택에 추가하여 실행.

동작 방식

1. 자바스크립트는 싱글 스레드로 작동하며, 콜 스택에 작업을 하나씩 처리합니다.

2. 동기 코드는 즉시 실행되지만, 비동기 코드는 Web APIs에서 처리된 후 태스크 큐에 대기합니다.

3. 이벤트 루프가 태스크 큐를 확인하여, 콜 스택이 비었을 경우 태스크 큐의 작업을 실행합니다.

마이크로 태스큐 큐

마이크로 태스크 큐(Microtask Queue)는 프로그래밍, 특히 자바스크립트와 같은 이벤트 기반 언어에서 비동기 작업을 처리하는 데 중요한 역할을 하는 개념입니다. 이는 Event Loop의 일부로, 태스크를 관리하고 실행 순서를 제어하는 메커니즘입니다.

주요 특징

1. 작업의 우선 순위 마이크로 태스크 큐는 콜 스택 큐보다 우선 실행됩니다.

2. 처리 순서

• 이벤트 루프에서 현재 실행 중인 태스크가 완료되면, 먼저 마이크로 태스크 큐에 있는 모든 작업이 처리됩니다.
• 이후에 콜 스택 큐 큐로 넘어갑니다.

3. 주요 예 다음은 마이크로 태스크 큐를 사용하는 주요 비동기 작업입니다.

• Promise.then(), Promise.catch()
• MutationObserver
• queueMicrotask() (명시적으로 큐에 추가하는 방법)

아래 코드에 실행 결과를 스스로 예측해봅시다.

Promise.resolve().then(() => console.log(1));

setTimeout(() => console.log(2), 10);

queueMicrtask(() => {
  console.log(3)
  queueMicrotask(() => console.log(4))
});

console.log(5)

실행 과정

1. 초기 작업: 모든 명령은 처음에는 콜 스택에 들어가 실행됩니다.

• Promise.resolve() → 마이크로태스크 큐에 .then 추가
• setTimeout() → 10ms 후 실행될 콜백을 태스크 큐에 추가
• queueMicrotask() → 마이크로태스크 큐에 작업 추가
• console.log(5) → 즉시 실행

2. ** 콜 스택 실행** 후: 메인 스택이 비면** 마이크로태스크가 실행**됩니다. 마이크로태스크는 큐에서 FIFO로 실행되며, 실행 중 새로운 마이크로태스크가 추가되면 즉시 큐에 들어갑니다.

3. 매크로태스크 처리: 마이크로태스크가 모두 처리된 후, 매크로태스크가 실행됩니다.

실행 순서 (콜 스택 기준)

1단계: 초기 실행 (콜 스택에서 처리)

• Promise.resolve().then(...) → 마이크로태스크 큐에 추가
• setTimeout(...) → 태스큐 큐에 추가
• queueMicrotask(...) → 마이크로태스크 큐에 추가
• console.log(5) → 출력: 5

2단계: 마이크로태스크 큐 처리

1. Promise.then(...) 실행 → 출력: 1

2. 첫 번째 queueMicrotask(...) 실행 → 출력: 3

   • 이때, 내부의 queueMicrotask(...)가 또 마이크로태스크 큐에 추가됩니다.

3. 두 번째 queueMicrotask(...) 실행 → 출력: 4

3단계: 태스크 큐 처리

• setTimeout(...) 실행 → 출력: 2

최종 출력

5
1
3
4
2

이번 글을 통해 자바스크립트의** 비동기 처리, 이벤트 루프, 그리고 콜 스택의 작동 원리**에 대해 알아보았습니다. 이러한 기초 지식은 복잡한 비동기 로직을 작성하거나 디버깅할 때 큰 도움이 된다고 생각합니다. 자바스크립트 런타임 환경과 이벤트 루프의 작동 방식을 깊이 이해하면 더 효율적이고 안정적인 코드를 작성할 수 있습니다. 비동기 코드에서 발생할 수 있는 문제를 예방하려면 이 원리를 숙지해야 합니다!

Next.js 공식 문서에서 프로덕션에 배포하기 전에, next build 명령어를 사용해 로컬에서 애플리케이션을 빌드하고 빌드 오류가 있는지 확인할 수 있고, next start 명령어로 실제 프로덕션 환경과 유사한 상태에서 애플리케이션 성능을 측정할 수 있다고 한다.

웹 성능을 측정하기 위해 Lighthouse를 사용할 것이다. Lighthouse란 웹 사이트의 성능, 접근성, SEO, 그리고 웹 애플리케이션의 최적화 상태를 자동으로 분석해주는 오픈 소스 도구이다. LIghthouse 설치 및 실행 설명 링크

이번 글에서는 세부 측정 항목과 항목들에 대한 내용들에 대해서는 다루지 않고 실제 내 페이지에서 LightHouse를 실행했을 때의 결과를 토대로 어떻게 측정 점수를 올렸는지 적어보겠다.

일단 npm run dev로 개발모드를 실행시켜서 개발자 도구에서 console탭을 눌렀을 때 메시지를 확인하겠다. 부분은 홈 페이지 경로에 대한 모임 목록들인데 경고메시지를 보겠다.

LCP라는 메시지만 기억하고 아래 LightHouse 실행결과를 이어서 확인하자. 참고로 npm run build로 빌드하고 npm run start로 실행한 뒤 시크릿 모드로 접속하여 LightHouse를 실행하자!

시크릿 모드에서 진행하는 이유!

1. 브라우저 확장 프로그램의 간섭 방지: 설치된 확장 프로그램들이 Lighthouse의 성능 측정에 영향을 줄 수 있다. 예를 들어, 광고 차단기나 스크립트 차단 확장 프로그램이 페이지 로딩 속도나 성능 평가에 부정확한 결과를 초래할 수 있 다.

2. 로그인 및 캐시 배제: 비밀모드는 캐시나 로그인 정보가 저장되지 않기 때문에, 실제 사용자가 처음 웹사이트에 접속하는 환경과 비슷한 조건에서 테스트를 진행할 수 있다. 캐시된 데이터나 로그인 세션이 있으면 Lighthouse 테스트 결과가 실제와 다르게 나올 수 있으므로, 비밀모드를 사용하는 것이 더 권장된다.

시크릿 모드 권고 링크1 시크릿 모드 권고 링크2

Lighthouse 실행 및 결과

시크릿 모드에서 개발자 도구를 열고 Device는 Desktop을 클릭하고 우측 상단에 Analyze page load 버튼을 클릭한다. (1분 정도 소요되는 것 같다.)

우선 LCP는 최대 콘텐츠 렌더링 시간을 나타내고 보고서의 성능(Performance) 섹션에서 추적되는 측정항목 중 하나이다. 구체적으로 LCP는 사용자가 페이지 로드를 시작한 시점부터 표시 영역 내에서 가장 큰 이미지나 텍스트 블록이 렌더링될 때까지의 시간을 측정한다.

LCP 설명 링크

우선 LCP를 구성하는 하위 4가지 카테고리를 알아보자.

1. 첫 바이트까지의 시간(TTFB)

• 사용자가 페이지 로드를 시작한 시점부터 브라우저가 실행될 때까지의 시간

• HTML 문서 응답의 첫 바이트를 수신

2. 리소스 로드 지연

• 서버에서 첫 번째 응답이 도착한 후, 브라우저가 LCP리소스(이미지나 폰트 같은 주요 리소스)를 로드하기 시작할 때까지 걸리는 시간

• 즉,** 리소스를 로드하는 준비가 되기까지의 대기 **시간

3. 리소스 로드 시간

• 브라우저가 LCP 리소스를 실제로 다운로드하는 데 걸리는 시간

• 리소스 로드 지연 후, 브라우저가 해당 리소스를 로드하기 시작하면, 서버로부터 그 리소스를 가져오는 데 걸리는 시간이 리소스 로드 시간

• 예를 들어, 이미지 파일이나 폰트 파일을 서버에서 다운받는 시간이 여기에 해당

4. 렌더링 지연

• 웹페이지의 특정 요소나 콘텐츠가 화면에 보이기 전까지 발생하는 시간 지연을 의미

이미지 참고 및 4가지 카테고리 링크

다시 위에 처음 콘손에 나온 메시지를 보자. "Please add the "priority" property if this image is above the fold"

"above the fold"란?

• above the fold는 사용자가 페이지를 열었을 때 스크롤하지 않아도 바로 보이는 영역을 의미한다. 즉, 화면 상단에 위치한 중요한 콘텐츠들이다.

• 반대로 below the fold는 스크롤해야 보이는 영역

"priority" 속성이란?

• priority 속성은 Next.js에서 이미지를 우선적으로 로드하라고 지시하는 역할을 한다. 페이지의 로딩 성능을 최적화하는 데 중요한 요소다.

Next.js image 컴포넌트 priority 속성

메시지의 의미

이미지가 above the fold에 위치해 있기 때문에, 사용자가 페이지를 로드하자마자 바로 보이는 중요한 이미지라는 것을 뜻한다. 따라서 priority 속성을 추가하여 해당 이미지를 빠르게 로드하게 함으로써 페이지의 첫 화면 렌더링 속도를 개선하라는 제안이다.

적용 코드 첫 번째 이미지에서 priority 속성을 추가하라는 메시지가 나타났기 때문에 index 값이 0인(첫 번째 요소) 경우에 priority 프롭스를 boolean 값으로 ProgressCard 컴포넌트에 전달해주었다.

     {data.pages.flat().map((gathering, index) => (
       <ProgressCard key={gathering.id} gathering={gathering} priority={index === 0} />
     ))}

ProgressCard 컴포넌트 코드 일부분

  <Image
    src={gathering.image || '/card-image2.png'}
    alt="Image"
    fill
    className="object-cover rounded-t-3xl md:rounded-t-none"
    priority={priority}
  />

실제 베포 환경 최종 Lighthouse 결과

이렇게 보는 거와 같이 최종 결과는 performance 점수가 크게 상향하였고 LCP 응답 시간이 2.1s에서 0.3s로 감소하였다. 결론적으로 priority 속성만 추가하면 해결된 부분이였지만 이 과정 속에서 LCP가 무엇인지 어떻게 구성되어있는지 해결방법에 어떻게 접근했는지 배워간 부분이 많다.

인증에 대한 이해는 애플리케이션의 데이터를 보호하는 데 매우 중요합니다. 이 페이지에서는 인증을 구현할 때 React와 Next.js의 어떤 기능을 사용해야 하는지 안내합니다.

시작하기 전에, 과정을 세 가지 개념으로 나눠보면 도움이 됩니다.

1. 인증 (Authentication): 사용자가 본인이 맞는지 확인하는 과정으로, 주로 사용자 이름과 비밀번호 같은 정보로 신원을 증명합니다.

2. 세션 관리(Session Management): 여러 요청 간에 사용자의 인증 상태를 유지하고 추적합니다.

3. 권한 부여(Authorization): 사용자가 접근할 수 있는 경로와 데이터를 결정합니다.

이 다이어그램은 React와 Next.js 기능을 사용한 인증 흐름을 보여줍니다.

이 페이지의 예제에서는 교육적인 목적을 위해 기본적인 사용자 이름과 비밀번호 인증 과정을 설명합니다. 사용자 맞춤 인증 솔루션을 구현할 수도 있지만, 보안과 간편함을 위해 인증 라이브러리 사용을 권장합니다. 이러한 라이브러리는 인증, 세션 관리, 권한 부여를 위한 내장 솔루션을 제공하며, 소셜 로그인, 다단계 인증, 역할 기반 접근 제어와 같은 추가 기능도 포함되어 있습니다. 인증 라이브러리 목록은 ‘인증 라이브러리’ 섹션에서 확인할 수 있습니다.

가입 및 로그인 기능

React의 서버 액션과 useFormState를 활용하여 <form> 요소를 사용하여 사용자 자격 증명을 캡처하고, 폼 필드를 검증하며, 인증 공급자의 API 또는 데이터베이스를 호출할 수 있습니다.

서버 액션은 항상 서버에서 실행되므로 인증 로직을 처리하는 안전한 환경을 제공합니다.

다음은 회원가입/로그인 기능을 구현하는 단계입니다:

1. 사용자 자격 증명 입력 받기 사용자 자격 증명을 입력받기 위해, 제출 시 서버 액션을 호출하는 폼을 만듭니다. 예를 들어, 사용자의 이름, 이메일, 비밀번호를 입력받는 회원가입 폼은 다음과 같습니다:

app/ui/signup-form.tsx

import { signup } from '@/app/actions/auth'

export function SignupForm() {
  return (
    <form action={signup}>
      <div>
        <label htmlFor="name">Name</label>
        <input id="name" name="name" placeholder="Name" />
      </div>
      <div>
        <label htmlFor="email">Email</label>
        <input id="email" name="email" type="email" placeholder="Email" />
      </div>
      <div>
        <label htmlFor="password">Password</label>
        <input id="password" name="password" type="password" />
      </div>
      <button type="submit">Sign Up</button>
    </form>
  )
}

app/actions/auth.tsx

export async function signup(formData: FormData) {}

2. 서버에서 폼 필드 검증 서버에서 폼 필드를 검증하기 위해 서버 액션을 사용합니다. 만약 인증 공급자가 폼 검증을 제공하지 않는다면, Zod나 Yup과 같은 스키마 검증 라이브러리를 사용할 수 있습니다.

예를 들어, Zod를 사용하여 적절한 오류 메시지와 함께 폼 스키마를 정의할 수 있습니다:

app/lib/definitions.ts

import { z } from 'zod'

export const SignupFormSchema = z.object({
  name: z
    .string()
    .min(2, { message: 'Name must be at least 2 characters long.' })
    .trim(),
  email: z.string().email({ message: 'Please enter a valid email.' }).trim(),
  password: z
    .string()
    .min(8, { message: 'Be at least 8 characters long' })
    .regex(/[a-zA-Z]/, { message: 'Contain at least one letter.' })
    .regex(/[0-9]/, { message: 'Contain at least one number.' })
    .regex(/[^a-zA-Z0-9]/, {
      message: 'Contain at least one special character.',
    })
    .trim(),
})

export type FormState =
  | {
      errors?: {
        name?: string[]
        email?: string[]
        password?: string[]
      }
      message?: string
    }
  | undefined

인증 공급자의 API나 데이터베이스에 불필요한 호출을 방지하기 위해, 정의된 스키마와 일치하지 않는 폼 필드가 있을 경우 서버 액션에서 조기에 반환할 수 있습니다.

app/actions/auth.ts

import { SignupFormSchema, FormState } from '@/app/lib/definitions'

export async function signup(state: FormState, formData: FormData) {
  // Validate form fields
  const validatedFields = SignupFormSchema.safeParse({
    name: formData.get('name'),
    email: formData.get('email'),
    password: formData.get('password'),
  })

  // If any form fields are invalid, return early
  if (!validatedFields.success) {
    return {
      errors: validatedFields.error.flatten().fieldErrors,
    }
  }

  // Call the provider or db to create a user...
}

다시 <SignupForm />으로 돌아가서, React의 useFormState 훅을 사용하여 폼 제출 중에 검증 오류를 표시할 수 있습니다

app/ui/signup-form.tsx

'use client'

import { useFormState, useFormStatus } from 'react-dom'
import { signup } from '@/app/actions/auth'

export function SignupForm() {
  const [state, action] = useFormState(signup, undefined)

  return (
    <form action={action}>
      <div>
        <label htmlFor="name">Name</label>
        <input id="name" name="name" placeholder="Name" />
      </div>
      {state?.errors?.name && <p>{state.errors.name}</p>}

      <div>
        <label htmlFor="email">Email</label>
        <input id="email" name="email" placeholder="Email" />
      </div>
      {state?.errors?.email && <p>{state.errors.email}</p>}

      <div>
        <label htmlFor="password">Password</label>
        <input id="password" name="password" type="password" />
      </div>
      {state?.errors?.password && (
        <div>
          <p>Password must:</p>
          <ul>
            {state.errors.password.map((error) => (
              <li key={error}>- {error}</li>
            ))}
          </ul>
        </div>
      )}
      <SubmitButton />
    </form>
  )
}

function SubmitButton() {
  const { pending } = useFormStatus()

  return (
    <button disabled={pending} type="submit">
      Sign Up
    </button>
  )
}

참고 사항

• 이 예제에서는 Next.js 앱 라우터에 포함된 React의 useFormState 훅을 사용합니다. React 19를 사용 중이라면 useActionState를 대신 사용하세요. 자세한 내용은 React 문서를 참조하세요.

• React 19에서는 useFormStatus가 반환하는 객체에 data, method, action과 같은 추가 키가 포함됩니다. React 19가 아닌 경우에는 pending 키만 사용할 수 있습니다. 또한 React 19에서는 useActionState가 반환된 상태에 pending 키도 포함합니다.

• 데이터를 수정하기 전에 사용자가 해당 작업을 수행할 권한이 있는지도 항상 확인해야 합니다. 자세한 내용은 '인증 및 권한 부여'를 참조하세요.

3. 사용자 생성 또는 사용자 자격 증명 확인 폼 필드를 검증한 후, 인증 공급자의 API나 데이터베이스를 호출하여 새로운 사용자 계정을 생성하거나 사용자가 존재하는지 확인할 수 있습니다.

이전 예제에서 이어서 설명

app/actions/auth.ts

export async function signup(state: FormState, formData: FormData) {
  // 1. Validate form fields
  // ...

  // 2. Prepare data for insertion into database
  const { name, email, password } = validatedFields.data
  // e.g. Hash the user's password before storing it
  const hashedPassword = await bcrypt.hash(password, 10)

  // 3. Insert the user into the database or call an Auth Library's API
  const data = await db
    .insert(users)
    .values({
      name,
      email,
      password: hashedPassword,
    })
    .returning({ id: users.id })

  const user = data[0]

  if (!user) {
    return {
      message: 'An error occurred while creating your account.',
    }
  }

  // TODO:
  // 4. Create user session
  // 5. Redirect user
}

사용자 계정을 성공적으로 생성하거나 자격 증명을 확인한 후, 사용자의 인증 상태를 관리하기 위한 세션을 생성할 수 있습니다. 세션 관리 방식에 따라 세션은 쿠키나 데이터베이스, 또는 두 곳 모두에 저장될 수 있습니다. 더 자세한 내용은 '세션 관리' 섹션에서 확인하세요.

팁

• 위 예제는 교육 목적으로 인증 단계를 상세히 설명하여 다소 장황해 보일 수 있습니다. 이를 통해 안전한 인증 솔루션을 직접 구현하는 과정이 얼마나 복잡해질 수 있는지 강조하고 있으며, 인증 라이브러리를 사용하여 과정을 단순화하는 것도 고려해 보세요.

• 또한 사용자 경험을 개선하기 위해, 회원가입 단계 초기에 중복 이메일이나 사용자 이름을 미리 확인하는 것이 좋습니다. 예를 들어, 사용자가 사용자 이름을 입력하는 중이거나 입력란이 포커스를 잃을 때 확인을 수행할 수 있습니다. 이를 통해 불필요한 폼 제출을 방지하고 즉각적인 피드백을 제공할 수 있습니다. 요청 빈도 관리는 use-debounce와 같은 라이브러리를 사용하여 디바운스 처리로 가능합니다.

세션 관리

세션 관리는 사용자 인증 상태가 여러 요청 간에 유지되도록 보장하는 역할을 합니다. 여기에는 세션이나 토큰을 생성하고, 저장하고, 갱신하고, 삭제하는 과정이 포함됩니다.

세션에는 두 가지 유형이 있습니다.

1. 무상태(Stateless): 세션 데이터(또는 토큰)가 브라우저의 쿠키에 저장됩니다. 이 쿠키는 요청마다 서버로 전송되어 세션을 검증할 수 있도록 합니다. 이 방식은 비교적 간단하지만, 올바르게 구현되지 않으면 보안이 취약할 수 있습니다.

2. 데이터 베이스(Database): 세션 데이터가 데이터베이스에 저장되고, 사용자의 브라우저에는 암호화된 세션 ID만 전달됩니다. 이 방식은 더 안전하지만, 구현이 복잡하고 서버 자원을 더 많이 사용할 수 있습니다.

참고 사항 두 가지 방식 중 하나 또는 둘 다 사용할 수 있지만, iron-session이나 Jose와 같은 세션 관리 라이브러리를 사용하는 것을 권장합니다.

무상태(Stateless) 세션

무상태 세션을 생성하고 관리하려면 다음 단계들을 따라야 합니다.

1. 세션 서명에 사용할 비밀 키를 생성하고, 환경 변수로 저장합니다.

2. 세션 관리 라이브러리를 사용해 세션 데이터를 암호화/복호화하는 로직을 작성합니다.

3. Next.js의 쿠키 API를 사용하여 쿠키를 관리합니다.

위 내용에 더해, 사용자가 애플리케이션으로 돌아올 때 세션을 갱신하는 기능과, 로그아웃 시 세션을 삭제하는 기능도 추가하는 것을 고려해 보세요.

참고사항 인증 라이브러리에 세션 관리가 포함되어 있는지 확인하세요.

1. 비밀 키 생성

   비밀 키 생성 세션을 서명하기 위해 비밀 키를 생성하는 방법에는 여러 가지가 있습니다. 예를 들어, 터미널에서 openssl 명령어를 사용하여 생성할 수 있습니다

** openssl rand -base64 32**

이 명령어는 32자 길이의 랜덤 문자열을 생성하며, 이를 비밀 키로 사용하고 환경 변수 파일에 저장할 수 있습니다.

.env

SESSION_SECRET=your_secret_key``

그런 다음 세션 관리 로직에서 이 키를 참조할 수 있습니다. app/lib/session.js

const secretKey = process.env.SESSION_SECRET

2. 세션 암호화 및 복호화

   다음으로, 선호하는 세션 관리 라이브러리를 사용하여 세션을 암호화하고 복호화할 수 있습니다. 이전 예제에서 이어서, Edge Runtime과 호환되는 Jose와 React의 서버 전용 패키지를 사용하여 세션 관리 로직이 서버에서만 실행되도록 합니다."

** app/lib/session.ts**

import 'server-only'
import { SignJWT, jwtVerify } from 'jose'
import { SessionPayload } from '@/app/lib/definitions'

const secretKey = process.env.SESSION_SECRET
const encodedKey = new TextEncoder().encode(secretKey)

export async function encrypt(payload: SessionPayload) {
  return new SignJWT(payload)
    .setProtectedHeader({ alg: 'HS256' })
    .setIssuedAt()
    .setExpirationTime('7d')
    .sign(encodedKey)
}

export async function decrypt(session: string | undefined = '') {
  try {
    const { payload } = await jwtVerify(session, encodedKey, {
      algorithms: ['HS256'],
    })
    return payload
  } catch (error) {
    console.log('Failed to verify session')
  }
}

팁 페이로드에는 이후 요청에서 사용될 최소한의 고유 사용자 데이터, 예를 들어 사용자 ID, 역할 등을 포함해야 합니다. 개인 식별 정보(전화번호, 이메일 주소, 신용카드 정보 등)나 비밀번호와 같은 민감한 데이터는 포함해서는 안 됩니다.

3. 쿠키 설정(권장 옵션)

   세션을 쿠키에 저장하려면 Next.js의 쿠키 API를 사용합니다. 쿠키는 서버에서 설정해야 하며, 다음과 같은 권장 옵션을 포함해야 합니다.

• HttpOnly: 클라이언트 측 JavaScript가 쿠키에 접근하는 것을 방지합니다.

• Secure: 쿠키를 전송할 때 HTTPS를 사용합니다.

• SameSite: 쿠키가 교차 사이트 요청과 함께 전송될 수 있는지를 지정합니다.

• ** Max-Age 또는 Expires**: 일정 기간 후 쿠키를 삭제합니다.

• Path: 쿠키의 URL 경로를 정의합니다."

각 옵션에 대한 자세한 내용은 MDN을 참조하세요.

app/lib/session.ts

import 'server-only'
import { cookies } from 'next/headers'

export async function createSession(userId: string) {
  const expiresAt = new Date(Date.now() + 7 * 24 * 60 * 60 * 1000)

   // 2. Encrypt the session ID
  const session = await encrypt({ userId, expiresAt })

  // 3. Store the session in cookies for optimistic auth checks
  const cookieStore = await cookies()
  cookieStore().set('session', session, {
    httpOnly: true,
    secure: true,
    expires: expiresAt,
    sameSite: 'lax',
    path: '/',
  })
}

서버 액션에서 createSession() 함수를 호출하고, redirect() API를 사용하여 사용자를 적절한 페이지로 리디렉션할 수 있습니다.

app/actions/auth.ts

import { createSession } from '@/app/lib/session'

export async function signup(state: FormState, formData: FormData) {
  // Previous steps:
  // 1. Validate form fields
  // 2. Prepare data for insertion into database
  // 3. Insert the user into the database or call an Library API

  // Current steps:
  // 4. Create user session
  await createSession(user.id)
  // 5. Redirect user
  redirect('/profile')
}

팁

• 쿠키는 클라이언트 측의 변조를 방지하기 위해 서버에서 설정해야 합니다.
• 🎥 시청하기: Next.js로 무상태 세션 및 인증에 대해 더 알아보기 → YouTube

세션 업데이트(또는 갱신)

세션의 만료 시간을 연장할 수도 있습니다. 이는 사용자가 애플리케이션에 다시 접근했을 때 로그인이 유지되도록 하는 데 유용합니다.

app/lib/session.ts

import 'server-only'
import { cookies } from 'next/headers'
import { decrypt } from '@/app/lib/session'

export async function updateSession() {
  const session = (await cookies()).get('session')?.value
  const payload = await decrypt(session)

  if (!session || !payload) {
    return null
  }

  const expires = new Date(Date.now() + 7 * 24 * 60 * 60 * 1000)

  const cookieStore = await cookies()
  cookieStore().set('session', session, {
    httpOnly: true,
    secure: true,
    expires: expires,
    sameSite: 'lax',
    path: '/',
  })
}

팁: 사용자 세션을 확장하는 데 사용할 수 있는 새로 고침(refresh) 토큰 인증 라이브러리가 지원하는지 확인하세요.

세션 삭제

세션을 삭제하려면 쿠키를 삭제하세요.

app/lib/session.ts

import 'server-only'
import { cookies } from 'next/headers'

export async function deleteSession() {
  const cookieStore = await cookies()
  cookieStore().delete('session')
}

그런 다음 애플리케이션에서 deleteSession() 함수를 재사용할 수 있습니다(예: 로그아웃 시)

app/actions/auth.ts

import { cookies } from 'next/headers'
import { deleteSession } from '@/app/lib/session'

export async function logout() {
  deleteSession()
  redirect('/login')
}

데이터베이스 세션

데이터베이스 세션을 생성하고 관리하려면 다음 단계를 따라야 합니다.

1. 세션 데이터를 저장할 데이터베이스에 테이블을 생성합니다(또는 인증 라이브러리가 이를 처리하는지 확인합니다).

2. 세션을 삽입, 업데이트 및 삭제하는 기능을 구현합니다.

3. 세션 ID를 사용자의 브라우저에 저장하기 전에 암호화하고, 데이터베이스와 쿠키가 동기화되도록 합니다(선택 사항이지만 미들웨어에서 낙관적인 인증 검사를 위해 권장됨)."

예시

app/lib/session.ts

import cookies from 'next/headers'
import { db } from '@/app/lib/db'
import { encrypt } from '@/app/lib/session'

export async function createSession(id: number) {
  const expiresAt = new Date(Date.now() + 7 * 24 * 60 * 60 * 1000)

  // 1. Create a session in the database
  const data = await db
    .insert(sessions)
    .values({
      userId: id,
      expiresAt,
    })
    // Return the session ID
    .returning({ id: sessions.id })

  const sessionId = data[0].id

  // 2. Encrypt the session ID
  const session = await encrypt({ sessionId, expiresAt })

  // 3. Store the session in cookies for optimistic auth checks
  const cookieStore = await cookies()
  cookieStore().set('session', session, {
    httpOnly: true,
    secure: true,
    expires: expiresAt,
    sameSite: 'lax',
    path: '/',
  })
}

팁

• 빠른 데이터 검색을 위해 Vercel Redis와 같은 데이터베이스를 사용하는 것을 고려해 보세요. 하지만 기본 데이터베이스에 세션 데이터를 유지하고 데이터 요청을 결합하여 쿼리 수를 줄이는 방법도 가능합니다.
• 더 고급 사용 사례를 위해 데이터베이스 세션을 사용할 수 있습니다. 예를 들어 사용자가 마지막으로 로그인한 시간, 활성 장치 수를 추적하거나 사용자가 모든 장치에서 로그아웃할 수 있는 기능을 제공하는 등의 용도로 활용할 수 있습니다.

세션 관리 구현 후, 사용자가 애플리케이션 내에서 접근할 수 있는 것과 수행할 수 있는 작업을 제어하기 위해 권한 부여 로직을 추가해야 합니다. 권한 부여 섹션으로 이동하여 더 자세히 알아보세요.

권한 부여(Authorization)

사용자가 인증되고 세션이 생성되면, 애플리케이션 내에서 사용자가 접근하고 수행할 수 있는 권한을 제어하기 위해 권한 부여(authorization)를 구현할 수 있습니다.

주요 권한 부여 확인 유형은 두 가지입니다:

1. 낙관적(Optimistic): 사용자가 쿠키에 저장된 세션 데이터를 사용하여 특정 경로에 접근하거나 행동을 수행할 수 있는 권한이 있는지 확인하는 방법입니다. 이러한 확인은 UI 요소를 보여주거나 숨기거나, 권한이나 역할에 따라 사용자를 리디렉션하는 등의 빠른 작업에 유용합니다.

2. 안전(Secure): 사용자가 데이터베이스에 저장된 세션 데이터를 사용하여 특정 경로에 접근하거나 행동을 수행할 수 있는 권한이 있는지 확인하는 방법입니다. 이러한 체크는 더 안전하며, 민감한 데이터에 접근하거나 특정 작업을 수행해야 하는 경우에 사용됩니다.

두 경우 모두 다음을 권장합니다.

• 권한 부여 로직을 중앙 집중화하기 위한 데이터 접근 계층(Data Access Layer) 생성

• 필요한 데이터만 반환하기 위한 데이터 전송 객체(Data Transfer Objects, DTO) 사용

• 옵션으로 미들웨어를 사용하여 낙관적인 체크 수행

미들웨어를 통한 낙관적인 체크 (선택 사항)

미들웨어를 사용하여 사용자의 권한에 따라 리다이렉트하는 경우가 있습니다. 여기 몇 가지 상황이 있습니다:

• 낙관적인 체크 수행: 미들웨어는 모든 경로에서 실행되므로, 리다이렉트 로직을 중앙 집중화하고 인가되지 않은 사용자를 미리 필터링하는 좋은 방법입니다.

• 사용자 간 데이터 공유가 있는 정적 경로 보호: 예를 들어, 유료 콘텐츠 뒤에 숨겨진 데이터와 같은 경우에 해당합니다.

그러나 미들웨어는 모든 경로에서 실행되기 때문에, 미리 가져온 경로를 포함하여 성능 문제를 방지하기 위해 데이터베이스 체크는 피하고 세션을 쿠키에서만 읽는 것이 중요합니다.

예시

middleware.ts

import { NextRequest, NextResponse } from 'next/server'
import { decrypt } from '@/app/lib/session'
import { cookies } from 'next/headers'

// 1. Specify protected and public routes
const protectedRoutes = ['/dashboard']
const publicRoutes = ['/login', '/signup', '/']

export default async function middleware(req: NextRequest) {
  // 2. Check if the current route is protected or public
  const path = req.nextUrl.pathname
  const isProtectedRoute = protectedRoutes.includes(path)
  const isPublicRoute = publicRoutes.includes(path)

  // 3. Decrypt the session from the cookie
  const cookie = (await cookies()).get('session')?.value
  const session = await decrypt(cookie)

  // 4. Redirect to /login if the user is not authenticated
  if (isProtectedRoute && !session?.userId) {
    return NextResponse.redirect(new URL('/login', req.nextUrl))
  }

  // 5. Redirect to /dashboard if the user is authenticated
  if (
    isPublicRoute &&
    session?.userId &&
    !req.nextUrl.pathname.startsWith('/dashboard')
  ) {
    return NextResponse.redirect(new URL('/dashboard', req.nextUrl))
  }

  return NextResponse.next()
}

// Routes Middleware should not run on
export const config = {
  matcher: ['/((?!api|_next/static|_next/image|.*\\.png$).*)'],
}

미들웨어는 초기 체크에 유용할 수 있지만, 데이터를 보호하는 데 있어 유일한 방어선이 되어서는 안 됩니다. 보안 검사는 데이터 소스에 최대한 가깝게 수행해야 하며, 더 많은 정보는 데이터 접근 계층(Data Access Layer)을 참조하세요.

팁:

• 미들웨어에서는 req.cookies.get('session').value를 사용하여 쿠키를 읽을 수 있습니다.

• 미들웨어는 엣지 런타임(Edge Runtime)을 사용하므로, 인증(auth) 라이브러리와 세션 관리 라이브러리가 호환되는지 확인하세요.

• 미들웨어의 matcher 속성을 사용하여 미들웨어가 실행될 경로를 지정할 수 있습니다. 하지만 인증(auth)의 경우, 모든 경로에서 미들웨어가 실행되는 것이 권장됩니다.

데이터 액세스 계층(DAL) 생성

데이터 요청과 인증 로직을 중앙에서 관리할 수 있도록 DAL(Data Access Layer)을 생성하는 것이 좋습니다.

DAL에는 사용자가 애플리케이션과 상호작용할 때 세션을 확인하는 기능이 포함되어야 합니다. 최소한 이 기능은 세션의 유효성을 검사하고, 이후 요청을 처리할 때 필요한 사용자 정보를 반환하거나 리다이렉트 하는 역할을 해야 합니다.

예를 들어, verifySession() 함수를 포함한 별도의 파일을 만들어 DAL을 구성할 수 있습니다. 그런 다음 React의 cache API를 사용하여 React 렌더링 동안 해당 함수의 반환 값을 메모이제이션하여 성능을 최적화할 수 있습니다.

app/lib/dal.ts

import 'server-only'

import { cookies } from 'next/headers'
import { decrypt } from '@/app/lib/session'

export const verifySession = cache(async () => {
  const cookie = (await cookies()).get('session')?.value
  const session = await decrypt(cookie)

  if (!session?.userId) {
    redirect('/login')
  }

  return { isAuth: true, userId: session.userId }
})

그런 다음 데이터 요청, 서버 작업(Server Actions), 경로 핸들러(Route Handlers)에서 verifySession() 함수를 호출할 수 있습니다.

app/lib/dal.ts

export const getUser = cache(async () => {
  const session = await verifySession()
  if (!session) return null

  try {
    const data = await db.query.users.findMany({
      where: eq(users.id, session.userId),
      // Explicitly return the columns you need rather than the whole user object
      columns: {
        id: true,
        name: true,
        email: true,
      },
    })

    const user = data[0]

    return user
  } catch (error) {
    console.log('Failed to fetch user')
    return null
  }
})

팁:

• DAL(Data Access Layer)은 요청 시점에 데이터를 보호하는 데 사용할 수 있습니다. 하지만 사용자가 공유하는 정적 라우트의 경우, 데이터는 요청 시점이 아닌 빌드 시점에 가져옵니다. 정적 라우트를 보호하려면 미들웨어를 사용하세요.

• 안전한 검사를 위해, 세션 ID를 데이터베이스와 비교하여 세션이 유효한지 확인할 수 있습니다. React의 캐시 함수(cache function)를 사용하여 렌더링 중 중복된 데이터베이스 요청을 방지하세요.

• 관련된 데이터 요청을 JavaScript 클래스에 통합하고, 메서드 호출 전에 verifySession()을 실행하도록 설정하는 것도 좋은 방법입니다.

데이터 전송 개체(DTO) 사용

데이터를 가져올 때, 애플리케이션에서 실제로 사용하는 필요한 데이터만 반환하는 것이 좋습니다. 예를 들어, 사용자 데이터를 가져올 때 비밀번호, 전화번호 등 전체 사용자 객체가 아니라 사용자 ID와 이름 같은 필요한 정보만 반환하는 것이 좋습니다.

하지만 반환되는 데이터 구조를 제어할 수 없거나, 팀 작업 중 전체 객체가 클라이언트에 전달되지 않도록 하고 싶을 때는 클라이언트에 노출해도 안전한 필드를 지정하는 전략을 사용할 수 있습니다.

app/lib/dto.ts

import 'server-only'
import { getUser } from '@/app/lib/dal'

function canSeeUsername(viewer: User) {
  return true
}

function canSeePhoneNumber(viewer: User, team: string) {
  return viewer.isAdmin || team === viewer.team
}

export async function getProfileDTO(slug: string) {
  const data = await db.query.users.findMany({
    where: eq(users.slug, slug),
    // Return specific columns here
  })
  const user = data[0]

  const currentUser = await getUser(user.id)

  // Or return only what's specific to the query here
  return {
    username: canSeeUsername(currentUser) ? user.username : null,
    phonenumber: canSeePhoneNumber(currentUser, user.team)
      ? user.phonenumber
      : null,
  }
}

데이터 요청과 인증 로직을 데이터 접근 계층(DAL)에 중앙 집중화하고 DTO(Data Transfer Object)를 사용하면, 모든 데이터 요청의 보안과 일관성을 보장할 수 있습니다. 이를 통해 애플리케이션이 확장되더라도 유지보수, 감사, 디버깅이 쉬워집니다.

참고사항

• DTO(Data Transfer Object)를 정의하는 방법에는 toJSON() 메서드를 사용하는 것부터 개별 함수, JS 클래스를 사용하는 것까지 다양한 방식이 있습니다. 이는 JavaScript 패턴이지 React나 Next.js의 기능이 아니므로, 애플리케이션에 가장 적합한 패턴을 찾기 위해 연구해 보는 것이 좋습니다.

• Next.js 보안 모범 사례에 대해 더 알고 싶다면, 우리의 "Next.js 보안" 기사에서 자세히 알아보세요.

서버 컴포넌트

서버 컴포넌트에서의 인증 검사는 역할 기반 접근 제어에 유용합니다. 예를 들어, 사용자의 역할에 따라 조건부로 컴포넌트를 렌더링할 수 있습니다:

app/dashboard/page.tsx

import { verifySession } from '@/app/lib/dal'

export default function Dashboard() {
  const session = await verifySession()
  const userRole = session?.user?.role // Assuming 'role' is part of the session object

  if (userRole === 'admin') {
    return <AdminDashboard />
  } else if (userRole === 'user') {
    return <UserDashboard />
  } else {
    redirect('/login')
  }
}

예시에서는 DAL에서 제공하는 verifySession() 함수를 사용하여 'admin', 'user', 및 권한 없는 역할을 확인합니다. 이 패턴은 각 사용자가 자신의 역할에 적합한 컴포넌트와만 상호작용하도록 보장합니다.

레이아웃 및 인증 확인

부분 렌더링(Partial Rendering) 때문에 레이아웃에서 체크를 수행할 때 주의해야 합니다. 레이아웃은 내비게이션 시 다시 렌더링되지 않으므로, 사용자의 세션이 모든 경로 변경 시마다 체크되지 않습니다.

대신, 데이터 자원이나 조건부로 렌더링될 컴포넌트에 가까운 곳에서 체크를 수행해야 합니다.

예를 들어, 사용자 데이터를 가져와서 내비게이션에 사용자 이미지를 표시하는 공유 레이아웃을 고려해 보세요. 인증 검사를 레이아웃에서 수행하는 대신, 레이아웃에서 사용자 데이터를 가져오는 getUser()를 호출하고, 인증 체크는 DAL에서 수행해야 합니다.

이렇게 하면 애플리케이션 내에서 getUser()가 호출되는 모든 위치에서 인증 검사가 수행되므로, 개발자가 사용자가 데이터에 접근할 권한이 있는지 확인하는 것을 잊는 것을 방지할 수 있습니다.

app/layout.tsx

export default async function Layout({
  children,
}: {
  children: React.ReactNode;
}) {
  const user = await getUser();

  return (
    // ...
  )
}

app/lib/dal.ts

export const getUser = cache(async () => {
  const session = await verifySession()
  if (!session) return null

  // Get user ID from session and fetch data
})

참고사항

• 단일 페이지 애플리케이션(SPA)에서 일반적으로 사용되는 패턴은 사용자가 인증되지 않은 경우 레이아웃이나 최상위 컴포넌트에서 null을 반환하는 것입니다. 하지만 이 패턴은 권장되지 않습니다. Next.js 애플리케이션은 여러 진입점을 가지므로, 중첩된 경로 세그먼트나 서버 액세스(Server Actions)에 대한 접근을 차단하지 못합니다.

서버 액션(Server Actions)

서버 액션을 공개 API 엔드포인트와 동일한 보안 고려 사항으로 취급하고, 사용자가 변형(mutation)을 수행할 수 있는 권한이 있는지 확인해야 합니다.

app/lib/actions.ts

'use server'
import { verifySession } from '@/app/lib/dal'

export async function serverAction(formData: FormData) {
  const session = await verifySession()
  const userRole = session?.user?.role

  // Return early if user is not authorized to perform the action
  if (userRole !== 'admin') {
    return null
  }

  // Proceed with the action for authorized users
}

라우트 핸들러

라우트 핸들러를 공개 API 엔드포인트와 동일한 보안 고려 사항으로 취급하고, 사용자가 해당 라우트 핸들러에 접근할 수 있는 권한이 있는지 확인해야 합니다.

예시

app/api/route.ts

import { verifySession } from '@/app/lib/dal'

export async function GET() {
  // User authentication and role verification
  const session = await verifySession()

  // Check if the user is authenticated
  if (!session) {
    // User is not authenticated
    return new Response(null, { status: 401 })
  }

  // Check if the user has the 'admin' role
  if (session.user.role !== 'admin') {
    // User is authenticated but does not have the right permissions
    return new Response(null, { status: 403 })
  }

  // Continue for authorized users
}

위의 예시는 두 단계의 보안 검사를 포함한 라우트 핸들러를 보여줍니다. 먼저 활성 세션이 있는지 확인한 후, 로그인한 사용자가 'admin'인지 검증합니다.

Context Providers

인증을 위한 컨텍스트 제공자(context providers)를 사용하는 것은 중첩 구조(interleaving) 덕분에 효과적입니다. 하지만 React 컨텍스트는 서버 컴포넌트(Server Components)에서 지원되지 않기 때문에 클라이언트 컴포넌트(Client Components)에만 적용 가능합니다.

이러한 방식은 동작하지만, 모든 자식 서버 컴포넌트는 먼저 서버에서 렌더링되며, 이 경우 컨텍스트 제공자의 세션 데이터에 접근할 수 없습니다.

app/layout.ts

import { ContextProvider } from 'auth-lib'

export default function RootLayout({ children }) {
  return (
    <html lang="en">
      <body>
        <ContextProvider>{children}</ContextProvider>
      </body>
    </html>
  )
}

"use client";

import { useSession } from "auth-lib";

export default function Profile() {
  const { userId } = useSession();
  const { data } = useSWR(`/api/user/${userId}`, fetcher)

  return (
    // ...
  );
}

클라이언트 컴포넌트에서 세션 데이터가 필요한 경우(예: 클라이언트 측 데이터 페칭을 위한 경우), React의 taintUniqueValue API를 사용하여 민감한 세션 데이터가 클라이언트에 노출되는 것을 방지해야 합니다.

Next.js 공식 문서

초기에 SSR(Server-Side Rendering)로 데이터를 10개 받아와 이를 초기 데이터(initialData)로 전달한 후, useInfiniteQuery를 이용해 데이터를 불러오고 있었다. 하지만 staleTime 속성을 설정한 후, 필터 값을 변경할 때마다 필터 값은 정상적으로 변하지만 데이터 목록은 전혀 변하지 않는 문제가 발생했다.

아래를 보면 변화가 없는 것을 알 수 있다. 그렇다면 왜 stateTime을 설정하면 이런 일이 발생할까 생각을 해보니 초기에 오는 데이터와 일치한다는 점에서 initialData 속성에 대해 뭔가 잘못 알고있는 부분이 있다고 생각했다.

아래의 예시를 보면 필터를 변경해도 데이터가 변하지 않는 상황을 확인할 수 있다.

문제가 발생한 이유는 staleTime이 설정된 상태에서 필터 값을 변경해도 초기에 받아온 initialData가 계속 사용되기 때문이었다. 필터 타입도 쿼리 키의 일부분으로 사용하고 있었으나, 쿼리 키가 변경되어도 여전히 같은 initialData가 적용되는 문제로 인해 데이터가 업데이트되지 않았던 것이다.

처음에는 initialData가 말 그대로 초기 데이터로만 사용된다고 생각했으나, 쿼리 키가 변경되더라도 계속해서 동일한 데이터를 참조하고 있었던 것이 문제였다.

해결 방법

이 문제를 해결하기 위해서는 최초 쿼리 키와 일치할 때만 initialData를 사용하도록 설정하는 것이 중요하다.

아래 코드를 통해 해결 과정을 설명하겠다.

1. 먼저, 초기 쿼리 키를 상수로 저장한다.

2. 현재 쿼리 키가 초기 쿼리 키와 일치하는지 여부를 확인합니다.

3. 쿼리 키가 최초 쿼리 키와 같을 경우에만 initialData에 초기 데이터를 전달한다. 그 외의 경우에는 새로운 데이터를 캐싱하고, 이를 기반으로 데이터가 업데이트된다.

const INITIAL_QUERY_KEY = 최초 쿼리 키 값

const isInitialQuery = 현재 쿼리 키 값 === INITIAL_QUERY_KEY

  initialData: isInitialQuery
      ? {
          pages: [gatherings],
          pageParams: [0],
        }
      : undefined,

이렇게 설정하면 초기 쿼리 키와 일치하는 경우에만 initialData가 사용되며, 필터를 변경할 때마다 정상적으로 새로운 데이터를 요청하고 캐싱하여 필터링 기능이 올바르게 작동하는 것을 확인할 수 있다.

사용자가 찜한 모임 목록을 서버에서 불러오는 기능을 구현 중이었다. 처음에는 'hydrated' 상태가 완료되지 않았을 때 로딩 메시지가 한 번 나타나고, 그 뒤로도 'isLoading' 상태에서 또 다른 로딩 메시지가 나타나는 문제가 있었다. 이러한 중복 로딩 표시가 사용자 경험을 저해할 수 있어 해결책을 찾고자 했다.

Zustand로 찜 목록을 관리하는 중, hydration 문제를 해결하기 위해 hydrated 값을 사용하여, 아직 hydration이 완료되지 않았을 때는 사용자에게 대체 메시지를 보여주는 방식을 구현했다.

그런데 아래 html 요소와 속성을 같게 줘도 글자가 위아래로 움직이는 화면이 나타났다. 그리고 아래와 같은 방법은 실제로 구현하면서도 이 방법은 아니것이라고 확신이 들었다.

처음에는 다음과 같은 코드를 사용했다.

if (!hydrated) {
  return (
    <div className="flex items-center justify-center h-full min-h-500pxr">
      <p className="h-10 text-sm font-medium text-center text-gray-500">찜 목록 확인 중...</p>
    </div>
  );
}
let content;

if (isLoading) {
  content = (
    <div className="flex items-center justify-center h-full min-h-500pxr">
      <p className="h-10 text-sm font-medium text-center text-gray-500">데이터 불러오는 중...</p>
    </div>
  );
}

하지만 hydrated가 false일 때와 isLoading 상태에서 두 개의 유사한 메시지를 보여주는 동안, 페이지에서 글자가 약간의 차이로 위아래로 움직이는 현상이 발생했다. HTML 구조와 속성은 같았지만, 이러한 화면 변화로 인해 사용자 경험이 떨어진다는 것을 느꼈다. 그리고 이 방법이 최선이 아니라는 확신이 들었다.

따라서 이 문제를 해결하기 위해, 두 상태(hydration과 isLoading)를 통합하여 메시지를 일관되게 유지하고 불필요한 화면 움직임을 방지하는 방식으로 개선할 필요가 있었다.

수정 전

해결 방법

그리고 실제 목록들은 useQuery를 이용하여 데이터를 요청해서 가져오고 있다.

먼저, react-query에서 enabled 옵션을 사용해 hydrated 상태가 완료될 때까지 쿼리가 실행되지 않도록 제어했다. 또한, hydrated가 완료되지 않았을 때와 isLoading 상태를 구분해 로딩 메시지를 한 번만 표시하도록 코드를 수정했다.

useQuery({
  queryKey,
  queryFn: async () => {
    // ...
  },
  enabled: hydrated,  // hydrated가 true일 때만 쿼리 실행
});

  if (!hydrated || isLoading) {
    return (
      <div className="flex items-center justify-center h-full min-h-500pxr">
        <p className="h-10 text-sm font-medium text-center text-gray-500">찜 목록 확인 중...</p>
      </div>
    );
  }

수정 후

이렇게 코드를 수정한 후, 처음 hydration이 완료되지 않았을 때만 로딩 메시지가 표시되고, 데이터를 불러올 때는 중복된 로딩 메시지가 사라지게 되었다. 결과적으로 사용자 경험이 개선되었다.

이 방법은 다른 비동기 데이터 로딩 상황에서도 쿼리 실행 조건을 제어할 때 유용하다고 생각한다.

Uncontrolled Component는** DOM에서 직접 데이터를 제어하는 방식**으로 작동한다. React에서는 ref를 사용하여 DOM 요소에 직접 접근할 수 있는데, 이 방식이 바로 Uncontrolled Component의 특징이다.

예시 코드

import { useRef } from 'react';

const UncontrolledComponent = () => {
  const inputRef = useRef(null); // useRef를 통해 input에 직접 접근

  const handleSubmit = e => {
    e.preventDefault();
    console.log(inputRef.current.value); // DOM을 통해 값에 접근
  };

  return (
    <form>
      <input type='text' placeholder='uncontrolled' ref={inputRef} /> 
      <button onClick={handleSubmit}>Submit</button>
    </form>
  );
};

export default UncontrolledComponent;

주요 특징

• ref를 통해 DOM 요소에 접근하여 값을 가져옴

• 컴포넌트 내부의 state가 아닌 DOM에서 관리되는 값을 사용하는 방식

• 양식 유효성 검사를 하려면 값을 읽은 후 추가적인 검사를 해야 하며, 값이 유효하지 않을 가능성이 존재

• 상태가 예측 불가능할 수 있으며, 컴포넌트가 DOM의 참조를 잃을 경우 데이터 제어가 어려워질 수 있음

Controlled Component

Controlled Component는 React의 state를 통해 데이터를 제어하는 방식이다. 즉, 입력 값이 React 컴포넌트의 상태에 의해 관리된다.

예시코드

import { useState } from 'react';

const ControlledComponent = () => {
  const [inputText, setInputText] = useState(''); // state를 사용하여 값 관리

  const handleSubmit = e => {
    e.preventDefault();
    console.log(inputText); // state에 저장된 값 출력
  };

  return (
    <form>
      <input
        type='text'
        placeholder='controlled'
        value={inputText} // 상태가 값으로 관리됨
        onChange={e => setInputText(e.target.value)} // 입력에 따라 state 업데이트
      />
      <button onClick={handleSubmit}>Submit</button>
    </form>
  );
};

export default ControlledComponent;

주요 특징

• state를 통해 폼 필드 값을 제어

• 컴포넌트 내부의 state가 아닌 DOM에서 관리되는 값을 사용하는 방식

• 입력 값이 state에 저장되고, 입력 값의 변동은 onChange 이벤트를 통해 관리

• 상태가 예측 불가능할 수 있으며, 컴포넌트가 DOM의 참조를 잃을 경우 데이터 제어가 어려워질 수 있음

• React의 컴포넌트 수명 주기와 상태가 잘 연동되어 있으며, 폼 요소와 데이터 제어가 매우 일관됨

Controlled Component와 Uncontrolled Component의 차이점

스스로 질문

질문 1: Controlled Component와 Uncontrolled Component의 차이점은 무엇인가요?

Controlled Component는 상태(state)를 통해 입력 필드의 값을 제어하는 반면, Uncontrolled Component는 DOM 요소에서 직접 값을 가져온다. Controlled Component는 onChange 이벤트를 사용해 입력 값을 실시간으로 업데이트하며, 양식 유효성 검사가 용이합니다. 반면 Uncontrolled Component는 ref를 사용해 DOM에 접근하여 데이터를 읽어오며, 유효성 검사를 위해 추가적인 작업이 필요하다.

질문 2: Controlled Component와 Uncontrolled Component 중 어느 것이 더 좋은가요?

상황에 따라 다르다. 일반적으로** Controlled Component가 더 권장된다. 상태를 통해 값이 관리되기 때문에 예측 가능하며, 실시간 유효성 검사와 데이터 관리를 용이하게 할 수 있다. 그러나 간단한 폼이나 DOM 직접 접근이 필요한 경우에는 **Uncontrolled Component를 사용할 수 있다.

오픈채팅방

카카오톡 오픈채팅방에서는 친구가 아닌 사람들과 대화를 할 수 있는데, 본래 닉네임이 아닌 가상의 닉네임을 사용하여 채팅방에 들어갈 수 있다.

신입사원인 김크루는 카카오톡 오픈 채팅방을 개설한 사람을 위해, 다양한 사람들이 들어오고, 나가는 것을 지켜볼 수 있는 관리자창을 만들기로 했다. 채팅방에 누군가 들어오면 다음 메시지가 출력된다.

"[닉네임]님이 들어왔습니다."

채팅방에서 누군가 나가면 다음 메시지가 출력된다.

"[닉네임]님이 나갔습니다."

채팅방에서 닉네임을 변경하는 방법은 다음과 같이 두 가지이다.

• 채팅방을 나간 후, 새로운 닉네임으로 다시 들어간다.

• 채팅방에서 닉네임을 변경한다. 닉네임을 변경할 때는 기존에 채팅방에 출력되어 있던 메시지의 닉네임도 전부 변경된다.

예를 들어, 채팅방에 "Muzi"와 "Prodo"라는 닉네임을 사용하는 사람이 순서대로 들어오면 채팅방에는 다음과 같이 메시지가 출력된다.

"Muzi님이 들어왔습니다." "Prodo님이 들어왔습니다."

채팅방에 있던 사람이 나가면 채팅방에는 다음과 같이 메시지가 남는다.

"Muzi님이 들어왔습니다." "Prodo님이 들어왔습니다." "Muzi님이 나갔습니다."

Muzi가 나간후 다시 들어올 때, Prodo 라는 닉네임으로 들어올 경우 기존에 채팅방에 남아있던 Muzi도 Prodo로 다음과 같이 변경된다.

"Prodo님이 들어왔습니다." "Prodo님이 들어왔습니다." "Prodo님이 나갔습니다." "Prodo님이 들어왔습니다."

채팅방은 중복 닉네임을 허용하기 때문에, 현재 채팅방에는 Prodo라는 닉네임을 사용하는 사람이 두 명이 있다. 이제, 채팅방에 두 번째로 들어왔던 Prodo가 Ryan으로 닉네임을 변경하면 채팅방 메시지는 다음과 같이 변경된다.

"Prodo님이 들어왔습니다." "Ryan님이 들어왔습니다." "Prodo님이 나갔습니다." "Prodo님이 들어왔습니다."

채팅방에 들어오고 나가거나, 닉네임을 변경한 기록이 담긴 문자열 배열 record가 매개변수로 주어질 때, 모든 기록이 처리된 후, 최종적으로 방을 개설한 사람이 보게 되는 메시지를 문자열 배열 형태로 return 하도록 solution 함수를 완성하라.

제한사항

• record는 다음과 같은 문자열이 담긴 배열이며, 길이는 1 이상 100,000 이하이다.

• 다음은 record에 담긴 문자열에 대한 설명이다.

  • 모든 유저는 [유저 아이디]로 구분한다.
  • [유저 아이디] 사용자가 [닉네임]으로 채팅방에 입장 - "Enter [유저 아이디] [닉네임]" (ex. "Enter uid1234 Muzi")
  • [유저 아이디] 사용자가 채팅방에서 퇴장 - "Leave [유저 아이디]" (ex. "Leave uid1234")
  • [유저 아이디] 사용자가 닉네임을 [닉네임]으로 변경 - "Change [유저 아이디] [닉네임]" (ex. "Change uid1234 Muzi")
  • 첫 단어는 Enter, Leave, Change 중 하나이다.
  • 각 단어는 공백으로 구분되어 있으며, 알파벳 대문자, 소문자, 숫자로만 이루어져있다.
  • 유저 아이디와 닉네임은 알파벳 대문자, 소문자를 구별한다.
  • 유저 아이디와 닉네임의 길이는 1 이상 10 이하이다.
  • 채팅방에서 나간 유저가 닉네임을 변경하는 등 잘못 된 입력은 주어지지 않는다.

입출력 예

정답코드

function solution(record) {
  const answer = [];
  const person = {};

   for (let i = 0; i < record.length; i++) {
    const [action, userId, username] = record[i].split(" ");

    if (action === "Enter" || action === "Change") {
      person[userId] = username;
    }
  }

   for (let i = 0; i < record.length; i++) {
    const [action, userId, username] = record[i].split(" ");

    if (action === "Enter") {
      answer.push(`${person[userId]}님이 들어왔습니다.`);
    } else if (action === "Leave") {
      answer.push(`${person[userId]}님이 나갔습니다.`);
    }

  }
  return answer;
}

코드설명

이 코드의 핵심 아이디어는 유저의 아이디는 변하지 않지만, 닉네임은 변경될 수 있다는 점을 활용하는 것이다. 따라서, 유저의 행동을 처리하면서 아이디를 키로 하고, 최신 닉네임을 값으로 하는 객체를 유지하여 최종 닉네임을 기록한다.

1. 첫 번째 for문에서는 Enter(입장) 또는 Change(닉네임 변경) 동작이 있을 때만, 해당 유저의 아이디를 person 객체에 저장하거나 업데이트한다. Leave(퇴장) 행동은 닉네임과 무관하므로 고려할 필요가 없다.

2. 두 번째 for문에서는 각 기록을 다시 순회하면서, 최종적으로 저장된 유저의 닉네임을 기반으로 입장(Enter) 또는 퇴장(Leave) 메시지를 생성하여 answer 배열에 추가한다. Change는 유저의 닉네임을 업데이트하는 데 사용될뿐이므로 고려하지 않는다.

위와 같은 과정을 거쳐서 최종적으로 방에서 보게 되는 입장/퇴장 메시지 목록이 반환된다.

Cypress로 E2E(End-to-end) 테스트를 시작하기 위해 Cypress를 설치한 후, 기본 예제 코드를 실행해 보았다. 공식 문서에서 제공하는 간단한 테스트 코드를 작성하고 작동을 시도했는데, 예상치 못한 타입 에러가 발생했다.

End-to-end tests 공식 문서 예제 코드

describe('My First Test', () => {
  it('Does not do much!', () => {
    expect(true).to.equal(true);
  });
});

하지만 실행 결과는 다음과 같았다. 아래 사진처럼 빨간 줄이 그어지며 타입 오류가 발생했다.

설정에 문제가 있나 싶어 다양한 해결 방법을 찾아보니, 대부분의 사람들이 두 가지 방법을 제시하고 있었다.

1. @jest/globals에서 expect를 import 해오기

import { expect } from '@jest/globals';

2. tsconfig.json에서 cypress.config.ts를 제외 설정하기

"exclude": ["node_modules", "cypress.config.ts", ]

두 가지 방법 전부 타입 에러 문제가 해결되지 않았다.

타입 충돌 원인

지금 사용하기를 Cypress 테스트 코드를 대상으로 TypeScript 타입 검사가 이뤄져야 하는데 Jest를 사용하고 있기 때문에 Cypress expect.to가 존재하지 않는다고 나오는 것이였다.

Cypress 공식 문서의 타입 스크립트 섹션에서 다음과 같이 말해주고 있었다.

동일한 프로젝트에서 Jest와 Cypress를 모두 사용하는 경우 두 테스트 러너에서 전역적으로 등록된 TypeScript 유형이 충돌할 수 있다

테스트 러너(Test Runner)는 코드를 실행하고 테스트를 자동으로 수행하는 도구다. 개발자가 작성한 테스트 스크립트를 실행해 주고, 그 결과를 보여주는 역할을 한다. 또한 테스트가 실패한 경우 오류 메시지를 제공하여 문제를 해결할 수 있도록 도와준다. 대표적인 테스트 러너로는 Jest와 Cypress가 있으며, 각각 다른 용도로 사용된다.

• Jest: 주로 유닛 테스트(Unit Test)나 통합 테스트(Integration Test)에 사용된다. 자바스크립트 환경에서 동작하며, UI 없이 코드의 로직을 테스트하는 데 적합
• Cypress: 주로 엔드 투 엔드 테스트(End-to-End Test)에 사용된다. 웹 애플리케이션의 실제 브라우저 동작을 테스트하는 데 유용하며, 사용자 상호작용을 시뮬레이션

해결 방법 (tsconfig.json 설정)

해결방법은 정말 간단한다. 타입 충돌이 발생하기 때문에 Cypress E2E 테스트를 위해 별도의 tsconfig.json을 설정한다.

1. cypress를 설치하면서 생긴 cypress 폴더 하위에 tsconfig.json 파일을 생성한다.

2. 아래 코드를 복사, 봍여 넣기를 진행한다.

   {
   "extends": "../tsconfig.json",
   "compilerOptions": {
    "noEmit": true,
    // be explicit about types included
    // to avoid clashing with Jest types
    "types": ["cypress"]
   },
   "include": [
    "../node_modules/cypress",
    "./**/*.ts"
   ]
   }

설정의 의미

1. "extends": "../tsconfig.json" 이 설정은 프로젝트의 기존의 상위 폴더에 있는 tsconfig.json 파일을 확장한다는 뜻이다. 즉, 상위 설정을 그대로 가져오고, 필요한 부분만 덮어써서 사용한다. 이를 통해 공통 설정을 유지하고, 필요한 부분만 수정할 수 있다.

2. "compilerOptions": { "noEmit": true } "noEmit": true는 TypeScript 컴파일러가 실제로 JavaScript 파일을 생성하지 않도록 하는 설정한다.

3. "types": ["cypress"]

Cypress와 Jest 같은 테스트 러너를 함께 사용할 경우, Jest와 Cypress가 각각 전역으로 타입을 정의하기 때문에 타입 충돌이 발생할 수 있다. 이를 방지하기 위해 Cypress 관련 타입만 명시적으로 포함하겠다는 의미이다.

4. "include": ["../node_modules/cypress", "./**/*.ts"] 이 설정은 컴파일에 포함할 파일 및 디렉터리를 지정한다.

• "../node_modules/cypress": Cypress가 설치된 디렉터리 경로를 포함
• "./**/*.ts": 현재 디렉터리 및 하위 디렉터리에 있는 모든 TypeScript 파일(.ts)을 포함

Cypress 타입 충돌 관련 공식 문서

인터넷을 통해 웹사이트에 접속할 때, 우리는 대부분 HTTP 또는 HTTPS를 사용한다. 이 두 프로토콜은 웹 브라우저와 서버 간의 통신 방식을 결정한다. 하지만 둘의 차이점과, 왜 HTTPS가 더 안전한지에 대해 자세히 알아볼 필요가 있다. 이번 글에서는 HTTP와 HTTPS의 차이점에 대해 설명하고, 왜 HTTPS가 중요한지 알아보겠다.

프로토콜: 프로토콜(Protocol)은 통신 규약을 의미하며, 컴퓨터나 네트워크 상에서 데이터를 주고받을 때 사용하는 규칙과 절차의 모음이다. 이를 통해 서로 다른 시스템이 일관된 방식으로 데이터를 교환하고 이해할 수 있다.

HTTP

** HTTP란 ?**

HTTP(HyperText Transfer Protocol)는 웹 브라우저와 서버가 데이터를 주고받는 표준 프로토콜이다. 이 프로토콜을 통해 웹 페이지, 이미지, 동영상 등을 주고받을 수 있다. 하지만 HTTP는 암호화되지 않은 평문(Plain Text) 방식으로 데이터를 전송한다.

즉, HTTP를 사용할 경우 다음과 같은 문제점이 발생할 수 있다.

• 보안 취약성: HTTP는 데이터를 암호화하지 않기 때문에, 중간에 누군가가 데이터를 가로챌 수 있습니다. 이를 중간자 공격(Man-in-the-Middle Attack)이라고 부른다.

• 신원 인증 부족: HTTP는 서버가 실제로 신뢰할 수 있는 서버인지 확인할 수 있는 방법이 없다. 따라서 피싱 사이트에 속을 가능성이 있다.

클라이언트 <---- 암호화 없음 ----> 서버

HTTPS

HTTPS란 무엇인가?

HTTPS(HyperText Transfer Protocol Secure)는 HTTP의 보안 버전이다. SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security)라는 암호화 프로토콜을 사용하여, 데이터를 암호화한 상태로 주고받는다. 이를 통해, 클라이언트와 서버 간의 통신을 더 안전하게 만들 수 있다.

HTTPS의 주요 기능

• 암호화: 서버와 클라이언트 간 주고받는 데이터를 암호화하여, 중간에서 누군가 데이터를 가로채더라도 내용을 알 수 없게 만듬

• 데이터 무결성: 전송 중에 데이터가 수정되거나 손상되지 않도록 보장

• 서버 신원 인증: 클라이언트는 서버가 신뢰할 수 있는 기관에 의해 인증된 서버인지 확인할 수 있다. 이는 SSL/TLS 인증서를 통해 이루어진다.

클라이언트 <---- 암호화 ----> 서버

HTTP와 HTTPS의 차이점

HTTPS의 중요성

오늘날 대부분의 웹사이트는 HTTPS를 사용한다. 특히 로그인 정보, 결제 정보 등과 같은 민감한 데이터를 주고받는 웹사이트에서 HTTPS는 필수적입니다. 구글 크롬과 같은 주요 웹 브라우저는 HTTP만 사용하는 웹사이트에 대해 "안전하지 않음" 경고를 표시한다.

HTTP에서 HTTPS로의 전환

웹사이트 소유자는 SSL/TLS 인증서를 발급받아야 HTTPS로 전환할 수 있다. 이 과정은 간단하며, 무료로 인증서를 발급해주는 Let’s Encrypt와 같은 서비스도 있다. HTTPS로 전환하면 사용자의 신뢰도를 높이고, 검색 엔진 최적화(SEO) 측면에서도 유리하다.

결론

HTTP는 빠르고 간단한 프로토콜이지만, 보안 측면에서 큰 취약점을 가지고 있다. 반면, HTTPS는 데이터 암호화, 서버 신원 인증, 데이터 무결성을 보장하여 더 안전한 웹 환경을 제공한다. 민감한 정보를 다루는 웹사이트라면 반드시 HTTPS를 사용하는 것이 필수적이다.

any 타입

• any 타입은 TypeScript에서 '모든 타입'을 의미

• 어떤 타입이든 될 수 있으며, 해당 값에 대해 아무런 제약 없이 자유롭게 사용 가능

• any를 사용하면 컴파일러가 타입 검사를 하지 않기 때문에 타입 안정성을 잃음

let value: any;
value = 42;
value = "hello";
value = true;

// 위에 value는 전부 any 타입
// 타입 검사 없이 사용 가능
console.log(value.toUpperCase());  // 런타임 에러가 발생할 수 있음

// Property 'toUpperCase' does not exist on type 'boolean' 에러 발생

위 코드에서 보듯이, any는 매우 자유롭게 사용할 수 있지만, 그만큼 실수를 감지하지 못하고 런타임에서 에러를 일으킬 수 있다. any는 매우 편리하지만, 타입 안정성을 희생하는 결과를 초래할 수 있다.

unknown 타입

• unknown 타입은 any와 유사하게 '모든 타입이 될 수 있다'는 의미

• 중요한 차이점은, unknown 타입으로 선언된 값은 타입이 확정되지 않으면 사용이 제한된다는 점

• 이를 통해 타입 안전성을 보장

let value: unknown;
value = 42;
value = "hello";

// 바로 사용 불가
// console.log(value.toUpperCase());  // 에러

'value' is of type 'unknown'.(18046) 에러 메시지


// 타입 검사를 통해 안전하게 사용 가능
if (typeof value === "string") {
    console.log(value.toUpperCase());  // 정상 동작
}

unknown은 항상 타입 검사를 통해 값의 타입을 확정해야만 사용할 수 있기 때문에, any보다 안전한 방식으로 값을 다룰 수 있다. 이는 unknown 타입의 주요 장점으로, 런타임 에러를 줄이는 데 도움이 된다.

어떤 타입을 선택해야 할까?

• any는 매우 유연하지만, 타입 안정성을 희생

• 정말로 타입을 모르는 경우에만 사용하고, 가능하면 unknown 타입을 사용

• unknown 타입은 타입 검사를 강제하므로, 타입 안전성을 유지하면서 유연한 코드를 작성 가능

결론적으로, 타입 안정성이 중요한 코드에서는 unknown을 사용하는 것이 더 좋은 선택이 될 수 있다. any는 꼭 필요한 상황에서만 사용하는 것이 좋다.

** 1. HTML 파일 다운로드 및 파싱**

• 브라우저는 서버에서 HTML 파일을 받아옵니다.

• HTML 파일을 받아오면, 브라우저의 렌더링 엔진이 HTML 파싱을 시작합니다.

• 이때 HTML을 분석하며 DOM (Document Object Model) 트리를 만듭니다. DOM은 HTML 요소들을 노드 형태로 표현한 트리 구조입니다.

• HTML에 포함된 <link>, <script>, <img> 등 외부 리소스는 별도로 다운로드 요청을 보내며, CSS와 JavaScript 파일이 이 과정에서 로드됩니다.

2. CSS 파일 다운로드 및 파싱

• 브라우저는 HTML 파싱 중 태그를 만나면, CSS 파일을 서버에서 다운로드받아 파싱합니다.

• CSS 파일은 브라우저의 렌더링 엔진에 의해 분석되어 CSSOM (CSS Object Model) 트리로 변환됩니다.

• CSSOM은 각 HTML 요소에 적용할 스타일을 정의하며, DOM과 결합하여 최종 화면에 표시될 구조를 만듭니다.

3. DOM과 CSSOM 결합 (Render Tree 생성)

• 브라우저는 파싱된 DOM 트리와 CSSOM 트리를 결합하여 렌더 트리 (Render Tree) 를 만듭니다.

• 렌더 트리는 화면에 실제로 그려질 요소들만 포함하며, display: none 속성이 있는 요소나 태그 내부의 내용은 제외됩니다.

• 이 렌더 트리는 각 요소의 위치와 스타일 정보를 포함한 시각적 구조입니다.

4. 레이아웃 단계 (Layout)

• 레이아웃 단계에서는 렌더 트리를 기반으로 각 요소의 정확한 위치와 크기를 계산합니다. 이 과정을 "reflow"라고도 부릅니다.

• 브라우저는 페이지의 뷰포트 크기, 콘텐츠 크기, 그리고 CSS 스타일에 따라 각 요소가 어디에 배치될지를 계산합니다.

5. 페인팅 (Painting)

• 페인팅 단계에서는 각 요소의 스타일(색상, 배경 이미지, 텍스트 등)을 렌더 트리에 적용하여 화면에 그려질 픽셀 데이터를 생성합니다.

• 이 단계에서 요소들은 layers (레이어)로 나뉘어 처리되며, 각 레이어는 페인팅 작업을 통해 색상, 그림자, 텍스트, 경계선 등의 시각적 스타일을 적용받습니다.

6. 컴포지팅 (Compositing)

• 페인팅 작업이 끝난 후, 여러 레이어로 나뉘어진 요소들은 최종적으로 합쳐져 화면에 렌더링됩니다. 이 과정을 컴포지팅 (Compositing)이라고 합니다.
  • 브라우저는 각 레이어를 GPU를 통해 빠르게 렌더링하고, 화면에 그려질 최종 이미지를 사용자에게 표시합니다.

7. JavaScript 실행 (자바스크립트의 영향)

• HTML 파싱 중