Dorong Dorong 💻😴

오늘은 제가 Context API에서 Zustand로 상태관리 도구를 전환하게 된 과정과 2024년 현재 리액트 상태관리 라이브러리들의 현황에 대해 이야기해보려 합니다.

1. Context API의 한계와 상태관리 라이브러리의 필요성

Context API로 시작한 이유

처음 알리니 프로젝트를 시작할 때는 Context API만으로 충분하다고 생각했습니다. 사용자 인증, 테마, 언어 설정 등 전역적으로 공유되어야 하는 상태들을 관리하는 데 Context API 만으로 충분했습니다.

// 초기 Context API 사용 예시
const PetContext = React.createContext<PetContextType | undefined>(undefined);

export const PetProvider: React.FC<PropsWithChildren> = ({ children }) => {
  const [petData, setPetData] = useState<PetData>({
    allergies: [],
    symptoms: [],
    foodLog: []
  });

  return (
    <PetContext.Provider value={{ petData, setPetData }}>
      {children}
    </PetContext.Provider>
  );
};

한계점 발견

하지만 프로젝트가 커지면서 여러 가지 한계점이 드러나기 시작했습니다:

• 불필요한 리렌더링: Context의 값이 변경될 때마다 해당 Context를 구독하는 모든 컴포넌트가 리렌더링되었습니다. 
• 코드 복잡도 증가: 여러 개의 Context를 중첩해서 사용하다 보니 Provider Hell이 발생했습니다.
• 상태 업데이트 로직 관리의 어려움: 비동기 작업과 복잡한 상태 업데이트 로직을 처리하는 데 한계가 있었습니다.

2. 주요 상태관리 라이브러리 비교 분석

Redux

Redux는 오랫동안 리액트 생태계의 표준과 같은 상태관리 라이브러리 입니다.

Redux의 핵심 개념

• Action: 상태 변경을 위한 이벤트를 설명하는 객체
• Reducer: Action을 받아 상태를 변경하는 순수 함수
• Store: 애플리케이션의 전체 상태를 보관하는 객체

Redux 미들웨어 생태계

• Redux Thunk: 비동기 작업을 처리하기 위한 가장 기본적인 미들웨어
• Redux Saga: 복잡한 비동기 흐름을 제어하기 위한 미들웨어
  • Generator 함수를 사용한 선언적 비동기 처리
  • 복잡한 시나리오(API 요청 취소, 재시도 등) 처리 가능
• Redux Toolkit: 보일러플레이트 코드를 줄이기 위한 공식 도구

그러나 Redux는 다음과 같은 단점이 있습니다:

• 많은 보일러플레이트 코드
• 학습 곡선이 가파름
• 작은 상태 변화에도 많은 코드 필요

Recoil

Facebook에서 만든 상태관리 라이브러리입니다.

장점

• React와의 높은 호환성
• 간단한 API (atom, selector)
• 비동기 데이터 처리가 쉬움

단점

• 아톰으로 관리되는 전역 상태를 어떤 컴포넌트라도 바로 아톰을 구독해서 업데이트를 받기에, 의존성이 여러 방향으로 엮이면서 예측하기 힘들어집니다.

Zustand

가볍고 직관적인 API를 제공하는 현대적인 상태관리 라이브러리입니다.

주요 특징

• 최소한의 보일러플레이트
• TypeScript 지원이 훌륭함
• Redux DevTools 지원
• 미들웨어 시스템 (persist, devtools 등)

예시 코드:

import create from 'zustand'

interface PetStore {
  symptoms: Symptom[]
  addSymptom: (symptom: Symptom) => void
  foodLogs: FoodLog[]
  addFoodLog: (log: FoodLog) => void
}

const usePetStore = create<PetStore>((set) => ({
  symptoms: [],
  addSymptom: (symptom) => set((state) => ({
    symptoms: [...state.symptoms, symptom]
  })),
  foodLogs: [],
  addFoodLog: (log) => set((state) => ({
    foodLogs: [...state.foodLogs, log]
  }))
}))

3. 실제 프로젝트에서의 선택: Zustand

알리니 프로젝트에서의 요구사항

1. 실시간 데이터 업데이트
2. 복잡한 상태 관리 (알레르기 증상, 음식 기록, 분석 데이터)
3. 성능 최적화
4. TypeScript 지원

Zustand 선택 이유

1. 간단한 설정과 사용법: 별도의 Provider 설정이 필요 없고, 직관적인 API를 제공합니다.
2. 성능 최적화: 필요한 상태만 구독하여 불필요한 리렌더링을 방지합니다.
3. TypeScript 지원: 타입 추론이 잘 동작하여 개발 생산성이 향상되었습니다.
4. 미들웨어 지원: persist 미들웨어를 통해 로컬 스토리지 연동이 쉬웠습니다.

Context API와의 조화

Context API와 Zustand를 함께 사용할 수 있습니다. 저는 다음과 같이 역할을 구분했습니다:

• Context API: 테마, 인증 등 애플리케이션의 전반적인 설정과 관련된 상태 관리 (단어 그대로 특정 맥락을 씌울때 사용했습니다.)
• Zustand: 비즈니스 로직과 관련된 복잡한 상태 관리

4. 결론

2024년 현재, 저는 다음과 같은 기준으로 상태관리 라이브러리를 선택했습니다:

1. 작은 프로젝트: Context API만으로도 충분
2. 중간 규모 프로젝트: Zustand
3. 대규모 프로젝트: Redux Toolkit 또는 Zustand

알리니와 같이 실시간 데이터 처리와 복잡한 상태 관리가 필요한 프로젝트에는 Zustand가 특히 적합했습니다. 코드가 간결하면서도 강력한 기능을 제공하며, 특히 TypeScript와의 호환성이 뛰어나 개발 경험이 매우 좋았습니다.

프로젝트에 도입될 무한 스크롤을 개발 중인 상황입니다.
개발을 진행하던 중 데이터가 무수히 많아질 경우 문제가 발생하진 않을까라는 생각에 무한 스크롤에 대한 최적화를 고민하게 되었습니다!
여러 최적화 중 하나는 버츄얼 스크롤에 대해 파트를 나눠 기록해두려 해요!

버츄얼 스크롤 이란?

버츄얼 스크롤(Virtual Scroll)은 대량의 데이터를 효율적으로 처리하기 위한 기술로, 사용자가 실제로 보고 있는 항목만 렌더링하여 성능을 개선합니다.

특히, 리스트나 그리드 형식의 데이터를 다룰 때 유용하게 사용됩니다.

이번 블로그에서는 버츄얼 스크롤을 사용해야 할 상황과, 실제 상용 라이브러리에서의 구현 방식을 살펴보겠습니다.

상용 라이브러리에 대한 설명은 별도의 글로 분리하였습니다!

해당 글에선 버추얼 스크롤을 직접 구현하기 전에 도입을 위해 찾아본 이미 상용화된 라이브러리에 대해 작성해 보겠습니다!

인기 라이브러리 개요

검토해본 버츄얼 스크롤을 지원하는 라이브러리로는 react-window, react-virtualized, react-virtuoso가 있습니다.

각 라이브러리는 고유한 접근 방식을 통해 버츄얼 스크롤을 구현하고 있으며, 다양한 사용 사례와 성능 요구사항에 맞추어 설계되었습니다.

이 중에서 React Virtualized는 가벼워진 버전인 React Window가 가장 많이 사용되며, React Virtuoso는 비교적 최근에 출시되어 사용량이 적지만 점점 인기를 끌고 있는 라이브러리입니다. React Virtuoso는 React Window에는 없는 기능들을 지원하여 가볍고 간단하면서도 다양한 요구에 대응할 수 있습니다. 이들 라이브러리는 가상 스크롤을 통해 스크롤을 내릴 때 데이터를 끊김 없이 보여줄 수 있는 windowing 처리를 지원합니다.

Windowing

Windowing은 현재 화면에 필요한 데이터만 표시하는 방법입니다. 긴 리스트의 경우 모든 데이터를 한 번에 렌더링하면 성능이 저하되고 렉이 발생할 수 있기 때문에, windowing 기술을 통해 효율적으로 데이터를 처리할 수 있습니다.

엘리님의 드림 코딩 Express 강의의 Rate Limit 관련 알고리즘을 학습하며 알게 됐던 개념인데 다시 보니 괜히 반갑네요! ㅎㅎ

스크롤 위치

• React Virtualized는 사용자가 스크롤한 위치를 기억하는 기능이 있어 페이지를 새로고침해도 그 위치에서 다시 시작할 수 있습니다.
• React Window는 스크롤 위치 저장 기능이 없어, 새로고침 후 최상단 항목으로 돌아가는 불편함이 있을 수 있습니다. 예를 들어, 1000개의 리스트 항목 중 700번째 항목을 보고 있다가 새로고침하면 최상단으로 이동합니다.
• 클라이언트 사이드 라우팅으로 인해 페이지 간 이동 시 상태가 유지되지만, URL이 변경되면 스크롤 위치가 초기화되어 페이지가 언마운트되고 새로운 컴포넌트가 마운트되기 때문에 초기 상태로 돌아갑니다.
• 언마운트 시 API 요청이 다시 발생할 수 있으며, Context API, Redux, React Query 등의 상태 관리 방법을 사용하여 불필요한 API 요청을 방지할 수 있습니다.

높이 계산 (정적, 동적)

• React Window는 정적인 높이를 지원하므로 리스트 항목의 높이가 일정해야 사용 가능합니다.
• React Virtualized는 동적인 높이를 지원하여 리스트 항목의 내용에 따라 높이가 달라져도 자동으로 계산할 수 있습니다. 이를 위해 CellMeasurer 컴포넌트를 사용할 수 있으며, 이 컴포넌트는 새로운 콘텐츠가 나타날 때 높이를 자동으로 재계산합니다.
• CellMeasurer와 함께 CellMeasurerCache를 사용하면 높이를 캐시하여 성능을 향상시킬 수 있습니다.

React Window

• 목적: 많은 데이터 리스트와 표 형식 데이터를 효율적으로 렌더링하여 뷰포트에 보이는 항목만 렌더링합니다.
• 주요 기능:
  • React Window는 기본적으로 정적인 높이를 가진 리스트와 그리드만 제공합니다. 필요한 최소한의 기능을 제공하여 경량화된 라이브러리입니다.
  • DOM 노드 수를 최소화하여 렌더링 시간과 메모리 사용량을 줄입니다.
  • 초보자를 위해 설계된 간단한 API로 성능에 중점을 둡니다.
  • react-window-infinite-loader와 같은 외부 패키지를 사용하여 데이터의 지연 로딩을 지원합니다.
• 사용법: 최소한의 설정으로 쉽게 사용할 수 있으며, 사용자 정의 속성과 이벤트 핸들러 또한 사용 가능합니다.

React Virtualized

• 목적: React Window와 유사하지만 더 복잡한 사용 사례를 위한 폭넓은 기능을 제공합니다.
• 주요 기능:
  • React Virtualized는 가상화된 그리드, 필터링, 정렬, 드래그 앤 드롭 등 다양한 기능을 제공합니다.
    • 가상화된 그리드는 동적인 높이 계산을 통해 사용자에게 보기 좋은 형태로 데이터가 배치됩니다.
    • 필터링 기능은 특정 조건에 맞는 항목만 표시할 수 있습니다.
    • 정렬 기능을 통해 사용자가 원하는 기준으로 리스트를 정렬할 수 있습니다.
    • 드래그 앤 드롭 기능을 통해 리스트 항목의 순서를 쉽게 변경할 수 있습니다.
    • 일부 스타일에 CSS가 필요하며, 번들 크기를 줄이기 위해 특정 구성 요소만 임포트할 수 있습니다.
    • 최적화를 위해 shallowCompare를 사용하여 props나 state가 변경되지 않으면 다시 렌더링하지 않습니다.
• 사용법: 복잡한 API 때문에 설정이 더 복잡할 수 있으며, react-window나 react-virtuoso와 비교해 애플리케이션의 번들 크기를 증가시킬 수 있습니다.
  
  

React Virtuoso

• 목적: 가변 크기 항목을 자동으로 처리하며, 다양한 기능을 제공하는 포괄적인 구성 요소 세트를 제공합니다.
• 주요 기능:
  • 수동 크기 조정 없이 가변 크기 항목을 자동으로 처리합니다.
  • 채팅 메시지 리스트
  • 스티키 헤더가 있는 그룹화된 항목
    • 리스트의 항목을 카테고리별로 그룹화 한다는 의미입니다!(제가 헷갈렸던 부분이라 풀어 적을게요!) 예를 들어, 제품 리스트가 "과일"이나 "채소"와 같은 카테고리로 나뉘어 있을 수 있습니다. 각 그룹에는 상단에 고정된 헤더가 있어 사용자가 리스트를 스크롤할 때 현재 어떤 그룹을 보고 있는지 쉽게 알 수 있게 해줍니다. 이 스티키 헤더 기능은 사용자에게 더 나은 맥락을 제공하여 사용 경험을 향상시킵니다.
  • 무한 스크롤 등을 지원합니다.
  • CSS 클래스 속성을 통해 동일한 크기의 항목을 여러 열로 표시할 수 있습니다.
• 사용법: 복잡한 리스트 뷰 구현을 단순화하여 직관적인 API로 개발자에게 사용하기 쉽게 설계되었습니다.

요약 및 마무리

• 성능: 세 라이브러리 모두 DOM 노드를 줄이고 렌더링을 최적화하여 성능을 향상시키는 데 중점을 둡니다.
• 복잡성: React Window가 가장 간단하고 경량이며, React Virtualized는 더 많은 기능을 제공하지만 복잡성이 증가합니다. React Virtuoso는 고급 기능과 사용 편의성의 균형이 좋습니다.
• 사용자 정의: 각 라이브러리는 사용자가 필요에 맞게 조정할 수 있는 다양한 옵션을 제공합니다. 특히 React Virtuoso와 React Virtualized는 스타일이나 레이아웃을 커스터마이즈하는 데 더 많은 유연성을 줍니다. 예를 들어, 사용자들은 자신만의 디자인 요구에 맞춰 항목의 크기, 색상, 배치 등을 자유롭게 변경할 수 있습니다. 
• React Window는 기본적인 리스트와 그리드, 정적인 높이를 지원하며, 필요 없는 기능들은 제거하여 가볍고 간단하게 사용할 수 있습니다. 작은 프로젝트에 적합하지만, 기능이 제한적입니다.
• React Virtualized는 많은 기능을 지원하며, 복잡한 UI/UX를 구축할 때 유용하지만, 설정이 복잡하고 파일 크기가 큰 단점이 있습니다.
• React Virtuoso는 경량화와 간편함을 추구하며, 최근 인기를 끌고 있는 라이브러리로, 필요한 기능이 많다면 다른 라이브러리와 함께 사용할 수도 있습니다.

이처럼 각 라이브러리는 각기 다른 특성과 장단점을 가지고 있으며, 프로젝트의 요구에 맞춰 선택하는 것이 중요합니다.

SVG를 별도의 컴포넌트로 만들지 않고도 컴포넌트처럼 사용할 수 있도록 Webpack 설정을 추가한 과정을 공유해 보려고 합니다.

프로젝트에서 첫 번째 SVG인 햄버거 아이콘을 SVG로 적용하면서 겪은 문제와 그 해결 과정을 함께 나누겠습니다.

SVG 파일을 직접 사용하는 이유

SVG를 img 태그가 아닌 컴포넌트처럼 사용하려면 일반적으로 함수형 컴포넌트로 변환하는 방법도 있지만, 저는 .svg 확장자를 그대로 사용하는 것이 파일 관리 측면에서 더 편하다고 느꼈습니다. 몇 가지 이유를 들어보겠습니다.

1. 파일 관리 용이성: SVG 파일을 별도의 컴포넌트로 만들 필요 없이, 파일 경로를 통해 쉽게 가져올 수 있어 프로젝트 구조가 깔끔해집니다.
2. 재사용성: 동일한 SVG 파일을 여러 곳에서 재사용할 수 있으며, 파일을 수정하면 모든 참조에서 자동으로 업데이트됩니다.
3. 디자인 툴과의 호환성: 많은 디자인 툴이 SVG 포맷을 지원하므로, 디자이너와의 협업이 원활합니다. SVG 파일을 직접 사용하면 디자이너가 작업한 파일을 그대로 활용할 수 있습니다.

이러한 이점 덕분에, 저는 svgr/webpack을 추가로 설치하여 SVG 파일을 쉽게 사용할 수 있도록 설정하였습니다.

문제의 시작

SVG 아이콘을 컴포넌트처럼 활용하기 위해 svgr/webpack을 설정하는 과정에서 몇 가지 문제가 발생했습니다.

1. 타입스크립트 에러: 현재 개발한 <Svg /> 컴포넌트에서는 props를 넘길 수 없어 에러가 발생했습니다. 예를 들어, <Hamburger width="24" /> 형태로 사용하려 했을 때, “Type '{width: string} is not assignable to type 'IntrinsicAttributes'.”라는 타입 에러가 발생했습니다. 이로 인해 props를 제대로 전달하지 못하게 되었고, 결과적으로 CSS에서 직접적으로 svg { }에 설정하게 되어 유연성이 떨어진 상황이었습니다.
2. 타입 선언 문제: declarations.d.ts 파일에서 SVG 타입을 any로 선언했기 때문에 발생한 에러였습니다. 이 문제를 해결하기 위해 타입을 string으로 변경하였고, 이는 tsconfig 설정과 관련이 있었습니다. 

상세 해결 과정

이 문제를 해결하기 위해 다음과 같은 과정을 거쳤습니다.

1. 타입 선언 수정: 초기에는 다음과 같이 선언했습니다.

// declarations.d.ts
declare module "*.svg?url" {
  const url: any;
  export default url;
}

하지만 any 대신 string으로 수정하여 에러를 해결했습니다.

// declarations.d.ts
declare module "*.svg?url" {
  const url: string;
  export default url;
}

 {
    test: /\.(jpg|jpeg|gif|png|eot|woff|ttf)$/i,
    type: "asset/resource",
  },
  {
    test: /\.svg$/,
    oneOf: [
      {
        use: ["@svgr/webpack"],
        issuer: /\.[jt]sx?$/,
        resourceQuery: { not: [/url/] },
      },
      {
        type: "asset",
        resourceQuery: /url/, // *.svg?url
      },
    ],
  },

배열의 순서대로 규칙을 처리하는 웹팩을 위해 @svgr/webpack 규칙을 assets/resource 규칙보다 상위로 올리는 방법도 있었으나, 두 규칙 중 하나의 규칙만이. svg 파일에 적용되게 하기 위해 @svgr/webpack의 svg 규칙만을 유지했습니다.

느낀 점

이번 작업을 통해 SVG를 효율적으로 활용할 수 있는 여러 방법에 대해 알게 되었고, Webpack과 TypeScript의 설정에 대한 이해해도도 높아진 것 같습니다. 파일 관리의 용이성과 재사용성을 고려할 때, SVG를 직접 사용하는 것이 매우 유리하다는 생각이 들었습니다. 앞으로도 이러한 경험을 바탕으로 더 나은 개발 환경을 만들어 가고 싶습니다.

SVG 컴포넌트로의 전환이 쉽지 않았지만, 결과적으로 더 유연한 디자인 작업이 가능해졌습니다. 여러분도 SVG를 다양하게 활용해 보시길 추천드립니다!

Allini는 Create React App(CRA)을 사용하지 않고, 직접 Webpack과 Babel을 설정해보기로 했습니다.
회사에서 Webpack을 설정해본 경험이 있어, 처음에는 그 기억에 의존해 작업을 시작했어요.

그런데 프로젝트 진행 도중 Pretendard-Black.subset.woff2 및 Pretendard-ExtraBold.subset.woff2 폰트 파일을 찾을 수 없다는 에러가 발생했습니다.

이 에러를 해결하기 위해 파일 위치, font.css의 경로, 파일명, 빌드 캐시 삭제 등 다양한 방법을 시도했지만,

문제는 여전히 해결되지 않았고..😢

제가 작성한 Webpack 설정 자체에 문제가 있는 것이 아닌가 의심하게 됐습니다.

Webpack 설정 점검: file-loader는 잘 등록했는데...

에러가 발생한 이유를 찾기 위해 webpack.config.js 파일에서 파일 로더 설정을 확인했습니다.

file-loader를 아래와 같이 설정해두었기에, 문제가 없을 것이라고 생각했었죠..! 

{
  test: /\.(png|jpe?g|gif|webp)$/i,
  use: [
    {
      loader: "file-loader",
      options: {
        name: "[path][name].[ext]",
      },
    },
  ],
}

그렇기에 이 설정에는 아무런 문제가 없다고 판단했고, 왜 이런 문제가 발생하는지 도저히 이해가 되지 않았습니다.

엉뚱한 고민: MSW가 문제인가?

이쯤 되니 MSW(Mocking Service Worker)가 폰트 파일조차 가로채는 것이 아닌가 하는 엉뚱한 생각까지 하게 되었어요..!

MSW는 백엔드가 구축되기 전에 프론트엔드 UI 개발을 위해 사용 중이었습니다.

하지만 공식 문서를 읽어본 결과, MSW는 정적 리소스(예: 폰트 파일)에는 영향을 주지 않는다는 것을 확인했습니다.

MSW가 폰트 파일 요청을 가로채지 않는 한, 이 문제는 MSW와 관련이 없을 가능성이 높았습니다.

진짜 문제: Webpack 버전 차이

고민을 거듭하던 중, 혹시 내가 알고 있던 Webpack 설정과 현재 사용하는 버전 간에 차이가 있는 것은 아닐까 하는 생각이 들었습니다.

이 생각이 바로 정답이었죠!!!  ᕦ( ᐛ )ᕡ

Webpack 5에서는 파일 로더 설정이 간소화되었고, 더 이상 file-loader를 사용할 필요가 없었습니다.

Webpack 5에서는 다음과 같이 설정합니다:

{
  test: /\.(jpg|jpeg|gif|png|svg|eot|woff|ttf)$/i,
  type: "asset/resource",
}

Webpack 5에서는 file-loader와 url-loader등을 더 이상 사용하지 않고, asset/resource, asset/inline, 그리고 asset을 통해 파일을 처리합니다.

• asset/resource: 별도의 파일을 내보내고 URL을 반환합니다. (file-loader 대체)
• asset/inline: 데이터 URL로 내보내기 (url-loader 대체)
• asset: 자동으로 데이터 URL과 파일 내보내기 중 선택하며, 기존의 크기 제한 설정도 포함됩니다.

더 자세한 내용은 참고했던 Webpack 공식 문서 링크를 남겨둘게요!!

학습 방식에 대한 반성, 그리고 앞으로의 계획

이전에 TOAST Editor가 React 17 버전까지만 지원된다는 이슈를 겪었던 적이 있습니다.

부끄럽지만 그때도 이전 지식에만 의존했던 탓에, 사용된 기술 스택에 대해 충분히 검토하지 않았던 경험이 있었습니다.

이번 Webpack 설정 문제를 겪으면서, 다시 한 번 저의 학습 방식에 대해 돌아보게 되었습니다..!

Webpack 버전을 올린 후에도 다른 작업에 급급해 중요한 변화를 미처 확인하지 않았던 것이 원인이었으니까요.

Allini 프로젝트는 팀원들의 회사 업무로 인해 잠시 중단되었었지만, 다시 시작하게 되었습니다!

현재는 디자이너님이 요청한 수정된 UI를 빠르게 적용하는 것이 우선순위가 높다고 판단하여, 이 부분부터 작업을 진행하고 있습니다. 

그렇기에 Webpack 5 버전에 맞춘 전체적인 설정 수정은 프로젝트가 완성된 후에 진행하기로 결정했습니다.

우선은 프로젝트의 완성도를 높이는 데 집중하고, 작업 중 발생하는 문제들은 하나씩 해결해 나갈 계획입니다.

프로젝트가 마무리되면, CSS 파일을 개별적으로 추출하기 위한 MiniCssExtractPlugin 등의 리팩토링도 진행할 예정입니다.

이 과정에서 작성된 최종 코드도 나중에 블로그에 공유할 예정이니, 기대해 주세요! 💪

React.js와 Next.js 프로젝트를 진행하던 중, 처음 개발 공부를 시작할 때 고민했던 라이브러리와 프레임워크에 대해 다시 한번 정리해보기로 했습니다.

과거에는 이들을 완성된 로봇과 조립형 로봇에 비유하곤 했지만, 지금은 다르게 접근해보려 합니다.

그렇다면 공식 문서부터 확인해 보겠습니다!

공식 문서의 메인 페이지에서조차 "사용자 인터페이스를 만들기 위한 JavaScript 라이브러리" 라는 문구로 우리를 환영하고 있습니다.

그렇다면 수많은 사람들은 도대체 무엇 때문에 혼동하게 된 걸까요?

라이브러리와 프레임워크에 대해 간략히 설명드린 후 "React.js는 라이브러리일까?"  목차에서 다시 한번 정리해 보겠습니다. 

라이브러리와 프레임워크란?

라이브러리

검색 시 쉽게 아래의 내용들을 확인해 보실 수 있습니다.

"특정한 기능을 쉽게 사용할 수 있도록 미리 작성된 코드의 집합"

"개발자가 필요에 따라 라이브러리를 호출하여 사용하는 방식으로, 도구처럼 필요한 부분만 선택적으로 사용"

정리해 보자면, 무언가를 만들 때 유용한 도구 같은 친구네요.

마치 미용실에서 쓰는 도구나 공사 현장에서 쓰는 도구처럼, 특정한 문제를 해결해 주는 기능을 제공해 줍니다.

드라이기로 머리를 말릴 필요는 없지만, 필요하면 사용할 수 있는 것처럼 이런 도구들은 필요에 맞게 골라 쓸 수 있습니다.

프레임워크

라이브러리보다 더 큰 단위의 솔루션을 제공합니다.

라이브러리에서의 예시를 가져와 보겠습니다.

미용실에서 머리를 말리는 방법을 다 정해주고, 그 안에서 정해진 방법을 이용해 머리를 말리는(필요한 로직을 구현하는) 방식입니다.

그래서 Next.js는 React.js를 베이스로 해 웹을 만드는데 필요한 전체적인 해결책을 제공해 줍니다!

React.js와 Next.js의 관계

• React.js는 UI를 선언적으로 만들기 위한 라이브러리로, 필요한 기능을 선택적으로 사용합니다.
• Next.js는 웹 어플리케이션 개발에 필요한 전체적인 솔루션을 제공하며, React를 기반으로 다양한 기능을 포함한 프레임워크입니다.

지금까지 라이브러리, 프레임워크와 React,js, Next.js에 대해 간략히 설명드렸습니다.

이제 본론으로 들어가 보도록 하겠습니다!

React.js는 라이브러리일까?

저는 프레임워크와 라이브러리에 대한 학습에서 "프레임워크 없는 프론트엔드 개발 | 프란세스코 스트라츨로" 교재의,

"프레임워크는 코드를 호출하고 코드는 라이브러리를 호출한다"라는 문구가 가장 와닿았습니다.

교재를 학습하며 해당 문구가 라이브러리와 프레임워크의 차이에 대해 정말 잘 설명하고 있다는 생각이 들었어요.

발췌한 문장을 기반으로 다시 정리하자면,

• 프레임워크는 코드를 호출하여 실행 흐름을 제어합니다.
• 라이브러리는 개발자가 필요한 기능을 호출하여 사용하는 도구입니다.

발췌한 문장을 기반으로 글을 써 내려갈 예정이에요.

참고하여 읽으신다면 좀 더 도움이 되실 거라 생각합니다!

이는 React가 UI 컴포넌트를 만들고 관리하는 데 중점을 두기 때문입니다.

그러나 저를 포함한 많은 개발자들은 React를 프레임워크처럼 사용하고 있습니다.
이유가 뭘까요?

이는 리액트 생태계와 커뮤니티의 강력한 영향력 때문입니다.
React는 UI를 렌더링하는 라이브러리로 시작했지만, 생태계의 발전과 함께 많은 개발자들이 React를 이용해 프레임워크처럼 프로젝트를 구조화하고 있습니다. 

이제 지금까지의 내용을 토대로 실제 개발과정을 예시로 들어 다시 한번 정리해 보도록 할게요!

어떻게 사용해야 될까?

프로젝트를 진행할 때, 프레임워크와 라이브러리의 사용 방식과 목적을 명확히 이해하는 것이 중요합니다.

React를 프레임워크처럼 사용할 때와 라이브러리처럼 사용할 때의 차이를 이해하면 더 나은 선택을 할 수 있습니다.

React를 프레임워크처럼 사용할 때

커뮤니티와 생태계의 영향력

• 리액트는 초기 설정과 구조가 이미 잡혀있는 상태에서 시작하기 때문에 많은 개발자들은 이를 프레임워크처럼 사용하게 됩니다. 예를 들어, npm create-react-app으로 프로젝트를 시작하면 정해진 구조 안에서 개발을 진행하게 됩니다.

컴포넌트 내의 다양한 기능

• 리액트를 사용할 때 컴포넌트에 이벤트 핸들러, 비즈니스 로직, API 호출 등을 모두 포함시킵니다. 이러한 방식은 리액트가 코드를 호출하는 형태로 동작하게 하여 프레임워크처럼 느껴지게 만듭니다.

즉, React 컴포넌트가 모든 실행 흐름을 제어하며, 강한 결합이 발생할 수 있습니다.

장점:

• 빠른 개발 속도: 비즈니스 로직을 리액트 컴포넌트 내부에 통합하여 빠르게 개발할 수 있습니다.
• 코드 구조가 명확하고 일관성이 있습니다.

단점:

• 의존성 증가: 비즈니스 로직이 리액트 컴포넌트에 강하게 결합되어 있어, 리액트를 다른 라이브러리로 대체하기 어렵습니다.
• 이는 향후 마이그레이션 시 큰 비용을 초래할 수 있습니다.

React를 라이브러리처럼 사용할 때

비즈니스 로직과 UI 렌더링을 분리하고, 이 둘을 연결하는 인터페이스를 두는 방법

상태 관리와 UI 업데이트

• 리액트에서 setState를 호출하면 UI가 리렌더링 됩니다. 이 점을 활용하여, setState를 UI를 업데이트하는 요소로 간주하고, UI 업데이트가 필요한 시점에만 setState를 호출하게 합니다.
• 이런식으로 비즈니스 로직은 리액트와 독립적으로 동작하도록 합니다. 이렇게 하면 리액트는 오로지 UI를 렌더링하는 역할만 하게 되며 상태 관리를 최소화할 수 있습니다.

비즈니스 로직 분리

• 비즈니스 로직은 퓨어한 자바스크립트로 작성하여 리액트와 독립적으로 동작하도록 합니다.
• 이를 통해 비즈니스 로직은 UI와 별개로 작동하게 됩니다.

UI 렌더링에만 집중

• 리액트를 순수 UI 렌더링 라이브러리로 사용하려면 비즈니스 로직을 리액트 외부의 순수 자바스크립트 클래스 등의 코드로 분리합니다. 리액트는 오직 데이터를 화면에 렌더링하는 역할만 수행합니다.
• 비즈니스 로직을 담당하는 클래스 등의 자바스크립트 코드로 작성하여, 데이터 처리와 상태 관리를 독립적으로 수행합니다.

인터페이스를 통한 통신

• 비즈니스 로직과 리액트 컴포넌트 간의 데이터 통신(연결)을 담당하는 인터페이스를 설계하여, 상태 변경을 리액트에 전달합니다.
• 이 인터페이스는 비즈니스 로직의 상태 변경을 감지하고, 필요한 시점에 리액트의 setState를 호출하여 UI를 업데이트합니다.

간단한 구현 예시

/**
* 비즈니스 로직 - 순수 자바스크립트 클래스
*/
class BusinessLogic {
  constructor() {
    this.data = null;
    this.listeners = [];
  }

  setData(newData) {
    this.data = newData;
    this.notifyListeners();
  }

  getData() {
    return this.data;
  }

  addListener(listener) {
    this.listeners.push(listener);
  }

  notifyListeners() {
    this.listeners.forEach(listener => listener(this.data));
  }
}

/**
* 리액트 컴포넌트 - UI 렌더링
*/
import React, { useState, useEffect } from 'react';

const TestComp = ({ businessLogic }) => {
  const [data, setData] = useState(businessLogic.getData());

  useEffect(() => {
    const handleDataChange = (newData) => {
      setData(newData);
    };

    businessLogic.addListener(handleDataChange);

    return () => {
      businessLogic.removeListener(handleDataChange);
    };
  }, [businessLogic]);

  return (
    <div>
      <h1>{data}</h1>
    </div>
  );
};

/**
* 비즈니스 로직과 리액트 컴포넌트 사용
*/
const logic = new BusinessLogic();
logic.setData("커피 마시고싶다..");

const App = () => (
  <TestComp businessLogic={logic} />
);

export default App;

장점

• 만약 리액트를 시장에서 더이상 원하지 않게 되거나 새로운 UI 렌더링 라이브러리(예: 스벨트)를 사용하고 싶을 때, 라이브러리처럼 구현했다면 전환이 매우 쉽습니다.
• 비즈니스 로직이 리액트와 독립적이기 때문입니다.

단점

• 실제 사례 드묾: 많은 회사들이 라이브러리처럼 구현하는 방식을 채택하지 않습니다. 이는 개발 비용과 시간이 많이 들기 때문입니다.
• 높은 개발 비용: 비즈니스 로직과 UI를 분리하여 모든 것을 인터페이스로 관리하면 개발 비용이 많이 듭니다. 이렇게 하면 초기 런칭이 어려워질 수 있습니다.

아래에서 좀 더 상세히 저의 생각을 풀어보려 합니다.

위와 중복되는 내용이 있지만 흐름을 위해 그대로 적어보도록 하겠습니다!

기술 부채와 그 관리

저는 기술 부채에 대해 개발 과정에서 단기적인 이익을 위해 장기적인 유지보수 비용을 증가시키는 선택이라고 생각합니다.

그리고 이 기술 부채의 개념은 "React.js의 라이브러리와 프레임워크 방식의 결정"에 도움을 줄 것이라 생각해요!

그래서 지금부터 React를 프레임워크처럼 사용할 때와 라이브러리처럼 사용할 때의 기술 부채를 비교해 보도록 하겠습니다.

프레임워크처럼 사용할 때의 기술 부채

• 강한 결합으로 인해 다른 라이브러리로 전환이 어려워집니다.
• 비즈니스 로직이 React 컴포넌트에 깊이 결합되어 유지보수가 어렵습니다.

라이브러리처럼 사용할 때의 기술 부채

• 초기 개발 비용이 높을 수 있습니다.
• 각 기능이 분리되어 있어 개발 속도가 느려질 수 있습니다.

기술 부채 관리의 중요성

기술 부채를 효과적으로 관리하는 것은 중요합니다.

프로젝트의 요구사항과 일정에 맞게 기술 부채를 잘 조정하면, 장기적으로 더 나은 유지보수와 확장성을 확보할 수 있습니다.

무엇보다 저는 기술 부채가 생겨도 청산만 잘하면 문제가 없다고 생각합니다.

그래서 기술 부채를 잘 내는 것도 저는 중요한 능력이라고 보고있습니다.

개발자가 이쁜 코드만 작성하는 예술가는 아니니까요.

그러니 무언가를 사용할 때 단순하게 정의된 특정 단어나 문장만을 받아들이는 게 아니라 상대적으로 생각하는 습관을 들일 수 있다면 빠른 성장에 유리하지 않을까 생각합니다.

결론

React는 공식적으로 라이브러리이지만, 많은 개발자들이 프레임워크처럼 사용하고 있습니다.

프로젝트의 특성과 요구사항에 따라 React를 어떻게 사용할지 결정하는 것이 중요합니다.

기술 부채를 관리하면서, 프레임워크와 라이브러리의 차이를 이해하고 적절하게 활용하면 성공적인 개발을 이룰 수 있습니다.

상대적으로 사고하고, 상황에 맞는 최선의 선택을 하는 습관을 기르면 더욱 빠르게 성장할 수 있을 것입니다!

여러분들께서 이 글을 읽고 난 후에도, 계속 학습하며 다양한 의견을 접하게 되시겠죠?!

자신들만의 단어로 설명할 수 있게 되고, 개발 방향에 대한 길잡이 역할에 도움이 될 수 있기를 바라며 이만 마치겠습니다.