Next.js와 SEO에 대한 개발자 Q&A 질문 모음

1. next.js를 실무에서 많이 쓰나요?

안녕하세요, React를 이제 막 시작한 학생입니다. React를 배우다보니 next.js관련 키워드가 많은 것 같더라구요. 커리어리에도 next.js 질문이 많네요. next.js를 실무에서 많이 쓰나요? 만약에 그렇다면 react를 배우기 전에 먼저 next.js를 배우는게 좋을까요? 좀더 효율적으로 공부하고싶은데 고수님들의 답변을 듣고 싶습니다. 감사합니다!

답변

많이 씁니다 react의 framework이라 react 모르고 nextjs응 쓸 수 없으니 react 내공을 키우는데 정진하십쇼!

2. 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의 혼합 등으로 조금 더 나은 렌더링방식을 가져가는 것으로 보입니다.

3. seo가 중요하지 않은 웹서비스 만들 때 react랑 nextjs 중에 뭘 더 추천하시나요?

신입이지만 스타트업이라서, 어쩌다보니 제가 프론트를 리드하게 됐습니다. 웹을 만들어야 하는데 react와 nextjs 중에 고민이 됩니다. react 개발 경험은 있는데, nextjs는 처음이라서요. 어떤 걸 추천하시나요?

답변

안녕하세요. 단순 React (Single Page Application)과 Next.js와 같은 정적 사이트 생성기 혹은 서버 사이드 렌더링에 도움을 주는 프레임워크의 차이점과 장단점을 알고나면 어떤 걸 선택해야 하는지 대충 감이 올 것 같아요. 단순 React (Single Page Application)은 하나의 페이지에서 모든 데이터를 주고 받아요. 사실 페이지 이동처럼 보이게 하는 것도 react-router-dom과 같은 대표적인 라우팅 라이브러리로 사실은 페이지 이동이 아니라 URL이 변경될 때 보여주는 컴포넌트가 달라지는 것 뿐이죠. 실제로 페이지가 이동되어서 다시 html과 javascript를 받아오는 건 아니에요. 그래서 단순 React와 같은 SPA에서는 맨 처음에 유저가 홈페이지에 들어와서 html을 받아오고 나서 css와 javascript(react)를 불러와서 앱을 실행시키면 그 이후에는 우리가 React안에서 작성해놓은 코드로 앱이 동작하게 돼요. 반면에 Next.js와 같은 정적 페이지 생성 프레임워크들은 미리 페이지를 생성해놔요. (HTML을 여러 개 생성해놔요) 그리고 유저가 홈페이지에 들어왔을 때 해당하는 URL의 HTML를 전달해줄뿐이죠. (모든 동작이 다 같다는건 아니에요. SSR, SSG에 따라서 조금 다르긴한데 이건 요기서 다루지 않을게요.) 그래서 React와 같은 SPA에서는 웹 페이지를 불러오고 나서 데이터를 주고 받을 일이 많을 때 조금 더 유리해요. Next.js와 같은 프레임워크는 HTML을 미리 생성해놓는데, HTML을 불러오고 나서 HTML이 많이 바뀔거라면 굳이 미리 생성해놓을 필요가 없는거죠. 그래서 어드민 페이지(단순 텍스트보다 주고 받는 데이터가 훨씬 많음) 혹은 한 페이지에서 모든 일을 처리하는 앱과 같은 경우는 굳이 Next.js와 같은 프레임워크를 사용할 필요가 없을 것 같네요. 반대로 HTML을 많이 생성해놓으면 유리한 앱들이 있어요. 예를들면 블로그나 공식문서와 같은 페이지들은 데이터가 자주 변할 일이 없어요. 거의 같은 HTML을 생성할거라면 굳이 유저가 웹페이지에 들어와서 HTML을 요청할 때 만들어주는게 아니라 미리 다 만들어놓고 만들어놓은 HTML을 단순히 전달해주면 되는거죠. 그리고 Next.js에서는 JavaScript는 실행하지 않는 검색엔진 로봇들에게는(구글봇은 이제는 Javascript도 실행한다고 하지만) HTML이 생성이 되어있어야 해당 HTML을 읽어서 검색엔진에 노출을 시켜주기도해요(SEO). 검색엔진에 노출되지 않아도 되는 앱들도 있어요. 예를들면 회사 내부에서만 쓰이는 웹사이트라던가, 어드민 페이지 같이 내부에서 쓰이는 페이지는 굳이 SEO를 신경쓰지 않아도 되겠죠. 또한 여러가지 프레임워크가 제공해주는 편의성 기능들이 있기도해요. 해당 기능들은 공식문서 ( https://nextjs.org/ )에 가면 조금 더 자세히 알 수 있으니 참고하시면 될 것 같아요. 결론 1. 데이터 교환이 많은 앱인가? (Yes: React, No: Next) 2. 검색엔진노출이 중요한 앱인가? (Yes: Next, No: React) 3. 또한 프레임워크가 제공해주는 여러 기능들이 마음에 들고 공감하는가? => 그럼 사용 위의 것들을 잘 고려하시고, 공식문서도 참고하셔서 잘 저울질 하셔서 선택하시면 될 것 같아요~ 감사합니다!

4. img태그에 alt는 왜 넣어야 하나요?

초보 코린이 프론트엔드 개발자 입니다. img 태그를 사용할 때 alt 속성을 넣지 않으면 아래와 같은 경고가 나오는데요 img elements must have an alt prop, either with meaningful text, or an empty string for decorative images. 왜 alt속성을 넣어줘야 하나요? 어차피 안보이는거... 고수님들 부탁드립니다.

답변

1. 구글 이미지 검색시에 alt 태그가 검색 순위에 영향을 줍니다 2. 윗분 말씀대로 시각장애인 분 대상으로 음성 서비스를 제공할 때 alt 태그를 사용합니다 그러므로 디스크립션이 구체적일 수록 좋은데 예를 들어 "아기" 보다는 "우는 아기"가 더 낫고 그것 보다도 "밥을 달라고 떼쓰며 우는 아기"가 더 낫습니다 링크 참조하세요 https://www.youtube.com/watch?v=dEbl5jvLKGQ (2분 부터) 그런데 db에서 임의의 이미지를 query문으로 불러와 뿌려주는 경우에는 안 넣는 경우도 있습니다 netflix, spotify 들어가셔서 devtools키고 이미지 보시면 alt태그 디스크립션 설명 거의 없습니다

5. next js에서 사용자 검증시 화면 안깜빡거림은 ssr만 가능한가요?

안녕하세요, 리액트 넥스트로 앱을 만드는 개발자 입니다. 사용자 검증을 csr(useEffect), ssr(getServerSideProps)둘 다 해보았습니다. 다만 csr의 경우 완전한 렌더링 이후 검증을 하기에 잠시나마 화면 깜빡임이 있습니다. ssr의 경우 서버에서 검증을 하기에 화면 깜빡임은 없지만 모든 화면에 ssr로직을 작성해야 합니다. 만약 화면 깜빡거림 없이 즉시 사용자 정보 UI를 화면에 나타내려면 SSR이나 getinitialProps를 사용하는 방법밖에 없나요?

답변

안녕하세요! 우선 "완전한 렌더링 이후"의 기준이 뭔지 잘 모르겠어서 "서버사이드에서 내려주는 최초 html이 보여진 후, hydration 이전"라고 가정하고 답변 드리겠습니다. 말씀하신것처럼 CSR에서 외부 서버 요청을 하는 경우, 결과를 받아서 다시 그려줄때까지 시간차가 발생하는데요. 이때 작성된 코드에 따라서 다르지만 깜빡거림이 발생할 수 있습니다. 일반적인 경우라면 깜빡임 보다는 최초 html에서 없던 컴포넌트가 데이터 요청 결과를 받은 후 갑자기 그려지는 현상일 것 같아요. 최초 html에서 없던 컴포넌트가 갑자기 생겨나면 SEO에 안좋은 영향을 줄 수 있기도 하고, 사용자 경험이 좋지 않기 때문에 대부분 해당 위치에 컴포넌트와 동일한 크기의 스켈레톤 (로딩 상태 컴포넌트)를 보여주기도 합니다. (다만, 화면이 깜빡이는 것은 최초 html이 렌더된 뒤 DOM을 버리고 다시 DOM을 만들어서 그려주는 현상인것 같은데 꼭 이럴 필요가 있는지 확인해보시면 좋을 것 같네요) SSR의 경우는 클라이언트로 html을 내려주기 전에 필요한 정보를 요청한 뒤 취합해서 내려주기 때문에 화면 깜빡임이 없는 것 같네요. 질문으로 돌아가보자면, "화면 깜빡거림 없이 즉시 사용자 정보 UI를 화면에 나타내려면" 중 "화면 깜빡거림"을 "컴포넌트만 깜빡거림" 수준까지 격리를 할 수 있다면 스켈레톤을 보여주는 것도 방법인것 같아요. "화면 깜빡거림"이라면 SSR도 나쁘지 않을것 같습니다. 하지만, SSR의 경우 사용자 검증 로직이 돌때까지 클라이언트(사용자)가 흰색 화면을 보게될 시간이 더 길어지겠죠. "완전한 렌더링 이후" === "서버사이드에서 내려주는 최초 html이 보여진 후, hydration 이전"이라면 종현님이 답변해주신 useLayoutEffect를 사용한다고해도 동일하게 화면이 깜빡거릴 것 같습니다. 만약 "완전한 렌더링 이후"의 의미가 "hydration을 거친 후 리액트 렌더 사이클을 한번 거친 html"이라면 useLayoutEffect를 사용해주시면 화면 깜빡거림이 사라질 것 같긴합니다. 간단한 예시를 code sandbox로 만들어보았습니다. https://codesandbox.io/p/sandbox/loving-water-67oc1z?file=%2Fpages%2Findex.tsx 해당 샌드박스의 프리뷰 주소를 새로운 브라우저 탭에서 크롬 데브 툴과 함께 3G 속도로 확인해보시면 될 것 같습니다 :)

6. 구글에 스켈레톤이 아니라 실제 페이지가 색인되도록 하는 방법?

안녕하세요, 최근에 유저 콘텐츠가 많아지면서 이 콘텐츠들이 구글에 잡히도록 작업을 했습니다. 그런데 색인 생성은 잘 되었지만 어떤 검색어를 입력해도 상위에 잘 노출이 되지 않고 효율이 너무 좋지 않아서 살펴보니 크롤러가 스켈레톤만 나오도록 긁어갔더라구요.. site 조건 걸어서 일반 유저가 들어오는 페이지를 확인해 보면 아무 문제 없는데, 왜 스켈레톤이 보이는 페이지만 긁어가는지 모르겠습니다.. 페이지 속도가 너무 느려서 그런 걸까요? 이 문제를 해결할 수 있는 방법을 제안해 주시면 감사하겠습니다 ㅠㅠ

답변

안녕하세요! 질문 내용만으로는 정확한 원인을 찾기 힘들 것 같습니다. 구현이 어떻게 되어있느냐에 따라서 원인이 다 다를 것 같네요. 구글 크롤러 봇의 경우 한 페이지에 머무는 시간은 정해져 있는 것으로 알고 있습니다. 머무는 시간동안 페이지 로딩을 완벽하게 하지 못한다면 질문자님의 인덱싱 결과처럼 스켈레톤만 보이는 페이지가 걸릴수도 있을 것 같아요. 스켈레톤만 보이는 원인은 사실 여러가지여서 코드를 보지않고는 정확한 이유를 찾기 어렵습니다. 질문자님이 예상하시는 "페이지 속도가 너무 느려서"도 이유가 될 수 있고요. 코드 상의 오류로 스켈레톤이 비정상적으로 오래 노출되는 것일 수도 있겠죠. 아니면 서버에서 봇을 차단하고 있는 것일수도 있구요. 일반적으로 SEO를 위해 페이지 색인을 하고 싶으시다면 서버사이드 렌더링으로 미리 데이터를 불러오는 방법을 많이 선택합니다. 서버에서 미리 불러온 데이터를 HTML에 같이 넣어서 브라우저로 내려주는 방식을 택하면, 스켈레톤을 보여줄 필요가 없게되겠죠. 결로은 스켈레톤만 보이게되는 이유를 천천히 찾아보시고 가능하다면 서버사이드 렌더링으로 인덱싱 되길 원하는 데이터를 미리 HTML에 심어 놓는 것을 추천드립니다 :)