Portfolio

🌈 시작하며

벌써 이제 컴포넌트를 얼추 완성시키고, 페이지를 만들게 됐어요~

저도 지금 처음 만져보는 개발자로서 익숙치는 않지만, 우리가 더 나은 프로젝트를 수행하는 데 있어 필요할 것 같아 글을 남깁니다 😆

⭐ 본론

우리는 다음과 같은 내용을 현 문서에서 톺아볼 거에요.

💡

1. CSR, SSR, SSG가 뭐에요? SSR과 SSG의 차이점은 무엇이죠? 2. 그렇다면, 이를 어떻게 내부에서 구현하죠? 3. 페이지는 어떻게 구성하는 거죠? 4. 페이지에 따른 전역 상태는 어떻게 지정하죠? 5. axios는 어떻게 다뤄야 할까요?

1. CSR, SSR, SSG가 무엇인가요?

💡

우선, 다음 이야기를 한 번 살펴보시죠!

우리가 정보처리기사 시험을 봤다고 생각해볼게요.

우리의 시험 결과는 다음 달에 나오기로 결정이 됐어요. 그런데, 갑자기 당일, 전산에 대한 오류가 생긴 거에요. 그러나 저는 지금 당장 시험 결과를 알아야 해서, 시험 결과를 조회했어요.

하지만, 안타깝게도 조회를 할 수 없었답니다. 왜냐구요? 모든 것은 데이터베이스에서 불러와야 했는데, 데이터베이스가 지금 먹통이거든요.

이게 마치 SSR과 CSR의 차이라고 볼 수 있어요. 현재 조회를 해주는 사람을 검색 봇이라고 생각해봅시다. 그렇다면, 검색 봇은 저희 페이지를 어떻게 분석할 수 있을까요?

💡

검색 봇의 기준은 항상 HTML과 같은 정적 문서, 파일이에요.

SPA(Client Side Rendering)의 한계

그런데, SPA의 한계가 무엇일까요? 바로 HTML은 단지 app만 있다!고 써져 있는 거죠.

클라이언트 사이드 렌더링은 클라이언트에서 모든 내용들을 자바스크립트 코드로 해석해서, 데이터를 불러와서 렌더링 시켜줘요.

따라서 검색 엔진은 아무것도 이를 모르는 상태에요. 응? 문서 하나 있는 애네? 하고 넘긴다는 거죠.

💡

그렇기 때문에 검색 최적화가 불가능하다는 단점이 존재한다는 얘기가 나오는 거에요.

SSR(Server Side Rendering), SSG(Static Site Generation)

대신 이 친구들은 서버에서 불러와요. 즉, 데이터에 대한 맵핑이 서버 측면에 존재하는 거에요.

따라서 서버는 필요한 데이터들을 미리 담을 수 있고, 이를 하나의 정적인 페이지로 담게 되는 거죠. 즉, 위의 예시로 말하자면, 시험 결과를 시험지에 하나하나 다 체크해둔 거에요!

그렇다면 이에 대한 이점은 어떻게 될까요? 시험 담당자(검색 봇)이 해당 학생의 결과를 조회할 때, 바로 알려줄 수 있겠죠? 즉 검색 최적화가 가능해지는 겁니다.

💡

1차적인 요약: 가. 서버사이드 측면에서의 SSR, SSG는 서버에서 페이지를 불러온다. 나. 따라서 검색 봇은 정적인 파일을 토대로 검사하고, 데이터를 체크하여 검색 최적화가 가능해진다.

SSR vs SSG

그럼 우리는 이게 가장 궁금할 거에요. 그래서 둘의 차이는 무엇일까요?

SSR

SSR은 말 그대로 서버 사이드 렌더링이에요. 따라서 언제든지 데이터들을 서버가 계속해서 렌더링하고, 이를 하나의 정적인 페이지로 반환하죠.

SSG

그런데 SSR의 경우, 만약 데이터가 항상 똑같은 내용을 반환하거나, 달라져도 크게 문제가 없는 데이터를 계속해서 렌더링하면 어떨까요? 리소스적으로 꽤나 비효율적이라는 생각이 들지 않나요?

예컨대, 시험 결과는 달라지지 않아요. 따라서 이를 그냥 종이에 채점하면 그만인데, 이를 컴퓨터가 계속 1번부터 n번까지 다시 체크하는 꼴이에요. 따라서 자원이 낭비되는 꼴입니다.

SSG는 이러한 데이터를 빌드 타임 때 아예 데이터를 캐싱해줘버려요. 따라서 응답 속도가 매우 빨라진다는 장점이 존재하는 것이죠!

대신 자주 바뀌는 데이터라면? SSG는 빌드 타임에만 데이터가 캐싱되어 문서를 정적으로 만드므로 적합하지 않겠죠?

💡

요약 SSR은 데이터가 자주 바뀌는 내용물에 적합하다. SSG는 데이터가 자주 바뀌지 않는 내용물(ex: 제품 리스트)에 적합하다.

2. 이를 어떻게 내부에서 구현하죠?

간단합니다. Next.js는 SSR의 이점뿐만 아니라, CSR의 이점을 같이 살리는 방향으로 제작된 프레임워크에요. 따라서 첫 렌더링 당시에만 SSR(SSG), 그 이후부터는 자동으로 CSR을 지원합니다.

Pre-rendering

결국 이렇게 서버 사이드에서 렌더링하는 것과, 정적으로 렌더링하는 것. 크게 두 가지 방법이 있어요. 참고로, 보통 넥스트에서는 정적 생성 방식을 권장합니다. 빠르거든요!

정적 생성 방식

getStaticProps

이를 사용하면 페이지 콘텐츠가, 외부에서 연동이 됩니다.

페이지에서 외부 데이터를 가져올 때 사용하는 함수입니다.

선협님 강의를 보아하니, 여기서 써도 렌더링이 되는 것처럼 보이지만... 현재 제 지식을 기준으로 말씀 드릴 때에는 기존 useEffect로 쓰는 게 더 효율적일 것 같습니다.

💡

왜 CSR 방식으로 쓰는 게 나을 것 같은가요?

공식 문서의 내용을 보아하니, 다음과 같은 내용이 나옵니다.

getStaticPaths

페이지 경로가 외부에서 연동이 된답니다!

`getServerSideProps`

그런데 말이죠, 정적 방식으로 생성하는 것에 대한 큰 문제점이 발생했어요.

왜냐구요?! 정적 방식은 그 순간의 데이터만 기억하게 됩니다. 즉 빌드 시간에서의 데이터만 남게 돼요.

따라서 결국 최신 데이터로 렌더링하지 못하는 상황이 발생하고... 이는 결국 UX 감소에 큰 원인이 됩니다.

따라서, 사람들에게 최신 정보를 전달해줘야 하는 상황이라면, getServerSideProps를 통해 SSR 방식으로 페이지를 렌더링하는 것을 추천합니다.

💡

참고로 getInitialProps는 이제 9버전 이상부터는 권장하지 않습니다. (현재: 11버전)

`ISR`

그래서 사람들은 고민하기 시작했어요.

💡

SSG 빠르고 좋긴한데... 좀 더 유용하게 쓸 수는 없을까?

그도 그럴 것이, SSG로 데이터를 전달해야 하면, 계속해서 빌드를 해야 하는 불편함이 존재하죠.

따라서, 이를 해결한 것이 ISR입니다.

ISR은 SSG를 일정 주기마다 데이터가 변했는지 검사해서, 업데이트를 해주는 방식이에요!

적용방법은 간단합니다. revalidate를 사용해주면 돼요.

그렇다면, 시간마다 데이터가 업데이트 돼서 다시 최신 데이터로 페이지를 만들어준답니다~~

👏🏻 마치며

사실 Next.js는 리액트의 SSR, SSG을 편리하게 하기 위한 프레임워크라고 봐도 무방할 만큼, 해당 내용이 핵심이고, 사실 저게 거의 전부라고 보면 되요!

💡

일단 Next.js에 겁먹기 보다는, 그저 Next.js의 탄생 배경과 철학을 이해한다면, 우리 정말 잘 할 수 있을 거 같아요 😏 이상! 힘내보자구유~ 🌈

SSR vs SSG에 대해 잘 적혀있는 블로그

SSR Naver D2

https://parkgang.github.io/next.js/lets-properly-understand-and-use-the-ssg-of-next.js/

[NEXTJS 간단히 톺아 보기]