Django에서 HttpResponse와 DRF Response 차이점

Django HttpResponse를 이용한 커스텀 응답 생성

Django에서 **HttpResponse**는 HTTP 응답을 반환하는 가장 기본적인 클래스입니다. 모든 Django 뷰 함수/메서드는 최종적으로 HttpResponse 객체 (혹은 그 하위 클래스)를 반환해야 합니다. HttpResponse는 django.http 모듈에 포함되어 있으며, 문자열이나 바이트 데이터를 인자로 받아 응답 객체를 생성합니다. 기본 콘텐츠 타입은 "text/html"이지만 필요에 따라 content_type 매개변수로 변경할 수 있습니다. 또한 상태 코드를 지정하려면 status 매개변수를 사용합니다 (기본값 200). 개발자는 HttpResponse를 통해 응답 본문, 헤더, 쿠키 등을 직접 구성할 수 있습니다.

• 문자열/HTML 응답 예시: 간단한 문자열을 응답으로 돌려주려면 다음과 같이 사용할 수 있습니다.

# views.py
from django.http import HttpResponse

def hello_view(request):
    return HttpResponse("Hello, Django!", content_type="text/plain", status=200)

위 예에서는 "Hello, Django!"라는 평문 텍스트를 응답 본문으로 하여 HttpResponse를 생성하고 있습니다. content_type을 "text/plain"으로 지정하여 단순 텍스트임을 명시했고, 상태 코드를 200으로 설정했습니다 (사실 200은 디폴트 값이므로 명시하지 않아도 됩니다).

• JSON 응답 예시: Django 기본 기능만으로 JSON 데이터를 반환하려면 두 가지 방법이 있습니다. 첫째, Python 객체(예: 딕셔너리)를 직접 JSON 문자열로 직렬화(json.dumps)한 뒤 그 문자열을 HttpResponse로 감싸는 방법입니다. 둘째, Django가 제공하는 편의 클래스인 **JsonResponse**를 사용하는 것입니다. JsonResponse는 HttpResponse를 상속받은 클래스이며, 주어진 딕셔너리를 자동으로 JSON으로 직렬화해 주고 Content-Type을 "application/json"으로 설정해 줍니다.

# views.py
import json
from django.http import HttpResponse, JsonResponse

def sample_json_view(request):
    data = {"message": "안녕하세요, Django!"}
    # 방법 1: 수동 직렬화 후 HttpResponse 사용
    json_str = json.dumps(data, ensure_ascii=False)
    return HttpResponse(json_str, content_type="application/json", status=200)

    # 방법 2: JsonResponse 사용 (더 편리)
    # return JsonResponse(data, status=200)

위 코드에서 방법 1은 json.dumps로 Python 딕셔너리를 JSON 형식의 문자열로 변환한 뒤 HttpResponse로 반환합니다. 방법 2는 JsonResponse를 사용하여 Django가 직렬화를 처리하도록 합니다. JsonResponse를 사용하면 내부적으로 json.dumps()를 호출하고 안전하게 JSON 응답을 만들어주므로, 일반적인 웹뷰에서 간단한 AJAX 요청에 응답할 때 편리합니다. 단, JsonResponse는 Django에 내장된 기본 기능만 활용하므로 고급 기능(예컨대 콘텐츠 협상이나 다양한 포맷 지원 등)은 제공하지 않습니다.

Django REST Framework(DRF)의 Response 객체 구조와 동작

Django REST Framework는 Django 기반의 강력한 RESTful API 프레임워크로, 여기서 제공하는 Response 클래스는 웹 API 응답을 쉽게 처리하도록 만들어졌습니다. DRF의 Response는 Django의 SimpleTemplateResponse를 상속하는 객체로서, HttpResponse의 한 형태입니다. 다만 동작 방식은 기본 HttpResponse와 약간 다릅니다.

• 초기화와 데이터 구조: Response를 생성할 때는 렌더링되지 않은 데이터(보통 파이썬 기본 자료형인 dict, list, str 등)로 초기화합니다. 즉, HttpResponse처럼 미리 직렬화된 문자열을 넣는 것이 아니라, 파이썬 객체를 그대로 넣으면 됩니다. 예를 들어, DRF의 Response에 딕셔너리를 넘기면 나중에 JSON 등의 포맷으로 변환될 때까지 해당 딕셔너리 상태로 유지됩니다. 이 때 Response.data 속성에 원본 데이터가 저장되고, status_code, headers 등의 속성도 사용할 수 있습니다. Response 객체는 나중에 .render() 메서드가 호출되기 전까지는 콘텐츠를 변환하지 않고 들고 있으며, 적절한 **렌더러(renderer)**가 선택되면 그제서야 최종 바이트 콘텐츠로 직렬화됩니다.
• 콘텐츠 협상 및 렌더링: DRF Response는 HTTP 콘텐츠 협상(content negotiation) 규칙을 따릅니다. 클라이언트의 Accept 헤더나 요청 특성에 따라 어떤 포맷으로 응답할지 자동 결정합니다. 예를 들어 기본 설정에서는 JSON 렌더러가 사용되지만, 클라이언트가 "text/html"을 요청하고 DRF Browsable API가 활성화되어 있다면 브라우저에서 볼 수 있는 HTML 형태로도 응답할 수 있습니다. DRF Response 클래스 자체가 이러한 협상을 지원하며, 여러 가지 콘텐츠 유형으로 변환 가능한 데이터를 품고 있다가, 최종적으로 적합한 렌더러가 선택되어 .render()를 실행하면 그때 출력용 콘텐츠(bytes)가 만들어집니다. 이 과정은 일반적으로 Django의 템플릿 응답 처리 단계에서 이루어지거나, DRF가 제공하는 APIView를 사용할 경우 명시적으로 Response를 마무리(.render())하면서 수행됩니다.
• 구조 요약: Response는 실질적으로 Django의 TemplateResponse와 유사하게 **지연된 렌더링(lazy rendering)**을 합니다. 개발자가 Response에 파이썬 데이터를 넣고 반환하면, DRF는 적절한 시점에 그 데이터를 직렬화하여 응답 본문(Response.content)을 생성합니다. 또한 Response 객체에는 accepted_renderer, accepted_media_type, renderer_context 같은 속성이 있어 어떤 렌더러와 미디어 타입이 선택되었는지 정보를 담고 있습니다. 이러한 속성들은 주로 DRF의 뷰/미들웨어 계층에서 설정됩니다. 요약하면, DRF의 Response는 **“필요한 데이터를 들고 있다가, 나중에 적절한 형태로 변환되는 응답”**이라고 볼 수 있습니다.
• 사용 예시: DRF에서 Response는 보통 APIView나 @api_view 데코레이터와 함께 사용됩니다. 예를 들어, 아래와 같이 함수 기반 뷰에 @api_view 데코레이터를 적용하면 DRF의 요청/응답 사이클을 사용하게 되고, 이 안에서 Response를 반환할 수 있습니다.

# views.py (DRF 활용 예시)
from rest_framework.response import Response
from rest_framework.decorators import api_view

@api_view(['GET'])
def sample_api(request):
    data = {"message": "Hello, DRF!"}
    return Response(data, status=200)

위 예시에서는 Response에 파이썬 딕셔너리 data를 직접 넣어서 반환했습니다. DRF는 이 데이터를 자동으로 JSON으로 직렬화하여 응답합니다 (기본 설정일 경우). 상태 코드는 status=200으로 지정했고, 추가로 필요하면 headers={'X-Example': 'value'} 같은 헤더도 생성자에 전달할 수 있습니다. DRF Response는 내부적으로 DRF의 여러 기능과 연동되므로, 반드시 DRF의 뷰 클래스/데코레이터 환경에서 사용하는 것이 권장됩니다. 일반 Django 뷰에서 Response 객체를 바로 반환할 수도 있지만, 이 경우 콘텐츠 협상 등의 이점은 제한적으로밖에 활용되지 못합니다.

HttpResponse와 DRF Response의 주요 차이점

앞서 살펴본 두 방식의 응답 객체는 목적이 비슷하지만 구현과 기능 면에서 몇 가지 중요한 차이점이 있습니다. 아래에 대표적인 차이점을 정리합니다:

• 데이터 준비 및 직렬화 방식: HttpResponse는 반환 시에 이미 변환된 최종 문자열을 필요로 합니다. 예를 들어 파이썬 딕셔너리를 바로 HttpResponse에 넣을 수 없고, str()로 변환되기 때문에 원하지 않는 형식이 될 수 있습니다. 개발자가 수동으로 json.dumps() 등을 호출해 응답 본문을 미리 준비해야 합니다. 반면 DRF Response는 직렬화되지 않은 파이썬 데이터를 그대로 받아들입니다. 내용이 렌더링(직렬화)되는 시점이 지연되므로, 응답을 반환하는 시점까지는 Python 객체 형태로 데이터를 가지고 있고, 적절한 렌더러가 선택된 후에 JSON/XML 등으로 변환합니다. 요약하면, HttpResponse는 즉시 렌더링된 콘텐츠를 다루고, Response는 나중에 렌더링될 데이터를 다룹니다.
• 콘텐츠 협상 및 포맷 지원: 기본 HttpResponse (및 JsonResponse)는 콘텐츠 협상 기능이 없습니다. 개발자가 응답 콘텐츠와 MIME 타입을 직접 정하면, 클라이언트 요청과 무관하게 그 형식으로 응답합니다. 예를 들어 JsonResponse는 항상 JSON (application/json)으로 반환합니다. DRF의 Response는 클라이언트의 요청에 따라 응답 포맷을 자동 결정할 수 있습니다. DRF 설정에 따라 JSON 외에도 XML, YAML, HTML 등 다양한 포맷으로 응답을 내보낼 수 있고, Accept 헤더를 기반으로 가장 적합한 콘텐츠 타입을 선택합니다. 이러한 콘텐츠 협상 덕분에 하나의 Response로 여러 형식의 응답을 유연하게 처리할 수 있습니다.
• 미들웨어 연동과 렌더링 타이밍: Django의 응답 처리 파이프라인에서, HttpResponse 객체는 뷰에서 반환될 때 이미 완전히 렌더링 완료된 상태입니다. 따라서 Django의 일반적인 process_response 미들웨어들을 그대로 통과합니다. 반면 DRF Response는 Django의 SimpleTemplateResponse를 상속하기 때문에, 템플릿 응답과 유사하게 .render() 호출 전까지 지연된 상태로 존재합니다. Django는 TemplateResponse를 반환할 경우 process_template_response 미들웨어 훅을 통해 응답을 조작할 기회를 주고, 최종적으로 자동 렌더링을 합니다. DRF Response도 이와 같이 템플릿 응답 미들웨어와 호환되며, 만약 DRF의 APIView를 사용한다면 APIView 내부에서 Response의 .render()가 호출되어 미들웨어 전에 렌더링이 완료되기도 합니다. 요컨대, Response는 Django의 응답 사이클에 녹아들어 필요한 시점까지 렌더링을 미루는 반면, HttpResponse는 즉시 콘텐츠가 확정됩니다.
• 부가 기능 및 REST 프레임워크 통합: HttpResponse는 Django 기본 기능만을 활용하므로 경량이며 추가적인 기능은 최소화되어 있습니다. 반면 DRF Response는 DRF와 긴밀히 통합되어 여러 편의 기능을 제공합니다. 예를 들어 DRF Response를 사용하면 개발 단계에서 Browsable API(웹으로 보는 API UI)를 자동 제공받을 수 있고, DRF의 예외 처리나 인증/퍼미션 체계와도 자연스럽게 어우러집니다. 또한 DRF Response는 rest_framework.status 모듈을 통해 의미 있는 상수로 상태 코드를 관리하거나, Response 서브클래스를 활용해 커스텀 응답을 만들기 쉽습니다. 반면 기본 HttpResponse만으로는 이러한 REST 특화 기능 (예: 직렬화 헬퍼, 다양한 미디어 타입, API 문서화 지원 등)을 직접 구현해야 합니다. 요약하면, 단순 Django 응답인 HttpResponse에 비해 DRF Response는 REST API 구축에 특화된 풍부한 기능을 내장하고 있습니다.

언제 Custom HttpResponse를 쓰고 언제 DRF Response를 써야 할까?

프로젝트의 목적과 성격에 따라 두 응답 방식 중 적절한 것을 선택하는 것이 중요합니다. 몇 가지 가이드라인을 소개합니다:

• Django 기본 웹앱이나 간단한 JSON 응답의 경우: 만약 DRF를 사용할 정도로 복잡한 API를 만들 필요가 없고, 일반 웹 페이지 내에서 간단히 JSON이나 파일을 반환하는 정도라면 HttpResponse 나 JsonResponse로 충분합니다. 예를 들어 일반 Django 뷰에서 AJAX 요청에 대한 간단한 JSON 데이터를 반환해야 하는 경우, DRF를 도입하지 않고 JsonResponse를 사용하는 편이 오히려 간편합니다. 또한 HTML 페이지 렌더링 응답 (HttpResponse나 render 함수), 이미지/파일 다운로드 응답 (FileResponse 등)처럼 RESTful API와 무관한 응답들도 Django의 기본 HttpResponse 체계로 처리하면 됩니다. Django 자체만으로 처리 가능한 요구사항이라면 굳이 DRF Response를 쓸 필요가 없습니다.
• RESTful API 및 다중 클라이언트 대상 서비스의 경우: 모바일 앱, 외부 서비스 등 다양한 클라이언트가 사용할 본격적인 API를 개발한다면 Django REST Framework를 도입하고 Response를 사용하는 것이 좋습니다. DRF의 Response는 데이터 직렬화, 컨텐츠 협상, 다양한 포맷 지원, 인증/권한 처리와 자연스러운 연계 등 API 구축에 필요한 요소들을 두루 갖추고 있어 생산성을 높여줍니다. 예를 들어 다수의 모델 데이터를 JSON으로 제공하고, 경우에 따라 XML로도 응답해야 하는 요구가 있다면 Response를 통해 손쉽게 지원할 수 있습니다. 또한 DRF의 APIView/ViewSet과 Response를 함께 사용하면 **예외 발생 시 일관된 오류 응답 형식(JSON 에러 메세지 등)**을 얻는 등 통합적인 이점을 누릴 수 있습니다. 요약하면, 웹 API 구현 시에는 DRF Response를, 단순한 웹 응답 시에는 Django HttpResponse를 선택하는 것이 합리적입니다.

예시: HttpResponse vs Response 사용 시나리오

• 시나리오 1: 일반 웹 애플리케이션에서 관리자 페이지용으로 간단한 JSON 통계를 제공하는 엔드포인트가 필요하다면? – 별도의 API 인프라를 구축할 필요 없이 Django의 JsonResponse로 충분히 구현 가능합니다. 이 경우 미들웨어나 브라우저 요청 특성을 고려한 컨텐츠 협상은 불필요하며, 응답 데이터도 비교적 단순합니다.
• 시나리오 2: 공개 REST API 서비스를 만들어 모바일 앱과 웹이 모두 소비하도록 할 계획이라면? – Django REST Framework를 사용하고, 뷰를 APIView/ViewSet으로 구성하며, 응답은 Response로 반환하는 것이 바람직합니다. 이렇게 하면 JSON 외에 다른 포맷도 지원하기 쉽고, 인증/권한/페이지네이션/스키마 문서화 등 향후 확장이 수월합니다.

---

참고 자료: Django 공식 문서의 HttpResponse 객체 설명, DRF 공식 문서의 Response 가이드, 그리고 관련 블로그 포스트를 참조하여 HttpResponse와 DRF Response의 차이점을 정리했습니다. 각 도구의 장단점을 이해하고 적재적소에 활용하면 Django 웹 개발과 API 개발을 더욱 효율적으로 진행할 수 있을 것입니다.