노트

LRU 캐시와 캐시 계층 비교

LRU Cache

백엔드#performance · 연결된 개념 9개

쉽게 말하면

LRU 캐시는 휴대폰의 최근 사용 앱 목록처럼, 정해진 개수만 남기고 꽉 차면 가장 오래 안 쓴 것부터 내보내는 메모리 캐시예요. 자주 쓰는 데이터는 계속 남고 안 쓰는 것만 밀려나죠.

비유가 깨지는 곳 휴대폰은 한 대지만 이 캐시는 서버 프로세스마다 따로 있어서, 서버를 여러 대로 늘리면 각자 캐싱해요. 함께 써야 하면 Redis 같은 외부 저장소를 두고, ttl로 오래된 값도 비워요.

LRU(Least Recently Used) 캐시는 크기를 정해 두고, 가득 차면 가장 오랫동안 쓰지 않은 항목부터 버리는 메모리 캐시다. Node.js에서는 lru-cache 패키지가 대표적이다. 자주 쓰는 데이터는 계속 남고 안 쓰는 것만 밀려난다.

import { LRUCache } from 'lru-cache'
const cache = new LRUCache({ max: 500, ttl: 1000 * 60 })   // 최대 500개, 1분 만료
 
async function getProfile(id) {
  const hit = cache.get(id)
  if (hit) return hit
  const profile = await db.users.find(id)
  cache.set(id, profile)
  return profile
}
  • 용도: 비싼 DB(Database) 조회·외부 API(Application Programming Interface)·계산 결과, 자주 요청되는 응답, DNS(Domain Name System)·파일 메타데이터, 짧게 사는 세션·토큰, 요청 횟수 집계(요청 제한 (Throttling))
  • 해시 맵(Hash Map)과 이중 연결 리스트(Doubly Linked List)를 조합하면 조회·갱신·제거를 모두 O(1)에 할 수 있다(해시 테이블, 연결 리스트)
  • 프로세스 메모리 안에 있어서 서버를 여러 대로 늘리면 서버마다 따로 캐시된다. 공유가 필요하면 Redis (인메모리 저장소) 같은 외부 저장소를 쓴다(수직 확장과 수평 확장)

층이 다른 캐시들

[브라우저: TanStack Query] → [서버 API: lru-cache] → [DB]
     네트워크 요청을 줄임          DB·외부 호출을 줄임
  • TanStack Query는 브라우저에서 같은 요청을 다시 보내지 않게 하고, 로딩·재요청·UI 연동까지 맡는다
  • lru-cache는 서버에서 같은 조회를 다시 하지 않게 하는 범용 저장소다. 상태나 UI 연동은 없다
  • React.cache는 요청 한 번 안에서만 산다
  • 둘을 함께 쓰면 2단 캐시가 된다. 일반적인 캐시 배치 전략은 읽기 캐시 전략

연결된 개념

이 노트를 가리키는 문서

뜻이 가까운 노트

  • Next.js 캐시 계층

    Next.js 14~15의 App Router 문서는 캐시를 위치와 수명이 다른 네 계층으로 설명했다. Next.js 16에서 Cache Components를 켜면 캐싱을 'use cache'로 명시하는 모델로 바뀌고 문서도 이 이름들을 쓰지 않는다(use-cache). 그래도 옛 코드와 아티클을 읽으려면 이 그림이 필요하다(2026 기준).

  • "use cache"와 Cache Components

    'use cache'는 Next.js 16의 Cache Components 모델에서 async 함수나 컴포넌트의 반환값을 캐시하라고 명시하는 지시어(Directive)다. 아무것도 표시하지 않으면 매 요청 실행되고, 캐시하고 싶은 곳에만 직접 붙인다(옵트인, Opt-in).

  • 저장소 역할 분담 (DB·캐시·큐·검색)

    서버 애플리케이션 옆에는 거의 늘 관계형 DB, 인메모리 캐시, 메시지 브로커(message broker), 검색 엔진이 붙는다. 하나로 다 하지 않는 이유는 데이터의 성격(영구성·속도·전달·검색)마다 잘하는 도구가 다르기 때문이다.

  • 브라우저 캐시

    한 번 받은 리소스(HTML·CSS·JS·이미지)를 브라우저가 저장해 두었다가 다시 쓰는 기능. 서버가 응답 헤더로 얼마나, 어떻게 캐시할지 알려 주고 브라우저가 그대로 따른다.

  • CSR·SSR·SSG·ISR

    렌더링 전략은 HTML(HyperText Markup Language)을 언제, 어디서 만드느냐의 선택이다. 브라우저에서 만들면 CSR(Client-Side Rendering), 요청마다 서버에서 만들면 SSR(Server-Side Rendering), 빌드 때 미리 만들면 SSG(Static Site Generation), 미리 만든 것을 주기적으로 다시 만들면 ISR(Incremental Static Regeneration)이다.

보기 옵션