[Django] DRF(Django REST Framework) 안 쓰고 있는데, 이대로 괜찮나

배경

설정 정리(감사) 작업을 하다가 settings/base.py에 REST_FRAMEWORK 설정 항목이 있는 걸 발견했다. 근데 INSTALLED_APPS엔 rest_framework 자체가 설치조차 안 되어 있었고, 프로젝트 전체를 뒤져봐도 import rest_framework 하는 코드가 한 줄도 없었다. 즉 이 설정을 읽어가는 코드가 프로젝트 안에 아예 존재하지 않는 죽은 설정값이었다.

지운 게 로그인/인증에 영향이 없는 이유

REST_FRAMEWORK 설정(SessionAuthentication, IsAuthenticated 등)은 Django REST Framework(DRF) 패키지 전용 옵션이다 — REST API 엔드포인트(/api/... 같은 JSON API)를 만들 때 쓰는 설정이지, 웹 화면 로그인이랑은 무관하다.

이 프로젝트의 실제 로그인/인증은 Django 기본 django.contrib.auth(세션 기반)로 동작한다. LoginRequiredMixin, PasswordChangeView 등을 쓰고 있고, INSTALLED_APPS/MIDDLEWARE에도 django.contrib.auth가 정상적으로 들어가 있다. 이건 REST_FRAMEWORK 설정과 완전히 별개다.

그래서 REST_FRAMEWORK 설정 삭제는 로그인/인증 동작에 아무 영향이 없다. 아마 예전에 "나중에 API를 DRF로 만들자"는 계획이 있었다가 실제로는 진행되지 않고 설정만 남아있던 흔적으로 보인다.

그럼 지금 API(AJAX)들은 뭘로 짜여 있나

지금 프로젝트의 AJAX/API 성격 엔드포인트(검색 자동완성 API 등)들은 전부 DRF가 아니라 일반 Django 뷰 함수/클래스에서 JsonResponse를 직접 반환하는 방식으로 짜여 있다. DRF의 Serializer, ViewSet, APIView 같은 건 코드 어디에도 안 쓰인다.

• 지금: REST_FRAMEWORK 설정이 없어도 이 JSON 응답 방식의 API들은 100% 그대로 동작한다 (애초에 그 설정을 참조하지 않았으니까)
• 나중에: 만약 진짜 DRF를 도입하기로 하면, 그때 pip install djangorestframework + INSTALLED_APPS에 "rest_framework" 추가 + REST_FRAMEWORK 설정을 다시 넣으면 된다. 지금 지운 건 "당장 필요없는 걸 치운 것"이지 "나중에 못 쓰게 막은 것"은 아니다 — 언제든 복구 가능

그대로 유지(순수 Django + JsonResponse) vs DRF, 뭐가 다른가

지금 방식 (순수 Django 뷰 + JsonResponse)

장점

• 의존성 추가 없음, 러닝커브 없음 — Django 기본기만 알면 됨
• "간단한 JSON 몇 개 필드 반환" 같은 작업은 오히려 코드가 더 짧고 직관적 (return JsonResponse({...}) 한 줄)
• 프로젝트가 기본적으로 서버사이드 렌더링(템플릿) 기반이고, API는 어디까지나 화면 보조용(자동완성, 인라인 갱신)이라 지금 구조가 목적에 잘 맞음

단점

• 엔드포인트가 늘어날수록 페이지네이션, 검증, 에러 포맷을 매번 손으로 맞춰야 함 (이미 공통 유틸 파일에 페이지네이션 로직을 직접 구현해둔 상태 — 이게 사실 DRF가 기본 제공하는 기능을 자체 구현한 것)
• 응답 포맷이 앱마다 미묘하게 달라질 위험 (비슷한 기능의 유틸이 여러 파일에 중복 구현되는 것도 이런 종류의 문제)

DRF를 썼다면/쓴다면

장점

• Serializer로 입력 검증 + 출력 직렬화를 한 곳에서 선언적으로 관리 (지금은 각 뷰에서 수동으로 dict 조립)
• ViewSet + Router로 CRUD 엔드포인트를 몇 줄로 자동 생성, 페이지네이션·필터링·정렬을 설정만으로 적용
• 인증/권한 클래스(IsAuthenticated 등)를 API 단위로 세분화해서 다르게 걸 수 있음 (지금은 권한 체계가 뷰 Mixin 기반이라 화면 접근 제어와 API 접근 제어가 같은 체계를 쓰는데, 이게 나쁜 건 아니다)
• 브라우저블 API(웹에서 바로 API 테스트 가능한 UI), OpenAPI 스키마 자동 생성 등 개발 편의 도구
• 외부 클라이언트(모바일 앱, 별도 SPA 프론트엔드, 타 시스템 연동)가 생기면 진가를 발휘함

단점

• 지금처럼 "화면 보조용 AJAX 몇 개"에는 오버엔지니어링 — Serializer 클래스 만들고 라우터 설정하는 게 오히려 JsonResponse 한 줄보다 번거로움
• 학습 비용 + 의존성 하나 추가

결론

지금처럼 템플릿 기반 사내 시스템 + 화면 보조용 소규모 API라면 지금 방식(순수 Django + JsonResponse)이 적절하다. DRF는 "이 시스템을 API 서버로 삼아 별도 프론트엔드(React 등)나 모바일 앱, 외부 연동을 붙일 계획"이 생겼을 때 전환을 고려하면 된다.

지금 구조에서 나중에 DRF가 필요해지면, 처음부터 DRF로 시작한 것보다는 손이 조금 더 가겠지만(기존 API를 DRF 스타일로 재작성) 불가능한 전환은 아니다. 지금 급하게 결정할 문제는 아니라는 결론.