Git 전체 명령어를 외울 필요는 없습니다. 이 글은 Next.js, Spring 등으로 개발할 때 실제로 자주 쓰이는 최소한의 Git 명령어만 모아서 정리한 글입니다. status, diff, add/commit, 브랜치, 리모트, 되돌리기, stash 위주로 다룹니다.

• clone 후 status, diff, add, commit, log까지 이어지는 기본 작업 흐름을 설명한다.
• git switch와 git checkout을 이용해 브랜치를 생성하고 이동하는 방법을 소개한다.
• 리모트와 동기화할 때 쓰는 fetch, pull, push, push -u 명령을 정리한다.

Next.js는 Vercel 전용 프레임워크가 아닙니다. 이 글은 Next.js 앱을 Docker 이미지로 빌드하고, Kubernetes Deployment와 Service로 운영하는 현실적인 예시와 함께 언제 이런 구조가 필요한지 정리합니다.

• Next.js 프로젝트에서 Docker/Kubernetes가 필요한 상황과 그렇지 않은 상황을 구분해 설명한다.
• 프로덕션용 멀티 스테이지 Dockerfile 예시를 통해 Next.js 컨테이너 이미지를 만드는 방법을 보여준다.
• 정적 빌드, SSR, ISR이 컨테이너 환경에서 어떻게 다르게 동작하는지 설명한다.

여러 개의 Next.js 앱을 도메인·경로로 나누고, 공용 UI·인증·내비게이션을 묶어서 하나의 제품처럼 보이게 만드는 실전 가이드입니다.

• 마케팅/앱/문서를 여러 Next.js 프로젝트로 나누는 기본 패턴을 설명한다
• 공용 디자인 시스템을 패키지로 분리해 각 앱에서 재사용하는 방법을 다룬다
• 서브도메인 간 쿠키 기반 인증으로 “한 번 로그인” 경험을 유지하는 법을 설명한다

여러 개의 Next.js 앱을 어떻게 나누고 붙일지, 언제 마이크로 프론트엔드가 도움이 되고 언제 그냥 모듈형 모놀리식으로도 충분한지 정리한 글입니다.

• Next.js 기준으로 마이크로 프론트엔드가 의미하는 바를 개념적으로 정리한다
• 프록시 기반 멀티 앱 구성, 런타임 모듈 조합, 빌드 타임 조합의 차이를 설명한다
• 라우팅·SSR·데이터 패칭·디자인 시스템 관점에서의 장단점을 짚는다

Next.js는 데이터베이스나 프로토콜이 아니라 풀스택 React 프레임워크입니다. 이 글은 Next.js 위에서 GraphQL이 어떤 역할을 하고, 그 뒤에 MongoDB와 PostgreSQL을 둘 때 아키텍처가 어떻게 달라지는지 정리합니다.

• Next.js, GraphQL, MongoDB, PostgreSQL이 실제 서비스 구조에서 맡는 역할을 구분해 설명한다.
• Server Component에서 최소한의 fetch 기반 클라이언트로 GraphQL을 호출하는 패턴을 보여준다.
• Route Handler 안에 GraphQL 서버를 호스팅하는 구조를 예시로 설명한다.

Next.js는 자체 WebSocket 서버를 제공하지 않지만, 브라우저 표준 API와 Route Handler를 활용하면 WebSocket과 SSE로 충분히 실시간 기능을 구현할 수 있습니다. 이 글은 현실적으로 쓸 수 있는 패턴만 정리합니다.

• Next.js, 런타임, 전송 계층(HTTP, SSE, WebSocket)의 역할을 분리해 설명한다.
• App Router Route Handler에서 ReadableStream으로 SSE 엔드포인트를 구현하는 예시를 제공한다.
• 클라이언트 컴포넌트에서 EventSource로 SSE 스트림을 소비하는 방법을 보여준다.

Next.js로 서비스 운영할 때 자주 필요한 캐싱, 레이트 리밋, 플래그 저장을 Redis로 어떻게 처리할 수 있는지 정리한 글입니다. 과장 없이, App Router 기준으로 Route Handler와 Server Action에 Redis를 연결하는 패턴만 다룹니다.

• Next.js 아키텍처에서 Redis가 잘 들어가는 자리(캐싱, 레이트 리밋, 세션/플래그)를 정리한다.
• lib/redis.ts에 공용 Redis 클라이언트를 만들고 재사용하는 패턴을 소개한다.
• App Router Route Handler에서 TTL이 있는 데이터 캐싱 예제를 제공한다.

Next.js와 Spring Boot를 “지금은 단순하고, 나중에도 확장하기 쉬운” 방식으로 조합하는 방법을 정리했습니다.

• Next.js는 프런트엔드 + BFF, Spring Boot는 깔끔한 API/백엔드로 역할을 분리하기
• 엔티티를 그대로 노출하기보다, UI 친화적인 API 계약(Contract) 설계하기
• SSR을 깨지 않으면서 Spring Security + 쿠키 기반 인증 처리하기

Next.js Route Handler에 둘 로직과 Spring Boot 백엔드로 분리할 로직을, 실제 기능 단위로 어떻게 나눌지 정리한 실무적인 기준입니다.

• UI 전용·세션 의존 로직은 Next.js Route Handler로 충분하다
• 여러 클라이언트와 무거운 도메인 로직은 Spring Boot로 분리하는 게 안전하다
• 인증은 “무엇을 볼 수 있는가”는 Next.js, “무엇을 할 수 있는가”는 Spring Boot가 책임지는 구조가 깔끔하다

App Router와 Route Handler, Server Action 덕분에 Next.js만으로도 꽤 많은 백엔드 역할을 할 수 있게 되었습니다. 그렇다고 해서 Express 같은 별도 백엔드가 항상 필요 없어지는 것은 아닙니다. 이 글은 언제 Next.js 단독으로 충분하고, 언제 Express 백엔드를 따로 두는 편이 나은지 비교합니다.

• Next.js에서 Route Handler, server-only 모듈, Server Action이 어떤 식으로 “내장 백엔드”를 구성하는지 설명한다.
• Express 백엔드가 독립적인 Node HTTP 서버로서 제공하는 장점을 정리한다.
• 단일 프론트/소규모 SaaS에서 Next.js만으로도 충분한 실제 상황을 소개한다.

트래픽만 버티는 것이 아니라, 기능과 팀 규모가 커져도 유지 가능한 Next.js 아키텍처를 어떻게 설계할지 정리한 글입니다. App Router 폴더 구조, 서버/클라이언트 역할 분리, 캐싱/렌더링 전략, UI/타입 레이어 구성까지 실무 관점에서 다룹니다.

• 트래픽, 기능, 팀 세 가지 관점에서 스케일링을 어떻게 나눠서 봐야 하는지 설명한다.
• App Router를 도메인 기준(마케팅, 앱, 관리자 등)으로 나누고, 공통 코드를 src 아래로 분리하는 폴더 구조 예시를 제시한다.
• 서버 컴포넌트/서버 유틸/클라이언트 컴포넌트를 분리해서 확장성과 테스트 용이성을 높이는 패턴을 소개한다.

Next.js 프로젝트에서 매일 쓰게 되는 Jest, RTL, Playwright 테스트 문법을 한 군데 모아 정리한 치트시트 스타일 글입니다.

• describe/test/it, expect와 자주 쓰는 Jest 매처 문법을 정리한다
• render, screen, userEvent로 DOM을 다루는 RTL 패턴을 예제로 보여 준다
• Playwright의 test, page, locator, expect 문법을 간단한 시나리오로 설명한다

App Router를 사용하는 Next.js 프로젝트에서 Jest, React Testing Library, Playwright를 어떻게 나눠 쓰고, 무엇을 어디에서 테스트할지 정리한 실전 가이드입니다.

• Next.js 앱에서 단위/통합/E2E 테스트 피라미드를 어떻게 설계할지 설명한다
• next/jest와 RTL을 이용한 기본 Jest 설정 예시를 제공한다
• Client Component와 서버 유틸을 실제 API 호출 없이 테스트하는 방법을 다룬다

Next.js는 TDD를 강제하지 않지만, 순수 로직·컴포넌트·E2E 플로우를 잘 나누면 TDD에 잘 어울립니다. 이 글은 Next.js 코드베이스에서 TDD를 현실적으로 적용하는 구조와 패턴을 다룹니다.

• 고전적인 Red-Green-Refactor 루프를 Next.js 구조에 어떻게 적용할지 설명한다.
• 비즈니스 로직을 /lib의 순수 함수로 분리하고 거기서부터 TDD를 시작하는 방법을 소개한다.
• Jest/Vitest + React Testing Library로 컴포넌트 레벨의 TDD를 진행하는 패턴을 다룬다.

최근 Next.js는 Turbopack과 Webpack을 함께 지원합니다. 이 글은 요즘 Next.js에서 Webpack이 어떤 역할을 하고, next.config.js의 webpack() 훅으로 무엇을 설정할 수 있는지, 그리고 언제 굳이 Webpack을 건드리지 않는 게 좋은지 정리합니다.

• 최근 Next.js에서 Turbopack과 Webpack이 어떤 식으로 함께 사용되는지 설명한다.
• next.config.js의 webpack() 함수를 통해 Webpack 설정을 수정하는 방법을 보여준다.
• alias, SVG 로더, 환경별 플러그인처럼 자주 쓰이는 커스터마이징 패턴을 정리한다.

2025년 기준 Next.js 개발자 입장에서 Turbopack을 언제 쓰고, 언제 webpack으로 돌아가는 게 나은지 솔직하게 정리한 글입니다.

• 지금은 주로 개발 경험(dev 속도)에 영향을 주고, 프로덕션은 여전히 webpack인 경우가 많다
• App Router + 최소한의 webpack 커스텀인 프로젝트에서 체감 이득이 크다
• `--webpack`이 필요한 툴이나 복잡한 webpack 설정이 있으면 무리하지 않고 webpack을 쓴다

Vercel에서 next/image를 쓸 때 어떤 패턴이 요금을 빠르게 태우는지, 여러 클라이언트 사이트를 호스팅하는 관점에서 정리한 실전 가이드입니다.

• Vercel 이미지 최적화는 “무료 마법”이 아니라 리소스를 쓰는 유료 기능이다
• CMS에서 올라오는 초대형 원본 이미지는 비용과 성능 모두에 악영향을 준다
• 작은 아이콘까지 next/image로 감싸는 것은 돈만 새고 이득은 거의 없다

Next.js 기준으로 Lighthouse를 어디에 쓰고, 어디서는 점수를 굳이 신경 쓰지 않아도 되는지 정리한 현실적인 가이드입니다.

• Lighthouse는 실사용 데이터가 아닌 “랩 테스트”라는 걸 전제로 본다
• 0-100 점수보다 LCP·INP·CLS가 어느 구간에 있는지가 더 중요하다
• 기술적 실수는 Lighthouse로 잡고, 우선순위는 Field 데이터로 정한다

Next.js 앱에서 LCP·INP·CLS를 줄이기 위해 이미지를 다루는 법, 클라이언트 JS 줄이는 법, 레이아웃 점프를 막는 패턴을 정리한 실전용 치트시트입니다.

• LCP는 “메인 콘텐츠가 언제 보이는지”로 이해하고, 히어로 영역을 먼저 최적화한다
• INP는 “클릭/입력 후 반응 속도”이므로, 전역 상태 남용과 무거운 위젯을 줄이는 게 핵심이다
• CLS는 이미지·위젯·폰트가 레이아웃을 밀어내지 않게 미리 공간을 예약하는 것으로 많이 해결된다

Next.js는 SEO를 자동으로 해결해 주지는 않지만, 서버 렌더링, 메타데이터 API, 라우팅, 성능 도구를 통해 SEO 친화적인 구조를 만들기 쉽게 해 줍니다. 이 글은 실제 동작을 기준으로 Next.js SEO를 정리합니다.

• Next.js에서 SSR/SSG와 CSR을 검색 엔진이 어떻게 다르게 보는지 설명한다.
• App Router의 metadata/generateMetadata API로 페이지별 title, description, OG 태그를 설정하는 방법을 다룬다.
• SEO에 도움이 되는 URL 구조, 리다이렉트, 내부 링크 패턴을 정리한다.

Next.js 프로젝트에서 접근성을 이론이 아니라 “실제 습관” 관점에서 정리한 글입니다. 시맨틱 HTML, next/link·next/image, 키보드 내비게이션, 포커스 관리, Skip 링크, 색 대비, ESLint 기반 자동 체크까지 다룹니다.

• div 남발 대신 의미 있는 HTML 태그(h1~h6, nav, main, button 등)를 사용하는 패턴을 소개한다.
• next/link와 next/image를 접근성 있게 사용하는 방법(의미 있는 링크 텍스트, alt/장식 이미지 처리)을 설명한다.
• label, aria-describedby, role="alert"를 활용해 폼 필드·에러 메시지를 연결하는 방법을 보여준다.

Next.js App Router 기준으로 불필요한 렌더를 줄이고, 무거운 계산과 리스트 렌더를 부드럽게 만드는 Hook 최적화 패턴을 정리한 글입니다.

• 무거운 로직을 Server Component로 보내고 클라이언트 영역을 최소화하는 전략을 설명한다
• useMemo와 useCallback을 언제 써야 실제로 도움이 되는지 기준을 제시한다
• UI에 직접 영향을 주지 않는 값은 useRef로 관리해 렌더를 줄이는 패턴을 소개한다

Next.js App Router 기준으로 props, params/searchParams, Metadata, app/api route handler, 공용 도메인 타입, 제네릭 fetch 헬퍼 등 실무에서 자주 쓰는 TypeScript 패턴을 정리한 글입니다.

• HTML 속성을 확장하는 컴포넌트 props 타입 패턴을 예제로 보여 준다
• 동적 라우트와 캐치올 라우트에서 params/searchParams 타입을 어떻게 잡을지 설명한다
• Metadata와 route handler 응답 타입을 명시해 서버/클라이언트 타입을 맞추는 방법을 다룬다

SSR/ISR/CSR을 언제 어떻게 쓸지, 실제 Next.js 프로젝트 기준으로 정리한 현실적인 가이드입니다. “이 데이터가 정말 매 요청마다 최신이어야 하는가?”에서 출발합니다.

• 첫 질문은 “요청마다 최신이어야 하는가?”이다
• 사용자별로 달라지지 않는 페이지는 static + revalidate가 기본값
• 로그인/대시보드처럼 사용자 상태에 민감한 화면에만 SSR을 쓴다

app/ · features/ · components/ · lib/로 나누어, 작은 랜딩 페이지부터 대시보드까지 버티는 Next.js 폴더 구조를 정리한 실전 가이드입니다.

• app/에는 라우팅과 레이아웃만 두고, 도메인 로직은 features/로 분리한다
• features/ 폴더 안에서 도메인별로 components·lib·hooks·types를 함께 관리한다
• components/는 Button·Modal 같은 공용 UI만 두고, 도메인 냄새 나는 컴포넌트는 넣지 않는다

Next.js(App Router) 기준에서 Redux Toolkit과 React Context를 언제 써야 하는지 정리한 글입니다. 서버 컴포넌트, URL, 로컬 상태를 먼저 활용하고, 진짜로 복잡한 클라이언트 비즈니스 로직이 생길 때 Redux를 도입하는 현실적인 기준을 제안합니다.

• Next.js 앱에서 서버 상태, URL 상태, 로컬 상태, 전역(공유) 상태가 어떻게 구분되는지 설명한다.
• ThemeContext 예시를 통해 작은 전역 상태에는 Context가 적합하다는 점을 보여준다.
• Redux Toolkit으로 스토어/슬라이스/타입드 훅을 정의하고 App Router 레이아웃에 연결하는 최소 예제를 제공한다.