음악을 틀고 다른 페이지로 이동하거나 새로고침하면 어떻게 될까요?

Jotai atom은 메모리에만 존재합니다. 새로고침하는 순간 플레이리스트, 현재 곡, 볼륨이 모두 초기화됩니다.

스트리밍 앱에서 새로고침할 때마다 음악이 처음부터 다시 시작된다면 불편하겠죠. 재생 상태를 브라우저에 저장해서 새로고침 후에도 이어 들을 수 있게 만들고 싶었습니다.

🚨 문제 예상 (원인)

localStorage는 안 될까?

가장 먼저 떠오르는 건 localStorage입니다. 하지만 몇 가지 한계가 있습니다.

// localStorage로 플레이리스트 저장한다면...
localStorage.setItem('playlist', JSON.stringify(playlist));

// 재생목록이 여러 개가 된다면 (v2 확장 시 예상되는 문제)
localStorage:
  likedTracks: [{ videoId: "abc", title: "노래A", thumbnail: "..." }, ...]
  playlist_1:  [{ videoId: "abc", title: "노래A", thumbnail: "..." }, ...]  // 중복!
  playlist_2:  [{ videoId: "abc", title: "노래A", thumbnail: "..." }, ...]  // 중복!

💡 아이디어 + 해결

IndexedDB는 브라우저 내장 NoSQL 데이터베이스입니다.

중복 저장 문제는 정규화된 스키마 설계로 해결했습니다. 트랙 데이터를 한 곳(tracks)에만 저장하고, 다른 스토어는 ID만 참조합니다.

🗂️ 스키마 설계: 정규화

문제: 같은 곡이 여러 곳에 중복 저장된다

"노래A"를 좋아요 추가하고, 플레이리스트 2개에도 넣으면 어떻게 될까요?

❌ 비정규화 구조 (중복 발생)

likedTracks:   [{ videoId: "abc", title: "노래A", thumbnail: "..." }]
playlist_1:    [{ videoId: "abc", title: "노래A", thumbnail: "..." }]  ← 같은 데이터
playlist_2:    [{ videoId: "abc", title: "노래A", thumbnail: "..." }]  ← 같은 데이터

썸네일 URL이 바뀌거나 제목이 수정되면 3곳을 전부 업데이트해야 합니다. 어느 한 곳을 빠뜨리면 데이터가 달라지는 불일치가 생깁니다.

해결: tracks를 단일 저장소로 분리

트랙 데이터는 tracks 스토어 한 곳에만 저장하고, 다른 스토어는 ID만 참조합니다.

✅ 정규화 구조

tracks (단일 저장소)
 └─ "abc" → { title: "노래A", thumbnail: "...", ... }  // 딱 1번만 존재

playlists (재생목록 목록)
 ├─ "__liked__"
 └─ "__playlist__uuid1"

playlistTracks (관계 테이블 - 다대다)
 ├─ "__liked__:abc"         → playlistId: "__liked__",        trackId: "abc", order: 0
 └─ "__playlist__uuid1:abc" → playlistId: "__playlist__uuid1", trackId: "abc", order: 0

"노래A"가 몇 개의 재생목록에 들어가 있든 tracks에는 딱 1개만 존재합니다. 데이터 수정이 필요하면 tracks 한 곳만 바꾸면 됩니다.

관계 구조 한눈에 보기

tracks ◀──────────────────── playlistTracks ──────────────────▶ playlists
 └─ "abc" (노래A)             ├─ "__liked__:abc"                  ├─ "__liked__"
 └─ "def" (노래B)             └─ "__playlist__:abc"               └─ "__playlist__uuid"

관계형 DB의 다대다(N:M) 관계를 playlistTracks라는 중간 테이블로 표현한 것입니다. 한 트랙이 여러 재생목록에 속할 수 있고, 한 재생목록에 여러 트랙이 담길 수 있습니다.

⚙️ IndexedDB 적용

idb 라이브러리로 편리하게

raw IndexedDB API는 콜백 기반이라 코드가 복잡합니다. idb 라이브러리를 사용하면 Promise 기반으로 깔끔하게 쓸 수 있습니다.

npm install idb

스키마 정의

// lib/indexedDB/index.ts
export interface PlayerDBSchema extends DBSchema {
  // 트랙 단일 저장소 - 좋아요/재생목록 공통 사용, 중복 방지
  tracks: {
    key: string;        // videoId
    value: PlaylistItem;
  };

  // 유저 재생목록 (폴더)
  playlists: {
    key: string;
    value: {
      id: string;       // "__liked__" | "__playlist__{uuid}"
      title: string;
      createdAt: number;
      updatedAt: number;
    };
  };

  // 재생목록 ↔ 트랙 관계 테이블 (다대다)
  playlistTracks: {
    key: string;        // `${playlistId}:${trackId}`
    value: {
      id: string;
      playlistId: string;
      trackId: string;  // tracks.key 참조
      order: number;
      addedAt: number;
    };
    indexes: {
      'by-playlist': string;
      'by-track': string;
    };
  };

  // 현재 플레이어 상태
  playerState: {
    key: string;
    value: {
      playlist: string[];              // trackId 배열만 저장 (full 객체 X)
      currentVideoId: string | null;
      playlistSource: PlaylistSource;
    };
  };
}

playerState에도 트랙 ID 배열만 저장하는 게 포인트입니다. 읽을 때 tracks에서 조인합니다.

DB 초기화 + 마이그레이션

const DB_NAME = 'player-db';
const DB_VERSION = 4;

export const getPlayerDB = () => {
  if (!dbPromise) {
    dbPromise = openDB<PlayerDBSchema>(DB_NAME, DB_VERSION, {
      upgrade(db, oldVersion, newVersion, transaction) {

        // v1 → v2: 기존 스토어 구조를 정규화된 구조로 교체
        if (oldVersion < 2) {
          const legacyDb = db as any;

          // 레거시 스토어 제거
          if (legacyDb.objectStoreNames.contains('likedPlaylist')) {
            legacyDb.deleteObjectStore('likedPlaylist');
          }

          // 새 스토어 생성
          db.createObjectStore('tracks', { keyPath: 'id' });

          const playlistStore = db.createObjectStore('playlists', { keyPath: 'id' });
          // 시스템 플레이리스트 초기 데이터
          playlistStore.put({
            id: LIKED_PLAYLIST_ID,
            title: '좋아요한 플레이리스트',
            createdAt: Date.now(),
            updatedAt: Date.now(),
          });

          const relationStore = db.createObjectStore('playlistTracks', { keyPath: 'id' });
          relationStore.createIndex('by-playlist', 'playlistId');
          relationStore.createIndex('by-track', 'trackId');

          db.createObjectStore('playerState');
        }

        // v2 → v3: 좋아요 플레이리스트 title 변경
        if (oldVersion < 3) {
          const playlistStore = transaction.objectStore('playlists');
          playlistStore.put({
            id: LIKED_PLAYLIST_ID,
            title: '좋아요한 플레이리스트',
            updatedAt: Date.now(),
            createdAt: Date.now(),
          });
        }
      },
    });
  }

  return dbPromise;
};

oldVersion < N 패턴으로 버전별 마이그레이션을 순차 적용합니다. 기존 사용자의 DB도 자동으로 최신 버전으로 업그레이드됩니다.

플레이어 상태 저장/불러오기

// lib/indexedDB/playerStateDB.ts

// 저장: 트랜잭션으로 atomic하게
export const savePlayerState = async (state: PlayerStateValue) => {
  const db = await getPlayerDB();

  // playerState + tracks 두 스토어를 하나의 트랜잭션으로 묶음
  const tx = db.transaction(['playerState', 'tracks'], 'readwrite');

  // tracks 스토어에도 최신 정보 저장 (put = upsert, 중복 방지)
  for (const track of state.playlist) {
    await tx.objectStore('tracks').put({ ...track, id: track.videoId });
  }

  // playerState에는 ID 배열만 저장
  await tx.objectStore('playerState').put(
    {
      playlist: state.playlist.map(track => track.videoId),
      currentVideoId: state.currentVideoId,
      playlistSource: state.playlistSource,
    },
    PLAYER_STATE_KEY,
  );

  await tx.done; // 트랜잭션 커밋
};

// 불러오기: ID 배열 → tracks 조인
export const getPlayerState = async (): Promise<PlayerStateValue | undefined> => {
  const db = await getPlayerDB();
  const entity = await db.get('playerState', PLAYER_STATE_KEY);

  if (!entity) return undefined;

  // ID 배열로 실제 트랙 데이터 조회
  const tracks = await Promise.all(
    entity.playlist.map(id => db.get('tracks', id))
  );

  return {
    playlist: tracks.filter(Boolean) as PlaylistItem[],
    currentVideoId: entity.currentVideoId,
    playlistSource: entity.playlistSource,
  };
};

트랜잭션으로 묶는 이유: tracks 저장 중 실패하면 playerState도 저장되지 않습니다. 부분 저장으로 인한 데이터 불일치를 방지합니다.

usePlayerCore에서 연동

export const usePlayerCore = () => {
  // 앱 시작 시 저장된 상태 복원
  const restorePlayerState = useCallback(async () => {
    const savedState = await playerStateDB.getPlayerState();
    if (!savedState) return;

    setPlaylist(savedState.playlist);
    setPlaylistSource(savedState.playlistSource);
    setCurrentVideoId(savedState.currentVideoId);
  }, [setPlaylist, setPlaylistSource, setCurrentVideoId]);

  useEffect(() => {
    restorePlayerState();
  }, [restorePlayerState]);

  // 상태 변경 시 자동 저장
  useEffect(() => {
    if (!playlistSource) return;
    if (playlist.length === 0) return;

    playerStateDB.savePlayerState({ playlist, currentVideoId, playlistSource });
  }, [playlist, currentVideoId, playlistSource]);
};

DB 무결성 보장: validateAndRepairDB

앱 시작 시 DB 상태를 검사하고 이상이 있으면 자동 복구합니다.

export const validateAndRepairDB = async () => {
  const db = await getPlayerDB();

  // 좋아요 플레이리스트가 없으면 복구
  const liked = await db.get('playlists', LIKED_PLAYLIST_ID);
  if (!liked) {
    await db.put('playlists', {
      id: LIKED_PLAYLIST_ID,
      title: '좋아요한 플레이리스트',
      createdAt: Date.now(),
      updatedAt: Date.now(),
    });
  }

  // 고아 트랙 정리 (존재하지 않는 플레이리스트를 참조하는 관계 레코드 삭제)
  const allPlaylistTracks = await db.getAll('playlistTracks');
  const allPlaylists = await db.getAll('playlists');
  const playlistIds = new Set(allPlaylists.map(p => p.id));

  const orphanTracks = allPlaylistTracks.filter(
    track => !playlistIds.has(track.playlistId)
  );

  await Promise.all(orphanTracks.map(track => db.delete('playlistTracks', track.id)));
};

// app/providers/DBProvider.tsx
export function DBProvider({ children }: { children: React.ReactNode }) {
  useEffect(() => {
    validateAndRepairDB(); // 앱 마운트 시 한 번 실행
  }, []);

  return <>{children}</>;
}

📊 Before / After

Before: v1 (yoon-play) · localStorage

이전에 만들었던 yoon-play v1에서는 보관함이 하나(좋아요 목록)뿐이었고, YouTube API 응답을 그대로 localStorage에 저장했습니다.

{
  "#myPlayListState": [
    {
      "kind": "youtube#searchResult",
      "etag": "je810BRbL_DSPPdeAju-JAVqI8w",
      "id": { "kind": "youtube#video", "videoId": "U34kLXjdw90" },
      "snippet": {
        "title": "지브리의 피아노 OST 모음",
        "channelTitle": "Soothing Piano Relaxing",
        "thumbnails": {
          "default": { "url": "...", "width": 120, "height": 90 },
          "medium":  { "url": "...", "width": 320, "height": 180 },
          "high":    { "url": "...", "width": 480, "height": 360 }
        },
        "publishedAt": "2021-07-30T01:25:42Z",
        "channelId": "UC3fcwju0wMjPhmmAWr0dUKQ"
        // ... 그 외 불필요한 필드들
      }
    }
  ]
}

실제로 필요한 건 4개 필드뿐인데, API 응답 전체를 저장하고 있었습니다.🥲

필요한 것:  videoId, title, channelTitle, thumbnail  → ~200 bytes
실제 저장:  YouTube API 응답 전체                    → ~1,000 bytes (5배)

v1은 보관함이 하나뿐이라 중복 문제는 없었지만, v2(yoon-play2)에서 재생목록이 여러 개로 늘어나는 순간 이 구조 그대로 쓰면 중복이 바로 터질 상황이었습니다. 그리고 새로고침하면 재생 상태가 초기화되는 문제도 그대로였고요. 😢

After: v2 (yoon-play2) · IndexedDB + 정규화

[새로고침 전 상태]
  노래A를 좋아요 + 플레이리스트 2개에 추가

IndexedDB:
  tracks:         { "abc": { title: "노래A", ... } }   // 딱 1번만 저장 ✅
  playlists:      { "__liked__", "__playlist__uuid1", "__playlist__uuid2" }
  playlistTracks: { "__liked__:abc", "uuid1:abc", "uuid2:abc" }
  playerState:    { playlist: ["abc", ...], currentVideoId: "abc" }

[새로고침 후]
  DBProvider 마운트 → validateAndRepairDB 실행
  usePlayerCore → getPlayerState → ID로 tracks 조인 → atom 복원
  이어 듣기 시작 ✅

🎓 회고

1. DB 설계는 처음부터 정규화를 고민하자

처음엔 좋아요 목록과 재생목록에 트랙 데이터를 그냥 통째로 저장했습니다. 한 곡이 여러 목록에 있으면 데이터가 중복되고, 썸네일이 바뀌면 모든 곳을 수정해야 했습니다. tracks를 단일 저장소로 분리하고 나서야 일관성이 생겼습니다. 관계형 DB의 정규화 원칙이 IndexedDB에서도 그대로 적용됩니다.

2. 트랜잭션은 데이터 일관성의 보험이다

tracks와 playerState를 각각 따로 저장하면, 중간에 실패했을 때 한쪽만 저장되는 상황이 생길 수 있습니다. 트랜잭션으로 묶으면 전부 성공하거나 전부 실패합니다.

3. 마이그레이션은 미리 설계하자

oldVersion < N 패턴으로 버전별 마이그레이션을 관리하니, 스키마가 바뀌어도 기존 사용자 데이터를 안전하게 유지할 수 있었습니다. 처음부터 버전 관리를 염두에 두지 않았다면, 스키마를 바꿀 때마다 기존 데이터가 날아가거나 오류가 생길 수 있어요.

지금까지 긴 글 읽어주셔서 감사합니다 :)

💬 비슷한 문제를 겪으셨거나, 더 좋은 해결 방법이 있다면 댓글로 공유해주세요!

보관함 페이지에는 플레이리스트별 트랙 목록이 있습니다. 트랙이 10~20개면 문제없지만, 좋아하는 곡을 계속 추가하다 보면 100곡, 200곡이 될 수 있습니다.

처음엔 단순하게 map()으로 전체를 렌더링했습니다.

// 단순 구현
export default function TrackList({ tracks }: { tracks: PlaylistItem[] }) {
  return (
    <ul>
      {tracks.map(track => (
        <PlayerQueueItem key={track.videoId} item={track} />
      ))}
    </ul>
  );
}

직관적이고 동작도 합니다. 하지만 "트랙이 많아지면 어떻게 될까?" 라는 의문이 생겼습니다!

문제 예상(원인)

DOM에 모든 요소가 존재한다는 것

화면에는 한 번에 약 10개의 트랙만 보입니다. 하지만 map()으로 렌더링하면 200곡이면 200개의 DOM 노드가 전부 존재합니다.

화면에 보이는 트랙: 10개
실제 DOM에 존재하는 트랙: 200개 💥

DOM 노드가 많을수록:

• 초기 렌더링 비용 증가 (200개를 한 번에 그림)
• 메모리 사용량 증가 (보이지 않는 요소도 메모리 차지)
• 스크롤 성능 저하 (브라우저가 관리할 노드가 많아짐)

🤔 실제로 문제가 될까?

트랙 하나가 단순한 텍스트라면 괜찮을 수 있습니다. 그런데 PlayerQueueItem은 썸네일 이미지, 버튼, 아이콘 등을 포함한 복합 컴포넌트입니다.

200개 × (이미지 + 텍스트 + 버튼 + 아이콘) = 상당한 DOM 크기

지금 당장 느리지 않더라도, 데이터가 많아질수록 문제가 될 가능성이 충분합니다. "느려지고 나서 고치기"보다 "예방하기" 를 선택했습니다.

💡 아이디어 + 해결

핵심 아이디어: 보이는 것만 그리자

스크롤 위치를 기준으로 현재 화면에 보이는 트랙만 DOM에 렌더링하면 됩니다. 스크롤을 내리면 새 항목이 그려지고, 화면을 벗어난 항목은 DOM에서 제거합니다.

[트랙 1]  ← DOM에 없음 (화면 위로 벗어남)
[트랙 2]  ← DOM에 없음
──────────────────── 화면 시작
[트랙 3]  ← DOM에 있음 ✅
[트랙 4]  ← DOM에 있음 ✅
[트랙 5]  ← DOM에 있음 ✅
[트랙 6]  ← DOM에 있음 ✅
[트랙 7]  ← DOM에 있음 ✅
──────────────────── 화면 끝
[트랙 8]  ← DOM에 없음 (화면 아래)
[트랙 9]  ← DOM에 없음
...

이 개념을 가상 리스트(Virtual List) 라고 합니다. 직접 구현할 수도 있지만, @tanstack/react-virtual이 이 로직을 제공합니다.

⚙️ 가상 리스트 적용

1. 설치

npm install @tanstack/react-virtual

2. 구현

'use client';

import { useCallback, useRef } from 'react';
import { useVirtualizer } from '@tanstack/react-virtual';

export default function TrackList({ tracks, context }: TrackListProps) {
  const { currentVideoId, setPlayerListFromContext } = usePlayerCore();

  // 1. 스크롤 컨테이너 ref
  const parentRef = useRef<HTMLDivElement | null>(null);

  // 2. 가상화 설정
  const rowVirtualizer = useVirtualizer({
    count: tracks.length,        // 전체 트랙 수
    getScrollElement: () => parentRef.current, // 스크롤 컨테이너
    estimateSize: () => 56,      // 트랙 하나의 높이 (px)
    overscan: 2,                 // 화면 밖으로 미리 렌더링할 개수
  });

  const handlePlay = useCallback(
    (videoId: string) => {
      const track = tracks.find(t => t.videoId === videoId);
      if (track) setPlayerListFromContext(tracks, track);
    },
    [tracks, setPlayerListFromContext],
  );

  // 3. 실제 렌더링되는 가상 아이템 목록
  const virtualItems = rowVirtualizer.getVirtualItems();

  return (
    // 4. 스크롤 컨테이너
    <div
      ref={parentRef}
      className='overflow-auto mt-8'
      style={{ height: 'calc(100vh - 380px - 80px)' }}
    >
      {/* 5. 전체 높이를 확보하는 컨테이너 (스크롤바가 올바르게 표시되도록) */}
      <ul
        className='relative w-full'
        style={{ height: `${rowVirtualizer.getTotalSize()}px` }}
      >
        {/* 6. 화면에 보이는 항목만 렌더링 */}
        {virtualItems.map(virtualRow => {
          const track = tracks[virtualRow.index];
          return (
            <li
              key={track.videoId}
              className='absolute left-0 top-0 w-full'
              style={{
                // 7. translateY로 정확한 위치에 배치
                transform: `translateY(${virtualRow.start}px)`,
              }}
            >
              <PlayerQueueItem
                item={track}
                isActive={track.videoId === currentVideoId}
                onClick={handlePlay}
                context={context}
                showLikeButton={false}
              />
            </li>
          );
        })}
      </ul>
    </div>
  );
}

핵심 개념 뜯어보기

getTotalSize() — 전체 높이 확보

style={{ height: `${rowVirtualizer.getTotalSize()}px` }}
// 200개 × 56px = 11,200px

실제로 DOM에는 10개만 있지만, 스크롤바는 200개짜리처럼 동작해야 합니다. getTotalSize()가 반환한 전체 높이를 컨테이너에 지정해서 스크롤 범위를 확보합니다.

translateY — 올바른 위치에 배치

style={{ transform: `translateY(${virtualRow.start}px)` }}
// 3번째 트랙이라면: translateY(112px) = 56px × 2

모든 아이템이 position: absolute로 컨테이너 좌상단에 쌓입니다. virtualRow.start를 translateY에 적용해 각 아이템을 정확한 위치에 배치합니다. width 대신 transform을 사용하므로 Layout 재계산 없이 GPU가 처리합니다.

overscan: 2 — 스크롤 버벅임 방지

overscan: 2

화면에 보이는 영역 위아래로 2개씩 미리 렌더링합니다. 스크롤할 때 새 항목이 즉시 나타나 버벅임이 없습니다. 너무 크면 렌더링할 DOM이 많아져 오히려 역효과가 납니다.

📊 Before / After (가상 시나리오)

200개 트랙 기준으로 예상되는 차이입니다.

Before: 전체 렌더링

페이지 진입
  ↓
200개 트랙 전부 DOM 생성
  ↓
초기 렌더링: 200개 × (이미지 + 텍스트 + 버튼) 처리
  ↓
메모리: 200개 DOM 노드 상주
  ↓
스크롤 시: 200개 노드를 기준으로 레이아웃 계산

After: 가상 리스트

페이지 진입
  ↓
화면에 보이는 트랙 10개 + overscan 4개 = 14개만 DOM 생성
  ↓
초기 렌더링: 14개만 처리 ✅
  ↓
메모리: 14개 DOM 노드만 상주 ✅
  ↓
스크롤 시: 진입/이탈 항목만 추가/제거 ✅

트랙 수가 늘어도 렌더링 비용이 거의 변하지 않는다는 게 핵심입니다.

🎓 회고

1. 느려지기 전에 설계하자

지금 당장 200곡을 가진 사용자가 많지 않을 수 있습니다. 하지만 가상 리스트는 적용 비용이 낮고, 데이터가 쌓일수록 효과가 커집니다. "느려지고 나서 고치기"보다 "예방하기"가 훨씬 쉽다는 걸 다시 확인했습니다.

2. DOM 크기도 성능이다

React 성능 최적화라고 하면 흔히 memo, useCallback을 떠올립니다. 하지만 DOM 노드 수 자체를 줄이는 것도 중요한 최적화입니다. 브라우저가 관리해야 할 노드가 적을수록 레이아웃 계산, 이벤트 버블링, 메모리 모두 고려해보는 습관을 가져보아요.

다음 글에는 IndexedDB 스키마 설계 및 데이터 무결성 관리에 대해 다뤄보려고 합니다!

지금까지 긴 글 읽어주셔서 감사합니다 :)

💬 비슷한 문제를 겪으셨거나, 더 좋은 해결 방법이 있다면 댓글로 공유해주세요!

이전 글에서 훅 분리로 불필요한 리렌더링을 줄였다면, 이번엔 300ms마다 발생하는 브라우저 렌더링 파이프라인 비용 자체를 줄여봤습니다.

📖 리페인트(Repaint)란?

리페인트는 브라우저가 요소의 시각적 스타일이 바뀌었을 때 픽셀을 다시 그리는 작업입니다.

예를 들어 background-color, color, border 같은 속성이 바뀌면 레이아웃은 그대로지만, 해당 영역의 픽셀을 다시 계산해서 화면에 그려야 합니다. 이게 리페인트입니다.

리플로우(Reflow)와 혼동되기 쉬운데, 차이는 다음과 같습니다.

리플로우가 발생하면 리페인트도 항상 따라옵니다. 반대로 리페인트는 리플로우 없이도 발생할 수 있습니다.

ProgressBar는 300ms마다 업데이트됩니다. width를 쓰면 리플로우 → 리페인트가 반복되고, transform을 쓰면 둘 다 건너뜁니다.

🚨 문제 발견

초기 구현: input[type="range"]

처음 ProgressBar는 네이티브 HTML 요소로 구현했습니다.

const ProgressBar = () => {
  const { duration, currentTime, playerRef, setCurrentTime } = usePlayer();

  const handleChange = (e: ChangeEvent<HTMLInputElement>) => {
    const newTime = Number(e.target.value);
    setCurrentTime(newTime);
    playerRef.seekTo(newTime, true);
  };

  ...

  return (
    <input
      type='range'
      min='0'
      max={duration || 0}
      value={currentTime}
      step='1'
      onChange={handleChange}
      className='w-full h-1'
    />
  );
};

위와 같이 간단하게 만들 수 있었지만 두 가지 문제가 있었습니다. 🥹

1. 커스텀 스타일링 한계 - 브라우저마다 기본 스타일이 달라 디자인 일관성 유지가 어려움
2. 성능 문제 - 브라우저가 내부적으로 value 변화를 처리하는 방식이 GPU 가속과 거리가 있음

그래서 커스텀 div 기반으로 다시 만들기로 했고,이 과정에서 렌더링 파이프라인에 대해 고민하게 됐습니다.

🔍 원인 분석: 브라우저 렌더링 파이프라인

브라우저가 화면을 그리는 과정은 3단계입니다.

Layout (Reflow) → Paint (Repaint) → Composite

• Layout: 요소의 위치와 크기를 계산
• Paint: 픽셀을 실제로 그림
• Composite: GPU가 레이어를 합성해 화면에 출력

단계가 앞으로 갈수록 비용이 큽니다. width 같은 레이아웃 속성을 변경하면 Layout부터 전체 파이프라인을 다시 실행합니다.

width를 쓰면 어떻게 될까?

// 300ms마다 이렇게 업데이트한다면...
<div style={{ width: `${progress}%` }} />

currentTime 업데이트 (300ms마다)
  ↓
width 변경
  ↓
Layout 재계산 (Reflow) 💥
  ↓
Paint (Repaint) 💥
  ↓
Composite

음악 재생 내내 300ms마다 Layout + Paint 비용이 발생합니다.

💡 해결: transform: scaleX()

transform과 opacity는 브라우저가 Composite 단계에서만 처리합니다. GPU가 레이어를 합성하는 것이라 CPU 부담이 거의 없습니다.

currentTime 업데이트 (300ms마다)
  ↓
transform 변경
  ↓
Composite만 실행 ✅ (Layout, Paint 건너뜀)

After: 커스텀 div + transform: scaleX()

const ProgressBar = memo(function ProgressBar({ className }: { className?: string }) {
  const { duration, currentTime, playerRef, setCurrentTime } = usePlayerTime();
  const progressBarRef = useRef<HTMLDivElement>(null);
  const [isDragging, setIsDragging] = useState(false);

  const progress = duration > 0 ? (currentTime / duration) * 100 : 0;

  ...

  return (
    <div className={`progress-bar relative w-full ${className || ''}`}>
      <div
        ref={progressBarRef}
        onPointerDown={handlePointerDown}
        onPointerMove={handlePointerMove}
        onPointerUp={handlePointerUp}
        className='h-[3px] hover:h-[6px] bg-white/60 cursor-pointer relative overflow-hidden touch-none'
      >
        {/* ✅ width 대신 transform: scaleX() */}
        <div
          className='progress absolute inset-0 h-full origin-left will-change-transform'
          style={{
            transform: `scaleX(${progress / 100})`,
            background: 'linear-gradient(90deg, #5E9F94 0%, #78B7AC 65%, #A9D8CF 100%)',
          }}
        />
      </div>
    </div>
  );
});

핵심 포인트 3가지

1. transform: scaleX(0 ~ 1)

// progress가 60%라면
transform: scaleX(0.6) // 0부터 1 사이 값으로 표현

width를 60%로 변경하는 대신,** 요소를 X축으로 0.6배 늘립니다.** 브라우저 입장에서는 Layout 재계산 없이 GPU 레이어만 다시 합성하면 됩니다.

2. origin-left

className='origin-left' // transform-origin: left

scaleX는 기본적으로 요소의 중앙을 기준으로 늘어납니다. origin-left를 설정해야 왼쪽 기준으로 늘어나 진행바처럼 동작합니다.

origin-center (기본):  ←[====중앙====]→  // 양쪽으로 늘어남
origin-left:           [====왼쪽→    ]   // 왼쪽에서 오른쪽으로 늘어남 ✅

3. will-change: transform

className='will-change-transform'

브라우저에게 "이 요소는 곧 transform이 자주 바뀔 거야" 라고 미리 알려줍니다. 브라우저는 해당 요소를 별도의 GPU 레이어로 미리 분리해두어 합성 비용을 더 낮춥니다.

⚠️ will-change는 남발하면 오히려 메모리 낭비가 됩니다. 실제로 애니메이션이 자주 발생하는 요소에만 사용하는 것이 좋습니다.

결과 비교

🎓 회고

1. CSS 속성마다 렌더링 비용이 다르다

모든 CSS 변경이 동일한 비용을 갖지 않습니다. 특히 자주 바뀌는 값이라면 어떤 속성을 쓰느냐가 체감 성능에 영향을 줍니다.

비용 낮음 ← transform, opacity
비용 높음 → width, height, top, left, margin, padding

자주 업데이트되는 애니메이션 요소라면 transform/opacity 사용을 우선 고려해보세요!!

2. will-change는 힌트, 만능 해결책이 아니다

will-change-transform을 모든 요소에 붙인다고 빨라지지 않습니다. GPU 레이어 분리는 메모리를 소비하므로, 실제로 변화가 잦은 요소에만 적용해야 합니다.

다음 글에는 *가상리스트 (React Virtual) *에 대해 다뤄보려고 합니다!

지금까지 긴 글 읽어주셔서 감사합니다 :)

💬 비슷한 문제를 겪으셨거나, 더 좋은 해결 방법이 있다면 댓글로 공유해주세요!

💡 "왜 특정 컴포넌트의 상태만 업데이트되는데 전체 컴포넌트가 리렌더링되지?"

Player 컴포넌트 구조

const Player = () => {
  return (
    <>
      <PlayerBar />
      <PlayerPanel />
    </>
  );
}

음악 플레이어를 만들면서 PlayerBar와 PlayerPanel 컴포넌트를 만들었습니다.

• PlayerBar: 화면 하단에 고정되어 있는 음악 플레이어 바
• PlayerPanel: PlayerBar 를 클릭하면 토글되며 보여지는 패널 (현재 재생 중인 음악 + 재생 목록)

🚨 문제 발견

1. PlayerBar 컴포넌트 내부 구조

PlayerBar는 음악을 제어할 수 있는 여러 컴포넌트들로 구성되어 있습니다.

<PlayerControl.Frame />
<PlayerControl.ProgressBar />
<PlayerControl.Buttons />
<PlayerControl.Volume />

PlayerControl은 플레이어를 제어하는 여러 컴포넌트들을 하나로 묶어 관리하기 위해 다음과 같이 구성했습니다.

export const PlayerControl = {
  Frame: PlayerFrame,
  Buttons: PlayerButtons,
  ProgressBar,
  Volume: PlayerVolumeControl,
};

각 컴포넌트는 독립적인 역할을 가지고 있으며, 모두 usePlayer() 훅을 사용해 플레이어의 상태와 제어 함수를 가져옵니다.

2. 문제의 시작: ProgressBar

음악 플레이어를 만들면서 ProgressBar가 특정 몇초바마 업데이트되도록 구현했습니다.

// ProgressBar 컴포넌트 내부
const updateTime = (newTime: number) => {
  if (!playerRef) return;

  setCurrentTime(newTime); // 👈 currentTime 업데이트

  if (seekTimeoutRef.current) {
    clearTimeout(seekTimeoutRef.current);
  }

  seekTimeoutRef.current = setTimeout(() => {
    playerRef.seekTo(newTime, true);
  }, 50);
};

당연히 현재 Time을 계산하는 ProgressBar 컴포넌트 에서만 리렌더링이 일어날 줄 알았으나,

개발자 도구를 열고 확인해보니, PlayerButtons나 PlayerVolumeControl등 다른 컴포넌트에서도 리렌더링이 일어나는 문제를 발견했습니다. 🤦🏻‍♀️

코드 예시

// PlayerButtons 컴포넌트
const PlayerButtons = () => {
  console.log('PlayerButtons 렌더링!'); // 👈 1초마다 출력됨!?

  const { isPlaying, currentIndex, lastIndex, ... } = usePlayer();
  // ...
}

// PlayerVolumeControl 컴포넌트  
const PlayerVolumeControl = () => {
  console.log('PlayerVolumeControl 렌더링!'); // 👈 이것도!?

  const { volume, handleVolume } = usePlayer();
  // ...
}

-> usePlayer() 훅을 사용하는 모든 컴포넌트에서 time이 업데이트될 때 마다 리렌더링

🔍 원인 분석

Before: 하나의 거대한 훅

처음에는 모든 플레이어 상태와 로직을 하나의 usePlayer 훅에서 관리했습니다.

export const usePlayer = () => {
  const [playlist, setPlaylist] = useAtom(playlistState);
  const [currentVideoId, setCurrentVideoId] = useAtom(currentVideoIdAtom);
  const [isPlaying, setIsPlaying] = useAtom(isPlayingState);
  const [currentTime, setCurrentTime] = useAtom(currentTimeAtom); // 👈 1초마다 변경
  const [duration, setDuration] = useAtom(durationAtom); // 👈 1초마다 변경
  const [volume, setVolume] = useAtom(volumeAtom);
    // ... 기타 상태들


  const nextPlay = () => { /* ... */ };
  const prevPlay = () => { /* ... */ };
  const togglePlay = () => { /* ... */ };
  // ... 기타 함수들

  return {
    // 모든 상태와 함수를 반환
    playlist,
    currentVideoId,
    isPlaying,
    currentTime, // 👈 문제의 원인
    duration,    // 👈 문제의 원인
    volume,
    nextPlay,
    prevPlay,
    togglePlay,
    // ...
  };
};

왜 문제가 발생했을까?

핵심은 React Hook의 동작 방식에 있다는 것을 알아차렸습니다.

const [currentTime, setCurrentTime] = useAtom(currentTimeAtom);

이 코드는 currentTime이 변경될 때마다 usePlayer 훅 전체를 리렌더링시킵니다.

따라서 훅이 리렌더링되면:

1. 내부의 모든 함수가 재생성됩니다 (nextPlay, prevPlay, togglePlay 등)
2. 반환되는 객체가 새로운 참조를 가집니다
3. 이 훅을 사용하는 모든 컴포넌트가 리렌더링됩니다.

PlayerButtons 컴포넌트의 경우:

const PlayerButtons = () => {

  const { isPlaying, currentIndex, lastIndex, prevPlay, nextPlay, togglePlay } 
    = usePlayer();  //  👈 currentTime, duration을 사용하지 않는데도 리렌더링!
  // ...
}

currentTime을 사용하지 않아도, usePlayer()훅 자체가 리렌더링되면서 반환하는 값들이 모두 새로운 참조가 되기 때문에 컴포넌트가 리렌더링됩니다.

결과적으로 ProgressBar 업데이트 -> currentTime 변경 -> usePlayer 훅 전체 리렌더링 -> usePlayer 훅을 사용하는 모든 컴포넌트 리렌더링💥

💡 해결: 훅 분리 전략

After : 역할별로 분리된 훅

// 1️⃣ 핵심 플레이어 제어 (재생/일시정지/곡 변경 등)
export const usePlayerCore = () => {
  const [playlist, setPlaylist] = useAtom(playlistState);
  const [currentVideoId, setCurrentVideoId] = useAtom(currentVideoIdAtom);
  const [isPlaying, setIsPlaying] = useAtom(isPlayingState);
  const [playerRef, setPlayerRef] = useAtom(playerRefAtom);
  const [isPlayerReady, setIsPlayerReady] = useAtom(isPlayerReadyAtom);
  // currentTime, duration은 포함하지 않음! ✅

  const currentIndex = useAtomValue(currentIndexAtom);
  const currentVideo = useAtomValue(currentVideoAtom);

  // ...

  const nextPlay = (e: MouseEvent<HTMLButtonElement>) => { /* ... */ };
  const prevPlay = (e: MouseEvent<HTMLButtonElement>) => { /* ... */ };
  const togglePlay = (e: MouseEvent<HTMLButtonElement>) => { /* ... */ };

  return {
    playlist,
    currentVideoId,
    isPlaying,
    currentIndex,
    currentVideo,
    nextPlay,
    prevPlay,
    togglePlay,
    // ...
  };
};

// 2️⃣ 시간 관련 (ProgressBar 전용)
export const usePlayerTime = () => {
  const [currentTime, setCurrentTime] = useAtom(currentTimeAtom); // 👈 여기로 격리
  const [duration, setDuration] = useAtom(durationAtom); // 👈 여기로 격리
  const playerRef = useAtomValue(playerRefAtom);

  const seekTo = (seconds: number) => {
    if (playerRef) {
      playerRef.seekTo(seconds, true);
    }
  };

  return {
    currentTime,
    setCurrentTime,
    duration,
    setDuration,
    seekTo,
  };
};

// 3️⃣ 볼륨 관련 (Volume Control 전용)
export const usePlayerVolume = () => {
  const [volume, setVolume] = useAtom(volumeAtom);
  const playerRef = useAtomValue(playerRefAtom);

  const handleVolume = (volume: number) => {
    if (playerRef) {
      playerRef.setVolume(volume);
    }
  };

  return {
    volume,
    setVolume,
    handleVolume,
  };
};

// 4️⃣ 기존 API 유지 (하위 호환성)
export const usePlayer = () => {
  const core = usePlayerCore();
  const time = usePlayerTime();
  const volumeCtrl = usePlayerVolume();

  return {
    ...core,
    ...time,
    ...volumeCtrl,
  };
};

이후 컴포넌트별 적용/수정

분리한 훅을 각 컴포넌트에 맞게 적용했습니다.

PlayerButtons - usePlayerCore 사용

const PlayerButtons = () => {
  // ✅ 이제 currentTime 변경에 영향받지 않음!
  const { 
    isPlaying, 
    currentIndex, 
    lastIndex, 
    isActuallyPlayerReady, 
    prevPlay, 
    nextPlay, 
    togglePlay 
  } = usePlayerCore(); 

  // ...
}

ProgressBar - usePlayerTime 사용

const ProgressBar = () => {
  // ✅ 시간 관련 상태만 구독
  const { duration, currentTime, playerRef, setCurrentTime } = usePlayerTime();

  const progress = duration > 0 ? (currentTime / duration) * 100 : 0;

  // ...
}

PlayerVolumeControl - usePlayerVolume 사용

const PlayerVolumeControl = () => {
  // ✅ 볼륨 관련 상태만 구독
  const { handleVolume, volume, setVolume } = usePlayerVolume();

  // ...
}

🔬 한 발 더: PlayerFrame의 숨겨진 리렌더링

훅 분리로 PlayerButtons, ProgressBar, PlayerVolumeControl의 불필요한 리렌더링은 해결됐습니다. 그런데 조금 더 살펴보니, PlayerFrame에도 같은 구조의 문제가 남아 있었습니다.

PlayerFrame은 300ms마다 현재 재생 시간을 YouTube 플레이어에서 읽어와 currentTimeAtom을 업데이트(write) 하는 역할을 합니다.

그런데 기존 코드를 보면:

// Before: PlayerFrame
const PlayerFrame = () => {
  const {
    setCurrentTime, // 👈 write만 필요한데
    setDuration,
    volume,
    // ...
  } = usePlayer(); // ← currentTime, duration을 read까지 구독하고 있음!

usePlayer()로 setCurrentTime을 가져오면서, 동시에 currentTimeAtom 값의 변화도 구독(read) 하게 됩니다.

결과: 300ms마다 currentTimeAtom이 업데이트될 때마다, 그 값을 set한 장본인인 PlayerFrame 자신도 리렌더링 발생! 🤦🏻‍♀️

💡 해결: useSetAtom으로 write-only 구독

Jotai는 useSetAtom이라는 훅을 제공합니다. 이 훅은 atom의 setter만 반환하고, atom 값이 변경되어도 해당 컴포넌트를 리렌더링하지 않습니다.

// After: PlayerFrame
import { useSetAtom } from 'jotai';
import { currentTimeAtom, durationAtom } from '@/store/player/atom';

const PlayerFrame = () => {
  const { ... } = usePlayerCore();              // currentTime 구독 없음 ✅
  const setCurrentTime = useSetAtom(currentTimeAtom); // write-only ✅
  const setDuration = useSetAtom(durationAtom);       // write-only ✅
  const { volume } = usePlayerVolume();

  // 300ms 인터벌에서 setCurrentTime을 호출해도
  // PlayerFrame은 더 이상 리렌더링되지 않음!

  ...

useAtom vs useSetAtom 비교

// useAtom: 값을 읽고 쓸 수 있지만, 값 변경 시 리렌더링 발생
const [currentTime, setCurrentTime] = useAtom(currentTimeAtom);

// useSetAtom: setter만 반환, 값이 바뀌어도 이 컴포넌트는 리렌더링 없음
const setCurrentTime = useSetAtom(currentTimeAtom);
// "write만 필요한 곳에서는 굳이 값을 구독할 필요가 없다"는 원칙을 적용한 것입니다.

결과

Before

ProgressBar 업데이트 (300ms마다)
  ↓
usePlayer 훅 전체 리렌더링
  ↓
PlayerButtons 리렌더링 🚨
PlayerVolumeControl 리렌더링 🚨
기타 컴포넌트들 리렌더링 🚨

After (훅 분리) - step 1

ProgressBar 업데이트 (300ms마다)
  ↓
usePlayerTime 훅만 리렌더링
  ↓
ProgressBar만 리렌더링 ✅
PlayerFrame은 여전히 리렌더링 중... 🚨

After (useSetAtom 적용 후)- Step 2

ProgressBar 업데이트 (300ms마다)
↓
usePlayerTime 훅만 리렌더링
↓
ProgressBar만 리렌더링 ✅
PlayerFrame 리렌더링 없음 ✅

개선 후:

• 불필요한 리렌더링 감소
• 성능 향상 체감

🎓 회고

1. Hook도 컴포넌트처럼 역할별 분리가 중요하다

처음에는 "한 곳에 모아두면 관리하기 편하겠다"고 생각했지만, 오히려 성능 문제를 야기하고 디버깅의 어려움도 있었습니다.

좋은 Hook 설계:

• 단일 책임 원칙 적용할 것
• 역할별로 다른 로직은 분리할 것
• 변경 빈도가 다른 상태는 분리 고려 해볼 것

2. 사용하지 않는 값도 리렌더링을 발생시킬 수 있다

// ❌ currentTime을 안 써도 리렌더링!
const { isPlaying, currentTime } = usePlayer();

// ✅ 필요한 것만 가져오기
const { isPlaying } = usePlayerCore();

hook이 반환하는 객체의 참조가 바뀌면, 구조 분해 할당으로 가져온 값들도 새로운 참조가 된다.

3. 성능 문제는 측정해서 발견하자

console.log로 간단하게 리렌더링을 확인했지만, React DevTools의 Profiler를 사용하면 더 정확한 측정이 가능하다고 하니, 해당 툴 이용해서 디버깅해보자!!

4. write만 필요하면 useSetAtom을 쓰자

atom을 업데이트하는 역할만 하는 컴포넌트에서 useAtom을 쓰면, 자신이 업데이트한 값에 의해 자기 자신이 리렌더링되는 역설적인 상황이 생긴다.

// ❌ set만 쓰는데 value도 구독
const [currentTime, setCurrentTime] = useAtom(currentTimeAtom);

// ✅ setter만 가져오기 → 리렌더링 없음
const setCurrentTime = useSetAtom(currentTimeAtom);

다음 글에는 ProgressBar의 리페인트를 줄이는 방법에 대해 다뤄보려고 합니다! width 속성 대신 transform: scaleX()를 사용해서 GPU 가속을 활용하는 방법을 공유할 예정입니다!

지금까지 긴 글 읽어주셔서 감사합니다 :)

💬 비슷한 문제를 겪으셨거나, 더 좋은 해결 방법이 있다면 댓글로 공유해주세요!

안녕하세요. 오랜만입니다. 붉은 말의 새해가 찾아왔네요!🌅 모두들 새해 복 많이 받으세요!ㅎㅎ

저는 작년 10월 정도부터 Yoon-Play2라는 AI 기반 음악 플레이어를 만들게 되었습니다.

이번에는! 단순히 음악을 재생하는 플레이어가 아니라, 사용자의 입력 텍스트 기반으로 동적으로 카테고리를 추천해주는 스마트한 플레이어를 목표로 하고 있습니다.🥳

이 시리즈에서는 프로젝트를 진행하며 겪은 기술적 챌린지와 해결 과정을 공유하려고 합니다.

🤔 왜 다시 만들게 되었나?

사실 이전에 원티드에서 주최했던 프리온보딩 코스를 참여하고, 짧은 기간 안에 yoon-play라는 뮤직 플레이어를 만든적이 있습니다 (3일안에 기획, 디자인, 개발 모두 다 해야했던,,🤦🏻‍♀️)

기존에는 정적인 감정, 장르 카테고리를 제공하고, 유튜브 api를 활용해서 플레이리스트를 제공하는 형식이었어요.

당시에는 만족스럽던 프로젝트였네요 ㅎㅎ

하지만 실제로 뮤직 플레이어의 필수 기능들이 빠져있기도 하고, 정적 카테고리 말고 "ai가 사용자의 상태, 기분을 파악해서 카테고리를 추천해주는 것은 없을까?"라는 생각이 들며 새롭게 만들어 보기로 했습니다!!

프로젝트를 진행하면서 비슷한 기능이나 내용일지도 모릅니다.

하지만, 새로운 기술 스택을 선택하고, 보다 더 좋은 코드로 작성되길 바라는 마음으로 다시 시작하려고 합니다.

🛠️ 기술 스택

이 프로젝트에서 사용할 기술들입니다:

Frontend

• Next.js 15, TypeScript, Tailwind CSS

상태 관리 & 데이터

• React Query (TanStack Query),~~(Recoil)~~ Jotai, IndexedDB (idb)

AI & API

• OpenAI API, YouTube Data API

Deploy

• Vercel

🎯 목표와 핵심 기능

핵심 기능

1. 🤖 AI 기반 카테고리 추천 (핵심 차별화 포인트!)

• 사용자 텍스트 기반으로 음악 카테고리, 장르 추천
• "오늘 기분이 우울해" → 위로되는 음악 추천
• "집중하고 싶어" → 집중력 높이는 음악 추천

2. 기본 플레이어 기능 (Yoon-Play1에서 놓쳤던 것들도 포함)

• 재생/일시정지/이전/다음
• 볼륨 컨트롤
• 프로그레스바

3. 재생목록 관리(feat. indexedDB)

• 사용자 재생목록 생성/수정/삭제
• 좋아요 목록
• (시간이 된다면?)IndexedDB로 오프라인 저장

4. 검색 기능

• 자유롭게 플레이리스트 검색

5. 성능 최적화

• 대용량 재생목록 가상 리스트
• 불필요한 리렌더링 방지
• 이미지 lazy loading

📝 시리즈 구성

이 프로젝트를 진행하며 겪은 이슈들과 해결 과정을 정리할 예정입니다 ㅎㅎ

🚀 이제 시작합니다

"일단 돌아가게 만들기"에서 벗어나, 제대로 된 웹 애플리케이션을 만들어보려고 합니다.

그 과정에서 마주친 문제들, 고민했던 지점들, 그리고 해결 방법들을 솔직하게 공유하겠습니다.

혹시라도 비슷한 프로젝트를 진행하시는 분들께 도움이 되었으면 좋겠습니다!

다음 글에서는 오디오 플레이어를 만들며 겪은 첫 번째 이슈부터 시작하겠습니다.

감사합니다.

💬 궁금한 점이나 피드백은 댓글로 남겨주세요!

해당 자료는 유튜브 신찬수 한국외대 교수님 강의를 시청하고 정리되어 있습니다. 🙏🏻

한방향 연결리스트

삽입 연산 With Python(강의)

pushFront, pushBack

class SinglyLinkedList:
  def __init__(self):
    self.head = None
    self.size = 0

  def __len__(self):
    return self.size

  def pushFront(self, key):
    new_node = Node(key)
    new_node.next = self.head;
    self.head = new_node
    self.size += 1

  def pushBack(self, key):
    v = Node(key)
    if len(self) == 0:
      self.head = v
    else:
      tail = self.head
      while tail.next != None:
        tail = tail.next
      tail.next = v
    self.size += 1

삭제 연산 With Python(강의)

popFornt

def popFront(self):
  if len(self) == 0:
    return None
  else:
    x = self.head
    key = x.key
    self.head = x.next
  self.size -= 1
  del x
  return key

popBack

def popBack(self):
  if len(self) == 0: return None
  else: # running techinque
    prev, tail = None, self.head
    while tail.next != None:
      prev = tail
      tail = tail.next
    if len(self) == 1:
      self.head = None
    else
      prev.next = tail.next # None
      key = tail.key
      del tail
      self.size -= 1
      return key

탐색 연산 With Python(강의)

def search(self, key):
  # key 값의 노드를 리턴, 없으면 None 리턴
  v = self.head
  while v.next != None:
    if v.key == key:
      return v
    v = v.next
  return None # or return v (== None)

한 방향 연결 리스트를 for...of 루프로 순회하는 법, 즉 제너레이터와 이터러블 구현을 설명해줄게.

제너레이터

• 한 방향 연결리스트를 for ..of 루프로 순회하려면 이터러블(iterable) 이어야 한다. (pytho,js 모두 동일)
• 따라서 yield가 포함된 제너레이터 함수를 사용하여 간단하게 이터러블을 만든 후 사용해야한다.

With JS 코드

class MyList
...

// 해당 코드 !!
*[Symbol.iterator]() {
    let current = this.head;
    while (current !== null) {
      yield current.value;
      current = current.next;
    }
  }

탐색 사용법

const list = new MyList();
for (let value of list) {
  console.log(value);
}

• 클래스에 위와 같은 이터러블이 생성되어있다면 그 클래스로 만든 객체 즉 한 방향 연결리스트가 for문으로 순회가 가능하게 된다!!!

한방향 연결리스트의 수행 시간

• pushFront: O(1)
• popFront: O(1)
• pushBack: O(n)
• popBack: O(n)

pushBack과 popBack은 tail을 쫓아가야하기 때문에 n번 필요

해당 자료는 유튜브 신찬수 한국외대 교수님 강의를 시청하고 정리했으며 코딩테스트 합격자되기 자바스크립트편 도서를 읽고 추가적으로 정리되어 있습니다. 🙏🏻

배열 vs 연결리스트

• 배열은 메모리 공간에 순차적으로 배치되므로 인덱스로 접근이 가능하지만,
• 연결리스트는 연속된 메모리 공간에 들어있는 것이 아닌 메모리상에서 흩어져 있어서 상수시간 접근이 불가능

연결리스트 (Linked List)

• 노드란 data 값(key)과 주소의 값(link)로 구성된 한쌍을 말하며, 노드와 링크로 연결된 자료구조를 말한다.
• 가장 앞의 노드를 헤드 노드(head node)로 칭한다.
• 마지막 노드에는 None/null이 있다

장점

• 배열은 중간에 데이터를 삽입하게 되면 뒤에 있는 데이터들이 n번씩 밀려나면서 이동해야하지만, 연결리스트는 중간에 새로운 노드 삽입 후 다시 연결만 하면 된다. 즉, 두 개의 링크 주소만 바꾸면 된다.
• 따라서 insert 작업에는 O(1)(상수시간)이 걸린다

연결리스트의 종류

• 한 방향, 양 방향 연결리스트 2종류가 있음

한 방향 리스트

• 링크가 한쪽 방향으로만 연결되어 있는 것으로, 한 방향으로만 갈 수 있고 반대 방향으로는 갈 수 없다.

양 방향 리스트

• 양쪽 방향으로 링크가 있어서 노드의 양쪽 방향으로 모두 이동할 수 있다.

구현하기

유튜브 강의는 파이썬으로 작성되어 있습니다.

class Node:
  def __init__(self, key = None):
    self.key = key
    self.next = None
  def __str__(self):
    return str(self.key) //print(v.key) 대신 print(v)로 쓸 수 있다.

사용 예시

a = Node(3)
b = Node(9)
c = Node(-1)

a.next = b
b.next = c

• c 노드를 테일 노드(tail node)라고 부른다.

• FIFO(First In First Out)의 구조를 갖춘 자료구조
• 먼저 들어온 것이 먼저 나가는 특징

스택의 연산

• 삽입: push
• 삭제: pop

배열을 이용한 큐

class Queue {
    items = [];
    front = 0;
    rear = 0;

    pop() {
        return this.items[this.front++];
    }

    push(item) {
        this.items.push(item)
        this.rear++;
    }

    isEmpty() {
        return this.front === this.rear
    }
}

연산의 수행시간

• pop : O(1)(상수 시간)
• push : O(1)
• isEmpty : O(1)

큐 예제 1) 요세푸스 문제

(코딩테스트 합격자되기 도서 참고)

• N명의 사람이 원형으로 서 있다.
• 임의의 숫자 K가 주어졌을 때 다음과 같이 사람을 없앤다

1. 1번 번호표를 가진 사람을 기준으로 K번째 사람 제거
2. 제거된 사람 다음 사람을 기준으로 다시 K번째 사람 제거

N과 K가 주어질 때 마지막에 살아 남은 사람의 번호는?

class Queue {
    items = [];
    front = 0;
    rear = 0;

    size() {
        return this.rear - this.front;
    }

    pop() {
        return this.items[this.front++];
    }

    push(item) {
        this.items.push(item);
        this.rear++;
    }
}


function Josephus(n, k) {
    const queue = new Queue();

    //1부터 n까지 queue에 넣기
    for(let i = 1; i <= n; i++) {
        queue.push(i);
    }
    // 한 사람이 남을 때까지 반복    
    while(queue.size() > 1) {
        // k-1번째 사람은 pop+ push
        for(let i = 0; i < k-1; i++) {
            queue.push(queue.pop());
        }
        queue.pop();
    }

    return queue.pop();
    // 마지막에 남아있는 사람의 번호
}

• k-1번째까지의 사람은 pop한 뒤 다시 queue에 넣어야함! => for문
• K번째 사람은 pop
• 한 사람이 남을 때까지 반복

해당 자료는 유튜브 신찬수 한국외대 교수님 강의를 시청하고 정리했으며 코딩테스트 합격자되기 자바스크립트편 도서를 읽고 추가적으로 정리되어 있습니다. 🙏🏻

Stack (스택)

• 삽입은 가장 아래부터 쌓이게 되고, 가장 맨 위에(마지막에 들어온) 있는 값이 가장 먼저 삭제된다. (LIFO)

스택의 연산

• 삽입: push
• 삭제: pop

강의 내에는 파이썬으로 작성되어있어, 해당 코드는 코딩테스트 합격자되기 도서를 참고해서 작성했습니다.

const stack = []; // 스택 초기화
const maxSize = 10; // 스택의 최대 크기

function isFull(stack) {
    return stack.length === maxSize;
}

function isEmpty(stack) {
    return stack.length === 0;
}

function push(stack, item) {
    if(isFull(stack)) {
        console.log('가득 찼습니다');
    } else {
        stack.push(item);
    }
}

function pop(stack){
    if(isEmpty(stack)) {
        return null;
    } else {
        return stack.pop();
    }
}

연산의 수행시간

• isFull : O(1)(상수 시간)
• isEmpty : O(1)
• push: O(1)
• pop: O(1)

스택 예제 1) 괄호 맞추기

(코딩테스트 합격자되기 도서 참고)

• 소괄호는 짝을 맞춘 열린 괄호''와 닫힌 괄호''로 구성
• 문제에서는 열린 괄호나 닫힌 괄호가 마국 뒤섰인 문자열을 준다.
• 이때 정상으로 열고 닫혔는지 판별하는 solution()함수 구현
• 정상적으로 열고 닫혔다면 true, 아니라면 false return

function solution(str) {
    cosnt stack = []; // 하나씩 담을 저장소 

    for(const s of str) {
        if(s === '(') {
            stack.push(s);
        } else if (s === ')') {
            if(stack.length === 0) {
                return false;
            } else {
                stack.pop();
            }
        }
    }

    return stack.length === 0;
}

• 열린 괄호 '('는 언젠가는 닫혀야 하는 괄호이므로 스택에서 기다리게 할 것.
• 닫는 괄호 ')'는 앞에서 열린 게 있어야 닫을 수 있으니까 스택에서 마지막에 연 괄호를 pop해서 짝을 맞추는 역할

case1 '('가 먼저 있다 => stack에 push case2 ')'가 왔고 스택이 비어있다? => 바로 false => 예) ')(' case3 ')'가 왔고, 스택이 비어있지 않다 => '('는 있을테니까 열고 닫히게 되었으므로 stack pop!

• index로 임의의 원소를 접근할 수 있다.
• 연산자 []로 접근할 수 있다. 상수시간(O(1))에 값을 알 수 있다.
• 삽입: push, shift
• 삭제: pop, unshift

2. Stack, Queue, deQueue

• 제한된 접근(삽입,삭제)만 허용한다.

Stack

• LIFO(Last In First Out)
• 마지막에 들어간 것이 첫번째로 나오는 특징
• push: 아래에서부터 차곡차곡 삽입된다.
• pop: 맨 위 값(가장 나중에 들어온 값)에서부터 삭제한다.

Queue

• FIFO(First In First Out)
• 처음 들어간 것이 첫번째로 나오는 특징 (은행 줄 기다리기)
• push : 삽입은 아래서부터 차곡차곡 쌓인다.
• pop: 삭제 역시 아래의 값(가장 먼저 들어온 값)부터 수행한다.

deQueue

• stack + queue 자료구조
• 삽입은 위, 아래로 수행할 수 있다.
• 삭제 역시 위, 아래로 수행할 수 있다.

3.linked list(연결리스트)

• 데이터를 저장할 때, 각 요소가 다음 요소의 주소(포인터)를 함께 저장해서 연결된 형태로 구성된 자료구조
• 인덱스를 바로 접근할 수 없다.
• 포인터로 요소들을 연결해 만든 유연한 자료구조 → 삽입/삭제엔 강하지만, 인덱스 접근은 느림

해당 자료는 유튜브 신찬수 한국외대 교수님 강의를 시청하며 정리했습니다. 🙏🏻

배열(Array) VS 리스트(List)

• 가장 기본적인 순차적인(순서대로) 자료구조

메모리 구조와 동작 방식에서 차이가 있음

const A = [2, 4, 0, 5];

배열

배열은 index를 이용해 특정 위치의 값을 상수시간 내에 읽고 쓸 수 있게 해주는 자료구조이다.

리스트

리스트는 각 원소가 따로따로 저장되며, 포인터(주소)를 통해 연결되는 자료구조이다.

2, 4, 0, 5는 객체가 되고, 따로 저장되며, A[0]은 2가 저장된 곳의 주소를 가리키고, A[1]은 4가 저장된 곳의 주소를 가리킨다.

A[2] = A[2] + 1을 수행하면 A[2]가 변경되는 것이 아니라, 그대로 0이 있고 1을 갖고있는 객체가 연결되며, A[2]가 가리키던 0 객체를 더이상 가리키지 않고, 1을 갖고 있는 객체를 가리키게 된다.

리스트의 이점

• 용량을 자동 조절한다. 공간이 부족하면 더 큰 용량을 할당하여 값을 저장.
• 동적 배열(Dynamic Array) => 처음부터 고정된 크기를 가지지 않는다!

let arr = [];
for (let i = 0; i < 10000; i++) {
  arr.push(i);  // 크기를 미리 선언하지 않아도 계속 들어감
}
console.log(arr.length); // 10000

list의 연산별 시간복잡도(Big-O)

Python

A.append(), A.pop: O(1) 평균 A.insert(), A.remove(): O(n) w.c A.index(), A.count(): O(n) w.c

JS

A.push(), A.pop() => O(1) A.unshift(), A.shift() => O(n) A.indexOf(),A.filter()... => O(n)

해당 자료는 유튜브 신찬수 한국외대 교수님 강의를 시청하며 정리했습니다. 🙏🏻

앞서 4강에서 본 3개의 함수의 시간 복잡도:

• Algorithm1(arrayMax): T1(n) = 2n - 1
• Algorithm2(sum1): T2(n) = 4n + 1
• Algorithm3(sum2): T3(n) = (3/2)n2 - (3/2)n + 1

도출할 수 있는 명제:

• Algorithm2가 Algorithm1보다 2배 느리다.
• Algorithm3는 n < (5/3) 이면 Algorithm2보다 빠르다.
• Algorithm3는 모든 n에 대해서 Algorithm1보다 느리다.
• Algorithm3는 n > 5/3이면 항상 Algorithm2보다 느리다

T1(n), T2(n)은 n에 대해 선형적으로 증가. 최고차항이 1차항 T3(n)은 n에 대해 제곱으로 증가. 최고차항이 n의 2제곱

n에 대한 최고차항 = 단위 시간의 증가율을 결정

Big-O 표기법

함수 값을 결정하는 최고차항만으로 간단하게 표기

T1(n) = 2n-1 => T1(n) = O(n) T2(n) = 4n+1 => T2(n) = O(n) T3(n) = 3/2n2-3/2n+1 => *T3(n) = O(n^2) *

표기방법

1. 최고차항만 남긴다.
2. 최고차항 계수(상수) 생략한다.
3. Big-O로 감싸서 적는다 => O(최고차항)

집합으로 이해하기

T1(n) = O(n) T2(n) = O(n) 위 두 함수는 O(n) 집합 안에 들어있는 것으로 보면 된다.

즉,

T1(n) ∈ O(n) T2(n) ∈ O(n)

문제 예시1

def increment_one(a):
    return a + 1

T1(n) = 1 => 0(n^0) => O(1)

문제 예시2

def number_of_bits(n):
    count = 0
    while n > 0 :
        n = n // 2
        count += 1

    return count

n/2^count = 1 n = 2^count 10g2n = count 즉 while문 log2n번 실행

T(n) =C log2n + 1 =>** O(log2n)**

해당 자료는 유튜브 신찬수 한국외대 교수님 강의를 시청하며 작성되어 있습니다. 🙏🏻

알고리즘 시간 복잡도(time complexity)

알고리즘 시간 복잡도를 계산하는 방법

1. 모든 입력에 대해 기본연산 횟수를 더한 후 평균(현실적으로 불가능)
2. 가장 안 좋은 입력(Worstcase input)에 대한 기본 연산 횟수를 측정(worstcase time complexity)

2번의 방법 경우 어떤 입력에서도 W.T.C보다 수행시간이 크지 않다. 즉 연산 횟수가 보장된다!

알고리즘 수행 시간 복잡도를 정의하는 방법

알고리즘 수행 시간 = 최악의 입력에 대한 기본 연산 횟수

예시

input: n개의 정수를 갖는 배열 A output: A의 수 중에서 최대값 리턴

alogirithm arrayMax(A, n):
  currentMax = A[0]

  for i = 1 to n-1 do
    if currentMax < A[i]:
      currentMax = A[i]
  return currentMax

위 코드에서 currentMax < A[i] 조건이 항상 참일 경우 가장 연산횟수가 크다.

예시: A = [2, 5, 7, 9, 15, 26]

for문이 n - 1만큼 실행할 때 기본연산은 2번 수행씩 된다. (if 참인지 비교, 참일경우 하위 코드 실행)

대입연산: 1 단위시간 반복문: (n - 1) * 2 = 2n - 2 단위시간

즉, T(n) = 2n - 1

n = 6 일때, T(6) = 12 - 1 = 11

시간 복잡도 예시 1

algorithm sum1(A, n):
  sum = 0                  # 대입연산 (1 단위시간)
  for i = 0 to n - 1 do
    if A[i] % 2 == 0:    # 나누고, == 맞는지 확인(2 단위시간)
      sum += A[i]        # 더하고 대입하라(2 단위시간)
  return sum

A: 모든 값이 짝수인 경우 W.C 입력인 것

T(n) = 4n + 1

=> for 문이 n번 돌고, if 2번, 참일 경우 2번 즉 4번, 첫번째 대입 해서 1번!

시간 복잡도 예시 2

algorithm sum2(A, n)
  sum = 0                 # 대입 연산(1 단위시간)
  for i = 0 to n - 1 do   
    for j = i to n - 1 do  
      sum += A[i] * A[j] # 더하고 대입(2 단위), 곱하기(1 단위)
  return sum

두번째 for문에 대해 j가 1+2+3+...+n 번인 것임므로 n(n+1)/2

=> for문이 n번 돌고, 그 하위 for문은 n(n+1)/2, if 부분은 3번, 즉 n(n+1) / 2* 3 * n, 첫번째 대입 해서 1번!

T(n) = ((3/2)n)(n+1) + 1 = (3/2)n^2 - (3/2)n + 1

해당 자료는 유튜브 신찬수 한국외대 교수님 강의를 시청하며 작성되어 있습니다. 🙏🏻

자료구조와 알고리즘 성능1: 가상컴퓨터 + 가상언어 + 가상코드

자료구조와 이를 해결하기 위한 알고리즘이 어느 정도의 성능을 보이는지 측정하고 비교해보자.

현실의 문제점

문제 1

• "자료구조"와 "알고리즘"을 생각하여 코드(C, Javascript, Python 등)로 구현하면 컴퓨터에서 동작하게 되지만,
• 각 컴퓨터마다 HW/SW 환경이 다를 수 있으므로 다른 성능을 낼 수 있다

-> 즉 이는 큰 문제가 될 수 있다.

문제 2

• 입력의 크기가 다양할 수 있다.
• 입력이 커질 수록 실행 시간도 많아지는데, 이 입력에 대해 코드 실행속도를 어떻게 정의하고 비교할 수 있을까?

해결책

가상의 컴퓨터(Virtual Machine) + 가상언어(Pseudo language) + 가상코드(Pseudo Code) 를 사용하자.

이렇게 하면 HW/SW 환경에 독립적이기 때문에 누구나 같은 환경에서 알고리즘을 객관적으로 비교할 수 있게 된다.

가상컴퓨터

가상 컴퓨터(Virtual Machine/Random Access Machine) Turing Machine -> von Neumann: RAM(Random Access Machine)

RAM = CPU + Memory + 기본연산(단위시간에 수행되는 연산들의 모음)

즉, CPU와 Memory와 함께 계산을 하는 것이 알고리즘이고, 알고리즘이 RAM이라는 가상컴퓨터 위에서 돌아가는 것!

RAM은 가상의 컴퓨터 환경으로써 알고리즘 성능을 측정하는 기준 플랫폼이다.

기본연산

배정, 대입, 복사 연산 등과 같이 일반적으로 한 단위 시간 안에 수행되는 연산

1. A = B (Read and Write)
2. 산술연산: +, -, *, / (%, 내림, 올림, 반올림 등은 기본 연산으로 보지 않으나, 수업에서는 이들도 단위시간에 들어가는 것으로 간주)
3. 비교연산: >, >=, <, <=, ==, !=
4. 논리연산: AND, OR, NOT
5. 비트연산: bit-AND, OR, NOT

즉, 우리는 기본연산으로 정의한 가상의 컴퓨터를 RAM이라고 칭하고, 이 RAM 모델 위에서 알고리즘이 실행되고 측정되는 시간을 비교하는 알고리즘 복잡도를 계산하고 비교할 것이다.

가상 언어 (Pseudo/Virtual Languages)

1. 배정, 산술, 비교, 논리, bit-논리 연산 등 기본연산을 표현할 수 있으면 됨
2. 비교: if, if else, if elseif... else 등
3. 반복: for, while 등
4. 함수: 정의, 호출, 반환 문법

가상코드 (Pseudo/Virtual Code)

1. 실제 돌아가는 코드가 아닌 가상머신(RAM)에서 돌아가는 코드이므로 자유롭게 기술할 수 있다.

작년 9월에 퇴사를 하고 올해부터 다시 이직준비를 하고 있다.🔥 올해는 벌써 상반기가 끝났고 하반기를 앞두고 있지만 여전히 코딩테스트는 어렵고, 이력서는 n번째 수정중이며 잘하고 있는지 불안한건 똑같다 🥲

[코딩테스트 합격자 되기 자바스크립트편 도서]를 추천받아 읽으면서 문제를 풀고 있고 문제풀이는 여기 깃허브에 올리고 있다🔥

아직 확실히 풀지는 못하고 있지만 계속 하다보면 되겠지..!!!!!!!!

혼자 공부하는 것보다 기록하면서 공부하면 더 이해도가 높아질 것 같아 지금이라도 다시 해보려고 한다!!

자료구조와 알고리즘 강의도 추천받아 듣고 있고, 핑계되며 반은 안/못 읽은 모던 자바스크립트 딥다이브 도서도 다시 읽으면서 기록해야겠다😭

진짜 다시 화이팅이다 !!!!

자료구조

• 자료는 즉 data를 말하며 해당 데이터를 담는 저장공간(memory)이 필요 => 데이터 값의 모임

• 저장된 데이터를 효과적으로 "읽기, 쓰기, 삽입,삭제, 탐색"와 같은 연산을 제공하여 수행할 수 있어야 한다.

알고리즘

• 입력된 데이터를 가지고 문제를 해결하는 논리적인 절차 / 방식

최대 공약수 알고리즘 GCD

gcd(8, 12) => max {1,2,4} => 즉, 4!

1. 빼기 방식

• 두 수를 비교해서 큰 수, 작은 수를 나타내고,
• 큰 수에서 작은 수를 빼고 값을 대입,
• 이 행동을 반복해서 한 수가 0이 되는 경우 그 때 큰수가 최대 공약수인 것.

gcd(a, b) {
    while(a !== 0 && b !== 0) {
        if(a > b) a -= b;
           else b -=a;
    }

    return a + b; // 둘 중에 하나가 0일테니
}

하지만 큰 수가 100, 작은 수가 2와 같이 큰 차이가 나는 두 수라고 하면 반복되는 횟수가 많아진다.

2. 나누기 방식

• 두 수를 비교해서 큰 수, 작은 수를 나타내고,
• 큰 수에서 작은 수를 나누고 나머지 값을 대입
• 이 행동을 반복해서 한 수가 0이 되는 경우, 그때 큰 수가 최대 공약수

gcd(a, b) {
    while(a !== 0 && b !== 0) {
        if(a > b) a %= b;
        else b %= a;
    }

    return a + b;
}

1번 방식으로는 gcd(2,100) -> gcd(2,98) -> gcd(2, 96)... gcd(2,0) 으로 2가 나오지만,

2번 방식으로는 gcd(2,100) -> gcd(2, 0) 한 번 만으로 결과 출력 가능

즉 더 빠른 결과 값을 나타낼 수 있음

해당 자료는 유튜브 신찬수 한국외대 교수님 강의를 시청하며 작성되어 있습니다. 🙏🏻

제한사항

• arr은 자연수를 담은 배열입니다.
• 정수 i, j에 대해 i ≠ j 이면 arr[i] ≠ arr[j] 입니다.
• divisor는 자연수입니다.
• array는 길이 1 이상인 배열입니다.

입출력 예

입출력 예#1

arr의 원소 중 5로 나누어 떨어지는 원소는 5와 10입니다. 따라서 [5, 10]을 리턴합니다.

입출력 예#2

arr의 모든 원소는 1으로 나누어 떨어집니다. 원소를 오름차순으로 정렬해 [1, 2, 3, 36]을 리턴합니다.

입출력 예#3

3, 2, 6은 10으로 나누어 떨어지지 않습니다. 나누어 떨어지는 원소가 없으므로 [-1]을 리턴합니다.

나의 풀이

function solution(arr, divisor) {
    let answer = [];
    for(let i=0; i<arr.length; i++){
        arr[i] % divisor === 0 && answer.push(arr[i])
    }
    return answer.length > 0 ? answer.sort((a,b) => a-b) : [-1];
} 

1. divisor에 의해 나누어지는 배열의 원소값이 있다면 answer에 push한다.
2. answer에 값이 있다면 오름차순 정렬로 나타낸다.
3. answer에 값이 없다면 -1을 return한다.

나의 풀이

function countFn(num){
    let count = 0;

    for(let i=1; i<=num; i++){
       if(num % i === 0) count++;
    }
    return count;
}

function solution(left, right) {
    let answer = 0;

    for (let i=left; i<=right; i++) {
        let count = countFn(i)
        count % 2 ? answer -= i : answer += i
    }
    return answer
}

1. left부터 right사이에 있는 숫자를 확인해야하므로 반복문으로 작성한다.
2. 가독성을 위해 countFn으로 따로 함수를 만든다.
3. countFn함수는 약수의 개수를 구하는 함수이다.
4. 약수의 개수가 짝수이면 answer에 약수의 개수가 짝수인 값을 더하고 홀수라면 뺀다.

놀이기구를 count번 타게 되면 현재 자신이 가지고 있는 금액에서 얼마가 모자라는지를 return 하도록 solution 함수를 완성하세요. 단, 금액이 부족하지 않으면 0을 return 하세요.

입출력 예

입출력 예 설명

이용금액이 3인 놀이기구를 4번 타고 싶은 고객이 현재 가진 금액이 20이라면, 총 필요한 놀이기구의 이용 금액은 30 (= 3+6+9+12) 이 되어 10만큼 부족하므로 10을 return 합니다.

나의 풀이

function solution(price, money, count) {
    let totalPrice = 0;

    for(let i=1; i<=count; i++) {
        totalPrice += price * i;
    }
    return money > totalPrice ? 0 : totalPrice - money
}

1. price 만큼 count번 추가되기 때문에 반복문을 사용하여 작성하기
2. 내가 가지고 있는 money가 총 필요한 금액보다 크다면 0을, 작다면(금액 부족) totalPrice-money 값을 return한다.

브라우저 저장소의 종류는 크게 Cookie와 WebStorage로 나눠지고 Webstorage는 localStorage와 sessionStorage로 이루어져 있다.

cookie란?

• cookie를 설정하면 이후 모든 요청은 쿠키정보를 포함하여 서버로 전송된다. => 불필요한 트래픽을 발생시킬 수 있다..!

  사용자가 따로 요청하지 않아도 브라우저가 Request시에 Request Header를 넣어 자동으로 서버에 전송

• 용량에 제한이 있고, 만료 기간을 가지며 일정 시간이 지나면 만료된다.

• 주로 서버에 HTTP 요청 시 헤더에 같이 집어 넣어 사용된다.

• 응답 헤더의 Set-Cookie에 담아 Key-Value 쌍의 Text 형식으로 데이터를 저장한다.

Cookie의 가장 큰 단점인 서버로 매번 전송을 하는 점, 그리고 용량 제한에 대한 단점을 극복하여 나타난게 WebStorage이다.

WebStorage

• LocalStaore와 SessionStorage가 존재한다.
• WebStorage는 key-value쌍의 구조로 데이터를 저장하고 key기반으로 데이터를 조회할 수 있다.

localStorage

프론트 개인프로젝트를 하면서 가장 많이 사용한 브라우저 저장소가 아닐까 싶다 🙂

• 브라우저가 닫히는 등 세션이 만료되어도 그대로 저장되어 남아있는 특징을 가지고 있다.
• 저장한 데이터를 지우지 않는 한 영구적으로 데이터가 남아있다라는 것!

SessionStorage

• localStorage와 다르게 브라우저가 닫히는 등 세션이 만료되면 저장되어있는 정보가 사라지는 특징을 가지고 있다.

✨요약!!

• 브라우저 저장소로는 Cookie와 WebStorage기 있다.
• Cookie는 매번 사용자가 설정하지 않아도 매번 서버로 전송되며 용량에 제한이 있다.
• 이러한 단점을 보완하여 나온 것이 WebStorage이다.
• WebStorage는 LocalStorage와 SessionStorage가 있다.
• LocalStorage는 저장한 데이터를 지우지 않는 한 영구적으로 보관이 가능하다. 브라우저가 닫히는 등 세션이 만료되어도 정보가 남아있음!
• SessionStorage는 브라우저가 닫히는 등 세션이 닫히면 정보가 사라진다.