Next.js 13 개발자를 위한 핵심 질문과 답변 모음

1. Next.js13 스타일링 어떻게 하시나요?

보통 저는 styled-component 를 주로 많이 사용했는데 이번에 app route 방식을 경험해볼겸 사이드플젝 하나 하려하는데 styled-component 는 안되는게 이것저것 많더라구여 다들 어떻게 하고계신가요?? 그리구 현업에서 Next 13 다들 마이그레이션 하시는 분위기인가요?

답변

백수의 의견이라 틀릴 수 있습니다. 훌륭하신 분들이 틀린 부분에 대해 지적해주시면 감사하겠습니다. 특정 CSS-in-JS 라이브러리가 Next 13이 아니라 React 18를 지원하는지가 더 중요합니다. 리액트 진영이 서버 컴포넌트, 동시성 렌더링과 함께 새로운 패러다임으로 넘어왔지만 많은 CSS-in-JS 라이브러리들은 서버 컴포넌트를 제대로 지원하고 있지 않은 것이 가장 큰 문제입니다. 참고로 tailwindcss 는 CSS-in-JS 가 아니기 때문에 이런 이슈에 더 자유롭습니다. 언젠가 styled-components, emotion 가 RSC 를 완벽 지원하는 날이 올 수도 있겠습니다만, 이 라이브러리들은 태생부터 런타임에 스타일을 생성하는 매커니즘을 가지고 있기 때문에 기존의 매커니즘을 바꾸지 않는다면 자잘한 이슈에 자유로울 수 없을 것이라 추측합니다. 대안은 css module, tailwindcss를 사용하시거나, RSC를 지원하는 제로 런타임 CSS-in-JS를 사용하는 것입니다. - pandacss (chakra team) - vanilla-extract 이 두 라이브러리는 stitches와 tailwind에 많은 영감을 받아 제작되었습니다. (그들에게 훌륭한 영감을 남긴 뒤, stitches는 운명하셨습니다.)

2. nextjs 13 getStaticProps 질문

안녕하세요. nextjs 13에서 변경된 app 디렉토리에서는 getStaticProps를 지원하지 않고 fetch의 cache로 getStaticProps 등의 동작을 수행할 수 있게 된 부분에 있어서 의문점이 생겨서 질문 남깁니다. 1. 서버 컴포넌트니까 console등은 서버에서 찍히는 것을 확인하였습니다. 이것은 서버 컴포넌트는 항상 ssr로 동작한다는 의미인것인가요? 2. fetch를 사용하지 않고서는 static, ssr, isr 을 구분시킬 수 없는 건가요? 3. 이전 버전(12)에서는 getStaticProps를 사용해서 fs, gray-matter 같은 static하게 서버에서 생성 해놓기를 원했던 경우에 사용하기도 하였는데 이런 부분은 구현할 수가 없는 건가요? (코드 첨부)

답변

안녕하세요. next.js 베타 문서를 빠르게 훑어보고 와서 답변드립니다. 1. 서버 컴포넌트니까 console등은 서버에서 찍히는 것을 확인하였습니다. 이것은 서버 컴포넌트는 항상 ssr로 동작한다는 의미인것인가요? 네, 서버 컴포넌트는 항상 서버에서 렌더해서 내려줍니다. app 디렉토리라면 서버 컴포넌트가 디폴트로 사용된다고 합니다. - https://beta.nextjs.org/docs/rendering/server-and-client-components#server-components 2. fetch를 사용하지 않고서는 static, ssr, isr 을 구분시킬 수 없는 건가요? 음, 확실하지는 않지만 기존 getStaticProps, getServersideProps 등을 버리고 fetch와 cache 메커니즘을 사용하도록 유도하는 것 같긴합니다. - https://beta.nextjs.org/docs/data-fetching/fetching#static-data-fetching 위 문서 하단으로 내려보시면 "Data fetching without fetch()" 단락을 참고해보시면 될 것 같습니다. 3. 이전 버전(12)에서는 getStaticProps를 사용해서 fs, gray-matter 같은 static하게 서버에서 생성 해놓기를 원했던 경우에 사용하기도 하였는데 이런 부분은 구현할 수가 없는 건가요? 첨부해주신 코드는 서버 파일 시스템에서 데이터 처리 로직을 돌리는 것 같은데, 동일하게 사용 가능할 것 같습니다. getStaticProps에 있는 로직을 컴포넌트 안에서 바로 사용 가능해보여요.

3. Next.js 서버 컴포넌트와 클라이언트 컴포넌트 관련 질문입니다.

입사한지 얼마 안된 신입 프론트엔드 개발자입니다. 회사에서 Next.js를 사용하게 되어 개념을 공부중입니다. Next.js 12까지 사용되던 SSR과 CSR, SSG의 개념은 문서를 뒤져가며 어느정도 이해했다고 생각합니다. 하지만 이번에 Next.js 13 app dir에서 사용되는 서버 컴포넌트(RSC)와 클라이언트 컴포넌트의 개념을 구글링을 통해 며칠동안 알아봐도 이해가 안가는 부분이 많아 겉핥기식으로만 이해가 갑니다. 제가 앞으로 해야할 분야인데 아무리 문서랑 검색을 통해 정보를 찾아봐도 제대로 이해가 가지않아 질문 올려봅니다. 1. 서버 컴포넌트는 서버에서 렌더링이 된다고 이해했는데, 그렇다면 서버 컴포넌트는 db에 직접 접근할 수 있다는 점 외에 SSR과 어떤 차이점이 있는건가요? 2. Next.js13 app dir는 use client를 사용하지 않은 모든 페이지가 서버 컴포넌트라고 알고있는데, 그렇다면 기존 Next.js12에서 지원하던 SSG은 더이상 Next.js13에서 지원하지 않는 건가요? 아니면 서버 컴포넌트랑 SSG는 공존할 수 있는 개념인가요? 3. 기존 Next.js 12에서는 데이터를 fetching해오지 않는 정적인 페이지는 기본적으로 SSG로 작동한다고 알고있습니다. 그렇다면 Next.js 13에서는 기본적으로 모든 컴포넌트가 서버 컴포넌트이니 데이터를 fetching하지 않는 페이지도 서버에서 렌더링이 되는건가요? 4. 클라이언트 컴포넌트에서 서버 컴포넌트를 import해 사용할 수 없다는데.. 저는 잘만 됩니다. 여기서 서버 컴포넌트는 클라이언트 컴포넌트가 된 건가요? 5. 서버 컴포넌트도 SSR처럼 브라우저에서 해당 페이지를 접속했을 때 렌더링이 되고 클라이언트에 내려오나요? 아직 Next.js 이해도가 낮아 질문이 이상할 수 있습니다. 양해 부탁드립니다. 이게 이해가 안가서 스트레스를 너무 받고있네요.. 도와주세요

답변

1. 이 글 한번 정독을 권합니다. https://velog.io/@2ast/React-%EC%84%9C%EB%B2%84-%EC%BB%B4%ED%8F%AC%EB%84%8C%ED%8A%B8React-Server-Component%EC%97%90-%EB%8C%80%ED%95%9C-%EA%B3%A0%EC%B0%B0 2. SSG도 Next App Route에서 지원 됩니다. 대부분 SSG로 껍데기를 만들고(메타태그 넣기 위해..), 내부는 CSR로 구현합니다. 3. 모든 컴포넌트가 서버 컴포넌트인게 아니라, 기본값이 서버 컴포넌트인겁니다. use client 이하는 클라이언트 컴포넌트가 됩니다. 4. 이거 좀 복잡한 부분인데요, 공식문서에 따르면.. https://nextjs.org/docs/getting-started/react-essentials#server-components “You cannot import a Server Component into a Client Component:” 서버 컴포넌트를 클라이언트 컴포넌트에 임포트하는건 불가능합니다. 단, children 형태로 넣는건 됩니다. 아래에 붙여넣은 코드를 참고해보세요. 본인이 import 한게 서버 컴포넌트가 아닐 수도 있습니다. 5번은 잘 모르겠네요.

4. Next 13과 react 18 서버 컴포넌트 관련 질문 (질문이 좀 길어요)

안녕하세요, 요즘 next 13과 react 18 서버 컴포넌트에 대해서 본격적으로 파고 있는데 궁금한 점들이 여러가지 떠올라서 글 올립니다. 1. data fetching 방식의 변경 우선 기존에는 동적인 data fetching의 경우, getServersideProps를 통해서 페이지의 root에 전달해주고는 방식이 일반적이었는데 서버에서만 돌아가는 서버 컴포넌트가 나오면서 data fetching을 컴포넌트 단위로 할 수 있게되면, 기존에 사용하던 getServersideProps 같은 유틸 함수들은 사라지는건가요? 기존에는 정적 데이터면 getStaticProps, 동적 데이터면 getServersideProps, 유저 상호작용이 필요한 데이터면 client side useEffect를 많이 사용했는데 next 13부터는 이게 뭔가 뒤섞이는 것 같아서 혼란스럽네요. next 13을 위한 data fetching 패턴이나 방법론이 있나요? 2. 기존에 사용하던 상태 관리 프레임워크의 변화 위와 어느정도 연결되는 이야기입니다. 기존에 react-query를 많이 사용했는데 next 13부터 컴포넌트 레벨로 데이터를 요청할 수 있고 또 next 차원에서 요청 중복 제거를 지원하게되면 react-query 처럼 서버 상태관리와 캐싱을 강점으로 내세우는 프레임워크의 역할을 어떻게 되는건가요? 서버 상태를 컴포넌트 레벨에서 가져올 수 있다고 해도, 여전히 전역 상태 관리가 필요할 것 같은데 recoil, redux, zustand 같은 상태 관리 프레임워크도 계속 쓰게되는 것일까요? 계속 쓰게 된다고 하면 서버 컴포넌트와의 호환성은 어떻게 되는건가요? 만약 전역 상태 관리를 써야하는 컴포넌트라면 서버 컴포넌트가 될 수 없는 것인가요? 3. 서버 구성의 변경 다른 곳은 모르겠지만, 저는 next 백엔드를 단순히 요청을 전달하는 용도로만 쓰고 실제로 중요한 로직은 다른 백엔드 서버에서 처리하는 구조를 가지고 있었습니다. 하지만, next 13을 보니 서버 컴포넌트에서 DB 연결을 직접해서 데이터를 가져오는 예시들도 있더군요. 사이드 프로젝트라면 모르겠지만, 실 서비스에서도 서버 컴포넌트 - DB 직접 연결 이라는 구조가 성립할 수 있는건가요? 기존에 데이터를 취합하고 내려주던 백엔드 서버의 역할이 생략되는거라고 생각해도 되는건가요? 4. 왜 다시 20년 전으로 돌아가는거죠 제가 20년 동안 개발한 것은 아니지만, 예전에는 웹페이지를 서버에서 완전히 로드해서 내려주는 형태를 가지고 있었다고 배웠습니다. 그러다가 개개인의 기기가 스펙이 좋아지면서 서버 부하를 줄이고 클라이언트 쪽에서 역할을 분담하는 방식이 떴다고 들었어요. react도 처음에는 이런 프레임워크로 나왔다고 알고 있습니다. 그러다가 next, remix 같은 프레임워크들이 서버사이드 렌더링을 적극적으로 장려하면서 다시 회귀하고 있다고 들었습니다. 최근에는 react 마저 서버 컴포넌트를 발표했잖아요. 왜 이제와서 다시 서버 쪽에서 페이지를 로드하는 방식을 추진하고 있는건가요? 질문을 적고보니 좀 길어졌는데, 서핑을 좀 해봐도 마땅히 도움이되는 글이 별로 없어서 현직자들은 어떻게 생각하시는지 의견을 얻고자 질문 올립니다!

답변

1번은 next.js 13버전 app에 대해서 공식문서(베타)를 보시면 없어짐을 아실 수 있습니다. 사실상 컴포넌트가 렌더링 되는 방식이 12에선 페이지 단위였다면 13에선 컴포넌트 단위로 변경되다보니 getStaticProps -> ISR or SSG, getServersideProps -> SSR로 페이지단위 렌더링 방식이 고정되는걸 서버컴포넌트와 클라이언트 컴포넌트로 컴포넌트 단위로 렌더링되는 방식이 변경되었다고 이해하시는게 더 나을거 같아요. 2번은 next.js13부터는 컴포넌트가 만약 상태라는걸 갖고 싶다면 클라이언트 컴포넌트를 사용하도록 강제화하고 있습니다. 서버컴포넌트에서 상태는 결국 디비라고 보시는게 더 편할거 같고 전역상태관리도 결국 top down이 아닌 bottom up 방식으로 변경되어감으로써 리덕스나 주스탄스 같이 정말 어플리케이션 전반에 걸치 상태라는 것은 이제 안쓰고 그 역할을 리액트쿼리 같은 캐싱기반으로 대체될것으로 전 생각하고 잇습니다. 3번은 아시다 싶이 가능이 한다는 것뿐이니 작은 서비스가 아닌 이상 백엔드 서버와 프론트엔드 서버는 분리되어야 관리도 용이하며 대용량 서비스에도 더 적합하기 때문에 next.js에 직접 디비를 연결할 일은 잘 없을것으로 보입니다. 4번은 아래의 deno 블로그에 올라온 글을 읽어보심이 더 좋을거 같습니다. https://deno.com/blog/the-future-and-past-is-server-side-rendering 제가 아는 지식선에서 설명을 드리자면 CSR에서 문제가 되었던 부분은 결국 프론트엔드에서 만드는 어플리케이션이 커짐에 따라서 한 화면을 이루는 번들 자체가 커져서 문제가 되었것으로 기억합니다. 추가적으로 모든 코드를 클라이언트에 돌리다보니 보안적인 문제도 있는것으로 알고 있습니다. 결국 SSR로 돌아온 것을 맞습니다만 jsp시절보다 낫다하는 면은 jsp시절에서는 클라이언트에서 렌더링하는 것 한벌, 서버에서 렌더링하는 것 한벌 짜야했던 점이 이제는 next.js와서 한벌로 가능해졌다는 점이 있고 위에서 설명드린 것처럼 한화면 모두 SSR인 것이 SSR과 SSG의 혼합 등으로 조금 더 나은 렌더링방식을 가져가는 것으로 보입니다.

5. Next.js 13 Vercel로 배포 질문

안녕하세요 이전에 사용한적 없던 Next.js를 이참에 13 버전이 나온 김에 공부를 하고 있습니다 DB의 경우 PlanetScale와 Prisma를 사용하여 같이 사용하고 있습니다 Vercel을 통해 Next.js를 배포한 상태이구요. 혼자 개발 공부용으로 하고있다보니 일단 배포DB와 개발 DB는 동일한걸 사용중입니다 npm run dev로 localhost를 접속하면 DB에 수정된 사항이 새로고침하면 바로 반영이 됩니다 (예시 : DB에 데이터가 4개가 있다가 > 6개로 변경) 하면 바로 반영이 됩니다 그러나 Vercel를 통해 배포한 페이지의 경우 동일한 DB를 사용하고 있으나 변경사항이 즉각 반영이 되지 않습니다, 항상 재 배포를 해야 그때 기준 최신화된 데이터를 가져옵니다 (예시 : DB에 배포 직전까지 데이터가 6개가 있다가 > 배포 후 4개로 변경 > 동일 DB 사용하니 당연히 이거도 반영이 되겠지? > 예상과 달리 데이터가 6개 그대로인 상황이 발생) 배포 버전에서도 DB 최신화된 사항을 그대로 반영시킬려면 어떻게 해야할까요??..

답변

저도 사이드프로젝트를 하다가 똑같은 현상을 겪어서, 아주 공감이 되는 질문이네요 ㅎㅎ 12에서 13으로 넘어가며, 서버 컴포넌트 개념이 추가되고 서버 컴포넌트의 경우 배포 시 정적으로 페이지가 만들어져 빌드 시점에서의 데이터를 기준으로 페이지들이 구성되는데요. https://nextjs.org/docs/app/building-your-application/deploying/static-exports#server-components 이를 해결하기 위해서는 클라이언트 컴포넌트로 만들어 렌더링 시점에 데이터를 가져오는 CSR 또는 서버 컴포넌트 그대로 유지한 상태에서 어느 시점에 기반 데이터를 업데이트 할지 설정해주는 ISR 방식 이렇게 두가지가 있을 것 같아요. (ISR 방식은 저도 아직 적용은 안해봤지만) 서버 컴포넌트의 데이터를 재확인하여, 페이지를 업데이트해주는 ISR(Incremental Static Regeneration) 방식은 공식 문서를 참고해서 적용해보실 수 있을 것 같습니다. https://nextjs.org/docs/app/building-your-application/data-fetching/revalidating