Next.js 공식 문서 활용
공식 문서의 시작 안내·개념·API 레퍼런스·예제를 탐색하고 현재 버전의 동작을 1차 근거로 확인합니다.
Next.js를 공부하고 개발하는 동안 가장 믿을 수 있는 도구는 공식 문서(official documentation)입니다. Next.js 팀이 직접 쓰고 계속 업데이트하므로 기능, 개념, 모범 사례를 가장 정확하고 체계적으로 제공하며, 단순한 레퍼런스를 넘어 실제 프로젝트에 적용할 때 필요한 판단 기준도 얻을 수 있습니다. 이 글에서는 Next.js 공식 문서로 학습하고, 문제를 해결하고, 최신 정보를 얻는 방법을 알아봅니다.
공식 문서의 중요성
공식 문서를 먼저 찾아야 하는 이유는 다음과 같습니다.
- 정확성과 신뢰성: API의 의도와 지원 범위를 확인하는 1차 자료입니다. 문서와 설치된 버전의 동작이 다르면 해당 릴리스, 공식 소스, 재현 결과를 함께 확인합니다.
- 최신 정보: Next.js는 빠르게 바뀌는 프레임워크이므로, 공식 문서가 릴리스 설명과 API 변경 사항을 정리합니다. 공식 저장소의 릴리스와 소스도 변경 내용을 확인하는 자료이므로 필요할 때 함께 봅니다. App Router와 Pages Router의 차이를 분명히 이해하는 데도 꼭 필요합니다.
- 체계적인 학습 경로: 설치부터 배포, 고급 기능까지 일관된 흐름으로 구성되어 있어, Next.js를 처음 배우는 사람도 차례대로 학습할 수 있습니다.
- 성능과 모범 사례: 기능 설명뿐 아니라 성능 최적화 전략과 권장 사용 패턴 등 실제 프로덕션 개발에 필요한 모범 사례를 제시합니다.
- API 레퍼런스: Next.js의 API, 컴포넌트, 함수에 대한 자세한 설명과 예제 코드를 제공해 개발 중 궁금한 점을 바로 찾아볼 수 있습니다.
개념 설명과 API의 호출 규칙은 함께 읽습니다. 가이드는 기능을 조합하는 흐름을, API 레퍼런스는 인자, 반환값, 사용 제한을 찾는 데 유용합니다. 가이드의 짧은 예만으로 반환값의 타입이나 버전별 기본값을 추측하지 않습니다. 두 설명이 다르거나 설치된 버전과 맞지 않는다면 해당 API의 버전 이력과 릴리스, 공식 소스를 함께 비교하고, 필요한 동작만 작은 재현으로 확인합니다. 확인하기 전의 추정과 실제로 확인한 결과도 구분합니다.
공식 문서 탐색 가이드
Next.js 공식 문서는 Getting Started, Guides, API Reference로 구성됩니다. Learn 튜토리얼과 공식 저장소의 Examples는 별도의 학습 자료와 구현 자료로 활용합니다.
Getting Started
Getting Started는 Next.js를 처음 접하는 사용자를 위한 섹션입니다. 프로젝트를 만들고 개발 서버를 시작하는 설치(Installation), App Router를 바탕으로 한 파일과 디렉터리의 기본 구조를 설명하는 프로젝트 구조(Project Structure)에서 시작해, 레이아웃과 페이지, 링크와 내비게이션, 서버와 클라이언트 컴포넌트, 데이터 가져오기와 캐싱, 이미지와 폰트 최적화 같은 핵심 기능을 차례로 소개합니다. Next.js 프로젝트를 처음 시작하거나 기본 설정 방법을 확인할 때 가장 먼저 참고합니다.
Learn
Next.js Learn은 Next.js의 핵심 개념을 실습 위주로 배우고 싶은 사용자를 위한 공식 튜토리얼입니다. 실제 대시보드 애플리케이션을 단계별로 만들며 라우팅, 데이터 페칭, 폼 처리, 인증 같은 주요 기능을 익힐 수 있습니다. 문서를 읽는 데서 그치지 않고 직접 코드를 쓰며 Next.js의 동작 원리를 몸에 익히는 데 효과적이며, 특히 App Router를 깊이 이해하는 데 도움이 됩니다.
Guides와 API Reference
Guides는 인증, 캐싱, 국제화, 테스트, 배포, 업그레이드 같은 주제를 실제 작업 순서에 따라 설명합니다. 특정 기능의 동작 원리를 이해하거나 고급 기능을 프로젝트에 적용하려 할 때 주로 참고합니다.
API Reference는 Next.js가 제공하는 기능을 종류별로 정리한 레퍼런스입니다. next/image, next/script, next/link 같은 컴포넌트, page, layout, route, proxy 같은 파일 규약, cookies, fetch, revalidateTag 같은 함수, next.config.js의 설정 옵션, next CLI의 명령을 각각 찾아볼 수 있습니다. 개발 중에 궁금한 API의 인자와 반환값, 사용 제한을 빠르게 확인하는 곳입니다.
Examples
Next.js 저장소의 Examples는 여러 사용 사례와 인기 라이브러리의 연동 예제를 모은 코드 저장소입니다. 특정 기능을 구현할 시작점을 찾거나, 인증과 상태 관리 같은 라이브러리를 Next.js와 통합하는 방법을 배울 때 유용합니다. 예제의 README와 고정된 의존성, 실행 조건을 확인하고, 학습을 위해 생략한 부분과 제품에 필요한 요구를 구분합니다.
반환값까지 따라 읽는 예: 요청 쿠키
Next.js 16의 App Router에서 요청의 표시 테마를 읽는다고 합시다. cookies API의 설명에서 먼저 반환값이 Promise인지, 어디에서 읽을 수 있는지 확인합니다. 현재 API는 비동기이므로 Next.js 14 이하의 동기 호출 예와 구분해야 합니다. 다음은 서버의 요청 컨텍스트에서 부르는 작은 읽기 함수입니다.
import { cookies } from 'next/headers';
export async function readTheme(): Promise<'dark' | 'light'> {
const store = await cookies();
const value = store.get('theme')?.value;
return value === 'dark' ? 'dark' : 'light';
}await로 받은 store에서 쿠키를 읽습니다. 쿠키가 없거나 값이 "admin"처럼 허용한 테마가 아니면 "light"를 반환합니다. 이 값은 표시 선택일 뿐, 사용자 인증이나 관리자 권한을 증명하지 않습니다. 서버 컴포넌트에서는 요청 쿠키를 읽을 수 있지만, 쿠키를 설정하거나 지우는 API는 서버 함수나 Route Handler 등에서만 쓸 수 있다는 제한이 따로 있습니다. Cache Components를 켠 서버 컴포넌트에서 요청 시점의 값을 읽을 때는 공식 문서의 Suspense 조건도 확인합니다. 브라우저 코드나 요청 밖에서 불러도 된다고 넓혀 해석하지 않습니다.
파일 위치와 라우터도 API의 사용 규칙에 포함됩니다. app/api/ping/route.ts의 요청 처리는 App Router의 Route Handler 문서에서 찾습니다. HTTP 메서드별로 GET 같은 이름의 함수를 내보내고 Web Request, Response API를 씁니다. pages/api/ping.ts에서 기본 내보내기와 req, res를 쓰는 Pages API Route 문서는 다른 파일 규약입니다. URL이 모두 /api/ping이어도 코드를 그대로 바꾸어 쓸 수는 없습니다.
공식 문서 활용 팁
공식 문서를 더 효율적으로 쓰는 방법은 다음과 같습니다.
- 검색: 문서 위쪽의 검색창에 키워드를 넣으면 관련 섹션, API, 예제를 빠르게 찾아 줍니다. 오류 메시지나 특정 기능의 이름을 그대로 검색해 봅니다.
- 목차: 사이드바에서 문서 주제를 고르고, 페이지 안의 목차로 소제목을 찾습니다. 좁은 화면에서는 메뉴를 열어 탐색합니다.
- 버전과 라우터 선택: 문서에서 고른 버전과 App Router, Pages Router 선택값을 프로젝트 의존성의 버전과 비교합니다. 선택기가 화면 어디에 있는지보다, 지금 어떤 버전과 라우터가 선택되었는지가 중요합니다.
- 예제 코드: 예제가 요구하는 파일 위치, 의존성, 환경 변수를 먼저 확인합니다.
...로 생략한 코드나 다른 절에서 정의한 모듈은 직접 채워야 하며, 설치된 버전에서 필요한 동작만 작은 예제로 확인합니다. - 관련 링크: 각 문서의 아래쪽이나 본문 중간에 관련 문서로 이어지는 링크가 많으므로, 이를 따라가며 한 주제를 깊이 있게 읽습니다.
- 오류 메시지의 링크: Next.js는 개발 중 생긴 오류에 공식 문서 링크를 함께 보여 주는 경우가 많습니다. 오류 메시지에 들어 있는 링크로 관련 문서를 바로 확인합니다.
- 주기적인 확인: Next.js는 꾸준히 업데이트되므로, 새 버전이 나올 때마다 공식 블로그와 문서에서 변경 사항과 새 기능을 확인하는 습관을 들입니다.
확인한 문서의 URL, 버전, 적용 조건과 실제로 검증한 범위를 짧게 남겨 두면, 나중에 무언가 바뀌었을 때 판단의 출처를 다시 찾기 쉽습니다.
API 문서를 한 질문에 적용하는 예도 보겠습니다. 서버 fetch의 응답을 여러 요청 사이에서 재사용하고 싶다면 먼저 fetch API 레퍼런스의 cache 설명을 읽습니다. 브라우저 HTTP 캐시의 옵션과 Next.js 서버의 지속 캐시에 대한 설명을 구별하고, 현재 프로젝트의 버전과 렌더링 조건에 맞춰 적용합니다.
정리
- 공식 문서는 API의 의도와 지원 범위를 확인하는 1차 자료이며, 설치한 버전과 라우터에 맞는 문서를 먼저 읽습니다.
- Getting Started는 기본 흐름을, Guides는 주제별 작업 순서를, API Reference는 인자와 반환값, 사용 제한을 찾는 곳입니다.
- 예제 코드는 파일 위치, 의존성, 생략된 부분을 확인하고, 설치된 버전에서 필요한 동작만 작게 재현합니다.
- 같은 URL이라도 App Router와 Pages Router의 파일 규약과 API는 다르므로 그대로 옮기지 않습니다.
- 읽은 문서의 URL과 버전, 실제로 확인한 범위를 함께 기록합니다.
연습 문제
1. 한 렌더 안의 중복 제거와 지속 캐시
한 서버 렌더 과정에서 같은 GET 호출이 한 번만 실행되었다는 사실을 확인했습니다. 이것만으로 다음 사용자의 요청도 이전 응답을 재사용한다고 할 수 있을까요? 요청 사이의 서버 캐시 재사용을 의도한다면 문서에서 어떤 옵션을 확인해야 할까요?
해설 보기
한 렌더 과정의 중복 제거는 메모이제이션의 범위일 수 있어, 다음 요청에서도 재사용된다는 뜻은 아닙니다. 서버의 지속 캐시를 의도한다면 cache: 'force-cache'의 동작과 적용 조건을 확인합니다. 기본 동작, 정적 사전 렌더, 개발 모드의 HMR 캐시는 각각의 설명을 읽어야 하므로, 옵션 하나로 모든 화면의 신선도를 추측하지 않습니다.
확인 기록에는 문서 URL, 버전, 실행 위치와 확인한 조건을, 재현 기록에는 변경 전후의 값과 요청 순서를 남깁니다. 문서를 읽은 범위와 실제 앱에서 실행한 범위는 따로 기록합니다.
2. 예전 동기 호출 예
Next.js 16의 서버 요청 코드에서 const store = cookies(); store.get('theme')를 작성했습니다. 예전의 동기 호출 예를 참고했다면, 현재 API에 맞추려면 무엇을 고쳐야 할까요?
해설 보기
cookies()가 돌려준 Promise를 기다린 뒤의 저장소를 써야 합니다. 서버의 비동기 함수에서 const store = await cookies()로 받은 뒤 get을 부릅니다. Next.js 14 이하의 동기 호출 예를 현재 버전에 그대로 쓰지 않으며, 호출하는 곳이 서버의 요청 컨텍스트여야 한다는 조건도 지킵니다.
3. readTheme의 반환값과 권한
위 readTheme에서 쿠키 값이 "dark"일 때, "admin"일 때, 쿠키가 없을 때 각각 무엇을 반환할까요? "admin"이라는 쿠키를 보냈다는 이유로 관리자 작업을 허용해도 될까요?
해설 보기
차례대로 "dark", "light", "light"입니다. 이 함수는 허용한 표시 테마만 고를 뿐 권한을 주지 않습니다. 쿠키 값은 사용자가 바꿀 수 있으므로, 관리자 작업은 검증한 인증 정보와 서버의 권한 정책으로 따로 판단합니다.
4. 같은 URL, 다른 라우터
파일은 app/api/ping/route.ts인데, 검색한 예는 pages/api/ping.ts의 export default function handler(req, res)입니다. URL이 같으니 그대로 적용할 수 있을까요? 어느 API 문서를 확인해야 할까요?
해설 보기
그대로 적용할 수 없습니다. App Router의 Route Handler 파일 규약과 메서드별 내보내기, Web Request와 Response API를 확인합니다. Pages Router의 기본 핸들러 내보내기와 요청, 응답 객체의 규칙은 별개입니다. URL 이름이 같다고 두 규약이 같은 것은 아닙니다.
5. 가이드와 레퍼런스가 다를 때
한 공식 가이드의 기본값 설명과 현재 API 레퍼런스의 설명이 서로 달라 보입니다. 프로젝트는 아직 실행해 보지 않았습니다. 어떤 조건과 자료를 더 확인하고, 결론을 어떻게 제한해야 할까요?
해설 보기
설치한 정확한 버전, 라우터, 실행 위치, 관련 옵션을 정하고, 해당 API의 버전 이력과 적용 범위, 릴리스나 공식 소스를 비교합니다. 가이드의 예가 다른 버전이나 생략된 조건을 전제하는지도 확인합니다. 필요한 동작만 재현해 확인하기 전에는 현재 앱에서 어느 기본값이 적용되었다고 단정하지 않으며, 읽은 자료와 아직 확인하지 않은 실행 범위를 함께 기록합니다.
버전별 변경 사항은 Next.js 업그레이드 안내와 Next.js 블로그에서 확인할 수 있습니다.
이것으로 19장과 Next.js 트랙을 마칩니다. 19장에서는 인증, 상태 관리, UI, 폼 검증, 데이터베이스 라이브러리를 요구사항과 실행 위치에 맞춰 고르는 방법, 커뮤니티에서 답을 찾고 재현할 수 있게 질문하는 방법, 그리고 공식 문서의 구성을 따라 현재 버전의 동작을 확인하는 방법을 살펴봤습니다. 이 트랙 전체로는 Next.js 프로젝트를 만들고 App Router의 라우팅과 렌더링을 익히는 데서 시작해, 데이터 페칭과 캐싱, 서버 컴포넌트와 상태 관리, 스타일링, 인증, Route Handler, 최적화, 테스트, 배포, 고급 기능을 거쳐, 온라인 북스토어를 직접 만들고 오류와 성능 문제를 진단하는 데까지 Next.js로 웹 애플리케이션을 만드는 전체 과정을 따라왔습니다. 처음부터 다시 훑어보고 싶다면 Next.js 교재의 목차로 돌아가세요.