• 객체 구조(shape)를 일정하게 유지하라
• 동적 프로퍼티 추가를 조심하라
• 객체를 렌더마다 새로 만들지 마라

처음엔 그냥 "최적화 팁"처럼 보이지만, 사실 이건 전부 JavaScript 엔진(V8)의 내부 최적화 방식과 연결되어 있다.

이번 글에서는

• JIT 컴파일
• Hidden Class
• Inline Cache

가 실제로 어떻게 동작하는지, 그리고 왜 React 성능과 연결되는지 정리해보려 한다.

(V8 기준으로 설명)

먼저 큰 흐름

JavaScript는 기본적으로 동적 언어다.

즉 이런 코드가 있을 때

obj.a

엔진은 런타임마다

• a 프로퍼티가 진짜 있는지
• 객체 구조가 뭔지
• 타입이 뭔지

확인해야 할 수도 있다.

원래라면 굉장히 느릴 수 있는 구조다.

그래서 현대 JS 엔진은 내부적으로 엄청난 최적화를 수행한다.

전체 동작 흐름

JavaScript
  ↓
Parser
  ↓
AST 생성
  ↓
Interpreter (Bytecode 실행)
  ↓
Profiler (실행 패턴 수집)
  ↓
JIT Compiler
  ↓
Optimized Machine Code

핵심은:

처음엔 빠르게 실행하고, 자주 쓰이는 코드를 나중에 최적화한다

는 점이다.

1. JIT 컴파일 (Just-In-Time)

왜 필요할까?

예전 JavaScript 엔진은

코드 한 줄 해석 → 실행

방식이었다.

즉 인터프리터 기반.

하지만 이 방식은 반복 실행되는 코드에서 비효율적이었다.

현대 엔진 방식

요즘 엔진은

1. 처음엔 빠르게 인터프리트
2. 실행 패턴 수집
3. 자주 실행되는 코드 발견
4. 최적화된 머신코드 생성

흐름으로 동작한다.

이걸 JIT(Just-In-Time) 컴파일이라고 한다.

예시

function add(a, b) {
  return a + b;
}

처음엔 일반적인 방식으로 실행된다.

하지만 계속

add(1, 2);
add(3, 4);
add(5, 6);

처럼 숫자만 들어온다면 엔진은 판단한다.

"이 함수는 숫자 계산 전용이네?"

그 순간 JIT가 최적화를 시작한다.

최적화되는 부분

원래 JS는 매 호출마다

• 타입 검사
• 연산 방식 결정

같은 작업을 해야 한다.

하지만 숫자만 들어온다고 확신하면

타입 검사 생략

가능해진다.

즉 거의 네이티브 코드 수준으로 빨라진다.

그런데 문제 발생

갑자기

add("a", "b");

가 들어오면?

기존 최적화 가정이 깨진다.

엔진은

Deoptimization (deopt)

을 수행한다.

즉

• 최적화 취소
• 일반 인터프리트 모드 복귀

가 발생한다.

핵심

JavaScript 엔진은

"예측 가능한 코드"

를 굉장히 좋아한다.

즉

• 타입 안정성
• 일관된 호출 패턴

이 중요하다.

2. Hidden Class

이건 V8 최적화의 핵심 중 하나다.

JavaScript 객체의 문제

JS 객체는 동적으로 구조가 바뀔 수 있다.

const user = {};

user.name = "me";

런타임에 프로퍼티가 계속 추가된다.

문제는 CPU는 원래

struct User {
  char* name;
}

같은 고정 구조를 좋아한다는 점이다.

그래서 등장한 Hidden Class

V8은 객체를 내부적으로

"고정 구조처럼"

관리한다.

예를 들어

const user = {
  name: "me",
  age: 20,
};

를 만들면 내부적으로

HiddenClass1
- name → offset 0
- age → offset 1

같은 구조를 생성한다.

왜 빠를까?

user.name

접근 시

offset 0 접근

만 하면 된다.

즉 일반 해시 탐색이 아니라:

거의 C 구조체 접근처럼 동작한다.

문제 상황

const a = { x: 1, y: 2 };

const b = { y: 2, x: 1 };

겉보기엔 같아 보이지만

• 프로퍼티 생성 순서가 다름
• Hidden Class도 다르게 생성됨

즉 엔진 입장에서는 서로 다른 객체 구조다.

React에서 왜 중요할까?

예

const state = {
  name,
  age,
};

객체 구조가 계속 일정하게 유지되면 엔진 최적화가 잘 유지된다.

반대로

const obj = {};

if (condition) {
  obj.name = "me";
}

처럼 구조가 계속 바뀌면 최적화가 깨질 가능성이 높아진다.

즉

객체 shape 안정성

이 성능과 연결된다.

3. Inline Cache (IC)

이건 Hidden Class와 연결되는 최적화다.

문제

user.name

를 매번

• 프로퍼티 탐색
• 위치 검색

하면서 찾으면 느리다.

해결 방식

엔진은 캐싱한다.

예를 들어

"이 객체는 HiddenClass1 이었지?"

를 기억해둔다.

그러면 다음 접근부터는

바로 offset 접근

가능하다.

이걸 Inline Cache(IC)라고 한다.

즉

"이 형태의 객체는 여기 접근하면 된다"

를 캐싱하는 구조다.

동작 흐름

처음 접근

lookup 발생

두 번째부터

cache hit

즉 훨씬 빨라진다.

문제 상황 — Megamorphic

foo(obj1);
foo(obj2);
foo(obj3);

근데 매번 객체 shape가 다르다면?

엔진 입장에서는

"왜 맨날 다른 객체가 들어오지?"

상태가 된다.

이를

Megamorphic

상태라고 부른다.

즉 Inline Cache가 너무 많은 형태를 처리해야 해서 최적화 효율이 떨어진다.

React와 연결되는 부분

예를 들어

<Component style={{ color: "red" }} />

이 코드는 렌더마다

{ color: "red" }

새 객체를 생성한다.

즉

• 새 reference
• 새 allocation
• GC 증가
• shape 최적화 방해 가능성

이 생긴다.

그래서

• useMemo
• useCallback
• 객체 memoization

같은 패턴이 중요해진다.

실제 프론트엔드 예시

좋지 않은 패턴

items.map((item) => ({
  ...item,
  active: true,
}));

렌더마다

• 새 객체 생성
• 새 allocation
• GC 비용 증가

가 발생한다.

물론 무조건 나쁘다는 건 아니지만:

자주 렌더되는 대규모 리스트

에서는 성능에 영향을 줄 수 있다.

전체 흐름 정리

1단계 — 인터프리트

일단 빠르게 실행

2단계 — 패턴 수집

엔진이 관찰한다.

- 숫자만 오네?
- 객체 구조 일정하네?
- 호출 패턴 안정적이네?

3단계 — Hidden Class 생성

객체 구조 최적화

4단계 — Inline Cache 적용

프로퍼티 접근 캐싱

5단계 — JIT 최적화

최적화된 머신코드 생성

6단계 — 예측 실패

타입이나 구조가 바뀌면

deopt 발생

다시 일반 모드로 복귀

결국 핵심은 하나

JavaScript 엔진 최적화는 결국

"예측 가능한 코드"

를 좋아한다.

즉

• 타입 안정성
• 객체 구조 안정성
• 일관된 호출 패턴

이 성능 최적화의 핵심이다.

이걸 이해하면

• 왜 객체 shape 유지가 중요한지
• 왜 dynamic property 추가가 느릴 수 있는지
• 왜 React re-render 최적화가 필요한지
• 왜 useMemo/useCallback을 쓰는지

를 단순 React 레벨이 아니라

"엔진 수준"

에서 이해할 수 있게 된다.

"페이지를 이동했다 돌아오면 왜 점점 느려지지?"

처음엔 렌더링 문제처럼 보이지만 실제 원인은 대부분 cleanup 누락이다.

특히 requestAnimationFrame은 컴포넌트가 사라져도 자동으로 멈추지 않는다.

명시적으로 취소하지 않으면 이전 루프가 계속 살아 있고, GPU 메모리도 계속 쌓인다.

App Router처럼 페이지 전환이 잦은 환경에서는 특히 더 잘 드러난다.

• 이전 페이지의 animation loop가 계속 실행되고
• geometry / material / texture가 GPU 메모리에 남아 있으며
• 결국 탭이 느려지거나 WebGL context limit에 걸리기도 한다

이번 글에서는 Three.js를 React useEffect 안에서 안전하게 사용하는 방법과 정확히 무엇을 cleanup 해야 하는지 정리해보려 한다.

문제 — 멈추지 않는 루프

보통 Three.js를 처음 세팅하면 이렇게 작성한다.

useEffect(() => {
  const renderer = new THREE.WebGLRenderer({ canvas });

  const scene = new THREE.Scene();

  const geometry = new THREE.BoxGeometry();

  const material = new THREE.MeshBasicMaterial({
    color: "blue",
  });

  const mesh = new THREE.Mesh(geometry, material);

  scene.add(mesh);

  const animate = () => {
    requestAnimationFrame(animate);

    mesh.rotation.y += 0.01;

    renderer.render(scene, camera);
  };

  animate();
}, []);

[] 덕분에 마운트 시 한 번만 실행된다.

문제는:

언마운트 시 아무것도 정리하지 않는다는 것

이다.

컴포넌트가 사라져도 내부적으로는:

animate()
  ↓
requestAnimationFrame(animate)
  ↓
animate()
  ↓
...

루프가 계속 반복된다.

즉 페이지를 이동해도 이전 animation loop가 백그라운드에서 계속 살아 있게 된다.

해결 — cleanup 함수 사용

useEffect는 cleanup 함수를 반환할 수 있다.

useEffect(() => {
  // 초기화

  return () => {
    // cleanup
  };
}, []);

이 함수는:

• 컴포넌트 언마운트 시
• 의존성 변경 직전

자동으로 실행된다.

Three.js 리소스 정리는 모두 여기서 수행해야 한다.

requestAnimationFrame 취소

먼저 animation loop를 멈춰야 한다.

let rafId = 0;

const animate = () => {
  rafId = requestAnimationFrame(animate);

  renderer.render(scene, camera);
};

animate();

return () => {
  cancelAnimationFrame(rafId);
};

핵심은:

rafId = requestAnimationFrame(animate);

처럼:

매 프레임마다 최신 ID를 저장하는 것

이다.

cleanup 시 마지막 예약 ID를 취소하면 다음 프레임부터 루프가 멈춘다.

중요한 문제 — GPU 메모리는 자동 해제되지 않는다

루프를 멈췄다고 끝난 게 아니다.

Three.js의:

• geometry
• material
• texture

같은 객체들은 내부적으로 GPU(WebGL)에 업로드된다.

즉 JavaScript 객체가 GC 대상이 되더라도:

GPU 메모리는 별도로 dispose 해야 한다.

dispose()

return () => {
  cancelAnimationFrame(rafId);

  geometry.dispose();

  material.dispose();

  texture.dispose();

  renderer.dispose();
};

각각 의미는 다음과 같다.

특히 texture.dispose()는 자주 빠뜨린다.

material.dispose()를 호출해도 texture는 자동 해제되지 않는다.

실제 패턴

보통은 이런 형태로 정리한다.

useEffect(() => {
  const canvas = canvasRef.current;

  if (!canvas) return;

  const renderer = new THREE.WebGLRenderer({
    canvas,
    antialias: true,
  });

  const scene = new THREE.Scene();

  const camera = new THREE.PerspectiveCamera(
    60,
    canvas.clientWidth / canvas.clientHeight,
    0.1,
    100,
  );

  camera.position.z = 3;

  const geometry = new THREE.BoxGeometry(1.5, 1.5, 1.5);

  const material = new THREE.MeshBasicMaterial({
    color: "#2563eb",
    wireframe: true,
  });

  const mesh = new THREE.Mesh(geometry, material);

  scene.add(mesh);

  let rafId = 0;

  const animate = () => {
    rafId = requestAnimationFrame(animate);

    mesh.rotation.y += 0.01;

    renderer.render(scene, camera);
  };

  animate();

  return () => {
    cancelAnimationFrame(rafId);

    geometry.dispose();
    material.dispose();

    renderer.dispose();
  };
}, []);

데모 전환 시 — 의존성 변경 패턴

탭 기반으로 여러 데모를 교체하는 경우에는:

useEffect(() => {
  const cleanup = initDemo(activeDemo, canvas);

  return () => {
    cleanup();
  };
}, [activeDemo]);

형태를 자주 사용한다.

흐름은:

이전 cleanup 실행
  ↓
raf 취소 + dispose
  ↓
새 데모 초기화

순서로 진행된다.

즉 데모를 빠르게 전환해도 이전 WebGL 리소스가 남지 않는다.

OrbitControls / GUI도 cleanup 필요

Three.js 자체뿐 아니라 부가 라이브러리도 정리해야 한다.

특히 OrbitControls는 이벤트 리스너를 등록하기 때문에 dispose하지 않으면 마우스 이벤트가 계속 살아 있다.

window 이벤트 리스너도 주의

이건 Three.js 외부 문제지만 정말 자주 놓친다.

const onResize = () => {
  // resize 처리
};

window.addEventListener("resize", onResize);

cleanup에서 반드시 제거해야 한다.

return () => {
  window.removeEventListener("resize", onResize);
};

canvas 이벤트도 동일하다.

canvas.addEventListener("mousemove", onMouseMove);

↓

canvas.removeEventListener("mousemove", onMouseMove);

정리하지 않으면:

• stale closure
• 중복 이벤트 실행
• 메모리 누수

문제가 발생할 수 있다.

정리

Three.js를 React에서 사용할 때 핵심은 결국 하나다.

초기화한 것은 반드시 cleanup에서 역순으로 정리한다.

• animation loop 중단
• GPU 리소스 dispose
• 이벤트 리스너 제거

이 세 가지만 제대로 관리해도 Next.js 환경에서 Three.js를 훨씬 안정적으로 사용할 수 있다.

"전송 버튼을 눌렀는데 내 메시지가 바로 안 뜬다."

WebSocket 기반이든 HTTP 기반이든, 서버 응답 이후에만 메시지를 추가하면 그 사이 UI가 멈춘 것처럼 보인다.

특히 네트워크가 느릴수록:

• 버튼을 눌렀는데 반응이 없고
• 메시지가 늦게 나타나며
• UX가 답답하게 느껴진다.

이번 글에서는 채팅 메시지 전송에 Optimistic Update를 적용하는 방법과, 서버 메시지와 로컬 메시지를 어떻게 동기화하는지 정리해보려 한다.

기본 구조 — pending 상태 추가

먼저 메시지 타입에 pending 상태를 추가한다.

type LocalMessage = ChatMessage & {
  pending?: boolean;
};

• 서버 메시지 → pending 없음 또는 false
• 아직 서버 확인 전인 메시지 → pending: true

즉:

"아직 서버 검증이 끝나지 않은 임시 메시지"

라는 상태를 표현하는 용도다.

실제로는 이 한 줄의 타입 확장만으로도 Optimistic Update의 기반이 만들어진다.

메시지 전송 — 먼저 렌더링하고 나중에 전송

const sendMessage = useCallback((content: string) => {
  const ws = wsRef.current;

  if (!ws || ws.readyState !== WebSocket.OPEN) return;

  // 1. 먼저 UI에 추가
  const optimistic: LocalMessage = {
    id: `pending_${Date.now()}`,
    content,
    author: currentUser,
    createdAt: new Date().toISOString(),
    pending: true,
  };

  setMessages((prev) => [...prev, optimistic]);

  // 2. 실제 전송은 그 다음
  ws.send(
    JSON.stringify({
      type: "chat:send",
      payload: { content },
    }),
  );
}, []);

핵심은 순서다.

기존 방식은:

전송 → 서버 응답 → 렌더

였다면,

Optimistic Update는:

렌더 → 전송 → 서버 검증

순서로 동작한다.

즉 유저 입장에서는 버튼을 누르는 즉시 내 메시지가 화면에 보인다.

서버 응답 처리 — pending 메시지 교체

이후 서버에서 chat:message 이벤트가 도착하면:

1. 내가 보낸 pending 메시지인지 확인
2. 맞다면 실제 서버 메시지로 교체
3. 아니라면 다른 유저 메시지로 추가

처리한다.

case "chat:message": {
  const incoming = data.payload.message;

  setMessages((prev) => {
    const pendingIdx = prev.findIndex(
      (m) =>
        m.pending &&
        m.content === incoming.content &&
        m.author.id === incoming.author.id,
    );

    // 1. pending 메시지 교체
    if (pendingIdx !== -1) {
      const next = [...prev];
      next[pendingIdx] = incoming;
      return next;
    }

    // 2. 중복 방지
    if (prev.some((m) => m.id === incoming.id)) {
      return prev;
    }

    // 3. 다른 유저 메시지 추가
    return [...prev, incoming];
  });
}

전체 흐름

전송 버튼 클릭
  ↓
pending 메시지 즉시 추가
(id: pending_xxx, pending: true)
  ↓
WebSocket 전송
  ↓
서버에서 chat:message 이벤트 도착
  ↓
pending 메시지 탐색
  ↓
일치하면 → 서버 메시지로 교체
불일치하면 → 새 메시지 추가

핵심 — pending 메시지 매칭 기준

가장 중요한 건:

"서버 메시지와 어떤 기준으로 매칭할 것인가"

다.

현재 구현에서는:

m.pending &&
m.content === incoming.content &&
m.author.id === incoming.author.id

조건으로 찾고 있다.

왜 id로 비교하지 않을까?

pending 메시지의 id는:

pending_123123

같은 임시값이다.

반면 서버 메시지는:

msg_87asd7

처럼 실제 DB 기반 id를 가진다.

즉 서로 값이 다르기 때문에 id 비교로는 매칭할 수 없다.

그래서:

• content
• author.id

조합으로 "같은 메시지"인지 판단한다.

UI에서 pending 상태 표현하기

pending 플래그를 사용하면 전송 중 상태를 자연스럽게 표시할 수 있다.

{messages.map((msg) => (
  <div
    key={msg.id}
    style={{
      opacity: msg.pending ? 0.5 : 1,
    }}
  >
    {msg.content}

    {msg.pending && (
      <span>전송 중...</span>
    )}
  </div>
))}

유저 입장에서는:

1. 메시지가 즉시 나타나고
2. 서버 응답 전까지 흐리게 표시되며
3. 서버 확인 후 정상 상태로 변경

되는 흐름으로 보인다.

주의할 점 — rollback 처리

현재 구조는 사실상:

ws.send(...)

후 응답을 기다리지 않는 fire-and-forget 방식이다.

즉 전송 실패 시 pending 메시지가 계속 남아 있을 수 있다.

실패 처리 방법

예를 들어 연결이 끊겼다면:

setMessages((prev) =>
  prev.filter((m) => !m.pending),
);

처럼 rollback 처리할 수 있다.

또는:

pending: "failed"

같은 상태를 추가해:

• 재전송 버튼
• 실패 표시 UI

를 제공할 수도 있다.

케이스별 처리 전략

정리

채팅에서 Optimistic Update의 핵심은 결국 두 가지다.

먼저 보여주고,

나중에 서버 상태와 맞춘다.

그리고 서버 응답이 도착하면:

임시 메시지를 실제 메시지로 교체한다.

이 흐름만 잘 설계해도 채팅 UX 체감 속도는 꽤 크게 개선된다.

특히 React를 사용하다 보면:

• 왜 useMemo를 쓰는지
• 왜 .map() 남발이 성능에 안 좋은지
• 왜 key가 중요한지
• 왜 Set으로 중복 제거를 하는지

같은 것들이 결국 자료구조/알고리즘 개념과 연결된다.

1. 왜 useMemo가 필요한가

핵심은:

같은 계산을 매 렌더마다 다시 하지 않기 위해

자료구조/알고리즘 관점에서는:

• 연산 비용 감소
• 시간복잡도 최소화
• 캐싱(Cache)

개념에 가깝다.

예를 들어:

const sorted = users.sort(...)

이 코드가 렌더마다 실행되면:

렌더 횟수 × 정렬 비용

이 계속 발생하게 된다.

정렬은 일반적으로:

O(n log n)

복잡도를 가지기 때문에 데이터가 많아질수록 부담이 커진다.

useMemo는 결국 캐싱

useMemo는 내부적으로 보면:

{
  deps: [...],
  cachedValue: result
}

처럼 이전 계산 결과를 저장해두는 개념에 가깝다.

예를 들면:

const sorted = useMemo(() => {
  return users.sort(...)
}, [users])

이렇게 작성하면:

• users가 변경되지 않는 동안
• 이전 계산 결과를 재사용

하게 된다.

즉:

불필요한 O(n log n) 연산을 줄이는 것

이 핵심이다.

2. 왜 .map() 남발하면 느릴까

핵심은:

배열 순회는 공짜가 아니다

.map()은 기본적으로:

O(n)

복잡도를 가진다.

예를 들어:

users.map(...)
posts.map(...)
comments.map(...)

이런 코드가 렌더마다 반복되면:

O(n) + O(n) + O(n)

비용이 계속 발생한다.

더 위험한 건 중첩 반복문

예:

users.map(user => {
  posts.map(post => ...)
})

이 경우는:

O(n²)

까지 증가할 수 있다.

React에서 특히 문제가 되는 이유는:

• state 변경
• props 변경
• context 변경

등으로 렌더링이 자주 발생하기 때문이다.

즉 .map()이 렌더마다 계속 반복 실행된다.

실무에서 사용하는 해결 방법

1. Memoization

const items = useMemo(() => {
  return data.map(...)
}, [data])

불필요한 반복 계산을 줄인다.

2. Virtualization

예:

• FlashList
• react-window

화면에 보이는 아이템만 렌더링해 렌더 비용을 줄인다.

3. Normalization

배열 대신 객체나 Map 형태로 관리한다.

예:

usersById[user.id]

이런 방식은 탐색 비용을 줄일 수 있다.

3. 왜 key가 중요한가

이건 React의 Diffing 알고리즘과 연결된다.

React는 이전 배열과 새 배열을 비교할 때:

"누가 누구인지"

판별해야 한다.

예:

[
  { id: 1 },
  { id: 2 },
  { id: 3 }
]

React는 key 기반으로 비교한다.

key={item.id}

그런데 index를 쓰면?

예를 들어:

A B C

상태에서 앞에 D가 추가되면:

D A B C

가 된다.

하지만 key={index}를 사용하면 React는:

0 = A → D로 착각
1 = B → A로 착각
2 = C → B로 착각

하게 된다.

그 결과:

• DOM 재사용 꼬임
• state 꼬임
• 불필요한 re-render 증가

같은 문제가 발생할 수 있다.

자료구조 관점으로 보면 결국:

고유 식별자(primary key)

문제에 가깝다.

DB에서 id가 중요한 이유와 비슷하다.

4. 왜 Set으로 중복 제거를 할까

배열에서 중복 검사를 할 때 보통:

arr.includes(x)

를 사용한다.

하지만 includes는:

O(n)

복잡도를 가진다.

예를 들어:

const result = []

for (const item of items) {
  if (!result.includes(item)) {
    result.push(item)
  }
}

이 방식은 최악의 경우:

O(n²)

까지 증가할 수 있다.

Set은 해시 기반

반면 Set은 해시 기반 자료구조라 탐색 비용이 매우 낮다.

const set = new Set(items)

검색은 평균적으로:

O(1)

에 가깝다.

그래서 실무에서는:

const unique = [...new Set(items)]

패턴을 굉장히 자주 사용한다.

예를 들어:

onlineUsers = [...new Set(users)]

처럼 websocket 중복 유저 제거에도 많이 사용된다.

결국 React 성능 최적화도 대부분 자료구조와 알고리즘 개념 위에서 동작한다.

Next.js App Router 환경에서 Emotion을 사용하다 보면 아래와 같은 오류를 종종 보게 됩니다.

Warning: Prop `className` did not match

또는:

• Hydration mismatch
• 스타일 깜빡임(FOUC)
• 스타일 우선순위 꼬임
• 서버/클라이언트 스타일 불일치

이번 글에서는 왜 이런 문제가 발생하는지 간단하게 정리해보겠습니다.

App Router는 기본적으로 Server Component 기반

Next.js App Router는 기존 Pages Router와 달리 기본적으로 Server Component 기반 구조입니다.

즉 컴포넌트가:

1. 서버에서 먼저 렌더링되고
2. HTML이 전달된 뒤
3. 클라이언트에서 hydration 되는 방식입니다.

반면 Emotion은:

• 런타임에서 스타일 생성
• 동적으로 className 생성
• 스타일 삽입 순서(insertion order) 관리

같은 특징을 가지고 있습니다.

즉 Emotion은 기본적으로 클라이언트 환경에서 동작하는 CSS-in-JS 방식에 더 가깝습니다.

여기서 App Router와 충돌이 발생할 수 있습니다.

가장 많이 발생하는 문제: className 불일치

Emotion은 렌더링 시점마다 className을 생성합니다.

예를 들면:

css-1abcde
css-92kda

같은 형태의 className이 만들어집니다.

그런데 App Router 환경에서는:

1. 서버 렌더링
2. 클라이언트 hydration
3. 다시 렌더링

과정을 거치면서 스타일 생성 순서가 달라질 수 있습니다.

그 결과:

Warning: Prop `className` did not match

같은 hydration 오류가 발생하게 됩니다.

왜 App Router에서 더 자주 발생할까?

React 18 + App Router는 아래 기능들을 적극적으로 사용합니다.

• Streaming SSR
• Suspense
• Concurrent Rendering

이 환경에서는 컴포넌트 렌더링 순서가 항상 동일하지 않을 수 있습니다.

하지만 Emotion은:

• 어떤 컴포넌트가 먼저 렌더됐는지
• 어떤 스타일이 먼저 삽입됐는지

에 영향을 많이 받습니다.

즉:

렌더링 순서가 바뀌는 환경에서 런타임으로 스타일을 생성하다 보니 문제가 발생하는 것

에 가깝습니다.

실제로 나타나는 현상들

1. Hydration mismatch

Warning: Prop `className` did not match

서버와 클라이언트의 className이 달라지는 문제입니다.

2. 스타일 깜빡임 (FOUC)

초기 렌더 시 스타일이 적용되지 않았다가 뒤늦게 적용되는 현상입니다.

3. 스타일 우선순위 꼬임

Emotion의 insertion order가 달라지면서 예상과 다른 스타일이 적용될 수 있습니다.

4. 특정 상황에서 스타일이 사라지는 문제

재현 조건이 일정하지 않은 경우가 많아 디버깅도 쉽지 않습니다.

styled-components도 비슷한데 왜 Emotion 이야기가 더 많을까?

Emotion은 특히:

• 런타임 의존성
• cache 관리
• insertion order

영향을 크게 받습니다.

그래서 App Router 환경에서는 설정이 조금만 어긋나도 문제가 쉽게 발생합니다.

특히 아래 설정이 중요합니다.

CacheProvider
useServerInsertedHTML

이 설정 없이 사용하면 스타일 충돌 가능성이 높아집니다.

해결 방법

보통은 Emotion Registry를 직접 구성해서 사용합니다.

예를 들면:

'use client'

import { CacheProvider } from '@emotion/react'
import createCache from '@emotion/cache'

그리고 Next.js의:

useServerInsertedHTML()

를 사용해 서버 렌더링 시 style 태그를 직접 삽입합니다.

핵심은:

서버와 클라이언트의 스타일 생성 순서를 최대한 동일하게 맞추는 것

입니다.

그래서 요즘은 어떤 방식이 많이 쓰일까?

최근 App Router 환경에서는 아래 스타일링 방식 선호도가 높아지고 있습니다.

• Tailwind CSS
• CSS Modules
• Panda CSS
• Vanilla Extract

이유는:

• hydration 문제 감소
• 서버 컴포넌트 친화적
• 런타임 비용 감소
• 번들 크기 감소

같은 장점 때문입니다.

마무리

Emotion 자체가 문제 있는 라이브러리는 아닙니다.

다만 Next.js App Router + React 18 환경에서는:

• Streaming SSR
• Concurrent Rendering
• Server Components

구조와 런타임 스타일 생성 방식이 충돌하기 쉬운 편입니다.

그래서 최근에는 빌드 타임 기반 스타일링 방식도 많이 사용되는 추세입니다.

React Native에서는 성능 이슈가 비교적 쉽게 발생하는 만큼 리스트 렌더링에는 FlashList를 사용하며 최대한 최적화를 고려하고 있다.

이번 글에서는 FlashList + Sticky Header를 구현하면서 특히 애를 먹었던 부분들과 그 과정에서 정리한 포인트들을 공유해보려고 한다.

첫 번째 시도

FlashList에서 제공하는 stickyHeaderIndices 옵션을 활용해 Sticky Header를 구현해보았다.

하지만 예상과는 다른 문제가 발생했다.

문제점

stickyHeaderIndices는 renderItem으로 렌더링되는 항목에만 적용되며, ListHeaderComponent에는 적용할 수 없었다.

그 결과 리스트의 첫 번째 상품 아이템이 고정되는 현상이 발생했고, 의도했던 Sticky Header와는 전혀 다른 어색한 UI가 만들어졌다.

두 번째 시도

그래서 다음으로는:

ListHeaderComponent를 사용하지 않고 Header 자체를 renderItem 안으로 넣어보자

라는 방향으로 구현을 변경했다.

이를 위해 리스트 데이터에 타입을 부여해 각 아이템 역할을 구분하도록 구성했다.

• type: 'header' → Sticky Header 영역
• type: 'item' → 일반 상품 아이템

이렇게 하면 Header 역시 리스트 아이템처럼 취급되기 때문에 stickyHeaderIndices를 적용할 수 있을 것이라 생각했다.

하지만 이 방식 역시 FlashList의 구조와 완전히 잘 맞는 방식은 아니었다.

FlashList 입장에서는 Header 또한 일반 아이템과 동일하게 처리되기 때문에:

• 재사용 대상이 되고
• 스크롤 상황에 따라 unmount / mount가 발생할 수 있으며
• Sticky 상태에서 불필요한 re-render가 발생할 가능성이 있었다.

결과적으로 FlashList의 가상화 장점을 일부 희생하는 구조에 가까웠다.

또한 성능 관점에서도 아쉬움이 있었다.

FlashList는 기본적으로 아이템 가상화에 최적화된 리스트인데, stickyHeaderIndices는 내부적으로 레이아웃 계산과 위치 보정 과정을 수행하기 때문에 스크롤 중 추가 비용이 발생할 수 있었다.

세 번째 시도

최종 구현 방식

결국 FlashList에서 제공하는 스크롤 이벤트를 활용해 현재 스크롤 위치를 직접 추적하는 방식으로 구현했다.

스크롤 중 전달받는 현재 Y축 값을 기준으로 Header의 위치를 비교하고, 특정 시점부터 Header를 show / hide 하도록 구성했다.

실제 구현에서는 Header의 opacity 값을 조정해 스크롤 위치에 따라 자연스럽게 나타나고 사라지는 형태로 처리했다.

이를 통해 Sticky Header를 실제로 고정시키지 않더라도, 사용자 입장에서는 자연스러운 Sticky UI처럼 느껴지도록 구현할 수 있었다.

무엇보다 레이아웃 재계산을 최소화하면서 JS → UI 업데이트 비용도 줄일 수 있었고, 결과적으로 성능과 UX 모두 만족할 수 있는 방향으로 마무리할 수 있었다.

• 캐싱은 자주 사용되는 데이터를 한 번 받아온 후에 그 데이터를 임시 저장소에 저장하여 동일한 데이터를 빠르게 불러와서 사용하는 기법을 말한다.
• 메모리 계층 구조에서 캐시는 디스크나 메인 메모리보다 더 빠르게 데이터를 불러와 사용해야 할 때 쓰인다.

캐싱의 종류?

• 캐싱에는 여러 종류가 존재한다.

1) 브라우저 캐시

• 변화가 적은 데이터라면 캐싱을 적용해 볼 수 있다. HTML, CSS, JavaScript, 이미지 등 웹 자원을 로컬 디스크에 저장해둔다. 이는 로컬 저장소에 캐시되기 때문에 단일 사용자를 대상으로 하며, 해당 사용자의 정보만을 저장한다. ex) Etag와 Cache-Control은 브라우저 캐시와 관련된 HTTP 헤더로, 웹 브라우저가 서버에서 자원을 어떻게 캐시할지를 결정하는 데 사용된다.

• HTTP 헤더의 ETag는 특정 버전의 리소스를 식별한다. 클라이언트는 데이터를 최초로 받은 이후 동일한 리소스를 요청할 때, 이전에 받은 Etag 값을 If-None-Match 헤더에 포함하여 요청을 보낸다.

• If-Modified-Since* 캐시된 리소스의 Last-Modified 값 이후에 서버 리소스가 수정되었는지 확인합니다. 서버는 이 Etag와 리소스의 현재 Etag를 비교하여, 리소스가 변경되지 않았다면 304 Not Modified 상태 코드와 함께 빈 응답을 보내고, 리소스가 변경되었으면 새로운 리소스를 반환한다.

• HTTP 헤더의 Cache-Control은 클라이언트(브라우저)와 서버 간의 캐시 동작을 제어한다.

  no-cache: 서버에서 데이터를 확인해야 하며, 이전에 캐시된 데이터를 사용하지 않도록 합니다.

• no-store*: 데이터가 캐시되지 않도록 합니다.

• max-age*: 리소스가 캐시된 후 최대 몇 초 동안 유효한지 지정합니다.

• public*: 리소스가 모든 캐시에 저장될 수 있음을 의미합니다.

• private*: 리소스는 사용자별로 개인적인 캐시에 저장됩니다.

• must-revalidate*: 캐시된 리소스가 만료되었을 경우, 서버에서 리소스를 다시 확인해야 함을 의미합니다.

• s-maxage*: 중간 서버에서만 적용되는 max-age 값을 설정하기 위해 사용합니다. 예를 들어, Cache-Control 값을 s-maxage=31536000, max-age=0 과 같이 설정하면 CDN에서는 1년동안 캐시되지만 브라우저에서는 매번 재검증 요청을 보내도록 설정할 수 있습니다.

no-cache 속성은 캐시를 먼저 사용하기 이전에 서버에 해당 캐시를 사용해도 되는지에 관해 검증 요청을 보내는 속성이다. 
no-cache 속성이 없는 경우 캐시가 있다면 바로 캐시를 쓰지만(max-age=0), no-cache 속성이 있는 경우 캐시를 바로 쓰지 않고 서버에 이 캐시를 사용해도 되는지에 대한 허락을 맡기 때문에 요청에 대한 시간이 소요될 수 있다.

no-store는 개인정보 등 private 한 데이터가 있는 경우 이 속성을 사용할 수 있다. (캐시를 만들어서 저장조차 하지 않는다.)
private cache에 반대되는 shared cache 가 존재한다.

Cache-Control max-age 값 대신 Expires 헤더로 캐시 만료 시간을 정확히 지정할 수도 있습니다.

• Cache-Control은 리소스를 어떻게 캐시할지에 대한 지침을 제공하며, Etag는 리소스의 변경 여부를 확인하는 데 사용된다.

2) 프록시 캐시

• 공유 캐시(shared cache)로 한 명 이상의 사용자에 의해 재사용되는 응답을 저장한다. no-cache는 최신화가 필요한 stale 데이터를 사용하고 싶을 때 사용하고, 이러한 데이터를 사용해서 문제가 발생한다면 504 에러를 반환하는 must-revalidate를 사용하면 된다.

3) CDN 캐시

• CDN은 성능 향상을 위해 클라이언트의 요청이 같은 서버로 가는 것을 막는다. CDN 캐시는 웹 자원의 정적 파일을 캐시하여 빠른 응답을 제공한다.

  일반적으로 캐시를 없애기 위해서 CDN Invalidation을 수행한다고 한다. CDN에 저장되어 있는 캐시를 삭제한다는 뜻이다. 브라우저의 캐시는 다른 곳에 위치하기 때문에 CDN 캐시를 삭제한다고 해서 브라우저 캐시가 삭제되지는 않는다.

데이터 페칭 라이브러리에서는 캐싱을 어떻게 처리할까?

React Query

• 서버에서 받은 데이터를 클라이언트의 로컬 메모리나 로컬 스토리지, 또는 IndexedDB에 저장하여 다음에 동일한 요청이 있을 경우 네트워크 요청을 생략하고 캐시된 데이터를 반환할 수 있습니다.
• staleTime을 설정하여 데이터가 "stale" 상태(즉, 오래된 상태)가 되기까지의 시간을 지정할 수 있고, cacheTime을 통해 캐시된 데이터를 얼마나 오래 보존할지 설정할 수 있습니다.

staleTime: 데이터를 얼마나 오래 캐시할지 지정합니다. 이 시간이 지나면 데이터는 "stale" 상태가 됩니다. cacheTime: 캐시된 데이터를 언제까지 저장할지 지정합니다. 이 시간이 지나면 캐시된 데이터는 삭제됩니다. refetchOnWindowFocus: 브라우저 창이 포커스를 받을 때 데이터를 자동으로 재페칭할지 여부를 설정합니다.

ref) https://yozm.wishket.com/magazine/detail/2341/ ref) https://toss.tech/article/smart-web-service-cache

* useImperativeHandle

• 부모 컴포넌트가 자식 컴포넌트의 특정 기능에 접근하도록 허용. 일반적으로 ref와 함께 사용되며, forwardRef가 필요함. 부모가 자식 컴포넌트의 특정 기능(예: focus, scroll)을 직접 호출.

[사용 예시]

const FancyInput = React.forwardRef((props, ref) => {
  const inputRef = React.useRef();
  React.useImperativeHandle(ref, () => ({
    focus: () => {
      inputRef.current.focus();
    },
  }));
  return <input ref={inputRef} />;
});

function Parent() {
  const ref = React.useRef();

  return (
    <div>
      <FancyInput ref={ref} />
      <button onClick={() => ref.current.focus()}>포커스</button>
    </div>
  );
}

* useLayoutEffect

• DOM이 렌더링된 직후, 브라우저가 그리기 전에 동기적으로 실행. DOM 변경 후 바로 실행이 필요한 경우에 적합하다. useEffect와 비슷하지만 실행 시점이 다르다.

[사용 시기]

DOM 요소의 위치, 크기 조정이 필요할 때. 애니메이션 효과나 스크롤 위치 설정.

[차이점]

useEffect: 렌더링 이후 실행 (비동기). useLayoutEffect: 렌더링 직전에 실행 (동기).

function LayoutEffectExample() {
  const divRef = React.useRef();

  React.useLayoutEffect(() => {
    console.log(divRef.current.offsetHeight);
  }, []);

  return <div ref={divRef}>레이아웃 확인</div>;
}

* useTransition

• 상태 업데이트를 긴급/비긴급으로 나누어 처리한다. 사용자 인터페이스가 부드럽게 유지. React 18의 Concurrent Mode에서 유용.

  function App() {
  const [isPending, startTransition] = React.useTransition();
  const [count, setCount] = React.useState(0);
  
  const handleClick = () => {
    startTransition(() => {
      setCount((c) => c + 1);
    });
  };
  
  return (
    <div>
      <button onClick={handleClick}>클릭</button>
      {isPending ? <p>로딩 중...</p> : <p>결과: {count}</p>}
    </div>
  );
  }
  

#### * useId
- 고유한 ID를 생성해서 HTML에 사용한다. 나는 폼에 적용했었다. 컴포넌트간 충돌이 없어 유용하다.

function Component() { const id = React.useId();

return ( 입력창 ); }

#### * useDefferedValue
- 부하가 큰 연산의 업데이트를 지연시켜 UI 성능 개선. UI가 느려지지 않도록 함.

function App({ value }) { const deferredValue = React.useDeferredValue(value);

return

#### * useActionState
- 비동기 액션의 상태를 더 명확하고 직관적으로 관리할 수 있다. (기존 useFormState 훅을 개선했다.)

"use client";

function App() { const [state, submitAction, isPending] = useActionState(customAction, initialState); // initialState like {error: null}

return (
    <form action={submitAction}>
    <button disabled={isPending}></button>
    {state.error && <span>error</span>}
    </form>
)

}

``` 리액트 훅이므로 클라이언트 컴포넌트에서 사용해야 한다. pending 상태와 useState, onSubmit 함수를 축약해 개인적으로 가독성과 데이터 응집도가 높아졌다고 생각한다.

“form, input, button 요소에 action 및 formAction props로 Server Action을 전달하면 JavaScript가 비활성화되었거나 코드가 로드되기 전에도 사용자가 폼을 제출하고, 오류를 표시할 수 있게 되었다.”

JavaScript가 비활성화되거나 코드가 로드되기 전에 사용자가 form을 제출할 수 있으면 뭐가 좋은걸까?

사용자의 인터넷 연결이 느리거나, 장치 성능이 낮거나, JavaScript가 비활성화된 환경에서도 폼 제출 기능이 정상적으로 작동하도록 보장해줄 수 있다. 이로써 웹사이트의 접근성을 높여 모든 사용자에게 일관된 경험을 제공할 수 있게 되고, 결과적으로 사용자가 겪을 수 있는 잠재적인 문제를 줄이고 더 많은 사용자가 서비스를 이용할 수 있게 하는 것이다.

• 리액트 상태 관리 라이브러리들 (feat. 장단점)
• 상태 관리에 Redux를 선택하게 된 계기
• Redux 셋팅하기
• Next.js에 Redux를 적용하며 마주하게 된 사사로운 오류사항들
• 번외

🛠️ 리액트 상태 관리 라이브러리들 (feat. 장단점)

리액트 상태 관리 라이브러리에는 다양한 종류가 있다. 익숙한 것들만 간단히 나열해보자면 Recoil, Redux, Jotai, Mobx, zustand 등등 ...

우리가 사용할 기술을 선정할 때 고려해야 할 것이 몇가지 있다. 각 기술의 특성과 장단점을 무조건 파악을 해야 한다는 거다.

제일 주의해야하는 건 무작정 '남들이 다 사용하니까' 선택하는 일이다.

그렇게 되면 내가 만들 프로젝트와 그 기술의 성격이 맞지 않을 수가 있고, 몸집이 커진 프로젝트를 다시 싹 다 갈아 엎어야 하는 대참사가 발생할 수도 있다.

상태관리에 Redux를 선택하게 된 계기

위와 같은 다양한 라이브러리 중 나는 zustand 또는 Redux 사이에서 고민하게 되었다.

나의 상황을 적어보자면

1) 온전히 혼자 작업을 해야 한다. 2) 최대한 빠르게 작업을 마무리 하면 좋다. 3) 두 라이브러리 모두 사용해 본 경험이 없거나 적다.

위 같은 상황에서 빠르고 쉽게 작업할 수 있는 zustand 를 선택하는게 더 효율적이었겠지만, 나는 redux를 선택했다!

왜냐면 redux는 대규모 프로젝트에 더 적합하기 때문이다. (나는 런칭해서 운영까지, 즉 유지보수까지 해보고 싶었기 때문이다.) 그리고 '쉬운걸 먼저 적용해버리면 나중에 더 큰 어려움을 마주하게 되지 않을까? 그러니까 어려운 것부터 먼저 깊게 다뤄보자!' 싶은 마음이었다.

따라서 redux를 next.js(App Route) + typescript 에 적용하게 되는데 ,,,

Redux 셋팅하기

자 차근차근 적용해보도록 하자.

우선, redux와 관련 패키지를 설치해야 한다.

Redux 설치

npm install @reduxjs/toolkit react-redux

Redux 설정

일단, store를 만든다. 이때 store는 redux의 모든 상태들을 관리하게 된다.

// store.ts

import { configureStore } from "@reduxjs/toolkit";
import rootReducer from "./rootReducer";

export const makeStore = () => {
  return configureStore({
    reducer: rootReducer,
  });
};


export type AppStore = ReturnType<typeof makeStore>;
export type RootState = ReturnType<AppStore["getState"]>;
export type AppDispatch = AppStore["dispatch"];

slice 생성

slice는 액션 및 리듀서를 포함한다.

import { createSlice } from "@reduxjs/toolkit";

const userAuthSlices = createSlice({
  name: "userAuth", // slice 식별
  initialState: { name: "subeen" },
  reducers: {
    setUserAuth: (state, action) => {
      state.name = action.payload;
    },
  },
});

export const { setUserAuth } = userAuthSlices.actions;

export default userAuthSlices.reducer;

이때, name에 따라 slice가 식별되니 직관적이게 작명하도록 유의한다.

Provider 설정

Provider를 설정해 모든 페이지에서 Redux 상태에 접근할 수 있도록 한다.

Next.js App Router 구조에서는 app/layout.tsx 파일에서 설정한다.

"use client";

import React from "react";
import { Provider } from "react-redux";
import { makeStore } from "./lib/store";

const store = makeStore(); // makeStore 함수를 호출하여 스토어 객체를 생성합니다.

const ClientLayout: React.FC<{ children: React.ReactNode }> = ({
  children,
}) => {
  return (
    <Provider store={store}>
      {/* store 객체를 Provider에 전달합니다. */}
      <main>{children}</main>
    </Provider>
  );
};

export default ClientLayout;

import Footer from "@/components/Footer";
import Header from "@/components/Header";
import type { Metadata, Viewport } from "next";
import { Inter } from "next/font/google";
import ClientLayout from "./ClientLayout";
import "./globals.css";

const inter = Inter({ subsets: ["latin"] });

export const metadata: Metadata = {
  title: "Create Next App",
  description: "Generated by create next app",
};

export const viewport: Viewport = {
  initialScale: 1,
  width: "device-width",
};

const RootLayout = ({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) => {
  return (
    <html lang="en">
      <body className={inter.className}>
        <ClientLayout>
          <Header />
          {children}
        </ClientLayout>
        <Footer />
      </body>
    </html>
  );
};

export default RootLayout;

위의 코드를 보면 바로 Provider로 감싸는 대신 ClientLayout으로 감쌌는데, 이는 Redux가 클라이언트 컴포넌트에서만 작동하는 훅을 사용해야하기 때문이다. (useSelector, useDispatch)

여기서 잠깐

Redux는 클라이언트 사이드 상태 관리 (브라우저 환경에서 동작하는 상태 관리 도구) 라이브러리이기 때문에 "use client" 지시어가 필요하다.

("use client" 지시어는 초기 페이지 로딩 속도나 사용자 경험에 부정적인 영향을 미칠 가능성이 있다. 번들 크기가 커져 페이지 로드 시간이 증가하는 단점도 있다.)

보통 그래서 next-redux-wrapper 라이브러리를 사용한다.

Redux 사용 예시

컴포넌트에서 redux 상태와 액션 사용 방법이다. useSelector와 useDispatch 훅을 이용하여 상태를 조회하고, 액션을 디스패치 할 수 있다.

// app/login/page.tsx
'use client';

import { useState } from 'react';
import { useDispatch } from 'react-redux';
import { login } from '../../features/userSlice';
import { useRouter } from 'next/navigation';

const LoginPage = () => {
  const [email, setEmail] = useState('');
  const [password, setPassword] = useState('');
  const dispatch = useDispatch();
  const router = useRouter();

  const handleLogin = async (e: React.FormEvent) => {
    e.preventDefault();

    // 실제로는 백엔드에서 로그인 API 호출
    const userData = {
      id: '123',
      name: 'John Doe',
      email: email,
    };

    // 로그인 성공 시 Redux에 사용자 정보를 저장
    dispatch(login(userData));

    // 대시보드로 리디렉션
    router.push('/dashboard');
  };

  return (
    <form onSubmit={handleLogin}>
      <div>
        <label>Email</label>
        <input
          type="email"
          value={email}
          onChange={(e) => setEmail(e.target.value)}
          required
        />
      </div>
      <div>
        <label>Password</label>
        <input
          type="password"
          value={password}
          onChange={(e) => setPassword(e.target.value)}
          required
        />
      </div>
      <button type="submit">Login</button>
    </form>
  );
};

export default LoginPage;

Next.js에 Redux를 적용하며 마주하게 된 사사로운 오류사항들

가장 많이 언급되는 불편함: 새로고침 하면 날라가요 ,,,

이를 해결하기 위한 몇가지 방법이 있다.

아. 일단 왜 이런 문제가 발생하냐면, 브라우저를 새로고침 하면 페이지 전체를 다시 로드하기 때문에 Redux 상태가 초기화된다.

첫번째 해결방법) redux-persist 라이브러리 사용

간략한 사용법 설명

npm install redux-persist

2. 스토어 설정

   // lib/store.ts
   import { configureStore } from '@reduxjs/toolkit';
   import { persistStore, persistReducer } from 'redux-persist';
   import storage from 'redux-persist/lib/storage'; // 기본적으로 localStorage 사용
   import rootReducer from './rootReducer'; // 모든 리듀서를 합친 rootReducer
   

const persistConfig = { key: 'root', storage, // localStorage에 저장 };

const persistedReducer = persistReducer(persistConfig, rootReducer);

export const store = configureStore({ reducer: persistedReducer, });

export const persistor = persistStore(store);

<br>

3. Provider 설정
<br>

// app/layout.tsx 'use client';

import './globals.css'; import { Provider } from 'react-redux'; import { store, persistor } from '../lib/store'; import { PersistGate } from 'redux-persist/integration/react'; import Header from '../components/Header';

export default function RootLayout({ children }: { children: React.ReactNode }) { return (

<br>


redux-persist의 PersistGate를 사용하여, 스토어가 복원되기 전까지 앱을 지연시킬 수 있다.

<br>



만약 세션 중에만 상태를 유지하고 싶다면 redux-persist/lib/storage/session을 사용할 수 있다.

<br>


__단점__
- 스토리지의 크기가 제한적이고, 복잡한 상태 관리에는 다소 비효율적일 수 있습니다.
상태가 커질수록 브라우저 로딩 시간이 길어질 수 있음.








<br><br>

**두번째 해결방법) localStorage나 sessionStorage 직접 사용**
<br>


1. store가 업데이트 될 때마다 localStorage에 상태 저장
<br>

<br>


__장점__
- redux-persist보다 가볍고, 직접 제어 가능.
- 상태가 단순한 경우 빠르게 적용 가능.
<br>
__단점__
- 수동으로 상태 직렬화/역직렬화를 관리해야 하므로 코드 복잡도가 약간 증가.
- 상태가 클 경우 저장 성능에 영향을 줄 수 있음.






<br>
<br>


**세번째 해결방법) 쿠키 사용**

<br>

쿠키를 사용하여 상태를 저장할 수 있지만, 쿠키는 브라우저가 서버에 전송하는 용도로 주로 사용되므로 큰 데이터를 저장하는 데는 부적합하다. 그러나 인증 정보나 작은 상태값을 저장하는 데에는 적합.

<br>

<br>



__장점__
- 인증 정보나 작은 상태 저장에 적합.
- 서버 사이드 렌더링(SSR)과 쉽게 연동 가능.
<br>
__단점__
- 쿠키는 용량 제한이 있으므로 큰 데이터를 저장할 수 없음.
- 보안 이슈가 있을 수 있으며, 민감한 정보는 적절히 암호화 필요.





<br><br>





**네번째 해결방법) 서버 사이드에서 상태 저장**

<br>

Next.js의 API Routes를 활용하여 서버에 상태를 저장하고, 필요할 때 API를 통해 불러오는 방법.


<br>

<br>

새로고침 시 상태가 서버로부터 복원될 수 있도록 useEffect로 API를 호출하여 상태를 불러오고, 저장할 때는 API로 상태를 보낸다. 

<br>


__장점__
- 큰 데이터를 저장하거나, 보안이 필요한 상태 관리에 적합.
- 서버에서 관리되므로 클라이언트 측의 저장 용량 한계를 걱정할 필요 없음.
<br>
__단점__
- 상태 저장 및 불러오는 로직이 복잡해질 수 있음.
- 상태 저장/복원 시 네트워크 지연이 발생할 수 있음.


<br>



<br>

**나는 위 방법들 중에 localStorage 직접 설정을 택했다.**

<br>

redux-persist 는 나중에 사용해보도록 하자 ~

<br><br>




#### localStorage에 직접 설정하기
<br>

<br>

이런식으로 작성했더니 타입 오류가 났다.

<br>


makeStore 함수에 직접적으로 subscribe 메서드를 호출하려고 했기 때문이다. 

makeStore 함수는 store를 반환하는 함수이지 store 자체가 아니다.

(makeStore 함수가 호출된 후에 반환된 store 인스턴스를 사용해야 함)



<br>




코드를 수정해준 후, 디버깅을 해보았는데 store를 참조하고 있지 않았다.

(그래서 자꾸 데이터가 보존되지 않고 날아감)


<br>


각 store는 name에 따라 식별되고 있는데, localStorage에서 가져온 이 데이터가 어느 store에 대한 데이터인지 매칭이 안되고 있었다. 



<br>

따라서 아래와 같이 수정해주었다. 

const parsedState = JSON.parse(serializedState);

// 로컬 스토리지의 상태를 rootReducer의 구조에 맞게 변환
return {
  userAuth: parsedState, // userAuth로 감싸기
};

<br><br>


이상으로 Redux 적용기 1탄을 마무리해보도록 하겠다. 




<br><br>


~~velog 예쁘고 가독성 있게 작성하는거 왜케 어려워 ...~~

export const getServerSideProps: GetServerSideProps = async (context) => {
  try {
    const { menuId } = context.query;
    const response = await axios.get<CategoryType[]>(
      "http://localhost:8080/category/get/menu",
      {
        headers: {
          "Content-Type": "application/json",
          "Access-Control-Allow-Origin": "*",
        },
        params: {
          menuId: menuId,
        },
      }
    );
    const data = response.data;
    console.log(data);
    return {
      props: {
        CategoryData: data,
      },
    };
  } catch (err) {
    console.log(err);
    return {
      props: {},
    };
  }
};

export NODE_OPTIONS="--max-old-space-size=8192"

// 직접 무효화 하기 전까지는 이 request는 캐싱됨.
// `getStaticProps`와 비슷! (즉, 빌드 시점에 fetch)
// `force-cache`가 디폴트 값이므로 생략 가능
fetch(URL, { cache: 'force-cache' });

// 매번 요청 때마다 refetch 됨.
// `getServerSideProps`와 비슷!
fetch(URL, { cache: 'no-store' });

// 이 request는 10초동안 캐싱됨.
// This request should be cached with a lifetime of 10 seconds.
// `revalidate` 옵션을 지정한 `getStaticProps`와 비슷!
fetch(URL, { next: { revalidate: 10 } });