# Django `LocMemCache` (로컬 메모리 캐시)란? ![로봇들의 데이터 보관소 이미지](/media/editor_temp/6/62743df3-4837-47d2-b16a-a458240f5629.png) `LocMemCache`는 Django가 제공하는 **로컬 메모리(Local-memory) 캐시 백엔드**입니다. 별도 캐시 설정을 하지 않으면, Django는 기본 캐시로 이 로컬 메모리 캐시를 사용합니다. 비교적 단순한 구조를 가진 앱에서 메모리 공유없이 독자적으로 빠르고 간편하게 운영하는 용도나 개발용 서버에서 Redis 세팅이전 빠르게 테스트를 할 때 사용하곤 합니다. **특징 요약** * **저장 위치:** 현재 실행 중인 **Django 프로세스의 RAM** * **공유 범위:** **프로세스 밖으로는 공유되지 않음(per-process)** * **특성:** **thread-safe** --- ## 어떤 문제를 해결하나 {#sec-d5ce9d49504b} 캐시는 “비싸게 계산/조회한 결과”를 잠깐 저장해두고, 다음 요청에서 재사용하는 용도입니다. 예를 들어 DB에서 자주 조회하는 값을 캐시에 넣으면: * 첫 요청: DB 조회 → 결과를 캐시에 저장 * 이후 요청: 캐시에서 즉시 반환(빠름) `LocMemCache`는 이 캐시를 **외부 시스템(Redis/Memcached 등) 없이** “내 프로세스 메모리에 바로” 저장합니다. --- ## 동작 방식 핵심 3가지 {#sec-5812aa71ede8} ### 1) “프로세스 단위” 캐시다 (가장 중요) {#sec-82e1553d2867} Django 문서에 명확히 적혀 있습니다: 로컬 메모리 캐시는 **per-process**입니다. 즉, * Gunicorn 워커 4개면 → **캐시도 4개** * 서버 2대면 → **서버마다 캐시가 따로** 그래서 **프로세스/서버 간 캐시 공유가 불가능**합니다. ### 2) “thread-safe”다 {#sec-b592565e73f5} 같은 프로세스 안에서 여러 스레드가 동시에 접근해도 안전하게 동작하도록 되어 있습니다. ### 3) 재시작하면 캐시가 사라진다 {#sec-56535f9324da} 메모리에만 있으니 프로세스가 재시작되면 캐시도 함께 초기화됩니다. --- ## 설정 방법 {#sec-ed6e3fa738df} `settings.py`에서 `CACHES`에 `BACKEND`를 지정합니다. ```python CACHES = { "default": { "BACKEND": "django.core.cache.backends.locmem.LocMemCache", "LOCATION": "unique-snowflake", } } ``` 공식 문서의 예시는 위 형태이며, `LOCATION`은 캐시 인스턴스를 구분하는 식별자 역할을 합니다. --- ## 장점 {#sec-38c232e71484} * **설정이 거의 필요 없음**: 외부 캐시 서버를 띄우지 않아도 됨 * **빠름**: 같은 프로세스 메모리 접근이라 지연이 낮음 * **개발/테스트에 편리**: “일단 캐시 개념을 붙여보기”에 좋음 --- ## 단점 및 주의점 {#sec-070a65a9d9f5} * **멀티 프로세스/멀티 서버에서 캐시가 쪼개짐** → “캐시가 안 먹는 것처럼 보이는” 상황이 생김 * **프로덕션에서 예측이 어려울 수 있음**: 트래픽이 여러 프로세스로 분산되면 캐시 히트율이 떨어질 수 있음 * **세션 저장소로는 비추천**: Django 세션 문서에서 로컬 메모리 캐시는 오래 유지되지 않고 멀티 프로세스에도 안전하지 않아 좋은 선택이 아니라고 경고합니다. --- ## 언제 쓰면 좋은가 {#sec-99e7489ed70c} * 로컬 개발 환경 * 단일 프로세스(또는 “캐시 공유가 필요 없는” 작업) * 기능 검증/테스트(외부 의존성 최소화) 반대로 **여러 프로세스/여러 서버에서 “같은 캐시를 함께 써야 하는” 요구**가 있으면, 로컬 메모리 캐시보다는 Redis/Memcached 같은 **공유 캐시**를 고려하는 편이 일반적입니다.