Django 6.0의 새로운 기능

• 20주년을 맞은 Django 6.0은 템플릿, 백그라운드 작업, 보안, 이메일 등 핵심 영역을 대폭 개선한 주요 릴리스임
• Template partials 기능으로 템플릿 내 코드 재사용이 쉬워졌으며, htmx와 같은 도구와의 통합이 강화됨
• Tasks 프레임워크가 새로 추가되어 HTTP 요청-응답 주기 밖에서 백그라운드 작업을 실행할 수 있음
• Content Security Policy(CSP) 가 기본 내장되어 XSS 등 콘텐츠 주입 공격 방어가 간편해짐
• 이메일 API 현대화, ORM 개선, 기본 키 확장 등으로 개발자 경험과 확장성이 크게 향상됨

---

Django 6.0 개요

• Django 6.0은 Python 웹 프레임워크의 새로운 릴리스로, 20년간의 발전을 이어가는 버전임
• 주요 변경 사항은 템플릿, 백그라운드 작업, 보안, 이메일 처리 등 네 가지 핵심 기능을 중심으로 구성됨
• 개발자 커뮤니티의 다수 기여자들이 참여했으며, 공식 릴리스 노트에 기반한 주요 개선점이 정리됨

django-upgrade 도구

• 기존 프로젝트를 Django 5.2 이하 버전에서 업그레이드할 때 django-upgrade 도구를 사용하면 코드 자동 변환 가능
• Django 6.0 관련 5개의 자동 수정기(fixer) 가 포함되어 있으며, 일부 경고를 자동으로 해결함

Template partials

• 템플릿 부분 정의({% partialdef %}) 기능이 추가되어 템플릿 내에서 코드 중복을 줄이고 재사용 가능
  • 동일 템플릿 내에서 정의한 partial을 여러 번 호출 가능
  • inline 옵션을 사용하면 정의와 동시에 렌더링 가능
• 부분 렌더링 기능을 통해 특정 partial만 독립적으로 렌더링 가능
  • 예시에서는 htmx를 사용해 view_count 부분을 주기적으로 갱신
  • URL에 #partial_name을 붙여 특정 부분만 렌더링 가능
• 이 기능은 Google Summer of Code 프로젝트를 통해 Django에 통합되었으며, 기존 django-template-partials 패키지에서 발전함

Tasks 프레임워크

• Django에 백그라운드 작업 실행용 Tasks 프레임워크가 새로 추가됨
  • HTTP 요청-응답 주기 외부에서 코드 실행 가능
  • 이메일 전송, 데이터 처리, 보고서 생성 등 비동기 작업에 활용
• @task 데코레이터로 작업 정의, Task.enqueue()로 큐에 등록 가능
• 기본 제공 백엔드는 개발용 ImmediateBackend, DummyBackend 두 가지이며,
  django-tasks 패키지의 DatabaseBackend를 사용하면 SQL DB 기반 실행 가능
• db_worker 명령으로 작업 워커를 실행하며, 로그를 통해 상태 확인 가능
• 이 기능은 Wagtail에서 시작된 아이디어로, DEP 0014 제안 후 Django에 통합됨

Content Security Policy(CSP) 지원

• Django 6.0은 CSP 표준을 기본 지원하여 XSS 등 콘텐츠 주입 공격 방어 강화
  • ContentSecurityPolicyMiddleware를 MIDDLEWARE에 추가해 활성화
  • SECURE_CSP, SECURE_CSP_REPORT_ONLY 설정으로 정책 구성 가능
• Nonce 기반 보안이 내장되어 <script> 및 <style> 태그에 nonce="{{ csp_nonce }}" 속성 추가 가능
  • 요청마다 난수 nonce가 생성되어 신뢰된 리소스만 실행됨
• CSP는 2004년 제안 이후 django-csp 패키지로 구현되어 왔으며, 이번 버전에서 공식 내장됨

이메일 API 업데이트

• Django의 이메일 처리 로직이 Python 3.6의 현대적 이메일 API로 전환됨
  • 내부적으로 email.message.EmailMessage 클래스를 사용
  • 기존 send_mail() 및 EmailMessage 인터페이스는 그대로 유지
• 새로운 API는 버그 감소, 보안성 향상, 인라인 첨부파일 처리 개선 등의 장점 제공
• MIMEPart 객체를 사용해 HTML 본문 내 이미지 등 인라인 첨부를 간단히 추가 가능
• 이 변경은 2024년 제안되어 8개월간 개발 후 병합됨

이메일 API의 위치 인자 제한

• django.core.mail API에서 일부 매개변수는 키워드 인자만 허용하도록 변경
  • fail_silently 등 선택적 인자를 위치 인자로 전달 시 경고 발생
  • 가독성과 유지보수성을 높이기 위한 조치
• django-upgrade의 mail_api_kwargs fixer로 자동 수정 가능

Shell 자동 import 확장

• Django 5.2의 자동 모델 import 기능이 확장되어,
  settings, connection, models, functions, timezone 등이 자동 import됨
• ./manage.py shell -v 2로 자동 import 목록 확인 가능
• 개발 편의성 향상 및 반복 코드 감소 효과

ORM 개선: save() 시 동적 필드 갱신

• GeneratedField나 표현식 기반 필드가 save() 후 자동 갱신됨
  • RETURNING 절을 지원하는 DB(SQLite, PostgreSQL, Oracle)에서 즉시 반영
  • MySQL, MariaDB에서는 지연 로딩으로 자동 갱신
• 추가 쿼리 없이 최신 값을 바로 사용할 수 있어 효율성 향상

Universal StringAgg 집계 함수

• StringAgg 집계 함수가 모든 데이터베이스 백엔드에서 사용 가능
  • 입력 값을 구분자(delimiter)로 연결한 문자열 반환
  • PostgreSQL 전용 기능이었으나 이제 django.db.models에서 직접 사용 가능
• Value() 표현식으로 구분자 지정 가능

BigAutoField 기본화

• DEFAULT_AUTO_FIELD의 기본값이 BigAutoField 로 변경
  • 64비트 정수형 기본 키를 사용하여 Primary Key 고갈 문제 예방
  • 새 프로젝트에서는 별도 설정 없이 자동 적용
• Django 3.2에서 도입된 설정을 단순화하여 보일러플레이트 감소

Template 개선

• forloop.length 변수가 추가되어 루프 내 전체 길이 참조 가능
  • {{ forloop.counter }}/{{ forloop.length }} 형태로 사용
• querystring 템플릿 태그 개선
  • 빈 매핑 시 ? 자동 추가로 링크 동작 일관성 확보
  • 다중 매핑 인자 병합 지원으로 쿼리 파라미터 조합 용이

마무리

• Django 6.0에는 174명의 기여자가 참여했으며,
  수많은 최적화와 버그 수정이 포함됨
• 업그레이드를 통해 보안성, 유지보수성, 개발자 경험(DX) 이 전반적으로 향상됨
• 공식 릴리스 노트에서 추가 변경 사항 확인 가능

[GN⁺]

Hacker News 의견들

• 몇 년째 회사에서 Django를 간헐적으로 써오고 있음. 전반적으로 마음에 들지만 ORM이 여전히 어렵게 느껴짐
  Django는 의견이 강한 프레임워크라 ‘Django 방식’을 따라야 한다는 걸 이제야 이해했음.
  문제는 여러 사업 부서의 다중 데이터베이스를 다뤄야 해서, 매번 그 특이점을 맞추느라 고생함.
  결국 managed를 끄고 inspectdb로 스키마를 가져온 뒤, 웹에 노출하고 싶지 않은 테이블을 수동으로 삭제하는 식으로 처리함.
  새로 만드는 웹앱에는 Django가 여전히 최선의 선택임

  • 동의함. 하지만 DB 마이그레이션 워크플로우는 여전히 아쉬움
    Django는 코드와 함께 스키마 상태를 저장하지 않아서, 매번 DB 명령을 실행할 때마다 현재 상태를 추론해야 함.
    모델 코드로 DB 상태를 정의하는 건 본질적으로 한계가 있음.
    나는 Rails처럼 명시적인 DB 명령으로 마이그레이션을 구성하고, 그 위에 모델을 얹는 방식을 더 선호함
  • Django의 다중 데이터베이스 지원을 쓰고 있는지 궁금함
  • 작은 프로젝트에서 Aldjemy를 써봤는데, Django ORM으로는 힘든 복잡한 쿼리 조합을 꽤 잘 처리해줬음
  • Django를 10년 넘게 써왔는데 ORM은 ‘괜찮은 편’ 정도임. 한때 SQLAlchemy로 바꾸자는 흐름도 있었지만, 그만한 가치가 없었음.
    Manager 인터페이스는 처음엔 헷갈리지만, 마이그레이션 도구는 정말 훌륭함
  • ORM을 통해 뷰나 materialized view를 설정해두면 성능 향상에 큰 도움이 됨.
    SQL 튜닝의 유연함과 Django의 편리함을 동시에 얻을 수 있음.
    단, 마이그레이션 스크립트 안에서 생성하는 걸 잊지 말아야 함

• Django가 매 릴리스마다 조금씩 꾸준히 개선되는 게 정말 마음에 듦.
  특히 6.0 버전은 유용한 기능이 많아서 흥미로움.
  믿을 수 있는 기술이 지루하다는 말은 틀렸음. 이런 식으로 발전하는 게 맞음

  • 나도 pre-1.0 시절부터 써왔고 여전히 좋아함.
    지금 Django의 탄생지 근처에 살고 있음.
    덧붙여, 어제부터 구직 중이니 경험 많은 Django 개발자를 찾는다면 연락 바람 ([e-mail])

• Adam이 쓴 코드나 블로그는 언제나 읽을 가치가 있음.
  앞으로 tasks 프레임워크가 어떻게 발전할지 기대됨.
  다만 훌륭한 Django-Q2가 Celery와 함께 언급된 건 조금 아쉬움

  • 작성자임. 칭찬 고맙고, Celery는 단지 인기 때문에 언급했을 뿐임 ;)
  • Celery는 완벽하진 않지만, 가장 나은 선택지임.
    버그가 많지만 사용자층이 워낙 커서 문제를 처음 겪는 경우가 드묾.
    Celery + RabbitMQ 조합으로 하루 수천만 건의 메시지를 안정적으로 처리했음.
    여전히 첫 번째로 고려할 만한 솔루션임
  • 여러 해 동안 Celery를 써왔는데, 어떤 점이 문제였고 Django Q2가 어떻게 개선해주는지 궁금함.
    다른 스택에서는 Kafka도 쓰지만, 그건 완전히 다른 수준의 사용 사례임
  • 왜 Celery가 ‘끔찍하다’고 하는지 궁금함

• Django를 5~6년 정도 써왔는데, ‘배터리 포함’ 이라는 장점은 분명하지만 전반적으로 무겁게 느껴짐

• Template partial 기능이 좋아 보임.
  React가 인기를 얻은 이유 중 하나가 코드 재사용성인데, Django도 그 방향으로 가는 듯함

  • React의 재사용성과 조합성의 핵심은 템플릿이 아니라 모든 것이 함수라는 점임
  • 이 기능은 특히 HTMX와 함께 쓸 때 큰 가치가 있음. HTMX는 많은 partial 템플릿을 필요로 함
  • React는 단순한 템플릿이 아니라 상태를 캡슐화한 컴포넌트를 제공함
  • 나도 Django 6을 테스트하면서 블로그에 partial을 써봤음
    예시는 여기 코드에 있음
  • Django가 이런 기능을 2025년에야 추가했다는 게 놀라움

• 나는 주로 Odoo를 쓰지만 Django와 Celery도 조금 다뤄봤음.
  Odoo의 OCA queue 모듈을 많이 사용하는 입장에서,
  Django가 왜 Postgres의 LISTEN/NOTIFY 기능을 활용하지 않는지 늘 궁금했음.
  아마 내가 Django 생태계에 익숙하지 않아서일 수도 있음

• Template Partials와 HTMX는 Django 버전의 Rails View Components + Stimulus처럼 느껴짐.
  Tasks 기능이 정식 지원되는 것도 반가움

  • Rails의 partial 렌더링은 공식 가이드에서 볼 수 있음
  • 프로덕션에서 Tasks를 쓰려면 django-tasks도 함께 써야 하는지 궁금함

• Django 1.x 시절, ORM이 없던 때부터 써왔음.
  이제서야 task 실행 기능이 추가된 게 정말 놀라움.
  비판하려는 건 아니고, 그저 흥미로운 진화임

  • 오히려 신선함. Django는 기능을 서두르지 않고 제대로 구현함.
    각 기능이 충분히 검증된 뒤에야 포함시키고, LTS와 API 안정성에 집중함.
    덕분에 새 버전이 나와도 전체 앱을 다시 써야 할 일이 거의 없음
  • Django는 사실 0.95 버전부터 ORM을 포함하고 있었음.
    당시엔 단순했지만, 꽤 오랫동안 raw SQL을 쓸 필요가 없었음

• 추가 토론은 이 스레드에서 이어지고 있음

• 나는 Django와 HTMX를 함께 쓰면서 컴포넌트 단위 템플릿이 너무 불편해서,
  직접 Python 기반의 컴포넌트 라이브러리 Compone를 만들었음.
  Django뿐 아니라 모든 Python 웹 프레임워크에서 쓸 수 있고, 훨씬 쾌적한 개발 경험을 줌