인터셉터 , 캐시

1️⃣ 인터셉터(Interceptor) — 요청 흐름 제어용

정체성: 요청/응답을 가로채서 공통 로직을 실행하는 미들웨어

역할

• 컨트롤러 전/후/완료 시점에 훅(hook)
• 검증·로깅·권한·컨텍스트 세팅 담당

언제 쓰나

• 인증/인가 체크
• 요청 파라미터 검증
• 트랜잭션/로깅/감사(Audit)
• 공통 헤더 처리

타이밍

• preHandle : 컨트롤러 전
• postHandle : 컨트롤러 후, 뷰 렌더링 전
• afterCompletion : 요청 완료 후

❌ 비즈니스 로직 넣는 곳 아님
❌ 성능 최적화 목적 아님

---

2️⃣ 캐시(Cache) — 성능 최적화용

정체성: 같은 계산/조회 결과를 재사용해서 속도 개선

역할

• DB / 외부 API 호출 감소
• 응답 시간 단축
• 시스템 부하 감소

언제 쓰나

• 조회가 잦고 변경이 적은 데이터
• 동일 입력 → 동일 출력
• 비용 큰 연산 결과

대표 사용

• @Cacheable : 캐시 있으면 바로 반환
• @CacheEvict : 갱신/삭제
• @CachePut : 항상 갱신

❌ 무조건 쓰면 안 됨
❌ 정합성(캐시 무효화) 설계가 핵심

---

3️⃣ 한 줄 비교 (업무 관점)

구분                                                              인터셉터                                                  캐시

목적	흐름 제어	성능 개선
대상	HTTP 요청/응답	데이터/결과
위치	컨트롤러 앞뒤	서비스/리포지토리
핵심	공통 정책	재사용
잘못 쓰면	스파게티 로직	데이터 불일치

---

4️⃣ 같이 쓰는 패턴 (실전)

전형적인 구조

1. 인터셉터
   → 인증/권한 체크
   → 요청 컨텍스트 세팅
2. 컨트롤러
3. 서비스 + 캐시
   → 조회 결과 캐싱

 

 

---

5️⃣ 결론 (실무 판단 기준)

• 공통 정책 / 흐름 제어 → 인터셉터
• 속도 / 비용 / 트래픽 → 캐시
• 둘은 대체 관계 아님, 역할 완전히 다름