# React Native의 렌더링 방식 이해하기

---

## Table of Contents

- [기존 React의 렌더링 방식과의 차이점](#기존-react의-렌더링-방식과의-차이점)
    - [1. React (웹)에서의 렌더링](#1-react-웹에서의-렌더링)
    - [2. React Native에서의 렌더링](#2-react-native에서의-렌더링)
- [React Native의 렌더링 과정](#react-native의-렌더링-과정)
    - [1. JavaScript에서 UI 선언](#1-javascript에서-ui-선언)
    - [2. Shadow Tree 생성 (Bridge를 통한 통신)](#2-shadow-tree-생성-bridge를-통한-통신)
    - [3. 네이티브 UI 업데이트](#3-네이티브-ui-업데이트)
- [Fabric: 새로운 렌더링 아키텍처](#fabric-새로운-렌더링-아키텍처)
    - [Fabric의 주요 특징](#fabric의-주요-특징)
    - [Fabric이 적용된 React Native의 렌더링 과정](#fabric이-적용된-react-native의-렌더링-과정)
- [React Native에서의 성능 최적화](#react-native에서의-성능-최적화)
    - [1. 불필요한 리렌더링 방지 (`React.memo`, `useMemo`)](#1-불필요한-리렌더링-방지-reactmemo-usememo)
    - [2. `useCallback`으로 함수 재생성 방지](#2-usecallback으로-함수-재생성-방지)
    - [3. FlatList와 VirtualizedList 사용](#3-flatlist와-virtualizedlist-사용)
- [결론](#결론)
- [참고 자료](#참고-자료)


## 기존 React의 렌더링 방식과의 차이점

React는 컴포넌트 기반의 선언형 UI 라이브러리로, 브라우저에서 DOM을 조작하는 방식으로 화면을 렌더링한다. 하지만 React Native는 웹이 아니라 모바일 애플리케이션을 위한 프레임워크다. 따라서 화면을 구성하는 방식이 다르다.

### 1. React (웹)에서의 렌더링

웹 환경에서는 React가 가상 DOM(Virtual DOM)을 이용하여 변경된 부분만 실제 DOM에 반영하는 방식으로 성능을 최적화한다.

React는 `setCount`가 호출될 때 가상 DOM에서 변경된 부분을 감지하고, 브라우저의 실제 DOM을 업데이트한다.

### 2. React Native에서의 렌더링

React Native는 웹이 아니라 네이티브 UI를 조작해야 한다. 따라서 브라우저의 DOM을 직접 조작하는 것이 아니라, **네이티브 컴포넌트와 브릿지를 통해 UI를 업데이트하는 방식**을 사용한다.

React Native에서는 `div`, `p`, `button`과 같은 웹 요소를 사용하지 않고, `View`, `Text`, `Button`과 같은 네이티브 컴포넌트를 사용한다.

## React Native의 렌더링 과정

React Native는 다음과 같은 과정으로 렌더링을 수행한다:

### 1. JavaScript에서 UI 선언

컴포넌트를 정의하고, 상태(state)가 변경될 때마다 React의 **Reconciliation 과정**을 거쳐 UI를 갱신한다.

### 2. Shadow Tree 생성 (Bridge를 통한 통신)

React Native는 가상 DOM 대신 **Shadow Tree**를 사용하여 변경 사항을 추적한다. 이 정보는 브릿지를 통해 네이티브 코드로 전달된다.

### 3. 네이티브 UI 업데이트

네이티브 측에서는 전달받은 정보를 기반으로 실제 UI 요소(View, Text 등)를 업데이트한다.

## Fabric: 새로운 렌더링 아키텍처

기존 React Native는 브릿지를 통해 JavaScript와 네이티브 간 통신을 했지만, 이 방식은 성능 저하를 유발하는 주요 원인이었다. 이를 해결하기 위해 **Fabric**이 도입되었다.

### Fabric의 주요 특징

1. **동기 렌더링(Synchronous Rendering)** 지원 → UI 업데이트가 더욱 빠르고 즉각적으로 반영됨
2. **JSI(JavaScript Interface) 활용** → 브릿지를 거치지 않고 네이티브 모듈과 직접 통신 가능
3. **Shadow Tree 최적화** → UI 업데이트 과정이 단순화됨
4. **향상된 멀티스레딩 지원** → UI 스레드에서 불필요한 작업을 줄이고 성능을 개선함

### Fabric이 적용된 React Native의 렌더링 과정

1. React 컴포넌트가 변경됨
2. Shadow Tree가 Fabric을 통해 네이티브와 직접 통신
3. UI 업데이트가 동기적으로 적용됨

Fabric을 사용하면 브릿지를 통한 비효율적인 통신이 제거되면서 **React Native의 성능이 대폭 향상**된다.

## React Native에서의 성능 최적화

React Native의 렌더링 방식은 웹과 다르기 때문에, 최적화 기법도 차이가 있다.

### 1. 불필요한 리렌더링 방지 (`React.memo`, `useMemo`)

이처럼 `React.memo`를 활용하면 동일한 props가 전달될 경우 리렌더링을 방지할 수 있다.

### 2. `useCallback`으로 함수 재생성 방지

이렇게 하면 불필요한 함수 재생성을 막아 렌더링 성능을 높일 수 있다.

### 3. FlatList와 VirtualizedList 사용

대량의 리스트를 렌더링할 때 `FlatList`를 사용하면 메모리 사용을 최적화할 수 있다.

## 결론

React Native는 기존 React와 비슷한 방식으로 UI를 선언하지만, 실제 렌더링 과정은 네이티브 UI와 브릿지를 통해 이루어진다. 그리고 새로운 아키텍처인 **Fabric**이 도입되면서 렌더링 성능이 더욱 향상되었다. 따라서 React 웹 개발자라 하더라도 **네이티브 UI 업데이트 방식과 최적화 기법을 이해하는 것이 중요**하다.

## 참고 자료

- [New Architecture is here](https://reactnative.dev/blog/2024/10/23/the-new-architecture-is-here)
- [Fabric](https://reactnative.dev/architecture/fabric-renderer)

앱에는 html, css가 없는데 어떻게 렌더링하는거지?

React Native의 렌더링 방식 이해하기

# 새로운 JavaScript Temporal 객체 소개 (2025년 1월 24일 실험적 릴리스)

---

## Table of Contents

- [기존 Date 객체의 한계](#기존-date-객체의-한계)
    - [1. 일관성 없는 API와 사용성 문제](#1-일관성-없는-api와-사용성-문제)
    - [2. 불변성(Immutable) 지원 부족](#2-불변성immutable-지원-부족)
    - [3. 시간대(Timezone) 및 UTC 처리의 불편함](#3-시간대timezone-및-utc-처리의-불편함)
    - [4. 포맷팅이 불편함](#4-포맷팅이-불편함)
    - [5. 날짜 계산이 불편함](#5-날짜-계산이-불편함)
- [Temporal 이란?](#temporal-이란)
    - [Temporal의 핵심 개념](#temporal의-핵심-개념)
- [주요 특징](#주요-특징)
    - [1. 불변성 (Immutable)](#1-불변성-immutable)
    - [2. 시간대(Timezone) 지원](#2-시간대timezone-지원)
    - [3. 나노초 단위 지원](#3-나노초-단위-지원)
    - [4. ISO 8601 포맷 기본 지원](#4-iso-8601-포맷-기본-지원)
    - [5. 날짜 간격 계산 간편화](#5-날짜-간격-계산-간편화)
    - [6. 기간 정렬 가능](#6-기간-정렬-가능)
- [참고 자료](#참고-자료)






지난 2025년 1월 24일, JavaScript의 `Temporal` 객체가 브라우저의 실험적 기능으로 제공되기 시작했다. 기존의 `Date` 객체와 어떤 차이점이 있으며, 어떤 기능을 제공하는지 정리해 보았다.

## 기존 Date 객체의 한계

`Date` 객체는 JavaScript가 1995년에 만들어질 때 Java의 초기 결함이 있는 `java.util.Date` API를 그대로 가져와 사용했다. Java 팀은 1997년에 이 문제를 해결했지만, JavaScript는 여전히 이를 유지하고 있다. 이 때문에 여러 가지 문제가 존재한다.

### 1. 일관성 없는 API와 사용성 문제

`Date` 객체는 생성, 조작, 포맷팅이 직관적이지 않다.

```js
const date = new Date(2025, 1, 14); // 2025년 2월 14일
```

- 월(Month)이 0부터 시작하여 직관적이지 않다.
- 날짜를 조작할 때 `setDate`, `setMonth` 같은 메서드를 직접 호출해야 한다.

### 2. 불변성(Immutable) 지원 부족

`Date` 객체는 mutable(변경 가능)하여, 조작 시 부작용이 발생할 수 있다.

```js
const date = new Date(2025, 1, 16);
date.setDate(date.getDate() + 1); // 원본 date 객체가 변경됨
```

이로 인해 여러 곳에서 같은 객체를 참조하면 예상치 못한 오류가 발생할 수 있다.

### 3. 시간대(Timezone) 및 UTC 처리의 불편함

`Date` 객체는 기본적으로 브라우저의 로컬 타임존을 사용하기 때문에, UTC 변환이 번거롭다.

```js
const date = new Date('2025-02-16T00:00:00Z');
console.log(date.toLocaleString('en-US', { timeZone: 'Asia/Seoul' }));
```

이처럼 `toLocaleString`을 활용해야 하지만, 브라우저별로 결과가 다를 수 있다. 또한, "시간대 없음"이라는 개념이 부족하여 달력이나 시계를 읽는 시간 개념을 다루기 어렵다.

### 4. 포맷팅이 불편함

기본 `Date` 객체에서 날짜를 원하는 형식으로 출력하려면 불편하게 조합해야 한다.

```js
const date = new Date();
console.log(`${date.getFullYear()}-${date.getMonth() + 1}-${date.getDate()}`);
```

### 5. 날짜 계산이 불편함

특정 날짜에 N일을 더하는 작업이 직관적이지 않다.

```js
const date = new Date();
date.setDate(date.getDate() + 7);
console.log(date);
```

이렇게 원본 객체를 수정해야 하는 문제가 있다.

이러한 문제들 때문에 대부분의 프로젝트에서 `moment.js`, `day.js`, `date-fns` 같은 라이브러리를 사용하여 날짜 및 시간을 처리해왔다.

## Temporal 이란?

`Temporal`은 기존 `Date` 객체의 한계를 극복하고 **보다 직관적이고 강력한 날짜/시간 API**를 제공하는 새로운 JavaScript 내장 객체다. 현재 실험적 릴리스로 제공되고 있으며, 추후 표준이 될 가능성이 높다.

### Temporal의 핵심 개념

Temporal은 순간(Instants), 지역 시간(Wall-clock time), 그리고 기간(Durations) 개념을 명확하게 정의한다.

- **지속시간(Duration)**: 두 시점 사이의 차이 (`Temporal.Duration`)
- **시점**:
    - **유니크한 시점**
        - 타임스탬프 (`Temporal.Instant`)
        - 시간대를 포함한 날짜-시간 (`Temporal.ZonedDateTime`)
    - **시간대를 인식하지 않는 날짜/시간 (`Plain`)**
        - 전체 날짜 및 시간: `Temporal.PlainDateTime`
        - 날짜만: `Temporal.PlainDate`
        - 연도와 월: `Temporal.PlainYearMonth`
        - 월과 일: `Temporal.PlainMonthDay`
        - 시간만: `Temporal.PlainTime`
- **현재 시간**: `Temporal.Now`

## 주요 특징

### 1. 불변성 (Immutable)

`Temporal`은 **immutable**하게 동작하며, 값을 변경하면 새로운 객체를 반환한다.

```js
const today = Temporal.PlainDate.from('2025-02-16');
const tomorrow = today.add({ days: 1 });

console.log(today.toString());   // 2025-02-16 (변경되지 않음)
console.log(tomorrow.toString()); // 2025-02-17 (새 객체 반환)
```

### 2. 시간대(Timezone) 지원

ISO 시간대를 명확하게 지정할 수 있다.

```js
const seoulTime = Temporal.Now.zonedDateTimeISO('Asia/Seoul');
console.log(seoulTime.toString()); // 2025-02-16T10:00:00+09:00[Asia/Seoul]
```

### 3. 나노초 단위 지원

기존 `Date` 객체는 밀리초(ms)까지만 지원했지만, `Temporal`은 나노초(ns)까지 정밀하게 다룰 수 있다.

```js
const now = Temporal.Now.instant();
console.log(now.epochNanoseconds); // 1708049295000000000 (나노초 단위)
```

### 4. ISO 8601 포맷 기본 지원

```js
const date = Temporal.PlainDateTime.from('2025-02-16T15:30:00');
console.log(date.toString()); // 2025-02-16T15:30:00
```

### 5. 날짜 간격 계산 간편화

`Temporal`에서는 `since()` 메서드를 사용해 날짜 차이를 쉽게 계산할 수 있다.

```js
const start = Temporal.PlainDate.from('2025-02-16');
const end = Temporal.PlainDate.from('2025-03-01');
const diff = end.since(start);
console.log(diff.days); // 13
```

### 6. 기간 정렬 가능

`Temporal.Duration.compare`를 활용해 기간을 정렬할 수 있다.

```js
const durations = [
  Temporal.Duration.from({ hours: 1 }),
  Temporal.Duration.from({ hours: 2 }),
  Temporal.Duration.from({ hours: 1, minutes: 30 }),
  Temporal.Duration.from({ hours: 1, minutes: 45 }),
];

durations.sort(Temporal.Duration.compare);
console.log(durations.map((d) => d.toString()));
// [ 'PT1H', 'PT1H30M', 'PT1H45M', 'PT2H' ]
```

## 참고 자료

- [TC39 Temporal Proposal](https://tc39.es/proposal-temporal/docs/)
- [MDN: JavaScript Temporal 소개](https://developer.mozilla.org/en-US/blog/javascript-temporal-is-coming/)
- [Bytes.dev - Temporal 개요](https://bytes.dev/archives/365)
- [MDN: Temporal API](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal)

새로운 JavaScript Temporal 객체 소개 (2025년 1월 24일 실험적 릴리스)

# JWT 인증에서 Refresh Token 갱신하기

---

## Table of Contents

- [들어가며](#들어가며)
- [JWT 인증 개요](#jwt-인증-개요)
- [Refresh Token을 활용한 인증 흐름](#refresh-token을-활용한-인증-흐름)
- [React + Axios로 Refresh Token 처리하기](#react--axios로-refresh-token-처리하기)
    - [1. Axios 인스턴스 설정](#1-access-token-만료-시-자동-갱신)
    - [2. Axios 인터셉터를 이용한 자동 토큰 갱신](#2-axios-인터셉터를-이용한-자동-토큰-갱신)
    - [3. React Query와 함께 사용하기](#3-react-query와-함께-사용하기)
- [에러 핸들링 전략](#에러-핸들링-전략)
    - [1. Access Token 만료 시 자동 갱신](#1-access-token-만료-시-자동-갱신)
    - [2. Refresh Token 만료 시 재 로그인 유도](#2-refresh-token-만료-시-재-로그인-유도)
    - [3. 네트워크 오류 및 예외 상황 대비](#3-네트워크-오류-및-예외-상황-대비)
- [정리](#정리)


## 들어가며

JWT(JSON Web Token)를 활용한 인증 방식은 웹 개발에서 널리 사용된다. 하지만 프론트엔드에서 액세스 토큰(access token)이 만료될 때, 이를 어떻게 갱신(refresh)할지 구현하는 과정은 생각보다 복잡할 수 있다.

이 글에서는 **JWT 인증 구조를 직접 구현하는 것이 아니라**, 프론트엔드에서 Refresh Token을 활용해 인증을 지속하는 방법을 다룬다. React, Axios, TanStack React Query를 활용한 실제 예제와 함께 살펴보자.

## JWT 인증 개요

JWT 인증에서는 두 개의 토큰이 사용된다:

- **Access Token**: API 요청 시 사용되며, 보안 강화를 위해 유효 기간이 짧다 (예: 15분).
- **Refresh Token**: 더 긴 유효 기간(예: 7일 이상)을 가지며, Access Token이 만료되었을 때 새로운 Access Token을 발급받는 데 사용된다.

## Refresh Token을 활용한 인증 흐름

1. 사용자가 로그인하면 서버에서 **Access Token + Refresh Token**을 발급한다.
2. Access Token을 HTTP 요청에 포함하여 API 호출을 수행한다.
3. Access Token이 만료되면, Refresh Token을 사용해 새로운 Access Token을 요청한다.
4. 새로운 Access Token을 발급받아 저장한 후, 요청을 다시 수행한다.
5. Refresh Token도 만료되면, 사용자는 다시 로그인해야 한다.

## React + Axios로 Refresh Token 처리하기

### 1. Axios 인스턴스 설정

```javascript
import axios from 'axios';

const api = axios.create({
  baseURL: 'https://api.example.com',
  withCredentials: true, // 쿠키에 저장된 refresh token을 포함
});

export default api;
```

### 2. Axios 인터셉터를 이용한 자동 토큰 갱신

```javascript
import api from './api';

api.interceptors.response.use(
  (response) => response,
  async (error) => {
    const originalRequest = error.config;
    
    if (error.response?.status === 401 && !originalRequest._retry) {
      originalRequest._retry = true;
      try {
        const { data } = await api.post('/auth/refresh');
        localStorage.setItem('accessToken', data.accessToken);
        api.defaults.headers.common['Authorization'] = `Bearer ${data.accessToken}`;
        return api(originalRequest); // 실패한 요청 재시도
      } catch (refreshError) {
        console.error('Refresh Token이 만료되었습니다. 다시 로그인해주세요.');
      }
    }
    return Promise.reject(error);
  }
);
```

### 3. React Query와 함께 사용하기

```javascript
import { useQuery } from '@tanstack/react-query';
import api from './api';

const fetchUserData = async () => {
  const { data } = await api.get('/user');
  return data;
};

const useUser = () => {
  return useQuery({
    queryKey: ['USER'],
    queryFn: fetchUserData,
    staleTime: 5 * 60 * 1000, // 5분간 캐시 유지
  });
};

export default useUser;
```

## 에러 핸들링 전략

JWT 기반 인증에서 중요한 부분은 **토큰 만료 시의 대응 전략**이다. Refresh Token을 활용한 인증 처리에서 발생할 수 있는 주요 에러와 그 대응 방안을 정리해보자.

### 1. Access Token 만료 시 자동 갱신

- 서버 응답이 `401 Unauthorized`인 경우, 자동으로 Refresh Token을 사용해 Access Token을 갱신한다.
- 갱신 후 실패했던 API 요청을 재시도한다.
- 갱신 요청도 실패하면 사용자에게 로그인이 필요하다는 메시지를 표시한다.

```javascript
if (error.response?.status === 401) {
  try {
    const { data } = await api.post('/auth/refresh');
    localStorage.setItem('accessToken', data.accessToken);
    api.defaults.headers.common['Authorization'] = `Bearer ${data.accessToken}`;
    return api(originalRequest); // 실패한 요청 재시도
  } catch (refreshError) {
    console.error('토큰 갱신 실패, 다시 로그인해야 합니다.');
  }
}
```

### 2. Refresh Token 만료 시 재 로그인 유도

- Refresh Token이 만료되면 사용자는 반드시 다시 로그인해야 한다.
- 사용자 경험을 고려하여 단순히 로그아웃시키는 것이 아니라 **안내 메시지를 표시**하는 것이 좋다.

```javascript
if (refreshError.response?.status === 403) {
  alert('세션이 만료되었습니다. 다시 로그인해주세요.');
  window.location.href = '/login';
}
```

### 3. 네트워크 오류 및 예외 상황 대비

- 인터넷 연결이 끊어진 상태에서 API 요청이 실패할 수 있다.
- 서버가 예상치 못한 오류(`500 Internal Server Error`)를 반환하는 경우도 고려해야 한다.

```javascript
if (!error.response) {
  alert('네트워크 연결을 확인해주세요.');
} else if (error.response.status >= 500) {
  alert('서버 오류가 발생했습니다. 잠시 후 다시 시도해주세요.');
}
```

## 정리

JWT 인증 방식에서는 Access Token이 만료될 때 Refresh Token을 활용해 인증을 지속해야 한다. Axios 인터셉터를 활용하면 자동으로 토큰을 갱신할 수 있고, React Query와 함께 사용하면 네트워크 요청을 효율적으로 관리할 수 있다.

특히 **토큰 만료 시의 에러 핸들링 전략**이 중요하다. Refresh Token까지 만료된 경우, 사용자를 재로그인하도록 유도하는 UX적인 고려도 필요하다.

프론트엔드에서 인증을 구현해야 한다면, 이런 방식을 참고해 적용해보자.

언제 Refresh Token 을 갱신하는게 좋을까?