**(해당 게시글은 NEXT.JS 15버전을 기준으로 작성되었으며 버전에 따라 내용이 상이할 수 있습니다.)** 글 3줄 요약 1. ‘서버 컴포넌트’는 서버측에서 렌더링 되어 송신되며, 그렇기에 클라이언트(사용자)에게 보여지지 않는 자바스크립트 코드이다. 2. ‘클라이언트 컴포넌트’는 사용자 측에서 실행되어지는 자바스크립트 코드이다. 3. 위 개념만 알고 있어도 Next.js의 80퍼센트는 이해한다 봐도 된다. --- # NEXT.JS에 대해 살펴보기 Next.js는 오늘날 현대적인 웹 애플리케이션 개발을 위해 사용되어지는 웹 `프레임워크` 중 하나이다. 아마 대부분의 사람들은 React를 접한 그 이후에 Next.js를 사용해보기 시작할 것이다(물론 리액트를 몰라도 잘 가르쳐주는 강의도 존재한다). 그 이유는 Next.js는 `React.js의 확장판`이기 때문이다. 그렇기에 React에 대한 이해 없이 Next.js를 하는 것은 말이 되지 않는다(라고 말하지만 필자도 리액트 잘 못한다). React.js도 쉽지 않지만 Next.js의 내용들도 쉬운 것이 없으며, 무엇보다 처음접하게 될 때 방대한 프레임워크 문법들로 인해 길을 잃기가 쉽다(버전 마다 계속해서 변하는 문법들로 혼란이 오는 것도 덤이다). 필자 본인도 Next.js를 혼자 공부하면서 길을 많이 잃었지만 뒤돌이켜 생각해보면 Next.js의 존재 이유에 대해 집중하게 되면 길을 잃지 않고 더 빠르게 공부할 수 있지 않을까 생각하게 된다. 만일 Next.js에 대해서 공부하고자 한다면 Next.js의 무엇이 가장 큰 특징인가에 집중하길 바라며, 그것을 이 글을 통해 한번 살펴보도록 하자. ## React.js와 Next.js는 어떻게 다를까? 앞서, Next.js는 `React.js의 확장판`이라고 한 바 있다. 그 말 그대로 React의 기능 위에 Next.js라는 것을 쌓아 올린 것이다. Next.js는 React의 무엇이 부족하기에 만들어진 것이며 어떻게 다를까? 한번 살펴보자. - *Server Side Rendering(서버 사이드 렌더링)* Next.js의 가장 중요한 특징이라고 할 수 있는 SSR은 서버측에서 페이지를 렌더링하여 사용자(클라이언트)에게 전송해주는 것을 의미한다. 기존의 React를 생각해봤을 때 React는 CSR(클라이언트 사이드 렌더링)으로, 클라이언트에게 페이지 렌더링의 모든 것을 다 주는 것과 마찬가지이다. 초기 페이지 로딩을 위해 모든 파일들을 다 받아야하기 때문에 필연적으로 느려지게 되지만 SSR은 그 페이지에 필요한 파일만을 받아오기 때문에 속도 측면에서 매우 유리하다. - *Static Site Generator(정적 사이트 생성자)와 Search Engine Organization(검색 엔진 최적화)* SSR에 더 이어지는 내용이기도 하다. 말그대로 정적으로 사이트를 생성한다는 의미이며 HTML로 생성하여 사용자에게 전송해준다. HTML에 대해 아는 사람이라면 HTML에서 중요한 것 중 하나는 metadata이다. metadata는 구글과 같은 검색엔진에 검색했을 때 페이지 정보가 나오도록 유도할 수 있다. 그렇다면 Next.js가 페이지마다 HTML로 초기 렌더링을 하여 사용자에게 페이지를 전달해준다면 그 페이지마다 중요한 내용을 metadata로 설정할 수 있을 것이고, 당연히 그렇게 가능하다. 하지만 CSR의 대표 주자인 React는 오직 하나의 html만 가질 수 있으며 그 하나의 html에 페이지를 자바스크립트로 그리기만 할 뿐이기 때문에 페이지마다 SEO 설정이 불가능하다. - *Next.js는 프레임워크, React.js는 라이브러리* 사실 애초에 Next.js와 React.js를 비교하는 건 성립이 되지 않는다. 앞서 말했듯 Next.js는 React 위에 기능을 더 얹은 `확장판`이다. React는 단순히 화면 렌더링에 초점을 맞춘 라이브러리에 불과하지만 Next.js는 그뿐만 아니라 정적 사이트 렌더링, API Route, 이미지 최적화 등등 웹 개발자가 쉽게 개발할 수 있도록 돕는 프레임워크이다. 이러한 점 외에도 Next.js와 React.js가 다른 점은 충분히 존재한다. 필자가 생각하기에는 주요하게 생각해야 할 점은 이 정도일 것이라 판단되며, 이를 곱씹어 본다면 왜 Next.js가 생겨난 것인지 충분히 이해할 수 있으리라 생각한다. ## SSR과 CSR SSR과 CSR에 대한 개념은 Next.js의 존재 근간 그 자체라고도 볼 수 있다. 그렇기 때문에 이곳에서 다시한번 그 차이점을 비교해보며 Next.js에 어떻게 작용하는지 살펴보도록 하자 ### 클라이언트 사이드 렌더링 (CSR) CSR은 React가 기본적으로 사용하는 렌더링 방식으로, 브라우저(클라이언트)에서 모든 렌더링이 이루어진다. 서버는 HTML 껍데기와 JavaScript 파일만 클라이언트로 전달하고, 브라우저는 이를 실행하여 페이지를 렌더링한다. - **장점:** >초기 서버 부하가 적다.
>클라이언트에서만 데이터를 처리하므로 유연성이 높다.
>처음 로딩을 제외하고 그 이후의 웹페이지 사용에서 로딩화면을 경험하지 않아도 된다. - **단점:** >초기 로딩 속도가 느릴 수 있다.
>검색 엔진 최적화(SEO)에 약하다.
### 서버 사이드 렌더링 (SSR) SSR은 브라우저가 요청을 보낼 때마다 서버에서 HTML 페이지를 생성하여 클라이언트로 전달한다. Next.js는 SSR을 통해 초기 로딩 속도와 SEO 문제를 효과적으로 해결한다. - **장점:** >초기 로딩 속도가 빠르다.
>검색 엔진 최적화(SEO)가 용이하다. - **단점:** >요청마다 서버에서 HTML을 생성하므로 서버 부하가 증가할 수 있다. >사용자는 필연적으로 모든 페이지마다 로딩화면을 볼 수 밖에 없다.
사실 CSR과 SSR의 차이점은 다른 곳에서도 많이 찾을 수 있다. 우리가 집중해야 하는 점은 바로 Next.js가 CSR과 SSR을 혼합 사용한다는 점이다. ### CSR과 SSR을 혼합 사용하는 Next.js Next.js는 CSR과 SSR의 장점을 조합하여 두 가지 렌더링 방식을 혼합 사용하는 독특한 구조를 제공한다. SSR을 통해 초기 페이지 로딩 속도와 SEO를 강화하고, CSR을 활용해 동적인 사용자 경험을 제공하여 CSR의 단점과 SSR의 단점을 서로 상쇄시키는 효과를 보여준다(물론 그게 완벽하게 상쇄하진 못하는건 어쩔 수 없다). --- # NEXT.JS 시작하기 서론이 좀 많이 길었다. 하지만 Next.js를 이해하는데 있어 가장 필요하면서 가장 중요한 내용이라 생각하기 때문에 서두에서 강조하였다. 사실상 Next.js의 전부라고 해도 될만큼 중요한 내용이니 배경지식이니 꼭 숙지하여야 한다. ## 프로젝트 생성 일단 프로젝트를 생성해보자. 이 글에서 사용하는 Next.js는 `15.1.5` 버전이며 라우팅 방식으로는 `앱 라우팅`방식으로 사용할 것이다. ``` npx create-next-app@15.1.5 ``` 프로젝트 파일 내에서 터미널에 입력하면 ![generating Next.js](https://code-masterpiece-image-bucket-z2.s3.ap-northeast-2.amazonaws.com/temp/20250118/9d888a59-62b4-4fb1-93f2-4d0f32ba17e6-_____2025-01-18_09-47-58.webp) 다음과 같은 여러 질문들을 한다. - **✅ Typescript:** >자바스크립트에 정적 타입을 추가하여 코드 안정성을 높여주는 자바스크립트의 확장판이다. 지금은 빡빡하게 코드를 검증 할 이유가 없으니 제외. - **✅ ESLint:** >자바스크립트의 문법 오류와 특정 문제를 분석하고 알려주는 코드 분석 도구이다. 위와 같은 이유로 제외. - **✅ Tailwind CSS:** >이미 구성되어있는 CSS 클래스들을 사용하여 빠르게 CSS를 적용시킬 수 있도록 도와주는 라이브러리이다. 굳이 귀찮게 CSS를 사용하진 않을거지만 혹시 사용할 수도 있으니 일단 넣었다. - **✅ src/:** >주요 코드들을 src폴더에 몰아넣게 할건지 물어보는 것이다. 하던말던 자유지만 프로젝트 루트 폴더에는 중요한 설정 파일들이 많기 때문에 난잡하게 폴더를 풀어놓는 것보단 프로젝트의 내용물을 src폴더에 한번 더 정리하는 걸 좋아하니 선택했다. - **✅ App Router:** >앱 라우팅 방식으로 페이지를 설정할 것인지에 대해 물어보는 것이다. 선택하지 않을 시 Next.js에서 이전부터 써왔던 페이지 라우팅 방식으로 프로젝트가 만들어진다. 개인적으로 앱 라우팅 방식이 더 직관적이며 관리가 쉽다고 생각하므로 여기서도 앱 라우팅 방식을 사용할 생각이다. - **✅ Turbopack:** >Vercel에서 개발한 웹 번들러이다. 번들러를 쉽게 설명하자면 여러 조각들을 하나의 박스에 담아놓는 것과 같다. 누군가 그 박스를 달라고 요청하면 그 박스만 주면되기 때문에 속도가 빨라지게 된다. 마찬가지로 웹페이지에대한 요청이 들어왔을때 번들러가 미리 포장한 것을 주면 되기 때문에 응답속도가 빨라진다. 다만 여전히 테스트 단계이기 때문에 본격적인 프로젝트에 도입하는 것은 시기상조이다. 지금같은 테스트 용도로 굳이 사용할 필요는 없겠지만 그렇다고 사용하지 않을 이유도 없기 때문에 사용하도록 하겠다. - **✅ import alias:** >자바스크립트로 import를 사용할 때 절대 경로를 설정함으로써 상대경로 사용하는 것을 피할 수 있는데 만약 `../../../../something/this.jsx` 같은 경로를 보면 벌써부터 어지러워지니 아주 읽기 쉽게 `@/something/this.jsx` 같은 형태로 절대경로를 설정하는 것이 좋다 이때 import 별칭을 @/로 사용할 것인지에 대해 묻는 것인데 no를 누르면 그대로 사용하게 되고 yes를 누르면 별칭을 수정할 수 있다. 바꿔도 되고 안바꿔도 되니 원하는대로 설정하면 된다. --- ![after generation](https://code-masterpiece-image-bucket-z2.s3.ap-northeast-2.amazonaws.com/temp/20250118/fa05106a-1a46-481d-95e9-3a058650669c-image.webp) 프로젝트가 생성되고 나면 다음과 같은 프로젝트들이 생겨나게된다. 일단 터미널에 다음 명령어를 집어넣어 개발자 모드로 웹을 실행시켜보자. ```terminal npm run dev ``` 이러한 명령어는 반드시 `**프로젝트의 루트**` 폴더에서 실행되어야함을 잊지말도록 하자.(위의 사진에서는 `**nextjs-test**`가 루트 폴더이다.)
![main page](https://code-masterpiece-image-bucket-z2.s3.ap-northeast-2.amazonaws.com/temp/20250118/d529e5a2-4d3e-40b2-8ddd-dfd553a87222-image.webp) 실행이되고 `http://localhost:3000`으로 접근하면 위와 같이 페이지가 정상적으로 뜰 것이다.

## 서버 컴포넌트와 클라이언트 컴포넌트 이해하기 글 서두에서 주구장창 떠들었던 것이 적용되는 부분이 바로 이부분이다. Next.js는 앞서 말했듯 CSR과 SSR을 혼합하여 사용하며 이것이 `서버 컴포넌트`와 `클라이언트 컴포넌트`의 형태로 나타난다. ![app folder](https://code-masterpiece-image-bucket-z2.s3.ap-northeast-2.amazonaws.com/temp/20250118/1a108f9d-a8e1-4feb-98af-ffae594857d0-image.webp) 먼저 app폴더로 이동하여 확인해보자 그러면 layout과 page가 있을 것이다(확장자는 중요하지 않다). 앱 라우팅 방식에서는 여러 예약어들이 있으며 layout과 page가 바로 그러한 것들 중 하나이다. 이 예약어들은 반드시 특정 기능이 있기때문에 그러한 목적으로 사용되는 것이 아니라면 네이밍할 시 예약어로 하여서는 안된다. 하지만 그걸 지금 알아보고자 하는 것이 아니니 다음에 앱라우팅의 작동 방식과 예약어들에 대해 정리해보자.
일단 layout으로 이동할 시 다음과 같은 코드를 볼 수 있다. ![](https://code-masterpiece-image-bucket-z2.s3.ap-northeast-2.amazonaws.com/temp/20250118/11bb3310-19a6-42a6-b6af-4b5016b6f671-image.webp) 중간에 metadata가 보이는가? 그리고 하단에 보게 될시 html태그를 볼 수 있겠는데 바로 이것이 서버측에서 전송될 html 레이아웃인셈이다. 그렇다면 이것은 무엇이겠는가? CSR이다. 그리고 Next.js에서는 바로 이것을 `서버 컴포넌트`라고 부르게 된다. 서버 컴포넌트는 따로 명시되지 않으며 근본은 항상 서버컴포넌트에서부터 시작하여 `클라이언트 컴포넌트`가 사용되기 전까지 서버컴포넌트 영역임을 항시 기억하자 --- page.js(혹은 jsx)로 이동하여 내용을 전부 없애고 다음과 같이 하여 프로그래밍 공부 국룰인 Hello부터 띄워보도록 하겠다. ```js import React from 'react'; const Page = () => { return (

Hello Next.js!

); }; export default Page; ``` ![page.jsx](https://code-masterpiece-image-bucket-z2.s3.ap-northeast-2.amazonaws.com/temp/20250118/cba3a4b1-bf10-48fd-9332-9a22cf5e47e2-image.webp) 정상적으로 출력이 된다.

이제 리액트의 기능을 활용하여 버튼을 하나 만들고 버튼을 누르면 글자의 색이 변경되도록 한번 해보고 싶다. 한번 코드를 작성해보자. ```js import React from 'react'; const Page = () => { const [color, setColor] = useState("aqua"); const toggleColor = () => { setColor(color === "aqua" ? "red" : "aqua"); } return (

Hello Next.js!

); }; export default Page; ``` 다음과 같이 코드를 작성하였고 정상작동한다면 클릭시 글자색은 바뀌게 될 것이다 확인해보자.
![csr error](https://code-masterpiece-image-bucket-z2.s3.ap-northeast-2.amazonaws.com/temp/20250118/afa4db5c-04b1-414d-ae62-bf2f438c62eb-image.webp) 다음과 같은 오류를 웹페이지에서 확인할 수 있을 것이다. 오류가 발생한다면 뭐라고 하는지 정확히 읽어보도록하자 >'useState' 훅함수는 클라이언트 컴포넌트에서만 작동한다고 한다. 고치려면 파일에 "use client"를 명시하라라고 적혀있다. 바로 이부분이 SSR의 특징이 나타나는 부분이다.
우리가 이 기능을 똑같이 html과 js로 구현한다고 하면 html에 addEventListener를 연결하여 기능을 구현할 것이다. 그럼 그것이 서버에서 통제되겠는가 웹사용자의 컴퓨터에서 실행이 되겠는가? 당연히 웹사용자측에서 실행이 될 것이다. 그것이 바로 `클라이언트 컴포넌트`의 의미이다. 내가 다른말로 부른다고 하면 클라이언트 측에서 작동할 코드라고 부르고 싶다.
이제 시키는대로 한번 “use client”를 명시해보도록 하자 ```js "use client"; import React from 'react'; const Page = () => { const [color, setColor] = useState("aqua"); const toggleColor = () => { setColor(color === "aqua" ? "red" : "aqua"); } return (

Hello Next.js!

); }; export default Page; ``` 파일의 맨 위에 “use client”라고 설명함으로써 이 쪽의 코드는 사용자 측에서 실행 될거에요~ 라는 것을 선언해주었다. ![csr error solved](https://code-masterpiece-image-bucket-z2.s3.ap-northeast-2.amazonaws.com/temp/20250118/97615955-75da-4453-82c7-a4e531be50a7-image.webp) 그리고 에러는 사라지고 본래 의도하였던대로 코드가 실행되는 것을 확인할 수 있게 된다. 지금의 구조를 생각해보면 `layout(서버 컴포넌트)` - `page(클라이언트 컴포넌트)`의 구조가 된 셈이다.
## 추가 검증하기 서버 컴포넌트는 서버에서만 실행되며 클라이언트 컴포넌트는 클라이언트 측에서만 실행된다. 그렇다면 서버측에서 실행된 코드는 클라이언트 측에서 확인이 불가능하다는 말일까? 확인해 볼 필요가 있을 것 같다. ```js import React from 'react'; import {notFound} from "next/navigation"; const Page = async () => { const fetchPost = async () => { // fetch의 결과물을 캐싱하지 않게하기 위해 no-cache 설정 const response = await fetch('https://jsonplaceholder.typicode.com/posts/1', { cache: "no-cache" }); // fetch 후 3초 뒤에 결과 출력하기 await new Promise((r) => setTimeout(r, 3000)); // 통신 오류시 404페이지로 이동 if (!response.ok) { notFound(); } return response.json(); } // 구조 분해 할당 const {title} = await fetchPost(); return (

{title}

); }; export default Page; ``` 이번엔 page(서버 컴포넌트)에서 [JSONPlaceholder](https://jsonplaceholder.typicode.com/)의 API를 활용하여 1번 포스트를 조회하여 title을 추출한 뒤 출력해보도록 해보자. fetch가 너무빠르면 결과를 예측하기 어려우니 3초뒤에 실행하도록 setTimeout을 설정했다. fetch의 결과물을 캐싱하지 않기 위해 cache를 “no-cache”설정하였다(next.js의 기능). >예상을 먼저 해보자. 현재 page는 서버 컴포넌트이니 페이지를 로딩하기 까지 3초 + a의 시간이 걸릴 것이며 클라이언트 측에서는 웹페이지를 요청한 network 기록 외에는 다른 것을 찾아볼 수 없을 것이다. 또한 fetchPost가 어떻게 실행이 되었는지도 알 방법이 없을 것이다. 과연 그럴까?
![ssr network](https://code-masterpiece-image-bucket-z2.s3.ap-northeast-2.amazonaws.com/temp/20250118/073a6402-51cc-4d23-a1bd-dc6234344dc4-image.webp) (해당 결과는 프로젝트를 빌드한 뒤의 결과이다.) 그리고 결과가 그것을 증명한다. localhost측에 요청을 날린 시간이 3.47정도 되며 클라이언트 측의 fetch 요청 기록을 찾아볼 수 없었다. ![ssr file](https://code-masterpiece-image-bucket-z2.s3.ap-northeast-2.amazonaws.com/temp/20250118/12d817f3-e6ae-40c6-a32e-5bf894b9e9f0-image.webp) 또한 fetchPost함수의 존재를 찾기위해 여기저기 돌아다녀봤지만 찾을 수 없었다. --- 그렇다면 클라이언트 컴포넌트에선 어떨까? ```js "use client" import React, {useEffect, useState} from 'react'; import {useRouter} from "next/navigation"; const Page = () => { const [title, setTitle] = useState(""); const router = useRouter(); useEffect(() => { const fetchPost = async () => { // fetch 후 3초 지연 await new Promise((r) => setTimeout(r, 3000)); // fetch의 결과물을 캐싱하지 않도록 no-cache 설정 const response = await fetch('https://jsonplaceholder.typicode.com/posts/1', { cache: "no-cache" }); // 통신 오류 처리 if (!response.ok) { router.push("/404"); return; } const data = await response.json(); setTitle(data.title); // 가져온 게시글 제목 표시 }; void fetchPost(); }, [router]); return (

{title ?

{title}

}

); }; export default Page; ``` “use client”를 선언함으로써 이 이후부터는 클라이언트 컴포넌트임을 선언하였고 통신 오류 처리라던지 해야되긴 하지만 그것이 당장 중요한 것은 아니니 일단 간단하게 작성해보았다. >역시 여기서도 예상을 먼저 해보자. 이번에는 서버 컴포넌트가 아닌 클라이언트 컴포넌트이다. 즉 서버에게 요청하는 시간은 매우 짧을 것이고 페이지를 불러온 후 클라이언트 측에서 fetch를 실행하게 될테니 클라이언트 측에서 network로 확인이 될 것이다. 어디로 fetch를 날렸는지 확인이 가능할 뿐만 아니라 이것이 어떻게 실행되는지 코드또한 확인이 가능할 것이다. 과연 그럴까? ![csr network](https://code-masterpiece-image-bucket-z2.s3.ap-northeast-2.amazonaws.com/temp/20250118/29a7ed87-f180-4753-ab81-1b45b4dd9899-image.webp) localhost 서버에게 요청한 시간은 15ms인데 반면 모든 페이지를 다 로딩 한 이후로 3초 + a 시간이 지난 뒤에야 비로소 fetch가 실행되는 것을 확인할 수 있다. ![csr file](https://code-masterpiece-image-bucket-z2.s3.ap-northeast-2.amazonaws.com/temp/20250118/cf80997b-b210-4cb3-af7d-c2c46e45e539-image.webp) 그리고 당연하게도 클라이언트 측에서 실행되어야만 하는 코드이므로 어디 서버에 fetch요청을 날렸는지, 어떻게 날렸는지 소스확인이 당연히 가능하다.
fetch를 실행한 위치가 서버 컴포넌트냐 클라이언트 컴포넌트냐의 차이는 상당함을 증명하였다. 작동방식에 차이가 생겼을 뿐만 아니라 코드 보안에 있어서도 영향을 주는 것을 증명하였다. - 서버 컴포넌트에서 fetch를 실행하게 되면 조회된 결과가 서버측에서 처리되어 그것을 하나의 html로 유저에게 전달하는 것이지만 클라이언트 컴포넌트에서 fetch를 실행할시 유저측에서 그 코드를 실행 시키는 것이므로 유저가 그 코드를 실행시킬 수 있고 확인할 수도 있다. - 서버컴포넌트에서 작성한 코드는 유저가 확인할 수 없지만 클라이언트 컴포넌트에서 작성한 코드는 유저가 확인할 수 있음을 증명하였다. # 마치며 이것만으로 Next.js를 이해할 수 있다라고 얘기할 수는 당연히 없다. 그러나 Next.js에서 무언가를 베우던, 무슨 라이브러리를 사용하던, 이 기존 개념에서 벗어나지 않는다. Next.js의 코드들은 무조건 서버 컴포넌트와 클라이언트 컴포넌트 안에서 작동하게 되며 그 코드가 어디에 위치하느냐에 따라 작동방식이 완전히 달라지게 된다. 그렇기 때문에 이 사실만 확실히 알고 있어도 Next.js의 70퍼센트는 이해한다라고 과장 좀 보태서 말할 수 있다. Next.js를 공부하고자 한다면 CSR과 SSR이 어떤 개념인지 다른 글도 읽어보길 바라며 Next.js를 공부하며 꾸준히 머릿속으로 이 코드가 어디서 어떻게 작동하게 될지 상상해보길 바란다.