[Next.js] 서버 사이드 렌더링(SSR)과 cookie 로그인 정보 다루기 (getInitialProps를 사용해도 되는가)

둥둥즈

두둥 프로젝트를 시작하면서 Next.js를 처음 프로젝트에 사용했다. 기획상 이전 프로젝트보다 SEO를 더 신경써야했고, 이미지 최적화와 같은 것들을 자동으로 제공해준다는 점이 좋았다. 이전부터 계속 써보고 싶었던 기술이었어서 공부하면서 프로젝트에 사용할 가치가 있었다. 이번 포스팅은 서버사이드 렌더링 환경에서 카카오 소셜 로그인을 구현하면서 공부했던 내용과 마주쳤던 고민들을 기록한 글이다.

 

목차
1. Next.js의 서버 사이드 렌더링(SSR)
2. 서버 사이드에서 쿠키 사용하기
3. getInitialProps를 사용해도 되는가?

 

 

1. Next.js의 서버 사이드 렌더링

글을 준비하면서 Next.js에서 서버사이드 렌더링의 방식을 조금 더 공부해보았다. 먼저 다들 아는 얘기. Next.js는 SSR을 기반으로 하지만, 페이지가 로드된 이후에는 일반적인 리액트의 CSR을 이용한다. 페이지가 한번 렌더링된 이후에 (axios 등으로) 패치된 데이터들을 보여줄땐 클라이언트쪽에서 다시 렌더링한다.

 

CSR에선 useEffect 를 통해 컴포넌트가 렌더링될때 데이터 패칭을 할 수 있다. 하지만 서버사이드 렌더링을 하는 Next.js에서 컴포넌트는 사전에 불러와야할 데이터가 필요할 수 있다. getInitialProps와 getServerSideProps 등을 이용해 서버에서 데이터를 패칭하고, 반환된 데이터를 사용해 미리 렌더링한다.

 

서버사이드의 흐름은 내가 이해한 바론, 다음과 같다.

 

1. Next 서버에서 Get 요청을 받으면, 요청에 맞는 Page를 찾는다.
2. _app.js의 getInitialProps가 있다면 실행한다.
3. 해당 Page의 getServerSideProps가 있다면 실행한다.
4. pageProps들을 받아와서 정적인 페이지를 생성한다.

 

React는 클라이언트에서 HTML, CSS, 자바스크립트 모두 render() 함수를 이용해 생성한다. 반면, Next.js는 서버에서 HTML을 가져온 후에, 클라이언트에서 자바스크립트 코드와 hydrate 하여 브라우저에 렌더링한다. hydrate() 함수를 이용해 서버에서 받아온 HTML에 번들링된 React 코드들이 한번 더 렌더링 되는 것.

 

 

2. 서버 사이드에서 쿠키 사용하기

두둥에선 카카오 소셜 로그인을 이용하고 있다. 웃긴건 일년도 더 전에 썼던 카카오 로그인 (실패한) 기록이 은근 조회수를 달달하게 먹고 있다. 찾아온 사람들에게 명쾌한 답을 주지 못해서 은근 미안함. 간단하게 흐름만 정리하면 이렇다.

 

1. client가 kakao server에게 인가 코드를 요청한다.
2. 이때 인가 코드는 리다이렉트 url에 쿼리로 전달된다.
   리다이렉트 페이지를 하나 만들어놓고 거기서 코드를 받아 사용할 수 있다.
3. 인가코드를 담아 server로 보낸다.
   server는 그 코드를 kakao server로 보내 카카오의 토큰을 발급받는다.
4. 서버에서 따로 토큰을 발급해 client로 응답을 준다. 자체적으로 유저 정보를 갖고 있기 위함.

 

현재 모노레포를 사용하고 있다. 어드민 레포와 티켓 레포 둘로 나뉘어져 있지만 두 서비스간 이동이 있어도 로그인은 계속 유지되어야 했다. accessToken은 항상 recoil에서 atom으로 관리하고, refreshToken만 cookie에 저장하도록 했다. 새로고침을 하거나 처음 페이지에 들어갈때마다 리프레쉬 로직이 돌아 매번 새로운 accessToken을 받아온다. 하지만 클라이언트에서 렌더링될때 리프레쉬를 해서 보여준다면 약간의 딜레이동안 로그인이 풀린 것처럼 보일 수 있다.

 

이렇게 서버에서 렌더링된 페이지에서부터 로그인 정보가 보여지도록 하고 싶었다. 어드민 서비스로 이동하더라도 로그인이 자연스럽게 유지되는 것 처럼 보일 것 같았다. getInitialProps를 통해 서버사이드에서 전역으로 데이터 패칭을 할 수 있다.

 

pages/_app.tsx

MyApp.getInitialProps = async (context: AppContext) => {
  const { ctx, Component } = context;
  const refreshToken = cookies(ctx).refreshToken;
  let pageProps = {};
  let loginData: OauthLoginResponse | null;
  try {
    const response = await AuthApi.REFRESH(refreshToken!);
    loginData = response;
    ctx.res?.setHeader(
      'set-cookie',
      `refreshToken=${response.refreshToken}; path=/; max-age=${response.refreshTokenAge}`,
    );
  } catch (err: any) {
    loginData = null;
  }

  if (Component.getInitialProps) {
    // Component의 context로 ctx를 넣어주자
    pageProps = await Component.getInitialProps(ctx);
  }
  // return한 값은 해당 컴포넌트의 props로 들어가게 됩니다.
  return { pageProps, loginData };
};

export default MyApp;

refresh 요청에는 refreshToken을 담아서 보낸다. 서버에서는 window와 document 객체를 사용할 수 없기 때문에 로컬스토리지와 document.cookie에서 토큰을 가져오는 방식은 쓸 수 없다. 대신 요청의 쿠키에 들어있는 토큰을 빼오면 서버 사이드에서도 쿠키를 사용할 수 있다.

 

getInitialProps는 context라는 인자를 받는다. context 안에는 req (HTTP 요청 객체)와 res (응답 객체)가 있다. 이를 이용해 서버 사이드에서 cookie를 다룰 수 있다. next-cookies 라이브러리를 사용해 ctx.req에 담긴 쿠키를 쉽게 문자열로 파싱해 가져왔다. refresh로 받아온 데이터들은 컴포넌트의 prop으로 같이 넘겨줄 수 있다.

 

refresh 후에 새로 발급받은 토큰들도 다시 클라이언트의 쿠키로 껴주는 작업도 필요하다. ctx.res의 헤더에 쿠키를 세팅해준다. 이 부분이 없다면 쿠키가 새 토큰으로 업데이트되지 않고 옛날거가 그대로 남아있게 될것이다. refresh 요청이 클라이언트에서 보낸게 아니라 서버에서 보내서 서버로 받은 것이기 때문.

 

흐름을 쉽게 정리하자면, 페이지 요청에 담긴 쿠키를 빼와서 refresh api를 호출하는데 사용하고, 그 새로 받아온 토큰들을 페이지 응답의 헤더에 다시 껴서 브라우저로 보내주는 것이다.

 

interface MyAppProps extends AppProps {
  loginData: OauthLoginResponse | null;
}

function MyApp({ Component, pageProps, loginData }: MyAppProps) {
  const initializer = useMemo(
    () =>
      ({ set }: MutableSnapshot) => {
        if (loginData) {
          const auth = {
            userProfile: loginData.userProfile,
            accessToken: loginData.accessToken,
            isAuthenticated: true,
            callbackUrl: (getCookie('redirectUrl') as string) || '/',
          };
          set(authState, auth);
        }
      },
    [loginData],
  );


  return (
  <...생략>
      <RecoilRoot initializeState={initializer}>
        // ...생략
      </RecoilRoot>
    </...생략>
  );
}

Page로 넘겨준 loginData를 컴포넌트에서 위 코드와 같이 받을 수 있다. 받아온 정보는 리코일의 initializeState를 이용해 바로 세팅했다.

 

개발환경일때 쿠키 등록

staging 서브도메인에 띄워져 있는 서버를 가지고 로컬에서 클라이언트 개발을 진행하고 있다. 서버(staging.dudoong.com)와 로컬 개발환경(localhost)이 도메인이 다르기 때문에 쿠키가 제대로 세팅이 되지 않은 것처럼 보였다. 그냥 평소처럼 클라이언트에서 api 요청을 보낼 때는 크게 문제가 되지 않았다. 개발자도구 애플리케이션에서 확인이 되지 않더라도 실제 요청의 헤더를 살펴보면 쿠키가 제대로 껴져있다.

 

하지만 서버 사이드에서 refresh api를 호출할 때 문제가 생겼다. 직접 ctx.req에서 쿠키를 가져와 세팅해주었기 때문이다. 이 때는 같은 도메인이 아닌 쿠키는 보여지지 않는다. 따라서 개발환경에서 로그인을 했을 때 수행할 작업을 따로 넣어주어야 한다.

 

export const setCredentials = (refresh: OauthLoginResponse) => {
  axiosPrivate.defaults.headers.common[
    'Authorization'
  ] = `Bearer ${refresh.accessToken}`;

  // 개발환경에서 로컬호스트로 쿠키 직접 넣어주기 위함
  if (process.env.NODE_ENV === 'development') {
    setCookie('accessToken', refresh.accessToken, {
      maxAge: refresh.accessTokenAge,
    });
    setCookie('refreshToken', refresh.refreshToken, {
      maxAge: refresh.refreshTokenAge,
    });
  }
};

 

 

3. getInitialProps를 사용해도 되는가?

공식문서를 포함해 많은 글에서 getInitialProps 사용을 권하지 않고 있다. 두둥에서 처음 Next를 사용하면서 공부할때 물론 문서에서 보고 지나갔던 글이었다. 그럼에도 getInitialProps를 사용한건 처음 서비스에 진입할때 무조건 리프레쉬 로직을 돌아 로그인 정보를 받아와야 했기 때문이다. 서비스의 어떤 페이지에서 새로고침했을때도 항상 로그인이 유지되어야 했다.

 

하지만 약간의 공부를 한 뒤에 알게된 문제점들이 있었다.

 

a. 자동 정적 최적화(Automatic Static Optimization) 불가

Next는 빌드타임에 getInitialProps를 사용하지 않는 페이지를 자동으로 pre-render 한다. 다른말로 하면, _app.tsx에서 전역으로 getInitialProps를 적용하게 되면, 모든 페이지가 무조건 서버 사이드 렌더링이 되는것이다.

 

λ  (Server)  server-side renders at runtime (uses getInitialProps or getServerSideProps)
○  (Static)  automatically rendered as static HTML (uses no initial props)

빌드 시에 터미널에 나오는 말이다. pre-render 한다는 것은 정적 HTML파일로 생성되었다는 뜻이다. 실제로 .next/server/static 폴더에 생성된 파일들을 확인해보면 오른쪽의 경우에 정적 HTML파일이 생성된 것을 볼 수 있다 (해당 경로에는 서버에서 사용되는 파일들이 생성된다). getInitialProps가 있는 페이지는 JS파일로 번들링되어 올라간다.

 

(왼) _app.tsx에서 getInitialProps 사용 / (오) 사용하지 않음

하지만 랜딩페이지와 공연 상세페이지와 같이 정적으로 보여줄 수 있는 페이지까지도 항상 SSR을 거쳐야 한다.

 

b. 페이지 이동마다 getInitialProps 실행

getInitialProps는 클라이언트 사이드와 서버 사이드 모두에서 동작한다. 기본적으로 서버 사이드에서 패칭한 데이터를 pageProps로 넘겨 렌더링하는 역할을 한다. 하지만 next/link나 next/router를 이용해 페이지를 이동할 때, 클라이언트 사이드로 getInitialProps가 내려와 작동하게 된다. 그렇게 되면 해당 로직이 불필요하게 앱의 번들에 포함되어 성능에 저하가 생길 수 있다. Next 9버전 이후 getServerSideProps와 getStaticProps로 분리된 이후로는 최대한 사용을 지양하라는 이유이기도 하다.

 

콘솔을 찍고 페이지를 이리저리 이동해보았다. 첫 렌더링시에는 서버에서 실행되고, 그 이후론 브라우저의 콘솔에서 보여진다. 매 페이지 이동마다 getInitialProps가 클라이언트 사이드에서 수행된다는 뜻. getServerSideProps를 사용하는 페이지(주문,결제)가 렌더링될때는 getInitialProps가 먼저 실행된 후에 getServerSideProps가 실행된다.

 

다행히 recoil에 initializeState를 넣는 로직은 라이브러리 내에서 최적화가 되어있는지 최초 1회 외에는 실행되지 않는다.

성능은 그렇다치고, 매 페이지 이동마다 getInitialProps가 실행되어 리프레쉬 요청을 보내게 되는건 내 처음 의도와 전혀 맞지 않았다. 딱 처음 한번만 되어야하는데... 자꾸 터미널 콘솔에 이상한게 찍히길래 이게 뭐지 했었는데 이게 그 이유였다.

 

  try {
    if (ctx.req) {
      const response = await AuthApi.REFRESH(refreshToken!);
      console.log(response.refreshToken);
      loginData = response;
      ctx.res?.setHeader(
        'set-cookie',
        `refreshToken=${response.refreshToken}; path=/; max-age=${response.refreshTokenAge}`,
      );
    } else throw new Error('isClient');
  } catch (err: any) {
    loginData = null;
  }

우선 간단하게 수정해보았다.

ctx.req는 서버 사이드에 있기 때문에, 최초 1회만 실행될 수 있다.

 

 

 

---

 

 

 

https://im-designloper.tistory.com/111

https://www.howdy-mj.me/next/hydrate

https://yeoulcoding.me/266