Django 6 릴리즈

 (docs.djangoproject.com)
6P by GN⁺ | ★ favorite | 댓글 1개
  • 웹 프레임워크 Django의 6.0 버전이 공개되어 Python 3.12 이상을 지원하고, 보안·템플릿·비동기 기능이 대폭 강화됨
  • Content Security Policy(CSP) 가 기본 내장되어 XSS 등 콘텐츠 주입 공격 방어를 위한 정책 설정이 가능함
  • Template Partials 기능으로 템플릿 내 재사용 가능한 부분 정의가 가능해져 코드 모듈화가 향상됨
  • Background Tasks 프레임워크가 추가되어 요청-응답 사이클 외부에서 비동기 작업 실행을 지원함
  • Python 최신 이메일 API 도입, MariaDB 10.5 지원 종료, DEFAULT_AUTO_FIELD 기본값 변경 등으로 호환성 조정과 현대화가 이루어짐

Python 호환성

  • Django 6.0은 Python 3.12, 3.13, 3.14를 지원하며, 각 시리즈의 최신 릴리스만 공식 지원
  • Django 5.2.x는 Python 3.10 및 3.11을 지원하는 마지막 버전임
  • Django 6.0 이후 서드파티 앱은 Django 5.2 이전 버전 지원을 중단할 것을 권장함

주요 신규 기능

Content Security Policy(CSP) 지원

  • Django에 CSP 표준이 내장되어 XSS 등 콘텐츠 주입 공격 방어 강화
    • ContentSecurityPolicyMiddleware, csp() 컨텍스트 프로세서, SECURE_CSP 설정을 통해 정책 정의 가능
    • Python 딕셔너리 기반 설정으로 명확하고 안전한 정책 구성 지원
  • SECURE_CSP_REPORT_ONLY로 모니터링 모드 설정 가능
  • 뷰 단위로 정책을 재정의하거나 비활성화할 수 있는 데코레이터 제공

Template Partials

  • 템플릿 일부(fragment) 를 정의하고 재사용할 수 있는 partialdef 및 partial 태그 추가
  • template_name#partial_name 구문으로 get_template(), render(), {% include %} 등에서 직접 참조 가능
  • 기존 서드파티 패키지 django-template-partials 사용자용 마이그레이션 가이드 제공

Background Tasks 프레임워크

  • Django에 비동기 작업 실행용 내장 프레임워크 추가
    • HTTP 요청-응답 사이클 외부에서 이메일 전송, 데이터 처리 등 수행 가능
    • @task 데코레이터로 작업 정의, enqueue()로 큐에 등록
  • 백엔드는 TASKS 설정으로 지정하며, 개발·테스트용 기본 백엔드 2종 포함
  • Django는 작업 생성과 큐잉만 담당하며, 실행은 외부 워커 프로세스가 수행해야 함

Python 최신 이메일 API 채택

  • Django의 이메일 처리 로직이 Python 3.6 이후의 현대적 이메일 API(email.message.EmailMessage)로 전환
  • 이전 SafeMIMEText, SafeMIMEMultipart 클래스는 더 이상 사용되지 않음
  • EmailMessage.message() 반환 타입이 Python의 EmailMessage 인스턴스로 변경됨

세부 개선 사항

Admin

  • Font Awesome Free 6.7.2 아이콘 세트 적용
  • AdminSite.password_change_form 속성으로 관리자 비밀번호 변경 폼 커스터마이즈 가능
  • messages.DEBUG와 messages.INFO에 별도 아이콘 및 CSS 스타일 적용

Auth

  • PBKDF2 해시 반복 횟수가 1,000,000 → 1,200,000으로 증가

GIS

  • GEOSGeometry.hasm 속성으로 M 차원 여부 확인 가능
  • Rotate 함수로 지정 각도 회전 지원
  • BaseGeometryWidget.base_layer 속성으로 지도 타일 제공자 커스터마이즈 가능
  • MariaDB 12.0.1 이상에서 coveredby, isvalid, GeoHash, IsValid 등 기능 지원
  • 위젯 렌더링 시 인라인 JavaScript 제거, 커스터마이즈 시 템플릿 수정 필요

PostgreSQL

  • Lexeme 표현식 추가로 전체 텍스트 검색어 제어 강화
  • CreateExtension 등 확장 관련 연산에 hints 매개변수 추가
  • django.contrib.postgres 관련 필드·인덱스·제약조건에 시스템 체크 추가

Staticfiles

  • ManifestStaticFilesStorage가 경로 정렬 일관성을 보장해 불필요한 diff 감소
  • collectstatic 명령이 기본적으로 요약만 출력, 세부 정보는 --verbosity 2 이상에서 표시

기타

  • Haitian Creole 언어 지원 추가
  • startproject, startapp 명령이 존재하지 않는 디렉터리 자동 생성
  • shell 명령에서 django.conf.settings 등 기본 유틸 자동 임포트
  • 마이그레이션에서 zoneinfo.ZoneInfo 직렬화 지원
  • StringAgg, AnyValue 등 새로운 집계 함수 추가
  • AsyncPaginator, AsyncPage로 비동기 페이지네이션 지원
  • ASGI 환경에서 HTTP/2 다중 Cookie 헤더 지원
  • 템플릿 내 forloop.length 변수 추가, querystring 태그 개선
  • DiscoverRunner가 forkserver 방식 병렬 테스트 지원

비호환 변경 사항

데이터베이스 백엔드 API

  • BaseDatabaseSchemaEditor 및 PostgreSQL 백엔드가 컬럼 삭제 시 CASCADE 사용 중단
  • return_insert_columns() → returning_columns() 등 메서드명 변경
  • UPDATE … RETURNING 지원 시 DatabaseFeatures.can_return_rows_from_update=True 설정 가능

지원 중단

  • MariaDB 10.5 지원 종료 (10.6 이상 필요)
  • Python 3.12 미만 지원 종료
    • 주요 라이브러리 최소 버전: aiosmtpd 1.4.5, bcrypt 4.1.1, Pillow 10.1.0, psycopg 3.1.12 등

Email

  • mixed_subtype, alternative_subtype, encoding 속성 제거
  • 내부 구현 변경으로 커스텀 EmailMessage 서브클래스 점검 필요

DEFAULT_AUTO_FIELD 기본값 변경

  • 기본값이 AutoField → BigAutoField로 변경
  • Django 3.2 이후 경고(models.W042)를 처리하지 않은 프로젝트는 설정 추가 필요

ORM 표현식

  • as_sql() 메서드의 반환 파라미터는 tuple 형식이어야 함

기타

  • JSON 직렬화 시 항상 개행 추가
  • asgiref 최소 버전 3.9.1로 상향

폐기 예정 기능

django.core.mail API

  • get_connection(), send_mail() 등에서 선택적 인자는 키워드 인자로만 전달해야 함
  • EmailMessage, EmailMultiAlternatives 생성 시 첫 4개 인자 외에는 키워드 인자만 허용

기타

  • BaseDatabaseCreation.create_test_db(serialize) 폐기, serialize_db_to_string() 사용
  • PostgreSQL 전용 StringAgg, OrderableAggMixin 폐기
  • urlize, urlizetrunc 기본 프로토콜이 Django 7.0에서 HTTPS로 변경 예정
  • ADMINS, MANAGERS 설정은 (이름, 주소) 튜플 대신 이메일 문자열 리스트로 지정해야 함
  • SafeMIMEText, SafeMIMEMultipart, BadHeaderError 등 이메일 관련 클래스 폐기

제거된 기능

  • BaseConstraint의 위치 인자 지원 제거
  • DjangoDivFormRenderer, Jinja2DivFormRenderer 삭제
  • cx_Oracle 데이터베이스 드라이버 지원 제거
  • forms.URLField 기본 스킴이 "http" → "https"로 변경
  • Model.save() 및 Model.asave()의 위치 인자 지원 제거
  • ModelAdmin.log_deletion(), LogEntryManager.log_action() 삭제
  • django.utils.itercompat 모듈 제거
  • GeoIP2.coords(), GeoIP2.open() 메서드 삭제
  • ForeignObject.get_joining_columns() 및 관련 메서드 제거

Django 6.0은 보안 강화, 비동기 처리, 현대적 이메일 API 도입을 통해 프레임워크의 안정성과 확장성을 높였으며, Python 3.12 이상 환경으로의 전환을 명확히 함.

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견

  • 예전에 근무했던 조직에는 NodeJS+React로 된 ‘현대식’ 코드베이스와, 15년 가까이 된 Python 2.7 기반의 Django 레거시 앱이 있었음
    처음엔 오래된 코드가 고통스러울 거라 걱정했지만, 오히려 그 반대였음
    Django 앱은 다루기 즐겁고 정리하는 과정이 정말 재미있었음. 새 Go/React 리라이트로 교체될 때가 오면 아쉬울 것 같음

    • 왜 굳이 교체하려는지 모르겠음. 고장 나지 않았다면 굳이 바꿀 필요가 없지 않음

  • Django 팀에게 축하를 보냄
    나는 오랫동안 Docker Compose 기반의 Django + Celery + Postgres + Redis + esbuild + Tailwind 스타터 앱을 유지해왔고, 최근 Django 6.0에 맞게 업데이트했음
    GitHub 저장소에서 확인 가능함
    아직 CSP 설정은 기본값으로 넣지 않았는데, 좀 더 검토 후 추가할 예정임

    • 북마크하려 했는데 이미 2023년 12월에 저장해둔 걸 발견했음
    • Nick의 저장소들은 항상 최고 수준임. 나도 내 자료에서 자주 인용하고 있음. 공개로 공유해줘서 고마움
    • 몇 년 전 프로젝트에서 이 템플릿을 썼었는데, 정말 훌륭했음
    • 최근 uv 추가를 보고 꾸준히 관리되고 있다는 게 느껴졌음

  • Django의 “batteries included” 철학은 AI 코드 생성에 완벽히 어울림
    관리자 패널, 로그인, 비밀번호 재설정 등 기본 기능이 이미 잘 갖춰져 있어서, AI가 작은 코드베이스로도 완전한 사이트를 만들 수 있음
    코드가 작고 명확하니 AI가 반복적으로 개선하기도 쉬움

    • Django의 장점은 사람이 읽기 쉬운 코드 구조임
      거대한 컴포넌트 대신 명확한 모델과 템플릿이 있어서, AI가 생성한 코드를 리뷰하기도 쉬움
      또 Django admin이 독립된 ground truth로 존재하므로, 프론트엔드가 망가져도 데이터를 다룰 수 있음
      다만 Python 생태계가 gevent 모델을 채택하지 않은 건 아쉬움. 그랬다면 비동기 전환이 훨씬 매끄러웠을 것임
    • Django의 INSTALLED_APPS 구조 덕분에 앱 단위로 기능을 쉽게 추가·제거할 수 있음
      Flask나 FastAPI처럼 느슨하게 연결된 프레임워크보다 훨씬 통합적임
      이런 차이가 결국 수많은 작은 불편함(papercuts) 을 줄여줌
    • Django와 Rails 둘 다 써봤는데, Claude Code로 테스트했을 때는 Rails가 훨씬 잘 작동했음
      오래된 .NET 앱을 리라이트했는데 Rails는 거의 완벽하게 변환했지만 Django는 어려워했음
    • 사실 Ruby on Rails가 더 오래전부터 CSP, 백그라운드 워커 등 다양한 기능을 기본 제공해왔음
    • Django는 오픈소스 프로젝트에서 워낙 오래 쓰여서, AI가 학습할 코드 데이터가 풍부함

  • 이번 릴리스의 template partials 기능은 꽤 괜찮아 보임
    하지만 타입 주석(type annotations) 상태는 여전히 불편함
    django-stubs는 mypy 플러그인이 필요하고, django-types는 pyright용 포크지만 동기화가 잘 안 됨
    pylance는 또 자체 포크를 씀
    다음 버전에서는 HttpRequest, HttpResponse, View, Model 같은 기본 타입이라도 공식적으로 포함되길 바람

  • Django 덕분에 웹 개발이 정말 즐거웠음
    다른 프레임워크로 바꿔도 결국 Django로 돌아오게 됨. 후회 없는 선택이었음

    • 나는 Ruby on Rails에서 같은 경험을 했음
      다른 프레임워크를 써봐도 Rails의 편리함 때문에 다시 돌아오게 됨
      다만 Rails에는 기본 Admin UI가 없다는 게 아쉬움
    • 백엔드만 본다면 Django는 훌륭하지만, 프론트엔드 측면에서는 아직 석기시대 수준임
      완전한 풀스택을 원한다면 Laravel이나 Rails를 보는 게 나음
    • 솔직히 Django의 매력을 잘 모르겠음
      PHP 시절부터 웹을 해왔는데 Django는 항상 그저 그런 느낌이었음

  • Django는 내 첫 프리랜스 대형 프로젝트였고, 여전히 편안하게 느껴짐
    여러 실험적인 시도를 해봤지만 항상 잘 작동했음. Django에게 감사함

  • 15년 가까이 Django를 거의 독점적으로 써왔음
    다른 프레임워크도 많이 시도했지만 Django만큼 손에 맞는 것은 없었음
    이번 릴리스에서 task framework를 추가했지만, 백엔드와 워커가 포함되지 않은 건 아쉬움
    차라리 다음 버전에서 완전한 형태로 포함되길 바람

    • Django가 그 선을 넘을 계획이 있는지 궁금함. 프레임워크 철학상 경계 유지를 중시할 것 같음
    • 완벽함이 선의 적이 되어선 안 됨. Django는 결국 “마감이 있는 완벽주의자” 를 위한 프레임워크임

  • Django의 포함형 구성(batteries included) 덕분에 규모와 상관없이 어떤 프로젝트에도 적합함
    팀과 기여자들에게 찬사를 보냄

  • 우리는 어떻게 SPA 시대에 들어오게 되었는지 궁금함. 단순히 로딩 스피너를 없애려던 건지, 더 깊은 이유가 있었는지 알고 싶음

    • 핵심 이유 중 하나는 모바일 앱의 등장이었음
      웹·iOS·Android가 하나의 백엔드를 공유하도록 만들면서, 자연스럽게 SPA 패턴이 확산됨
      나도 여전히 SPA를 만들지만, 언젠가 Django + htmx로 큰 프로젝트를 해보고 싶음
    • 예전에 Angular로 데이터 시각화를 하면서 SPA로 전환했음
      페이지 리로드 없이 앱처럼 동작하는 게 매력적이었지만, 실제로는 강제 새로고침이 필요한 경우도 많았음
      그래도 데이터와 표현을 분리하는 구조는 우아하다고 생각함
    • 웹은 원래 문서 렌더링용으로 만들어졌지만, 사용자는 앱을 원했음
      그래서 JS로 문서를 앱처럼 바꾸려는 시도가 이어졌음
    • 인터넷 속도가 느리고, 백엔드 검증이 느렸던 시절엔 폼 검증을 위해 JS를 추가하다가 복잡해졌음
      결국 프론트엔드와 백엔드를 분리하고, API 계약과 검증 절차가 생겼음
      나중엔 다시 서버 컴포넌트로 통합하려는 흐름이 생겼고, 지금 우리가 그 지점에 있음
      참고로 예전식 웹폼 예시는 이 링크에서 볼 수 있음
    • Django나 Rails 같은 템플릿에는 타입 안정성이 부족했음
      그래서 나는 TypeScript 기반 빌드 프로세스를 선호하게 되었음

  • Django를 쓸 때마다 단순히 즐거움을 느낌. 그게 전부임

답변달기