[Next.JS] getStaticProps를 이용해서 서버 자원을 효율적으로 사용하고, 비용을 절감하기

개요

getStaticProps를 이용하려는 생각은 회사에서 서비스 중인 그룹웨어 메인 페이지를 부분을 개발하면서 시작하게 됩니다.

메인페이지에 접속하게 되면 google api, 전자결재, 조직도, 게시판, 개인정보 등등 수 많은 API를 요청 보내고 있습니다.

여기서 가장 주목했던건 엄청난 양의 데이터가 담긴 조직도 데이터였습니다.

조직도는 그룹웨어 내에 가장 많이 쓰이는 시스템 중 하나로 개선을 한다면 눈에 뛰는 효과가 분명하다고 생각헀습니다.

 

또한 조직도 같은 경우는 자주 변경되지도 않는 데이터인데 사용자가 로그인 할 때마다 데이터를 호출할 필요가 있을까? 라는 생각을 가지게 되었습니다.

물론 서버상태관리 라이브러리인 SWR 덕에 사용자가 최초 메인페이지에 접속했을 경우에만 1번 호출하지만 새로고침을 하거나 재접속을 하여도 굳이 같은 데이터를 받아올 필요가 있을까 하는 생각을 가지게 되었습니다.

 

이전 노션 API를 통해 게시판을 만드는 경험이 있어서 getStaticProps를 통해 정적 데이터를 서버에 들고 있으면서 클라이언트 쪽에 요청이 오면 빌드 시점에 불러온 조직도 데이터를 불러주면 API 요청은 줄이면서 사용자는 미리 불러진 데이터를 통해 더 빠르게 화면을 확인 할 수 있어 사용자 경험 측면에서도 분명 좋을거라 생각했습니다.

SSR vs SSG

프론트엔드 개발을 하시는 분이라면 SSG와 SSR은 많이 들어보셨을겁니다.

간단하게 설명하자면 아래와 같습니다.

SSR (Server-Side Rendering)

• 각 요청마다 서버에서 HTML을 생성합니다.
• 최신 데이터를 제공하므로 실시간 데이터를 반영할 수 있습니다.
• 페이지 요청 시마다 서버에서 처리가 필요하므로 서버 부하가 발생하고, 로드 속도가 느릴 수 있습니다.

SSG (Static Site Generation)

• 빌드 타임에 HTML을 생성하여 정적 파일로 저장합니다.
• 생성된 정적 파일은 서버 요청 없이 클라이언트에게 바로 제공됩니다.
• 초기 페이지 로드 속도가 매우 빠르고, 서버 부하가 적습니다.
• 데이터가 변경될 때마다 빌드가 필요하지만, revalidate 옵션을 통해 특정 간격으로 재생성할 수 있습니다.

getStaticProps vs getServerSideProps

getStaticProps

getStaticProps는 빌드 시 데이터 페칭을 처리하여 정적 생성(static generation)을 가능하게 합니다. 이 메서드는 빌드 타임에 호출되며, 데이터를 미리 가져와 HTML 파일로 생성합니다. 그 결과, 페이지는 빠르고 효율적으로 제공됩니다.

• 콘텐츠가 자주 변경되지 않는 경우
• 블로그 게시물, 마케팅 페이지 등 변경 빈도가 낮은 페이지
• SEO가 중요한 경우
• 빌드 타임에 데이터가 페칭됩니다.
• 데이터를 정적으로 생성하므로 페이지 로드 속도가 빠릅니다.
• 재생성(revalidate)을 설정하여 데이터가 변경될 때마다 정적 페이지를 갱신할 수 있습니다.

getServerSideProps

getServerSideProps는 요청 시마다 서버에서 데이터를 페칭하여 SSR(Server-Side Rendering)을 가능하게 합니다. 이 메서드는 각 요청마다 호출되며, 최신 데이터를 기반으로 HTML을 생성합니다.

• 데이터가 자주 변경되는 경우
• 사용자별 데이터를 처리해야 하는 경우
• 실시간 데이터를 반영해야 하는 경우
• 각 요청 시마다 서버에서 데이터를 페칭합니다.
• 최신 데이터를 제공하므로 실시간 데이터 반영이 가능합니다.
• 페이지 로드 시마다 서버에서 처리되므로 다소 지연될 수 있습니다.

 

getStaticProps:

빌드 타임에 데이터를 페칭하여 정적 페이지를 생성합니다. 페이지 로드 속도가 빠르고 변경 빈도가 낮은 데이터에 적합합니다.

getServerSideProps:

요청 시마다 서버에서 데이터를 페칭하여 최신 데이터를 반영합니다. 변경 빈도가 높거나 사용자별 데이터를 처리해야 할 때 적합합니다.

 

조금 더 쉬운 예로 들자면 아래와 같습니다.

SSR(getServerSideProps) : 매 요청마다 서버가 페이지를 동적으로 생성하고 데이터를 페칭해야 합니다. 100명의 사용자가 동시에 접속하면 100번의 서버 요청이 발생하며, 이는 서버 자원을 많이 소모하게 됩니다.

SSG(getStaticProps) : 페이지가 미리 생성되어 정적 파일로 제공됩니다. 100명의 사용자가 동시에 접속해도 동일한 정적 파일을 받으므로, 추가적인 서버 요청이 거의 없습니다. 이는 서버 비용을 크게 절감합니다.

 

따라서 자주 변하지 않는 정적 데이터라 getStaticProps 를 이용했고 혹시나 변하는 경우 revalidate로 2시간마다 데이터를 업데이트 할 수 있게 처리하였습니다.

export async function getStaticProps() {
  // Fetch data from an API
  const res = await fetch('https://api.example.com/data');
  const data = await res.json();

  return {
    props: {
      data,
    },
    revalidate: 2 * 60 * 60, // Optional: Regenerate the page every 2 hours
  };
}

 

Issue 사항

1. 데이터 페칭 이슈

getStaticProps는 빌드시점에 데이터를 페칭하는 것으로 공식 문서에 나와 있습니다.

콘솔을 찍어봐도 null로 나오는 경우가 있었습니다.

백엔드 쪽 CORS 설정이 어떻게 되어 있는지 확인해보았습니다.

 

스프링 쪽 allowedOrigins 쪽에 모든 경로에 대한 요청을 허용하게 되어 있습니다.

보통 서비스 하는 도메인 경로만 허용하게 되어 있게 설정이 되어 있지만  저희 그룹웨어 특성상 SAP, ERP, IT시스템 등등 수 많은 시스템과 연동이 되어 있어서 일단 모든 요청에 대한 허용을 한 것으로 보였습니다.

 

자사 내부에서 쓰이는 그룹웨어라 외부에 도메인이 노출되진 않았지만 그래도 보안정책과 허용되지 않은 도메인에서 요청이 온다면 어떻게 할까? 생각할 수 있습니다. 이 부분은 아래 적혀 있습니다.

 

그러면 왜 데이터를 빌드 시점에 불러오지를 못 할까??

 

@Controller 쪽 소스를 확인해보니

@AuthenticantionPrincipal을 통해서 Member 정보, 즉 저희 직원 정보가 있어야 요청을 받을 수 있게 처리해놓은 것으로 확인되었습니다.

그래서 빌드 시점에 ADMIN 계정에 대한 정보를 넣어 데이터를 페칭할 수 있게 처리하였습니다.