NestJS에서 캐싱은 어떻게 추가하나요?

Question

Accepted Answer

NestJS는 store 전반에 걸쳐 작동하는 통합 API를 가진 내장 **캐싱 module**(`@nestjs/cache-manager`)을 제공합니다 — 기본적으로 인메모리, 또는 여러 인스턴스에 걸친 분산 캐싱을 위한 **Redis**. 캐싱은 반복적인 비싼 작업을 피함으로써 성능을 극적으로 향상시킵니다.

## 캐시 module 설정

```ts
@Module({
  imports: [
    CacheModule.register({
      ttl: 60000,        // 기본 TTL(ms) — 항목이 60초 후 만료
      max: 100,          // 메모리 내 최대 항목 수 (인메모리 store)
      isGlobal: true,    // 앱 전역에서 사용 가능
    }),
  ],
})
export class AppModule {}
```

## interceptor로 엔드포인트 자동 캐싱

```ts
@Controller("products")
@UseInterceptors(CacheInterceptor)   // GET 응답을 자동으로 캐싱
export class ProductsController {
  @Get()
  @CacheTTL(30000)                    // 이 라우트의 TTL 재정의
  findAll() {
    return this.productsService.findAll();   // 결과 캐싱; 이후 GET은 즉시
  }
}
```

`CacheInterceptor`는 `GET` 엔드포인트 응답을 (URL을 키로) 자동으로 캐싱하고 반복 요청 시 캐시된 결과를 제공합니다 — 읽기가 많은 엔드포인트를 캐싱하는 가장 간단한 방법입니다.

## CacheManager로 수동 캐싱 (더 많은 제어)

```ts
@Injectable()
export class ProductsService {
  constructor(@Inject(CACHE_MANAGER) private cache: Cache) {}

async getProduct(id: string) {
    const cached = await this.cache.get(`product:${id}`);   // 먼저 캐시 확인
    if (cached) return cached;                               // 캐시 HIT

const product = await this.db.findProduct(id);           // 캐시 MISS — 가져옴
    await this.cache.set(`product:${id}`, product, 3600000); // 저장 (1시간 TTL)
    return product;
  }
}
```

`CACHE_MANAGER`를 주입하면 완전한 제어가 가능합니다 — 특정 비싼 작업을 캐싱하기 위한 get-or-fetch 패턴(캐시 확인, 소스로 폴백, 결과 저장).

## Redis로 분산 캐싱 (여러 인스턴스)

```ts
CacheModule.registerAsync({
  useFactory: async () => ({
    store: await redisStore({ url: process.env.REDIS_URL }),   // Redis를 store로 사용
    ttl: 60000,
  }),
});
```

동일한 API를 **Redis**로 백업하면 모든 앱 인스턴스에 걸친 **공유** 캐시가 됩니다 — 여러 인스턴스를 실행할 때 필수적입니다(인메모리 캐시는 인스턴스 간에 공유되지 않음).

## 어려운 부분: 캐시 무효화

```ts
async updateProduct(id: string, data) {
  await this.db.update(id, data);
  await this.cache.del(`product:${id}`);   // 변경 시 무효화 → 오래된 데이터 방지
}
```

```text
가장 큰 캐싱 과제: 무효화(INVALIDATION). 데이터가 변경되면 캐시를 지우거나
갱신해야 합니다. 아니면 사용자가 오래된 데이터를 봅니다. 전략: TTL(짧은 staleness
허용), 쓰기 시 명시적 삭제(cache.del), 또는 cache tag.
```

## 왜 중요한가

캐싱은 백엔드 애플리케이션에 가장 영향력이 큰 성능 최적화 중 하나이며, NestJS의 내장 캐싱 module은 이를 깔끔하고 일관되게 만듭니다.

읽기가 많은 API가 비싼 작업(데이터베이스 쿼리, 외부 API 호출, 계산)을 캐싱함으로써 엄청난 이득을 보므로 이를 이해하는 것이 중요합니다 — 지연 시간과 부하를 극적으로 줄입니다.

NestJS는 간단한 자동 캐싱(GET 엔드포인트를 위한 `CacheInterceptor`)과 세밀한 수동 제어(특정 작업을 위한 `CACHE_MANAGER` get-or-fetch 패턴) 모두를 제공합니다.

결정적으로, 통합 API는 다양한 store와 함께 작동하므로 동일한 코드가 **인메모리 캐싱**(빠름, 단일 인스턴스) 또는 **Redis**(여러 인스턴스에 걸친 공유 캐시)를 사용할 수 있습니다 — 그리고 수평 확장 시 인메모리 캐시가 *공유되지 않는다*는 것(분산 캐싱에 Redis 필요)을 아는 것은 중요한 아키텍처 포인트입니다.

마찬가지로 중요한 것은 캐싱의 핵심 난점 — **무효화**(오래된 데이터 제공을 피하기 위해 데이터가 변경될 때 TTL이나 명시적 삭제를 통해 캐시를 지우거나 갱신) — 를 이해하는 것입니다. 이를 잘못하는 것이 고전적인 캐싱 실패이기 때문입니다.

언제 어떻게 캐싱을 적용할지 알고, 배포에 맞는 올바른 store를 선택하고, 무효화를 올바르게 처리하는 것은 빠르고 확장 가능한 NestJS service를 구축하는 데 가치 있는 시니어 수준 지식입니다.