도니 House

Next.js 하이드레이션 에러 우아하게 처리하기

도니도니도니도니 — Mon, 22 Jun 2026 16:06:09 +0900

Next.js가 어떻게 돌아가는지 부터 파악해보기

- 프로젝트를 진행하면서 hydration에러가 발생했습니다.React error 418이 Hydration에러가 발생했다라는 뜻이라고 합니다.

- 근데 왜 발생했을까요

- 우선 Hydration이 뭔지 부터 저는 바로잡고자 다시한번 공부를 했습니다.

Hydration?

이정환님의 인프런 강의를 참고한 이미지입니다.

- 이번 Next.js에서 어떻게 렌더링을 하는지에 대해서 봅시다.

- 유저가 브라우저에서 접속 요청을 하면 서버에서 사전 렌더링이 시작됩니다. 이때 Next.js는 서버 컴포넌트(SC)와 클라이언트 컴포넌트(CC)를 구분해서 처리합니다.

- 서버 컴포넌트는 서버에서 실행된 뒤 RSC Payload 형태로 직렬화됩니다. 클라이언트 컴포넌트는 서버에서 HTML로 렌더링됩니다. 이 둘을 합쳐 완성된 HTML을 브라우저에 전달하고 유저는 즉시 화면을 볼 수 있습니다.

여기서 주의할 점 — SC는 RSC Payload로 클라이언트에 전달될 뿐 추가 작업이 없습니다. 반면 CC는 JS Bundle을 통해 Hydration 과정이 필요합니다.

- JS Bundle에는 SC가 제외된 CC만 포함되어 있으며 Hydration은 서버에서 받은 HTML에 이벤트 핸들러를 연결하는 과정입니다. 이 과정이 완료되어야 버튼 클릭 상태 변경 같은 상호작용이 가능해집니다.

다시 한번 정리하면 아래 그림으로 정리를 할 수 있습니다.

- 유저 접속 요청 -> SC, CC구분 해서 따로 실행 -> 실행된 결과 HTML을 전달 -> 유저가 화면 볼 수 있음 -> JS Bundle(CC만) -> 하이드레이션

다시 프로젝트로

- 이제 흐름을 이해했습니다.

- 근데 왜 프로젝트에 에러가 발생할까요?? 코드를 봅시다

  const getGenerationStatus = sessionStorage.getItem(
    WRITE_GENERATION_STATUS_KEY
  );

  const helperText =
    getGenerationStatus === "generating"
      ? "글 생성 중입니다. 버튼을 눌러 생성 화면으로 이동하세요."
      : getGenerationStatus === "done"
      ? "생성이 완료되었습니다. 버튼을 눌러 결과를 확인하세요."
      : getGenerationStatus === "error" && Boolean(getGenerationStatus)
      ? "생성 중 오류가 발생했습니다. 버튼을 눌러 다시 확인하세요."
      : `저장 가능: 포스트 최대 ${MAX_STORED_POSTS}개까지. 생성 후 자동으로 저장됩니다.`;

  const buttonLabel =
    getGenerationStatus === "generating"
      ? "생성 화면으로 이동"
      : getGenerationStatus === "done"
      ? "생성 결과 보기"
      : getGenerationStatus === "error" && Boolean(getGenerationStatus)
      ? "생성 화면으로 이동"
      : "AI 글 생성하기";

- 코드를 보면 세션 스토리지를 사용합니다.

- 여기서 문제가 발생하는데 세션 스토리지는 브라우저에만 존재합니다. 이게 왜 문제가 되는지 살펴보면

서버에서 렌더링할 때 → sessionStorage 없음 → getGenerationStatus = null

브라우저에서 Hydration할 때 → sessionStorage 있음 → getGenerationStatus = "generating" (등)

서버 HTML이랑 클라이언트 HTML이 달라서 → Hydration 에러

초기 서버 렌더링 시 sessionStorage가 없어 null로 렌더링되는데 Hydration 과정에서 클라이언트가 sessionStorage 값을 읽어 다른 값을 렌더링하기 때문에 불일치 에러가 발생합니다.

- Next.js 공식문서에도 다음과 같이 나와있습니다. https://nextjs.org/docs/messages/react-hydration-error#common-causes

Text content does not match server-rendered HTML

Next.js by Vercel is the full-stack React framework for the web.

nextjs.org

- Hydration 오류가 발생할 경우중 3번 케이스가 제가 해당하는 케이스입니다.

- 해결방법도 아래에 나와있습니다.

- useEffect가 가장 쉬워보이는데 함정이 있는데 초기설정 값이 나왔다가 다시 실제값이 넣어지는데 이로 인해 깜빡이는 것처럼 보이는 현상이 발생할 수 있습니다.

- 코드로 예시를 보면

- 아래 코드를 보면 처음 마운트 이후 한번만 값을 읽기 때문에 SessionStorage 값을 변경해도 UI가 자동으로 안바뀝니다.

const [status, setStatus] = useState<string | null>(null);

useEffect(() => {
  setStatus(sessionStorage.getItem(WRITE_GENERATION_STATUS_KEY));
}, []);

다른 방법 뭐가 있을까?

useSyncExternalStore 도입

- 문서 자료를 찾던중 useSyncExternalStore라는 리액트 훅을 발견했습니다.

- useSyncExternalStore는 React 18에서 추가된 훅으로 외부 스토어를 구독하기 위한 공식 API입니다.

- useSyncExternalStore의 도입 이유는 외부스토어를 구독하고 있어 실시간으로 반영이 가능하기 때문입니다.

- useSyncExternalStore는 인자를 다음과 같이 3개를 받습니다.

const value = useSyncExternalStore(
  subscribe,          // 스토어 변경 감지 구독 함수
  getSnapshot,        // 클라이언트에서 현재 값 읽기
  getServerSnapshot   // 서버에서 현재 값 읽기 (SSR용)
);

subscribe

스토어가 변경됐을 때 React에게 알려주는 함수로 React가 내부적으로 callback을 넘겨주고 변경이 생기면 그걸 호출하면 됩니다.

() => {
  window.addEventListener('storage', callback);
  return () => window.removeEventListener('storage', callback);
}

getSnapshot

클라이언트에서 현재 스토어 값을 읽는 함수로 매 렌더링마다 호출되고 이전 값이랑 다르면 리렌더링 트리거합니다.

() => sessionStorage.getItem(WRITE_GENERATION_STATUS_KEY)

getServerSnapshot

서버 렌더링할 때 사용할 값이고 sessionStorage처럼 서버에 없는 API면 null을 반환합니다.

() => null

프로젝트에 적용시켜보기

- 현재 같은 탭 안에서 sessionStorage 변경을 UI에 반영을 해야하기 때문에 커스텀 이벤트로 직접 발행했습니다

export const WRITE_GENERATION_STATUS_KEY = "self:write-generation-status";
export const GENERATION_STATUS_CHANGE_EVENT = "write-generation-status-change";

export function setGenerationStatus(status: GenerationStatus): void {
  sessionStorage.setItem(WRITE_GENERATION_STATUS_KEY, status); // ① 값 저장
  notifyGenerationStatusChange();                               // ② 알림
}

function notifyGenerationStatusChange(): void {
  window.dispatchEvent(new Event(GENERATION_STATUS_CHANGE_EVENT));
}

export function getGenerationStatus(): GenerationStatus | null {
  const raw = sessionStorage.getItem(WRITE_GENERATION_STATUS_KEY);
  ...
}

- dispatchEvent로 상태변경을 알리고 useGenerationStatus가 subscribe를 통해 그 신호를 읽도록 구현했습니다.

function subscribe(onStoreChange: () => void) {
  window.addEventListener(GENERATION_STATUS_CHANGE_EVENT, onStoreChange);
  return () => window.removeEventListener(GENERATION_STATUS_CHANGE_EVENT, onStoreChange);
}

function getSnapshot() {
  return getGenerationStatus(); // 클라이언트: sessionStorage 읽기
}

function getServerSnapshot() {
  return null; // 서버 + hydration 첫 렌더: 항상 null
}

export function useGenerationStatus() {
  return useSyncExternalStore(subscribe, getSnapshot, getServerSnapshot);
}

- 서버와 클라이언트 첫 렌더는 둘 다 null → "AI 글 생성하기"로 하였고 hydration 이후 getSnapshot()이 실제 값을 읽어 UI가 바뀝니다.

마치며

이번 에러를 통해 Hydration이 단순히 "서버 HTML에 이벤트 연결하는 것" 이상의 의미가 있다는 걸 체감했습니다.

서버와 클라이언트의 렌더링 결과가 반드시 일치해야 한다는 제약이 있고 sessionStorage처럼 브라우저에만 존재하는 API를 아무 생각 없이 쓰면 바로 터진다라는 것을 깨달았습니다..

useEffect로 빠르게 해결할 수도 있었지만 이번엔 useSyncExternalStore를 써보면서 외부 스토어를 React답게 구독하는 방법도 익혔다. 에러 하나가 꽤 많은 걸 알려주는 좋은 계기가 된거같습니다.

미들웨어(프록시)로 유연하게 처리 해보기

도니도니도니도니 — Sun, 21 Jun 2026 22:31:09 +0900

다시 한번

- 더 해빗(TheHabit)이라는 습관 형성 챌린지 서비스를 다시 만들면서 겪은 이야기입니다.

- 온보딩 페이지를 구현하면서 고려하지 못한 부분에 대해서 보완해보고자 프로젝트를 다시 시작했습니다.

- 과거에 왜 하지 않았을까 생각해봤을때 딱 아래 사진과 똑같았습니다.

- 예외 처리 혹은 다른 여러가지 상황을 고려하지 못했던거 같습니다.

- 일단 작동하니 넘겼던 과거를 후회하면서...

- 여러 예외 상황 등을 바로 잡아보고자 합니다.

과거의 구현이 어떻게 되었고 현재 어떻게 수정할지에 대해

// 쿠키를 날것으로 직접 읽었음
const token = req.cookies.get('next-auth.session-token')?.value;
console.log('pathname', pathname); // console.log도 남아있었음

if (token && pathname.startsWith('/onboarding')) {
  return NextResponse.redirect(new URL('/user/dashboard', req.url));
}
if (!token && pathname.startsWith('/user')) {
  return NextResponse.redirect(new URL('/login', req.url));
}

온보딩 컴포넌트
// 완료 기록 자체가 없었음
const handleNext = () => {
  if (currentStep < ONBOARDING_LIST.length - 1) {
    setCurrentStep(currentStep + 1);
  } else {
    router.push('/login'); // 그냥 로그인 페이지로 보냄
  }
};


const onboarding = req.cookies.get('onboarding')?.value;

if (onboarding === 'done' && isOnboardingPath) {
  // 근데 /dashboard 로 잘못 보내고 있었음 (버그)
  return NextResponse.redirect(new URL(token ? '/user/dashboard' : '/dashboard', req.url));
}

- 과거에 만든 미들웨어 코드입니다. 지금와서 보니 많이 아쉽습니다..

- 일단 가장 큰 문제는 쿠키 형식으로 구현했었는데 문제는 DB에 저장을 하지 않아 유저가 개발자라면 쿠키에 데이터를 삭제시키면 문제가 생길거 같습니다.

- 또하 경로또한 팀원들끼리 정했던 규칙에서 바뀌는 상황이 발생해 이를 또한 수정이 필요해 보입니다.

개선점 찾아보기

1. 일단 가장 먼저 온보딩했다고 토큰이나 불린 값으로 DB에 저장하기

2. 미들웨어 경로 다시 수정해서 지정하기

여기서 주의할 점
1. 일단 가장 먼저 온보딩했다고 토큰이나 불린 값으로 DB에 저장하기 -> 2가지를 상황을 가정해야 합니다.
a. 유저가 온보딩을 봤는데 로그인을 안했다면?
b. 유저가 로그인을 하지 않고 온보딩을 봤는데 로그인을 한다면 그때의 온보딩 처리

- 위와 같은 두가지 상황을 추가로 고려해서 생각해봤습니다.

두가지 해결해보자

// app/api/onboarding/complete/route.ts
export async function POST() {
  const session = await getServerSession(authOptions);

  // 로그인 유저면 DB에 저장 (다른 경로)
  if (session?.user?.id) {
    await supabase
      .from('users')
      .update({ onboarding_completed: true })
      .eq('id', session.user.id);

    return NextResponse.json({ redirectTo: '/user/dashboard' });
  }

  // ✅ 비로그인이면 쿠키를 심는다
  const response = NextResponse.json({ redirectTo: '/demo' });

  response.cookies.set('onboarding', 'done', {
    httpOnly: true,        // JS에서 접근 불가 (보안)
    secure: process.env.NODE_ENV === 'production',
    sameSite: 'lax',
    maxAge: 60 * 60 * 24 * 365, // 1년
    path: '/',
  });

  return response;
}

- 저는 다음과 같이 해결해봤습니다.

- 로그인을 한 유저가 온보딩을 완료시 : 기존 수퍼베이스 users 테이블에 온보딩을 완료하면 onboarding_completed : true로 DB에 저장을 하고 리다이렉트를 시켰습니다.

- 로그인을 하지 않은 유저가 온보딩을 완료시 : 쿠키에 onboarding:done 이라는 값을 넣고 온보딩을 한번 보면 더 이상 접근을 하지 않도록 쿠키에 데이터를 넣었습니다.

- 다음으로는 미들웨어 처리입니다.

// middleware.ts
export default async function middleware(req: NextRequest) {
  const token = await getToken({ req, secret: process.env.NEXTAUTH_SECRET });
  const onboardingCookie = req.cookies.get('onboarding')?.value;

  const isLoggedIn = !!token?.id;
  const hasGuestOnboardingCookie = onboardingCookie === 'done';

  // ✅ 핵심: 로그인 됨 + 쿠키 있음 → DB에 동기화
  if (isLoggedIn && hasGuestOnboardingCookie) {
    await syncGuestOnboardingToDb(token.id);
  }

  // ...이후 리다이렉트 로직
}

// libs/onboarding/onboarding.server.ts
export async function syncGuestOnboardingToDb(userId: string) {
  const supabase = getSupabaseAdmin();

  await supabase
    .from('users')
    .update({
      onboarding_completed: true,
      updated_at: new Date().toISOString(),
    })
    .eq('id', userId);
}

그리고 동기화 후 쿠키는 응답에서 삭제합니다.

// middleware.ts 의 respond 함수
const respond = (response: NextResponse) => {
  if (isLoggedIn && hasGuestOnboardingCookie) {
    response.cookies.delete('onboarding'); // ✅ 쿠키 삭제
  }
  return response;
};

// middleware.ts
// 로그인 됨 + 쿠키 있음 → DB에 동기화
if (isLoggedIn && hasGuestOnboardingCookie) {
  await syncGuestOnboardingToDb(token.id); // ← 이 부분
}

// libs/onboarding/onboarding.server.ts
export async function syncGuestOnboardingToDb(userId: string) {
  await supabase
    .from('users')
    .update({ onboarding_completed: true })
    .eq('id', userId);
}

// 과거
export const config = {
  matcher: ['/', '/user/:path*', '/onboarding/:path*'],
};

// 현재
export const config = {
  matcher: ['/', '/user/:path*', '/onboarding/:path*', '/login'],
};

- 미들웨어로 유저가 경로에 접근할려고 할때를 제어해봤습니다.

- 게스트 때 온보딩을 완료한 사용자가 나중에 로그인하면 미들웨어가 쿠키를 감지해서 DB에 자동으로 동기화하고 쿠키를 삭제합니다.

미들웨어 ??
- 미들웨어란 요청과 응답 사이에 끼어드는 코드라고 생각합니다.
- 이해는 되는데 이거를 왜 사용하는지는 예시를 봅시다.
미들웨어 없이 각 페이지에서 직접 처리하면 이렇게 됩니다.

// 모든 protected 페이지마다 이 코드가 반복됨
const { data: session } = useSession();

useEffect(() => {
  if (!session) router.replace('/login');
}, [session]);
- 아래 코드를 보면 세션으로 유저가 로그인했는지 파악하고 로그인이 안되어 있다면 UseEffect 안의 조건문이 실행되어 login으로 이동을 합니다.
- 여기서 하나의 문제가 발생하는데 우선 화면이 바로 이동하는게 아니라 리다이렉트가 일어나 화면이 나오고 그 다음 이동을 한다는 점입니다. 그리고 만약 위와 같이 다른 곳도 로그인이 되었는지 일일히 처리하기 위해서 위 코드를 반복적으로 호출해야 한다는 문제도 있습니다.
- 이때 미들웨어를 사용해서 처리하면 좋습니다.
- 하나 주의사항이 있는데 미들웨어는 기본적으로 matcher 경로를 따로 지정해주지 않으면 어떤 페이지에서든 미들웨어가 먼저 실행이 되어 성능의 저하가 생길수도 있습니다.
export const config = {
  matcher: ['/', '/user/:path*', '/onboarding/:path*', '/login'],
};
- 그래서 다음과 같이 특정 미들웨어가 필요한 경로에만 다음과 같이 작성해주는 것이 올바른 방법입니다.

마무리

작동은 했지만 구멍이 있던 코드를 다시 들여다보니 사실 당연히 고려해야 했던 상황들이었습니다. 이번 개선을 통해 온보딩 완료 여부를 DB와 쿠키 두 곳에서 관리하고 미들웨어 하나로 모든 경우를 제어하게 됐습니다. 다음엔 처음 설계할 때부터 이런 예외 상황을 먼저 생각해보려 합니다.

프로젝트를 다방면으로 생각해보기

도니도니도니도니 — Sun, 14 Jun 2026 11:41:33 +0900

다시 시작..

프로젝트를 구현하면서 기능을 완성하는 데 집중한 나머지 다양한 관점에서 충분히 고민하지 못했다는 것을 깨달았다.
구현이 끝나면 ‘이제 다 했다’는 안도감이 들었고 그 때문에 사용성이나 예외 상황 개선 가능성을 놓치기도 했다.
이번 기회를 통해 구현에서 끝나는 것이 아니라 완성 이후에도 더 나은 방향을 고민하는 습관을 만들어가고자 한다.

예외 상황 생각해보기

- 현재 상황을 다이어 그램으로 생각해 봤다.

- 간단하다 유저가 블로그 글 생성을 할때 나가면 api를 연결해서 데이터를 유지해서 db에 insert할지 아니면 네트워크를 abosrtController로 취소할지에 대한 그림이다.

AbortController로 진행 중인 저장 요청 취소하기 또는 글 생성 중 유저 이탈 시 안전하게 요청 취소하기

- 유저가 글 생성 취소할때 연결을 취소 시키는 방법이다. 흐름은 다음과 같다.

1. 글 생성 완료 → 자동으로 DB 저장 시도 (데이터 유지)
2. 저장 중 유저가 나가면 → AbortController로 취소 신호 (AbortSignal)
3. 이미 진행 중인 요청은 최대한 마무리

코드로 흐름을 보면

- 아래의 뒤로 가기 버튼이 클릭이 되면

import Link from "next/link";
import { ArrowLeft } from "lucide-react";

export default function GeneratingDraftHeader() {
  return (
    <header className="px-8 py-6 border-b border-navy-700 shrink-0">
      <div className="flex items-center gap-4">
        <Link
          href="/write"  // 단순히 /write로 이동
          className="flex items-center gap-2 text-slate-400 hover:text-white transition-colors">
          <ArrowLeft size={20} />
          <span>뒤로 가기</span>
        </Link>
        <div className="h-6 w-px bg-slate-600" />
        <h1 className="text-xl font-semibold text-white">AI 블로그 생성</h1>
      </div>
    </header>
  );
}

- 자동으로 저장되도록 구현한 코드를 signal을 통해 신호 응답에 따라 제어를 했다.

- AbortController를 선언하고 ref를 사용해서 컴포넌트 언마운트시 클린업 함수를 통해 자동으로 취소 되도록 구현했다.

activeSaveAbortRef.current?.abort(); -> abort()함수가 요청을 취소 시키는 함수다.

// 진행 중인 저장 API 호출을 추적하는 ref
const activeSaveAbortRef = useRef<AbortController | null>(null);

useEffect(() => {
  return () => {
    // 컴포넌트 언마운트 시 자동 취소
    activeSaveAbortRef.current?.abort();
  };
}, []);

// 자동 저장 시작
const controller = new AbortController();
activeSaveAbortRef.current = controller;

const { postId } = await saveGeneratedArticle(
  article,
  payload.selectedTemplate,
  { signal: controller.signal }  // ← 신호 전달
);

- 다음으로 ai한테 api 요청을 하는 작업을 중단시켜야 한다.

useEffect(() => {
  if (!payload) {
    setError("작성 정보가 없습니다.");
    setIsGenerating(false);
    return;
  }

  const controller = new AbortController();  // fetch 신호 생성
  
  const run = async () => {
    try {
      const res = await fetch(aiEndpoint(), {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify(payload),
        signal: controller.signal,  // ← fetch 요청에 신호 연결
      });
      
     
      // ... 처리
    } catch (err) {
      if (isAbortError(err) || controller.signal.aborted) return;
      // AbortError는 무시 (정상적인 취소)
      setError(/* 실제 에러만 처리 */);
    }
  };

  run();

  return () => controller.abort();  // ← 언마운트 시 요청 취소
}, [payload, templateKey]);

정리

사용자가 "뒤로 가기" 클릭
↓
Next.js에서 /write 페이지로 네비게이션
↓
GeneratingDraft 컴포넌트 언마운트 (리액트 라이프사이클)
↓
useGeneratingDraft의 cleanup 함수 실행
│
├─ activeSaveAbortRef.current?.abort()
│ └─ saveGeneratedArticle의 fetch 요청 취소
│
└─ useArticleGeneration의 cleanup 함수 실행
└─ controller.abort()
└─ AI API (Gemini/OpenAI) fetch 요청 취소
↓
모든 진행 중인 요청 중단
↓
상태 업데이트 안 됨 (isAbortError로 필터링)
↓
/write 페이지 렌더링

- 또한 현재 코드로만 보면 어떤 효과가 있는지 알고싶어 실제 openai 코드의 토큰 사용량을 비교해봤다. 우선 만약 abortController가 없을시에는 기존 토큰에서 600토큰 가량을 낭비하게 되지만, 이를 abortController를 사용하니 800토큰 만큼의 낭비를 줄일 수 있게 되었다.

2번째 시나리오 유저가 글쓰는 사이트를 나가거나 닫아도 유지해서 보여주기

- 유저가 시도할만한 것들을 막아보자

1. 유저가 뒤로가기 했을때 데이터 유지

2. 유저가 경로를 강제로 쳤을때의 예외처리

유저가 뒤로가기를 한다면??

- 유저가 뒤로가기를 했을때 고려해볼만한 문제는 아무런 예외처리를 토큰이 낭비하는 문제를 발견했다.

- 이를 해결해보고자 세션 스토리지에 상태를 넣어 이를 가져와 상태에 따라 유저가 생성하기 버튼을 클릭해도 값을 재생성하지 못하도록 막아보았다.

export function setGenerationStatus(status: GenerationStatus): void {
  if (typeof window === "undefined") return;
  sessionStorage.setItem(WRITE_GENERATION_STATUS_KEY, status);
  notifyGenerationStatusChange();
}

- 우선 간단하게 세션 스토리지에 위와 같이 만들어 상태 값을 넣어서 제어를 해보고자 했다.

- 저 status의 상태는 크게 3가지로 나눴다.export type GenerationStatus = "generating" | "done" | "error";

- generating일때 뒤로가기를 눌렀을때 세션 스토리지의 상태 값을 가져와 상태에 따라 경로 리다이렉트와 버튼text를 다르게 보여수정해봤다. 왼쪽 버튼이 스토리지에 값이 없을때이고 스토리지에 generating이면 생성화면이 나오도록 수정했다.

스토리지 상태 값

유저가 경로를 강제로 리다이렉트 한다면?

- 우선 가장 먼저 떠오른 것은 Next.js의 미들웨어로 처리하는 방법이 먼저 떠올랐다.

- 현재 Next.js 에서 proxt.ts로 미들웨어 이름이 변경이 되었기 때문에 이에 맞게 수정을 했다.

- 우선 기존 세션 스토리지에 값을 넣어놨기때문에 이를 활용해보고자 했다.

여기서 문제점 미들웨어는 세션스토리지에 접근을 못한다... 그래서 이를 해결해보고자 쿠키에 직접 데이터를 넣어 해결해보고자 했다.
쿠키는 요청할때마다 서버로 데이터가 직접 가기 떄문에 쿠키를 사용했다.

function guardGeneratingPage(req) {
  if (pathname !== "/write/generating") return;  // 다른 경로는 무시
  const hasEntry = req.cookies.get("write-generating-entry")?.value === "1";
  if (!hasEntry) {
    return redirect("/write");   // ❌ 쿠키 없음 → 차단
  }
  const res = next();
  clearGeneratingEntryCookie(res);  // ✅ 통과 후 쿠키 삭제 (1회용)
  return res;
}

- 그래서 위오같이 쿠키에 임시 토큰 1을 넣어 이를 통해 유저가 특정 경로로 들어오면 들어오지 못하도록 막았다.

⚡️ 토큰 제어??
버튼 누를 때 쿠키 넣고 → 첫 입장 때 proxy가 확인 후 바로 삭제
- 위 플로우를 만들면 경로를 다시 재 진입할때 쿠키에 데이터가 없어 미들웨어를 통해 경로 보호가 된다고 생각이 들었고 현재 잘 작동이 된다.

아직 해결해야할 숙제

- 새로고침하면 쿠키가 삭제되는데 이를 어떻게 방지할지 좀 생각해봐야겠다

- 그리고 추가로 세션 스토리지 방식은 보안 적인 측면이나 많은 문제가 생길수 있어 db에 데이터를 저장시켜 이를 보완해보고자 한다.

결론

- 항상 한 방법으로만 생각해보지 말자. 프로젝트 개선할 사항은 정말 무궁무진하다는 것을 깨달았다.

클라이언트 중복 방어의 한계와 서버 이중 방어 — isSubmitting부터 idempotency key까지

도니도니도니도니 — Sun, 7 Jun 2026 19:05:59 +0900

배경

피드백 생성 기능을 구현하면서 한 가지 문제를 발견했다.

사용자가 버튼을 빠르게 여러 번 클릭하면 GPT API 호출이 그 횟수만큼 전송됐다. API 비용은 호출 횟수에 비례하고 동일한 피드백이 여러 번 생성되면 DB도 오염되어 막아야 했다.

1차 시도 — isSubmitting으로 클라이언트 방어

가장 먼저 떠오른 건 버튼 상태 관리였다. API 호출 중에는 버튼을 비활성화하면 중복 클릭 자체를 막을 수 있다.

const [isSubmitting, setIsSubmitting] = useState(false);

const handleGenerate = async () => {
  if (isSubmitting) return;
  setIsSubmitting(true);
  try {
    await generateFeedback();
  } finally {
    setIsSubmitting(false);
  }
};

<button disabled={isSubmitting} onClick={handleGenerate}>
  피드백 생성
</button>

UI 레벨에서는 깔끔하게 막혔다. 하지만 구현 직후 한 가지 의문이 생겼다.

한계 발견 — 네트워크 탭으로 우회 가능

브라우저 개발자 도구 네트워크 탭에서 요청을 직접 복사해 재전송하면 isSubmitting 상태와 무관하게 서버로 요청이 전달된다. 클라이언트 방어는 어디까지나 UI 레벨의 방어다. 서버 입장에서는 어디서 온 요청인지 알 수 없다.

즉, 클라이언트 방어만으로는 완전하지 않다.

2차 방어 — 서버에서 DB 체크

서버에서도 방어 로직을 추가했다. 피드백 생성 요청이 들어오면 DB에 해당 챌린지의 피드백이 이미 존재하는지 먼저 확인한다. 있으면 GPT를 재호출하지 않고 기존 데이터를 그대로 반환한다.

// 서버 API route
const existing = await db.feedback.findFirst({
  where: { challengeId },
});

if (existing) {
  return Response.json({ feedback: existing });
}

// 없을 때만 GPT 호출
const feedback = await generateWithGPT(routineData);
await db.feedback.create({ data: { challengeId, ...feedback } });';

이렇게 하면 클라이언트를 우회해 요청이 들어와도 GPT가 중복 호출되지 않는다.

개념 정리

이중 방어란? 클라이언트와 서버 양쪽에 각각 독립적인 방어 로직을 두는 패턴이다. 클라이언트 방어가 뚫려도 서버에서 한 번 더 걸러낸다. 어느 한쪽만 믿지 않는다는 원칙이다.

idempotency key란? 동일한 요청을 여러 번 보내도 결과가 한 번만 처리되도록 보장하는 고유 키다. 클라이언트가 요청 시 UUID 같은 고유값을 헤더에 담아 보내고 서버는 이 키를 기준으로 이미 처리된 요청인지 판단한다.

// 클라이언트
const idempotencyKey = crypto.randomUUID();

await fetch('/api/feedback', {
  method: 'POST',
  headers: {
    'Idempotency-Key': idempotencyKey,
  },
});

// 서버
const key = request.headers.get('Idempotency-Key');
const processed = await db.idempotencyKeys.findFirst({ where: { key } });

if (processed) {
  return Response.json({ feedback: processed.result });
}

회고

isSubmitting으로 클라이언트 방어를 구현했을 때 처음엔 충분하다고 생각했다. 그런데 네트워크 탭을 직접 조작하면 우회가 가능하다는 걸 깨닫고 나서 방어의 범위를 다시 생각하게 됐다.

클라이언트 방어는 사용자 경험을 위한 것이고 서버 방어는 데이터 무결성을 위한 것이다. 둘은 목적이 다르고 역할도 다르다. 어느 한쪽만으 로는 완전하지 않다.

다음에 유사한 기능을 구현한다면 idempotency key(멱등성 키) 도입을 진지하게 고려할 것 같다.

AbortController 도입시도

도니도니도니도니 — Mon, 1 Jun 2026 20:57:23 +0900

프로젝트 문제점

- 항상 프로젝트에는 새로운 문제점이 생긴다.

문제 정의

- 문제점은 클라이언트 측에서 블로그 글 생성 -> 취소 할때의 문제가 있었다.

문제 해결 시도하기

- 클라이에서 블로그 글 생성 -> 취소 할때의 문제가 뭔지를 우선 정의했다.

흐름은 다음과 같다.
1. 사용자가 블로그 글을 생성한다.
2. 갑자기 사용자가 블로그 글을 취소해버리거나 뒤로 가기를 눌러버린다.
3. 내가 구현한 코드에는 취소나 뒤로가기를 누르면 그대로 AI API 요청을 보낸다.

- 위와 같은 문제를 나는 클라이언트 측에서 AbortController를 활용해서 비동기 작업을 취소해보도록 했다.

AbortController ?

- AbortController란 현재 진행중인 비동기 작업을 취소할수 있게 해주는 Web 표준 Api라고 한다.

const controller = new AbortController();

controller.signal  // 취소 신호를 감지하는 객체
controller.abort() // 취소 신호를 발생시키는 함수

- 사용법은 간단하게 new 키워드로 AbortController를 선언하면 된다.

Signal 객체는 취소 신호를 감지하는 객체이고, abort() 함수를 호출하면 그 즉시 비동기 작업이 취소가 된다고 한다.

일단 뭔지는 이해했는데 언제 주로 사용할까??

useEffect(() => {
  fetch("/api/gemini", { body: JSON.stringify(payload) })
    .then(res => res.json())
    .then(data => setArticle(data)); // 문제 발생 가능
}, [payload]);


//AbortController 사용
useEffect(() => {
  const controller = new AbortController();

  fetch("/api/gemini", { signal: controller.signal });

  return () => controller.abort(); // 네트워크 요청 자체를 끊음
}, [payload]);

- 위 코드를 봐보자 나는 현재 fetch 함수로 Next.js 서버로 gemini API로 요청을 보냈다. 이때 만약 유저가 뒤로가기를 누르거나 탭을 꺼버린다면 위 요청은 취소가 되어야 한다.

- 이때 AbortController를 사용한다. 흐름을 보면 아래와 같다.

- fetch는 Web 표준 API라 Signal을 보고 스스로 멈추는데 이를 활용해서 Payload의 값이 변경이 되면 CleanUp 함수가 먼저 실행되어 취소가 되도록 유도하는 방법이다.

fetch가 signal 감시 중
    ↓
signal.aborted = true 감지
    ↓
fetch 내부에서 AbortError throw
    ↓
요청 중단

해결방법( 2. 갑자기 사용자가 블로그 글을 취소해버리거나 뒤로 가기를 눌러버린다.)

- 위 개념을 알고 이제 문제를 해결해보고자 했다.

 useEffect(() => {
    if (!payload) {
      setError("작성 정보가 없습니다.");
      setIsGenerating(false);
      return;
    }

    const controller = new AbortController();
    setArticle(null);
    setError("");
    setIsGenerating(true);

    const run = async () => {
      try {
        const res = await fetch(aiEndpoint(), {
          method: "POST",
          headers: { "Content-Type": "application/json" },
          body: JSON.stringify(payload),
          signal: controller.signal,
        });

        if (!res.ok) {
          const json = (await res.json().catch(() => ({}))) as {
            error?: string;
          };
          throw new Error(json.error ?? `HTTP ${res.status}`);
        }

        const parsed = (await res.json()) as ArticleGenerationResponse;
        setArticle({
          title: parsed.title,
          content: String(parsed.content ?? ""),
          keywords: Array.isArray(parsed.keywords)
            ? parsed.keywords.map(String)
            : [],
          template: templateKey,
        });
      } catch (err) {
        if (controller.signal.aborted) return;
        setError(
          err instanceof Error ? err.message : "글 생성에 실패했습니다."
        );
      } finally {
        if (!controller.signal.aborted) {
          setIsGenerating(false);
        }
      }
    };

    run();

    return () => controller.abort();
  }, [payload, templateKey]);

  return { article, error, isGenerating };

- 코드가 길지만 컨트롤러만 우선 보면 aiEndPoint()함수는 gemini한테 블로그 글을 작성해서 나한테 보내달라고 하는 api 요청 함수인데 유저가 뒤로 가기를했을때 혹은 페이지를 나갔을때 clenaup함수를 사용해 다음과 같은 문제를 방지하고자 했다.

하지만 문제가 있었다. 연결이 사실 2개였던 것이다.
[브라우저] ──①──▶ [Next.js /api/gemini] ──②──▶ [Gemini]
나는 ①번 연결만 끊으면 된다고 생각했지만, ②번 연결은 별개의 HTTP 요청이라 클라이언트가 abort()를 해도 Next.js → Gemini 호출은 그대로 진행되고 있었다.

즉 클라이언트가 나가도 서버는 Gemini 응답을 끝까지 기다리고 있는 상태였다.

또 다른 문제는 SDK는 AbortController를 지원하지 않는다는 점이었다. 나는 이를 해결하고자 fetch로 직접 호출을 시도했다.

정리

AbortController는 신호를 보내는 것일 뿐 받는 쪽이 직접 처리해야 한다.

fetch는 signal을 내장 지원하지만 SDK는 지원하지 않을 수 있다.

연결이 여러 개라면 각 연결마다 signal을 직접 연결해줘야 한다.

React Activity?

도니도니도니도니 — Thu, 12 Mar 2026 18:47:08 +0900

React 렌더링

Activity 컴포넌트를 이해하기 전에 먼저 React에서 상태 업데이트가 어떻게 이루어지고 왜 리렌더링이 발생하는지 이해할 필요가 있다.

React 공식 문서에서는 Activity가 hidden 상태일 때 렌더링을 수행하지 않는다고 설명하고 있기 때문에, 이를 이해하기 위해 먼저 React의 기본 렌더링 과정을 살펴보았다.

예를 들어 다음과 같은 코드가 있다고 하자.

function App() {
const [count, setCount] = useState(0);

return (
<button onClick={() => setCount(count + 1)}>
클릭
</button>
);
}

버튼을 클릭하면 setCount가 호출되고 React는 다음과 같은 과정을 통해 UI를 업데이트한다.

setState
↓
updateQueue에 update 추가
↓
render phase 시작
↓
컴포넌트 함수 실행
↓
새로운 UI 계산
↓
Reconciliation (이전 UI와 비교)
↓
commit phase
↓
DOM 업데이트

Reconciler와 Reconciliation

위 과정에서 중요한 부분은 Reconciliation(재조정) 단계이다.

React는 이전 UI와 새로운 UI를 비교하여 어떤 부분이 변경되었는지 판단하고 필요한 부분만 DOM을 업데이트한다.

이 작업을 수행하는 것이 Reconciler이며, 이 과정에서 React는 Fiber Tree라는 자료구조를 사용한다.

Fiber Tree

Fiber Tree는 React가 컴포넌트 구조를 관리하기 위해 사용하는 내부 트리 구조이다.

각 컴포넌트는 하나의 Fiber Node로 표현되며, 다음과 같은 정보가 저장된다.

type → 컴포넌트 타입
props → 전달된 props
memoizedState → 현재 state
child → 첫 번째 자식 노드
sibling → 형제 노드
return → 부모 노드

예를 들어 다음과 같은 컴포넌트 구조가 있을 때

<App>
<Header />
<Content />
</App>

React 내부에서는 다음과 같은 Fiber Tree가 만들어진다.

Fiber(App)
 ├ Fiber(Header)
 └ Fiber(Content)

상태 업데이트가 발생하면

setState가 호출되면 React는 바로 state를 변경하지 않고 먼저 updateQueue에 상태 변경 요청을 저장한다.

예를 들어 다음과 같은 상태가 있다고 하자.

function App() {
const [count, setCount] = useState(0)
const [name, setName] = useState("A")
}

React 내부에서는 Hook 상태가 다음과 같이 관리된다.

Fiber(App)
 memoizedState
 ↓
 Hook1
 state = 0
 next →
 Hook2
 state = "A"

이때 count를 증가시키는 함수가 호출되면

setState 호출
↓
updateQueue에 update 추가
↓
render phase에서 updateQueue 처리
↓
새로운 state 계산
↓
memoizedState 업데이트

이 과정에서 React는 새로운 Fiber Tree(workInProgress)를 생성한다.

Fiber Tree 비교

React는 상태 업데이트가 발생하면

current Fiber Tree
VS
workInProgress Fiber Tree

를 비교한다.

이 비교 과정이 바로 Reconciliation이며, 이를 수행하는 것이 Reconciler이다.

구조는 다음과 같다.

React
└ Fiber Tree
 └ Fiber Node
 ├ memoizedState
 ├ updateQueue
 └ hooks

왜 Fiber Tree를 두 개 유지할까?

React 내부에는 두 개의 Fiber Tree가 존재한다.

current Fiber tree
workInProgress Fiber tree

current → 현재 화면에 렌더링된 UI 상태
workInProgress → 다음 UI 상태를 계산하는 트리

렌더링 과정은 다음과 같이 진행된다.

render phase
current ───────────► workInProgress
▲ │
│ │
└────── commit ────────┘

React는 workInProgress tree에서 새로운 UI를 계산한 뒤 commit 단계에서 current tree와 교체한다.

이 구조 덕분에

렌더링 도중 오류가 발생해도 기존 UI는 유지되고
계산이 완료된 결과만 DOM에 반영되기 때문에

UI 업데이트가 안정적으로 이루어질 수 있다.

React Activity

- React Activity는 새롭게 추가된 컴포넌트로 컴포넌트를 "숨김 상태로 유지하면서" 상태를 보존한다고 한다.

- 보통 React에서 버튼을 클릭하면 state 상태가 변경이 되어, 리렌더링이 발생한다.

- 하지만 Activity의 경우는 unmount 되지 않아 리렌더링이 발생하지 않는다

<Activity mode="hidden">
  <ChatPanel />
</Activity>

Activity가 어떻게 리렌더링이 일어나지 않도록 할까

- Activity가 리렌더링을 하지 않는 이유를 간단히 말하면 일종의 스킵을 통해 리렌더링을 하지 않는다.

- 보통의 상태 업데이트가 일어난다면 아래와 같이 일어나지만, React Activity는 다르다.

setState
↓
updateQueue에 update 추가
↓
render phase 시작
↓
컴포넌트 함수 실행
↓
새 Fiber 생성
↓
Reconciliation
↓
commit phase
↓
DOM 업데이트

- React는 memoizedState를 통해 visible한 상태인지 hidden 상태인지를 관리한다고 한다.

- 다시 React 동작원리를 보면 리액트에서 렌더링은 아래와 같이 렌더단계에서 내부에서는 Fiber를 하나씩 순회하며 렌더링 작업을 수행한다고 한다.

- React는 memoizedState를 통해 Offscreen Fiber가 visible 상태인지 hidden 상태인지 관리한다.

memoizedState === null → visible
memoizedState !== null → hidden

- Activity가 hidden 상태가 되면 React는 해당 Fiber의 memoizedState에 OffscreenState 객체를 저장한다.

Fiber(Activity)
   │
   └ Fiber(Offscreen)
        memoizedState = OffscreenState (hidden)
        │
        └ Fiber(ChatPanel)

App
├ Header
├ Activity
│  └ ChatPanel
│     ├ MessageList
│     └ Input
└ Footer

Activity는 Offscreen Fiber로 구현되며, hidden 상태일 때 memoizedState에 OffscreenState가 저장된다. React는 이를 통해 hidden 상태를 판단하고 subtree 렌더링을 스킵하지만, Fiber 구조 자체는 유지되기 때문에 subtree는 제거되지 않는다.

Activity 사용은 그러면 언제?

- 뭐 대충 Activity가 이전값을 memoziedState에 OffsreenState에 저장되어 Fiber노드가 유지되어 유지가 된다는거는 알겠는데 이거를 언제 써야 잘 썼다고 소문이 날까?

- 유튜브나 강의를 보면 Activity를 상태 조건에 따라 컴포넌트 렌더링 되는 모달? 같은 경우 사용하면 무작정 좋다고 하는데 이거는 아닌거 같다.

- 나도 처음은 그냥 오 편하고 좋네? 이 생각으로 있는 모달 모두 Activity처리헀는데 생각을 조금만 해보니 오히려 문제가 있을수도 있지 않을까? 생각이 들었다. 뭐 예를들어 잠깐 보여주는 모달 toast나 그런것들 까지 굳이?? 오히려 저 상태값을 저장하고 있는 메모리한테 미안하다 라는 생각이 들었다.

- 그래서 올바르게 사용하고자 한다면 유지가 되어야하는 유저 정보를 보여주는 모달? 같은 거나? 댓글모달 아니면 회원가입할때 유지되어야 하는 상태일때 사용하면 좋을거 같다.

회원가입 단계형 모달
결제 단계 모달

- 사람들이 그냥 좋다고 하는 것에는 항상 나쁜점도 있는거 같다. 항상 잘 알아보고 적절할때 스킬을 사용하면 더 멋진 개발자가 되지 않을까 생각이 들었다.

쿠키, 세션, 스토리지

도니도니도니도니 — Sat, 6 Dec 2025 20:12:58 +0900

✅ React에서 데이터 저장 방식 정리

1) React의 상태(state)와 한계

React는 컴포넌트 내부의 state로 화면에 필요한 데이터를 관리한다.
setState가 호출되면 상태가 업데이트되고 UI는 자동으로 다시 렌더링된다.

하지만 state는 컴포넌트 메모리에 존재하는 일시적인 값이기 때문에:

페이지 새로고침
컴포넌트 언마운트(페이지 이동)

와 같은 상황에서 초기값으로 리셋된다.

중요!!
state는 “리렌더링” 때문에 사라지는 것이 아니다.
사라지는 이유는 오직 새로고침 또는 언마운트 때문.

따라서 로그인 정보처럼 지속되어야 하는 값은 state만으로 유지할 수 없다.

2) 지속적으로 유지해야 하는 데이터는 브라우저 저장소에 저장

페이지 이동, 새로고침, 앱 재실행 후에도 유지해야 하는 데이터는
React state가 아닌 브라우저 저장소에 저장해야 한다.

대표적인 저장 방식은 다음과 같다.

Cookie (쿠키)
localStorage
sessionStorage

이 저장소들은 컴포넌트 생명주기와 상관없이 브라우저에 남아 있기 때문에
새로고침 또는 컴포넌트 이동이 발생해도 데이터가 유지된다.

3) 쿠키(Cookie)와 세션(Session)

✔ 쿠키

쿠키는 브라우저와 서버가 정보를 교환하기 위해 사용하는 작은 데이터 저장공간이다.

쿠키 특징

브라우저가 서버에 요청을 보낼 때 자동으로 포함된다.
도메인 단위로 저장되며, 다른 도메인에는 전송되지 않는다.
브라우저마다 서로 다른 저장공간을 사용한다.
(Chrome 쿠키 ≠ Safari 쿠키)
max-age, expires로 유효기간 설정 가능.

쿠키의 문제점

쿠키는 기본적으로 JS에서 읽을 수 있기 때문에:

document.cookie

이 코드로 브라우저에 저장된 쿠키를 그대로 읽을 수 있다.

따라서 쿠키에 로그인 정보 같은 민감한 데이터를 직접 저장하면
삭제·수정·탈취(XSS)에 취약해진다.

✔ 세션(Session)

세션은 사용자 정보를 쿠키에 직접 저장하지 않기 위한 인증 방식이다.

세션 동작 방식

사용자가 로그인하면 서버가 세션 ID를 생성한다.
실제 사용자 정보는 서버 내부(세션 저장소)에 저장한다.
브라우저에는 세션 ID만 쿠키에 저장한다.
브라우저는 요청마다 세션 ID를 자동 전송한다.
서버는 세션 ID를 기반으로 사용자 정보를 조회한다.

즉, 민감한 정보는 브라우저가 아닌 서버가 보관하기 때문에 안전하다.

4) XSS와 CSRF (쿠키가 취약한 이유)

✔ XSS (Cross-Site Scripting)

악성 스크립트가 웹페이지에서 실행되는 공격.
document.cookie로 쿠키를 탈취할 수 있다.

해결:
HttpOnly 옵션을 설정하면 JS로 쿠키를 읽을 수 없게 된다.

✔ CSRF (Cross-Site Request Forgery)

쿠키가 자동 전송되는 특성을 이용하여
사용자가 의도하지 않은 요청을 서버로 보내는 공격.

예:

로그인 쿠키가 자동 전송 → 서버는 정상 요청으로 착각.

해결:

쿠키에 SameSite 옵션 설정
CSRF Token 사용

5) localStorage / sessionStorage

✔ localStorage

브라우저에 영구적으로 저장되는 데이터
새로고침 / 탭 닫기 / 브라우저 종료 후에도 유지
서버로 자동 전송되지 않음
JS로 접근 가능 → XSS 취약

사용 예:
다크모드 설정, 비로그인 장바구니, 사용자 환경설정 등

✔ sessionStorage

탭 단위로 저장되는 데이터
탭을 닫으면 삭제됨
다른 탭과 공유되지 않음
서버로 자동 전송되지 않음
JS로 접근 가능 → XSS 취약

사용 예:
회원가입 단계(step form) 임시 저장, 페이지 이동 중 임시 데이터

최종 요약

React의 state는 컴포넌트 메모리에 존재하기 때문에 새로고침 또는 언마운트 시 사라진다.

지속되어야 하는 데이터는 브라우저 저장소(Cookie, localStorage, sessionStorage)에 저장해야 한다.

쿠키는 서버와 자동으로 데이터를 주고받는 저장소지만, JS로 접근 가능한 특성 때문에 XSS와 CSRF에 취약할 수 있다. 이를 해결하기 위해 HttpOnly, SameSite 옵션을 사용한다.

세션은 사용자 정보를 서버에 저장하고, 쿠키에는 세션 ID만 저장하는 구조로 쿠키의 보안 문제를 해결하며 안전하게 인증 상태를 유지할 수 있게 한다.

localStorage는 브라우저에 영구 저장되고, sessionStorage는 탭 단위로 관리된다. 두 저장소 모두 서버에 자동 전송되지 않기 때문에 UI 상태나 임시 데이터 저장에 적합하다.

React 딥다이브

도니도니도니도니 — Mon, 20 Oct 2025 14:10:06 +0900

React hook 알아보기

useCallback

useMemo가 값을 기억했다며느 useCallbak은 인수로 넘겨받은 콜백 자체를 기억한다.
즉 useCallback은 특정 함수를 새로 만들지 않고 다시 재사용한다는 의미이다.

음 솔직히 뭔지 모르겠다 ... 예시를 보자아

✅ 확인하고 넘어가기
- React에서 리 렌더링이 일어나면 함수가 다시 만들어지고 다시 실행이 된다. -> 이로 인해 함수 내부 변수가 함수 등이 다른 메모리 주소를 가르킨다.

"use client";

import { useEffect, useState } from "react";

export default function SignupPage() {
  const [step, setStep] = useState(1);

  const onClick = () => {
    setStep(step + 1);
  };

  useEffect(() => {
    console.log("click");
  }, [onClick]);

  return (
    <div>
      {step}
      <button onClick={onClick}>next</button>
    </div>
  );
}

다음과 같은 예제를 보자 버튼을 클릭하면 onClick 함수가 실행이 된다. 그로 인데 setState 상태가 변경이 되어 리액트가 리렌더링을 일으킨다.
리렌더링이 일어나니 컴포넌트 내부에 있는 모든 변수, 함수가 다시 생성되고 실행된다. 이로 인해 버튼을 클릭하면 click이라는 콘솔이 나오게 된다. 그렇다면 실행이 되지 말아야 하는 함수의 경우 메모이제이션이 필요하지 않을까??? 해서 나온것이 useCallback이다.

"use client";

import { useCallback, useEffect, useState } from "react";

export default function SignupPage() {
  const [step, setStep] = useState(1);

  const onClick = useCallback(() => {
    setStep(step + 1);
  }, [step]);

  useEffect(() => {
    console.log("click");
  }, [onClick]);

  return (
    <div>
      {step}
      <button onClick={onClick}>next</button>
    </div>
  );
}

useCallback은 다음과 같이 사용하면 된다. 의존성 배열의 값이 변경이 되면 메모이제이션이 된 onClick 함수가 실행이 된다. 음 근데 결국 똑같이 버튼 클릭하면 리렌더링 발생하는거자나???? 맞긴하다. 하지만 다른 예제를 보면 왜 사용하면 좋은지 알 수 있다.

"use client";

import { useCallback, useState } from "react";

function Child({ onClick }: { onClick: () => void }) {
  console.log("  자식 리렌더링");
  return <button onClick={onClick}>자식 버튼</button>;
}

export default function SignupPage() {
  const [count, setCount] = useState(0);

  // ❌ 리렌더링될 때마다 새로운 함수가 생성됨
  const handleClick = useCallback(() => {
    console.log("clicked");
  }, []);

  console.log("  부모 리렌더링");

  return (
    <div>
      <p>count: {count}</p>
      <button onClick={() => setCount(count + 1)}>부모 버튼</button>
      <Child onClick={handleClick} />
    </div>
  );
}

위예제를 보면 부모 컴포넌트가 자식 컴포넌트한테 onClick이라는 props를 전달해서 자식 컴포넌트가 이를 사용중인데, 부모 컴포넌트가 리렌더링이 발생하면 자식 컴포넌트 또한 강제로 리렌더링이 되는 것을 볼 수 있다.
이유는 부모컴포넌트의 setCount로 인해 상태 변경이 되어 전체 리렌더링이 발생하는데 자식 또한 props가 변경되었다고 판단해 리렌더링이 발생한다. 이를 useCallback을 쓰면 음 근데 부모 리렌더링 이랑 자식 리렌더링 둘다 발생하는데 ???

useCallback
- useCallback은 함수 주소를 고정시켜주는 것이지, 리렌더링 방지하는 기능은 따로 없다는 것을 알았다...
- 위 원인을 찾아보니 결국 props의 값이 변경이 되지 않더라도 부모 컴포넌트가 리렌더링이 발생하니 같이 리렌더링이 발생하는 것이었다...
이를 통해 useCallback은 함수 메모리 주소를 고정시켜주지만, 결국 리렌더링이 일어난다는 것을 알게되었다...
해결방안은 의존성 배열에 따라 리렌더링 되도록 하는 것이 useCallback을 유연하게 사용하는 것이다

useCallback + React.memo

두 훅을 같이 사용하면 최적화하는데 도움이 될거 같다. useCallback은 함수의 참조 값을 고정시키고 React.memo는 props를 비교해 같다면 리렌더링을 방지하니 이 둘을 혼합해서 사용해보자

useRef

useRef는 useState와 비교할 때 컴포넌트 내부에서 렌더링이 일어나도 변경 가능한 상태값을 저장하고 있다. 하지만 2가지 차이가 있다.
- useRef는 반환값인 객체 내부에 있는 current로 값에 접근 변경할 수 있다
- useRef는 그 값이 변하더라도 렌더링을 발생시키지 않는다.
여기서 알 수 있는 점은 useRef는 값의 변경이 일어나도 리렌더링이 발생하지 않는다는 것이다.
보통 useRef는 검색 엔진을 최적화할때 사용하면 좋을거 같다.
- ⚠️ 여기서 주의할 점은 리렌더링이 발생하지 않아 화면상에는 변경점을 찾아볼 수 없다는 것이다.

프로젝트를 하면서 고민점들 (라우팅 렌더링)

도니도니도니도니 — Sat, 18 Oct 2025 22:22:06 +0900

페이지 이동시 리렌더링이 발생하는 문제

개발 중 헤더의 li를 클릭하면 링크는 잘 이동되지만, active 표시가 되지 않는 문제가 발생했다.

이유가 뭘까 state가 왜 초기화 되는지 찾아보자
우선 가설을 세웠다.
- 라우팅이 된 후 active가 안되는 것이니 Next.js의 문제인가
- 그래서 Header의 라우팅이 현재 어떻게 되었는지 찾아보자
app/
├── layout.tsx
├── page.tsx
├── _components/
│   ├── Header/
│   │   └── Header.tsx
│   └── layout/
│       └── LayoutProvider.tsx
└── globals.css
현재 나의 헤더는 layout에 LayoutProvider 컴포넌트를 감싸서 페이지 마다 다른 레이아웃을 적용시키기 위해서 분리 했다
현재 나는 LayoutProvider를 Server Component로 했다. Next.js를 찾아보니 Segment 단위 서버 렌더링을 한다고 한다. 이게 원인거 같다.
Segment는 단위 서버 렌더링은 경로 이동 ex) / -> /about 으로 이동하면 서버 컴포넌트를 새로 렌더링해서 스트리밍을 한다고 한다.
이로 인해 경로 이동을 하게 되면 서버 컴포넌트안에 Header가 있기 때문에 리 렌더링이 되는 것 같다.

해결방안

간단한 방안은 usePathname()을 사용하는 것이다.
변경 전 코드는 li를 클릭하면 setStatus로 이름을 넣어 업데이트 시켜 그와 일치하면 스타일을 주는 것을 만들었었다.

const [status, setStatus] = useState("default");
const handleStatus = (name: string, href: string) => {
  setStatus(name);
  if (name === "사부작 게시판") {
    setIsOpen(true);
  } else {
    setIsOpen(false);
  }
  if (href) {
    router.push(href);
  }
};

<li
  key={item.id}
  onClick={() => handleStatus(item.name, item.href)}
  className={
    status === item.name
      ? styles.navLinkItemLinkActive
      : styles.navLinkItemLink
  }
>
  {item.name}
</li>

usePathname
- usePathname은 현재 URL 경로를 읽는 클라이언트 전용 훅이다.
- usePathname은 클라이언트 쪽에서 관리를 하기 때문에, 페이지 이동시 리렌더링이 발생은 하지만, 컴포넌트 자체가 다시 생성은 되지 않아 위의 문제점을 해결할 수 있다.

다른 해결 방안

client component로 ??

뭔가 가장 먼저 떠오른 방법은 LayoutProvider.tsx를 client 컴포넌트로 변경하는 방법이 떠올랐다. Segment 단위 서버 렌더링을 한다고 했으니 그러면 client 컴포넌트로 변경한다면 리렌더링만 발생하지 않을까 고민이 되었다.
⚠️근데 주의사항이 있었다. 현재 경로가 components / layout 폴더 안에 LayoutProvider가 있기 때문에, 클라이언트 컴포넌트로 바꾼다고 해서 app 라우팅 계층이 아니라 단순 Import 된 컴포넌트로 처리를 한다는 것이다.
이를 해결하기 위해서는 LayoutProvider를 app 폴더 경로로 옮겨야 한다. 하지만 폴더구조를 맞추기 위해서 위 방법은 택하지 않도록 하였다

정리

문제원인해결

페이지 이동 시 Header state 초기화	Segment 단위 서버 렌더링으로 LayoutProvider 재생성	usePathname() 사용
"use client"로도 해결 안 됨	_components 폴더는 라우트 계층 아님	LayoutProvider를 app 폴더로 이동 or Header를 root layout로 분리

React 딥다이브

도니도니도니도니 — Fri, 17 Oct 2025 20:11:01 +0900

리액트 훅 파해치기

useState

useState 컴포넌트는 내부에서 상태를 정의하고, 이 상태를 관리할 수 있게 해주는 훅이다

import { useState } from 'react'

const [state, setState] = useState(initialState);

useState 인수로는 사용할 초기값 state 초기값을 넘겨준다. 아무런 값을 넘겨주지 않으면 undefined가 나온다.
useState 훅의 반환 값은 배열이며, 배열의 첫번째 원소로 state 값 자체를 사용이 가능하고, 두번째 setState 함수를 사용해 state의 값을 변경이 가능하다.

function Component() {
  let state = 'hello'
}

 function handleButtonClick() {
   state = 'hi'
 }

 return (
   <>
     <h1>{state}</h1>
     <button onClick={handleButtonClick}>hi</button>
   </>
 )
}

위 코드는 리액트에서 동작하지 않는다. 리액트에서 렌더링은 return 함수를 실행한 다음, 실행 결과를 이전의 리액트 트리와 비교해 필요한 부분만 업데이트 된다. 리액트에서 리렌더링이 일어나는 조건은 부모컴포넌트가 렌더링 되거나, key 값이 변경이 되거나, props, state가 변경이 되어야 리렌더링이 발생한다.
위와 같은 이유로 다음 코드는 버튼을 눌러도 아무런 동작을 하지 않는다.

function Component() {
   const [, trigger] = useState()
   
   let state = 'hello'
}

 function handleButtonClick() {
   state = 'hi'
   trigger()
 }

 return (
   <>
     <h1>{state}</h1>
     <button onClick={handleButtonClick}>hi</button>
   </>
 )
}

그렇다면?? 다음은 코드에서는 setState 함수를 실행시켜 렌더링이 일어나게 했는데 여전히 버튼 클릭해도 아무런 값이 나오지 않는다.
이유는 return 값을 비교해 실행되기 때문이다. 즉 매번 렌더링이 발생할 때마다 함수는 새롭게 다시 실행되고, 새롭게 실행되는 함수에서 state는 매번 hello로 초기화 되고 아무리 state를 변경해도 hello로 초기화 된다.

여기서 알 수 있는 것은 렌더링이 발생하면 컴포넌트 자체는 새롭게 다시 실행된다는 것이다

function Component() {
  const [state, setState] = useState(false)
  
  function handleClick() {
    setState((prev) => !prev)
  }
  
  return (
    <>
     <button onClick={handleClick}>+</button>
    </>
  )
}

위처럼 사용해야 정상적으로 작동을 한다. 근데 궁금한게 위에서 말한 렌더링이 발생하면 컴포넌트 자체가 다시 새롭게 실행이 되는데 어떻게 초기화가 안될까

✅ 이유는 리액트 파이버 때문이다.
만약 setState 함수가 호출되면 리액트 Fiber에 존재하는 updateQueue에 등록한다. 이를 기반으로 리액트는 다시 컴포넌트를 실행시킨다.
setState(nextValue)

Fiber.memoizedState = {        // useState 훅 저장 공간
  memoizedState: currentValue, // 현재 상태값
  updateQueue: [               // 변경 요청들
    { action: nextValue }
  ]
}
setState가 업데이트 되면 아래와 같이 파이버는 updateQueue에 새로운 상태를 적용시키고 이 결과를 memoziedState에 저장한다고 생각하자.

게으른 초기화

일반적으로 useState에서 기본값을 선언하기 위해 useState() 인수로 원시값을 넣는 경우가 대부분일 것이다. 그러나 이 useState 인수로 특정한 값을 넘기는 함수를 넣어줄 수 있다. useState에 변수 대신 함수를 넘기는 것을 게으른 초기화(lazy initailzation)이라 한다.
리액트 공식문서에서 lazy initailzation은 복잡하거나 무거운 연산을 포함하고 있을때 사용하라고 되어있다.
이 초기화 함수는 오로지 state가 처음 만들어질때만 사용하고 리렌더링이 발생하면 무시된다고 한다.

게으른 초기화는 정리하면 useState 인수로 함수를 전달해야할 때를 방지하고자 사용하면 된다고 알고있자!!

⚠️ 주의사항으로는 lazy initailzation에 함수 자체를 넣어줘야지 함수를 호출하는 식으로 만들면 리렌더링되면 함수가 호출되니 이를 주의하자

useEffect

useEffect는 애플리케이션 내 컴포넌트들의 여러 값들을 활용해 동기적으로 부수 효과를 만드는 매커니즘이다.

useEffect(() => {
  
}, [props, state])

useEffect의 첫 번째 인수로는 실행할 부수효과가 있는 함수를, 두 번째 인수로는 의존성 배열을 전달한다.
의존성 배열이 변경될때 콜백함수가 실행이 된다고 하는데 어떻게 실행이 되는걸까..??

import React, { useEffect } from "react";

export default function Footer() {
  const [counter, setCounter] = useState(0)

  useEffect(() => {
    console.log(counter) // 1 2 3 4...
  }, []);
  
  useEffect(() => {
    console.log(counter) // 1 2 3 4...
  }, [counter]);

  useEffect(() => {
       console.log(counter) // 1 2 3 4...
  }, [counter]);
  
  useEffect(() => {
  console.log("  effect 실행");

  return () => {
    console.log("  cleanup 실행");
  };
}, []);



  return <button onClick={handleClick}>Click me</button>;
}

useEffect는 state와 props의 변화속에서 일어나는 렌더링 과정에서 실행되는 부수 효과 함수라고 볼 수 있다.
위 useEffect 훅에서 의존성 배열은 빈배열[] 이다. 이러면 useEffect는 화면에 처음 마운트 되었을때만 렌더링을 실행한다. state, props가 변경이 되어도 한번만 실행이 된다.
다음 useEffect의 의존성 배열에는 [counter] state가 들어있는데, 이는 state의 값이 변경될 때 리렌더링이 발생하는 의미이다.

clean up 함수

clean up 함수는 말그대로 정리를 위한 함수이다.
위 예제에서 외부 API 등록하거나, setTimeout등 useEffect 안에서 side effect가 실행이 되면 브라우저는 메모리 누수가 생길 수 있다.
무조건 적으로 useEffect를 사용했다고 해서 clean up 함수를 사용해야 하는 것은 아니다.

useEffect 조금더 깊이 파보기

- useEffect가 side effect를 처리하기 위해서 만든거는 알겠다.. 근데 side effect나 이런 외부에서 일어나는 일들을 리액트 내부에서 처리하지 않을까??
- 이는 React가 순수하지 않은 작업을 commit Phase 단계에서 실행을 하고 싶어서라고 한다.
- React는 UI 렌더링과 side effect를 완전히 분리하고 싶어 한다.

이유는 리액트 렌더링 단계에서 렌더 단계에서 JSX를 계산할 때 예측 가능한 렌더링을 유지하고 싶어서 라고 한다.
이로 인해 side effect가 일어나는 경우 렌더 단계에서 실행이 되는 것이 아니라 커밋 단계에서 실행이 된다 !!!

그렇다면 모든 훅들???도 커밋 단계에서 실행이 될까???
- 정답은 모든 훅은 아니다. side effect를 일으키지 않는 훅들은 커밋 단계가 아닌 렌더 단계에서 실행이 된다.

useEffect => Passive Effect?
- 리액트에서 useEffect를 수동 효과 라고도 하는데 브라우저의 DOM 업데이트와 페인팅을 모두 끝난 후에 비동기로 실행이 되기 때문이다.
- 리액트에서 내부적으로 Fiber Tree를 돌면서 모든 useEffect들을 한번에 실행하지 않고 queue에 넣어둔다. 이를 Passive Effect Queue라고 한다.

정리

1️⃣ useState — 상태의 저장소, Fiber에 의존하는 이유

정의

useState는 컴포넌트 내부에서 상태(state)를 정의하고 관리하기 위한 훅이다.

import { useState } from 'react';

const [state, setState] = useState(initialState);

initialState: 초기 상태 값 (넘기지 않으면 undefined)
반환값: [state, setState]
- state: 현재 상태 값
- setState: 상태를 갱신하고 리렌더링을 트리거하는 함수

2️⃣ useEffect — 부수효과(Side Effect)를 관리하는 메커니즘

정의

useEffect는 렌더링 과정에서 발생하는 부수효과(side effect)를 다루는 훅이다.

useEffect(() => {
// 부수효과 로직
return () => { // cleanup 로직 };
}, [deps]);

첫 번째 인수: 실행할 함수
두 번째 인수: 의존성 배열(deps)
- []: 최초 마운트 시 한 번만 실행
- [state]: 해당 값이 바뀔 때마다 실행