왜 React가 아니라 Next.js를 사용하나요?
Frontend 개발자 자격요건
최근 Frontend 개발자 채용공고 자격요건을 들여다보면 어렵지 않게 발견할 수 있는 키워드들이 있다.
HTML, CSS, Javascript, ( React, Vue, Angular ), ES6, 웹표준, 웹접근성, 마크업, Typescript …
회사 입장에서 수월한 인력수급을 위해선 모두가 사용하는 기술스택을 따라하는 것 만큼 좋은게 없을 것이다.
Jquery의 뒤를 이어 표준이 되어버린 React와 어느순간 기본 소양이 되어버린 Typescript, 위에서 적진 않았지만 심심찮게 보이는 테스트코드 작성경험(Jest) 도 빼놓을 수 없다.
물론 회사마다 다른 기술스택을 사용하겠지만 어느 순간부터 아주 빠른 속도로 치고 올라온 키워드가 있으니, 바로 오늘 얘기할 주제인 Next.js 다.
사실 Next.js가 등장한 지는 시간이 꽤나 지났다. 16년 10월에 처음 등장하였으니 React가 공개된 지 3년만에 나온 프레임워크다. ( React가 벌써 11년째인 것도 새삼 놀랍다 )
그런 Next.js가 왜 최근 들어서야 이렇게 가파른 성장세를 보인걸까?
왜 React가 아닌 Next 를 사용해야 하는걸까?
Next의 장점은 SSR을 통한 렌더링 최적화와 SEO최적화 정도 아닌가?
나는 꾸준히 이 문제에 대해서 궁금증을 가지고 있었고, 최근 면접에서 이 질문에 대한 정답을 얻은 것 같아 이 글을 통해 공유하려 한다.
SSR ( Server Side Rendering )
Frontend는 언제나 좋은 사용성(UX)과 빠른 렌더링 사이에서 Trade Off 관계를 가져왔다. 그 과정에서 React가 득세하게 된 이유또한 충분히 브라우저의 성능이 향상되어 정적 HTML파일을 내려받는 것 보다는 느리지만, 클라이언트 사이드에서 렌더링(CSR)을 통해 마치 하나의 어플리케이션을 사용하는 듯 한 UX의 서비스를 충분히 빠르게 제공하고 동시에 컴포넌트 기반 아키텍처를 통해 재사용성을 끌어올려 DX까지 사로잡을 수 있었기 때문이었던 것 같다.
CSR이 득세하던 추세가 줄어들고 최근들어 Next.js 가 주목받게 된 큰 이유 중 하나가 바로 SSR이 아닐까 싶다. SSR의 장점은 크게 두 가지정도 있다.
- 빠른 컨텐츠 렌더링
- SEO 최적화
1. 빠른 컨텐츠 렌더링
첫 번째로 CSR로 전환되기 이전의 HTML파일 내려받는것과 마찬가지로 렌더링이 완료된 파일을 내려받아 그대로 그리기만 하기 때문에 응답속도가 빠르다는 점이다. 최근 몇년 간 CSR에 익숙해져있던 사용자들은 점점 다양한 기능들이 추가되며 한껏 무거워진 CSR을 사용하다가 모든 거품이 빠진 SSR을 다시한번 접한다면 그 빠른 응답속도에 흥미를 느끼는 것은 당연하다.
2. SEO 최적화
SEO최적화의 경우엔 사용자보단 운영측의 큰 장점이다.
기존의 CSR의 경우엔 사용자의 상호작용에 따라 그 구조가 바뀌기 때문에 Search Engine이 어떤 정보를 보여주는 지 알 수 있는 방법이 없었다. 하지만 SSR은 다르다. 서버에서 이미 HTML파일을 구성해서 내려보내기 때문에 Search Bot은 해당 HTML파일을 참조하여, 사용자가 사용하는 많은 정보가 담겨있다고 판단하여 검색결과에서 상단에 노출시켜주는 것이다.
한국의 검색시장 점유율은 10년 전까지만 하더라도 구글의 검색시장 점유율은 1% 대로 다음과 네이버가 양분한 시장이라고 볼 수 있었다. 하지만 다음이 빠르게 저무르고 동시에 구글이 매우 빠르게 다음 사용자 뿐만 아니라 네이버 사용자까지 흡수하며 2020년엔 구글과 네이버의 격차가 겨우 9% 정도로 좁혀졌다.
이 탭의 제목인 SEO은 Search Engine Optimization 즉, 검색엔진 최적화라는 뜻을 가졌지만 실상은 앞에 Google 이라는 글자를 덧붙여야 정확할 것이다. 물론 많은 검색포털이 구글의 Search 알고리즘을 차용하여 구현했을테니 다른 포털에서의 최적화는 덤이다.
다른 포털사이트(네이버)의 경우엔 상단 노출을 위해 막대한 광고비를 지출해야하지만 이미 상당수의 고객이 위치한 구글검색에선 단순히 SSR을 ‘잘’ 사용하는 것 만으로 상단에 위치할 수 있다.
운영측면에서 보자면, 사용자도 만족하는데 광고비까지 자동으로 최소화할 수 있는 솔루션을 채택하지 않을 이유가 없다.
Next.js (SSR) 의 한계 (였던 것)
우리는 앞서 풍부한 사용자 인터랙션을 통한 UX를 가진 CSR과 빠른 응답속도와 SEO최적화라는 장점을 가진 SSR에 대해서 짧게 알아봤다.
SSR을 주요기능으로 가졌‘던’ Next.js 는 React를 대체할 매력적인 새로운 옵션이 될 수 없었다. SSR이 가진 장점만으론 여전히 React로의 전환 때 이루어진 사용자 인터랙션이라는 UX를 보완할 수 없기 때문이다.
하지만 작년 13.4 버전 이후 Next.js 에 ‘use client’ 라는 새로운 기능이 추가된다.
use client
간단하게 요약하자면 Next.js 가 SSR 뿐만 아니라 CSR 도 지원하는 기능이 탑재된 것이다.
따라서 개발자는 원하는 부분은 SSR로, 사용자 인터랙션을 원하는 부분은 CSR로 구현할 수 있다. Next.js 의 유일한 단점이었던 사용자 인터랙션을 활용할 수 있게 된 것이다.
헤더, 푸터, Navbar와 같이 고정 레이아웃은 SSR로 그리고 사용자 인터랙션이 필요한 주요서비스는 CSR로 구현하여 사용자에겐 빠르게 무언가 그려내서 보여주고, CSR 컨텐츠는 조금 느리게나마 제공해서 인터랙션을 구현한다. 말 그대로 두 마리 토끼를 다 잡을 수 있게 되었다.
동시에 SEO 최적화를 통한 검색 상단노출과 광고비 절감은 덤이다.
Why React?
React는 Javascript 라이브러리다. 즉, JS 코드에서 어디서든 React코드를 가져와서 사용할 수 있다는 뜻이다.
사실 ReactDOM을 script Root Element로 사용하는 만큼 거의 프레임워크에 가깝지만 아무튼 라이브러리다.
당신에게 누군가 왜 리액트를 사용하느냐고 물어본다면 뭐라고 답할 것 같은가?
Vanilla JS 로 개발을 해 본 경험이 있다면 느꼈을 이벤트리스너 핸들링과 변수선언의 불편함을 매우 간편하게 관리해주고 비즈니스로직에 집중할 수 있기 때문이 아닐까 싶다.
따라서 요약하자면 Vanilla JS로도 모든것을 구현할 수 있지만, 더 간편하게 중요한 비즈니스로직에만 집중할 수 있기 때문에 React를 사용한다고 할 수 있을 것 같다.
즉, 사용하지 않을 이유가 없다.
Why Next.js?
Next.js는 React 의 프레임워크다. 즉, 라이브러리처럼 끌어다 쓴다기 보다는 Next.js 라는 바탕 위에서 React를 사용한다고 보면 될 것 같다.
그럼 마지막으로 Next를 사용해야하는 이유는 뭘까?
Vanilla JS가 아닌 React를 사용하는 이유와 마찬가지로 Next를 사용하지 않을 이유가 없기 때문이다.
내가 생각했던 ‘Next의 장점은 SSR을 통한 렌더링 최적화와 SEO최적화 정도 아닌가?’ 라는 질문은 ‘use Client’를 절반만 알고 있었기에 생긴 질문이었다.
SSR의 단점이었던 사용자 인터랙션도 ‘use client’ 키워드를 통해 지원하고, 동시에 SSR의 모든 장점을 갖는데 CSR의 React(물론 최근에 SSR을 지원하긴 한다)사용을 고집할 이유가 없다는 결론이다.
맺으며
개인적인 생각으로는, 아마도 Next 또한 새로운 표준이 될 가능성이 높아보인다. Remix나 qwik 과 같은 대체제가 있지만 시장을 이미 선점하고 있는 Next를 밀어내기 위해선 뒤처진 시간을 상쇄할만큼의 엄청난 기술적 혁신이 없다면 어렵다고 본다.
이 답변을 준 회사 면접에선 떨어졌다. 하지만 그간 가지고있던 질문에 마침표를 찍을 수 있는 시간이었기에 아쉬움은 없다.