어느날, 개발 중이던 페이지가 너무 버벅이는 느낌이 들었다. 이상하다고 생각하던 찰나, 메모리 사용량을 우연치않게 확인해보니 무려 700MB 가 넘어가고 있었다. 분명 페이지를 처음 로드했을 땐 200MB 정도였는데 말이다.

한번 의심이 들자 제대로 확인해보고 싶어졌다. 페이지를 켜둔 채로 6시간 후에 다시 확인해보니, 메모리 사용량은 무려 1.2GB 까지 올라가 있었다. 분명 뭔가 문제가 있다.

메모리 스냅샷

크롬 개발자 도구의 Performanc 탭에서 메모리 스냅샷을 찍어보았다.

회색은 가비지콜렉터가 수집해간 메모리, 파란색은 누수된 메모리이다. 슬슬 메모리 누수(Memory Leak) 가 의심되기 시작했다.

원인은 Swiper

페이지에서 사용 중인 슬라이더는 Swiper.js 였고, 특히 loop, onSlideChange, observer, observeParents 옵션들이 의심됐다.

useCallback 을 쓴 이유

버튼 클릭 핸들러는 다음과 같이 useCallback 으로 감싸주었다.

const handleNextClick = useCallback(() => {
  const next = (activeIndex + 1) % champions.length;
  setActiveIndex(next);
}, [activeIndex, champions.length]);

useCallback 은 컴포넌트가 리렌더링될 때마다 새로운 함수를 만드는 것이 아니라, 의존성 배열이 바뀌지 않는 이상 기존 함수를 재사용한다. 즉, 불필요한 렌더링을 막고 성능을 조금이라도 개선할 수 있다.

observer 옵션 제거

Swiper 의 observer , observeParents 옵션은 DOM 변화가 있는지 계속 감시한다. 반응형 대응에는 좋지만, 계속 DOM을 지켜보고 있는 자체가 메모리 사용량을 야금야금 늘리는 원인이 될 수도 있다고 생각했다.

그래서 나는 반응형 대신 고정형 슬라이드로 구조를 바꿨다.

리팩토링 후 코드

useEffect(() => {
  const interval = setInterval(() => {
    setActiveIndex((prev) => (prev + 1) % champions.length);
  }, 3000);
  return () => clearInterval(interval);
}, [champions.length]);

useEffect(() => {
  bgSwiperRef.current?.slideTo(activeIndex);
  contentSwiperRef.current?.slideTo(activeIndex);
}, [activeIndex]);

Swiper 컴포넌트도 간결하게 정리했다. 불필요한 옵션을 제거하고, loop, autoplay, observer 없이도 기본적인 기능만으로도 충분히 매끄러운 동작이 가능했다.

결과

수정 후에는 슬라이드가 인터랙션을 할 때만 메모리를 사용하고, 일정 시간이 지나도 메모리 사용량이 눈에 띄게 증가하지 않았다. 메모리 누수를 어느정도 잡은 것이라 생각한다.

마무리

이번 경험을 통해 내가 얻은 교훈은 다음과 같다:

• observer , autoplay , loop 같은 Swiper 편의기능이 때로는 독이 될 수 있다.

• 메모리 문제는 눈에 안 보이는 누수가 많기 때문에, 직접 확인하고 스냅샷을 찍어봐야 확실해진다.

• 불필요한 렌더링을 줄이는 useCallback 같은 훅도 작은 도움이 된다.

물론 아직 완벽하게 잡지는 못했다. 사실 어느정도 까지 잡아야 될지는 잘모르겠다. 그래도 어느정도 잡은거에 대해서 만족할 수 있었다.

무심코 넘어갔던 슬라이더 하나가, 1.2GB의 메모리 누수를 만들고 있었다. 앞으로 이 useCallback 이라던지 useMemo 에 대해서 좀 더 관심을 가지고 잘 활용해 봐야할 것 같다.

로컬에서는 정상적으로 작동했지만, 배포 서버에선 모든 플레이어가 레드팀으로만 분류되는 이상한 문제가 발생했다.

문제 상황

로컬 환경에서는 플레이어 10명이 블루팀과 레드팀으로 5:5 로 잘 나눠졌었다. 하지만 배포된 서버에서는 모든 플레이어가 레드팀으로만 처리되고 있었다.

프론트에서 올리는 .rofl 파일 자체는 동일했기 때문에, 문제는 백엔드 코드나 배포 환경 에 있을 것이라 예상했다.

로컬에서는 아래와 같이 Blue와 Red로 팀이 잘 나눠졌었다.

[
  { "nick": "player1", "team": "Blue" },
  { "nick": "player2", "team": "Red" },
]

그런데 배포 서버에서는 모든 팀이 이렇게 나와버렸다.

[
  { "nick": "player1", "team": "Red" },
  { "nick": "player2", "team": "Red" },
]

기존 코드

team: player:Team === "100" ? "Blue" : "Red"

.rofl 파일을 파싱했을 때, player.TEAM 값은 "100" 이라는 문자열로 되어 있었다. 그래서 "100" 과 "100" 을 비교하면 당연히 true 이고, Blue 팀으로 잘 분류되었었다.

하지만 배포 환경에서는 이 비교가 통하지 않았다. 즉, player.TEAM === "100" 이 조건이 실패하면서 전부 Red로 분류된 것이다.

왜 이런 일이 생겼을까?

여기서 떠올린 가능성은 다음과 같았다.

혹시 JSON 파싱 과정이나 통신 중에 "100" 이라는 문자열이 숫자 100 으로 자동으로 타입 변환된 건 아닐까?

예를 들어, 배포된 서버에서는 아래와 같은 상태였을 수 있다.

typeof player.TEAM     // "number"
player.TEAM            // 100

그러면 "100" === 100 은 false 가 되니깐 조건이 통과되지 않는다. 결국 모든 유저가 Red팀으로 들어가게 된다.

해결 방법

그래서 조건을 아래처럼 수행했다.

team: String(player.TEAM) === "100" ? "Blue" : "Red";

이렇게 하면 player.TEAM 이 "100" 이든 100 이든 무조건 문자열 "100"으로 변환해서 비교하기 때문에 타입 차이로 인한 오류를 막을 수 있다.

타입 안정성을 높이는 좋은 습관이긴 했지만, 결과적으로는 이 코드 자체가 배포 서버에 반영되지 않았던 것이 진짜 원인이었다.

진짜 원인

나는 프론트는 Netlify로 배포하고 있고, .rofl 파일의 파싱을 담당하고 있는 백은 CloudType 을 쓰고 있다.

내 착각인건지는 잘 모르겠는데 일단 Netlify 는 커밋 및 푸쉬를 하면 자동으로 재빌드 를 해주었다. 그래서 CloudType 도 그렇게 하면 재빌드를 해주었던것 같았는데 그게 아니었다.

확인을 해보니 예전 빌드를 쓰고있었다.

team: player.TEAM === 100 ? "Blue" : "Red";

이 부분이 문제였다. 당연히 player.TEAM 은 String 으로 밖에 오질 않는데 Number 값과 비교하니 false 일 수 밖에 없었다. 그러니 당연히 Red 인것이고.

로컬은 따로 node 에서 로컬서버를 돌리고 있기 때문에 수정된 버전을 사용하고 있었는데 배포사이트에서는 예전 버전을 사용하고 있었다.

따라서, 백서버를 재 빌드 하고 테스트 해보니 배포사이트에서도 잘 되는 것을 확인할 수 있었다.

느낀 점

이번 경험을 통해 몇 가지 중요한 교훈을 얻었다.

• 타입 안정성의 중요성 : 문자열과 숫자는 엄연히 다르며, 조건 비교 시 주의가 필요하다.

• 타입스크립트 도입의 필요성 : 타입스크립트였다면 이런 실수를 훨씬 더 빨리 캐치할 수 있었을 것이다.

• CI/CD 파이프라인에 대한 이해 부족 : 프론트는 Netlify 로 자동 배포되지만, 백엔드는 CloudType 에서 수동으로 배포해야 한다는 것을 몰랐다. 앞으로는 자동화된 CI/CD 설정을 적용해서 커밋할 때마다 백엔드도 자동으로 최신화되도록 구성하고 싶다.

이번 해프닝은 작은 실수였지만, 타입과 배포 환경의 중요성을 몸으로 배울 수 있었던 좋은 계기가 되었다.

그리고, 나는 다시 테스트한다고 엉망이 된 Elo 점수들을 복구하기 위해서 다시 매치들을 기록해야된다.

문제 상황

아래 그림은 현재 처한 문제이다.

Swiper로 슬라이드를 만들 때 다음과 같이 설정했다.

<Swiper
  modules={[Navigation, Autoplay]}
  navigation={{
    nextEl: ".swiper-custom-next",
    prevEl: ".swiper-custom-prev",
  }}
  spaceBetween={30}
  breakpoints={{
    1536: { slidesPerView: 4 },
    1280: { slidesPerView: 3 },
    768: { slidesPerView: 2 },
    0: { slidesPerView: 1 },
  }}
  loop={true}
  autoplay={{ delay: 3000, disableOnInteraction: false }}
  onSlideChange={(swiper) => setActiveIndex(swiper.realIndex)}
  speed={1000}
  allowTouchMove={false}
  onSwiper={(swiper) => (contentSwiperRef.current = swiper)}
>

리사이징이 빠르게 발생하면 슬라이드 레이아웃이 깨졌다. 현재 처한 상황은 내가 적용한 두 번째 슬라이드가 한 차례 밀린 현상이다. 이유를 몰라 구글링을 해봤더니 다음 두 가지 방법이 있었다.

• observer , observerParents 옵션 추가

• swiper 내부 상태 대신 swiper 인스턴스를 직접 사용하기

처음에 oberver 옵션을 사용했으나 해결되지 않았다. 결국 두 번째 방법으로 해결했다.

왜 observer 옵션이 안 먹혔을까?

swiper 내부에서 자체 상태 관리를 하고 있다. 리액트에서 setActiveIndex 와 같은 상태를 별도로 두고 swiper 내부 상태에 의존하면, 리사이징처럼 빠르게 업데이트가 일어나는 상황에서는 상태 간 동기화가 안맞을 때가 있다.

즉, 리액트에서 설정한 activeIndex와 swiper 내부의 실제 index 상태가 서로 달라질 수 있다는 이야기다. 그래서 observer 옵션을 써도, 리액트의 상태가 늦게 반영되면서 순간적인 화면 깨짐 현상이 발생했던 것이다.

swiper 인스턴스를 직접 쓰면 왜 해결되나?

swiper 내부 상태를 리액트 상태로 바꾸는 대신, swiper 가 직접 관리하는 인스턴스를 사용하는 방식으로 바꿔주었다.

onSlideChange={(swiper) => {
  const realIdx = swiper.realIndex;
  setActiveIndex(realIdx);
  bgSwiperRef.current?.slideToLoop(realIdx);
}}

이렇게 swiper 인스턴스에서 직접 현재 인덱스를 가져오면, 리액트 상태 업데이트의 지연 없이 즉시 swiper 의 실제 상태를 가져올 수 있다.

즉, swiper가 자체 관리하는 실제 슬라이드 상태에 직접 접근해서 화면이 깨지는 현상을 방지한 것이다.

(화질은 용량이슈로 인해...)

마무리

결론적으로, Swiper를 사용할 때는 swiper 인스턴스를 통해 실제 상태에 접근하는 게 더 안정적이다. 리액트의 상태를 별도로 관리하기보다는 swiper 가 자체 관리하는 상태를 직접 쓰는 방식을 기억하자.

이 간단한 팁 하나가 슬라이드 레이아웃이 무너지는 스트레스를 없애줬다.

개발하다 보면 사용자에게 작업의 성공, 실패 등을 알려주는 토스트 메세지 (mui 에서는 snackbar)가 필요하다.처음에는 단순하게 alert 으로 알려주었다가 그래도 프론트엔드 개발자를 꿈꾸는데 언제까지 alert 으로 알려주기에는 가오(?)가 안살기에 한번 달아보았다. 처음에는 단순하게 각 컴포넌트에서 토스트 메세지 상태를 관리했다. 아래 코드처럼 말이다.

// 토스트 관리를 위한 상태
const [snackMessage, setSnackMessage] = useState("");
const [snackColor, setSnackColor] = useState("success");
const [state, setState] = useState({
  open: false,
  Transition: SlideTransition,
});

// 토스트 핸들러
const showSnack = (message, type = "success") => {
  setSnackMessage(message);
  setSnackColor(type);
  setState({ open: true, Transition: SlideTransition });
};

const handleSnackClose = () => {
  setState({ ...state, open: false });
};

return (
  {/* 위에서 컴포넌트를 만든 후  */}
    <ToastContext.Provider value={{ showSnack }}>
      {children}
      <Snackbar
        open={state.open}
        autoHideDuration={3000}
        onClose={handleSnackClose}
        anchorOrigin={{ vertical: "top", horizontal: "right" }}
        slots={{ transition: state.Transition }}
      >
        <Alert onClose={handleSnackClose} severity={snackColor}>
          {snackMessage}
        </Alert>
      </Snackbar>
    </ToastContext.Provider>
  );

이렇게 해서 토스트를 만들어주었다. 그리고 여기저기 컴포넌트에 토스트가 필요한 곳에 넣어주었다. 그러다가 문득 생각이 들었다. 왜 여기저기에 복붙해서 넣어줘야하나? 이것도 훅 비스무리로 만들 수 없을까 라는 생각말이다.

여기서 문제점이 들어난 것이다.

이 방식의 문제점은 토스트 메세지가 필요한 모든 컴포넌트에서 동일한 코드를 반복해야 한다는 것이다. 같은 코드를 여러 곳에 복붙하는것은 비효율적이며 유지보수를 어렵게 만든다. 어떻게 하면 효율적으로 관리할 수 있을까?

React Context 와 Provider란?

이런 상황에서 React의 Context API가 해결책이 될 수 있다. React Context는 컴포넌트 트리 전체에 데이터를 제공하는 방법이다. 마치 지금 내가 쓰고 있는 Jotai 느낌이지만 조금 다르긴 하다. 이에 대해서는 후술할 예정이다.

일반적으로 부모 컴포넌트에서 자식 컴포넌트로 props를 통해 데이터를 전달하는데, 여러 단계의 컴포넌트를 거쳐야 하는 경우 번거로워진다. Context를 사용하면 트리 구조내 어느 컴포넌트에서든 필요한 데이터에 직접 접근할 수 있다.

Context API의 주요 구성 요소는 다음과 같다:

1. createContext: Context 객체를 생성한다.

2. Provider: Context의 값을 하위 컴포넌트에 제공한다.

3. useContext: Context의 값을 읽는 Hook 이다.

토스트 메세지 관리를 위한 Context 구현

먼저 토스트 메세지 관리를 위한 Context와 Provider를 만들었다.

"use client";

import { Alert, Slide, Snackbar } from "@mui/material";
import { createContext, useContext, useState } from "react";

const ToastContext = createContext(null);

function SlideTransition(props) {
  return <Slide {...props} direction="left" />;
}

export function ToastProvider({ children }) {
  // 토스트 관리를 위한 상태
  const [snackMessage, setSnackMessage] = useState("");
  const [snackColor, setSnackColor] = useState("success");
  const [state, setState] = useState({
    open: false,
    Transition: SlideTransition,
  });

  // 토스트 핸들러
  const showSnack = (message, type = "success") => {
    setSnackMessage(message);
    setSnackColor(type);
    setState({ open: true, Transition: SlideTransition });
  };

  const handleSnackClose = () => {
    setState({ ...state, open: false });
  };

  return (
    <ToastContext.Provider value={{ showSnack }}>
      {children}
      <Snackbar
        open={state.open}
        autoHideDuration={3000}
        onClose={handleSnackClose}
        anchorOrigin={{ vertical: "top", horizontal: "right" }}
        slots={{ transition: state.Transition }}
      >
        <Alert onClose={handleSnackClose} severity={snackColor}>
          {snackMessage}
        </Alert>
      </Snackbar>
    </ToastContext.Provider>
  );
}

export const useToast = () => useContext(ToastContext);

createContext 함수를 사용하여 Toastcontext 라는 새로운 Context를 생성했다.

ToastProvider 컴포넌트는 토스트 메세지 상태를 관리하고, showSnack 함수를 Context 값으로 제공한다. 또한 실제 Snackbar 컴포넌트를 렌더링한다.

useToast 라는 커스텀 훅을 만들어서 어디서든 쉽게 Context 값을 가져올 수 있게 하였다.

<body className={`${notoSans.variable} antialiased max-w-[1920px] w-full`}>
    <ClientProvider>
        <ToastProvider>{children}</ToastProvider>
    </ClientProvider>
</body>

다음은 layout 에 Provider 를 적용시켜줬다.

실제 적용

다음은 토스트 메세지를 사용한 사례이다.

import { useToast } from "/ToastContext"

export default function Page() {
  const { showSnack } = useToast();

  const handleCopy = async () => {
    // copy 로직 실행

    try {
      ...
    } catch (error) {
      console.error("Failed to copy: ", error)
      showSnack("클립보드 복사에 실패했습니다.", "error")
    } finally {
      showSnack("복사 완료", "success");
    }
 };

 return (
   {/* 컴포넌트 */}
   <button onClick={handleCopy}> 복사하기 </button>
   );
}

이렇게 하면 각 컴포넌트에서 반복적으로 토스트 관련 코드를 작성할 필요가 없다. useToast 훅을 사용하면 어디서든 쉽게 토스트 메세지를 표시할 수 있다.

기존 코드와 비교했을 때 useToast() 한번이면 끝나니깐 굉장히 편리하고 보기에도 좋아졌다.

Context API vs Jotai 간단하게

Context API 가 적합한 경우:

• 간단한 전역 상태를 관리할 때

• 추가 라이브러리 의존성을 피하고 싶을 때

• UI 테마, 사용자 인증 등 자주 변경되지 않는 상태

• 토스트 메세지처럼 중앙에서 관리되는 UI 상태

Jotai 가 적합한 경우:

• 복잡한 상태 로직이 필요할 때

• 성능 최적화가 중요할 때

• 여러 작은 상태들이 독립적으로 변경될 때

• 상태 간 파생 관계가 많을 때

내가 쓴 토스트 메세지 같은 간단한 UI 상태 관리는 Context API 로도 충분하다. 하지만 애플리케이션이 성장하고 상태 관리가 복잡해진다면 Jotai 같은 라이브러리를 고려해볼 수 있다.

마치며

React Context 와 Provider 패턴을 사용하면 토스트 메세지와 같은 글로벌 상태를 효율적으로 관리할 수 있다. 이 패턴은 다음과 같은 이점을 있다:

1. 코드 중복을 줄일 수 있다.

2. 컴포넌트 간 props 전달을 최소화할 수 있다.

3. 관심사를 분리하여 코드 구조를 개선할 수 있다.

4. 유지보수가 더 쉬워진다.

이 패턴은 토스트 메시지뿐만 아니라 테마, 사용자 인증, 언어 설정 등 애플리케이션 전체에서 공유해야 하는 상태를 관리하는 데도 유용하게 활용할 수 있다.

더 복잡한 상태 관리가 필요할 경우 Jotai, Recoil, Zustand 같은 라이브러리를 검토해볼 수 있지만, 간단한 사용 사례에는 React의 기본 기능만으로도 충분하다.

React Context API나 적절한 상태 관리 라이브러리를 활용하면 더 깔끔하고 유지보수하기 쉬운 코드를 작성할 수 있다. 프로젝트의 복잡성과 요구사항에 맞게 적절한 도구를 선택하는 것이 중요하다.

게임 데이터 조회 API 를 개발하면서 성능 이슈를 겪고 있었다. 사용자 정보와 최근 경기 기록을 불러오는 과정이 생각보다 오려 걸려서 화면 로딩이 느려지는 문제가 있었다. 특히 MongoDB 쿼리를 여러 번 순차적으로 실행하면서 시간이 많이 소요되었다.

해결과정

처음 해결해보려고 했던 방법

일단 tanstack query 에서 placeholder data 를 제공해준다.

const {
    data: userDetail = [],
    isLoading,
    isError,
    error,
  } = useQuery({
    queryKey: ["userDetail", player?.name],
    queryFn: () => fetchPlayerDetail(player?._id),
    enabled: !!player?._id,
    refetchOnWindowFocus: false,
    refetchOnReconnect: false,
    staleTime: 1000 * 60 * 5,
    placeholderData: keepPreviousData,
  });

이처럼 placeholderData 를 쓰면 새 데이터가 로딩되기 전까지 "잠깐 대체용"으로 이전 데이터를 보여주는 역할을 한다. 그래서 로딩 상태를 안 보이게 할 수 있다.

이러면서 UX 를 개선할 수 있지만 단순 눈속임일 뿐이라 생각했다. 실질적으로 데이터 통신을 더 빠르게 할 수 있는 방법이 없나 검색해보다가 Promise 를 써서 병렬 처리를 하면 좀 더 빠르게 데이터 통신을 할 수 있다고 알았다.

기존 방식: 순차적 데이터 로딩

처음에는 아래와 같이 순차적으로 데이터를 불러오는 방식을 사용했다.

1. 사용자 기본 정보 조회

2. 가장 많이 플레이한 챔피언 조회

3. 최근 5경기 데이터 조회

4. 최근 5경기 승률 데이터 조회

// 유저 기본 정보 조회
const user = await User.findById(id)
  .select("name nickName position eloRating")
  .lean();

// 유저의 가장 많이 플레이한 챔피언
const mostPlayedChampion = await Match.aggregate([
  // 집계 파이프라인...
]);

// 유저의 최근 5경기
const recentMatches = await Match.find({
  "players.userNickname": user.nickName,
})
  .sort({ createdAt: -1 })
  .limit(5);

// 유저의 최근 5경기의 승률
const recentMatchesData = await Match.aggregate([
  // 집계 파이프라인...
]);

이렇게 순차적으로 데이터를 불러오면 한 쿼리가 완료된 후 다음 쿼리가 실행되어 전체 처리 시간이 길어졌다.

성능 측정

순차적 처리 방식의 성능을 측정하기 위해 console.time 과 console.timeEnd 를 사용했다.

console.time("순차적");
// 모든 순차적 쿼리 실행
console.time("순차적");

10번의 테스트 결과, 순차적 처리 방식은 평균적으로 다음과 같은 시간이 소요되었다.

• 208ms, 180ms, 205ms, 204ms, 210ms, 219ms, 208ms, 204ms, 209ms, 209ms
• 평균: 205.6ms

개선 방식: Promise.all 을 활용한 병렬 처리

성능 개선을 위해 Promise.all 을 사용하여 여러 쿼리를 병렬로 실행하는 방식으로 변경했다.

// 유저 정보는 먼저 따로 불러와야 함
const user = await User.findById(id)
  .select("name nickName position eloRating")
  .lean();

// 닉네임을 기준으로 다른 쿼리를 병렬 처리
const [mostPlayedChampionAgg, recentMatches, recentMatchesDataAgg] = 
  await Promise.all([
    Match.aggregate([/* 첫 번째 쿼리 */]),
    Match.find({ /* 두 번째 쿼리 */ }),
    Match.aggregate([/* 세 번째 쿼리 */])
  ]);

병렬 처리 방식의 성능을 동일하게 측정했다.

console.time("병렬")
// 병렬 쿼리 실행
console.timeEnd("병렬");

10번의 테스트 결과, 병렬 처리 방식은 다음과 같은 시간이 소요되었다.

• 127ms, 86ms, 130ms, 127ms, 124ms, 126ms, 124ms, 127ms, 108ms, 126ms
• 평균: 120.5ms

성능 비교 결과

두 방식의 성능을 비교한 결과:

• 순차적 처리: 평균 205.6ms
• 병렬 처리: 평균 120.5ms
• 개선율: 약 41.4% 향상

개선 원리: Promise.all 의 활용

Promise.all 메서드는 여러 프로미스를 병렬로 실행하고 모든 프로미스가 완료되었을 때 결과를 반환한다. 이를 활용하면 서로 의존성이 없는 여렁 데이터베이스 쿼리를 동시에 실행할 수 있다.

주의할 점은 병렬 처리를 하려면 쿼리 간의 의존성을 파악해야 한다는 것이다. 내 경우에는 유저 기본 정보(특히 닉네임)가 다른 쿼리에 필요했기 때문에 유저 정보만 먼저 조회한 후, 나머지 세 가지 쿼리를 병렬로 처리했다.

// 1. 유저 정보 먼저 조회 (다른 쿼리들이 이 정보에 의존)
const user = await User.findById(id).lean();

// 2. 나머지 쿼리들은 병렬로 처리
const [query1Result, query2Result, query3Result] = await Promise.all([
  // 여러 쿼리 동시 실행
]);

결론

Promise.all을 활용한 병렬 처리는 API 성능을 크게 향상시킬 수 있는 간단하면서도 효과적인 방법이다. 내 프로젝트에서는 약 41%의 성능 향상을 달성했고, 이는 사용자 경험 개선으로 이어졌다.

특히 여러 개의 독립적인 데이터베이스 쿼리가 필요한 경우, 순차적 처리 대신 병렬 처리를 고려해보는 것이 좋다. 다만 쿼리 간의 의존성을 파악하여 필요한 경우 일부 쿼리는 순차적으로 실행해야 한다는 점을 명심해야 한다.

남아있는 문제점

기존 해결책(Next.js Image 컴포넌트 활용)으로 깜빡임 현상은 많이 개선되었지만, 다음과 같은 문제가 여전히 존재했다:

1. 콘텐츠와 배경 이미지 사이에 약간의 로딩 시간 차이가 발생

2. 이미지 전환 시 완벽한 동기화가 이루어지지 않음

새로운 접근법: Swiper로 배경 이미지 처리하기

기존에는 콘텐츠만 Swiper로 관리하고 배경 이미지는 단일 Image 컴포넌트로 처리했다. 이를 개선하기 위해 배경 이미지도 Swiper를 사용하여 관리하는 방식을 도입했다.

배경 이미지용 Swiper 구현

{/* 배경 이미지 Swiper */}
<Swiper
  modules={[Autoplay, EffectFade]}
  effect="fade"
  autoplay={{ delay: 3000, disableOnInteraction: false }}
  loop
  speed={1000}
  slidesPerView={1}
  onSlideChange={(swiper) => setActiveIndex(swiper.realIndex)}
  allowTouchMove={false}
  onSwiper={(swiper) => (bgSwiperRef.current = swiper)}
  className="absolute inset-0 opacity-70 z-0 rounded-2xl"
>
  {shiftedChampions.map((champion, idx) => {
    return (
      <SwiperSlide key={idx}>
        <div className="relative w-full h-[37.5rem]">
          <Image
            src={champion.logo}
            alt={champion.name}
            fill
            priority
            className="object-cover"
          />
        </div>
      </SwiperSlide>
    );
  })}
</Swiper>

콘텐츠용 Swiper 구현

{/* Swiper 콘텐츠 */}
<div className="absolute inset-0 z-10 py-10 px-5">
  <Swiper
    modules={[Navigation, Autoplay]}
    navigation={{
      nextEl: ".swiper-custom-next",
      prevEl: ".swiper-custom-prev",
    }}
    spaceBetween={30}
    slidesPerView={4}
    loop={true}
    autoplay={{ delay: 3000, disableOnInteraction: false }}
    onSlideChange={(swiper) => setActiveIndex(swiper.realIndex)}
    speed={1000}
    allowTouchMove={false}
    onSwiper={(swiper) => (contentSwiperRef.current = swiper)}
    className="w-full h-full z-10"
  >
    {/* 슬라이드 콘텐츠 */}
  </Swiper>
</div>

두 Swiper 동기화하기

두 Swiper 간의 완벽한 동기화를 위해 참조 객체(useRef)를 활용했다.

// 스와이퍼 참조 객체
const contentSwiperRef = useRef(null);
const bgSwiperRef = useRef(null);

// 버튼 동기화
const handleNext = () => {
  contentSwiperRef.current?.slideNext();
  bgSwiperRef.current?.slideNext();
};

const handlePrev = () => {
  contentSwiperRef.current?.slidePrev();
  bgSwiperRef.current?.slidePrev();
};

이 코드를 통해 네비게이션 버튼을 클릭할 때 콘텐츠와 배경 이미지가 동시에 전환되도록 처리했다.

주요 개선 사항

1. EffectFade 모듈 활용 배경 이미지 Swiper에 effect="fade" 옵션을 적용하여 부드러운 전환 효과를 구현했다. 이를 위해 Swiper의 EffectFade 모듈을 import 했다.

2. 동일한 전환 속도 설정 두 Swiper 모두 speed={1000}으로 설정하여 전환 속도를 동일하게 맞췄다. 이를 통해 시각적으로 더 자연스러운 전환이 가능해졌다.

3. 사용자 조작 방지 allowTouchMove={false} 옵션을 통해 사용자가 직접 슬라이드를 조작하는 것을 방지하고, 네비게이션 버튼을 통해서만 슬라이드를 전환할 수 있도록 했다.

4. 이미지 최적화 유지 배경 이미지에도 여전히 Next.js의 Image 컴포넌트를 사용하고 priority 속성을 적용하여 로딩 최적화의 이점을 유지했다.

결과 및 성능 향상

이 개선된 방식을 적용한 결과:

1. 배경 이미지와 콘텐츠 간의 로딩 시간 차이가 사라졌다.

2. 이미지 전환 시 깜빡임이 완전히 제거되었다.

3. fade 효과로 인해 시각적으로 더 부드러운 전환이 가능해졌다.

4. 네비게이션 버튼을 통한 조작 시 두 요소가 완벽하게 동기화되었다.

결론

Next.js의 Image 컴포넌트와 Swiper를 함께 활용하면 이미지 로딩과 전환 시 발생하는 문제를 효과적으로 해결할 수 있다. 특히 배경 이미지와 콘텐츠를 각각 별도의 Swiper로 관리하고 동기화하는 방식은 사용자 경험을 크게 향상시키는 효과적인 방법이다.

이미지가 많이 사용되는 현대 웹 애플리케이션에서 이러한 최적화는 사용자 만족도를 높이고 웹사이트의 품질을 향상시키는 중요한 요소가 된다.

웹 애플리케이션을 개발하다 보면 이미지 로딩과 관련된 문제에 종종 직면하게 된다. 특히 슬라이드 형태로 이미지가 전환될 때 아래와 같은 깜빡임 현상이 발생했다.

이런 깜빡임은 사용자 경험을 저해하는 요소로, 웹사이트의 품질을 떨어뜨리는 원인이 된다.

기존 코드 분석

{/* 배경 이미지 */}
      <div
        className="absolute inset-0 bg-black z-0 transition-all
        duration-300 rounded-xl"
        style={{
          backgroundImage: `url(${background})`,
          backgroundSize: "cover",
          backgroundPosition: "center",
          opacity: 0.5,
        }}
      />

{/* 배경 이미지 preloading */}
      <div className="hidden">
        {champions.map((champion, idx) => (
          <Image
            key={idx}
            src={champion.logo}
            alt=""
            width={1}
            height={1}
            priority
          />
        ))}
      </div>

이 코드에서 발견된 문제점:

1. 배경 이미지는 일반 div의 style 속성으로 처리되어 최적화가 부족했다.
2. 이미지 preloading을 위해 hidden div 안에 모든 이미지를 넣어두었지만 효율적이지 않았다.
3. width와 height가 1로 설정되어 실제 이미지 크기와 맞지 않았다.

해결 방법

Next.js의 Image 컴포넌트를 제대로 활용하여 문제를 해결했다.

{/* 배경 이미지 */}
      <Image
        src={background}
        alt="배경 이미지"
        fill
        className="object-cover z-0 rounded-xl opacity-50 
        transition-opacity duration-300"
        priority
      />

해결 후에는 깜빡임이 사라진 것을 확인할 수 있다.

핵심 개선 사항

1. Next.js Image 컴포넌트 활용

• 기존 div + backgroundImage 방식 대신 Next.js의 최적화된 Image 컴포넌트 사용
  

2. fill 속성 적용

• 부모 요소의 크기에 맞게 이미지가 채워지도록 설정
  

3. priority 속성 활용

• LCP(Largest Contentful Paint) 요소로 인식하여 더 높은 우선순위로 로딩
  

4. transition-opacity 적용

• 이미지 전환 시 부드러운 효과 제공

결론

Next.js의 Image 컴포넌트를 적절히 활용하면 이미지 로딩 시 발생하는 깜빡임 현상을 효과적으로 해결할 수 있다. 특히 priority 속성과 fill 속성을 함께 사용하면 사용자 경험을 크게 향상시킬 수 있다. 이미지가 많은 웹 애플리케이션에서는 로딩 최적화가 매우 중요하므로, Next.js가 제공하는 이미지 최적화 기능을 적극적으로 활용하는 것이 좋다.

CastError: Cast to ObjectId failed for value "reset-today" (type string) at path "_id" for model "user" at SchemaObjectId.cast

GPT에 물어본 결과 이 에러는 Mongoose가 reset-today 라는 문자열을 MongoDB의 _id 필드로 해석하려고 시도하는 과정에서 발생한 것이다. MongoDB에서 _id 필드는 기본적으로 ObjectId 타입이어야 하지만, 지금 전달된 값이 문자열 "reset-today" 여서 문제가 발생한 것이다.

따라서 해결 방법으로는

1. 라우팅 경로를 명확하게 고정 경로로 설정
2. 경로 우선 순위 확인

이 두 가지 방법을 추천하였다. 첫 번째 방법은 경로를 확실히 해줬으므로 문제가 되지않았다. 따라서, 두 번째 방법으로 해결을 하였다. 고정된 경로들을 동적 경로들보다 먼저 선언하도록 라우팅 파일을 수정해줬다.

// 고정된 경로
router.put("/reset-today", userController.resetUserTeam);

// 동적 경로
router.put("/:id", userController.updateUser);

이렇게 하니 잘 작동을 하였다. 하지만, 왜 이렇게 해야 작동이 되는지 궁금해서 좀 더 찾아보았다.

1. 고정 경로와 동적 경로의 차이

고정 경로

고정 경로는 특정 URL에 대해서만 매칭된다. 예를 들어, 다음과 같은 경로는 URL이 정확히 /reset-today 일 때만 매칭된다.

router.put("/reset-today", (req, res) => {
  res.send("Resetting today's data");
});

이 경로는 URL이 정확하게 /reset-today일 때만 실행된다. 다른 URL이 들어오면 이 경로는 매칭되지 않는다.

동적 경로

동적 경로는 경로에 들어오는 다양한 값들을 변수로 처리할 수 있다. 예를 들어, /:id 는 다양한 값이 들어올 수 있는 유연한 경로이다.

router.put("/:id", (req, res) => {
  res.send(`Updating user with ID: ${req.params.id}`);
});

이 경로는 /user/123 같은 경로에서 123 을 id 로 받아 처리하는 등 유연하게 동작한다.

2. 왜 고정 경로를 먼저 선언해야 할까?

Express는 라우터를 위에서 아래로 순차적으로 검사합니다. 즉, 요청이 들어왔을 때 가장 먼저 일치하는 경로가 실행됩니다. 고정 경로와 동적 경로가 함께 있을 때 고정 경로가 먼저 선언되지 않으면, 동적 경로가 고정 경로보다 먼저 매칭될 수 있습니다.

예시: 잘못된 선언 순서

// 동적 경로가 먼저 선언된 경우
router.put("/:id", (req, res) => {
  res.send(`Updating user with ID: ${req.params.id}`);
});

router.put("/reset-today", (req, res) => {
  res.send("Resetting today's data");
});

이 경우, 만약 클라이언트가 /reset-today 로 요청을 보낸다면 Express는 첫 번째로 선언된 /:id 경로와 먼저 매칭된다. 따라서 "reset-today" 라는 문자열이 id 로 해석되어, 예상치 못한 동작이 발생하게 된다.

만약 이 id 값이 MongoDB의 _id 와 같이 특정 형식(예: ObjectId )으로 사용된다면, 다음과 같은 오류가 발생할 수 있다.

CastError: Cast to ObjectId failed for value "reset-today" at path "_id"

이 오류는 MongoDB가 reset-today 라는 문자열을 ObjectId 로 변환하려고 시도했지만 실패했기 때문에 발생한다.

해결책: 고정 경로를 먼저 선언

이 문제를 해결하려면 고정 경로를 먼저 선언하여 동적 경로가 이를 덮어쓰지 않도록 해야 한다.

// 고정 경로를 먼저 선언
router.put("/reset-today", (req, res) => {
  res.send("Resetting today's data");
});

// 동적 경로는 그 이후에 선언
router.put("/:id", (req, res) => {
  res.send(`Updating user with ID: ${req.params.id}`);
});

이제 /reset-today 로 요청이 들어오면 먼저 고정된 경로가 처리되고, 이후에 동적 경로가 처리된다. 이 방식으로 동적 경로가 고정된 경로와 충돌하는 문제를 방지할 수 있다.

3. 결론

Express에서는 고정 경로와 동적 경로를 선언할 때, 고정 경로를 먼저 선언해야 한다. 그렇지 않으면 동적 경로가 고정된 경로와 일치하여 잘못된 값이 변수로 처리되거나, 예상치 못한 에러가 발생할 수 있다.

다음과 같은 규칙을 기억:

• 고정 경로는 특정 URL에만 매칭되므로 최우선으로 처리해야 한다.
• 동적 경로는 유연하게 다양한 값들을 처리할 수 있지만, 고정 경로를 덮어쓰지 않도록 주의해야 한다.

Express의 라우팅 순서를 잘 이해하고 사용하면, 이런 문제를 피하고 애플리케이션이 의도한 대로 작동하도록 만들 수 있다.

일단 이 에러는 jsonwebtoken 라이브러리를 사용하여 토큰을 생성하거나 검증할 때 발생하는 오류이다. 찾아보니깐 이 에러는 주로 jwt.sign() 또는 jwt.verify() 함수에 비어 있거나 undefined인 secretOrPrivateKey 값을 전달했을 때 발생한다고 나온다.

require('dotenv').config();
const jwt = require('jsonwebtoken');
const JWT_SECRET_KEY = process.env.JWT_SECRET_KEY;

UserSchema.methods.generateToken = function() {
  const token = jwt.sign({ _id: this.id }, JWT_SECRET_TOKEN);
  return token;
}

이런 식으로 토큰을 반환해줬지만 막상 로그인에서 에러가 뜨는것이다. 분명 나는 .env 에 JWT_SECRET_KEY 도 정의해줬고 dotenv를 통해 process.env 를 node 상에서 사용할 수 있게 해줬는데 인식을 못하는 것이었다.

해결방법을 계속 찾아보는데 스택플로우에서 백틱을 써보라고 하였다.

그래서 다음과 같이 코드를 고쳤다.

const JWT_SECRET_KEY = `${process.env.JWT_SECRET_KEY}`;

이랬더니 에러가 뜨지 않고 정상작동을 하는것을 확인하였다. 백틱을 쓰는것과 안쓴것의 차이를 모르겠다. gpt에 물어본 결과, 백틱을 감싸면 undefined 일지라도 템플릿 리터럴로 문자열로 처리되기 때문에 에러가 발생하지 않는다고 한다.

하지만, api 호출하는데 있어서 undefined가 되면 로그인 에러가 떠야 함에도 불구하고 잘 작동되는것을 보면 원래는 api 주소가 맞았다는 뜻일텐데 애매한 부분만 남고 해결이 되어버렸다.

ref: https://stackoverflow.com/questions/58673430/error-secretorprivatekey-must-have-a-value

데이터베이스 연결 설정

이전 글에서 MongoDB를 연결하는 방법을 알아보았다. 그 중, Mongoose를 통한 DB 연결을 할 것이다.

Next.js 에서 MongoDB 연결 방법

// app/lib/utils.js

import mongoose from 'mongoose';

const connection = {};

export const connectToDb = async () => {
  try {
    if (connection.isConnected) {
      console.log('Using existing connection');
      return;
    }
    const db = await mongoose.connect(process.env.MONGO);
    connection.isConnected = db.connections[0].readyState;
  } catch (error) {
    console.log(error);
    throw new Error(error);
  }
};

API 정의

이제 Next.js의 API Routes 기능을 사용하여 블로그 포스트를 가져오는 API를 정의한다. 이를 위해 app/api/blog/[slug]/route.js 파일을 생성하고, 특정 슬러그(slug)에 해당하는 포스트를 데이터베이스에서 가져오는 GET 핸들러를 작성한다.

// app/api/blog/[slug]/route.js

import { Post } from '@/lib/models';
import { connectToDb } from '@/lib/utils';
import { NextResponse } from 'next/server';

export const GET = async (request, { params }) => {
  const { slug } = params;
  try {
    await connectToDb();

    const post = await Post.findOne({ slug });
    return NextResponse.json(post);
  } catch (err) {
    console.log(err);
    throw new Error('Failed to fetch post!');
  }
};

API 사용

API를 정의한 후, 클라이언트 측에서 이 API를 호출하여 데이터를 가져오는 방법을 살펴보겠다. 이를 위해 app/blog/[slug]/page.jsx 파일을 생성하고, 해당 파일에서 특정 슬러그에 대한 블로그 포스트 데이터를 가져와 렌더링한다.

// app/blog/[slug]/page.jsx

const getData = async (slug) => {
  const res = await fetch(`http://localhost:3000/api/blog/${slug}`);

  if (!res.ok) {
    throw new Error('Something went wrong!');
  }

  return res.json();
};

export default async function SinglePost({ params }) {
  const { slug } = params;
  const post = await getData(slug);

  return (
    <div>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </div>
  );
}

전체 코드 구조

이번 예제에서 사용한 전체 코드 구조는 다음과 같다.

/app
  /api
    /blog
      [slug]
        route.js
  /blog
    [slug]
      page.jsx


/lib
  utils.js
  models.js

결론

이번 글에서는 Next.js를 사용하여 RESTful API를 정의하고, 이를 클라이언트에서 호출하여 데이터를 가져오는 방법을 블로그 포스트 예제를 통해 알아보았다. Next.js의 파일 기반 라우팅 시스템을 활용하면 API 엔드포인트와 페이지 컴포넌트를 효율적으로 관리할 수 있다.

async function testAPI() {
  try {
    const response = await fetch("http://localhost:3000/api/movies", {
      method: "GET",
      headers: {
        'Content-Type': 'application/json',
      },
    });

    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }

    const result = await response.json();
    return result;
  } catch (error) {
    console.error('Error fetching API:', error);
    return [];
  }
}

MongoDB 에 Data fetching

MongoDB에 데이터를 패칭하는 법

// lib/fetchAndInsert.ts
import fetch from 'node-fetch';
import clientPromise from './mongodb';

async function fetchExternalData(apiUrl: string) {
  const response = await fetch(apiUrl);
  if (!response.ok) {
    throw new Error(`Failed to fetch data from ${apiUrl}: ${response.statusText}`)
  }

  const data = await response.json();
  return data;
}

async function insertDataToMongoDB(data: any) {
  const client = await clientPromise;
  const db = client.db('sample_mflix');
  const collection = db.collection('nomad');

  const result = await collection.insertMany(data);
  return result;
}

async function fetchDataAndInsertToMongoDB(apiUrl: string) {
  try {
    const data = await fetchExternalData(apiUrl);
    console.log('Data fetched from API: ', data);

    const result = await insertDataToMongoDB(data);
    console.log('Data inserted to MongoDB: ', result);
  } catch (error) {
    console.error("Error fetching data and inserting to MongoDB: ", error);
  }
}

export default fetchDataAndInsertToMongoDB;

// app/api/fetch-and-insert/route.ts
import { NextRequest, NextResoponse } from "next/server";
import clientPromise from '../../../lib/mongodb';

export async function GET (request: NextRequest) {
  const apiUrl = process.env.NEXT_PUBLIC_API_URL;
  try {
    await fetchDataAndInsertToMongoDB(apiUrl);
    return NextResponse.json({ message: "데이터 패치 및 삽입 완료" });
  } catch(error) {
    return NextResponse.json({ message: "데이터 패치 및 삽입 실패", error: error.message });
  }
}

// app/(home)/page.tsx
async function testAPI() {
  try {
    const response = await fetch("http://localhost:3000/api/fetch-and-insert", {
      method: "GET",
      headers: {
        'Content-Type': 'application/json',
      },
    });

    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }

    const result = await response.json();
    return result;
  } catch (error) {
    console.error("Error fetching API: ", error);
    return [];
  }
}

데이터 패칭하는 법(캐싱)

const getData = async() => {
  const response = await fetch("https://jsonplaceholder.typicode.com/posts");

  if (!response.ok) {
    throw new Error("Something went wrong!");
  }

  return response.json();
}

데이터 캐싱 하지않는 법

const getData = async() => {
  const response = await fetch("https://jsonplaceholder.typicode.com/posts", {
    cache: 'no-cache'});

  if (!response.ok) {
    throw new Error("Something went wrong!");
  }

  return response.json();
}

데이터 캐싱 유효기간 설정

const getData = async() => {
  const response = await fetch("https://jsonplaceholder.typicode.com/posts", {
    next: { revalidate: 3600 });

  if (!response.ok) {
    throw new Error("Something went wrong!");
  }

  return response.json();
}

• Next.js 의 SSR과 CSR을 효과적으로 관리하는 방법에 대해 설명한다.
• dynamic , useEffect , suppressHydrationWarning 의 차이점과 각각의 사용 상황을 다룬다.

1. dynamic을 사용하여 동적 컴포넌트 로딩

[ 설명 ]

• dynamic 함수는 클라이언트 전용 컴포넌트를 동적으로 로드할 수 있게 해준다.
• SSR을 비활성화하여 초기 로딩 시간을 단축하고, 특정 컴포넌트를 필요할 때 로드한다.

[ 사용 예시 ]

import dynamic from 'next/dynamic';

const HydrationTestNoSSR = dynamic(() => import('@/components/hydrationTest'), 
                                   {ssr: false});

const Page = () => {
  <div>
      <h1>My Page</h1>
      <HydrationTestNoSSR />
  </div>
}

export default Page;

[ 언제 사용하면 좋은가? ]

• 클라이언트 전용 컴포넌트를 로드할 때
• 초기 로딩 성능을 최적화할 때
• 브라우저 API를 사용하는 컴포넌트를 다룰 때

2. useEffect를 사용하여 클라이언트 사이드 로직 실행

[ 설명 ]

• useEffect 훅은 컴포넌트가 마운트된 후 클라이언트 사이드에서 실행된다.
• 서버와 클라이언트 간의 상태를 동기화하거나 클라이언트에서 특정 로직을 실행하는 데 유용하다.

[ 사용 예시 ]

import { useState, useEffect } from 'react';

const TimeComponent = () => {
  const [time, setTime] = useState('');

  useEffect(() => {
    setTime(new Date().toLocalTimeString());
  }, []);

  return (
    <div>
        The Current time is: {time}
    </div>
    );
};

export default TimeComponent;

[ 언제 사용하면 좋은가? ]

• 클라이언트에서 실행되어야 하는 로직이 있을 때
• 데이터 패칭, DOM 조작, 이벤트 리스너 설정 등 클라이언트 전용 작업

3. suppressHydrationWarning 으로 경고 억제

[ 설명 ]

• 서버와 클라이언트 간의 HTML 불일치로 인해 발생하는 경고를 억제한다.
• 주로 클라이언트에서만 동적으로 업데이트되는 컴포넌트에서 사용된다.

[ 사용 예시 ]

import { useState, useEffect } from 'react';

const TimeComponent = () => {
  const [time, setTime] = useState('');

  useEffect(() => {
    setTime(new Date().toLocalTimeString());
  }, []);

  return (
    <div suppressHydrationWarning>
        The Current time is: {time}
    </div>
    );
};

export default TimeComponent;

[ 언제 사용하면 좋은가? ]

• 서버와 클라이언트 간의 타이밍 차이로 인해 HTML 불일치가 발생할 때
• 클라이언트에서만 동적으로 변하는 데이터를 다룰 때

결론

Next.js 에서 서버와 클라이언트 간의 동기화는 중요한 과제이다.

dynamic 은 동적 컴포넌트 로딩과 초기 로딩 성능 최적화에 유용하며, useEffect 는 클라이언트 사이드 로직 실행에 필수적이다. suppressHydrationWarning 은 불필요한 경고를 억제하여 클라이언트에서만 동적으로 변하는 데이터를 처리할 때 유용하다.

각 방법의 적절한 사용을 통해 더 나은 사용자 경험을 제공할 수 있다.

CSR (Client-Side Rendering)

• 사용자가 http://lama.dev/about 페이지를 요청한다.
• 서버는 빈 index.html 파일을 클라이언트에게 보낸다.
• 클라이언트는 받은 index.html 파일을 통해 JavaScript 파일을 로드한다.
• JavaScript가 실행되어 클라이언트 측에서 페이지가 렌더링된다.

[ 궁금점 ]

클라이언트가 받은 빈 index.html 파일을 통해 JavaScript 파일을 로드한다는게 정확히 무슨 뜻인지 이해가 안갔다. 그래서 다음과 같이 질문을 하였다.

CSR 에서 클라이언트가 받은 빈 index.html 을 통해서 어떻게 JavaScript 파일을 로드하는가? html에 JavaScript 파일이 있나?

네, 정확히 맞습니다. CSR(Client-Side Rendering)에서는 서버가 빈 index.html 파일을 클라이언트에 보내지만, 이 HTML 파일에는 필요한 JavaScript 파일을 로드하는 스크립트 태그가 포함되어 있습니다. 이 스크립트 태그를 통해 클라이언트가 JavaScript 파일을 로드하고, 그 후에 해당 JavaScript 파일이 실행되어 페이지를 렌더링하게 됩니다.

CSR의 경우, 기본적인 흐름은 다음과 같습니다:

• 사용자가 특정 URL(http://lama.dev/about)을 요청합니다.
• 서버는 빈 index.html 파일을 클라이언트에게 보냅니다. 이 파일에는 필요한 JavaScript 파일을 로드하는 스크립트 태그가 포함되어 있습니다.
• 클라이언트는 받은 index.html 파일을 파싱하여, <script> 태그를 통해 JavaScript 파일을 로드합니다.
• 로드된 JavaScript 파일이 실행되면서, 클라이언트 측에서 페이지의 콘텐츠를 생성하고 렌더링합니다.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>My App</title>
</head>
<body>
  <div id="root"></div>
  <script src="/static/js/main.js"></script>
</body>
</html>

이 경우, main.js 파일이 로드되고 실행되면서, React 또는 다른 JavaScript 프레임워크가 #root 요소 안에 필요한 콘텐츠를 생성하게 됩니다.

CSR의 장점을 클라이언트 측에서 빠르게 인터렉티브한 페이지를 만들 수 있다는 것이며, 단점은 초기 로딩 속도가 SSR 보다 느릴 수 있고, SEO에 불리할 수 있다는 점입니다. 하지만 Next.js 와 같은 프레임워크를 사용하면 CSR과 SSR을 혼합하여 사용할 수 있기 때문에, 이러한 단점을 보완할 수 있습니다.

SSR (Server-Side Rendering)

• 사용자가 http://lama.dev/about 페이지를 요청한다.
• 서버는 요청을 처리하여 완성된 about.html 파일을 클라이언트에게 보낸다.
• 클라이언트는 받은 about.html 파일을 그대로 렌더링하여 사용자에게 보여준다.
• 추가적인 인터렉티브 기능을 위해 JavaScript 파일이 로드된다.

[ 주요 차이점 ]

• CSR 초기 로딩 시 서버에서 빈 HTML 파일을 보내고, 클라이언트 측에서 JavaScript를 통해 콘텐츠를 렌더링한다. 따라서 초기 로딩 시간이 다소 길 수 있으며, 검색 엔진 최적화(SEO)에 불리할 수 있다.

• SSR 서버에서 완성된 HTML 파일을 보내므로 초기 로딩 시간이 빠르고, SEO에 유리하다. 클라이언트 측에서도 JavaScript를 통해 추가적인 인터렉티브 기능을 제공할 수 있다.

출처

!youtube[vCOSTG10Y4o]

```js /** @type {import('next').NextConfig} */ const nextConfig = { images: { remotePatterns: [ { protocol: 'https', hostname: 'www.example.com', } ] } }

module.exports = nextConfig

usePathName

usePathName 훅은 현재 URL의 경로(pathname)를 반환한다. 쿼리 파라미터를 포함하지 않고 오직 경로만 나타내기 때문에 URL의 구조를 확인할 때 유용하다.

// app/navigationTest/page.jsx

'use client';
import { usePathName } from "next/navigation";

const Navigation = () => {
  const pathname = usePathName();

  console.log(pathname); // 현재 경로 출력

  return (
    <div>
      localhost:3000/navigationTest
    </div>
  )
}

export default Navigation;

콘솔창 결과 /navigationTest

위 예제에서 usePathName 을 사용하여 현재 경로를 가져와 콘솔에 출력한다.

useRouter

useRouter 훅은 라우터 인스턴스를 반환하여 네비게이션을 프로그래밍 방식으로 제어할 수 있다. 페이지 이동, 페이지 새로고침, 뒤로가기, 앞으로가기 등의 작업을 수행할 수 있다.

'use client';
import { useRouter } from "next/navigation";

const Navigation = () => {
  const router = useRouter();

  const handleClick = () => {
    console.log("clicked");
    router.push('/'); // 지정된 URL로 이동
    // router.replace('/'); // 히스토리를 남기지 않고 이동
    // router.refresh(); // 현재 페이지 새로고침
    // router.back(); // 이전 페이지로 이동
    // router.forward(); // 다음 페이지로 이동
  }

  return (
    <div>
      <button onClick={handleClick}>Write and Redirect</button>
    </div>
  )
}

export default Navigation;

이 예제에서는 버튼 클릭 시 router.push('/') 를 호출하여 루트 페이지로 이동한다. useRouter 훅을 사용하여 다양한 네비게이션 동작을 제어할 수 있다.

useSearchParams

useSearchParams 훅은 URL의 쿼리 파라미터를 읽고 설정하는 데 사용된다. 쿼리 파라미터를 가져오거나 변경할 때 유용하다.

'use client';
import { useSearchParams } from "next/navigation";

const Navigation = () => {
  const searchParams = useSearchParams();

  const q = searchParams.get("q");
  console.log(q); // 'q' 파라미터 값 출력

  return (
    <div>
      localhost:3000/navigationTest
    </div>
  )
}

export default Navigation;

localhost:3000/navigationTest?q=test URL에서 q 파라미터의 값을 가져와 콘솔에 출력한다.

test

[ 쿼리 파라미터 설정 예시 ]

set 메서드를 사용하여 쿼리 파라미터를 설정하는 방법도 살펴보겠다.

'use client';
import { useSearchParams } from "next/navigation";

const Navigation = () => {
  const searchParams = useSearchParams();

  const q = searchParams.get('q');
  console.log(q); // 현재 'q' 파라미터 값 출력

  const handleClick = () => {
    const newSearchParams = new URLSearchParams(searchParams.toString());
    newSearchParams.set('q', 'hello'); // 'q' 파라미터를 'hello'로 설정

    router.push(`?${newSearchParams.toString()}`);
  }

  return (
    <div>
      <button onClick={handleClick}>
        Write and Redirect
      </button>
    </div>
  )
}

export default Navigation;

버튼 클릭 시 localhost:3000/navigationTest?q=test 의 쿼리가 localhost:3000/navigationTest?q=hello 로 변경된다.

요약

• usePathName 현재 경로를 가져오는 훅
• useRouter 네비게이션을 제어할 수 있는 훅
• useSearchParams 쿼리 파라미터를 읽고 설정할 수 있는 훅

이 세 가지 훅을 활용하면 Next.js 애플리케이션에서 클라이언트 사이드 네비게이션을 효과적으로 처리할 수 있다.

[app>api>movies>route.ts]

import { NextRequest, NextResponse } from "next/server";
import clientPromise form "../../../lib/mongodb";

export async function GET(request: NextRequest) {
  console.log('--------');
  try {
    const client = await clientPromise;
    const db = client.db('sample_mflix');
    const movies = await db.collection('nomad').find({}).toArray();
    return NextResponse.json(movies);
  } catch (error) {
    return NextResponse.error();
  }
}

[app>(home)>page.tsx]

async function getMovies() {
  const response = await fetch('http://localhost:3000/api/movies', {
    method: "GET",
    headers: {
      "Content-Type": "application/json",
    },
  });

  if (!response.ok) {
    throw new Error(`HTTP error! status: ${response.status}`)
  }

  const movies = await response.json();
  return movies;
}


export default async function HomePage() {
  const movies = await getMovies();
  return (
    <div>
      {movies.map(movie => (
        <Movie key={movie.id} id={movie.id} title={movie.title} />
        ))}
      </div>
    )
}

이렇게 하면 잘 렌더링 된다.

그러다 문뜩 MongoDB 의 데이터를 조작하면 어떻게 되는지 궁금해졌다. 그래서 collection 의 데이터를 조금 변형해봤다.

Inside Out2 > Inside Out3

제목을 바꿔봤고 전체 데이터를 갖고오는 것이 아닌 5개의 데이터를 갖고 오도록 하였다. 코드를 다음과 같이 바꿨다.

[app>api>movies>route.ts]

const movies = await db.collection('nomad').find({}).limit(5).toArray();

이제 내 예상은 Inside Out의 제목은 3으로 바뀌어야했고 데이터는 5개만 가져와야했다. 하지만, 예상과 반대로 전과 다름없는 화면을 렌더링 하고 있었다.

무슨 문제인가 하고 곰곰히 생각해보았다.

[ 1. MongoDB 의 변경된 데이터가 반영이 안되었다. ]

혹시나 MongoDB 에서만 적용이 되고 api fetch 할 때는 전혀 반영이 안되었을 수도 있다. 그래서 다음과 같은 url 주소에 접속해보았다.

http://localhost:3000/api/movies

이 곳에 들어가면 내가 패칭한 json이 있기 때문이다. 확인해본 결과, MongoDB 에서 변경한 데이터가 잘 패칭되었다. 그렇다면 api 의 문제는 아니다.

[ 2. 브라우저 캐싱 문제 ]

그렇다면 캐싱문제가 아닐까 라는 생각을 하였다. 코드상에서는 문제가 없어 보였기 때문이다. 따라서, 강력새로고침 (Ctrl + F5) 를 해보았다.

그랬더니, Inside Out3 의 제목과 5개의 데이터들이 렌더링 되었다.

MongoClient를 이용한 방법

먼저, MongoClient 를 이용하여 MongoDB에 연결하는 방법을 살펴보겠다.

코드

import { MongoClient } from 'mongodb';

const uri = process.env.MONGODB_URI || '';
const options = {}

if (!uri) {
  throw new Error('Please add your Mongo URI to .env local');
}

let client;
let clientPromise: Promise<MongoClient>;

if (process.env.NODE_ENV === 'development') {

  if (!global._mongoClientPromise) {
    client = new MongoClient(uri, options);
    global._mongoClientPromise = client.connect();
  }
  clientPromise = global._mongoClientPromise;
} else {
  client = new MongoClient(uri, options);
  clientPromise = client.connect();
}

export default clientPromise;

코드 설명

[ MongoDB 클라이언트 가져오기 ]

import { MongoClient } from 'mongodb';

mongodb 패키지에서 MongoClient 를 가져온다. 이를 통해 MongoDB 클라이언트를 생성할 수 있다.

[ URI 및 옵션 설정 ]

const uri = process.env.MONGODB_URI || '';
const options = {}

console.log('MONGODB_URI: ', uri);

환경 변수 MONGODB_URI 에서 MongoDB URI 를 가져오고, 이 URI 가 설정되지 않은 경우 빈 문자열을 기본값으로 사용한다. 연결 옵션은 빈 객체로 설정되어 있다. 또한, URI 를 콘솔에 출력하여 확인한다.

[ URI 유효성 검사 ]

if (!uri) {
  throw new Error('Please add your Mongo URI to .env local');
}

URI 가 비어 있는 경우, 에러를 발생시켜 사용자가 올바른 URI 를 설정하지 않았음을 알린다.

[ 클라이언트 및 클라이언트 프라미스 변수 선언 ]

let client;
let clientPromise: Promise<MongoClient>;

MongoDB 클라이언트와 클라이언트 연결 프라미스를 저장할 변수를 선언한다.

[ 개발 환경에서의 설정 ]

if (process.env.NODE_ENV === 'development') {
  if (!global._mongoClientPromise) {
    client = new MongoClient(uri, options);
    global._mongoClientPromise = client.connect();
  }
  clientPromise = global._mongoClientPromise;
} else {
  client = new MongoClient(uri, options);
  clientPromise = client.connect();
}

• 개발 환경 (process.env.NODE_ENV === 'development') 에서는 전역 객체 global 에 MongoClient 연결 프라미스를 저장한다. 이렇게 하면 개발 환경에서 코드가 여러 번 실행되더라도 같은 연결을 재사용할 수 있다.

• global._mongoClientPromise 가 설정되지 않은 경우, 새로운 클라이언트를 생성하고 연결한다.

• 개발 환경이 아닐 때는, 클라이언트를 생성하고 바로 연결한다.

[ 클라이언트 프라미스 내보내기 ]

export default clientPromise;

clientPromise 를 기본 내보내기로 설정하여 다른 모듈에서 이 클라이언트를 사용할 수 있게 한다.

Mongoose를 이용한 연결

다음은 Mongoose 를 이용하여 MongoDB에 연결하는 방법이다.

코드

import mongoose from 'mongoose';

const connection = {};

export const connectToDb = async () => {
  try {
    if (connection.isConnected) {
      console.log('Using existing connection');
      return;
    }
    const db = await mongoose.connect(process.env.MONGO);
    connection.isConnected = db.connections[0].readyState;
  } catch (error) {
    console.log(error);
    throw new Error(error);
  }
};

코드 설명

[ Mongoose 가져오기 ]

import Mongoose from 'mongoose';

mongoose 패키지를 가져와 MongoDB와 상호작용할 수 있는 도구를 제공한다.

[ 연결 상태를 저장할 객체 선언 ]

const connection = {};

연결 상태를 저장하기 위한 객체를 선언한다.

[ 데이터베이스 연결 함수 ]

export const connectToDb = async() => {
  try {
    if (connection.isConnected) {
      console.log("Using existing connection");
      return;
    }
    const db = await mongoose.connect(process.env.MONGODB);
    connection.isConnected = db.connections[0].readyState;
  } catch (err) {
    console.error(err);
    throw new Error(err);
  }
};

• 이미 연결된 상태라면 기존 연결을 재사용하도록 설정한다.
• mongoose.connect 를 통해 MongoDB에 연결한다.
• 연결이 성공하면, 연결 상태를 업데이트한다.
• 연결 과정에서 에러가 발생하면 이를 콘솔에 출력하고 에러를 발생시킨다.

장단점

MongoClient

[ 장점 ]

1. 직접적인 제어 MongoClient는 MongoDB의 기본 클라이언트 라이브러리로, MongoDB와의 상호작용을 직접 제어할 수 있다. 이를 통해 최적화된 쿼리와 데이터베이스 작업을 수행할 수 있다.

2. 경량 MongoClient는 가벼운 라이브러리로, 추가적인 추상화 계층이 없다. 따라서 메모리 사용량이 적고, 성능이 빠르다.

3. 유연성 MongoDB의 모든 기능을 직접 활용할 수 있으며, 피룡한 기능을 선택적으로 사용할 수 있다.

[ 단점 ]

1. 추가 코드 필요 데이터 모델링, 스키마 관리, 검증 등의 작업을 직접 구현해야 하므로 코드 작성량이 증가할 수 있다.

2. 복잡성 증가 복잡한 쿼리나 데이터 변환을 처리할 때 추가적인 로직이 필요하므로, 코드가 복잡해질 수 있다.

Mongoose

[ 장점 ]

1. 스키마 기반 모델링 Mongoose는 스키마 기반 데이터 모델링을 제공하여 데이터 구조를 명확하게 정의하고, 데이터의 일관성을 유지할 수 있다.

2. 내장 검증 및 후크 데이터 유효성 검사를 자동으로 수행하고, 데이터베이스 작업 전후에 실행되는 후크(hook)를 지원한다. 이를 통해 데이터 무결성을 보장할 수 있다.

3. 편리한 쿼리 API Mongoose는 MongoDB 쿼리를 보다 간결하게 작성할 수 있는 API를 제공한다. 이를 통해 복잡한 쿼리도 쉽게 작성할 수 있다.

4. 가상 필드 및 메소드 스키마에 가상 필드와 커스텀 메소드를 추가하여 데이터를 가공하거나 확장할 수 있다.

[ 단점 ]

1. 추상화 오버헤드 Mongoose는 MongoDB 위에 추가적인 추상화 계층을 두기 때문에, 성능이 조금 저하될 수 있다.

2. 추가 학습 필요 Mongoose의 고유한 문법과 기능을 익혀야 하므로, 초기 학습 비용이 발생할 수 있다.

3. 유연성 감소 스키마 기반 모델링으로 인해, 스키마를 유연하게 변경하거나 동적 데이터를 처리하는 데 제약이 있을 수 있다.

결론

• MongoClient는 MongoDB와의 상호작용을 직접 제어하고 싶고, 추가적인 추상화 없이 경량의 클라이언트를 선호하는 경우에 적합하다. 예를 들어, 간단한 CRUD 애플리케이션이나 특정 성능 최적화가 필요한 경우에 유용하다.

• Mongoose는 스키마 데이터 모델링, 데이터 검증, 편리한 쿼리 API 등을 제공하므로, 데이터 구조가 명확하고 복잡한 비즈니스 로직을 구현하는 데 유리하다. 예를 들어, 대규모 애플리케이션이나 데이터 무결성이 중요한 프로젝트에서 유용하다.

마무리

이 글에서는 Next.js 애플리케이션에서 MongoDB에 연결하는 두 가지 방법을 소개했다. MongoClient 와 Mongoose 를 사용한 방법 모두 장단점이 있으므로, 프로젝트의 필요에 따라 적절한 방법을 선택하면 된다.

코드 스플리팅은 웹 애플리케이션의 성능을 개선하기 위한 기법 중 하나로, 전체 애플리케이션을 작은 청크로 나누어 필요할 때마다 로드할 수 있도록 하는 방식이다. 이 방법은 애플리케이션의 초기 로딩 시간을 크게 줄일 수 있으며, 사용자 경험을 향상시키는데 기여한다.

모듈화

[모듈?]

IDE( 또는 코드에디터) 에서 작성한 자바스크립트 파일 하나가 모듈 하나다. 개발자는 export 와 import 를 사용해서 모듈(파일) 간 코드를 공유한다.

[모듈화]

자바스크립트 버전이 ES5 에서 ES6 으로 넘어오면서 변화 중 하나는 모듈화가 가능해졌다는 점이다. ES5 까지는 전역 스코프만 가능했지만, ES6 부터는 모듈 스코프가 가능해져 특정 파일만 불러올 수 있다.

다음은 정적으로 import 하는 법이다.

import { FieldValues, SubmitHandler, useForm } from 'react-hook-form';

이와 같이 선언된 스크립트는 실제로 사용되지 않더라도 전부 불러오게 된다.

다음은 동적으로 import 하는 법이다.

const { useForm } = await import('react-hook-form');

const { register } = useForm({ mode: 'onChange'});

이와 같이 동적으로 선언된 스크립트는, 런타임시 실제로 필요할 때 스크립트 파일을 볼러올 수 있다.

동적 import 로 작성된 코드는 WebPack, Rollup, Vite 등 코드 스플리팅을 지원하는 번들러에서 bundle 시 코드가 나누어져 번들링 된다.

이렇게 코드를 나누어 번들링하고, 런타임시 필요한 모듈을 불러오게 하는 것을 코드 스플리팅(Code Splitting) 이라고 한다.

주요 이점

• 성능 최적화 사용자가 실제로 필요로 하는 코드만 로드하기 때문에 불필요한 데이터 전송을 줄이고, 애플리케이션의 응답성을 향상시킨다.

• 효울적인 자원 관리 처음 애플리케이션을 로드할 때 모든 스크립트를 다운로드할 필요가 없으므로, 네트워크 자원과 처리 파워를 절약할 수 있다.

• 유지 관리의 용이성 애플리케이션을 작은 청크로 나누어 관리하면, 특정 부분의 수정이 전체 애플리케이션에 미치는 영향을 최소화할 수 있다.

적용 사례

다음은 리모델링 프로젝트 때 썼던 라우팅 방법이다.

{
    id: 'Main',
    path: '/',
    text: '메인 페이지',
    lazy: async () => {
      const Module = await import('@/pages/Main/Main');
      return { Component: Module.default };
    },
}

다음은 부캠 파이널 프로젝트 때 썼던 라우팅 방법이다.

const router = createBrowserRouter([
  // 루트 페이지 (메인)
  {
    path: '/',
    element: <RootLayout />,
    errorElement: <MissingPage />,
    children: [
      {
        index: true,
        element: <IntroPage />,
      },
      {
        path: 'main',
        element: (
          <SetPage>
            <MainPage />
          </SetPage>
        ),
      }

둘의 차이점은 뭘까?

차이점

[라우팅 방식의 차이]

리모델링 프로젝트 비동기로 컴포넌트를 로드하는 코드 스플리팅이다. lazy 키워드를 통해 비동기 함수로 컴포넌트를 로드하고 있으며, 페이지 로드 시간을 줄이기 위해 사용된다. 해당 페이지가 필요할 때만 해당 컴포넌트를 로드하게 해서 초기 로딩 속도를 개선한다.

파이널 프로젝트 createBrowserRouter 를 사용하여 라우터를 정의하고 있다.

createBrowserRouter란? React Router v6 에서 도입된 API 중 하나로, 라우터를 생성한다. 더 선언적이고 직관적인 방식으로 라우트를 정의할 수 있게 해준다. 또한 코드의 가독성과 유지 보수성을 향상시킨다.

• 선언적 라우팅 구조 라우트를 배열 형태로 선언적으로 정의할 수 있다. 각 라우트는 경로, 컴포넌트, 자식 라우트 등을 포함할 수 있으며, 이러한 구조는 애플리케이션의 라우팅 로직을 한 눈에 파악하기 쉽게 만들어 준다.

• 네스팅된 라우트 라우트 내에 children 속성을 사용하여 하위 라우트를 정의할 수 있다. 이를 통해 복잡한 라우팅 구조를 계층적으로 관리할 수 있으며, 각 레벨에서 필요한 컴포넌트를 렌더링할 수 있다.

• 에러 핸들링 errorElement 프로퍼티를 사용하여 특정 경로에서 발생할 수 있는 오류를 처리하는 컴포넌트를 정의할 수 있다. 이는 사용자에게 보다 친절한 에러 페이지를 제공하고, 예외 상황을 더욱 효과적으로 관리할 수 있게 해준다.

[구성 요소의 사용]

리모델링 프로젝트 단일 lazy 함수를 통해 비동기적으로 모듈을 로드하고, 모듈에서 기본으로 내보낸 컴포넌트를 사용한다. 이 방법은 라우트별로 모듈을 분리하여 필요할 때만 로드하는 코드 스플리팅을 통해 성능 최적화를 꾀할 수 있다.

파이널 프로젝트 라우트별로 element, errorElement, children 구조를 사용하여, 더 세밀하고 계층적인 라우팅 구조를 제공한다. 각 라우트는 자체적으로 페이지 레이아웃, 에러 페이지, 하위 라우트 등을 정의할 수 있다. 이는 라우트 관리를 좀 더 유연하게 하며, 복잡한 애플리케이션에서 라우트 관리를 쉽게 할 수 있게 한다.

[성능 및 최적화]

리모델링 프로젝트 초기 로드 시간에 집중한 지연 로딩 방식을 사옹하여, 사용자가 실제로 방문하는 페이지의 컴포넌트만 로드한다.

파이널 프로젝트 더 구조화된 접근 방식을 통해 복잡한 라우트를 관리하면서도 React Router 의 최신 기능을 활용하여 애플리케이션의 유지보수성을 향상시킨다.

단점

이렇게 보면 lazy loading 을 무조건 쓰는 것이 최적화에 도움이 되고 안 쓸 이유가 없을 것 같은데 단점이 없는것이 아닌가? 궁금해서 단점에 대해서 한번 찾아보았다.

• 지연 시간 발생 사용자가 특정 기능이나 페이지에 접근할 때 그 시점에서야 필요한 리소스를 로드하기 시작하므로, 사용자는 해당 컴포넌트가 로드될 때까지 기다려야 할 수 있다.

• 코드 복잡성 증가 코드 스플리팅과 레이지 로딩을 구현하기 위해서는 추가적인 로직이 필요하며, 이로 인해 코드의 복잡성이 증가하며 개발과 유지 보수가 어려워질 수 있다.

• SEO 영향 검색 엔진 최적화에 부정적 영향을 줄 수 있다. 검색 엔진 크롤러가 자바스크립트를 완전히 실행하지 않고 페이지를 크롤링할 경우, 로드되지 않은 컨텐츠는 인덱싱되지 않을 수 있다.

이렇게 단점들을 찾아보았는데, 이렇게 보면 사실 큰 단점이 없는 것 같다.

지연 시간 발생은 어차피 처음에 모든 스크립트들을 로드하는 것도 마찬가지일 것 같고, 코드 복잡성 증가는 사실 개발자 입장에서만 그렇지, 사용자들은 더 나은 경험을 할 것이다. SEO 영향은 React Helmet 을 씌워도 안되는지 사실 잘 모르겠다. 해봐야 알 것 같다. 사실 그냥 리액트의 문제 아닌가?

그럼 어느 때에 써야하나?

그럼 최적의 사용 시나리오는 어떤 경우일까 궁금해졌다. 찾아보니 다음과 같았다.

• 대형 에플리케이션 많은 페이지와 기능을 가진 대형 애플리케이션에서는 사용자가 접근할 가능성이 낮은 부분까지 모두 초기에 로드하는 것은 비효율적이다. 이런 경우 lazy loading 을 통해 필요한 부분만 로드하도록 설정하는 것이 좋다.

• 특정 기능이 중요도가 낮은 경우 예를 들어, 애플리케이션의 특정이 기능이 일부 사용자에게만 필요하다면, 그 기능의 로딩을 지연시키고 기본 기능에 더 빠르게 접근할 수 있도록 할 수 있다.

대형 애플리케이션에 적용한다는 거는 조금만 생각하면 금방 알 수 있었던 이유다. 하지만 중요도는 생각치도 못했다. 중요도가 낮은 기능은 스크립트 로드시간을 초기에 하지말고 그 기능이 쓰일 때 로드될 때 하면 기본적인 기능의 접근은 더 빠르게 될 것이다.

작은 프로젝트 때는 굳이 lazy 를 써야할까 싶었는데, 전부 적용하는 것이 아닌 중요도가 낮은 기능에는 충분히 적용할만 한 것 같다.

요약

코드 스플리팅은 웹 애플리케이션의 초기 로딩 시간을 줄이고 사용자 경험을 개선하기 위해 전체 애플리케이션을 작은 청크로 나누어 필요할 때 로드할 수 있게 하는 기법이다. 모듈화는 ES6 이후 자바스크립트에서 가능해졌으며, export와 import를 통해 코드를 모듈 간에 공유할 수 있다. 정적 import는 코드가 항상 로드되지만, 동적 import는 코드가 실제 필요할 때만 로드되도록 하여 코드 스플리팅을 가능하게 한다.

코드 스플리팅의 이점으로는 성능 최적화, 효율적인 자원 관리, 유지 관리의 용이성 등이 있다. 하지만 단점으로는 지연 시간 발생, 코드 복잡성 증가, SEO에 대한 부정적 영향 등이 있다. 이 기법은 특히 대형 애플리케이션에서 효과적이며, 사용자가 자주 방문하지 않는 페이지나 중요도가 낮은 기능에 적용하면 초기 로드 시간을 줄이면서도 필요한 기능은 적시에 제공할 수 있다.

결론적으로, 코드 스플리팅은 애플리케이션의 성능과 사용자 경험을 향상시키는 중요한 전략이지만, 적용할 때는 애플리케이션의 구조와 사용자의 접근 패턴을 고려해 신중하게 결정해야 한다.

HealthyP 리팩토링 중 건강식 | 다이어트 | 벌크업 | 비건 등 대분류 카테고리에서 캐싱문제가 있다는 것을 발견하였다.

예를 들어, 건강식을 누르면 데이터가 캐싱되고 다음으로 다이어트 카테고리를 누른다. 그러면, 건강식의 데이터들이 잠깐 나온다음 다이어트 데이터들이 나온다.

이처럼, 이전 카테고리의 데이터들이 잠깐씩 렌더링 된다는 것이 문제였다. 원인이 무엇인가 하니, tanstack query 에서 쓰이는 캐싱로직이 잘못되었다는 것을 알게되었다.

[기존 코드]

const { data, status, isFetchingNextPage, fetchNextPage, hasNextPage } = useInfiniteQuery({
    queryKey: 'recipes',
    queryFn: callbackFn,
    initialPageParam: 1,
    getNextPageParam: (lastPage, allPages) => {
      const nextPage = lastPage.length ? allPages.length + 1 : undefined;
      return nextPage;
    },
  });

어디가 문제인가하니 querkKey 부분이 문제였다. 건강식, 다이어트, 벌크업, 비건 심지어 사진에는 보이지 않지만 북마크 페이지 조차 queryKey 를 recipes 를 쓰고 있었다.

그래서, 5개의 페이지가 같은 데이터들을 캐싱하고 덮어씌우는 과정에 있었던 것이었다.

이 문제를 해결하기 위해, 각각 카테고리들에게 다른 queryKey 를 적용시킬 필요가 있었다. 다음은 수정한 코드이다.

[수정한 코드]

interface infinityCardProps {
  callbackFn: (pageParam: { pageParam: number | undefined }) => Promise<RecordModel[]>;
  title: string;
}

export function useInfinityCard({ callbackFn, title }: infinityCardProps) {

  const { data, status, isFetchingNextPage, fetchNextPage, hasNextPage } = useInfiniteQuery({
    queryKey: [title],
    queryFn: callbackFn,
    initialPageParam: 1,
    getNextPageParam: (lastPage, allPages) => {
      const nextPage = lastPage.length ? allPages.length + 1 : undefined;
      return nextPage;
    },
  });

props 로 title 을 추가해줬다. 그리고 useInfinityCard 를 쓰는 CategoryPage 에서 title 을 추가해줬다.

export function CategoryPage() {
  const { title } = useParams();

  async function getRecipeData({ pageParam = 1 }) {
    if (title === '오늘의 레시피') {
      const recordsData = await db.collection('recipes').getList(pageParam, 6, {
        expand: 'rating, profile',
        sort: '-views',
      });
      return recordsData.items;
    } else {
      const recordsData = await db.collection('recipes').getList(pageParam, 5, {
        expand: 'rating, profile',
        filter: `category = "${title}"`,
        sort: '-created',
      });

      return recordsData?.items;
    }
  }

  const { data, status, isFetchingNextPage, userData, ref } = useInfinityCard({
    callbackFn: getRecipeData,
    title: title || 'recipes',
  });

그 결과, useParamas() 에 의해 얻은 title 을 통해 각각의 카테고리에 알맞은 queryKey 를 배정해 줄 수 있었다.

그리고 각 queryKey 를 배정해준 결과, 이전 데이터들이 더이상 렌더링 되지 않고 정상적으로 현 카테고리들의 데이터들만 렌더링이 되었다.

결과

스켈레톤 컴포넌트는 데이터를 가져오는 동안 사용자가 로드 중인 상태를 시각적으로 알려주는 디자인 패턴이다. 이 방법은 데이터가 완전히 로드되기 전에 페이지의 레이아웃을 대략적인 형태로 보여준다. 이 형태는 일반적으로 회색 블록이나 줄들로 이루어져 있으며, 최종 컨텐츠가 들어갈 자리를 대략적으로 표현한다.

스켈레톤 UI의 주요 목적

• 로딩 인디케이터 페이지나 앱이 여전히 작동 중이고 데이터가 로딩되고 있다는 것을 사용자에게 알린다. 이는 단순히 로딩 스피너나 진행 바를 보여주는 것보다 사용자에게 더 많은 정보를 제공한다.

• 인지적 부하 감소 사용자가 최종 컨텐츠의 형태와 구조를 예상할 수 있게 하여, 실제 컨텐츠가 로드될 때 정보를 더 빠르게 처리할 수 있도록 돕는다.

• 보다 나은 사용자 경험 빈 화면 대신 구조화된 플레이스홀더를 보여주어 사용자의 인내심을 돕고, 페이지가 로드되는 동안의 불편함을 줄여준다.

스켈레톤 UI 는 데이터 로딩 시간이 긴 웹 애플리케이션, 특히 복잡한 데이터와 인터랙션이 많은 대시보드, 피드, 또는 목록이 있는 경우에 특히 유용하다. 이 패턴은 사용자에게 페이지 로딩 중인 상태를 더 명확하게 전달하고, 컨텐츠가 곧 등장할 것임을 암시하여 사용자의 관심을 유지하는 데 도움을 준다.

tailwind 스켈레톤 UI 사용법

tailwind 에는 따로 스켈레톤을 위한 유틸리티 css 가 없으니 직접 만들어 써야한다.

따라서 tailwind.confing.js 에 다음과 같은 코드를 추가해줘야한다.

// tailwind.config.js
extend: {
      animation: {
        shimmer: 'shimmer 1.5s infinite linear',
      },
      keyframes: {
        shimmer: {
          '0%': { backgroundPosition: '200%' },
          '100%': { backgroundPosition: '-200%' },
        },
      },
      backgroundImage: {
        'gradient-custom': 'linear-gradient(to right, #D9D9D9 0%, #EDEEF1 50%, #D9D9D9 100%)',
      },
      backgroundSize: {
        custom: '300% 100%',
      },
}     

애니메이션은 본인 입맛대로 수정 및 작성해주면 된다. 그리고 이대로 쓸 수 있지만 여러곳에서 쓰일 것을 대비해 utility css 로 등록해둔다.

// index.css
@layer components {
  .skeleton {
    @apply animate-shimmer bg-gradient-custom bg-custom;
  }
}

utility css 로 등록을 한 다음, 다음과 같이 작성하면 된다.

// Skeleton.tsx
export default function SkeletonLargeCard() {
  return (
    <div className="h-max overflow-hidden p-14pxr bg-white max-w-430pxr shrink-0 shadow-default">
      <div className="flex justify-between min-h-54pxr items-center">
        <div className="flex gap-4pxr items-center">
          <div className="size-30pxr bg-gray_400 rounded-[30px] skeleton" />
          <div className="w-60pxr h-25pxr bg-gray_400 rounded-[5px] skeleton" />
        </div>
        <div className="w-30pxr h-25pxr bg-gray_400 rounded-[5px] skeleton" />
      </div>
      <div className="w-full h-181pxr bg-gray_400 rounded-[5px] mb-20pxr skeleton" />
      <div className="flex gap-5pxr mb-20pxr">
        <div className="w-50pxr h-25pxr bg-gray_400 rounded-[5px] skeleton" />
        <div className="w-50pxr h-25pxr bg-gray_400 rounded-[5px] skeleton" />
      </div>
      <div className="w-170pxr h-25pxr bg-gray_400 rounded-[5px] mb-10pxr skeleton" />
      <div className="w-full h-25pxr bg-gray_400 rounded-[5px] skeleton" />
      <div className="flex px-2pxr pt-20pxr pb-36pxr gap-4pxr items-center">
        <div className="w-50pxr h-20pxr bg-gray_400 rounded-[5px] skeleton" />
        <div className="w-50pxr h-20pxr bg-gray_400 rounded-[5px] skeleton" />
      </div>
    </div>
  );
}

뼈대를 만든 다음 skeleton tailwind css 를 추가해주면 된다. 그리고 로딩 상태일 때 Skeleton 을 불러오면 다음과 같이 애니메이션이 작동한다.

느낀점

스켈레톤 을 적용하기 전에는 로고만 뚜둥 하고 뜨는 정도였다. 그마저도, 1초도 안되는 짧은 시간이었다. 네트워크를 통해 로딩속도를 조절하면 로고가 뜨고 빈 화면이 몇초간 유지가 되었다.

하지만, 스켈레톤 을 적용하였더니 일단 다음과 같은 장점을 느낄 수가 있었다.

• 로딩중 일단, 데이터가 로딩중 이라는 것을 로고만 뜨는 것보다 확실히 알 수가 있었다. 더구나, 그냥 회색 스켈레톤 만 띄우면 잘 알 수가 없을것이다. 하지만, 하얀 빛이 오른쪽으로 이동하고 있는 것을 통해 로딩중 이라는 것을 확실히 알 수 있었다.

• 앞으로의 레이아웃 레이아웃이 예상이 된다. 이 점이 생각보다 꽤 큰 도움이 되는 것 같다. 레이아웃을 미리 볼 수 있음으로써 정보들의 배치 혹은 내가 원하는 정보의 위치를 예상할 수 있었다. 스켈레톤 골격 자체가 데이터가 생기고 난 후의 골격을 따라가다보니 배치에서의 큰 오차가 없었다.