띵스룸 프론트엔드 레포지토리 링크: https://github.com/DdingSroom/dding-sroom-frontend

띵스룸(Ddingsroom)은 명지대학교 학생지원팀의 승인 하에 명지대학교 학생회관 4층 5개의 스터디룸을 대상으로 운영되고 있는 명지대학교 공식 학생회관 스터디룸 예약 서비스이다.

이 글에서는 2025년 8월 중후반 약 2주간 진행된 시범 운영 및 2025년 9월부터 글을 쓰고 있는 현재 2026 2월까지 진행된 공식 운영 과정에서 있었던 일련의 일들을 회고글 형태로 작성해보려 한다.

개발을 본격적으로 시작하게 된건 2025년 7월 후반이었다. 본래의 학생회관 4층 스터디룸은 예약 서비스의 부재로 인해 공정하지 못한 이용 기회, 자리 무단 점유, 비효율적인 회전율 등의 여러 문제가 존재하고 있었다. 띵스룸 팀은(아래 '우리') 이러한 문제를 내가 해결 할 수 있는 '예약 서비스 개발'로 해결할 수 있다 생각했고, 학생지원팀과의 면담 일정을 잡아 제안서를 가지고 학생지원팀 계장님께 제안을 드렸다.

제출했던 띵스룸 제안서: https://certain-gallium-c59.notion.site/2421129efe5a80069a94f4e0c99cf3e4?source=copy_link

다행히 제안은 통과되었고 제안이 통과되고 난 후부터 바로 개발에 착수했다. 약 한달 간의 개발 기간을 통해 대략적인 서비스의 형태를 갖추게 되었고, 학생지원팀과 다시 면담 일자를 잡고 서비스 운영에 대한 허락을 받으러 갔다.

띵스룸은 학생들에게 제공 될 메인 예약 서비스 도메인 외에도 학생지원팀측에서 스터디룸 및 서비스에 가입한 학생들을 관리할 수 있도록 하는 관리자 도메인도 함께 구현되었기에, 학생지원팀측에서 주로 사용할 관리자 도메인을 위주로 서비스 이용 방법을 소개드렸다.

학생지원팀측에서 메인 예약 서비스 도메인 및 관리자 도메인에 대한 여러 번의 기술적인 테스트 및 검증을 통한 서비스에 대한 기술적인 문제가 없다는 판단 하에 운영을 허락해주셨다.

공식적인 운영에 앞서, 2025년 8월 17일 - 2025년 8월 31일 약 2주 간의 기간 동안 시범운영을 거쳐 문제가 없다면 2025년 9월 1일부터 공식 운영을 허락해주신다는 학교 측의 제안을 받아들여 5개의 스터디룸 앞에 시범운영 관련 공고문을 붙이고 시범운영을 시작했다.

스터디룸 앞에 붙여진 공고문 내용

공고문을 붙이고 서비스가 운영되고 있는 사진

시범 운영 기간 동안에는 학교 측의 요청 사항에 따라 서브 기능들(커뮤니티, 공지사항, 건의사항)을 제외한 메인 기능인 예약 관련 기능들(회원가입, 로그인, 예약, 마이페이지)만 운영을 진행했다.

그 결과 시범운영 기간 동안 아래 구글 애널리틱스 대시보드에 나와있는 것과 같이 약 4.8천 건의 조회수와 8천 건의 이벤트 수가 서비스 내에서 발생했다.

또한 시범운영 기간 동안 교내 창의적 SW 경진대회가 있었는데 해당 대회에 서비스를 출품하고자 했다. 경진대회에 출품할 때는 서비스의 모든 기능을 다 보여주는게 맞다고 판단하여 실제 시범 운영이 진행되고 있는 Main 브랜치와 별도로 Production 브랜치를 생성해 배포 도메인을 다르게 하여 서비스를 출품했다.

제출했던 SW 명세서: https://certain-gallium-c59.notion.site/SW-2551129efe5a80978256d62bbba81314?source=copy_link

제출했던 전체 기능을 제공하는 버전 실행 방법을 설명하는 문서: https://certain-gallium-c59.notion.site/SW-2551129efe5a80978256d62bbba81314?source=copy_link

출품한 서비스는 교내 경진대회에서 서류 심사와 발표 심사를 거쳐 '장려상(4위)'라는 성과를 얻게 되었다.

2025 명지대학교 SW 경진대회 입상작 관련 게시글: https://cs.mju.ac.kr/ince/5121/subview.do?enc=Zm5jdDF8QEB8JTJGYmJzJTJGaW5jZSUyRjY3OSUyRjIyNjAwMiUyRmFydGNsVmlldy5kbyUzRg%3D%3D

시상식은 2025년 10월 17일 자연캠퍼스에서 진행되었다.

시상식 관련 기사: https://www.newsis.com/view/NISX20251022_0003372670

시상식에서 장려상을 수여받는 모습

시범 운영 기간 동안 별도의 기술적인 오류나 결함, 학생지원팀으로의 문의 없이 무사히 운영을 마칠 수 있었고, 2025년 9월 1일 부터 학생지원팀의 승인 하에 공식 운영을 허락받게 되었다.

공식 운영부터는 시범 운영 때는 제공하지 않았던 서브 기능들(커뮤니티, 공지사항, 건의사항)까지 포함하여 운영을 진행하였다.

아래 구글애널리틱스 대시보드 결과와 같이 9월부터 12월까지 약 3달 간 3.1만 건의 조회수와 5.5만 건의 이벤트 수가 기록되었다.

특히 중간고사나 기말고사 기간에는 트래픽이 평소보다 3배 이상 증가하였는데, 기술적인 오류나 결함없이 운영을 성공적으로 진행할 수 있었다.

아래와 같이 건의 내역으로 접수된 내용 중 기술적인 건의 내역은 최대한 빠르게 반영 및 개발하여 재배포를 진행하였고, 운영적인 건의 내역은 학생지원팀과의 논의를 통해 해결할 수 있는 내역은 최대한 빠르게 해결하였다.

학생지원팀도 지속적으로 관리자 페이지를 통해 예약 현황을 확인하며, 우리에게 수정 내용을 면담을 통해 요청하였고, 우리는 즉각적으로 피드백을 받아들여 서비스에 반영하였다.

약 3개월 간의 공식 운영을 마치고 2025년 12월 23일부터 2026년 2월 28일까지 학생회관 4층 내부 공사가 진행되었다. 학교 측의 요청에 따라 해당 공사 기간 동안에는 서비스가 운영되지 않도록 막아두고 돌아오는 2026년 3월부터 다시 운영을 재개하기로 했다.

middleware로 서비스 진입을 막아놓은 화면

또한 학교 홍보 기자단에서 '띵스룸' 서비스와 서비스를 개발한 '띵스룸 팀'에 대해 인터뷰 요청이 들어와 인터뷰를 진행하였고, 해당 인터뷰 내용은 학교 공식 인스타그램 계정에 매거진 형태로 게재되었다.

게재된 매거진 링크: https://www.instagram.com/p/DRyMEddD7TA/?img_index=1

공사가 시작된 2025년 12월 23일 부터 현재 이 글을 쓰고 있는 2026년 2월 19일까지 아래와 같은 리팩토링 작업이 진행되었고, 3월부터는 서비스 게재와 함께 아래와 같은 사항들을 새로운 프론트엔드 팀원과 함께 리팩토링해나갈 계획에 있다.

2026년 상반기 리팩토링 예정 내역

• Javascript -> Typescript 언어 마이그레이션
• 운영하며 필요하다고 느낀 추가적인 초기세팅 재진행
• Next.js 특징을 살려 서비스 고도화

• “이 버튼 hover는 어떻게 되는 거였지?”
• “모달 padding이 왜 페이지마다 달라…?”
• “이 컴포넌트, 여기선 되는데 저 페이지에서만 깨져요”
• “디자이너가 말한 ‘카드’가 A카드인지 B카드인지부터 다시 맞추자…”

나도 팀 프로젝트를 해보면서 느낀 건, 이런 문제들이 실력 부족 때문이 아니라 협업 구조가 불명확해서 터진다는 점이었다. 그래서 앱잼 전에 체계를 정리해놓고 싶었고, 그게 Storybook으로 이어졌다.

✔️ 팀 프로젝트에서 제일 자주 터지는 문제: “UI가 어디에 정의되어 있지?”

개인 프로젝트와 다르게 팀 프로젝트는 화면이 늘어나면서 “비슷한 UI”가 여기저기 복제된다. 기존에는 보통 이런 흐름으로 개발을 진행했다.

1. 페이지 하나 생성
2. 그 안에서 버튼/카드/모달을 바로 구현
3. “다른 데서도 쓰겠네?” 싶으면 그때 컴포넌트 분리

결국 UI를 ‘코드’로 정의하고 관리하는 기준점이 필요했다. 그게 Comfit이 Storybook을 찾게 된 첫 번째 이유다.

Storybook을 쓰기 시작하면 앞으로 흐름이 아래와 같이 변경될 것이다.

1. 컴포넌트를 먼저 생성
2. Story에서 상태별로 확인
3. 컴포넌트가 어느 정도 책임을 가져도 되는지 판단
4. 그 다음 페이지에 조립

특히 앱잼처럼 UI 요구사항이 자주 바뀌는 환경에서는 페이지 안에서 수정하는 것보다 컴포넌트 단위에서 검증하는 게 훨씬 빠르다고 생각했다.

✔️ Storybook이 해결해준 핵심은 “컴포넌트의 단일 출처(Single Source of Truth)”

Storybook은 한 줄로 정리하면 이거였다.

UI 컴포넌트를 페이지랑 분리해서, 컴포넌트 자체를 전시하고 테스트하는 공간

나는 Storybook을 도입하기 전에, 컴포넌트가 항상 페이지에 붙어 있는 형태로만 작업했다. 그러다 보니 컴포넌트를 고칠 때마다 이런 식의 비효율이 발생했다.

• 페이지 실행 → 해당 컴포넌트 있는 화면 이동 → 상태 만들어서 확인 → 다시 수정 → 다시 확인
• props 조합이 바뀌면 또 다른 페이지 가서 확인
• 빈 상태(empty), 로딩, 에러 상태 같은 건 페이지에서 만들기 번거로워서 “나중에…”가 됨

Storybook은 이걸 반대로 만든다.

• 컴포넌트만 단독으로 띄워서
• props를 바꿔가며 케이스를 정리하고
• “정상/로딩/빈상태/에러/긴텍스트/모바일” 같은 모든 상태를 의도적으로 만들어 확인한다

이 흐름이 팀 프로젝트에서 특히 유용했던 이유는 명확했다.

☑️ “디자인 확인”이 페이지가 아니라 컴포넌트 기준이 됨

페이지는 여러 요소가 섞여 있어서 디테일 체크가 어렵다. 근데 Storybook에서는 버튼 하나, 카드 하나를 정확히 그 컴포넌트만 보고 검증할 수 있다.

☑️ “QA”가 기능 QA뿐 아니라 UI 케이스 QA까지 가능해짐

팀 프로젝트에서 자주 놓치는 케이스가 이거였다.

• 텍스트가 길면 줄바꿈이 터지는지
• 이미지 없으면 레이아웃이 무너지는지
• 버튼 disabled 상태가 명확한지
• 에러 메시지가 두 줄 이상이면 UI가 깨지는지

이런 걸 페이지에서 다 확인하려면 시간이 정말 많이 든다. Storybook에서는 한 화면에서 “케이스”를 정리해두면 계속 재활용할 수 있다.

✔️ “그래서 우리는 왜 ‘지금’ Storybook을 붙이기로 결정했나”

결론적으로 Storybook을 도입하기로 한 결정은 “좋아 보인다”가 아니라, 앱잼의 현실적인 제약 때문에 더 확실해졌다.

☑️ 앱잼은 시간이 짧고, UI 수정이 잦다

짧은 기간에 MVP를 만들면, 기획과 디자인이 중간중간 계속 바뀐다. 이때 페이지에서만 UI를 관리하면, 변경이 생길 때마다 전체 화면을 다시 열어서 “어디가 영향 받는지” 추적해야 한다.

Storybook이 있으면 바뀐 컴포넌트의 영향 범위를 Stories 목록만 봐도 바로 알 수 있다.

☑️ 협업에서 가장 많이 깨지는 건 “컴포넌트 재사용”이다

예를 들어 팀원 A는 PrimaryButton을 만들어 쓰는데 팀원 B는 같은 버튼을 페이지에 그냥 새로 만들 수도 있다. “어디에 뭐가 있는지” 안 보여서 생기는 문제라고 생각한다.

Storybook은 “컴포넌트 카탈로그” 역할을 해서 어떤 컴포넌트를 써야 하는지 한 번에 알 수 있게 한다.

☑️ 우리는 특히 ‘상태 관리’가 정리된 UI를 만들고 싶었다

로딩, 에러, 빈 상태 처리가 흔히 “나중에”로 미뤄진다. 근데 앱잼은 데모까지 가야 해서, 이런 디테일이 결국 완성도를 가를 수 있다고 생각한다.

Storybook에서 상태를 강제로 정리해두면 개발 과정에서 “기본 상태만 있는 UI”가 되는 걸 막아줄 수 있다고 한다.

✔️ Storybook 설치 & 세팅 (React 기준 / 실습 기록)

나는 “일단 빨리 붙이고, 팀에서 쓰기 좋은 구조”를 목표로 했다.

☑️ 설치

npx storybook@latest init

실행하면 알아서 프로젝트 환경에 맞게 설정해준다. (React/Vite/Next 등 자동 감지)

☑️ 실행

npm run storybook

기본 포트는 6006

✔️내가 실제로 만든 예시: Button 컴포넌트 스토리

☑️ Button 컴포넌트

// components/Button/Button.tsx
type ButtonProps = {
  label: string;
  variant?: 'primary' | 'secondary';
  disabled?: boolean;
  onClick?: () => void;
};

export default function Button({
  label,
  variant = 'primary',
  disabled = false,
  onClick,
}: ButtonProps) {
  return (
    <button
      disabled={disabled}
      onClick={onClick}
      className={`btn ${variant} ${disabled ? 'disabled' : ''}`}
    >
      {label}
    </button>
  );
}

☑️ Story 파일

// components/Button/Button.stories.tsx
import type { Meta, StoryObj } from '@storybook/react';
import Button from './Button';

const meta: Meta<typeof Button> = {
  title: 'components/Button',
  component: Button,
  args: {
    label: '버튼',
    variant: 'primary',
    disabled: false,
  },
};

export default meta;
type Story = StoryObj<typeof Button>;

export const Primary: Story = {};
export const Secondary: Story = { args: { variant: 'secondary' } };
export const Disabled: Story = { args: { disabled: true } };
export const LongText: Story = { args: { label: '텍스트가 엄청 길어지면 어떻게 될까 확인하기' } };

이렇게 해두면 팀이 버튼을 쓸 때 Primary/Secondary/Disabled/긴텍스트 케이스를 “페이지 실행” 없이 바로 확인 가능하다.

✔️ args를 쓰기 시작하면서 “상태 정의”가 명확해짐

Storybook에서 가장 많이 쓰게 될 기능이 바로 args이다.

export const Disabled: Story = {
  args: {
    disabled: true,
  },
};

이 한 줄이 의미하는 바는 아래와 같다.

• 이 컴포넌트에는 disabled 상태가 존재한다
• 이 상태는 디자인/기획적으로도 고려된 상태다
• 페이지에서 “나중에 처리”할 수 없는 상태가 된다

특히 아래 상태들을 Story로 만들어두는 게 좋을 것 같다.

• disabled
• loading
• empty (데이터 없음)
• 텍스트가 비정상적으로 긴 경우
• 모바일 뷰포트

✔️ Viewport로 모바일 UI를 미리 검증하기

앱잼 프로젝트 특성상 모바일 UI 대응은 거의 필수다. Storybook에서는 애드온 하나로 이걸 바로 확인할 수 있다고 한다.

// .storybook/preview.ts
import type { Preview } from '@storybook/react';

const preview: Preview = {
  parameters: {
    viewport: {
      defaultViewport: 'mobile1',
    },
  },
};

export default preview;

이렇게 설정해두면,

• 모바일에서 버튼이 너무 커지지는 않는지
• 텍스트가 두 줄로 깨질 때 레이아웃이 무너지지 않는지
• 터치 영역이 너무 작지 않은지

를 페이지 들어가지 않고도 확인할 수 있다.

✔️ Storybook을 붙이고 나서, 실제로 체감될 변화

☑️ 컴포넌트를 수정이 더욱 용이할 것이다

예전에는 “이 컴포넌트 고치면 어디 깨질지”가 무서웠다. Storybook에서는 관련 story를 쭉 돌려보면서 영향 범위를 빠르게 확인할 수 있을 것이다.

☑️ 디자이너 커뮤니케이션이 쉬워질 것이다

“이 카드에서 padding이 조금만 더…” 같은 피드백이 들어오면, 페이지 링크보다 Story 링크를 공유하는 게 훨씬 빨랐다.

• 페이지: 다른 UI 요소 때문에 뭐가 문제인지 설명이 길어짐
• Story: “이 컴포넌트 여기 부분만” 명확하게 잡힘

☑️ ‘상태’가 정리된 UI가 만들어질 것이다

로딩/빈상태/에러상태를 story로 만들어두니까 나중에 페이지 개발할 때 “이 상태 처리부터 해야지”라는 습관이 생길 것 같다.

✔️ 우리는 Storybook을 “이렇게” 운영하려고 한다 (Comfit 팀 규칙)

앱잼에서 Storybook을 그냥 설치만 해두면, 한정된 시간 안에 정신 없이 결국 안 쓰게 될 수도 있다 생각한다. 그래서 나는 운영 규칙을 최소한으로 잡는 게 중요하다고 생각한다.

• 공용 컴포넌트는 PR 올릴 때 story도 같이 작성
• “상태 케이스”는 최소 3개(기본/disabled/긴텍스트 or 로딩)
• 컴포넌트 이름과 story title은 폴더 구조랑 일치
• 디자인 변경이 생기면 먼저 story에서 수정 후 페이지 적용

Storybook 도입은 “선택”이 아니라 “비용 절감”일 것이다

Storybook을 도입하기 전엔 “이거까지 하면 시간이 더 드는 거 아닌가?”라는 생각이 컸다.

하지만 직전 기수 앱잼 팀 프로젝트를 살펴보니 그 반대였다.

• 페이지에서 확인하느라 새는 시간
• 수정 영향 범위 추적하느라 새는 시간
• QA에서 UI 케이스 다시 찾느라 새는 시간
• 디자인 커뮤니케이션 비용

이런 것들을 합치면 Storybook은 초반 투자로 전체 비용을 줄이는 도구일 것이다. 앱잼처럼 짧고 빠르게 완성해야 하는 프로젝트에서는 특히 더 효과가 크다고 느껴질 것이라 생각한다.

React로 프로젝트를 진행하다 보면 상태 관리가 점점 부담이 되는 순간이 온다. 처음에는 props로 충분하다고 생각했지만, 컴포넌트가 늘어나면서 props drilling이 깊어지고, Context API는 생각보다 구조가 복잡해졌다. Redux는 안정적이지만 작은 프로젝트에 적용하기에는 설정 비용이 꽤 크다는 느낌을 받았다.

그래서 이번 프로젝트에서는 가볍고 직관적인 전역 상태 관리 도구를 사용해보고 싶다는 생각을 하게 되었고 앱잼 팀원들과의 회의를 거쳐 Zustand를 최종적으로 선택하게 되었다. 이 글은 앱잼 프로젝트에 적용하기 전에 Zustand를 기술적으로 정리하고, 직접 실습해보기 위함이다.

✔️ Zustand란 무엇인가

Zustand는 Flux 패턴을 기반으로 한 경량 상태 관리 라이브러리로, React Hook 형태로 전역 상태를 관리할 수 있도록 도와준다. 가장 큰 특징은 store가 컴포넌트 트리 안에 존재하는 것이 아니라 외부에 독립적으로 존재한다는 점이다. 컴포넌트는 필요한 상태만 선택적으로 구독하고, 상태가 변경되었을 때 실제로 사용하는 값이 바뀐 컴포넌트만 리렌더링된다.

Context API처럼 Provider로 감쌀 필요도 없고, Redux처럼 액션과 리듀서를 분리할 필요도 없다. 상태를 정의하고 바로 사용하는 흐름이 굉장히 단순하다.

개념 요약

• store는 외부에 존재
• 컴포넌트는 store를 구독(subscribe) 한다
• selector를 통해 부분 구독 가능
• 상태 변경 시 구독 중인 컴포넌트만 리렌더링

  [ Store ] → (subscribe) → [ Component ]

  👉 React Context와 달리 상태 변경 ≠ 전체 리렌더링

✔️ Store 생성 실습

구조를 이해하기 위해 가장 기본적인 counter store를 예제로 실습을 진행해보겠다.

Zustand에서 store는 create 함수로 생성한다. 이 함수 안에서는 상태(state)와 상태를 변경하는 함수(action)를 함께 정의한다. Redux처럼 액션과 리듀서를 분리하지 않고, 한 곳에서 상태 흐름을 모두 확인할 수 있다는 점이 특징이다.

먼저 counter 상태를 관리하는 store를 하나 만든다.

// stores/useCounterStore.ts
import { create } from 'zustand';

interface CounterState {
  count: number;
  increase: () => void;
  decrease: () => void;
}

const useCounterStore = create<CounterState>((set) => ({
  count: 0,
  increase: () =>
    set((state) => ({
      count: state.count + 1,
    })),
  decrease: () =>
    set((state) => ({
      count: state.count - 1,
    })),
}));

export default useCounterStore;

코드를 위에서부터 하나씩 보면 구조가 훨씬 명확해진다. CounterState 인터페이스에서는 이 store가 어떤 상태와 함수를 가지는지 정의한다. 여기서는 숫자 형태의 count 상태와, 값을 증가·감소시키는 두 개의 함수가 전부다.

create 함수의 인자로 전달되는 콜백 함수 안에서는 set을 사용할 수 있는데, 이 set 함수가 바로 상태를 변경하는 역할을 한다. set 안에서는 이전 상태를 받아 새로운 상태를 반환하는 방식으로 값을 업데이트한다. 이 방식은 React의 setState와 굉장히 유사해서 이해하기 어렵지 않다.

이렇게 만든 store의 가장 큰 특징은 컴포넌트 트리와 완전히 분리되어 있다는 점이다. Context API처럼 Provider로 감싸줄 필요가 없고, 단순히 훅을 import해서 호출하기만 하면 된다.

이제 이 store를 실제 컴포넌트에서 사용해보자.

import useCounterStore from '@/stores/useCounterStore';

export default function Counter() {
  const count = useCounterStore((state) => state.count);
  const increase = useCounterStore((state) => state.increase);
  const decrease = useCounterStore((state) => state.decrease);

  return (
    <div>
      <p>{count}</p>
      <button onClick={increase}>+</button>
      <button onClick={decrease}>-</button>
    </div>
  );
}

여기서 중요한 점은 store 전체를 한 번에 가져오지 않고, selector를 통해 필요한 값만 가져오고 있다는 것이다. count 값은 숫자가 바뀔 때만 리렌더링을 유발하고, 증가·감소 함수는 상태 변화와 무관하게 안정적으로 사용할 수 있다.

이 구조 덕분에 Zustand는 별도의 설정 없이도 자연스럽게 렌더링 최적화를 할 수 있다.

✔️ Zustand 내부 동작 구조

Zustand의 store는 create 함수로 생성되며, 이 함수 안에서 상태와 상태를 변경하는 함수들을 함께 정의한다. 내부적으로는 set과 get을 통해 상태를 관리하며, 이 store는 하나의 싱글톤처럼 동작한다.

컴포넌트는 store 전체를 구독하는 것이 아니라 selector를 통해 필요한 상태만 가져오게 된다. 이 덕분에 상태가 변경되더라도 관련 없는 컴포넌트는 영향을 받지 않는다. 이런 구조 덕분에 Zustand는 별도의 복잡한 최적화 없이도 자연스럽게 렌더링 성능을 관리할 수 있다.

create((set, get) => ({
  state,
  actions,
}))

• set : 상태 변경 함수
• get : 현재 상태 접근
• store는 singleton
• React 외부에서도 접근 가능

상태 흐름

1. 컴포넌트가 selector로 상태를 구독
2. set() 호출 → 상태 변경
3. 변경된 상태를 사용하는 컴포넌트만 리렌더링

✔️ Selector 기반 구독의 중요성

Zustand를 사용할 때 가장 중요하다고 느낀 부분은 selector를 통한 상태 구독이다. store 전체를 한 번에 가져오면 상태가 조금만 바뀌어도 컴포넌트가 다시 렌더링된다. 반대로 selector를 사용하면 실제로 필요한 값이 변경될 때만 렌더링이 발생한다.

프로젝트 규모가 커질수록 이 차이는 꽤 크게 느껴질 수 있다. Zustand의 성능을 제대로 활용하려면 반드시 selector 기반 구독을 사용하는 습관을 들이는 게 좋다고 느꼈다.

❌ 전체 상태 구독 (비추천)

const store = useCounterStore();

• store의 어떤 값이 바뀌어도 리렌더링

✅ 부분 구독 (권장)

const count = useCounterStore((state) => state.count);

• count가 바뀔 때만 리렌더링

✔️ Zustand에서 비동기 처리하기 — store로 API 로직 옮겨보기

Zustand에서 비동기 처리가 자연스럽다고 느껴지는 이유는 Redux처럼 thunk나 saga 같은 별도의 middleware를 붙이지 않아도, store 안에서 그냥 async 함수를 정의하고 그 안에서 set으로 상태를 업데이트하면 끝난다.

이번 실습에서는 예시로 유저 목록을 가져오는 API 호출을 생각하고, 그 로직을 컴포넌트가 아니라 store 안으로 옮겨보겠다. 핵심은 loading, error, data 같은 상태를 store에서 같이 들고 가면서, 컴포넌트는 “불러오기 버튼”과 “화면 렌더링”만 담당하게 만드는 것이다.

먼저 store를 만든다.

// stores/useUserStore.ts
import { create } from 'zustand';

type User = {
  id: number;
  name: string;
  email: string;
};

interface UserState {
  users: User[];
  isLoading: boolean;
  error: string | null;

  fetchUsers: () => Promise<void>;
  clearError: () => void;
}

const useUserStore = create<UserState>((set, get) => ({
  users: [],
  isLoading: false,
  error: null,

  clearError: () => set({ error: null }),

  fetchUsers: async () => {
    // 1) 요청 시작: 로딩 true, 에러 초기화
    set({ isLoading: true, error: null });

    try {
      // 2) API 호출 (예시)
      const res = await fetch('https://jsonplaceholder.typicode.com/users');

      // 3) 실패 케이스 처리
      if (!res.ok) {
        throw new Error(`요청 실패: ${res.status}`);
      }

      const data = await res.json();

      // 4) 성공 시: 데이터 저장 + 로딩 false
      set({
        users: data.map((u: any) => ({
          id: u.id,
          name: u.name,
          email: u.email,
        })),
        isLoading: false,
      });
    } catch (e: any) {
      // 5) 에러 시: 에러 메시지 저장 + 로딩 false
      set({
        error: e?.message ?? '알 수 없는 에러가 발생했어요.',
        isLoading: false,
      });
    }
  },
}));

export default useUserStore;

여기서 포인트는, fetchUsers라는 비동기 함수가 store 내부에 있다는 점이다. 이 함수는 요청 시작 시점에 로딩 상태를 켜고, 응답을 받으면 users를 업데이트하고, 실패하면 error를 업데이트한다. 즉 비동기 로직에 필요한 상태 흐름을 한 곳에서 통제하게 된다.

이제 컴포넌트에서는 훨씬 단순하게 사용할 수 있다. 컴포넌트는 “언제 fetch를 호출할지”와 “화면에 어떻게 보여줄지”만 신경 쓰면 된다.

import { useEffect } from 'react';
import useUserStore from '@/stores/useUserStore';

export default function UserList() {
  const users = useUserStore((state) => state.users);
  const isLoading = useUserStore((state) => state.isLoading);
  const error = useUserStore((state) => state.error);
  const fetchUsers = useUserStore((state) => state.fetchUsers);
  const clearError = useUserStore((state) => state.clearError);

  // 페이지 들어오자마자 불러오고 싶으면 useEffect로 호출
  useEffect(() => {
    fetchUsers();
  }, [fetchUsers]);

  if (isLoading) return <p>불러오는 중...</p>;

  if (error) {
    return (
      <div>
        <p>에러: {error}</p>
        <button
          onClick={() => {
            clearError();
            fetchUsers();
          }}
        >
          다시 시도
        </button>
      </div>
    );
  }

  return (
    <div>
      <button onClick={fetchUsers}>유저 목록 새로 불러오기</button>

      <ul>
        {users.map((u) => (
          <li key={u.id}>
            {u.name} ({u.email})
          </li>
        ))}
      </ul>
    </div>
  );
}

이렇게 되면 컴포넌트 안에서 try/catch, setLoading, setError, setUsers 같은 코드가 사라지고, UI는 UI답게 정리된다. 그리고 API 관련 상태 변화는 store에서 일관된 방식으로만 관리되기 때문에, 기능이 커져도 구조가 무너지지 않는다.

✔️ persist 미들웨어 활용

로그인 토큰이나 설정 값처럼 새로고침 이후에도 유지되어야 하는 상태는 persist 미들웨어를 사용하면 된다. localStorage나 sessionStorage를 선택할 수 있고, 설정도 단순하다.

실제로 로그인 상태 등을 관리할 때 굉장히 유용할 것 같았고, 프로젝트에서 바로 활용할 수 있겠다는 생각이 들었다.

import { persist } from 'zustand/middleware';

const useAuthStore = create<AuthState>()(
  persist(
    (set) => ({
      accessToken: null,
      setToken: (token) => set({ accessToken: token }),
      logout: () => set({ accessToken: null }),
    }),
    {
      name: 'auth-storage',
      storage: sessionStorage,
    }
  )
);

• 새로고침 후에도 상태 유지
• 로그인/예약/설정 상태에 적합

✔️ Zustand를 쓰는 기준

Zustand는 전역 UI 상태나 사용자 흐름과 관련된 상태를 관리하는 데 적합하다. 모달 열림 여부, 로그인 정보, 예약 상태처럼 여러 컴포넌트에서 공통으로 사용되는 값들이 여기에 해당한다.

반면 서버에서 받아오는 데이터의 캐싱이나 refetch가 중요한 경우에는 React Query 같은 라이브러리를 함께 사용하는 것이 더 적절하다고 느꼈다.

Zustand에 적합한 상태

• 로그인 정보
• 예약 정보
• 모달, 토스트, UI 상태
• 전역 필터 조건

Zustand에 부적합한 상태

• 서버 캐시
• pagination / refetch 중심 데이터

👉 Zustand + React Query 조합 추천

✔️ Store 분리 전략

Zustand를 사용할 때 store를 어떻게 나누느냐도 중요하다. 하나의 store에 모든 상태를 몰아넣기보다는, 인증, 사용자 정보, UI 상태처럼 도메인 단위로 분리하는 것이 관리하기 훨씬 수월하다.

이렇게 분리하면 상태의 책임이 명확해지고, 유지보수도 쉬워진다.

stores/
 ├─ useAuthStore.ts
 ├─ useModalStore.ts
 ├─ useReservationStore.ts
 └─ useUserStore.ts

• 도메인 단위 분리
• store 하나에 모든 상태 몰아넣지 않기

✔️ 다른 상태 관리 방식과의 비교

Context API는 간단한 상태 공유에는 적합하지만, 상태가 자주 바뀌는 경우 렌더링 최적화가 어렵다. Redux는 강력하지만 설정과 구조가 부담스럽다. Zustand는 이 둘 사이에서 비교적 가볍게 사용할 수 있는 대안이라는 느낌을 받았다.

프로젝트 성격과 규모에 따라 선택은 달라질 수 있지만, 이번 앱잼 React 프로젝트에서는 Zustand가 가장 적절한 선택이라고 판단했다.

✔️ 마무리

Zustand는 전역 상태 관리를 복잡하게 만들지 않으면서도, 필요한 성능과 구조를 충분히 제공해주는 라이브러리라고 느꼈다. 설정 부담이 적고, 코드 흐름이 직관적이라 React 프로젝트에 빠르게 적용할 수 있다는 점이 가장 큰 장점이다.

이번 프로젝트에서는 UI 상태와 사용자 흐름 관리에 Zustand를 적극적으로 활용해볼 계획이다. 이후 실제로 사용하면서 느낀 장단점이나 패턴들도 따로 정리해보고 싶다.

이 글에서는 리액트 최적화 기법 3가지를 중심으로 “왜 필요한지 → 언제 쓰는지 → 어떻게 적용하는지”를 코드와 함께 정리해보겠다.

• React.lazy: 초기 번들 크기를 줄이는 코드 스플리팅
• debounce: 입력/이벤트 폭주를 막는 제어 기법
• useCallback: 불필요한 리렌더링을 줄이는 함수 메모이제이션

✔️ React.lazy: 초기 로딩을 가볍게 만드는 코드 스플리팅

왜 React.lazy가 필요할까?

리액트 앱은 기본적으로 한 번에 모든 JS 번들을 내려받아 실행한다. 페이지 수가 많아질수록, 또는 차트·에디터·지도 같은 무거운 컴포넌트가 많아질수록 첫 화면을 보기까지의 시간(LCP) 이 급격히 늘어난다.

하지만 모든 컴포넌트가 첫 화면에 꼭 필요하지는 않다. 예를 들어

• 관리자 페이지
• 결제 페이지
• 무거운 모달
• 통계/차트 페이지

이런 컴포넌트는 “필요해질 때 로드” 하는 것이 훨씬 효율적이다.

React.lazy 기본 사용법

import React, { Suspense } from "react";

const HeavyChart = React.lazy(() => import("./HeavyChart"));

export default function Dashboard() {
  return (
    <Suspense fallback={<div>차트 로딩 중...</div>}>
      <HeavyChart />
    </Suspense>
  );
}

• React.lazy → 동적 import
• Suspense → 로딩 중 보여줄 UI 처리

👉 초기 번들에는 HeavyChart가 포함되지 않고, 실제 렌더링 시점에 로드된다.

라우트 단위로 분리하면 효과가 가장 크다

import React, { Suspense } from "react";
import { Routes, Route } from "react-router-dom";

const Home = React.lazy(() => import("./pages/Home"));
const Admin = React.lazy(() => import("./pages/Admin"));
const Payment = React.lazy(() => import("./pages/Payment"));

export default function App() {
  return (
    <Suspense fallback={<div>페이지 로딩 중...</div>}>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/admin" element={<Admin />} />
        <Route path="/payment" element={<Payment />} />
      </Routes>
    </Suspense>
  );
}

체감 할 수 있는 것

• 첫 화면 로딩 속도 개선
• Network 탭에서 JS 파일이 여러 chunk로 나뉘는 것을 확인 가능

모달도 lazy로 분리하면 UX가 좋아진다

import React, { useState, Suspense } from "react";

const ImageEditorModal = React.lazy(() => import("./ImageEditorModal"));

export default function Page() {
  const [open, setOpen] = useState(false);

  return (
    <>
      <button onClick={() => setOpen(true)}>모달 열기</button>

      {open && (
        <Suspense fallback={<div>모달 준비 중...</div>}>
          <ImageEditorModal onClose={() => setOpen(false)} />
        </Suspense>
      )}
    </>
  );
}

👉 모달을 열 때만 무거운 라이브러리를 로드하기 때문에 초기 진입 속도와 전체 UX 모두 개선된다.

✔️ debounce: 입력 이벤트 폭주를 막는 방법

debounce가 필요한 이유

검색창에서 키를 누를 때마다 API를 호출하면:

• 타이핑 10번 → API 10번
• 네트워크 낭비
• 응답 순서 꼬임 가능성
• UX 저하

와 같은 현상이 일어날 수 있다.

👉 debounce는 “마지막 입력 후 일정 시간 동안 추가 입력이 없을 때만 실행” 되도록 만든다.

debounce 구현 예시

import { useEffect, useState } from "react";

export default function SearchBox() {
  const [keyword, setKeyword] = useState("");
  const [debouncedKeyword, setDebouncedKeyword] = useState("");

  useEffect(() => {
    const timer = setTimeout(() => {
      setDebouncedKeyword(keyword);
    }, 400);

    return () => clearTimeout(timer);
  }, [keyword]);

  useEffect(() => {
    if (!debouncedKeyword) return;
    console.log("API 호출:", debouncedKeyword);
  }, [debouncedKeyword]);

  return (
    <input
      value={keyword}
      onChange={(e) => setKeyword(e.target.value)}
      placeholder="검색어 입력"
    />
  );
}

• keyword → 즉시 반영
• debouncedKeyword → 입력 멈춘 뒤 확정
• API 호출은 debounced 값 기준

커스텀 훅으로 재사용하기

import { useEffect, useState } from "react";

export function useDebouncedValue(value, delay = 300) {
  const [debounced, setDebounced] = useState(value);

  useEffect(() => {
    const timer = setTimeout(() => setDebounced(value), delay);
    return () => clearTimeout(timer);
  }, [value, delay]);

  return debounced;
}

const debouncedKeyword = useDebouncedValue(keyword, 400);

👉 검색, 필터, 자동완성 등 거의 모든 입력 UX에 활용 가능하다.

✔️ useCallback: 불필요한 리렌더링을 막는 함수 메모이제이션

문제 상황: 함수는 매 렌더마다 새로 만들어진다

const handleClick = () => {
  setCount(count + 1);
};

이 함수는 컴포넌트가 렌더링될 때마다 새로 생성된다. 이걸 props로 내려주면, 자식 컴포넌트는 “props가 바뀌었다”고 인식하고 다시 렌더링된다.

useCallback 없이 발생하는 리렌더

const Child = React.memo(({ onClick }) => {
  console.log("Child 렌더링");
  return <button onClick={onClick}>+</button>;
});

부모의 다른 state가 바뀌어도

• 함수 참조 변경
• Child 리렌더 발생

이 일어난다.

useCallback으로 해결하기

import { useCallback, useState } from "react";

const Child = React.memo(({ onClick }) => {
  return <button onClick={onClick}>+</button>;
});

export default function Parent() {
  const [count, setCount] = useState(0);
  const [text, setText] = useState("");

  const handleClick = useCallback(() => {
    setCount((prev) => prev + 1);
  }, []);

  return (
    <>
      <input value={text} onChange={(e) => setText(e.target.value)} />
      <Child onClick={handleClick} />
    </>
  );
}

• 함수 참조 유지
• React.memo와 함께 사용할 때 효과 극대화
• prev 패턴으로 의존성 배열 단순화

목표: TBT(총 차단 시간) 줄이고, LCP 안정화해서 Performance 점수 개선하기

0. 측정 전 “환경 고정”부터 하기 (점수 출렁임 방지)

Lighthouse 결과에 아래 문구가 계속 떴다.

• Chrome extensions negatively affected this page's load performance…

즉, 확장 프로그램 영향으로 점수가 흔들릴 수 있음. 따라서 아래처럼 고정하고 측정했다.

• 시크릿 모드(확장 OFF) 또는 확장 없는 프로필
• DevTools Performance는 Record → 새로고침 → 아무것도 안 누르고 첫 화면 안정화 → Stop
• Next.js 환경이기 때문에 next build && next start(프로덕션)에서 다시 한 번 측정

1. 문제 상황: Performance 점수는 낮은데, 무엇이 막고 있는지 모르겠음

처음에는 이런 상태였다.

• Performance 점수 낮음 (점수가 무려 40점대인 쓰레기 성능)
• Metrics에서 특히 TBT가 매우 큼
• LCP도 비정상적으로 늦게 잡히는 케이스가 존재

--

2. DevTools Performance로 “Bottom-up”에서 범인 찾기

Lighthouse는 “결과”만 보여주고, 원인 함수/컴포넌트를 바로 집어주진 않는다. 그래서 DevTools Performance 탭에서:

1. 성능 측정
2. 아래 탭 중 Bottom-up 탭 확인
3. Self time / Total time 큰 항목이 실제 범인임을 확인

특정 함수/컴포넌트가 렌더링 중 반복 호출되며 메인 스레드를 오래 잡는 패턴이 보였다. (예: nowInKST()처럼 toLocaleString(timeZone) 기반 계산이 타임슬롯 개수만큼 반복)

3. 1차 개선: 배너 마루 이미지 Next/Image 전환 + priority 적용

문제 상황 (LCP 병목)

Lighthouse에서 확인한 LCP 요소는 메인 배너 이미지였다. 해당 이미지는 다음 문제를 가지고 있었다.

• 일반 <img> 태그 사용
• 기본 lazy loading
• 포맷 최적화(webp/avif) 미적용

👉 그 결과, LCP가 10초 이상으로 측정되었다.

해결 방법

1. Next/Image로 전환

• 자동 리사이징
• 포맷 자동 변환(webp/avif)
• 네트워크 최적화

2. LCP 대상 이미지에만 priority 적용

• 페이지 로드 시 즉시 네트워크 요청
• 모든 이미지에 적용하지 않고
• 상단 배너(LCP 후보)에만 제한적으로 적용

<Image
  fill
  priority
  className="object-cover"
  src={bannerImageUrl}
  alt="메인 배너 이미지"
/>

결과

• LCP는 1.1s로, Core Web Vitals 기준을 충분히 만족하는 상태
• 초기 화면 체감 속도 대폭 개선
• Performance 점수 상승

👉 LCP는 “가장 큰 요소 하나”만 정확히 잡아도 효과가 크다.

2차 개선: 초기 렌더 성능 개선을 위한 dynamic import 적용

문제 상황 (초기 JS 실행 비용 과다)

초기 진입 시:

• 당장 보이지 않는 페이지
• 사용자가 아직 접근하지 않는 컴포넌트까지

모두 번들에 포함되어 있었다.

그 결과:

• JS 번들 크기 증가
• 메인 스레드 점유 증가
• TBT 상승

해결 방법

Next.js권장방식대로 React.lazy 대신 next/dynamic을 활용해 초기 화면에 필요한 컴포넌트만 로드하도록 분리했다.

import dynamic from 'next/dynamic';

const ReservationSection = dynamic(
  () => import('@components/common/ReservationSection'),
  {
    ssr: false,
    loading: () => (
      <div className="w-full max-w-[95%] min-h-[240px] rounded-2xl bg-white shadow-sm border border-gray-50" />
    ),
  },
);

3차 개선: ReservationSection 탭 구조 & 렌더링 최적화

문제 상황 (숨겨진 렌더링)

기존 ReservationSection 구조에서는:

• ‘오늘 예약’, ‘내일 예약’ 컴포넌트가 모두 마운트
• display: none으로만 제어

👉 즉, 안 보여도 렌더/계산/이펙트는 실행되고 있었다.

해결 방법: “보이는 탭만 렌더링”

최적화가 필요한 경우에는 보이는 탭만 렌더링(조건부 렌더링) 구조로 바꾸는 것이 효과적이다.

{currentTab === 0
  ? <TodayReservationList />
  : <TomorrowReservationList />}

결과

• LCP, FCP, Speed Index, CLS → 모두 안정화 완료
• Performance 점수의 병목은 이제 TBT 하나로 명확히 좁혀진 상태
• LCP 16.7s → 1.5s, TBT 14.8s → 3.3s로 개선하며 성능 병목을 렌더링 단계에서 JS 실행 단계로 축소
• 다음 단계의 최적화 목표는:
  • 초기 JS 실행량 추가 감소
  • 불필요한 마운트/계산 제거
  • 더 세분화된 코드 스플리팅

- Compound Component Pattern - Higher-Order Component(HOC) - React Portal

✔️ Compound Component Pattern

컴파운드 패턴은 여러 개의 컴포넌트가 마치 하나의 컴포넌트처럼 함께 동작하도록 만드는 패턴이다. React의 Context API와 주로 함께 사용된다.

언제 쓰는가?

• 드롭다운, 모달, 탭 UI처럼 “부모 안에 여러 하위 요소가 협력하는 구조”가 필요할 때
• <Select>, <Select.Option>처럼 개발자가 사용하기 쉽고 직관적인 API를 만들고 싶을 때

예시 코드 – Tabs Component

import { createContext, useContext, useState } from "react";

const TabsContext = createContext<any>(null);

export function Tabs({ children, defaultValue }) {
  const [active, setActive] = useState(defaultValue);
  return (
    <TabsContext.Provider value={{ active, setActive }}>
      <div>{children}</div>
    </TabsContext.Provider>
  );
}

Tabs.List = function TabsList({ children }) {
  return <div>{children}</div>;
};

Tabs.Trigger = function TabsTrigger({ value, children }) {
  const { active, setActive } = useContext(TabsContext);
  return (
    <button
      onClick={() => setActive(value)}
      style={{
        fontWeight: active === value ? "bold" : "normal",
      }}
    >
      {children}
    </button>
  );
};

Tabs.Content = function TabsContent({ value, children }) {
  const { active } = useContext(TabsContext);
  return active === value ? <div>{children}</div> : null;
};

사용법

<Tabs defaultValue="tab1">
  <Tabs.List>
    <Tabs.Trigger value="tab1">탭 1</Tabs.Trigger>
    <Tabs.Trigger value="tab2">탭 2</Tabs.Trigger>
  </Tabs.List>

  <Tabs.Content value="tab1">내용 1</Tabs.Content>
  <Tabs.Content value="tab2">내용 2</Tabs.Content>
</Tabs>

장점

• 사용성이 직관적
• UI 요소들을 마음대로 배치해도 내부적으로 잘 동작
• Context를 통해 상태를 깔끔하게 공유

✔️ Higher-Order Component (HOC)

HOC는 컴포넌트를 인자로 받아 새로운 기능을 덧붙인 컴포넌트를 반환하는 함수다.

공식 정의

A higher-order component is a function that takes a component and returns a new component

언제 사용하는가?

• 공통 로직을 여러 컴포넌트에서 재사용해야 할 때 (예: 인증 체크, 로깅, 공통 데이터 패칭, 권한 관리))

예시 코드 – 인증 여부 검사 HOC

function withAuth(Component) {
  return function ProtectedComponent(props) {
    const isLogin = Boolean(localStorage.getItem("token"));

    if (!isLogin) return <div>로그인이 필요합니다.</div>;

    return <Component {...props} />;
  };
}

사용법

function MyPage() {
  return <div>마이페이지!</div>;
}

export default withAuth(MyPage);

장점

• 인증, 공통 로직을 깔끔하게 재사용 가능
• 코드 중복 감소

단점

• 컴포넌트 트리가 복잡해지고 디버깅이 어려움
• React 공식 문서에서는 HOC보다 Custom Hook을 더 권장하는 추세

✔️ React Portal

Portal은 컴포넌트를 DOM 트리 외부로 렌더링하는 기능이다.

대표적인 사용 사례

• 모달
• 토스트 메시지
• 드롭다운 메뉴
• 오버레이 UI

즉, 시각적으로는 화면 맨 위(z-index 최고)에 떠 있어야 하지만 컴포넌트 구조는 기존 트리 하위에 있을 때 매우 유용하다.

예시 코드 – Modal 구현

import { createPortal } from "react-dom";

export default function Modal({ children }) {
  const modalRoot = document.getElementById("modal-root");

  return createPortal(
    <div className="overlay">
      <div className="modal">{children}</div>
    </div>,
    modalRoot
  );
}

index.html에 Portal 루트 추가

<div id="root"></div>
<div id="modal-root"></div>

사용법

function App() {
  const [open, setOpen] = useState(false);

  return (
    <>
      <button onClick={() => setOpen(true)}>모달 열기</button>

      {open && (
        <Modal>
          <h2>모달 콘텐츠</h2>
        </Modal>
      )}
    </>
  );
}

Portal을 쓰는 이유?

• 모달이 부모의 overflow: hidden이나 z-index 영향을 받지 않도록 하기 위함
• DOM 계층을 시각적 계층과 분리할 수 있음

✍️ webpack-bundle-analyzer — 번들을 시각적으로 분석하기

이 도구는 프로젝트의 JS 번들 크기를 시각화해주는 대표적인 분석 툴이다. 실제로 웹 서비스 성능 문제의 상당수는 “번들이 너무 크다”로부터 시작된다. 이를 해결하려면 무엇이 큰지 먼저 알아야 한다.

✔️ 설치

npm install --save-dev webpack-bundle-analyzer

✔️ Webpack 설정에 추가

// webpack.config.js
const BundleAnalyzerPlugin =
  require("webpack-bundle-analyzer").BundleAnalyzerPlugin;

module.exports = {
  plugins: [
    new BundleAnalyzerPlugin({
      analyzerMode: "server",
      openAnalyzer: true,
    }),
  ],
};

✔️ 번들 분석 화면 예시

이 화면을 통해 다음과 같은 의사결정을 할 수 있다.

• lodash 전체를 import하고 있어 tree-shaking이 안 되고 있네 → 부분 import로 변경
• moment.js가 너무 크네 → dayjs로 교체
• React-Query devtools가 production에도 포함되네 → 조건부 로딩 필요
• initial chunk가 너무 커서 FCP(First Contentful Paint)에 악영향 → dynamic import 적용

✔️ Dynamic Import (Code Splitting) 적용 예시

// Before
import HeavyModal from "./HeavyModal";

// After
const HeavyModal = React.lazy(() => import("./HeavyModal"));

코드 분할을 통해 최초 렌더링에 필요한 JS 크기를 큰 폭으로 줄일 수 있다.

✍️ CSS 최적화 — 렌더링 비용 줄이기

JS 실행시간 최적화라고 해서 JS만 줄이면 되는 것이 아니다. CSS도 브라우저의 렌더링 성능에 큰 영향을 준다. 불필요한 CSS는 JS처럼 파싱하고 적용하는 데 시간이 소요되기 때문이다.

✔️ 1. 사용되지 않는 CSS 제거 (Unused CSS purge)

Tailwind, Next.js, CRA 등 많은 프레임워크가 기본적으로 지원하지만 직접 PurgeCSS를 적용할 수도 있다.

npm install @fullhuman/postcss-purgecss

// postcss.config.js
module.exports = {
  plugins: [
    require("@fullhuman/postcss-purgecss")({
      content: ["./src/**/*.jsx", "./public/index.html"],
      defaultExtractor: (content) => content.match(/[\w-/:]+(?<!:)/g) || [],
    }),
  ],
};

✔️ 2. Critical CSS 추출

Critical CSS는 “초기 렌더링에 필요한 최소한의 CSS만 inline으로 넣는 방법”이다. Next.js는 이를 자동으로 처리해주지만, 직접 적용하려면:

<style>
  /* critical CSS inserted here */
</style>
<link rel="stylesheet" href="main.css" />

이렇게 하면 초기 렌더링 속도가 크게 향상된다.

✔️ 3. CSS 파일 분할 로딩

React + Webpack 환경에서 CSS도 JS처럼 Split 가능하다.

// webpack.config.js
{
  test: /\.css$/,
  use: [MiniCssExtractPlugin.loader, "css-loader"],
}

파일이 분리되면 JS 실행시간도 줄고 렌더링 지연도 감소한다.

✔️ CSS 최적화 결과 예시

위처럼 CSS blocking time이 줄어들면 JS도 함께 빠르게 실행된다.

✍️ React Compiler — 렌더링과 JS 실행량을 획기적으로 줄여주는 최신 기술

React 팀이 공개한 React Compiler는 현재(2025년 기준) 가장 효율적인 렌더링 최적화 도구다.

✔️ React Compiler가 하는 일

• React.memo를 자동으로 적용
• useCallback/useMemo 없이도 안정적인 렌더링
• 불필요한 리렌더링 제거
• JS 실행량 자체를 감소시킴

즉, 기존에는 개발자가 직접 최적화를 해줘야 했던 부분을 자동화해준다.

✔️ React Compiler 적용 예시 (Next.js 15 기준)

// next.config.js
module.exports = {
  reactCompiler: true,
};

혹은 React 19 환경에서:

"use client";
import { compiler } from "react-compiler";

✔️ React Compiler 사용 전/후 렌더링 비교

React Compiler가 활성화되면 다음과 같은 효과가 있다:

• JS 실행 시간 감소
• Virtual DOM 업데이트 비용 감소
• 컴포넌트 rerender 횟수 감소
• 이벤트 핸들러/콜백의 메모리 사용량 감소

특히 많은 상태와 props가 오가는 대규모 SPA에서 체감 속도 차이가 크다.

✍️ Caching: 이미 가져온 건 또 가져오지 않는다

캐싱(Caching)은 가장 기본적인 지연시간 최적화 전략이다. 핵심은 “같은 요청을 반복하지 않는다”는 점이다. 요청한 리소스(HTML, JS, CSS, 이미지, API 응답 등)를 클라이언트나 서버 가까운 곳에 저장해 두었다가, 동일한 요청이 들어오면 캐시된 결과를 즉시 반환해서 네트워크 왕복 비용을 절약한다.

✔️ 브라우저 캐싱

브라우저는 정적 리소스를 캐싱해 두고, 캐시 정책(Cache-Control, ETag, Last-Modified 등)에 따라 재요청 여부를 판단한다. 예를 들어, 정적 이미지나 JS 번들에 Cache-Control: max-age=31536000이 걸려 있다면 브라우저는 거의 1년 동안 서버에 요청하지 않고 바로 로컬 캐시에서 리소스를 꺼내 쓴다.

✔️ API 응답 캐싱

React Query(TanStack Query) 같은 상태 관리 라이브러리도 내부적으로 캐싱을 적극적으로 활용한다. 5~10초 사이에 계속 같은 API를 호출하는 경우, 네트워크 요청을 줄이고 캐시 데이터를 즉시 반환해 UI 반응성을 크게 높여준다.

간단한 코드 예시

const { data } = useQuery({
  queryKey: ["posts"],
  queryFn: fetchPosts,
  staleTime: 5000, // 5초 동안 refetch 방지
});

목록 → 상세 → 목록으로 이동해도 네트워크 요청 없이 즉시 화면이 렌더링된다.

✔️ 캐싱 동작 흐름

✔️ 캐싱의 효과

• 네트워크 왕복 시간(RTT) 감소
• 서버 부하 감소
• 사용자 체감 속도 대폭 향상
• 반복되는 스크롤·탭 이동 상황에서 특히 효율적

✍️ Prefetching: 사용자가 클릭하기 전에 미리 준비해두기

Prefetching은 “사용자가 곧 접근할 것 같은 리소스를 미리 가져와 두는 전략”으로, 지연시간 최적화에서 가장 체감 효과가 큰 기술 중 하나다. 브라우저는 백그라운드에서 조용히 리소스를 다운로드해 놓고, 사용자가 실제 요청하는 순간 즉시 제공한다.

✔️ 페이지 Prefetch

Next.js의 next/link는 사용자 viewport에 들어오면 자동으로 Link 타겟 페이지를 prefetch한다. 사용자가 링크를 클릭하는 순간 거의 즉시 페이지가 뜬다.

✔️ 데이터 Prefetch

예를 들어, 쇼핑몰 사이트에서 상품 목록 → 상품 상세 페이지로 넘어갈 것이 예상된다면 React Query에서는 다음과 같이 prefetch할 수 있다:

queryClient.prefetchQuery(['product', id], () => fetchProduct(id));

그 결과, 사용자가 상세 페이지 버튼을 누르는 순간 이미 데이터가 준비되어 있기 때문에 로딩 스피너도 거의 보이지 않는다.

✔️ Prefetch는 언제 사용할까?

• 페이지 이동이 자주 일어나는 UI
• 사용자의 행동 패턴이 뚜렷한 사용자 플로우
• 모바일 환경처럼 네트워크 속도 편차가 큰 경우

✔️ 주의점

과도하게 prefetch하면 오히려 불필요한 데이터 사용이 증가하여 성능을 해칠 수 있다. 따라서 사용자 행동 예측이 중요하다.

✔️ 페이지 Prefetch 예시 (Next.js)

Next.js에서 next/link는 자동으로 prefetch 기능을 제공한다.

<Link href="/products/1" prefetch>
  상품 상세보기
</Link>

viewport에 보이는 순간 Next.js가 내부적으로 페이지 데이터를 미리 가져오고, 사용자가 클릭하면 거의 새로고침 없이 즉시 이동된다.

✔️ Prefetch 동작 구조

✍️ CDN: 지리적으로 가장 가까운 곳에서 제공하기

CDN(Content Delivery Network)은 웹 리소스를 지리적으로 사용자와 가까운 서버에서 제공하는 시스템이다. 한국 사용자에게 미국 서버에서 직접 리소스를 제공한다면 RTT가 수십~수백 ms까지 올라갈 수 있지만, CDN 캐시 서버가 서울·도쿄 등에 배치되어 있다면 지연시간은 극적으로 줄어든다.

✔️ 왜 CDN이 중요한가?

인터넷의 물리적 거리 문제를 해결하는 가장 현실적이고 강력한 기술이기 때문이다. 아무리 최적화를 해도 원본 서버가 멀면 기본적인 RTT는 절대 피할 수 없다.

✔️ CDN의 장점

• 지리적으로 가까운 Edge 서버에서 리소스 제공
• 대규모 트래픽에도 안정적인 분산 처리
• 정적 리소스(JS, CSS, 이미지, 폰트) 제공 속도 극대화
• 브라우저 캐싱과 함께 사용하면 “더 이상 빨라질 데가 없는” 수준까지 최적화 가능

✔️ CDN 적용 예시(HTML)

<link rel="stylesheet" href="https://cdn.example.com/style.css" />

이렇게 CDN 도메인으로 불러오면, 사용자는 가장 가까운 Edge 서버에서 파일을 다운로드한다.

CDN 요청 흐름 이미지

✔️ 예시

• Cloudflare CDN
• AWS CloudFront
• Akamai
• Fastly

👉 CDN은 단순히 빠르기만 한 것이 아니라,보안(WAF, SSL), 도커 이미지 배포, 캐시 무효화, 엣지 컴퓨팅 등 다양한 기능을 함께 제공해 modern web의 핵심 기반이 된다.

⚛️ useLayoutEffect — DOM 변경 시점까지 제어하고 싶을 때

리액트를 처음 배울 때 가장 많이 쓰는 훅은 useEffect입니다. 그런데 분명 코드가 맞는데 “화면 깜빡임”, “스타일이 늦게 반영됨”, "스크롤 위치가 순간 튀는 현상" 등의 문제가 있을 때가 있습니다. 이럴 때 필요한 훅이 바로 useLayoutEffect입니다.

✔️ useEffect vs useLayoutEffect: 실행 시점의 차이

먼저 두 훅의 실행 흐름을 비교해볼게요.

React 렌더링 → (1) DOM 업데이트 → (2) useLayoutEffect 실행 → 브라우저가 화면에 그림 → (3) useEffect 실행

즉,

👉 중요한 포인트

useLayoutEffect는 렌더링을 블로킹합니다. 즉, 해당 콜백이 끝날 때까지 화면이 그려지지 않습니다.

그래서 잘 사용하면 깜빡임 없이 자연스러운 UI를 만들 수 있지만, 남용하면 성능이 나빠질 수 있습니다.

✔️ 예제: 실행 순서 비교

useEffect(() => {
  console.log('useEffect', count)
}, [count])

useLayoutEffect(() => {
  console.log('useLayoutEffect', count)
}, [count])

버튼을 클릭해 count가 변경되면 실행 순서는 항상 아래와 같습니다.

useLayoutEffect → useEffect

✔️ 언제 useLayoutEffect를 써야 할까?

DOM은 계산됐지만 브라우저에 그려지기 전 “그리기 전에 꼭 해야 하는 작업”이 있을 때

예를 들어:

• DOM 크기를 재고 해당 값으로 스타일을 조정해야 할 때
• 스크롤 위치를 정확히 특정 지점으로 이동시켜야 할 때
• 애니메이션 초기 상태를 DOM 기반으로 세팅해야 할 때
• 측정 기반 UI(Layout Shift 방지)가 필요할 때

즉, 화면에 깜빡임 없이 자연스럽게 초기 상태를 맞추고 싶을 때입니다.

⚛️ useContext — props drilling을 해결하는 리액트의 ‘전역 전달자’

리액트 컴포넌트 트리 구조에서는 부모가 가진 데이터를 자식, 손자, 증손자에게 전달해야 하는 경우가 많습니다.이걸 전부 props로 내려보내면 아래처럼 지옥 같은 코드가 됩니다.

<A props={value}>
  <B props={value}>
    <C props={value}>
      <D props={value} />
    </C>
  </B>
</A>

이걸 props drilling이라고 합니다.

✔️ useContext란?

Context는 리액트에서 “전역 데이터”를 공유하는 메커니즘입니다.

• Provider가 값을 제공하고
• 하위의 모든 Consumer(useContext 사용 컴포넌트)가 값을 사용할 수 있음

✔️ Context 사용 예제

const MyContext = createContext();

function Parent() {
  return (
    <MyContext.Provider value={{ hello: 'react' }}>
      <Child />
    </MyContext.Provider>
  )
}

function Child() {
  const value = useContext(MyContext);
  return <div>{value.hello}</div>
}

✔️ 그러나! useContext는 성능적으로 “독이 될 수 있다”

❗ Provider 하위의 컴포넌트는 값이 변경되면 전부 리렌더링된다

function ParentComponent() {
  const [text, setText] = useState('');

  return (
    <ContextProvider text={text}>
      <input value={text} onChange={handleChange} />
      <ChildComponent />
    </ContextProvider>
  );
}

이때 text가 바뀌면 화면에 출력하는 ChildComponent만 리렌더링될 것 같지만…

👉 ContextProvider 하위 트리는 모두 리렌더링됩니다.

콘솔 출력:

렌더링 GrandChildComponent
렌더링 ChildComponent
렌더링 ParentComponent

✔️ 해결: memo + context 분리

자식 컴포넌트를 memo로 감싸면 props가 변하지 않는 한 리렌더를 막을 수 있습니다.

const ChildComponent = memo(() => {
  return <GrandChildComponent />;
});

하지만 근본적인 해결책은:

• Context를 너무 많은 데이터 저장소로 사용하지 말 것
• Context를 역할별로 세분화해 분리할 것
• Recoil/Zustand/Jotai 같은 상태 라이브러리 고려

⚛️ useCallback — 함수를 재생성하지 않도록 메모이제이션하기

React에서 함수는 매 렌더링마다 새로 만들어집니다. 이게 문제되는 이유는 자식 컴포넌트 메모이제이션(memo)과 연관되기 때문입니다.

✔️ 문제 상황: memo를 썼는데도 자식이 계속 리렌더링됨

const Child = memo(({ value, onChange }) => {
  useEffect(() => console.log('렌더링', value));
  return <button onClick={onChange}>toggle</button>
});

부모:

function App() {
  const [status1, setStatus1] = useState(false);
  const [status2, setStatus2] = useState(false);

  const toggle1 = () => setStatus1(!status1);
  const toggle2 = () => setStatus2(!status2);

  return (
    <>
      <Child value={status1} onChange={toggle1} />
      <Child value={status2} onChange={toggle2} />
    </>
  );
}

버튼을 누를 때마다 두 Child 컴포넌트가 모두 리렌더링됩니다.

왜? 👉 onChange 함수가 매 렌더링마다 새로 생성되기 때문

✔️ 해결: useCallback 적용

const toggle1 = useCallback(() => {
  setStatus1(!status1)
}, [status1])

이제 함수는 의존 배열이 변경될 때만 새로 생성됩니다.

다시 렌더링을 확인하면:

• onChange가 변경된 컴포넌트만 리렌더링됨
• memo + useCallback 조합으로 최적화 성공

✔️ useCallback vs useMemo 차이

둘은 사실 거의 똑같은 훅이며, useCallback은 다음과 같은 sugar syntax일 뿐입니다.

useCallback(fn, deps) === useMemo(() => fn, deps)

하지만 이 개념들이 내부적으로 어떻게 동작하는지를 깊게 이해하고 나면, 성능 최적화나 구조 설계에서 “감으로 쓰는 코드”가 줄어들고, “어디를 어떻게 최적화해야 할지”를 훨씬 선명하게 판단할 수 있게 된다.

이번 글에서는 리액트의 핵심 개념 세 가지인 메모이제이션, 렌더링 구조, Virtual DOM + Fiber 아키텍처를 정리해보았다.

✔️ 메모이제이션 — “불필요한 연산을 기억하는 기술”

리액트에서 메모이제이션은 대표적으로 다음 훅이 있다.

• useMemo

• useCallback

• React.memo

이 세 가지는 형태는 다르지만 공통적으로 한 번 계산한 값, 한 번 만든 함수를 기억해뒀다가 재사용하는 역할을 한다. 즉, 매 렌더링마다 똑같은 일을 반복하지 않고, “이전 결과를 재활용할 수 있는 상황이라면 굳이 다시 계산하지 말자”라는 전략이다.

이 기술의 목적은 단 하나다.

💡 불필요한 재연산 또는 재렌더링을 줄여 성능을 최적화한다.

컴포넌트는 상태나 props가 조금만 변해도 다시 호출되기 때문에, 내부에 있는 연산이 비싸면 곧바로 렉이나 프레임 드랍으로 이어질 수 있다. 메모이제이션은 이런 “비싼 연산”이 꼭 필요할 때만 실행되도록 조건을 걸어 주는 장치라고 보면 된다.

useMemo — “값을 기억한다”

useMemo는 계산 비용이 큰 값을 기억한다. 말 그대로 “메모이제이션된 값”을 리턴하는 훅이다.

const value = useMemo(() => heavyCalc(a, b), [a, b]);

heavyCalc(a, b)를 상당히 무거운 연산이라고 가정해보자. useMemo를 사용하면 a 또는 b가 바뀔 때만 heavyCalc가 재실행되고, 그 외의 렌더링에서는 이전에 계산해 둔 결과를 그대로 재사용한다.

즉, “입력이 변하지 않았다면 굳이 다시 계산하지 말고, 캐시해 둔 값을 그대로 돌려주자”는 방식이다. 대량의 데이터 필터링, 복잡한 통계 계산, 포맷팅 등 한 번 계산하는 데 시간이 꽤 드는 작업에 주로 사용될 수 있다.

-> 함수가 실행되면 먼저 입력값에 해당하는 결과가 캐시에 있는지 확인하고, 이미 계산된 값이 있다면 다시 계산하지 않고 캐시된 결과를 그대로 반환한다. -> 반대로 캐시에 없다면 함수가 실제로 실행되어 결과를 만든 뒤, 그 값을 캐시에 저장해 두었다가 다음 호출에서 재사용한다.

1.2 useCallback — “함수의 주소값을 기억한다”

리액트의 함수형 컴포넌트는 렌더링될 때마다 함수가 다시 실행된다. 당연히 그 안에서 정의한 이벤트 핸들러 같은 함수들도 매 렌더링마다 새로 생성된다.

보통은 큰 문제가 없지만, 이 함수를 자식 컴포넌트에 props로 전달할 경우에는 상황이 달라진다. 자식 입장에서는 “매번 다른 함수(참조)가 들어왔다”고 느끼기 때문에, 실제 로직은 바뀌지 않았더라도 불필요하게 다시 렌더링될 수 있다.

이때 useCallback을 사용한다.

const handleClick = useCallback(() => {
  setCount(c => c + 1);
}, []);

useCallback은 말 그대로 “함수의 주소값(참조)을 기억해 두는 훅”이다. 의존성 배열에 있는 값이 바뀌지 않는 한, 렌더링이 여러 번 일어나더라도 동일한 함수 인스턴스를 재사용한다.

이 특징 때문에 React.memo와 함께 쓸 때 효과가 크다. 자식 컴포넌트가 React.memo로 감싸져 있고, props로 받은 함수가 useCallback으로 안정적으로 고정되어 있으면, 자식은 “props가 이전과 동일하다”고 판단해 렌더링을 건너뛸 수 있다.

-> 리액트가 전체를 다시 렌더링하지 않고, 바뀐 부분만 골라서 렌더링한다는 걸 보여준다.

• 왼쪽의 빨간 노드(Dirty): state가 변경된 컴포넌트
• 오른쪽의 파란 노드: 실제로 다시 렌더링된 부분

리액트는 이렇게 변경이 일어난 지점부터 아래로만 렌더링을 전파해 불필요한 계산을 줄이고 필요한 부분만 효율적으로 업데이트한다.

1.3 React.memo — “props가 같으면 렌더링하지 말자”

export default React.memo(MyComponent);

React.memo는 컴포넌트 전체를 메모이제이션하는 고차 컴포넌트다. 이렇게 감싸주면 리액트는 이 컴포넌트에 전달된 props를 얕게(shallow) 비교한 뒤, 이전 렌더링 때와 값이 완전히 동일하다면 컴포넌트 자체의 렌더링을 생략한다.

즉, 같은 props로 또 호출될 필요가 없는, 순수하게 UI만 그려주는 프리젠테이셔널 컴포넌트와 궁합이 좋다. 예를 들어 긴 리스트 아이템을 렌더링하는 컴포넌트라면, props가 변하지 않는 한 다시 렌더링할 이유가 없으니 React.memo로 감싸는 것만으로도 비용을 크게 줄일 수 있다.

✔️ 주의!

• 객체/배열/함수는 참조가 바뀌면 다른 props로 판단됨

• 그래서 상위 컴포넌트가 매 렌더링마다 새 객체/함수를 만들어서 넘기면, React.memo는 매번 “다른 props”라고 생각해 버린다

→ 따라서 useMemo/useCallback과 함께 사용해야 효과가 있음

예를 들어 onClick={() => ...}를 JSX 안에서 바로 만들기보다는, useCallback으로 감싸서 참조가 유지되도록 해주어야 React.memo의 장점을 온전히 누릴 수 있다.

1.4 정리

📌 메모이제이션은 무조건 쓰는 도구가 아니다. 필요할 때만 사용해야 한다.

잘못 사용하면 다음 문제가 발생할 수 있다.

• 메모리 사용량 증가 → 한 번 계산한 값을 계속 들고 있어야 하기 때문에, 캐시가 많아질수록 메모리를 더 많이 점유한다.

• 불필요한 비교 비용 발생 → 매 렌더링마다 “이전 값과 같은지”를 비교하는 비용이 추가로 발생하고, 이 비용이 오히려 득보다 실이 커질 수도 있다.

• 코드 복잡도 상승

• 컴포넌트 곳곳에 useMemo, useCallback, React.memo가 섞여 들어가면, 나중에 코드를 읽을 때 “왜 여기서 메모이제이션을 했는지” 맥락을 이해하기 어려워질 수 있다.

결국 “느리니까 일단 useMemo를 붙이자”가 아니라, “어떤 연산이 병목인지, 어느 지점이 진짜로 비용이 큰지”를 파악한 뒤 정밀하게 적용하는 것이 메모이제이션의 정석이다.

✔️ 리액트 렌더링 — “렌더링이란 무엇인가?”

많은 개발자가 혼동하는 부분이 바로 렌더링이 일어나는 조건과 단계다. 보통은 “렌더링 = 화면이 다시 그려지는 것”이라고 막연히 생각하지만, 리액트는 이 과정을 훨씬 더 세분화해서 다룬다.

리액트는 단순히 “화면이 다시 그려지는 것”만을 렌더링이라고 말하지 않는다. 실제로는 다음과 같은 두 단계로 구성된 매우 복잡한 작업이다. 이 두 단계가 분리되어 있기 때문에, 리액트는 계산과 실제 DOM 변경을 따로 관리하면서 효율을 높일 수 있다.

리액트 렌더링의 두 단계

① Render Phase (렌더 단계)

• 순수 함수처럼 실행되어 UI의 “스냅샷”을 생성

• React Fiber 트리를 기반으로 각 컴포넌트의 결과를 계산

• 필요하다면 작업 도중에 비동기적으로 중단 가능

• 이 단계에서는 DOM에는 아직 아무 변화도 일어나지 않음

즉, Render Phase는 “만약 이런 상태라면 UI가 어떻게 생겼어야 하는지”를 머릿속(가상 트리)으로 그려보는 과정이다. 계산만 수행할 뿐, 실제로 화면에 적용되지는 않는다.② Commit Phase (커밋 단계)

② Commit Phase (커밋 단계)

• Render Phase에서 계산한 결과를 바탕으로 실제 DOM을 변경

• useEffect, useLayoutEffect 같은 부수효과도 이때 실행

• 이 단계는 중단 불가, 반드시 끝까지 완료되어야 함

Commit Phase가 끝나야 비로소 사용자 눈에 보이는 화면이 바뀐다. 즉, 우리가 보는 “UI 업데이트”는 Commit Phase의 결과물이다.

-> Render Phase에서는 JSX를 기반으로 새로운 Fiber 트리를 만들고 이전 렌더 트리와 비교(diffing)을 수행한다. -> Commit Phase에서는 diff 결과를 기반으로 실제 DOM을 최소한으로 업데이트한다.

2.1 렌더링 발생 조건

다음 중 하나만 일어나도 렌더링이 발생한다.

• state 변경

• props 변경

• 부모 컴포넌트가 렌더링됨 (자식도 기본적으로 다시 렌더링)

• context 변경

리액트는 이런 변경 신호를 감지하면 해당 컴포넌트 및 자식들에 대해 Render Phase를 다시 수행한다.

그리고 여기서 중요한 점은…

❗ “렌더링이 일어났다고 해서 DOM이 무조건 변경되는 것은 아니다!”

• 렌더링(Render Phase) : 가상 DOM(Fiber 트리) 상에서 “무엇이 어떻게 달라졌는지”를 계산하는 단계, 리액트 내부 계산 영역

• 커밋(Commit Phase) : 이 계산 결과를 실제 DOM에 반영하는 단계

이렇게 두 단계를 분리해 두었기 때문에, 리액트는 렌더링(계산)은 자주 일어나도 괜찮게 만들고, DOM 변경은 정말 필요한 시점에 최소한으로만 수행하는 전략을 취할 수 있다.

✔️ Virtual DOM & React Fiber — “리액트 성능의 핵심”

리액트의 가장 유명한 개념 중 하나가 바로 Virtual DOM(가상 DOM)이다. 평소 리액트를 공부하다 보면 거의 무조건 등장하는 개념이기 때문에 익숙한 용어이지만, 동시에 “Virtual DOM이라서 브라우저 DOM보다 무조건 빠르다”라는 식의 오해도 많은 것 같다.

실제로는 Virtual DOM 자체가 마법처럼 빠른 것이 아니라, DOM을 직접 다루는 횟수와 범위를 줄여서 전체적인 퍼포먼스를 안정적으로 유지하기 위한 전략에 가깝다.

즉, Virtual DOM의 핵심은 “절대적인 속도”가 아니라, 다양한 UI 변경 상황에서 일관되게 ‘충분히 빠른’ 성능을 제공하는 구조에 있다.

3.1 Virtual DOM이 필요한 이유

브라우저 DOM 변경은 비용이 크다.

• 레이아웃 계산 (Reflow)

• 페인트(Paint)

• 복잡한 트리 구조 변경

DOM 요소를 자주 변경하면 브라우저는 레이아웃과 페인트를 반복해서 수행해야 하고, 화면이 복잡할수록 그 비용은 더 커진다.

리액트는 이러한 연산을 다음 순서로 최적화한다.

1. 변경되었을 것 같은 부분만 Virtual DOM에서 먼저 계산한다.

2. 이전 Virtual DOM과 비교(diff)해서 최소 변경 사항만 추려낸다.

3. 그 최소 변경 사항만 실제 DOM에 반영한다.

4. 필요 없는 렌더링은 Fiber의 스케줄링에 의해 중단하거나 연기할 수 있다.

즉…

💡 Virtual DOM의 목적은 “최소 변경만 DOM에 반영하기 위한 사전 계산 구조”이다.

DOM을 직접 마구 건드리는 대신, 한 단계 위에서 “어디를 어떻게 바꿀지”를 먼저 계산하고, 거기서 나온 diff만 실제 DOM에 적용하는 방식이라고 이해하면 된다.

3.2 React Fiber — 리액트 아키텍처의 핵심

Virtual DOM을 실제로 구현하는 기술이 바로 Fiber다. 단순히 “트리를 한 번에 재귀 순회”하는 수준이 아니라, 렌더링을 잘게 나누고 우선순위를 매기고, 중단·재개하는 데 최적화된** 리액트 전용 렌더링 엔진**이라고 보면 된다.

Fiber는 각 컴포넌트/DOM 노드를 나타내는 “작업 단위 객체”이며, 내부 구조는 다음과 같다.

• tag (타입: 함수 컴포넌트, 호스트 컴포넌트, 텍스트 등)

• pendingProps : 아직 처리되지 않은 새 props

• memoizedProps : 이전 렌더링에서 사용된 props

• stateNode : 실제 DOM 노드나 인스턴스

• child : 첫 번째 자식 Fiber

• sibling : 같은 레벨의 다음 형제 Fiber

• return : 부모 Fiber

• alternate (더블 버퍼링 구현을 위한 “쌍” Fiber)

이 정보들을 통해 리액트는 “현재 화면 상태”와 “새로 계산된 화면 상태”를 각각의 Fiber 트리로 관리하면서, 어떤 노드를 어떻게 업데이트해야 할지 세밀하게 제어할 수 있다.

-> React Fiber가 컴포넌트 트리를 내부적으로 어떻게 연결하는지를 보여준다. 각 Fiber 노드는 세 가지 포인터로 연결된다.

• child(빨간색): 첫 번째 자식 노드를 가리킴

• sibling(초록색): 형제 노드를 오른쪽으로 연결

• return(갈색): 부모 Fiber로 되돌아가는 링크

JSX의 계층 구조가 실제로는 이렇게 child → sibling → return 형태의 연결 그래프로 재구성되기 때문에, 리액트는 트리를 유연하게 순회하고 작업을 중단·재개할 수 있다.

3.3 Fiber의 강력한 특징

① 작업을 쪼갤 수 있다 (scheduling)

우선순위가 낮은 렌더링 작업은 나중에 수행하고, 사용자 입력 등 중요한 이벤트는 먼저 처리할 수 있도록 작업을 작은 단위로 쪼개고 스케줄링할 수 있다. 덕분에 큰 렌더링 작업이 있어도 UI가 완전히 멈춰버리는 상황을 줄일 수 있다.

② 작업을 중단하고 재개할 수 있다

SPA에서 많은 렌더링을 순차적으로 처리하면서 발생하던 버벅임을 없애기 위해, Fiber는 렌더링 도중에도 작업을 일시 중단할 수 있는 구조를 갖는다. 필요하다면 “여기까지 하고 잠깐 멈췄다가, 브라우저가 한숨 돌린 후에 다시 이어서 렌더링”하는 식으로 작업을 이어갈 수 있다.

③ 더블 버퍼링

- current 트리(화면에 보이는 상태)

- workInProgress 트리(작업 중인 상태)

리액트는 이 두 트리를 동시에 유지하다가, workInProgress 트리의 작업이 끝나면 포인터만 바꿔 current 트리로 승격시킨다. 이 방식 덕분에 DOM을 조금씩 바꾸다가 실패하는 일이 없고, 항상 “완성된 결과만 한 번에 커밋”해서 UI 일관성을 지킬 수 있다. -> _오른쪽의 Virtual DOM 영역: 현재 화면을 나타내는 Current Fiber Tree와 새로 렌더링을 준비하는 Work-in-Progress Tree가 함께 존재한다. _ -> _Render Phase: WIP 트리가 계산되며, Commit Phase가 되면 그 결과가 왼쪽의 실제 DOM 트리에 반영된다. _

“쓰지 않는 코드는 버려라.” — 번들 속 불필요한 잎사귀를 털어내는 기술

🌲 들어가며

대부분의 웹앱은 수많은 라이브러리로 구성됩니다. lodash, date-fns, moment, react-icons, three.js... 우리가 사용하는 코드보다 사용하지 않는 코드가 훨씬 많습니다.

이제 브라우저가 그 모든 코드를 다운로드하고, 파싱하고, 실행해야 한다면? 필요하지 않은 코드도 사용자 경험에 직접적인 성능 비용을 유발하게 됩니다.

이 문제를 해결하는 것이 바로 Tree Shaking입니다.

“빌드 단계에서 사용되지 않는(Dead) 코드를 제거해 번들을 더 작게 만드는 기술”

Tree Shaking 개념

Tree Shaking은 정적 분석(Static Analysis) 을 통해 사용되지 않는 코드를 “감지하고 제거”하는 번들 최적화 기술입니다.

말 그대로 트리에서 안 쓰이는 가지(코드)를 “털어내는(shake)” 과정이죠.

Tree Shaking 작동 원리 (사용되지 않는 코드 제거 과정)

• 상단의 Input: { Used: { scope1 } } 는 번들러(Webpack, Rollup 등)가 실제로 사용 중인 함수(scope1) 만 추적한다는 것을 의미합니다.
• 코드 내에서 scope1과 scope2는 실행되지만, scope3은 호출되지 않습니다.
• 따라서 scope3에서 사용하는 isNumber() 함수는 실제 빌드 결과에서 제거(Tree Shaking) 됩니다. 👉 Tree Shaking은 이렇게 “사용되지 않는 모듈(import)”을 정적 분석(Static Analysis) 을 통해 감지하고, 최종 번들에서 제외함으로써 파일 크기를 최소화하고 성능을 최적화합니다.

🌲 왜 Tree Shaking이 필요한가?

문제 상황

모듈 단위의 import/export 구조를 가지는 ES6(ESM) 환경에서는, 다음처럼 작은 기능 하나만 가져와도 사실상 전체 코드가 번들될 수 있습니다.

// utils.js
export function add(a, b) { return a + b; }
export function sub(a, b) { return a - b; }
export function mul(a, b) { return a * b; }

// main.js
import { add } from './utils.js';
console.log(add(2, 3));

위 코드의 결과는?

👉 기본적으로 add, sub, mul 세 함수가 모두 번들에 포함됩니다. 왜냐하면 번들러가 “어떤 함수가 실제로 쓰이는지” 분석하지 않으면 전체 모듈을 가져오기 때문입니다.

Tree Shaking은 이 중 사용된 함수(add)만 남기고, 나머지(sub, mul)를 제거합니다.

Tree Shaking 적용 전후 구조 비교

• 왼쪽(Before Tree Shaking): index.js가 여러 모듈(Module 1~3, file1~4.js)과 함수들을 참조하고 있습니다. 하지만 이 중 다수의 모듈과 함수는 실제 실행되지 않음에도 번들에 포함되어 있습니다.
• 오른쪽(After Tree Shaking): 번들러(Webpack/Rollup 등)가 정적 분석(Static Analysis) 을 통해 실제로 참조되는 함수(file3.js → function) 만 남기고, 사용되지 않는 코드(죽은 가지, Dead Code)를 모두 제거했습니다. 👉 Tree Shaking은 이렇게 “필요한 코드만 살아남게” 하여 번들 크기를 최소화하고, 불필요한 로드 및 파싱 비용을 줄이는 핵심 최적화 기법입니다.

🌲 Tree Shaking의 작동 원리

Tree Shaking은 ES Modules(ESM) 구조와 정적 분석(Static Analysis) 을 기반으로 작동합니다.

작동 단계

예시로 이해하기

// math.js
export const add = (a, b) => a + b;
export const minus = (a, b) => a - b;

// main.js
import { add } from "./math.js";
console.log(add(2, 3));

빌드 결과 (Before)

const add=(a,b)=>a+b;const minus=(a,b)=>a-b;console.log(add(2,3));

빌드 결과 (After Tree Shaking)

console.log(((a,b)=>a+b)(2,3));

👉 minus()는 제거됨

ES Module의 Binding 구조

• ES Module은 단순히 값을 복사하지 않고, “참조(reference)”로 연결된 바인딩(binding) 을 유지합니다.
• 즉, 한 모듈에서 export한 변수가 변경되면, 이를 import한 다른 모듈에서도 자동으로 최신 값이 반영됩니다.
• 하지만 반대로 import한 쪽에서 값을 변경하려는 시도는 불가능합니다 (읽기 전용 바인딩). 👉 이러한 정적 구조적 연결성 덕분에 Tree Shaking 같은 정적 분석 기반 최적화가 가능해집니다.

🌲 Tree Shaking이 가능한 전제 조건

Tree Shaking이 작동하려면 몇 가지 필수 조건이 있습니다.

// webpack.config.js
module.exports = {
  mode: "production",
  optimization: { usedExports: true },
};

🧭 주의: CommonJS(require)는 동적 import 경로를 분석할 수 없어 Tree Shaking이 불가능합니다.

ESM vs CJS: Tree Shaking이 가능한 이유

• CJS(CommonJS) 는 require()를 런타임에 실행하므로, 어떤 모듈이 실제로 사용될지 정적 분석 시점에 알 수 없습니다.
• ESM(ES Modules) 은 import/export가 파일 상단에서 정적으로 선언되기 때문에, 번들러(Webpack, Rollup 등)가 의존 그래프를 쉽게 분석하여 사용되지 않는 코드를 안전하게 제거(Tree Shaking) 할 수 있습니다. 👉 Tree Shaking은 ESM의 정적 구조 덕분에 가능한 최적화입니다.

🌲 Tree Shaking vs Dead Code Elimination (DCE)

결국 Tree Shaking은 DCE의 전처리 단계라고 볼 수 있습니다. → 번들러가 “무의미한 export”를 제거하고, → 압축기가 “조건상 절대 실행되지 않는 코드”를 제거합니다.

🌲 Tree Shaking의 한계와 실패 사례

// babel.config.json { "presets": [["@babel/preset-env", { "modules": false }]] }

``` 배럴 파일 import 문제 도식

• index.js에서 모든 모듈을 한꺼번에 export하면, 사용되지 않는 함수까지 모두 번들 파일(bundle.js) 에 포함됩니다.
• 즉, Tree Shaking이 제대로 작동하지 않아 번들 크기가 커지는 원인이 됩니다. 👉 "배럴 구조는 Tree Shaking의 적"이라고 할 수 있습니다.

🌲 마무리

Tree Shaking은 “코드를 지운다”는 행위가 아닙니다. “사용자에게 도달하지 않는 코드가 존재하지 않도록 한다”는 원칙입니다.

즉, 성능 최적화의 목적은 “코드를 덜 쓰는 것”이 아니라, “사용하지 않는 코드를 아예 배포하지 않는 것”이죠.

이건 결국 “사용자의 다운로드 시간을 줄이는 UX 최적화”이기도 합니다.

Tree Shaking은 가벼운 사용자 경험을 위한 사전 청소기다.

한 번에 다 불러오지 말고, 필요한 시점에 나눠서 불러와라

✂️ 들어가며

SPA(Single Page Application)는 한 번 로드되면 앱 전체를 빠르게 사용할 수 있다는 장점이 있습니다. 하지만 문제는 처음 로드되는 "한 번"이 너무 무겁다는 점이죠.

초기 번들이 너무 크면,

• 페이지 진입 속도는 느려지고,
• 사용자는 첫 화면을 보기 전부터 지루해하며,
• 브라우저는 파싱·실행하느라 메인 스레드를 점유합니다.

이때 필요한 전략이 바로 Code Splitting(코드 분할)입니다.

“앱 전체 코드를 한 덩어리로 불러오지 말고, 필요한 순간에 나눠서 불러온다.”

왜 코드 분할이 필요한가?

문제 상황: 번들 크기 폭발

현대 프론트엔드는 하나의 번들 파일(bundle.js)에 다음이 모두 들어갑니다:

• React / Vue / Lodash 같은 공통 라이브러리
• 모든 페이지/컴포넌트의 코드
• 스타일, 폰트, 이미지 등 정적 리소스

결과적으로 “첫 화면을 띄우기 위해 10만 줄의 코드”를 받게 됩니다.

하나의 번들로 묶인 구조 (Webpack 번들링 개념도)

• 왼쪽: 여러 개의 모듈(자바스크립트, Sass, 이미지 등)이 서로 의존 관계를 맺고 있습니다.
• 가운데: Webpack이 이 모든 파일을 하나의 번들(bundle) 로 묶어주는 과정입니다.
• 오른쪽: 번들링 결과물로, .js, .css, .jpg, .png 등의 정적 자산(Static Assets) 이 생성됩니다. 👉 이처럼 번들링은 프로젝트의 모든 자원을 하나로 압축하지만, 모든 코드가 한 번에 로드되어 초기 성능 저하를 초래할 수 있습니다. 따라서 이후 단계에서 Code Splitting(코드 분할) 을 통해 필요한 부분만 나누어 불러오는 최적화가 이루어집니다.

✂️ Code Splitting 개념

Code Splitting은 애플리케이션 코드를 여러 개의 작은 번들(Chunk)로 분리하여, 필요한 시점에만 네트워크로 로드하는 기법입니다.

즉, 앱을 기능 단위로 쪼개서 “사용자가 필요한 순간”에만 불러옵니다.

# 예시
main.js         (기본 UI)
chart.js        (통계 페이지용)
admin.js        (관리자 페이지용)

이렇게 분할하면 초기 로딩 때 main.js만 다운로드하고, 관리자 페이지로 이동할 때 admin.js를 나중에 불러옵니다.

Code Splitting 구조도

• 상단: 기존에는 모든 코드가 하나의 bundle.js 안에 묶여 있어, 페이지를 처음 로드할 때 모든 스크립트가 한꺼번에 다운로드되었습니다.
• 하단: Code Splitting을 적용하면, 코드를 여러 개의** chunk 파일(chunk.js)** 로 나누어 사용자가 특정 페이지나 기능을 요청할 때만 해당 코드가 로드됩니다. 👉 초기 로딩 속도를 줄이고, 사용자가 실제로 필요로 하는 기능만 즉시 로드할 수 있습니다.

✂️ 동작 원리: 번들러가 코드를 나누는 방법

번들링의 기본

Webpack, Vite, Rollup 같은 번들러는 모든 JS 파일의 의존 관계 그래프를 분석하여 하나의 파일로 묶습니다.

하지만 다음 조건을 만나면 자동으로 “청크(Chunk)”를 나눕니다.

1. 동적 import 사용 (import()) 2. React.lazy() 등 lazy load 선언 3. Route-level Split (페이지 단위 분리)

// before
import Chart from './Chart';

// after
const Chart = React.lazy(() => import('./Chart'));

👉 import()가 등장하는 순간, Webpack은 해당 모듈을 별도 청크(chart.chunk.js)로 분리합니다. 브라우저는 실제로 그 코드가 필요해질 때 네트워크 요청을 보냅니다.

Webpack 의존 그래프 구조도

• 상단(bootstrap.main.ts) 은 애플리케이션의 Entry Point 로, Webpack이 번들링을 시작하는 진입점입니다.
• 중앙(app.component.js) 에서 여러 모듈(external.lib.js, some.component.ts)로 의존 관계(Dependency) 가 확장됩니다.
• 각 모듈은 또 다른 파일(.css, .sass, .dep.js)을 불러오며, Webpack은 이 관계들을 모두 연결해 의존 그래프를 형성합니다. 👉 번들러는 이 그래프를 기반으로 ** 코드 분할(Code Splitting)** 이 필요한 지점을 자동으로 감지하고, 필요할 때만 해당 모듈을 로드하도록 청크를 생성합니다.

✂️ React에서 Code Splitting 적용하기

1️⃣ 라우트 기반 분할

페이지 전환 시 필요한 컴포넌트만 불러오는 방법입니다.

// routes/Dashboard.jsx
export default function Dashboard() {
  return <h1>📊 Dashboard</h1>;
}

// App.jsx
import { Suspense, lazy } from 'react';
const Dashboard = lazy(() => import('./routes/Dashboard'));
const Settings = lazy(() => import('./routes/Settings'));

export default function App() {
  return (
    <Suspense fallback={<div>로딩 중...</div>}>
      <Router>
        <Route path="/dashboard" element={<Dashboard />} />
        <Route path="/settings" element={<Settings />} />
      </Router>
    </Suspense>
  );
}

• lazy()는 동적 import를 감싸는 React 도우미
• Suspense는 로딩 중 fallback UI를 보여주는 역할

Code Splitting 적용 전: 모든 스크립트가 한 번에 로드되는 모습

• Chrome DevTools의 Network 탭에서 확인한 결과,페이지 진입 시 index.js, main.js, _app.js, webpack.js 등
• 모든 스크립트 파일이 동시에 요청*되고 있습니다.
• 이런 구조에서는 사용자가 방문하지 않는 페이지의 코드까지 미리 로드되기 때문에 초기 로딩 시간이 길어지고, TTI(Time To Interactive) 도 지연됩니다. 👉 Code Splitting을 적용하면, 이러한 스크립트 중 실제로 필요한 청크만 먼저 로드되어 초기 성능이 크게 개선됩니다.

2️⃣ 컴포넌트 단위 분할

큰 라이브러리(예: Chart.js, Editor 등)는 초기 번들에서 제외하고 사용 시점에만 로드하도록 분할합니다.

const Chart = lazy(() => import('./components/HeavyChart'));
...
<Suspense fallback={<Spinner />}>
  <Chart />
</Suspense>

👉 사용자가 “차트 영역”을 보기 전까지 관련 라이브러리(JS, CSS)는 네트워크 요청조차 발생하지 않습니다.

✂️ 분할 전략의 종류

✂️ Code Splitting의 부작용과 주의점

✂️ Code Splitting + Prefetch / Preload

Code Splitting을 했더라도, 사용자가 자주 갈 페이지라면 미리 당겨받을 수도 있습니다.

<link rel="prefetch" href="/settings.chunk.js" />
<link rel="preload" href="/main.chunk.js" as="script" />

Preload 적용 전후 렌더링 비교 (Financial Times 실험 예시)

• 상단(1: before preload): Preload를 적용하기 전, 초기 화면이 2.5초까지 거의 비어 있다가 3.0초 이후에야 주요 콘텐츠가 렌더링되기 시작합니다.
• 하단(2: with preload): Preload를 적용한 뒤, 핵심 리소스가 사전에 요청되어 초기 렌더링 시점이 1초 이상 빨라졌습니다. 👉 Preload는 “지금 필요한 리소스”를 미리 불러와 사용자에게 더 빠른 첫 화면(FCP, LCP)을 제공하는 효과를 냅니다.

✂️ 성능 검증 방법

Code Splitting 후의 번들 크기 시각화 (Webpack Bundle Analyzer)

• 이 트리맵은 번들 파일(bundle.js) 내부의 구성 요소를 시각적으로 분석한 결과입니다.
• 왼쪽(node_modules) 영역에는 외부 라이브러리(apexcharts, react-dom, react-slick 등)가, 오른쪽(src) 영역에는 애플리케이션 자체 코드(index.tsx, tailwind.css)가 포함되어 있습니다.
• 각 블록의 크기는 해당 모듈이 번들 내에서 차지하는 파일 크기 비중을 의미합니다. 👉 이처럼 Code Splitting을 적용하면, 필요한 라이브러리나 기능 단위로 번들을 나눠서 관리할 수 있고, 과도하게 큰 모듈(apexcharts.common.js 등)을 분리하거나 Lazy Loading 대상으로 최적화할 수 있습니다.

✂️ 마무리

코드 분할은 단순히 파일을 나누는 기술이 아닙니다. “사용자 경험을 기준으로 로딩 순서를 설계하는 전략”입니다.

초기 로딩이 가벼워질수록, 사용자는 앱이 즉시 반응한다고 느낍니다. 이것이 “빠름”의 심리적 체감 속도입니다.

필요한 시점에 필요한 코드만 로드하라.

“보이는 순간만 로드한다”

💤 들어가며

웹페이지가 느린 이유는 단순히 코드가 많아서가 아닙니다. 초기 로딩 시 필요하지 않은 리소스까지 모두 불러오기 때문입니다.

이미지, 동영상, 외부 스크립트, 차트 라이브러리… 사용자가 아직 스크롤하지도 않았는데 모두 다운로드된다면, 네트워크는 ‘필요 없는 일’을 먼저 처리하고 있는 셈이죠.

이 문제를 해결하는 것이 바로 Lazy Loading (지연 로딩) 입니다. 즉, “사용자가 실제로 볼 때만 리소스를 불러오는 기술”입니다.

💤 Lazy Loading 개념

Lazy Loading은 브라우저의 기본 작동 방식을 “지연시켜” 필요한 순간에만 네트워크 요청을 발생시키는 전략입니다.

즉, 로딩 타이밍을 이렇게 바꿉니다.

Before vs After Lazy Loading

• 왼쪽 (Traditional Loading): 페이지가 열리자마자 모든 콘텐츠를 한꺼번에 로드 → 초기 로딩 속도 저하
• 오른쪽 (Lazy Loading): 사용자가 스크롤할 때마다 화면에 보이는 콘텐츠만 로드 → 초기 렌더링 시간 단축 👉 Lazy Loading은 “보이는 순간에만 필요한 데이터를 로드한다”는 원리로 작동하며, 페이지 로드 성능을 향상시키고 불필요한 네트워크 요청을 줄이는 대표적인 렌더링 최적화 기법입니다.

💤 Lazy Loading의 동작 원리

1️⃣ Intersection Observer API

브라우저가 특정 요소가 뷰포트에 진입했는지 감시하는 기능입니다. 이때 감시 대상이 화면에 등장하면 이미지 로드 요청을 트리거합니다.

useEffect(() => {
  const observer = new IntersectionObserver((entries) => {
    entries.forEach((entry) => {
      if (entry.isIntersecting) {
        entry.target.src = entry.target.dataset.src; // 진입 시 이미지 로드
        observer.unobserve(entry.target);
      }
    });
  });

  document.querySelectorAll("img[data-src]").forEach((img) => observer.observe(img));

  return () => observer.disconnect();
}, []);

• isIntersecting: 해당 요소가 뷰포트 안으로 들어왔는가
• observer.unobserve: 한 번 로드된 요소는 다시 감시하지 않음
• data-src: 아직 로드하지 않은 이미지 URL을 임시로 보관

Intersection Observer 작동 원리

• 파란색 root는 브라우저의 Viewport이며, 감시 기준이 되는 영역입니다.
• true는 현재 Viewport 안에 있는 요소, false는 화면 밖에 있는 요소를 의미합니다.
• 스크롤 시 요소가 root 경계선에 도달하면 Intersection Observer가 이를 감지하여 Lazy Loading, Infinite Scroll, 애니메이션 실행 등의 로직을 자동으로 수행합니다.

2️⃣ 브라우저 기본 속성 loading="lazy"

최근 대부분의 브라우저(Chrome, Edge, Firefox)는 HTML 속성 하나로 기본 Lazy Loading을 지원합니다.

<img src="photo.jpg" loading="lazy" alt="sample image" />

• 지원 브라우저: Chrome 76+, Edge 79+, Firefox 75+
• 비지원 브라우저(사파리 등)는 JS 폴리필(IntersectionObserver)을 함께 사용

이 속성 하나로 이미지 로딩 타이밍을 자동으로 최적화할 수 있습니다. Chrome은 기본적으로 뷰포트의 약 1250px 근처에 진입하면 요청을 시작합니다.

🧭 Tip: loading="lazy"는 <iframe> 태그에도 적용됩니다. → YouTube, Map, 광고 등의 embed 콘텐츠를 늦게 로드할 수 있습니다.

rootMargin과 사전 로딩 거리

const observer = new IntersectionObserver(callback, {
  rootMargin: "200px",
});

• rootMargin은 화면 경계선 앞뒤 여유 거리입니다.
• 200px로 설정하면, 이미지가 화면에 200px 전에 미리 로드됩니다.
• 지나치게 작으면 이미지가 깜빡이며 로드되고,너무 크면 Lazy Loading의 효과가 줄어듭니다.

🧭 추천 값: 200px ~ 400px (사용자 스크롤 속도에 따라 조정)

Intersection Observer 속성 개념도

• 왼쪽의 Root: 브라우저의 Viewport(감시 기준 영역)를 의미하며,
• 가운데의 Root Margin: Viewport 바깥쪽 여유 영역으로, 미리 로드를 유도해 화면 깜빡임을 줄입니다.
• 오른쪽의 Threshold: 요소가 화면에 얼마나 보여야 콜백이 실행될지를 결정합니다. 👉 적절한 rootMargin과 threshold 설정은 스크롤 시 더 부드러운 사용자 경험을 제공합니다.

💤 Lazy Loading 적용 예시

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

function LazyImage({ src, alt }) {
  const [isVisible, setVisible] = useState(false);
  const imgRef = useRef(null);

  useEffect(() => {
    const io = new IntersectionObserver(([entry]) => {
      if (entry.isIntersecting) setVisible(true);
    }, { rootMargin: "300px" });

    if (imgRef.current) io.observe(imgRef.current);
    return () => io.disconnect();
  }, []);

  return (
    <img
      ref={imgRef}
      src={isVisible ? src : "/placeholder.jpg"}
      alt={alt}
      loading="lazy"
      style={{ width: "100%", borderRadius: "8px" }}
    />
  );
}

export default function Gallery() {
  return (
    <section>
      <h2>Lazy Loaded Gallery</h2>
      <div className="grid">
        {Array.from({ length: 12 }, (_, i) => (
          <LazyImage
            key={i}
            src={`/images/photo-${i + 1}.jpg`}
            alt={`photo-${i}`}
          />
        ))}
      </div>
    </section>
  );
}

Lazy Loading 동작 예시

• 왼쪽: 스크롤 전 상태로, 아직 실제 이미지가 로드되지 않아 저해상도 Placeholder(블러 처리 이미지)가 보입니다.
• 오른쪽: 사용자가 스크롤해 해당 위치에 도달했을 때, 실제 고해상도 이미지가 로드되어 자연스럽게 전환된 모습입니다. 👉 Lazy Loading은 이런 방식으로 불필요한 초기 로딩을 줄이고 스크롤에 맞춰 콘텐츠를 점진적으로 표시합니다.

💤 Lazy Loading의 한계와 주의점

💤 Lazy Loading 적용 후 측정 방법

Lazy Loading 성능 비교 그래프

• 그래프 설명: WordPress 사이트를 기준으로, 네이티브 이미지 Lazy Loading을 적용했을 때와 그렇지 않을 때의 LCP(Largest Contentful Paint, 핵심 콘텐츠가 렌더링되기까지의 시간)을 비교한 결과입니다.
• 좌측(No): Lazy Loading 미적용 시, 브라우저가 모든 이미지를 한꺼번에 로드해 LCP가 더 길게 측정되었습니다.
• 우측(Yes): Lazy Loading 적용 시, 초기 렌더링에 필요한 이미지만 우선 로드되어 LCP가 단축되었습니다. 👉 Lazy Loading은 페이지 초기 로딩 성능을 향상시키고, 사용자 체감 속도를 개선하는 데 효과적입니다.

💤 마치며

Lazy Loading은 “기술적으로 어렵지 않은데, 가장 효과가 큰 최적화”입니다. 이미지 한 장만 줄여도 LCP가 절반 가까이 개선되는 경우도 있습니다.

가장 중요한 원칙은 단 하나입니다.

“사용자가 실제로 보는 순간에만 로드하라.”

필요한 시점에 필요한 리소스를 보내면, 사용자 경험은 자연스럽게 부드럽고 빠른 서비스로 바뀝니다.

수천 개의 데이터를 한 화면에 “한 번에” 렌더링하지 않는 이유

💭 들어가며

웹 서비스가 커질수록 “리스트”는 폭발적으로 늘어납니다. 상품 목록, 알림함, 채팅 메시지, 피드, 로그 — 모두 리스트 형태입니다.

그런데 리스트 아이템이 1,000개만 넘어도 브라우저는 숨이 찹니다. 스크롤이 버벅이고, 메모리 사용량이 치솟고, TTI(대화 가능 시점)은 지연됩니다.

이때 등장하는 것이 바로 데이터 리스트 가상화(Data List Virtualization)입니다. 한마디로 말하면 “보이는 만큼만 렌더링한다”는 기술이죠.

💭 렌더링은 ‘보이는 것보다 더 많다’

일반적인 리스트 컴포넌트는 이렇게 동작합니다.

function List({ items }) {
  return (
    <div>
      {items.map((item) => (
        <div className="row" key={item.id}>
          {item.title}
        </div>
      ))}
    </div>
  );
}

데이터가 1,000개라면 <div>가 1,000개 생성됩니다. 하지만 실제로 사용자가 한눈에 볼 수 있는 항목은 10~15개에 불과하죠.

이런 상황에서 브라우저는 다음과 같은 일을 합니다:

결과적으로 스크롤이 버벅이고, 모바일에서는 렌더링 중단(Frozen Frame)이 발생하기도 합니다.

• DOM 노드 증가에 따라 JS Heap과 FPS가 주기적으로 상승·하락
• 렌더링 부하가 누적되며 브라우저가 Reflow/Repaint를 반복하는 패턴 확인 👉 “DOM이 많아질수록 브라우저의 렌더링 비용이 급격히 증가한다”

💭 “가상화(Virtualization)”란 무엇인가?

데이터 리스트 가상화는 다음 한 문장으로 요약됩니다.

“보이는 영역(뷰포트) + 주변 버퍼만 렌더링하고, 나머지는 가짜 높이로 대체한다.”

즉, 실제 DOM에는 일부만 존재하지만, 브라우저는 전체 스크롤 높이를 가상으로 계산해 마치 전부 있는 것처럼 보여줍니다.

동작 개념

• 왼쪽(Regular Scrolling): 리스트의 모든 아이템(item 998~item 1006)이 실제 DOM에 렌더링되어 있어, 항목이 많아질수록 레이아웃 계산과 페인트 비용이 급증합니다.
• 오른쪽(Virtualized Scrolling): 현재 화면(visible viewport) 안의 항목(item 1000~item 1005)만 실제 DOM에 존재하며, 위아래 항목은 존재하지 않거나 가상의 패딩 공간으로 대체됩니다. 👉 “보이는 부분만 렌더링”함으로써 브라우저의 렌더링 부하를 크게 줄이고 FPS를 안정적으로 유지할 수 있습니다.

💭 브라우저는 이렇게 처리한다 (작동 원리)

리스트 가상화는 세 가지 핵심 원리로 작동합니다.

① Viewport 계산

• 현재 스크롤 위치(scrollTop)와 화면 높이(clientHeight)를 이용해 “지금 보여줘야 할 항목의 인덱스 범위”를 계산합니다.
• 예: scrollTop=500이면 startIndex=10, endIndex=25 정도로 계산

② 가짜 컨테이너 높이 유지

• 실제 렌더링된 항목 외에도, 리스트 전체 높이를 유지하기 위해 상단/하단에 padding element(빈 div)를 둡니다.
• 이렇게 하면 스크롤바 길이는 실제 전체 데이터와 동일하게 보입니다.

③ 항목 재활용(Recycling)

• 스크롤할 때마다 DOM을 새로 만들지 않고, 기존 노드의 위치와 내용만 교체합니다.
• 즉, DOM 수는 일정하게 유지되며 스크롤만 가상적으로 “이동”합니다.
• 브라우저 렌더링 파이프라인 (Critical Rendering Path)*
• Network 단계: HTML, CSS, JS 파일이 다운로드됨
• DOM & CSSOM 생성: HTML → DOM, CSS → CSSOM 구조로 파싱
• Render Tree 결합: 브라우저가 어떤 요소를 어떤 스타일로 그릴지 결정
• Layout: 각 요소의 크기와 위치를 계산
• Paint: 픽셀 단위로 화면에 실제로 그려짐 👉 Virtualization은 이 중 Layout → Paint 구간에서의 작업량을 줄여, 브라우저가 모든 리스트 아이템을 매번 다시 계산하지 않도록 하여 스크롤 성능을 향상시키는 핵심 최적화 방식입니다.

💭 구현 방식 비교

💭 렌더링 병목 구간 예시

Virtualization 적용 전 렌더링 병목 구간 (DevTools Performance Timeline)

• 노란색(Rendering): Layout 및 스타일 재계산(Recalculate Style) 단계 — DOM이 많을수록 빈번히 발생
• 빨간색(Painting): 픽셀을 다시 그리는 과정(Repaint) — 스크롤이나 화면 갱신 시 자주 호출
• 보라색(Scripting): JavaScript 로직 실행 👉 Rendering과 Painting이 촘촘히 반복되는 것은 브라우저가 매 프레임마다 화면 전체를 다시 그리는 비효율적인 상태임을 의미합니다. 👉 Virtualization을 적용하면 이 과정 중 불필요한 Layout/Paint 호출이 제거되어, 렌더링 부하가 줄고 FPS가 안정적으로 유지됩니다.

💭 장단점

| 구분 |
| ----- | -------------------------------------------------------------------------------- | ✅ 장점 | - DOM 렌더링 최소화
- 메모리 사용량 감소
- 모바일 스크롤 프레임 유지
- 초기 로드 속도 향상 | | | ⚠️ 단점 | - SEO(검색엔진)가 전체 데이터 접근 불가
- 키보드 포커스 이동 시 항목 언마운트 문제
- 동적 높이 항목에서 위치 계산 어려움 | |

🧭 Tip: 가상화는 “렌더링 성능 최적화”이지, 데이터 요청 최적화는 아닙니다. API 호출은 별도로 페이지네이션·캐싱과 함께 관리해야 합니다.

💭 실제 적용 시 고려 사항

1. 항목 높이

• 고정 높이면 react-window
• 유동 높이면 react-virtualized
• 가변 콘텐츠는 CellMeasurer 활용

2. 스크롤 컨테이너 구조

• 반드시 overflow: auto 또는 scroll이 지정된 부모 필요
• 상하 padding element로 스크롤 높이 보정

3. A11y (접근성)

• 보이지 않는 항목은 스크린리더 탐색 불가
• 가상화 시 aria-live 영역으로 시각적/논리적 순서 보정

4. SEO

• 검색엔진 크롤러는 JS 실행 없이 HTML만 읽을 수 있음 → SSR 또는 CSR 하이브리드 전략 필요

5. 테스트 포인트

• 스크롤 시 CPU 점유율
• Reflow/Repaint 횟수
• Long task 발생 여부

Lazy Loading 동작 시각화

• 왼쪽: 여러 개의 600×600 이미지 블록이 나열되어 있으며, 화면 스크롤에 따라 새로운 이미지가 등장함
• 오른쪽: Chrome DevTools의 Network 탭에서, 스크롤 시점마다 새 이미지 요청(.jpg, .png)이 발생하는 것을 확인할 수 있음 👉 Lazy Loading은 뷰포트 안에 들어온 이미지만 네트워크 요청을 보내는 방식으로, 페이지 초기 렌더링 속도를 개선하고 트래픽을 절감하는 대표적인 프론트엔드 최적화 기법입니다.

💭 Virtualization이 특히 효과적인 경우

💭 Virtualization과 함께 쓰면 좋은 기술

💭 마무리

데이터 리스트 가상화는 브라우저 성능의 “생명줄”입니다. DOM이 1만 개든, 10만 개든, 사용자가 보는 건 한눈에 보이는 몇십 개뿐이죠.

Virtualization은 사용자가 체감하는 부드러움을 위해 렌더링 리소스를 “지금 필요한 부분”에만 집중시키는 기술입니다.

즉, 이것은 단순한 렌더링 트릭이 아니라 UX 중심 성능 설계(Performance-Driven UX)의 핵심입니다.

왜 Hook을 쓰는가 — 로직 재사용보다 “관심사 분리”

처음엔 useState, useEffect로 충분하다. 하지만 컴포넌트가 커지면 이런 현상이 생긴다 👇

• UI 로직과 비즈니스 로직이 섞여 가독성이 떨어짐
• 상태 변화가 많아 디버깅이 어려워짐
• 비슷한 로직을 여러 컴포넌트에서 반복

이때 커스텀 훅(Custom Hook) 은 “로직을 옮겨놓는 함수”가 아니라, 컴포넌트가 가져야 할 책임을 분리하고 독립시키는 도구로 보는 게 중요하다.

“Hook은 코드를 분리하는 수단이 아니라, 책임을 분리하는 수단이다.”

useState / useEffect로는 충분하지 않을 때

React의 초반 단계에서는 대부분 이렇게 작성한다.

function Example() {
  const [count, setCount] = useState(0);
  useEffect(() => {
    console.log("Count changed:", count);
  }, [count]);
}

문제는, 기능이 늘어날수록 useEffect가 점점 복잡해지고 *“의존성 지옥” *이 시작된다는 것이다.

useEffect(() => {
  fetchData();
  handleResize();
  handleAuthCheck();
}, [token, width, isLoggedIn]);

각 로직이 서로 영향을 주고받으며 렌더링 타이밍, 비동기 처리, 상태 동기화 문제가 꼬이기 시작한다. 이 시점이 바로 커스텀 훅을 도입해야 할 타이밍이다.

커스텀 훅으로 분리하는 기준

많은 개발자들이 처음엔 useLogin, useFetch, useForm 처럼“기능 단위”로 훅을 만든다. 하지만 진짜 좋은 분리는 ‘하나의 책임(Responsibility)’에 집중된 훅이다.

예를 들어 useFetch라는 훅은 “데이터 요청 + 에러 핸들링 + 로딩 상태”라는 하나의 책임에 집중되어 있다면 괜찮다. 하지만 여기에 “토큰 갱신”이나 “자동 재시도”까지 들어간다면 이미 역할이 넘친 상태다.

훅 간 의존성 관리 — Controller 패턴

커스텀 훅을 많이 만들다 보면 이런 문제가 생긴다.

“A 훅 안에서 B 훅을 직접 호출하면 안 되나?”

가능은 하지만, 훅 간 결합도가 올라가고 재사용성이 떨어진다.

이럴 때 효과적인 방법은 Controller 훅 패턴이다. 즉, 여러 하위 훅을 조립하고 상위 레벨에서 데이터 흐름을 제어하는 방식이다.

function useController() {
  const { data, error, refetch } = useFetch("/api/data");
  const { isOpen, toggle } = useModal();
  const { value, onChange } = useFormField("");

  // 데이터 흐름 조립
  useEffect(() => {
    if (error) toggle(true); // 에러 시 모달 오픈
  }, [error]);

  return { data, error, isOpen, toggle, value, onChange, refetch };
}

이렇게 하면 각각의 훅은 하나의 책임에 집중하고, Controller 훅은 전체 로직을 조율하는 역할만 맡게 된다.

Hook 구조 설계 패턴 3가지

프로젝트 단위에서 커스텀 훅을 설계할 때는 3단계 구조로 나누면 깔끔하다.

① Controller Hook

여러 훅을 조립해 데이터 흐름을 제어

예: useDashboard, useAuthFlow

• 책임: 전체 로직 통합, 의존성 조율
• 장점: 상위 로직이 한눈에 들어옴
• 단점: 커지면 또 비대해질 수 있음

② State Hook

특정 도메인의 상태를 캡슐화

예: useUserState, useThemeState

• 책임: 상태와 업데이트 로직 관리
• 장점: 독립적인 상태 관리 가능
• 단점: 전역 남용 시 데이터 추적 어려움

③ Utility Hook

순수 기능만 수행, 사이드이펙트 없음

예: useInterval, usePrevious, useMediaQuery

• 책임: 보조 로직 제공
• 장점: 재사용성 높음, 테스트 쉬움
• 단점: 너무 세분화하면 관리 복잡

  💡 패턴 정리: “Controller → State / Utility” 구조로 나누면 데이터 흐름이 명확하고, 유지보수가 쉬워진다.

훅의 이름은 역할을 드러내야 한다

좋은 훅은 이름만 봐도 무슨 일을 하는지 알 수 있다. 나쁜 훅은 “이 훅이 뭘 하는지 직접 열어봐야” 알 수 있다.

// ❌ 나쁜 예시
useCommonLogic();
useSomething();

// ✅ 좋은 예시
useModalVisibility();
useAuthVerification();
useKeyboardShortcut();

“무엇을 하는가?”가 아니라 “왜 존재하는가?”를 드러내는 네이밍이 좋다.

Hook을 설계할 때 자주 하는 실수

결론: 훅은 로직 재사용보다 데이터 흐름을 명시화하는 도구

결국 커스텀 훅의 목적은 “로직을 옮기는 것”이 아니라, 상태 → 로직 → UI의 흐름을 명확히 보여주는 것이다.

Hook은 기술이 아니라 사고방식이다. 컴포넌트를 “UI 중심”이 아니라 “데이터 흐름 중심”으로 바라보게 만들어준다.

클로저 · 싱글 스레드 · 이벤트 루프 · 렌더링 프로세스

리액트 심화 개념(예: 렌더링 최적화, useCallback, useMemo, 비동기 상태 업데이트 등)을 이해하려면 자바스크립트의 실행 원리를 탄탄히 아는 것이 필수입니다.

이번 글에서는 리액트를 공부하기 전에 반드시 짚고 넘어가야 할 JS 핵심 4개념을 정리했습니다.

클로저 (Closure)

정의: “함수가 선언될 때의 렉시컬 스코프(변수 환경)를 기억하여, 실행 시점에도 그 변수들에 접근할 수 있는 현상(함수 + 환경의 조합).”

1) 메모리·실행 모델

• 함수가 선언되면, 엔진은 그 함수에 대한 [[Environment]](= 외부 렉시컬 환경 참조)를 저장합니다.
• 외부 함수가 종료되어도, 내부 함수가 참조하는 변수들이 살아있다면 GC 대상이 되지 않습니다. (“메모리 캡처”)
• 즉, 스코프 체인은 “문법적(렉시컬) 위치”로 고정됩니다. 호출 위치가 아니라 선언 위치가 중요합니다.

function makeCounter(step = 1) {
  let value = 0;                 // ← 렉시컬 환경에 저장

  return function inc() {        // ← [[Environment]]로 value를 기억
    value += step;
    return value;
  };
}

const c1 = makeCounter();  // c1은 value=0을 기억
const c2 = makeCounter(2); // c2는 value=0, step=2를 기억

console.log(c1()); // 1
console.log(c1()); // 2
console.log(c2()); // 2
console.log(c2()); // 4

흔한 함정: 루프 + var

const btns = Array.from(document.querySelectorAll('button'));
for (var i = 0; i < btns.length; i++) {
  btns[i].addEventListener('click', () => console.log(i));
}
// 모든 버튼이 마지막 값만 출력

• var는 함수 스코프라 하나의 i를 공유합니다. 해결 👉 let(블록 스코프) 사용하거나 즉시실행함수(IIFE)로 캡쳐

  for (let i = 0; i < btns.length; i++) {
  btns[i].addEventListener('click', () => console.log(i));
  }

2) 리액트와의 연결

• Stale Closure(오래된 값 참조) 문제:

  function App() {
  const [count, setCount] = useState(0);
  
  // 이 핸들러는 "정의된 렌더링 시점의 count"를 기억
  const onClick = () => {
    setTimeout(() => {
      // 여기서의 count는 과거 값일 수 있음
      setCount(count + 1);
    }, 1000);
  };
  return <button onClick={onClick}>{count}</button>;
  }

• 해결 👉 업데이트 함수형(setter 콜백) 사용:

  setCount(prev => prev + 1); // 항상 최신 state 기반

• useCallback/useMemo는 의존성 배열을 통해 어떤 값을 클로저로 “고정”할지 제어합니다. 의존성 누락 시 의도치 않은 낡은 값 참조가 발생합니다. (ESLint hooks 규칙으로 방지)

3) 알아두면 좋은 점

• 이벤트 핸들러에서 state를 읽고 업데이트할 때는 가급적 함수형 업데이트로 안전하게 처리하기
• 메모리 누수: 클로저가 거대한 객체를 잡고 있으면 GC가 못 합니다. 더 이상 필요없을 때 참조를 끊거나, effect 정리(clean-up)로 해제하기

자바스크립트의 렉시컬 환경(Lexical Environment) 구조를 시각적으로 표현한 다이어그램

싱글 스레드 (Single Thread)

정의: 자바스크립트 엔진은 기본적으로 단 하나의 호출 스택(Call Stack) 에서 코드를 순차 실행합니다.

1) 왜 중요한가

• 한 번에 하나의 작업만 메인 스레드에서 처리 → 블로킹이 발생하면 UI 멈춤
• JS 자체는 싱글 스레드지만, 브라우저는 별도 스레드(타이머, 네트워크, I/O, 렌더링 등) 를 갖습니다. 비동기는 이들과의 협업으로 구현됩니다.

  console.log("A");
  setTimeout(() => console.log("B"), 0);
  console.log("C");
  // A -> C -> B

2) 메인 스레드를 막는 코드 예시

// 200ms 동안 CPU 바쁜 작업(동기)
const block = (ms) => {
  const end = performance.now() + ms;
  while (performance.now() < end) {}
};

console.log("start");
block(500);       // 이 동안 클릭, 스크롤, 렌더링 모두 지연
console.log("end");

해결 아이디어

• 작업 쪼개기(Chunking): setTimeout, queueMicrotask, requestIdleCallback, requestAnimationFrame 등으로 틈 주기
• Web Worker로 CPU 바운드 작업을 메인 스레드 밖에서 처리

3) 리액트와의 연결

React 18의 Concurrent Rendering은 싱글 스레드 환경에서 “작업을 잘게 쪼개고, 우선순위를 둬서 중단/재개할 수 있도록” 만든 모델입니다.

• 긴 렌더링 작업이 메인 스레드를 독점하지 않도록, 사용자 입력/애니메이션 같은 급한 일에 먼저 시간을 양보합니다.

자바스크립트 런타임 구조

이벤트 루프 (Event Loop)

정의: 콜 스택이 비는 순간, 대기 중인 태스크(작업)를 정해진 우선순위에 따라 가져와 실행시키는 스케줄러/조정자

1) 구성요소와 순서

• Call Stack: 현재 실행 중인 JS 프레임
• Web APIs: 타이머, DOM, fetch 등 브라우저/런타임 제공 기능
• Task Queue(Macro Task): setTimeout, setInterval, MessageChannel, script…
• Microtask Queue: Promise.then/catch/finally, queueMicrotask, MutationObserver
• Event Loop: 스택이 비면, 먼저 Microtask 전부 → 그 후 다음 Task 한 번 수행 → 다시 Microtask …

  console.log("start");
  

setTimeout(() => console.log("timeout"), 0);

Promise.resolve() .then(() => console.log("microtask-1")) .then(() => console.log("microtask-2"));

console.log("end"); // start -> end -> microtask-1 -> microtask-2 -> timeout

---

#### `queueMicrotask` 타이밍

console.log("A"); queueMicrotask(() => console.log("B (micro)")); console.log("C"); // A -> C -> B (micro)

---

#### `requestAnimationFrame(rAF)` 타이밍
- **렌더 직전** 한 번 호출됨(프레임 동기화)

requestAnimationFrame(() => { // 여기는 다음 페인트 직전: DOM 읽고/쓰고, 스타일/레이아웃 최소화 전략 가능 });

requestAnimationFrame(() => { // 여기는 다음 페인트 직전: DOM 읽고/쓰고, 스타일/레이아웃 최소화 전략 가능 });

---

### 2) 리액트와의 연결
- `setState`는 보통 **동기처럼 보이지만 배치/스케줄링**되어 나중에 반영됩니다.
- `useEffect`는 **커밋 후(페인트 이후)** 비동기적으로 실행
- `useLayoutEffect`는 **DOM 커밋 직후(페인트 이전)** 실행되어 **레이아웃 측정**에 적합
- Transition(React 18): **긴 렌더링을 낮은 우선순위**로 보내 UI 응답성을 확보
---

### 알아두면 좋은 점
- Network 응답 후 DOM 업데이트 → `microtask` vs `task` **타이밍**에 따라 reflow 횟수가 달라질 수 있음
- **긴 루프/대량 DOM 조작**은 `rAF`/`IdleCallback`으로 분할, 또는 가상화·버퍼링 적용
---

![](https://velog.velcdn.com/images/hello-yujin/post/a36bd910-f950-4e7f-9d8e-52a2b34c7726/image.webp)
_이벤트 루프(Event Loop) 의 전체 흐름_

## 브라우저 렌더링 프로세스 (CRP: Critical Rendering Path)

> 정의: 브라우저가 HTML/CSS/JS를 받아 **화면에 픽셀로 그릴 때까지**의 전체 파이프라인

---

### 1) 파이프라인 단계
1. **HTML 파싱 → DOM 생성**
2. **CSS 파싱 → CSSOM 생성**
3. **Render Tree = DOM + CSSOM 결합(보이는 노드만)**
4. **Layout(Reflow)**: 각 노드의 **기하(위치·크기)** 계산
5. **Paint**: 배경, 글자, 테두리 등 그리기
6. **Composite**: 여러 레이어를 GPU로 합성(Transform/Opacity는 합성 단계에서 처리 가능)
> **Recalculate Style → Layout → Paint → Composite** 순으로 DevTools 타임라인에 보이는 이유가 이 흐름 때문
---

### 2) 비용이 큰 작업과 최적화 기준
- **Layout(=Reflow)**: 문서 흐름에 영향 → **비싸다 **
(예: `width/height/top/left`, 폰트 바뀜, DOM 삽입/삭제 등)
- **Paint**: 배경/텍스트/그라데이션/박스-쉐도우가 많으면 비용 상승
**Composite-only**: `transform`/`opacity` 변경은 **Layout/ Paint**를 건너뛸 수 있어 상대적으로 저렴

/* 좋음: 합성 단계에서 처리됨 */ .box.animate { will-change: transform, opacity; transition: transform 300ms, opacity 300ms; }

---

### 3) JS와 렌더링의 상호작용
- JS가 **메인 스레드**를 오래 잡고 있으면, **렌더 스텝**(Layout/Paint/Composite)이 지연됩니다.
- 반대로, 스타일 계산이나 레이아웃을 **자주 강제**하면(예: 잦은 `offsetWidth` 읽기 → layout flush) 프레임이 끊깁니다.

// layout thrashing (피해야 함) for (const el of items) { const w = el.offsetWidth; // 레이아웃 강제 el.style.width = (w + 10) + 'px'; }

// layout thrashing (피해야 함) for (const el of items) { const w = el.offsetWidth; // 레이아웃 강제 el.style.width = (w + 10) + 'px'; }

---

#### 개선: 읽기→쓰기 배치

// 1) 먼저 모두 읽고 const widths = items.map(el => el.offsetWidth); // 2) 다음 프레임에 한번에 쓰기 requestAnimationFrame(() => { items.forEach((el, i) => { el.style.width = (widths[i] + 10) + 'px'; }); });

---

### 4) 리액트와의 연결
- 리액트는 **Virtual DOM**으로 실제 DOM 변경 최소화 → CRP 비용 절감
- 다만 **렌더 함수 자체가 무거우면**(큰 리스트, 복잡한 계산) **JS가 메인 스레드를 막아** 렌더링이 지연됩니다.
(해결: **컴포넌트 분할**, `React.memo`, `useMemo`/`useCallback`,** 리스트 가상화**, **서버 컴포넌트/SSR**, Concurrent 특성(transition) 활용)
- **측정 우선**: Chrome DevTools Performance/Profiler로 **Recalculate Style/Layout/Paint**가 어디서 발생하는지 확인

---

![](https://velog.velcdn.com/images/hello-yujin/post/0b83e057-939a-4c69-ad7f-da477ce2b55e/image.jpg)
_브라우저 렌더링 과정(Critical Rendering Path)_

웹 성능을 개선하고 네트워크 사용량을 줄이는 가장 확실한 방법은 ‘브라우저 개발자 도구(DevTools)’를 제대로 이해하는 것입니다. 이번 글에서는 제가 직접 운영 중인 스터디룸 예약 서비스 ‘Ddingsroom’을 예시로, 크롬 개발자 도구의 Network / Performance / Lighthouse 패널을 중심으로 실제 로딩 과정에서의 병목 지점을 찾고, 폰트 및 이미지 최적화로 대역폭을 줄이는 방법을 정리해보겠습니다.

1️⃣ Network 패널 이해하기 (Ddingsroom 로딩 구조 분석)

Network 패널은 웹 페이지가 요청하는 모든 리소스의 네트워크 흐름을 시각적으로 보여주는 도구입니다. HTML, JS, CSS, 이미지, 폰트 등 어떤 리소스가 얼마만큼의 시간과 대역폭을 사용했는지를 분석할 수 있습니다.

Ddingsroom은 Next.js 기반으로 구성되어 있어,초기 렌더링 시 HTML → CSS → JS → API → 이미지 순으로 리소스가 순차적으로 요청됩니다.

주요 항목

• Name: 요청된 파일 이름 (예: index.html, main.js)
• Status: HTTP 응답 코드 (200, 404, 304 등)
• Type: 리소스 타입 (document, script, stylesheet, image 등)
• Initiator: 어떤 코드가 해당 요청을 유발했는지 (예: JS, CSS import)
• Size: 다운로드된 실제 바이트 크기 (압축 전/후)
• Time: 요청~응답까지 걸린 총 시간
• Waterfall: 각 요청의 타이밍 시각화 (병렬 요청 구조 확인 가능)

Ddingsroom에서의 활용 포인트

1. 불필요한 요청 찾기 예약 정보와 사용자 정보 API가 중복 호출되는지 점검 2. 304 Not Modified 확인 정적 리소스(layout.css, main-app.js)가 캐싱을 통해 효율적으로 재사용되는지 확인 3. Bundling 점검 webpack.js 파일의 크기가 큰 경우, 코드 스플리팅 필요성 검토 4. Lazy Loading 검증 예약 이미지(스터디룸 사진 등)가 초기 로딩 시 불필요하게 전부 불려오지 않는지 체크

⚙️ Ddingsroom 프로젝트 Network 패널

실제 Ddingsroom 프로젝트의 네트워크 탭 화면 캡쳐본입니다. 상단의 Throttling: 3G와 Disable cache를 설정하여 모바일 네트워크 환경을 재현했습니다. layout.css, webpack.js, main-app.js 등 주요 리소스의 요청 순서를 확인할 수 있고, DOMContentLoaded(5.38s)와 Load(38.86s) 시점을 기준으로 병목 구간을 분석했습니다.

2️⃣ Performance 패널 - 렌더링 병목 분석

Performance 패널은 페이지 로딩과 렌더링 과정 전체를 타임라인으로 시각화합니다. Network가 “전송 속도”를 본다면, Performance는 “CPU/렌더링 속도”를 분석하는 패널입니다.

Ddingsroom에서는 로그인 후 AfterLoginBanner나 예약 모달 렌더링 시 JS 연산량이 급증해 메인 스레드의 Task가 길어지는 경우가 있습니다.

주요 항목

• Main Thread Activity: JS 실행, 렌더링, 리플로우, 페인트 등 브라우저 내부 작업
• FPS (Frame Per Second): 초당 프레임 — 60fps 유지가 이상적
• Screenshots: 각 시점의 페이지 렌더링 미리보기
• CPU Usage: JavaScript 실행, 레이아웃, 스타일 계산 등의 CPU 부하율
• Bottom-up View: 함수별로 CPU 사용 시간 분석 가능

실제 적용 예시

1. 스크롤 시 버벅임 JS Event Listener가 너무 많거나 무거운 연산 확인 2. 리플로우 발생 CSS 속성 변경 시 Layout Trashing 여부 파악 3. LCP(Largest Contentful Paint)개선 이미지 로드 타이밍 및 lazy loading 확인

⚙️ Ddingsroom 프로젝트 Performance 측정 결과

아래 결과는 Ddingsroom 로그인 페이지의 초기 로딩 성능을 Chrome DevTools Performance 패널에서 3G 네트워크 환경으로 측정한 수치입니다.

분석

• LCP 지연 원인

  • 초기 로딩 시 div.text-4xl.md:text-5xl.font-bold 요소가 포함된 메인 헤더 영역이 렌더링 지연 발생
  • 이미지, JS 번들, 또는 폰트 로딩이 렌더 블로킹(Render Blocking) 으로 작용했을 가능성 높음
  • 특히, 폰트 요청이 비동기적으로 처리되지 않거나 캐시되지 않은 경우 LCP가 악화될 수 있음

• CLS 0.00 (Good)

  • 모든 요소에 고정된 높이·비율이 적용되어 레이아웃 시프트 없이 안정적인 렌더링이 이루어짐
  • 이는 Tailwind의 aspect-ratio, 고정 height, width 지정 덕분으로 보임

• INP 48ms (Good)

  • 버튼 및 입력 요소의 이벤트 처리 루프가 가볍고,
    JS 메인 스레드의 블로킹 구간이 거의 없음 → 사용자 반응 즉시 반영 가능

향후 개선 계획

이번 측정에서 LCP(42.24s) 지표가 성능 병목으로 드러났습니다.
따라서 아래와 같은 단계별 최적화를 진행할 예정입니다.

1. 이미지 로딩 최적화

• next/image 컴포넌트로 모든 정적 이미지 교체
• hero·배너 이미지에 priority 속성 부여, 하단 콘텐츠에는 loading="lazy" 적용
• JPEG → WebP / AVIF 변환 및 CDN 캐싱 도입으로 응답 속도 단축

2. 폰트 로딩 개선

• GmarketSans를 Self-hosted WOFF2 폰트로 전환
• font-display: swap 적용하여 폰트 로딩 중에도 텍스트를 즉시 표시
• <link rel="preload" as="font"> 로 주요 폰트 사전 로드

3. JS 번들 최적화

• Next.js의 dynamic import()를 활용해 비필수 스크립트 지연 로딩
• React.memo 및 useMemo로 렌더링 비용 최소화
• 불필요한 콘솔 로그 및 외부 라이브러리 의존성 정리

4. 캐싱 정책 고도화

• 정적 리소스(/static/*, /fonts/*, /images/*)에
  Cache-Control: public, max-age=31536000, immutable 헤더 적용
• 이후 Cloudflare / Vercel CDN 연동을 통해 전역 엣지 캐시 활성화

3️⃣ Lighthouse 패널 - 웹 성능 자동 진단

Lighthouse는 페이지 품질을 종합적으로 분석해주는 자동화 툴입니다.

Performance, Accessibility, Best Practices, SEO, PWA 등 5가지 항목을 점수화해줍니다.

Lighthouse 주요 카테고리

• Performance: 페이지 로딩 속도, LCP, CLS, TBT 등 주요 웹 성능 지표
• Accessibility: 대체 텍스트, ARIA 속성, 색 대비 등 접근성 검증
• Best Practices: HTTPS, JS 오류, 콘솔 경고 등 점검
• SEO: 검색엔진 최적화 관련 메타태그, robots.txt 여부
• PWA: Progressive Web App 지원 여부

Lighthouse 점수 개선 방안

• 이미지 → WebP 형식으로 변환
• 폰트 → font-display: swap 사용
• JS 번들 → Tree Shaking 적용
• CSS → Critical CSS 인라인 삽입
• 캐시 정책 → Cache-Control, ETag 적극 활용

이 화면은 Chrome DevTools의 Lighthouse 탭에서 성능 진단을 시작하기 전, 측정 조건을 설정하는 단계입니다.
분석할 페이지 유형, 디바이스 환경, 그리고 평가 항목(Category)을 지정한 뒤
“Analyze page load” 버튼을 눌러 리포트를 생성합니다.

⚙️ Ddingsroom 프로젝트 Lighthouse 탭 성능 진단 결과

Lighthouse 분석 결과, Ddingsroom은 SEO와 접근성 측면에서 매우 우수한 구조를 보였지만 초기 렌더링 속도와 JS 번들 크기로 인해 Performance 점수가 낮게 측정되었습니다.

향후에는 이미지 WebP 변환, 코드 스플리팅, 폰트 최적화 등을 통해 성능 지표를 42 → 80 이상으로 향상시키는 것을 목표로 하고 있습니다.

4️⃣ 폰트 최적화(Font Optimization)

폰트는 눈에 보이지 않지만, 웹 페이지 로딩을 느리게 만드는 주요 요인 중 하나입니다.

최적화 방법 5단계

1. WOFF2 형식 사용 TTF/OTF보다 30~50% 용량 절감 2. 서브셋(Subsetting) 실제 사용하는 문자만 포함 (예: 영문 전용, 한글 일부) 3. font-display: swap 적용 폰트 로딩 중 FOUT(Flash of Unstyled Text) 방지

@font-face {
  font-family: 'Pretendard';
  src: url('/fonts/pretendard.woff2') format('woff2');
  font-display: swap;
}

4. Preload / Preconnect 사용

<link rel="preload" href="/fonts/pretendard.woff2" as="font" type="font/woff2" crossorigin>

5. CDN 대신 Self-hosting 고려 Google Fonts보다 직접 호스팅이 빠를 수 있음

위 이미지는 브라우저 렌더링 과정에서 CSS와 폰트 로딩이 페이지 표시 속도에 어떤 영향을 미치는지를 보여줍니다.

1. T₀ ~ T₁ (Request → Build DOM)

• 브라우저는 HTML 문서를 요청(GET html)하고 응답을 받아 DOM 트리를 생성합니다.
• 이 단계에서 CSS 파일을 발견하면 추가 네트워크 요청(GET css)을 수행합니다.
• CSS는 렌더링을 차단하는 Render Blocking 리소스로, 응답이 오기 전까지 화면이 그려지지 않습니다.

2. T₁ ~ T₂ (Build CSSOM → Font 요청)

• CSS 응답이 오면 브라우저는 CSSOM(CSS Object Model)을 빌드합니다.
• CSS 내 @font-face 선언이 있으면 폰트를 새로 요청(GET font)하게 됩니다.
• 폰트 응답이 늦을 경우 텍스트는 보이지 않고 FOUT(Flash of Unstyled Text) 또는 FOIT(Flash of Invisible Text) 현상이 발생합니다.
• 이 과정이 blocked text painting으로 표시된 이유입니다.

3. T₂ ~ T₃ (First Paint → Paint Text)

• CSSOM과 DOM이 결합되어 렌더 트리(Render Tree)가 완성되면
  브라우저가 최초로 화면을 그립니다(First Paint).
• 그러나 폰트가 아직 로드되지 않았다면 텍스트는 그려지지 않고,
  폰트 응답 후에야 실제 텍스트가 표시(Paint Text)됩니다.
• 즉, 폰트 로딩이 늦을수록 LCP(Largest Contentful Paint) 지표가 나빠지고 사용자에게는 로딩이 느리게 느껴집니다.

핵심 요약

CSS와 폰트는 렌더링을 지연시키는 주요 원인이므로,
font-display: swap 속성 적용이나 preload로 폰트를 미리 불러오면
First Paint 시점에 텍스트가 빠르게 표시되어 렌더 블로킹 시간을 단축할 수 있습니다.

⚙️ Ddingsroom 프로젝트에의 적용 예시

현재 Ddingsroom은 GmarketSans 시스템 폰트를 로컬 폰트 기반으로 사용하고 있습니다.
이 방식은 사용자 OS(macOS, Windows 등)에 해당 폰트가 설치되어 있을 경우
네트워크 요청 없이 바로 렌더링된다는 장점이 있습니다.
하지만, 로컬에 폰트가 없는 환경에서는 대체 폰트가 적용되며 시각적 일관성이 깨질 수 있습니다.

향후에는 Self-hosting + 최적화된 폰트 서빙 전략을 도입하여
렌더링 안정성과 성능 점수를 동시에 개선할 계획입니다.

5️⃣ 이미지 최적화(Image Optimization)

이미지는 전체 페이지 용량의 60~80%를 차지합니다. 따라서 적절한 포맷, 크기, 로딩 전략이 핵심입니다.

이미지 포맷 선택 가이드

실제 최적화 기법

1. Responsive Images

<img src="hero-640.webp"
     srcset="hero-1280.webp 1280w, hero-640.webp 640w"
     sizes="(max-width: 768px) 640px, 1280px"
     alt="메인 배너 이미지">

2. Lazy Loading

<img src="banner.webp" loading="lazy" alt="배너 이미지">

3. Next-gen Formats (WebP, AVIF) Lighthouse에서도 직접 추천됨

4. CDN 이미지 압축 서비스 사용 (Cloudflare, Imgix 등)

위 이미지는 CDN(Content Delivery Network) 이 원본 서버(Origin Server)와 사용자(User) 사이에서 어떻게 이미지나 정적 리소스를 빠르고 안정적으로 전달하는지를 보여줍니다.

작동 원리 요약

1. 사용자 요청(Request)

• 사용자가 이미지를 요청하면 브라우저는 먼저 CDN 서버(엣지 서버) 로 요청을 보냅니다.
• CDN은 전 세계 여러 지역에 분산되어 있으며, 사용자의 물리적 위치와 가장 가까운 서버가 응답합니다.

2. CDN 캐시(Cache) 확인

• CDN은 동일한 이미지 요청이 들어올 때마다 자신의 캐시 스토리지를 먼저 확인합니다.
• 캐시에 파일이 있다면 원본 서버에 재요청하지 않고 즉시 응답(Response) 합니다.
• 이렇게 하면 네트워크 지연(latency)이 줄고, 트래픽 비용도 절감됩니다.

** 3. 원본 서버(Origin Server) 요청**

• 만약 CDN 캐시에 이미지가 없거나 만료되었다면,
  CDN은 원본 서버에 직접 요청을 보냅니다.
• 이후 받은 응답을 캐시에 저장해, 다음 요청 시 빠르게 서빙할 수 있게 합니다.

4. 서버 장애 시의 이점

• 이미지처럼 변경이 드문 리소스는 CDN 캐시 내에 유지되기 때문에,
  원본 서버가 일시적으로 다운되더라도 CDN이 캐시된 파일을 그대로 전달할 수 있습니다.
• 즉, 사용자는 서비스 장애를 거의 느끼지 못합니다.

⚙️ Ddingsroom 프로젝트에의 적용 예시

현재 Ddingsroom의 정적 이미지(/public/static/images/*)는 로컬에서 직접 서빙되고 있습니다.
향후에는 Cloudflare Images / AWS CloudFront / Vercel Image Optimization 같은 CDN을 활용하여 개선을 목표로 하고 있습니다.

👀 마치며

솔직히, 지금까지는 “기능이 돌아가면 됐다”고 생각한 적이 많았습니다. 하지만 Ddingsroom은 실제로 학생들이 매일 접속하는 운영 서비스입니다. 1초의 지연, 한 번의 깜빡임도 사용성의 피로로 돌아올 수 있습니다. 개발자 도구와 Lighthouse로 직접 분석해보니, 이미지·폰트·JS 번들이 성능에 미치는 영향을 구체적으로 확인할 수 있었습니다.

이번 점검을 통해 배운 건, 성능 최적화는 ‘추가 작업’이 아니라 ‘사용자 경험의 기본’이라는 점입니다. 앞으로는 다음과 같은 방향으로 개선을 이어갈 계획입니다.

• 이미지 → WebP 변환, lazy 로딩, CDN 캐싱

• 폰트 → woff2 self-hosting, preload, font-display: swap

• 코드 → dynamic import, Tree Shaking 적용

이번 글에서는 1️⃣ Local Storage, Session Storage, Cookie 의 차이점 2️⃣ 그리고 실제로 제가 운영 중인 Ddingsroom 프로젝트에서 어떻게 세션을 관리하고 있는지 를 함께 살펴보겠습니다.

📦 Local Storage

Local Storage는 브라우저에 반영구적으로 데이터를 저장하는 저장소입니다.

• 유효 기간: 무기한 (사용자가 직접 삭제하지 않는 이상 남음)
• 용량: 약 5MB (브라우저별로 다름)
• 특징: 서버로 전송되지 않음, 클라이언트에서만 접근 가능

예시

localStorage.setItem("theme", "dark");
localStorage.getItem("theme"); // "dark"
localStorage.removeItem("theme");

주요 사용 예시

• 다크 모드 / 라이트 모드 설정
• 최근 본 상품, 선호 카테고리 저장

🔐 Session Storage

Session Storage는 탭 단위로 유지되는 임시 저장소입니다. 브라우저 탭을 닫으면 데이터가 삭제됩니다.

• 유효 기간: 브라우저 탭을 닫을 때까지
• 서버 전송: 자동 전송 안 됨
• 용량: 약 5MB

예시

sessionStorage.setItem("accessToken", "abc123");
sessionStorage.getItem("accessToken"); // "abc123"
sessionStorage.clear();

주요 사용 예시

• 로그인 세션 유지 (JWT 토큰 저장)
• 임시 입력 폼 데이터

🍪 Cookie

Cookie는 서버와 클라이언트가 자동으로 주고받을 수 있는 데이터 조각입니다.

• 유효 기간: 설정 가능 (max-age / expires)
• 용량: 약 4KB
• 서버 전송: 자동 전송
• 보안 옵션: Secure, HttpOnly, SameSite 등으로 강화 가능

예시

document.cookie = "user=Yujin; max-age=3600; path=/";

주요 사용 예시

• 자동 로그인, 세션 식별자 (session_id)
• 웹 분석, 광고 트래킹

세 저장소 비교

Cookie & LocalStorage 관계 시각화

🏫 Ddingsroom 프로젝트의 세션 유지 구조

간단하게 Local Storage, Session Storage, Cookie에 대해 알아봤으니 이제 실제 제가 운영중인 Ddingsroom 프로젝트에서 어떻게 세션을 유지하는지 살펴보도록 하겠습니다. Ddingsroom은 JWT 기반 클라이언트 세션 관리를 사용하고 있습니다. 즉, 서버 세션이 아닌 토큰 기반 인증 방식입니다.

로그인 이후의 흐름

1️⃣ 로그인 성공 시 서버에서 accessToken, refreshToken, userId를 반환합니다. 2️⃣ 클라이언트에서 이를 sessionStorage에 저장합니다. 3️⃣ Axios 인스턴스가 모든 API 요청에 Authorization 헤더를 자동 추가합니다.

📁 관련 파일 구조

libs/
 └── api/
      ├── instance.js     ← axios 인스턴스 + 인터셉터
      ├── getUserId.js    ← 토큰 기반 유저 식별
      └── admin.js        ← 관리자용 API
stores/
 ├── useTokenStore.js     ← Zustand 전역 상태로 토큰 관리
 ├── useReservationStore.js
 └── useCommunityStore.js

1. axios 인스턴스 설정 (libs/api/instance.js)

import axios from 'axios';

const axiosInstance = axios.create({
  baseURL: process.env.NEXT_PUBLIC_API_BASE_URL,
  timeout: 10000,
});

axiosInstance.interceptors.request.use((config) => {
  const accessToken = sessionStorage.getItem('accessToken');
  if (accessToken) {
    config.headers.Authorization = `Bearer ${accessToken}`;
  }
  return config;
});

-> 인증이 필요한 모든 요청에 자동으로 토큰이 붙습니다.

2. 응답 인터셉터에서 만료 토큰 처리

axiosInstance.interceptors.response.use(
  (response) => response,
  (error) => {
    const { response } = error;
    if (response && (response.status === 401 || response.status === 403)) {
      sessionStorage.removeItem('accessToken');
    }
    return Promise.reject(error);
  }
);

-> 토큰이 만료되면 자동으로 세션이 종료되어 재로그인을 유도합니다.

3. Zustand를 통한 전역 세션 관리 (useTokenStore.js)

import { create } from 'zustand';

const useTokenStore = create((set) => ({
  accessToken: sessionStorage.getItem('accessToken') || '',
  refreshToken: sessionStorage.getItem('refreshToken') || '',
  userId: parseInt(sessionStorage.getItem('userId')) || null,

  setAccessToken: (token) => {
    set({ accessToken: token });
    sessionStorage.setItem('accessToken', token);
  },
  clearTokens: () => {
    set({ accessToken: '', refreshToken: '', userId: null });
    sessionStorage.clear();
  },
}));

-> Zustand와 sessionStorage를 양방향 동기화하여, 새로고침해도 세션이 유지됩니다.

왜 Session Storage를 선택했을까?

• 보안성: 토큰이 HTTP 요청마다 자동 전송되지 않아 XSS에만 주의하면 안전하다 판단했습니다.
• 유지 기간: 브라우저 탭 단위로 로그인 시간이 유지되기에 공용 PC 등에서 자동 로그아웃이 가능합니다.
• UX 향상: 새로고침 시에도 Zustand의 rehydrate()로 세션 유지가 가능합니다.
• 간결함: 복잡한 서버 세션 관리 대신 클라이언트 단에서 간단하게 구현이 가능합니다.

세션 구조 다이어그램

[서버] 
  ↓ (로그인 응답)
  accessToken, refreshToken, userId
  ↓
[클라이언트]
 ┌──────────────────────────┐
 │ sessionStorage            │
 │  ├ accessToken            │
 │  ├ refreshToken           │
 │  └ userId                 │
 └──────────────────────────┘
         │
         ▼
 [useTokenStore.js] ← Zustand 전역 상태
         │
         ▼
 [axiosInstance] → Authorization 헤더 자동 부착

결론 — 실서비스에서 드러난 문제와 개선 방향

Ddingsroom은 JWT + Session Storage 기반 세션 유지 구조를 사용합니다.

• 서버 세션 대신 클라이언트 중심의 토큰 인증
• Axios 인터셉터로 인증 헤더 자동 부착
• Zustand로 전역 상태 동기화 = 탭 단위의 보안 중심 UX

그러나 최근 실제 서비스 운영 중 다음과 같은 사용자 피드백이 접수되었습니다.

🗣️ 사용자 피드백 사례

“자꾸 예약 내역이 사라집니다. 전날 예약했는데 다음날 들어와 보니 예약이 안 되어 있어서 너무 곤란했습니다. 오늘도 또 그러네요. 왜 그런 건가요?”

이 피드백은 “예약이 정상적으로 완료되지 않은 것처럼 보인다”는 내용이었지만, 서버 로그를 분석해보니 예약 API 자체가 백엔드로 전송되지 않았거나, 인증 실패(401) 로 처리된 경우였습니다.

Access Token이 만료된 상태에서 사용자가 예약 버튼을 누르면 요청이 서버로 전달되지 않거나 401 Unauthorized로 거절되지만, UI에는 별다른 오류 안내가 표시되지 않아 사용자는 예약이 된 줄 착각하게 됩니다. 결국 예약 데이터가 DB에 저장되지 않은 채 사라지는 현상이 발생한 것입니다.

이를 해결하기 위해 현재

• Access Token 사전 갱신 (Preemptive Refresh)
• 401 응답 시 자동 재발급 및 재시도 로직
• HttpOnly 쿠키 기반 Refresh Token 보관
• 멀티탭 동기화 구조 개선 등의 개선을 진행 중에 있습니다.

이 개선이 적용되면, 사용자는 토큰 만료를 인식하지 않고도 서비스 내에서 로그인 상태가 끊김 없이 유지될 것 입니다.

💡 다음 포스트에서는 이 Refresh Token 로직을 실제 코드 레벨에서 어떻게 구현했는지, Axios 인터셉터와 Network Interceptor 기반으로 자세히 다뤄보겠습니다.

서비스를 만들 때 대부분의 개발자는 “기능 구현”에 집중합니다. 하지만 배포 후 아무리 좋은 서비스를 만들어도,검색 결과에 내 서비스가 전혀 보이지 않는다면 아무 의미가 없을 것 입니다.

저는 명지대학교 학생회관 스터디룸 예약 서비스 "DdingsRoom"을 개발하면서 처음으로 SEO(Search Engine Optimization, 검색 엔진 최적화)의 중요성을 체감했습니다. 이번 글에서는 SEO의 기본 개념부터, 실제로 DdingsRoom 프로젝트에 적용한 코드를 중심으로 어떻게 검색 노출을 개선했는지 정리해보려 합니다.

2. SEO란 무엇인가?

SEO(Search Engine Optimization)는 Google이나 Naver 같은 검색 엔진이 내 웹사이트를 더 잘 이해하고 노출하도록 만드는 과정입니다.

검색 엔진은 아래 3단계를 통해 페이지를 노출시킵니다.

1. 크롤링(Crawling) – 검색봇이 웹을 돌아다니며 페이지를 수집

2. 인덱싱(Indexing) – 수집한 페이지의 내용을 데이터베이스에 저장

3. 랭킹(Ranking) – 검색어와 관련성 높은 페이지를 우선 노출

즉, 개발자가 해야 할 일은 _“검색봇이 내 페이지를 쉽게 읽고, 정확히 이해하도록 구조를 만들어주는 것”_입니다.

3. DdingsRoom 프로젝트에서 SEO 적용하기

DdingsRoom은 Next.js 14 + Vercel 배포 환경으로 운영 중입니다. Next.js는 서버 사이드 렌더링(SSR)과 정적 페이지 생성(SSG)을 지원하기 때문에 React 기반 서비스 중에서도 SEO 친화적인 프레임워크예요.

아래는 제가 RootLayout에서 적용한 SEO 설정 코드입니다.

export const metadata = {
  metadataBase: new URL('https://ddingsroom.com'),
  title: 'DdingsRoom | 명지대학교 학생회관 스터디룸 예약 서비스',
  description:
    '명지대학교 인문캠퍼스 학생회관 스터디룸 예약부터 사용까지! 간편한 온라인 예약 시스템으로 언제든지 스터디룸을 예약하세요.',
  keywords: [
    '명지대학교', '스터디룸', '예약', '학생회관', '인문캠퍼스', '띵스룸', 'DdingsRoom',
  ],
  authors: [{ name: 'DdingsRoom Team' }],
  creator: 'DdingsRoom',
  publisher: 'DdingsRoom',
  robots: 'index, follow',
  openGraph: { ... },
  twitter: { ... },
};

이 설정을 통해 다음과 같은 SEO 요소들을 개선했습니다.

1. 메타 정보 (Meta Information)

title: 'DdingsRoom | 명지대학교 학생회관 스터디룸 예약 서비스',
description: '명지대학교 인문캠퍼스 학생회관 스터디룸 예약부터 사용까지!'

→ 브라우저 탭 제목, 검색 엔진 미리보기, SNS 카드에 표시되는 정보입니다. title과 description을 구체적으로 작성하면 Google 검색결과에 서비스가 깔끔하게 표시됩니다.

2. 키워드 (Keywords)

keywords: ['명지대학교', '스터디룸', '예약', '학생회관', '띵스룸']

→ Google은 최근 직접적인 keywords는 중요하게 보지 않지만, 검색 노출의 문맥을 강화하는 데 도움이 되며,특히 국문 서비스나 지역 서비스(“명지대학교” 등)에서는 효과적이라고 합니다.

3. Open Graph (OG) & Twitter Card

openGraph: {
  title: 'DdingsRoom | 명지대학교 학생회관 스터디룸 예약 서비스',
  description: '명지대학교 인문캠퍼스 학생회관 스터디룸 예약부터 사용까지!',
  images: [{ url: '/static/images/ddingsroom.png', width: 1200, height: 630 }],
},
twitter: {
  card: 'summary_large_image',
  title: 'DdingsRoom | 명지대학교 학생회관 스터디룸 예약 서비스',
  description: '명지대학교 인문캠퍼스 학생회관 스터디룸 예약부터 사용까지!',
  images: ['/static/images/ddingsroom.png'],
}

→ SNS 공유 최적화(소셜 SEO) 부분이에요. 누군가가 서비스 링크를 카카오톡, 트위터, 인스타그램 등에 공유하면 이 메타 정보에 따라 미리보기 이미지, 제목, 설명이 자동으로 표시됩니다.

즉, 공유되는 순간부터 브랜딩 효과를 얻을 수 있습니다.

4. Robots & Sitemap

robots: 'index, follow'

→ 검색 엔진이 이 페이지를 수집(index) 하고, 내부 링크를 따라갈 수 있도록(follow) 허용하는 설정입니다.

추가로 /robots.txt와 /sitemap.xml을 생성하면 Google Search Console에서 인덱싱을 훨씬 빠르게 할 수 있다고 합니다.

5. Viewport & Theme Color

export const viewport = {
  width: 'device-width',
  initialScale: 1,
  maximumScale: 5,
  themeColor: '#ffffff',
};

→ 모바일 친화도(Responsive SEO)를 위한 설정입니다. 모바일 페이지가 최적화되어야 Google의 모바일 퍼스트 인덱싱에서 좋은 점수를 받습니다.

6. Google Analytics (GA4)

<Script
  src="https://www.googletagmanager.com/gtag/js?id=G-NEXY3X7HZG"
  strategy="afterInteractive"
/>
<Script id="google-analytics" strategy="afterInteractive">
  {`
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments);}
    gtag('js', new Date());
    gtag('config', 'G-NEXY3X7HZG');
  `}
</Script>

→ Google Analytics를 통해 방문자 데이터를 추적합니다. 검색 유입 경로, 페이지별 체류시간 등을 분석해 SEO 전략의 효과를 정량적으로 확인할 수 있습니다.

2025.10.21.화 기준 Google Analytics 연동 페이지 대시보드

4. 적용 후 변화

SEO 적용 이전에는 Google에서 띵스룸이나 명지대학교 스터디룸을 검색해도 서비스가 노출되지 않았습니다.

그러나 메타데이터를 적용하고 Google Search Console에 sitemap을 등록한 후 약 2주 만에 서비스가 검색 결과에 노출되기 시작했습니다.

또한 Vercel에서 배포된 페이지의 Lighthouse SEO 점수는 70점대에서 98점으로 향상되었습니다.