- Next.js를 실행하면 속도가 너무 느려서 기존 webpack 대신 Turbopack 엔진을 사용했다.
React만을 사용할때와 Next 프레임워크를 사용하는 것이 어떤 차이일까?
그리고 Webpack과 Turbopack 차이는 무엇일까?
React는 브라우저에서만 실행되는 라이브러리로, 화면 렌더링은 빠르지만 서버사이드 기능이 없다.
반면 Next.js는 서버렌더링(SSR)과 정적 페이지 생성(SSG), 라우팅, 이미지 최적화 등을 통합해 실제 서비스에 더 적합하지만, 이런 추가 기능 때문에 빌드와 HMR(Hot Module Replacement) 속도가 느려지는 문제가 있다.
이를 해결하기 위해 Next.js 팀이 Rust 기반의 Turbopack 엔진을 도입했고,
기존 Webpack보다 10~20배 빠른 빌드 및 즉각적인 코드 반영(HMR)을 가능하게 했다.
결과적으로 Next.js는 React의 생산성과 서버기능을 모두 갖춘 프레임워크이다.
- Postcss는 무엇인가?
TailwindCSS는 “디자인 규칙집”이고,
PostCSS는 그 규칙을 실제 CSS 코드로 자동 변환해주는 엔진
TailwindCSS는 디자인 규칙을 만들고,
Autoprefixer는 CSS에 브라우저 호환성을 위한 접두사(-webkit-, -moz-)를 자동으로 붙여주는 플러그인이고 보통 TailwindCSS와 같이 사용해서 추가했다.(Next 내부에서 이미 기본값이 내장되어 있고 특정 환경 설정 원하면 package.json의 browserslist 라는 설정으로 기준을 관리)
- ESLint와 Prettier를 간단하게 정리하자면?
ESLint는 코드가 “올바른지” 검사하고, Prettier는 코드가 “보기 좋게” 정리되도록 도와준다.
- App Router와 Pages Router의 차이
Pages Router → 단순, 클라이언트 중심, 옛 방식
App Router → 구조적, 서버 중심, Next.js의 새로운 표준
Next.js에는 두 가지 라우팅 방식이 있다.
예전 버전에서 사용되던 Pages Router와,
Next.js 13 이후 도입된 새로운 시스템인 App Router다.
Pages Router는 pages/ 폴더 안의 파일 이름이 그대로 URL 경로가 되는 단순한 구조를 가지고 있다.
예를 들어 pages/about.tsx 파일을 만들면 /about 페이지가 자동으로 생성된다.
이 방식은 이해하기 쉽고 빠르게 개발할 수 있지만,
모든 페이지마다 Header나 Footer 같은 공통 UI를 반복해서 작성해야 하고,
서버에서 데이터를 불러오거나 에러·로딩 상태를 처리할 때 불편하다.
또한 React의 새로운 기능인 Server Component를 사용할 수 없다는 한계도 있다.
이 한계를 개선하기 위해 등장한 것이 App Router다.
App Router는 app/ 폴더 안에서 폴더 구조 자체가 URL을 결정한다.
예를 들어 app/about/page.tsx는 /about 페이지가 된다.
또한 layout.tsx를 통해 모든 페이지에 공통되는 구조(예: Header, Footer)를 쉽게 적용할 수 있고,
loading.tsx, error.tsx, not-found.tsx 같은 특별한 파일을 만들어
로딩 상태나 에러 페이지를 자동으로 관리할 수 있다.
가장 큰 차이는 렌더링 방식이다.
Pages Router는 대부분 클라이언트 중심(Client Side Rendering) 으로 작동하는 반면, App Router는 서버 중심(Server Component 기반) 으로 동작한다.
즉, 페이지를 그리기 전에 서버에서 데이터를 미리 불러오고 HTML을 만들어 보내기 때문에 속도가 더 빠르고, 검색 엔진 최적화(SEO)에도 유리하다.
또한 React 18의 Streaming 렌더링 기능을 지원해, 페이지의 일부가 먼저 표시되면서 나머지 데이터가 불러와질 때까지 기다리지 않아도 된다.
결국 Pages Router는 간단한 프로젝트나 기존 코드 유지보수에는 여전히 쓸 수 있지만, 새로운 프로젝트라면 App Router가 훨씬 유리하다.
App Router는 구조가 더 체계적이고, 유지보수가 쉽고, 서버 렌더링과 성능 최적화 기능을 자연스럽게 지원하기 때문이다.
- Postmark 연동으로 서버리스 환경에서 이메일 전송하는 원리는?
Postmark API에 “이메일 전송 요청”만 보내면
→ Postmark 서버가 실제 메일을 대신 발송함
- "strict": true의 의미는?
TypeScript의 모든 엄격 모드(예: noImplicitAny, strictNullChecks 등)를 한꺼번에 켜서 모든 타입 검사를 가장 강력하게 수행
- "paths": { "@/": ["./src/"] } 의미는?
폴더 구조가 깊어져도, import 경로를 짧고 보기 쉽게 만들기 위해 사용.
../../../components/Button 같은 복잡한 상대경로 대신
@/components/Button처럼 짧고 명확한 경로로 import 하여 상대경로 지옥을 없애 가독성/리팩터링 내구성 ↑.
paths를 쓰면 보통 "baseUrl": "."도 함께 두는 게 안전하다고 해서 추가함
- "moduleResolution": "bundler" & "module": "esnext" 의미는?
module: esnext는 typeScript가 트랜스파일할 때, 모듈 시스템을 최신 ES 표준 방식(ES Modules) 으로 유지하도록 만드는 옵션
moduleResolution: bundler은 import 경로를 어떻게 해석할지(TypeScript가 모듈을 찾는 방식)를 "번들러 스타일"로 맞추는 옵션
즉, 최신 ESM 방식으로 컴파일하고, 모듈 경로는 번들러 스타일로 찾는 설정
trailingSlash 설정은?
URL 끝에 /(슬래시)를 자동으로 붙여 정적 사이트 경로 문제를 줄이는 옵션
true로 설정하면 항상 /가 붙는 형태로 고정
정적 호스팅(output: "export")에서만 trailingSlash: true가 유리하다
1) 정적 호스팅은 폴더 구조로 페이지를 찾기 때문
정적 호스팅(예: S3, GitHub Pages, Netlify, Vercel export)은 실제 서버가 아니라 그냥 파일들을 그대로 업로드해서 제공하는 방식
예를 들어 about 페이지가 있다면 정적 사이트는 이렇게 생긴다:
/about/index.html
이때 URL이 URL 정적 서버가 찾는 실제 파일
/about/ → /about/index.html ✅ 찾음
/about → /about (파일 없음 → 404 가능) ❌
즉 /about은 폴더가 아니라 “about”이라는 파일을 찾으려 해서 404 에러
그래서 항상 /를 붙여 폴더(index.html)로 인식시키려는 것 → 이것이 trailingSlash: true가 유리한 가장 큰 이유
2) 반면 SSR 서버 환경은 폴더 개념이 아니기 때문
Node 서버나 Next.js 서버 모드(SSR)는 요청이 들어오면 서버가 직접 라우팅해서 페이지를 찾아줌
그래서 /about /about/ 둘 다 똑같이 페이지를 반환할 수 있음 (서버가 알아서 처리)
즉, 정적 호스팅이 아닌 서버 환경에서는 trailingSlash가 필수가 아님 → 성능 차이도 거의 없음.
images: {
unoptimized: true, // Next 이미지 최적화 끄기(정적호스팅시)
} 설정은?
이 또한 정적호스팅시 서버요청이 불가하기 때문에 이미지 최적화를 할 수 없어서 사용하고 정적호스팅이 아닐경우 Next.js가 제공하는 이미지 최적화 기능을 그대로 사용 가능함.
정적 호스팅(정적 export)와 SSG의 차이
SSG는 “빌드 시 HTML을 미리 만드는 렌더링 방식”이고, 정적 Export는 “서버 없이 HTML/JS만 배포하는 결과(배포 방식)”
js.configs.recommended,
...compat.extends('next/core-web-vitals', 'next/typescript') 설정
js.configs.recommended
→ ESLint가 제공하는 기본 자바스크립트 규칙 모음으로 JS 문법 오류나 기본적인 코드 실수를 잡아준다.
예:
next/core-web-vitals<img> 대신 <Image> 컴포넌트 사용 권장<a> 태그 안에 <Link> 중복 금지next/script 사용 방식 검사 등next/typescript
→ TypeScript용 규칙 세트로 TypeScript는 타입 검사기가 있지만,
ESLint가 타입 이외의 코드 스타일/품질 문제를 같이 검사할 수 있게 한다.
예:
추가 설정 항목
no-unused-vars, no-console, eslint-config-prettier
no-unused-vars
사용되지 않은 변수가 있으면 경고 (하지만 빌드 중단 ❌)
no-console
console.log() 있으면 경고만 표시
→"실행은 가능하지만 코드 정리할 때 참고하라"는 정도로 설정
eslint-config-prettier
→ Prettier와 ESLint는 각자 스타일 관련 규칙이 다르기 때문에 충돌이 생길 수 있다.
예:
ESLint: "세미콜론 꼭 써!"
Prettier: "세미콜론 빼!"
이럴 때 eslint-config-prettier가 ESLint의 스타일 관련 규칙을 꺼서 충돌을 막아준다.
→ 역할이 명확하게 분리
"plugins": ["prettier-plugin-tailwindcss"] 설정
Tailwind 클래스 이름을 자동으로 정렬