🧅

Django Middleware — 요청/응답을 감싸는 양파 구조

MIDDLEWARE 설정 순서가 왜 중요한지, 내부에서 어떻게 체이닝되는지

MIDDLEWARE = [
    'SecurityMiddleware',      # 1번째: 가장 바깥
    'SessionMiddleware',       # 2번째
    'CommonMiddleware',        # 3번째
    'AuthenticationMiddleware', # 4번째: 가장 안쪽
]

요청이 들어오면: Security → Session → Common → Auth → View
응답이 나가면: View → Auth → Common → Session → Security

양파를 까는 것처럼 들어가고, 다시 껍질을 입히듯 나온다.

내부 구현

Django 3.1+부터 미들웨어는 ASGI/WSGI 호환 callable이다:

class SimpleMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response  # 다음 미들웨어 (또는 View)

    def __call__(self, request):
        # 요청 처리 (바깥 → 안)
        response = self.get_response(request)  # 다음 단계 호출
        # 응답 처리 (안 → 바깥)
        return response

get_response가 체인의 다음 링크다. Django가 서버 시작 시 MIDDLEWARE 리스트를 역순으로 순회하면서 각 미들웨어의 get_response에 다음 미들웨어를 연결한다.

순서가 중요한 이유

SessionMiddlewareAuthenticationMiddleware보다 앞에 있어야 한다 — Auth가 세션에서 유저 정보를 읽기 때문. 순서를 바꾸면 request.user가 항상 Anonymous가 된다.

핵심 포인트

1

MIDDLEWARE 리스트 순서 = 요청 처리 순서 (역순으로 체이닝)

2

get_response(request) 호출이 다음 미들웨어/View를 실행

3

요청: 바깥→안, 응답: 안→바깥 (양파 구조)

4

Session이 Auth보다 먼저 와야 request.user가 작동한다

사용 사례

커스텀 로깅 — 요청/응답을 감싸서 처리 시간 측정 CORS 처리 — CorsMiddleware가 응답 헤더를 추가

참고 자료