'react.js' 태그의 글 목록

react.js

React 서버 컴포넌트 심층 분석! 2024.10.22 7
React.js는 라이브러리일까 프레임워크일까 2024.07.02

React 서버 컴포넌트 심층 분석!

ppogeul 2024. 10. 22. 22:07

2024. 10. 22. 22:07

들어가며

최근 Allini 프로젝트를 진행하면서 몇 가지 고민이 생겼습니다.

over-fetching, waterfall 현상으로 인한 성능 저하, 그리고 무엇보다 빠른 시장 검증을 위해 다양한 라이브러리를 활용해야 하는 상황에서 발생하는 번들 사이즈 증가 문제였죠.

좋은 개발자는 단순히 모든 것을 손수 처음부터 구현하는 것이 아니라, 적절한 라이브러리를 선택하고 조잡해 빠르게 제품을 만들어내는 능력이 중요하다고 생각합니다.

하지만 이러한 접근은 필연적으로 번들 사이즈 증가라는 문제를 동반하게 되었고, 이는 제가 React 서버 컴포넌트에 관심을 갖게 된 주된 계기가 되었습니다!

1. React 서버 컴포넌트의 현재 사용 가능 여부

현재 상태

React 18 버전: 서버 컴포넌트 미지원
React 19 RC(Release Candidate): 서버 컴포넌트 지원

하지만 현재 React 18.2.0을 사용중인 프로젝트에서 서버 컴포넌트를 직접 사용하기는 어렵습니다.

React 19로의 업그레이드를 고려해볼 수 있지만, RC 버전이기 때문에 프로덕션 환경에서의 사용은 신중히 결정해야 합니다.

2. SSR과 서버 컴포넌트의 관계

학습 초기에 가장 헷갈렸던 개념입니다!

SSR (Server-Side Rendering)

목적: 초기 페이지 로드 성능 개선 및 SEO 최적화
동작 방식:
- 서버에서 전체 페이지의 초기 HTML을 생성
- 클라이언트로 HTML과 JS 번들을 전송
- 클라이언트에서 hydration 과정을 통해 인터랙티브한 앱으로 전환

이전 React 공식 문서에 따르면, React의 서버 사이드 렌더링 메서드들은 크게 세 가지 환경으로 구분됩니다:

Node.js Streams 환경용:

renderToPipeableStream()
renderToNodeStream() (Deprecated)
renderToStaticNodeStream()

Web Streams 환경용 (브라우저, Deno, modern edge runtimes):

renderToReadableStream()

스트림을 지원하지 않는 환경용:

renderToString()
renderToStaticMarkup()

기존 SSR의 동작 방식은 아래와 같습니다.

// 기존 SSR의 동작 방식
// 1. 서버에서 초기 렌더링
const app = ReactDOMServer.renderToPipeableStream(<App />);
// 한번에 전체 HTML을 생성하여 클라이언트로 전송

// 2. HTML 문서에 삽입
const html = `
  <!doctype html>
  <html>
    <body>
      <div id="root">${app}</div>
      <script src="/bundle.js"></script>
    </body>
  </html>
`;

공식 문서에 따르면, renderToPipeableStream을 통해 초기 셸(shell)을 렌더링하고 전송합니다.

renderToPipeableStream의 기본 개념은 아래와 같습니다.

Node.js 환경에서 React 트리를 HTML 스트림으로 변환하는 API입니다.
점진적인 로딩이 가능한 스트리밍 SSR을 구현할 수 있습니다.

예시 코드

// 발전된 SSR (스트리밍 방식)
const { pipe } = renderToPipeableStream(<App />, {
  bootstrapScripts: ['/main.js'],
  onShellReady() {
    // 1. 먼저 기본 뼈대(shell)를 보냄
    // 초기 shell(Suspense 경계 위의 콘텐츠)이 준비되면 스트리밍 시작

    pipe(response);
  },
  onAllReady() {
    // 모든 콘텐츠가 준비되면 호출 (크롤러나 정적 생성용)
  }
});

기존의 renderToString은 제한적인 기능을 제공하는 반면, renderToPipeableStream은 Suspense를 완전히 지원하고 HTML 스트리밍이 가능한 더 발전된 형태의 SSR 방식입니다.

주요 차이점:

기존 SSR: 모든 데이터를 다 모아서 한번에 보냄 (느림)
새로운 SSR:
1. 먼저 페이지의 기본 뼈대를 보내고
2. 나머지 내용은 준비되는 대로 조금씩 보냄 (더 빠름)

쉽게 말하면, 기존 SSR은 "식당에서 모든 요리가 완성될 때까지 기다렸다가 한번에 서빙"하는 것이고, 새로운 방식은 "준비된 메뉴부터 먼저 서빙하고, 나머지는 완성되는 대로 가져다주는" 것과 비슷합니다.

React 서버 컴포넌트 (RSC)

목적: 번들 사이즈 최적화 및 서버 리소스 직접 접근
동작 방식:
- 특정 컴포넌트를 서버에서만 실행되도록 지정
- 서버에서 렌더링된 결과만 클라이언트로 전송
- JS 번들에 서버 컴포넌트 코드는 미포함

두 기술의 상호보완적 관계

SSR과 서버 컴포넌트는 서로를 대체하는 기술이 아닌, 보완하는 기술입니다:

역할 분담
- SSR: 초기 페이지 로드 시 전체 HTML 생성
- 서버 컴포넌트: 특정 컴포넌트들의 서버 실행 및 번들 크기 최적화

3. 프레임워크들의 서버 컴포넌트 구현

Next.js의 접근

Next.js는 자체적인 서버 컴포넌트 구현을 통해 React의 실험적 기능을 안정적으로 제공합니다.

React 코어 팀과 Next.js 팀의 협력
- React 코어 팀의 주요 멤버들(Joe Savona, Sebastian Markbåge 등)이 Vercel(Next.js)에 합류
- 이를 통해 React의 실험적 기능을 Next.js에서 먼저 안정적으로 구현 가능
서버 컴포넌트의 발전 과정
- 2020년: React 팀이 서버 컴포넌트 개념 첫 발표
- React 18: 서버 컴포넌트 기초 인프라 포함, but 완전한 구현은 아님
- Next.js 13: App Router와 함께 서버 컴포넌트 전면 도입

기술적 구현 방식

React의 Server Components에 대한 공식문서를 보면,

문서에서는 Server Components 구현에 대해 다음과 같이 언급하고 있습니다:

"To support React Server Components as a bundler or framework, we recommend pinning to a specific React version, or using the Canary release. We will continue working with bundlers and frameworks to stabilize the APIs used to implement React Server Components in the future."

이는 Server Components 구현을 위한 번들러 API가 아직 완전히 안정화되지 않았음을 시사합니다.

Next.js는 다음과 같은 방식으로 서버 컴포넌트를 구현했습니다:

// next.config.js
{
  webpack: (config, { isServer }) => {
    if (isServer) {
      // 서버 컴포넌트 처리
      config.plugins.push(new webpack.DefinePlugin({
        // marked, sanitize-html 같은 서버 전용 라이브러리들이
        // 클라이언트 번들에 포함되지 않도록 처리
        'process.env.SERVER_ONLY': JSON.stringify(true)
      }));
      
      config.module.rules.push({
        test: /\.(js|jsx|ts|tsx)$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ['@babel/preset-react'],
            plugins: [
              // async 컴포넌트 지원을 위한 변환
              '@babel/plugin-syntax-top-level-await',
              // Server Component의 import 구문 처리
              ['@babel/plugin-transform-modules-commonjs', {
                importInterop: 'node'
              }]
            ]
          }
        }
      });
    } else {
      // 클라이언트 컴포넌트 처리
      config.module.rules.push({
        test: /\.(js|jsx|ts|tsx)$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ['@babel/preset-react'],
            plugins: [
              // "use client" 지시어가 있는 파일만 클라이언트 번들에 포함
              ['./plugins/client-directive', {}],
              // Server Component의 출력을 클라이언트에서 hydrate하기 위한 변환
              ['./plugins/server-reference', {}]
            ]
          }
        }
      });
    }
    return config;
  }
}

// Server Component 렌더링 함수
async function renderServerComponent(Component, props) {
  // 문서에 언급된 것처럼 build time 또는 request time에 실행 가능
  const stream = await ReactServerDOM.renderToReadableStream(
    <Component {...props} />,
    // 클라이언트 컴포넌트의 번들 정보를 담은 매핑
    webpackMap
  );
  
  // React의 Flight 포맷으로 직렬화
  return encodeRSCPayload(stream);
}

이 구현은 공식 문서의 다음 개념들을 반영합니다:

"Server Components are a new type of Component that renders ahead of time, before bundling, in an environment separate from your client app or SSR server."
- webpack 설정에서 isServer 플래그로 환경을 분리
"Server Components can run once at build time on your CI server, or they can be run for each request using a web server."
- renderServerComponent 함수가 이 두 가지 케이스를 모두 지원
"Async Components are a new feature of Server Components that allow you to await in render."
- 서버 측 babel 설정에 @babel/plugin-syntax-top-level-await 포함

핵심 구현 요소

RSC 포맷
- 서버 컴포넌트의 렌더링 결과를 특별한 포맷으로 직렬화
- JSON이 아닌 특별한 바이너리 형식 사용
- React Flight 아키텍처 활용
번들링 최적화
- 서버 전용 코드를 클라이언트 번들에서 제외
- 클라이언트 컴포넌트만 선택적으로 번들링
스트리밍 지원
- React Suspense와 통합
- 점진적인 페이지 로딩 구현

이해를 위해 기본적인 틀에 맞춰 간소화해 구현해 봤습니다!
혹시 틀린 부분이 있다면 편하게 댓글 주시면 감사하겠습니다!

Remix의 접근

Remix는 라우터 기반의 서버 중심 아키텍처를 채택하여 유사한 이점을 제공합니다.

// Remix의 서버 사이드 로직 예시
export async function loader({ request }) {
  const data = await getProducts();
  return json(data);
}

export default function Products() {
  const products = useLoaderData();
  return (
    <div>
      <h1>Products</h1>
      <ProductList products={products} />
    </div>
  );
}

4. Next.js 앱 라우터와 서버 컴포넌트의 관계

Next.js의 앱 라우터는 서버 컴포넌트를 기본값으로 채택했습니다. 매우 중요한 아키텍처적 결정이죠?!

기본 구조

// app/layout.jsx (서버 컴포넌트)
export default function RootLayout({ children }) {
  return (
    <html>
      <body>{children}</body>
    </html>
  );
}

// app/page.jsx (서버 컴포넌트)
async function Home() {
  const data = await getData(); // 서버에서 직접 데이터 fetch
  
  return (
    <main>
      <h1>Welcome</h1>
      <ClientComponent data={data} />
    </main>
  );
}

// components/client-component.jsx
'use client';

function ClientComponent({ data }) {
  // 클라이언트 사이드 인터랙션이 필요한 컴포넌트
  return <div>{/* 인터랙티브 UI */}</div>;
}

주요 특징

자동 코드 분할

// app/products/page.jsx
import { ProductList } from './components/product-list';

async function ProductsPage() {
  const products = await fetchProducts(); // 서버에서만 실행
  return <ProductList products={products} />;
}

// 이 컴포넌트와 관련된 서버 로직은 클라이언트 번들에 포함되지 않음

스트리밍과 Suspense 통합

// app/dashboard/page.jsx
import { Suspense } from 'react';

export default function Dashboard() {
  return (
    <div>
      <Suspense fallback={<LoadingUI />}>
        <SlowComponent />
      </Suspense>
    </div>
  );
}

마치며

현재 제가 진행 중인 프로젝트에서는 React 18.2.0을 사용하고 있어 서버 컴포넌트를 직접 사용하기는 어려운 상황입니다.

하지만 고객 피드백을 받은 후 Next.js로의 마이그레이션을 고려하고 있으며, 서버 컴포넌트의 이점을 자연스럽게 활용할 수 있는 좋은 기회가 될 것 같습니다.

프로젝트가 커지며, 번들 사이즈 최적화와 서버 리소스 활용 측면에서 큰 이점을 제공할 것으로 기대됩니다!

📃 참고 문헌

React 19 RC!!!

React RFC 깃헙

Next.js App Router RFC 깃헙

Next.js Server Components 공식문서

React Core팀 Dan Abramov의 Server Components 소개 발표

카카오페이 - React Server Components

요즘 IT - React Server Components

freeCodeCamp - React Server Components

'Side Project > Allini - 반려견 음식 관리' 카테고리의 다른 글

PostCSS와 Autoprefixer 웹팩 설정부터 문제 해결까지 (1)	2024.11.01
express-openapi-validator PR 여정기! HTTP 인증 로직 개선 하기 🚀 (11)	2024.10.27
Virtual Scroll: 어떤 상황에서 써야할까? (8)	2024.10.13
실제로 상용 라이브러리에서 버츄얼 스크롤을 어떻게 구현했을까? (0)	2024.10.13
SVG를 컴포넌트처럼 사용하기 위한 Webpack 설정 (4)	2024.10.08

React.js는 라이브러리일까 프레임워크일까

ppogeul 2024. 7. 2. 10:15

2024. 7. 2. 10:15

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

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

시작하기에 앞서 글 제목과 같이 React.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.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를 어떻게 사용할지 결정하는 것이 중요합니다.

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

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

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

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

'CS' 카테고리의 다른 글

Chrome 브라우저 렌더링 - Critical Path 이전 과정은? (0)	2024.03.20

PREV 이전 1 NEXT 다음

Dorong Dorong 💻😴