Negative Caching이란?
캐싱이라고 하면 보통 자주 조회되는 데이터를 저장해 두었다가 빠르게 응답하는 기술을 떠올립니다. 그런데 Negative Caching은 조금 다릅니다. 이는 ‘존재하지 않는 데이터’에 대한 조회 결과, 즉 실패 응답 자체를 캐싱하는 기법입니다. 예를 들어 사용자가 존재하지 않는 회원 ID로 조회를 요청했을 때, 시스템이 DB까지 가서 ‘없음’을 확인하고 그 결과를 잠시 저장해 두는 것입니다. 다음에 같은 요청이 들어오면 DB를 다시 조회하지 않고 캐시에 저장된 ‘없음’ 응답을 바로 돌려줍니다.
동작 원리와 예시
일반적인 캐싱은 ‘값이 있을 때’만 캐시에 저장하지만, Negative Caching은 조회 결과가 null이거나 404 같은 실패 상태일 때도 이를 캐시에 기록합니다. 예를 들어 DNS 조회를 생각해보면 이해하기 쉽습니다. 존재하지 않는 도메인을 조회하면 DNS 서버는 NXDOMAIN 응답을 반환하는데, 이 결과도 일정 시간 캐싱됩니다. 그래야 같은 존재하지 않는 도메인에 대해 매번 전체 DNS 트리를 다시 탐색하지 않아도 됩니다.
애플리케이션 레벨에서도 마찬가지입니다. 예를 들어 다음과 같이 캐시를 구성할 수 있습니다.
get(key)호출 시 캐시에 값이 있으면 즉시 반환- 캐시에 없으면 DB 조회 후, 결과가 없어도 ‘NOT_FOUND’ 같은 특수 값을 캐시에 저장
- 다음 요청부터는 DB 접근 없이 ‘NOT_FOUND’를 반환
이때 중요한 점은 Negative Cache의 TTL(유효 시간)을 일반 캐시보다 짧게 설정하는 것입니다. 나중에 실제로 데이터가 생성될 수 있기 때문에 너무 오래 캐싱하면 새로 생긴 데이터를 계속 ‘없음’으로 잘못 응답하게 됩니다.
실무에서 왜 필요한가
Negative Caching이 없다면 존재하지 않는 리소스에 대한 반복 요청이 그대로 DB나 백엔드 시스템에 부하를 줍니다. 특히 악의적인 사용자가 존재하지 않는 ID를 무작위로 대량 요청하는 경우, 이는 일종의 서비스 거부 공격(DoS)처럼 작동할 수 있습니다. 캐시가 있는 값만 저장한다면 이런 요청은 매번 캐시를 우회해 DB까지 도달하게 되고, 결국 시스템 전체 성능 저하로 이어집니다.
따라서 Negative Caching은 단순한 성능 최적화를 넘어 시스템을 보호하는 역할도 합니다. 실제로 CDN, DNS, API 게이트웨이, ORM 캐시 레이어 등 다양한 곳에서 이 개념이 활용되며, ‘없다는 사실’ 역시 하나의 유효한 데이터로 취급해 캐싱 전략에 포함시키는 것이 안정적인 시스템 설계의 핵심입니다.