AI 타로 서비스를 만들 때 API와의 연동을 클라이언트에서 제어하면 위험할 수 있기 때문에, 서버리스 기능을 사용해보기로 했고 => 서버리스 기능을 제공하는 플랫폼을 이용할 수도 있지만, 그 대신 Next.js의 API Routes 기능을 활용하여 백엔드 관련 기능을 별도의 플랫폼으로 빼는 대신 하나의 프로젝트로 관리하는 아키텍쳐를 적용해보기로 했다

• 추가로, Next.js를 배워서 포트폴리오를 SSG로 바꾸는것도 계획에 있음

그래서 Next.js를 배워볼 것임
어디선가 그러게 남들 다 Next.js 배우고 스터디도 할 때 너도 빨리 하라고 했지?라고 말하는 소리가 들리는 것 같다...

시작하기

먼저 npx create-next-app@latest 명령어로 next 프로젝트를 만들어준다. 프로젝트명은 moonstruck으로 정했음.
그러면 얘가 이런것들을 물어본다.

✔ Would you like to use TypeScript? … No / Yes
✔ Would you like to use ESLint? … No / Yes
✔ Would you like to use Tailwind CSS? … No / Yes
✔ Would you like to use `src/` directory? … No / Yes
✔ Would you like to use App Router? (recommended) … No / Yes
✔ Would you like to customize the default import alias (@/*)? … No / Yes
✔ What import alias would you like configured? … @/*

TypeScript를 쓸 건지, EsLint와 Tailwind CSS를 사용할건지 물어보는 부분은 따로 설명이 필요없을듯
다만 나는 vanilla-extract를 사용할 것이기 때문에 세번째거는 No 선택해줬다

• src/ 디렉토리를 사용할래요? : 이건 사용하는 경우와 사용하지 않는 경우의 예시를 보자.

사용하는 경우
my-nextjs-app/
├── src/
│   ├── pages/
│   ├── components/
│   └── styles/
├── package.json
├── tsconfig.json
└── .env

사용하지 않는 경우
my-nextjs-app/
├── pages/
├── components/
├── styles/
├── package.json
├── tsconfig.json
└── .env

즉, 소스코드 관련 파일들(pages, components, styles 등)을 src 디렉토리로 묶을 건지 물어보는 건데,
지금까지의 경험으로 src 디렉토리로 묶어놓는 게 더 익숙하기도 하고, 규모가 커지는 경우 모든 파일들이 메인 디렉토리에 모여있으면 보기 난잡할 거 같아서 yes를 선택해줬다.

• App Router 쓸거에요?(권장됨) : 이건 기존의 기능인 Pages Router를 쓸 건지, Next.js 13에서 새로 도입된 기능 중 하나인 App Router를 쓸 건지 물어보는거다.
• 간단하게 비교해보자면 아래와 같다.

    Pages Router (기존 방식)
	- 폴더 구조: pages/ 폴더에서 파일을 생성함으로써 URL 라우트를 자동으로 생성하는 방식.
	- 파일 기반 라우팅: 파일 이름이 곧 URL 경로가 됨. pages/index.tsx는 /와 매핑되고, pages/about.tsx는 /about과 매핑됨.
	- 기능: 기존 방식에서는 getServerSideProps, getStaticProps, getInitialProps와 같은 메서드를 사용해 SSR(서버 사이드 렌더링) 및 정적 사이트 생성(SSG)을 처리.
    
	2. App Router (새로운 방식)
	- 폴더 구조: app/ 디렉토리를 사용하여 컴포넌트와 라우트를 구성.
	- React Server Components 지원: 서버에서 렌더링되는 컴포넌트를 기본으로 사용하고, 클라이언트 컴포넌트는 별도로 명시할 수 있음. 더 나은 성능과 유연성을 제공.
	- 폴더 기반 라우팅: app/ 폴더에서 하위 폴더를 생성하면 폴더 이름이 라우트가 됨. 예를 들어, app/about/page.tsx 파일은 /about 경로로 매핑됨.
	- 자동 레이아웃 지원: 특정 폴더에 layout.tsx 파일을 넣으면, 해당 경로에 공통 레이아웃을 자동으로 적용할 수 있음.
	- Server Actions: Next.js 13 App Router는 서버에서 데이터를 처리하는 로직을 컴포넌트와 함께 정의할 수 있는 기능을 제공해, 프론트엔드와 백엔드를 더 유기적으로 연결함.

• 나는 Next.js에 대해 쥐뿔도 모르기 때문에, 최신을 기준으로 배우는 게 더 낫겠다고 생각해서 yes를 골라줬다.

• 또한 내가 필요한 기능 (클라이언트에 환경 변수와 관련 기능들을 노출하지 않고 API와 통신)을 구현하는 데 있어서 App Router가 제공하는 기능들이 더 적합하다고 판단했음

• 경로 별칭을 사용할까요? (@/) : 프로젝트의 루트 경로를 의미하는 경로 별칭(@/)을 사용할건지 물어보는거. 이걸 사용하면 상대 경로를 사용하지 않고 절대 경로처럼 간단하게 파일을 불러올 수 있음 (예: @/components/Header)

• 폴더가 깊어지면 상대 경로를 사용할 때 경로가 매우 복잡해질 수 있는데, 그걸 방지해줌

• 어떤 경로 별칭을 사용할까요? : 경로 별칭을 커스터마이즈할지 물어보는거. 기본값을 유지하면 Next.js 앱의 루트 디렉토리를 @로 지정해서, 프로젝트 내에서 @로 시작하는 경로는 루트 디렉토리를 기준으로 파일을 찾게 됨.

• 원하는대로 커스터마이즈할 수 있음. 예를 들어 src/디렉토리를 기준으로 하고 싶으면 @src/*로 변경할 수 있음.

• @대신 ~나 $ 쓰는것도 가능

• 기본으로 써보자 싶어서 기본 설정을 유지했음

이렇게 초기 설정을 마치고 두근대는 마음으로 매우 오랜만에 npm run dev 명령어를 입력하면 아래와 같은 화면이 뜬다

• 와! 첫걸음을 뗐다! 드디어!

• 이제 스타일링에 사용할 vanilla-extract를 설치해주고, next.config.mjs에 vanilla extract 설정을 추가해준다.

import { VanillaExtractPlugin } from '@vanilla-extract/webpack-plugin';

/** @type {import('next').NextConfig} */
const nextConfig = {
  webpack: (config) => {
    config.plugins.push(new VanillaExtractPlugin());
    return config;
  },
};

export default nextConfig;

• 그리고 globals.css와 pages.module.css를 삭제하고, pages.tsx와 layout.tsx의 내용을 수정하여 Hello World만 띄운 상태로 만들어주기로 함
  
  이게 얼마만의 헬로월드야
• 이제 다음으로 할 일은 Redux-toolkit 초기 설정이다.