안녕하세요. 진짜 오래만에 블로그를 쓰게 되었습니다. 😇
진짜 최근에 너무 바빴는데 가시적인 성과는 딱히 없지만...
그래도 눈에 보이지 않는 것들을 많이 배우고 얻은 시기라고 스스로 위로하며 다시 열심히 공부를 해보려고 합니다.
무얼 공부해야 하나 하다가, (사실 공부할 거를 따지라고 하면 너무너무 많지만 게으른 제가 안 하는 거에요 판사님?!)
Nextjs가 여전히 프론트엔드 개발자들에게는 흥미거리이자, 공부거리이자, 뭐 그런 거라서 Next.js에 대해서 튜토리얼을 만들어보면서 공부를 좀 해보려고 합니다.
What is the Next.js?
nextjs가 뭐냐고 물어보신다면 기계적으로 답을 할 수 있습니다. SSR을 위한 프론트엔드 프레임워크이다. 뭐 이렇게요. 그러면 SSR이 뭔데요? 라고 다시 반문이 들어오면 서버에서 각 라우터에 대한 index.html을 만들어서 클라이언트에서 요청이 오면 해당 index.html을 응답으로 리턴하고, 그 외 DOM 조작이나 이벤트 리스너 추가 등과 같은 실제로 화면을 active하게 만들어주는 imported js는 index.html을 파싱하면서 따로 받아오는 것이죠. (이런 걸 hydrate라고 한다던가? 여담이지만 hydrate라는 단어 자체는 정말 많은 곳에서 쓰이기 때문에 맥락을 같이 봐야 더 이해가 잘 될 것 같습니다.) 여튼 더 깊은 개념은 저도 잘 모르기 때문에 차차 공부를 하면서 알아가 보시죠.
입사 초창기에 vue.js 다음으로 경험했던 프레임워크가 사실 Nextjs입니다. SSR 프로젝트를 진행했었더랬죠. 당시 Next 12 버전을 사용했었고, (사실 해당 프로젝트에서 react query도 처음 썼었습니다. 아마도 3.x 버전이었던 걸로 기억합니다. tanstack query로 통합되기 전의 일입니다.) 회사에서 기억하시는 분들은 많이 없겠지만 정말이지 B2C 해외 진출을 꿈꾸던 그런 신생 프로젝트가 있었습니다.
팀에서는 온갖 최신 기술을 다 갖다가 쓴, 저같은 뉴비에게는 정말 행운이 아닐 수 없는 그런 프로젝트였습니다. (이제는 역사의 뒤안길로 사라졌지만?) 아마도 제 기억이 맞다면 리드 분들께서 프로젝트 시작 시점에 SEO 때문에 Next.js를 선택하셨던 것 같습니다. 해외 유저들에게 잘 노출되는 게 중요한 포인트였기 때문이죠. 하지만 부끄럽게도 당시의 저는 배포 하나 제대로 할 줄 모르는 초짜였고, Next를 쓰면서도 Next의 동작원리라든가 성능 최적화라든가 하는 그런 부분들은 하나도 고민하지 못했었습니다. 2주동안 진행되는 스프린트 내에 요구 받은 기능을 최대한 버그 없이 만들어 내는 게 저의 최대 목표였기 때문입니다. 그랬던 제가 2년 넘게 일을 하면서 많이 성장했고 이제는 팀에서 1.0n 몫을 해낼 수 있게 된 건 정말 기적 같은 일이라고도 할 수 있겠네요.
다시 본론으로 돌아와서 그랬기 때문에 사실 지금은 그 어디서도 사실 Nextjs를 경험해봤다고 말을 하지 못하고 있습니다. 약 4개월 정도 프로젝트를 담당한 이후에는 쭉 vue.js만 썼었고, 해당 프로젝트는 이후 일정 기간 동안 운영되다가 서버도 내려버렸기 때문이죠. 잘 모르고 썼었고, 이제는 진짜 안 쓰고 있으니 아예 해봤다고 말하지 못하는 것 같습니다.
Nextjs는 그래서 뭔가 저에게 여전히 애매모호한 존재입니다.
이마트 시식코너에서 맛만 본 기분이죠.
서론이 길었네요. 그래서 뭘 만들거냐면요. 공식문서에 있는 기능들을 하나씩 가볍게 구현해 볼 계획입니다. 꾸준히 잘 진행해서 이 글이 next 시리즈의 프롤로그가 되면 좋겠네요. 😎
Next.js Main Feature
이런 feature가 있다고 하네요. 다들 잘 아시겠지만, Next.js의 경우에는 우리가 흔히 쓰는 React, Vue와 달리 디렉토리 자체(파일 시스템)로 라우팅이 되기 때문에 라우팅을 위한 라이브러리가 따로 필요하지 않습니다. 기존에는 pages라는 디렉토리 하위에 만든 디렉토리로 라우팅이 되었는데, Next 13에서 beta로 app router가 등장했고 13.4부터 stable 버전으로 app router를 제공했네요. Next 13.4 change log blog
app router의 경우 pages가 아닌 app 디렉토리 하위에 구성한 디렉토리로 라우팅이 되고 layout과 같은 기능도 제공한다고 얼핏 봤는데 실제로 만들어보면서 더 자세하게 살펴 보도록 하겠습니다.
13.2 change log를 보니 SEO 측면에서도 변경된 라우팅의 영향을 받는 것 같습니다. Metadata API가 새로 등장했는데 app router에서만 사용 가능하며 page 라우팅 방식의 head.js를 대체한다고 합니다. :) 13.2 변경점 참고
API Routes vs Route Handlers
Next.js 12를 찍먹하고 떠난 제가 Next.js에 대해 오랜만에 찾아보니 정말 모르는 게 많네요. 그리고 route 방식이 달라졌다는 이야기를 들었을 때는 그냥 단순히 라우팅 시작 디렉토리가 달라졌다고 생각했는데 찾아보면 찾아볼수록 라우팅 방식의 변화가 Next.js에서 사용하는 많은 내장 API들에게 영향을 준 것 같습니다.
Next.js는 서버 사이드 렌더링을 지향하기 때문에 서버에서 동작하는 코드를 작성할 수 있습니다. 각 페이지를 구성하기 위해서 서버 코드를 주로 작성하지만, 가끔은 CORS 에러를 피하기 위해서 서버 쪽 코드에서 외부 API를 호출하는 로직을 짜고 클라 사이드에서 내부 API를 찔러 우회하는 방식을 쓰기도 하죠.
(CORS라는 개념은 브라우저 정책이기 떄문에 서버 <-> 서버 간 API 호출에서는 CORS 에러에서 자유로울 수 있습니다.)
(이제 서버 컴포넌트 라는 개념이 나왔더라고요. 이것도 앞으로 좀 더 공부하면서 자세히 살펴보겠습니다. 예전에는 page 하위 디렉토리에서 getServerSideProps 함수 내에 작성한 코드만 서버 쪽에서 동작하고 나머지는 다 클라 사이드에서 동작하는, 즉 js 파일에 포함되는 코드라고 이해를 했는데 이제는 기본적으로 다 server component인 것 같습니다.)
API Routes는 page 라우팅 방식을 사용하는 경우 페이지 생성 대신 내부 API endpoint를 만들기 위해 사용할 수 있습니다. 설명에서 흥미로운 것은 SSG로 빌드하는 경우에는 해당 API를 못 쓴다고 하는데요. app router의 경우에 동일 기능으로 사용할 수 있는 Route Handler는 SSG로 빌드해서 배포해도 사용이 가능하다고 하네요.(🤔????) 어떻게 이게 가능한 건지는 차차 공부하면서 알아보도록 하겠습니다.
Data Caching
Next.js는 여러 종류의 캐싱이 일어나는 것 같습니다. 기본적으로 제가 아는 캐싱은 브라우저 캐싱(Cache-control, proxy caching, CDN 등)인데요. next.js 내부적으로도 캐싱을 하는 것 같네요. 공식문서에서는 4가지를 소개하고 있는데 퀵하게 훑어봤을 때 client라고 표시되어 있는 Router Cache의 경우는 페이지나 정적 자원들을 요청하는 경우에 발생하는 캐싱인 것 같고 그 외의 캐싱들은 server side, 빌드 타임에 캐싱 여부? 방식이 결정되는 것 같습니다. revalidate 조건도 유저가 (일부)설정할 수 있는 것 같은데 이것도 앞으로 공부하면서 더 살펴 보겠습니다.
바로 tutorial을 만들려고 했는데 공식문서를 읽다보니 모르는 내용이 두 줄의 하나 꼴로 계속 나와서 퀵하게 훑어보게 되었네요.🤪 다음 글에서 진짜로! 한 번 공식 문서를 따라가 보면서 튜토리얼을 만들어 보도록 하겠습니다.
fin.
