최근에 [Nuxt](https://nuxt.com/)를 쓸 일이 있어 Nuxt 4 기반 프로젝트를 새로 만들어보았다.
```
npm create nuxt@latest <project-name>
```
원래도 DX가 뛰어난 Vue를 오랜기간 써 왔기 때문에 학습곡선은 거의 0에 가까웠고, Remix 경험이 있어서 디렉토리 기반 라우팅에도 바로 적응했다. 레일즈마냥 워낙 많은 마법이 존재해서 "이게 왜 되지?" 싶은 것들이 좀 있는데, 몇 가지는 다음과 같다.
- `~/app/components` 폴더에 파일을 생성하면 알아서 전역 컴포넌트로 등록되며, 다른 컴포넌트들에서 별도의 import 없이 사용 가능함.
- `~/app/components/course/List.vue` 형태처럼 중간에 디렉토리를 낀 경우, 그것이 자동으로 prefix들이 되어 `<CourseList />`형태로 명명됨.
- `.vue` 파일들 내부에선 `ref`, `computed`, `watch`, `onMounted` 등을 쓰기 위해 `import ... from 'vue'`를 할 필요가 없음. 그냥 글로벌하게 지원됨.
- `~/app/composables/useMyHook.vue` 등으로 composables 폴더 안에 넣은 훅들 역시, `.vue` 파일들에서 별도의 명시적 import 없이 자동으로 접근 가능함.
- `~/app` 폴더 말고, `~/server/api/서버파일들`을 작성하면 기본적으로 동일한 포트(default: 3000)의 `[METHOD] /api/...` 백엔드 호출들을 처리해줌. 이를테면 `~/server/api/me.get.ts`는 `GET /api/me`의 핸들러임. 근데 나는 서버의 경우는 아래처럼 라우트와 핸들러를 직접 정의하는 방식을 선호해서 개인적으로는 불호이고, 프로덕션에서는 다른 포트에 별도 서버를 띄워서 쓸 듯.
```
app.get('api/me', userController.me)
```
그러나 좀 규모가 있는 서버가 아니라 몇 개의 endpoint로 해결 가능한 간단한 프로젝트라면 프론트엔드와 백엔드에서 일부 코드(ex: 타입, 간단한 헬퍼 등)는 공유할 수도 있어서 편리할 듯 하기는 함.
- 내장 함수 중에 `$fetch`가 있는데, 흔히 익숙한 axios 등의 HTTP 클라이언트와 사용법도 거의 동일하니 그냥 이걸 쓰면 된다. 또 `$fetch`를 래핑한 경량(?) tanstack-query 느낌의 `useFetch` 훅도 존재한다.
- `useAsyncData`훅이 있는데, `<script setup>` 내에서 바로 `await useAsyncData(...)` 형태로 사용하면 매우 간단하게 비동기 데이터의 SSR 처리가 가능하다. 브라우저에서 소스보기를 하면 비동기 데이터들이 마크업에 잘 들어가 있는 것을 확인할 수 있다. 원래 이런 SSR을 직접 하려면 프레임워크가 제공하는 `renderToString` 등의 함수를 직접 SSR 서버에서 실행해줘야 하는데, 그런 복잡한 기믹을 이해할 필요가 없으므로 편리하다. ([물론 공부해보는 것은 좋다.](https://blog.coinsect.io/posts/seo-ssr-spa-universal-rendering))
## 결론
새로운 Vue 프로젝트를 진행하고 싶다면 별 고민 없이 그냥 Nuxt로 하면 된다. SSR이나 SEO를 염두해둔 경우라면 당연하고, 그냥 생 SPA로 서비스하는 경우라도 그렇다. Nuxt는 Vue보다 더 opinionated 되어 있고, 커뮤니티의 오랜 고민으로 프로젝트 구조가 좀 더 de facto에 가까워진 형태라 할 수 있으니 그냥 망설임 없이 따라가도 괜찮다고 하겠다.
뿐만 아니라 이젠 느려터진 Webpack은 좀 그만 봤으면 싶은 상황에서 기본 번들러도 Vite이니 더할 나위 없이 좋다.
필자가 선호하는 Vue의 컴포넌트 선언 방식은 [이 글](https://blog.coinsect.io/posts/vue-de-facto-script-setup-typescript)에 적어두었다.