Django에서 요청 생명주기는 어떻게 동작하나요?

Question

IT Interview Practice · Accepted Answer

Django에서 요청은 **WSGI/ASGI handler**에 의해 처리되고, **middleware** 스택에 감싸이며, **URL resolver**에 의해 **view**로 라우팅되고, `HttpResponse`로 변환되어 동일한 middleware를 역순으로 통과하며 다시 바깥으로 흘러나갑니다.

## 단계

```
Web server ──▶ WSGI/ASGI handler  (HttpRequest 생성)
   ▼
Middleware — request 단계           (위 → 아래: get_response 전의 __call__)
   ▼
URL resolver (urls.py)  ── path 매칭 → view + kwargs
   ▼
Middleware — process_view 훅
   ▼
View (function / class-based)  ── 여러분의 로직, HttpResponse 반환
   ▼
Middleware — response 단계          (아래 → 위: get_response 후)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — WSGI(동기) 또는 ASGI(비동기) handler가 environ/scope로부터 `HttpRequest`를 만듭니다.
2. **Middleware, request 단계** — 각 middleware의 `get_response()` *이전* 코드가 위에서 아래로 실행됩니다(`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). 그중 어느 것이든 흐름을 중단하고 response를 조기에 반환할 수 있습니다.
3. **URL 해석** — `ROOT_URLCONF` 패턴이 path와 매칭되어 view를 선택하고 kwargs를 캡처합니다.
4. **`process_view`** — view가 호출되기 직전에 실행되는 middleware 훅입니다.
5. **View** — 여러분의 함수 기반 또는 클래스 기반 view가 실행되어, 보통 모델을 쿼리하고 템플릿을 렌더링한 뒤 `HttpResponse`를 반환합니다. 예외는 `process_exception`을 트리거합니다.
6. **Middleware, response 단계** — `get_response()` *이후* 코드가 아래에서 위로 실행되어, middleware가 나가는 response(header, 압축)를 수정할 수 있게 합니다.
7. `HttpResponse`가 서버와 클라이언트로 스트리밍되어 돌아갑니다.

```python
# middleware.py
class TimingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

def __call__(self, request):          # 2. request 단계 (전)
        request.started = time.monotonic()
        response = self.get_response(request)  # 다음 레이어 / view 호출
        response["X-Time"] = "..."         # 6. response 단계 (후)
        return response

# urls.py  → 3. routing
urlpatterns = [path("items/<int:pk>/", views.item_detail)]

# views.py → 5. view
def item_detail(request, pk):
    return render(request, "item.html", {"item": Item.objects.get(pk=pk)})
```

## 왜 중요한가

Django의 request/response 사이클은 middleware 중심이므로, 대부분의 횡단 관심사 동작 — auth, session, CSRF, security header, 캐싱 — 은 순서가 정해진 middleware로 구현됩니다. request 단계 코드는 위에서 아래로, response 단계 코드는 아래에서 위로 실행된다는 것(그리고 `MIDDLEWARE`의 순서가 중요하다는 것)을 이해하는 것은 여러분의 middleware를 올바르게 배치하고, 왜 `403`/리다이렉트가 여러분의 view보다 먼저 발생하는지 디버깅하며, 모든 view를 건드리지 않고 어디에 로직을 후킹할지 아는 데 필수적입니다.

단계

왜 중요한가

관련 질문