---
category: AI_and_ML
tags: [auto-wikified, technical-documentation, merged, ai_and_ml]
title: Filters
description: "Filters(필터)는 소프트웨어 프레임워크에서 HTTP 요청과 응답을 가로채어 처리하는 하위 수준의 컴포넌트이자 교차 절단 관심사(Cross-Cutting Concerns)를 다루는 주요 아키텍처 패턴입니다."
last_updated: 2026-05-04
---

# Filters


## 📌 Brief Summary
Filters(필터)는 소프트웨어 프레임워크에서 HTTP 요청과 응답을 가로채어 처리하는 하위 수준의 컴포넌트이자 교차 절단 관심사(Cross-Cutting Concerns)를 다루는 주요 아키텍처 패턴입니다. Spring Boot와 같은 프레임워크에서는 서블릿 계층에서 동작하여 MVC 컨트롤러에 도달하기 전의 모든 요청을 가로챕니다 [1]. NestJS에서는 애플리케이션 전반의 처리되지 않은 예외를 포착하여 일관성 있는 응답으로 변환하는 예외 필터(Exception Filters)의 형태로 주로 활용됩니다 [2]. 

## 📖 Core Content
* **Spring Boot에서의 필터의 역할과 특징** 
  * 필터는 Spring MVC와는 독립적으로 동작하는 Servlet API의 일부(`javax.servlet.Filter` 인터페이스)입니다 [1, 3].
  * HTTP 요청이 DispatcherServlet에 도달하기 전, 그리고 응답이 반환된 후에 동작하는 하위 수준(low-level) 컴포넌트로 기능합니다 [1, 3].
  * 특정 컨트롤러뿐만 아니라 정적 리소스를 포함한 모든 HTTP 요청에 대해 작동한다는 특징이 있습니다 [1, 3].
  * 주로 CORS(교차 출처 리소스 공유) 핸들링, 인증(Authentication) 및 인가, 요청 및 응답 로깅, 응답 압축 및 캐싱, 요청/응답 객체 수정 등의 범용적이고 전역적인 HTTP 처리에 적합하게 사용됩니다 [1, 3, 4].

* **NestJS에서의 예외 필터(Exception Filters)**
  * NestJS 환경에서 필터는 주로 애플리케이션 내의 처리되지 않은 예외(Unhandled exceptions)를 포착하고 사용자 친화적인 응답을 자동으로 구성하여 반환하는 '예외 계층(Exceptions layer)'으로 활용됩니다 [2].
  * 대규모 프로젝트에서는 에러 핸들링을 중앙 집중화하기 위해 전역 필터(Global Filter)로 구현(`main.ts`에 등록 등)하는 것이 모범 사례로 꼽힙니다 [5].
  * 이를 통해 개별 컨트롤러가 각기 다른 방식으로 오류를 포맷팅하는 것을 방지하고, 전체 API 엔드포인트에 걸쳐 오류 응답 형식을 일관되게 유지할 수 있습니다 [5].

* **다른 횡단 관심사 패턴(인터셉터 및 AOP)과의 계층적 차이**
  * 교차 절단 관심사를 처리할 때 필터는 '서블릿 레이어(Servlet layer)'에서 작동하여 가장 바깥쪽에서 요청을 제어합니다 [3, 4]. 
  * 이와 대비하여 인터셉터(Interceptors)는 Spring MVC 계층 내에서 컨트롤러 메서드 실행 전후를 감싸며 동작하고, AOP(관점 지향 프로그래밍)는 어떠한 Spring Bean 메서드(컨트롤러, 서비스, 리포지토리 등)에나 적용되어 비즈니스 로직 건드림 없이 기능을 주입한다는 점에서 명확한 구조적 차이가 있습니다 [3, 4, 6, 7].

## ⚖️ Trade-offs & Caveats
* **넓은 동작 범위로 인한 성능 오버헤드 위험성** [1, 3]
  * Spring Boot에서 필터는 정적 리소스를 포함해 애플리케이션으로 들어오는 **모든 HTTP 요청**에 대해 예외 없이 실행됩니다. 따라서 필터 내에 복잡한 연산이나 무거운 외부 시스템 호출 로직을 포함할 경우, 전체 시스템의 병목 현상 및 성능 저하를 초래할 위험이 있습니다.
* **세밀한 제어(Fine-grained control)의 한계** [3]
  * 필터는 Spring MVC의 디스패처 서블릿 외부에서 전역적으로 동작하기 때문에, 특정 컨트롤러나 개별 메서드 단위로 로직을 적용하기에는 적합하지 않습니다. 선택적인 적용이나 메서드 레벨의 세밀한 제어가 필요할 때는 필터보다는 AOP 체계나 인터셉터를 사용하는 것이 바람직한 기술적 선택입니다.
* **오류 형식 중앙 집중화의 경직성** [2, 5]
  * NestJS 등에서 전역 예외 필터를 사용하여 오류 처리 형식을 통일하면 유지보수성이 높아지지만, 모든 오류 응답이 동일한 파이프라인을 타게 되므로 특정 엔드포인트에만 특수한 오류 페이로드나 예외 로직이 필요한 경우에는 유연성이 다소 떨어질 수 있습니다.


---
*Last updated: 2026-05-03*

## 📚 Legacy Insights & Additional Context
> [!NOTE]
> Below is content merged from previous versions of this documentation.

## 📌 한 줄 통찰 (The Karpathy Summary)
> "없다는 것은 확실히 알지만, 있다는 것은 가끔 착각한다." 공간 효율성을 극대화한 확률적 자료구조로, 거대한 데이터 집합에서 특정 원소가 포함되어 있는지 '초고속'으로 확인하는 선별 장치다.

## 📖 구조化된 지식 (Synthesized Content)
- **Probabilistic Membership**:
    - "원소가 집합에 있는가?"에 대해 "없음"(100% 확실) 또는 "있을지도 모름"(False Positive 발생 가능)으로 답한다.
- **Space [[Efficiency|Efficiency]]**:
    - 실제 원소를 저장하지 않고 해시 함수와 비트 배열(Bit Array)만 사용하므로, 메모리 사용량을 획기적으로 줄인다.
- **Use Cases**:
    - 데이터베이스의 불필요한 디스크 읽기 방지, 악성 URL 차단 목록 확인, 대규모 네트워크 라우팅 등에서 전방 필터로 활약한다.

## ⚠️ 모순 및 업데이트 (RL Update)
- 블룸 필터의 성능 관건은 False Positive 확률을 낮추는 것이다. 비트 배열의 크기와 해시 함수의 개수를 데이터 양에 맞게 정밀하게 계산하는 수학적 튜닝이 필수적이다.

## 🔗 지식 연결 (Graph)
- Related: Hash-Functions , [[Big-Data|Big-Data]]-[[Processing|Processing]]
- Foundation: Computational Theory & Math/Information Theory
