🚀 Next.js 6장: Data Fetching 르네상스 — fetch 떡상과 Memoization의 비밀

📋 목차

• 📌 이 문서를 읽기 전에
• 🤔 왜 알아야 하는가
• 🏗️ 비유로 먼저 이해하기
• 🧩 fetch API의 부활: Next.js가 훔친 표준 🟢
• 🛡️ Request Memoization — 똑같은 API 호출의 중복 방어 🟡
• 🌱 fetch가 불가능한 환경: ORM과 서버 SDK 우회법 🔴
• 🔑 API 정보 드릴링 방지 — 요청 컨텍스트 직접 접근 패턴 🟡
• 💥 에러 해결 카탈로그
• 🏁 이번에 배운 내용 총정리
• 📝 마무리 퀴즈
• 🔗 더 알아보기

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 15분(전체) / 핵심 파트만: 8분

🗺️ 이 문서의 흐름
가로챈 fetch 의 정체 → 캐싱 1단계(Memoization) 메커니즘 → DB 쿼리 중복 방지 패턴

🎯 이 문서를 다 읽으면 할 수 있는 것

• Props Drilling을 피하기 위해 여러 컴포넌트에서 같은 API를 중복 호출하는 아키텍처를 당당하게 짤 수 있다.
• Next.js가 무효화 불가능하게 강제로 걸어버리는 1단계 단발성 캐시(Memoization) 의 수명을 정확히 알 수 있다.
• Prisma, Drizzle 등 fetch 를 안 쓰는 ORM 환경에서도 중복 쿼리를 방어하는 cache() 래핑을 적용할 수 있다.

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

• 영철(새로 온 주니어): "리드 님... 레이아웃에서도 유저 정보가 필요하고 본문에서도 필요해서 fetch 를 두 번 썼거든요. 그런데 로그를 보니 DB 조회가 두 번씩 발생해서 서버 비용이 두 배로 깨지고 있어요! 전역 상태 라이브러리라도 써야 할까요? 😭"
• 영호(FE 리드): "영철 님... App Router 환경에서는 Next.js가 몰래 fetch 함수를 가로채서 똑같은 요청을 하나로 병합(Memoization) 해줘요! 무거운 전역 상태 관리자는 더 이상 데이터 공유용으로 쓰지 않아도 된다고요!"

🤔 왜 알아야 하는가

오래된 리액트 방식에서는 컴포넌트 A와 저어어 밑에 있는 컴포넌트 Z가 둘 다 "현재 로그인한 유저 정보"를 보고 싶을 때 참 괴로웠지.

1. 최상단에서 API를 한 번 호출해 Props Drilling으로 아래 컴포넌트까지 내려주든가,
2. Redux, Recoil, React Query (Tanstack Query) 같은 전역(Global) 클라이언트 캐싱 라이브러리를 붙이든가.

하지만 이 방식들은 방대한 자바스크립트 번들을 브라우저에 내려보내고 use client 최상단 오염을 전파하는 거대한 병목이었어.
Next.js 13+ App Router 세상에서는 서버 컴포넌트가 대세가 되었어. 서버 컴포넌트끼리 데이터를 공유하려면 어떻게 해야 할까?
놀랍게도 리액트와 넥스트 팀이 제시한 해답은 "그냥 여러 군데에서 똑같은 API를 각자 호출하세요! 중복 제거는 우리가 몰래 알아서 해줄게요." 였어. 이 마술 같은 "단발성 캐시(Request Memoization)" 원리를 모르면 옛날 방식으로 돌아가 불필요하게 서버 부하와 클라이언트 번들을 낭비하게 돼.

🏗️ 비유로 먼저 이해하기

🧒 5살에게 설명한다면? (영수네 국밥집 고기 고명)

손님(사용자) 이 들어와서 "수육 국밥 하나요!" 라고 주문을 했어.(단일 렌더링 요청)

주방 보조 A(레이아웃) 가 "어! 수육 고기 한 접시 필요해!" 라고 소리치며 냉장고(fetch) 로 뛰어갔어. 접시를 꺼내와.
1초 뒤에 주방 보조 B(본문) 도 똑같이 "어! 나도 수육 한 접시 필요한데!" 라며 냉장고(fetch) 로 뛰어갔지.

그런데 주방장(Next.js) 이 척 가로막으며 말해.
"어허! 방금 A가 꺼낸 고기 접시, 내가 여기 도마 위에(임시 메모리) 똑같이 썰어놨어! 냉장고 문 또 열지 말고 이거 그냥 나눠서 담아!"

단, 손님이 국밥을 다 먹고 나가는 순간(렌더링 완료), 도마 위에 남은 고기 정보는 깨끗이 치워져서 리셋 돼. 다음 손님이 오면 또 새로 꺼내야 하지. 이게 Request Memoization 이야.

🧩 fetch API의 부활: Next.js가 훔친 원래 표준 🟢

기존 프론트엔드 개발자들은 axios를 선호했어.
하지만 Next.js App Router 생태계에서는 순수 브라우저 API였던 fetch를 무조건 1순위로 써야 해.

왜냐고? Next.js 코어 팀이 브라우저의 전유물이었던 fetch 함수를 Node.js 환경에서 돌아갈 수 있도록 몰래 덮어씌워서(Monkey Patching) 확장 개조해놨거든.

이 개조된 fetch는 단순한 통신 모듈을 넘어서 서버 캐시 저장소(next: { revalidate }, cache: 'force-cache')와 연결된 거대한 캐시 컨트롤러야. axios는 순수 서드파티이므로 이 마법의 혜택을 1도 볼 수가 없어! (단발성 중복 제거는 여전히 스스로 해야 함)

🛡️ Request Memoization — 똑같은 API 호출의 중복 방어 🟡

💡 이 문서에서 다루는 캐싱은 단 하나의 사용자 접속(1 Request) 주기 동안만 살아남는 단발성 "기억(Memoization)" 이다! 영구 보존되는 데이터 캐시 챕터는 [Advanced]에서 따로 딥다이브 할 예정.

컴포넌트 구조

// 영수네 커뮤니티 페이지 구조
app/
 ├─ layout.tsx (사이드바 메뉴 - 접속 유저 프로필 필요)
 └─ user/[id]/page.tsx (본문 - 역시나 접속 유저 프로필 필요)

❌ 과거의 공룡 방식 (전역 스토어)
레이아웃에서 데이터를 받아온 뒤 Context API나 Redux/Zustand Store에 억지로 밀어 넣고 page.tsx에서 꺼내 쓰게 하는 방식. 코드가 지저분해지고 클라이언트 컴포넌트화가 강제된다.

✅ RSC 최신 폼 (각자도생 렌더링)

// 1. app/layout.tsx
// 헤더에 로그인한 사용자 "영철"의 이름을 띄워야 한다!
export default async function Layout({ children }) {
  const res = await fetch('https://api.my.com/user/1');
  const user = await res.json(); // { name: "영철", job: "프론트엔드 개발자" }
 
  return <nav>환영합니다, {user.name} 님</nav>{children}
}

// 2. app/user/[id]/page.tsx
// 본문에서도 프로필 수정 폼을 위해 또 내 정보 전체가 필요하다!
export default async function Page() {
  const res = await fetch('https://api.my.com/user/1'); // URL과 메소드가 100% 똑같다!
  const user = await res.json();
 
  return <div>내 직업: {user.job} </div>
}

[내부에서 일어나는 일]

1. 사용자가 페이지 접속. (렌더링 트리 탐색 시작)
2. layout.tsx 실행 중 fetch('/user/1') 조우. Next.js가 "내 단발성 메모리에 이 요청결과 있나? 없네. 진짜 DB 가서 데이터 가져온다(MISS)."
3. 결과를 가져온 뒤, 응답 객체를 컴포넌트에 넘김과 동시에 Next.js 내부 메모리(캐시 트리)에 살짝 저장해둠.
4. 트리 아래쪽 page.tsx 실행. 또 fetch('/user/1') 조우.
5. Next.js가 웃으면서 가로챔. "아하! 이 URL, 아까 1밀리초 전에 위에서 똑같이 불렀던 거잖아! 진짜 서버로 네트워크 전송하지 말고 아까 저장해둔 거 바로 돌려줄게 (HIT)."
6. 렌더링 종료 후 HTML 완성. 이 메모이제이션 수첩은 즉시 폐기 됨. (서버 리소스 반환)

어때? 우리는 아무런 전역 상태 라이브러리(Zustand 등)를 깔지 않고도, 그저 똑같은 주소의 fetch를 여러 줄 복붙했을 뿐인데 서버 부하는 무조건 1회로 한정되는 축복을 누리게 된 거야. Props Drilling에서 영원히 해방된 거지!

🌱 fetch가 불가능한 환경: ORM과 서버 SDK 우회법 🔴

영철(신입)이가 헐레벌떡 뛰어와. "리드님!! 큰일 났어요! 저희는 프론트 단독 fetch로 API 호출 안 하고, 데이터베이스를 직접 찌르는 Prisma를 쓰고 있어서 db.user.findUnique() 함수를 쓰잖아요! 얘는 fetch가 아니라서 레이아웃이랑 본문에 두 번 쓰면 DB 쿼리가 진짜로 두 번 나가서 데이터베이스 부하가 두 배로 늘어나요!"

영호(리드)가 대답해. "네, Next.js 코어 팀이 가로채서 마개조한 건 오직 fetch 뿐이에요. 외부 라이브러리인 Prisma, Drizzle, Firebase SDK, Stripe 등은 바보처럼 매번 정직하게 쿼리를 날리죠. 이럴 땐 우리가 수동으로 React.cache() 라는 방어막을 직접 치는 겁니다."

✅ 완벽한 수동 래핑 (React cache API 도입)

fetch를 못 쓴다면, 내 일반 함수라도 저 1회용 단발성 메모리(Memoization)의 축복을 받게끔 모자(cache)를 씌워주면 돼.

// app/lib/getUser.ts (🔥 중요 유틸 함수 파일)
import { cache } from 'react' // Next.js가 아니라 React 코어에서 지원하는 API!
import db from './prismaClient'
 
// 순정 함수인 getUserById를 cache() 방어막으로 감싼다!
export const getUserById = cache(async (id: string) => {
  console.log('이 로그가 딱 한 번만 찍혀야 정상입니다!'); // 증명용 로그
  const user = await db.user.findUnique({ where: { id } });
  return user;
})

이제 layout.tsx와 page.tsx에서 이 getUserById('123') 함수를 10번, 100번 복붙해서 마구잡이로 호출해도, 동일한 인자(id='123')에 대한 리액트 사이클 내에서의 DB 쿼리는 콘솔 보장 단 1번만 발동해.

💡 심화 주의: 이 React.cache()는 Next.js의 4중 캐시 중 최고급인 Data Cache(영구 보관 캐시)까지는 건드리지 못해! 오직 '이번 한 번의 페이지 방문(1 Request Lifecycle)'에 한해서만 중복을 막는 똑똑한 지우개가 달린 수첩일 뿐이야.

🔑 API 정보 드릴링 방지 — 요청 컨텍스트 직접 접근 패턴 🟡

🎯 이 섹션을 읽고 나면:

• cookies() / headers() 를 어느 깊이의 서버 컴포넌트에서든 직접 호출할 수 있음을 안다
• 인증 토큰을 Props로 내려받지 않아도 되는 이유를 설명할 수 있다
• React.cache() 가 '이번 요청(1 Request Lifecycle)' 범위에서만 유효함을 알고 올바르게 사용할 수 있다

문제: "인증 정보도 결국 Prop Drilling이 생기잖아요!"

영철이가 또 뛰어와. "리드님! fetch('/api/posts')를 여러 컴포넌트에서 각자 호출하는 건 이제 알겠어요. 그런데... 그 API가 인증이 필요해서 Authorization: Bearer <토큰> 헤더를 붙여야 한다면요? 토큰은 쿠키에서 꺼내야 하는데, 최상단 레이아웃에서 꺼낸 토큰을 페이지로 Props로 내려주고, 또 그 자식 컴포넌트로 Prop Drilling해야 하는 것 아닌가요? 아, 그리고 URL 파라미터나 쿼리스트링도 마찬가지 아닌가요? /posts/[id] 의 id 를 자식 컴포넌트까지 내려줘야 하잖아요?"

영호가 웃으며 대답해. "쿠키/헤더든, params든, 서버 컴포넌트 환경에서는 모두 어느 깊이에서든 직접 접근이 가능해요. next/headers에서 제공하는 cookies()와 headers() 함수, 그리고 params와 searchParams 는 렌더 트리 어느 깊이에서든 직접 받아 쓸 수 있거든요. 서버이기 때문에 가능한 특권이에요!"

❌ 과거 방식 (쿠키 Prop Drilling)

// app/layout.tsx — 쿠키 꺼내서 아래로 내려줌
export default async function Layout({ children }) {
  const cookieStore = await cookies()
  const token = cookieStore.get('session-token')?.value
  return <Main token={token}>{children}</Main> // token을 props로 넘겨야 함
}
 
// app/page.tsx — 받아서 또 내려줌
export default function Page({ token }) {
  return <PostList token={token} /> // 계속 내려가야 함
}

✅ RSC 방식 (어디서든 직접 접근)

// app/posts/PostList.tsx — 어느 깊이에 있어도 직접 쿠키 접근!
import { cookies } from 'next/headers'
 
export default async function PostList() {
  const cookieStore = await cookies()
  const token = cookieStore.get('session-token')?.value
 
  const posts = await fetch('https://api.my.com/posts', {
    headers: { Authorization: `Bearer ${token}` }, // Props 없이 직접 사용
  })
  const data = await posts.json()
  return <ul>{data.map(p => <li key={p.id}>{p.title}</li>)}</ul>
}

Props 드릴링이 완전히 사라졌어. cookies()와 headers() 는 HTTP 요청 객체에 직접 접근하는 서버 전용 함수야. Node.js 서버 안에서 실행되기 때문에 어느 깊이의 서버 컴포넌트에서 호출해도 동일한 현재 요청 컨텍스트를 참조해.

params와 searchParams도 직접 받으면 돼

쿠키만이 아니야. URL 동적 파라미터(params)와 쿼리스트링(searchParams)도 서버 컴포넌트에서 직접 props로 받거나, Next.js 15 이상에서는 await 형태로 받을 수 있어.

// app/posts/[id]/CommentSection.tsx
// ✅ page.tsx를 거치지 않고 직접 params를 받아서 쓸 수 있어
export default async function CommentSection({
  params,
}: {
  params: Promise<{ id: string }>  // Next.js 15 기준 Promise 타입
}) {
  const { id } = await params  // URL: /posts/123 → id = "123"
 
  const comments = await fetch(`https://api.my.com/posts/${id}/comments`)
  return <ul>...</ul>
}

// app/search/ResultList.tsx
// ✅ 검색 쿼리(?q=react&page=2)도 직접 받아서 쓸 수 있어
export default async function ResultList({
  searchParams,
}: {
  searchParams: Promise<{ q?: string; page?: string }>
}) {
  const { q, page } = await searchParams  // 쿼리스트링 직접 접근
 
  const results = await fetch(`https://api.my.com/search?q=${q}&page=${page}`)
  return <ul>...</ul>
}

💡 Next.js 15 주의사항: params와 searchParams 가 비동기(Promise) 타입으로 바뀌었어. await를 반드시 붙여야 해. Next.js 14 이하에서는 params.id 처럼 바로 접근 가능해.

React.cache()로 세션 정보 1회만 조회하기

여러 컴포넌트에서 쿠키를 각자 꺼내 API 요청을 한다면, 매번 인증 API가 따로 호출될 수 있어. React.cache()로 감싸서 요청당 1회만 실행되도록 보장해라.

// app/lib/auth.ts
import { cache } from 'react'
import { cookies } from 'next/headers'
 
// 이 함수는 한 요청 사이클에서 몇 번을 호출해도 실제 fetch는 딱 1번만 실행돼
export const getSession = cache(async () => {
  const cookieStore = await cookies()
  const token = cookieStore.get('session-token')?.value
  if (!token) return null
 
  const res = await fetch('https://api.my.com/me', {
    headers: { Authorization: `Bearer ${token}` },
  })
  return res.json() // { userId: 'abc123', name: '영철', role: 'user' }
})

이제 layout.tsx, page.tsx, 어떤 서버 컴포넌트에서든 getSession()을 호출해도 실제 HTTP 요청은 단 1번만 나가.

// 레이아웃에서도 호출
export default async function Layout({ children }) {
  const session = await getSession() // 1번째 호출 → 실제 fetch 발동 (MISS)
  return <nav>안녕하세요, {session?.name} 님</nav>
}
 
// 깊은 자식 컴포넌트에서도 호출
export default async function UserCard() {
  const session = await getSession() // 2번째 호출 → 캐시에서 즉시 반환 (HIT)
  return <div>역할: {session?.role}</div>
}

⏱️ React.cache 유효 범위 — "이번 요청"이 전부다

⚠️ 중요: React.cache() 의 메모이제이션은 단일 렌더 사이클(1 HTTP Request) 범위에서만 유효해. 브라우저가 새로고침하거나 다른 사용자가 접속하면 캐시는 완전히 비워지고 새로 시작해.

사용자 A의 요청 시작 → getSession() 1번째 호출 (MISS) → 실제 API fetch 실행
                    → getSession() 2번째 호출 (HIT)  → 메모리에서 즉시 반환
사용자 A의 응답 완료 → ❌ 캐시 폐기됨
 
사용자 B의 요청 시작 → getSession() 1번째 호출 (MISS) → 처음부터 다시 fetch

이 덕분에 사용자 간 데이터 오염(Cross-user data leak) 이 발생하지 않아. 사용자 A의 세션이 사용자 B에게 흘러가는 일은 절대 없어.

💡 한 줄로 기억하기
RSC에서는 인증 토큰을 props로 들고 뛰어다닐 필요 없어. next/headers에서 직접 꺼내고, React.cache() 로 감싸면 한 요청 안에서 중복 호출도 막을 수 있어. 단, 이 캐시는 현재 사용자의 요청이 끝나는 순간 자동 폐기돼.

➡️ 다음 섹션에서는: 자주 만나는 에러 메시지들을 증상별로 묶은 카탈로그를 확인해봐.

💥 에러 해결 카탈로그

에러 메시지가 뜨면 Ctrl+F로 검색해봐.

❌ You are using an unsupported version of Next.js for React.cache

원인: 무심코 다른 파일에서 cache 함수를 잘못 썼거나 환경 이슈.
해결책: cache는 오로지 서버 컴포넌트(Server Components) 생태계와 서버 단에서만 동작하는 메모이제이션이다! 클라이언트 컴포넌트 컴파일러 측에서 이 함수를 import해서 쓰려 하면 터진다. (클라이언트는 기존 방식의 useMemo나 useQuery 등을 써야 함)

❌ (fetch) 중복 제거가 안 되고 API가 2번 찔려요!

원인: Request Memoization의 작동 조건은 철저하게 "메소드(GET 등)와 URL(경로+쿼리스트링)과 옵션(headers 등)이 100% 완벽히 일치할 때" 만 발동함. 만약 한쪽에선 Authorization 헤더를 넣고 한쪽에선 빼먹었다면 브라우저(Next.js)는 다른 요청으로 간주하고 두 번 쏜다.
해결책: 아예 getUserProfileFetch() 같이 fetch 옵션 무장을 끝마친 유틸 함수 하나를 만들어서 곳곳에서 똑같이 불러다 쓰는 패턴을 사용해라.

🏁 이번에 배운 내용 총정리

💡 한 줄로 기억하기
서버 컴포넌트 세상에서는 눈치 보지 말고 필요한 곳에서 필요한 만큼 데이터를 직접 요청해(Fetch)라. 똑똑한 수문장(Next.js Memoization)이 다 알아서 중복 요금을 면제해 줄 거니까. 단, 손님이 집에 가는 순간 멤버십 무효화!

🐣 영철이의 퇴근 일기

오늘은 정말 큰 짐을 하나 내려놓은 기분이야. 예전엔 컴포넌트마다 같은 데이터를 부르면 서버가 터질까 봐 무서워서 Props Drilling 하느라 땀 뻘뻘 흘렸거든. 그런데 영호 리드 님이 말씀하신 '도마 위의 고기(Memoization)' 덕분에 이제는 당당하게 각자 필요한 곳에서 fetch 를 날릴 수 있게 됐어!

💡 오늘의 교훈: "서버 컴포넌트라면 Props로 데이터를 옮기지 말고, 필요한 곳에서 직접 fetch하자! 나머지는 리액트 주방장이 알아서 병합해준다."

React.cache() 라는 든든한 방어막도 배웠으니, 이제 우리 서비스의 DB 부하도 걱정 없어. 오늘은 머리를 많이 썼더니 좀 멍하네. 집에 가서 시원하게 샤워하고 푹 자야지. 내일은 오늘보다 더 빠르고 효율적인 데이터 페칭 코드를 짜볼 거야! 🐣

🔗 더 알아보기

• Next.js Docs: Request Memoization