Migration: CRA To Next.js (feat. React v18)

안녕하세요. 원더월 프론트엔드팀 황호찬입니다.
기존 원더월 프론트엔드 프로젝트는 CSR(CRA) 방식의 웹 페이지였습니다.
최초 생성 시에는 빠른 개발 진행을 위해서, 그 후에는 마이그레이션의 기회 비용이 낮아서 등의 이유로 SSR(Next.js) 도입을 미루고 있었습니다.
이번 글에서는 그런 프론트엔드 원더월 웹 프로젝트에 왜 Next.js를 도입했고, 무엇이 달라졌는지 이야기해보려고 합니다.

Why?

자, 그럼 여태껏 CSR로 방치(?)해놓은 프로젝트에 갑자기 왜 Next.js 도입을 시도하게 되었을까요?

첫 번째로는, 우선 간단한 SEO 처리입니다.
밑에서 설명할 예정이지만, CSR에서의 복잡한 SEO처리를 Next.js에서는 간단히 처리할 수 있다고 생각했습니다.

두 번째 이유는 바로 React 18버전의 정식 출시로 인한 SSR에서의 Suspense 지원이었습니다.
SSR에서의 Suspense를 정식 지원하게 됨으로써, SSR이 갖는 몇가지 문제점들이 해소되었습니다.

이는 Next.js로의 마이그레이션을 진행하기에 충분한 이유였고, 이번 기회에 Next.js 적용과 함께 React18 업데이트 작업을 진행하게 되었습니다.

그래서 뭐가 달라지긴 했나?

1. SEO 처리

CSR 기반의 웹은 기본적으로 SEO 처리가 불가능합니다. CRA로 만든 프로젝트에서 웹 크롤러가 body 태그내부에서 찾아볼수 있는건…

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

실제 내용들이 렌더링될 root 노드 한줄 뿐이기 때문입니다.

이를 해결하기 위해서 기존 프로젝트에서는 AWS CloudFront Lambda@Egde를 통해서 SEO 처리를 하고 있었습니다.
페이지가 변경되거나 생성되면 Lambda@Edge 코드에 해당 페이지에 대한 SEO 처리를 추가/삭제하고 변경된 코드를 다시 CloudFront에 배포하는 과정을 거쳐야 했습니다.

let html = await new S3({signatureVersion: 'v4'})
    .getObject({
        Bucket: stageVariable.Bucket,
        Key: 'index.html'
    })
    .promise()
    .then(value => value.Body.toString());

// html head meta 수정

response.body = html;

return response;

하지만 Next.js를 도입한 후에는 각 페이지에서 getStaticProps 혹은 getServerSideProps에서 SEO 처리를 위한 값을 정의하고, 해당 값을 페이지의 props로 넘기기만 하면 별도 배포 없이도 간단하게 처리할 수 있습니다.

export const getServerSideProps = async ({query}) => {
    const response = await getClass({classId: Number(query.id)});

    if (!response) {
        return {
            redirect: {
                permanent: false,
                destination: Path.Class
            }
        };
    }

    return {
        props: {
            meta: {
                title: response.title
            }
        }
    };
};

<title>{props.meta.title}</title>;

이처럼 설정한 내용이 정상적으로 html에 포함된것을 볼 수 있습니다.

2. 폴더 구조 변경

기존 프로젝트의 폴더 구조는 각 페이지에 해당하는 폴더를 만들고, 그 폴더가 해당 페이지에서 사용하는 모든 요소를 포함하고 있는 구조였습니다.

src/pages/Home
 - index.tsx
 - styles.ts
 - types.ts
 - components
   - HomeBanner
     - index.tsx
   - HomeContents
     - index.tsx
   - ...

하지만 Next.js의 기본 구조는 pages 폴더의 하위 폴더 구조를 기반으로 라우팅을 하는 형식으로, 기존의 폴더 구조를 유지할 수 없었습니다.
이로 인해 폴더 구조 자체를 변경하게 되었고 기존의 페이지별로 내부 요소를 관리하는 구조가 아닌 각 요소 내부에서 페이지 별로 관리하는 구조로 변경하게 되었습니다.

src/
 - pages/home
 - components/home
 - ...

3. react-router에서 next/router로의 변경

CRA 기반의 기존 프로젝트에서는 history 관리를 위해서 react-router 라이브러리를 사용했습니다.
하지만 Next.js에서는 자체적으로 next/router를 지원하여, next/router로의 수정 작업을 진행하였습니다.

둘 사이에 문법과 기존에 지원하던 기능 중, 지원하지 않는 기능이 몇개 있었고
특히 history 객체에서의 몇몇 변수 및 메소드들은 next/router에서 사용법이 다르거나 없는 기능이어서
next/router의 적절한 기능들로 대체하여 처리해야 했습니다.

// v1
history.push('/class');
history.push('/class', {param: 'value'});
history.state; // {param: value}
if (history.action === 'pop');

// v2
router.push('/class');
router.push({pathname: '/class', query: {param: 'value'}});
history.query; // {param: 'value'}
router.beforePopState(() => {});

4. Suspense with SSR

기존의 SSR은 클라이언트에서 HTML을 받아와 렌더링을 진행하고, 하이드레이션을 진행합니다.
이 기능만으로도 충분해 보일수 있지만, 문제는 애플리케이션 전체를 대상으로 처리된다는 것입니다.
데이터가 있을때만 실제 컴포넌트를 보여주고 데이터 패칭이 완료되지 않을때, fallbackUI를 노출하고 싶을때, 데이터의 존재 여부를 파악하여 조건부 렌더링 처리를 진행하고 있었습니다.
하지만 이는 데이터, Javascript, 하이드레이션의 과정을 모두 기다린 후에야 비로소 상호작용이 가능하다는 이슈가 있습니다.

1. Container, Component1, Component2 렌더링
2. Container, Component1, Component2 하이드레이션
3. 사용자 상호작용 가능

//index.tsx
const data = fetch('url');

return (
  <Container>
    <Component1 />
    {data && <Component2 props={data} />}
  </Container>
)

하지만 React18에서 SSR에 Suspense를 지원하게 되면서 위 문제점들을 해결할 수 있었습니다.

1. Container, Component1, Component2 fallbackUI 렌더링
2. Container, Component1 hydration => Container, Component 사용자 상호작용 가능
   +) Component2 렌더링, Component2 하이드레이션

// Component2.tsx
const data = useSWR('url', {suspense: true, revalidateOnMount: true});

// index.tsx
return (
  <Container>
    <Component1 />
    <Suspense fallback={<Loading />}>
      <Component2 />
    </Suspense>
  </Container>
)

기존에 rendering, 하이드레이션을 모두 기다리고 나서야 User 상호작용이 가능했던것과 달리
2번 시점에 사용자가 Component2 영역에 액션을 발생시키면 2번 과정을 거치지 않고 Component2의 렌더링, 하이드레이션을 우선적으로 처리합니다.
또한 Component2의 하이드레이션이 완료되지 않았어도, 다른 컴포넌트에 대한 상호작용이 가능합니다.

이 외에도 서버 사이드에서 window 객체의 부재로 인한 이슈 처리, Layout 컴포넌트 관리 등 수많은 이슈 해결 및 변경이 있었지만 가장 크게 달라진 부분은 이렇게 네가지라고 생각합니다.

이제 남은일은…

이렇게 CRA 기반 CSR 프로젝트(v1)에서 Next.js 기반의 SSR 프로젝트(v2)로의 원더월 프론트엔드 마이그레이션은 끝났습니다!!!
하지만 아직 부족한 부분, 수정해야할 부분이 산더미입니다.
원더월 웹은 꾸준히 업데이트 되고 있고, 마이그레이션을 하는데 있어서 업데이트되고 있는 모든 요소가 포함되어야 합니다.
이에, 팀 내부적으로 논의하여 최소한으로 배포할 수 있는 수준의 코드인 상태로 배포 후, v2에서 추가 개발의 진행 및 꾸준한 리팩토링을 진행하기로 했습니다.

앞으로 v2 버전의 원더월 웹에서는 새로운 기능의 추가 개발과 함께
더욱 SSR 다운, 더욱 React다운 코드로의 리팩토링을 진행할 예정입니다.

다음 글에서는 v2 migration 진행 시, AWS S3 (CSR) 에서 AWS Serverless (SSR) 로의 무중단 배포와
AWS Serverless에서 Vercel로의 배포 플랫폼 변경에 대한 내용을 다루어보려고 합니다. 많은 관심 부탁드립니다!
감사합니다.

참조

• Introducing React 18
• New Suspense SSR Architecture in React 18