Update: Wikified 129 files from Datacollector_MAC/out_wiki (P-Reinforce v3.0)

10_Wiki/Topics/Middleware & Interceptors.md

@@ -1,13 +1,42 @@
 ---
-id: P-REINFORCE-AUTO-4808EA
-category: "10_Wiki/💡 Topics/Software Engineering"
-confidence_score: 0.95
-tags: [auto-reinforced]
-last_reinforced: 2026-05-03
-github_commit: "[P-Reinforce] Continuous Worker - Middleware & Interceptors"
+category: Middleware & Interceptors.md
+tags: [auto-wikified, technical-documentation, merged, middleware & interceptors.md]
+title: Interceptors
+description: "인터셉터(Interceptors)는 애플리케이션의 핵심 비즈니스 로직을 수정하지 않고도 로깅, 보안, 성능 모니터링 등 횡단 관심사(Cross-cutting concerns)를 일관되게 처리하기 위해 사용되는 컴포넌트이자 패턴이다 [1, 2]."
+last_updated: 2026-05-04
 ---
 
-# [[Middleware & Interceptors|Middleware & Interceptors]]
+# Interceptors
+
+
+## 📌 Brief Summary
+인터셉터(Interceptors)는 애플리케이션의 핵심 비즈니스 로직을 수정하지 않고도 로깅, 보안, 성능 모니터링 등 횡단 관심사(Cross-cutting concerns)를 일관되게 처리하기 위해 사용되는 컴포넌트이자 패턴이다 [1, 2]. 주로 클라이언트의 요청이 컨트롤러에 도달하기 전이나 컨트롤러가 응답을 반환한 후에 개입하여 사전 및 사후 처리를 수행한다 [2, 3]. Spring Boot, NestJS 등의 현대적인 프레임워크에서 기본적으로 지원되며, 요청 처리 파이프라인을 구조화하고 코드 중복을 줄이는 데 핵심적인 역할을 한다 [4-6].
+
+## 📖 Core Content
+* **Spring Boot의 인터셉터 메커니즘**
+  * Spring Boot에서 인터셉터는 Spring MVC의 기능으로 제공되며, 서블릿 필터(Filter) 이후와 컨트롤러 실행 사이의 단계에서 동작한다 [3].
+  * `HandlerInterceptor` 인터페이스를 구현하여 사용하며, 주로 컨트롤러 요청에 대한 권한 검사(Authorization), 실행 시간 로깅, 요청 속성 수정과 같은 전/후처리 작업에 사용된다 [3, 4, 7].
+
+* **NestJS의 인터셉터 파이프라인**
+  * NestJS는 Angular의 구조적 패턴을 차용하여 요청 처리 파이프라인의 일부로 인터셉터를 제공한다 [5].
+  * 기존 Express 프레임워크의 단순 미들웨어에 비해 인증, 로깅, 유효성 검사 등의 패턴을 훨씬 더 구조화된 방식으로 처리할 수 있게 해준다 [8]. 
+  * 특히 RxJS 스트림을 활용하여 비동기 작업의 흐름을 유연하게 제어할 수 있다는 것이 강력한 장점이다 [2, 6].
+
+* **실전 활용 및 구조적 적용 (공통)**
+  * **캐싱 레이어 구현:** 프레임워크에 관계없이 인터셉터(또는 데코레이터)를 사용하면 기존 비즈니스 로직 코드를 수정하지 않고도 캐싱 동작을 추가할 수 있다 [2].
+  * **모듈화 전략:** NestJS와 같은 환경에서는 여러 기능에서 공통으로 쓰이는 인터셉터를 `SharedModule`이나 `CoreModule`에 선언하여 중앙 집중적으로 구성하고, 일회성 초기화 및 의존성 관리를 수행하는 패턴이 권장된다 [9, 10].
+
+## ⚖️ Trade-offs & Caveats
+* **적용 범위와 계층적 제약 (Spring Boot):** Spring Boot의 인터셉터는 오직 Spring MVC 계층에 종속되어 동작하므로, 정적 리소스를 포함한 모든 HTTP 요청을 제어하는 서블릿 필터(Filter)를 완전히 대체할 수는 없다 [3, 7]. 또한, 컨트롤러 밖의 서비스나 리포지토리 계층의 메서드를 가로채는 데는 사용할 수 없으며, 이러한 세밀한 제어가 필요할 경우 AOP(Aspect-Oriented Programming)를 별도로 활용해야 한다 [3, 7].
+* **초기 학습 곡선 (NestJS):** Express의 단순한 미들웨어 패턴(req, res, next)에 익숙한 개발자가 인터셉터 기반의 처리 파이프라인을 도입할 경우, 의존성 주입(DI) 및 데코레이터 등과 맞물려 초기 학습에 시간이 걸릴 수 있다 [11].
+* **전역(Global) 설정의 남용 위험:** 공통 인터셉터를 선언할 때 편의를 위해 `@Global()` 데코레이터를 사용하여 애플리케이션 전역에서 사용할 수 있게 설정할 수 있다. 하지만 이를 무분별하게 남용할 경우 모듈의 독립성이 저하되고 의존성이 불투명해지는 기술 부채를 유발할 수 있으므로, 진정한 의미의 횡단 관심사에만 제한적으로 사용해야 한다 [9].
+
+---
+*Last updated: 2026-05-03*
+
+## 📚 Legacy Insights & Additional Context
+> [!NOTE]
+> Below is content merged from previous versions of this documentation.
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
 미들웨어(Middleware)와 인터셉터(Interceptor)는 로깅, 인증, 캐싱, 예외 처리와 같이 애플리케이션 전반에 걸쳐 공통으로 요구되는 횡단 관심사(Cross-Cutting Concerns)를 캡슐화하고 중앙 집중화하는 구조적 컴포넌트이다 [1]. 프레임워크에 따라 처리되는 계층이 다르며, 미들웨어는 주로 서블릿이나 HTTP 요청/응답 파이프라인 전반에서 동작하고, 인터셉터와 AOP는 프레임워크의 특정 모델이나 메서드 실행 전후에서 세밀한 흐름 제어를 제공한다 [2-6]. 이를 통해 핵심 비즈니스 로직의 오염을 방지하고 시스템의 유지보수성과 확장성을 높인다 [1, 7].