# Django 6.0의 새로운 기능

> Clean Markdown view of GeekNews topic #24980. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=24980](https://news.hada.io/topic?id=24980)
- GeekNews Markdown: [https://news.hada.io/topic/24980.md](https://news.hada.io/topic/24980.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-12-11T01:33:16+09:00
- Updated: 2025-12-11T01:33:16+09:00
- Original source: [adamj.eu](https://adamj.eu/tech/2025/12/03/django-whats-new-6.0/)
- Points: 4
- Comments: 1

## Topic Body

- 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)** 이 전반적으로 향상됨  
- 공식 릴리스 노트에서 추가 변경 사항 확인 가능

## Comments



### Comment 47549

- Author: neo
- Created: 2025-12-11T01:33:16+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46210240) 
- 몇 년째 회사에서 Django를 간헐적으로 써오고 있음. 전반적으로 마음에 들지만 **ORM이 여전히 어렵게 느껴짐**  
  Django는 의견이 강한 프레임워크라 ‘Django 방식’을 따라야 한다는 걸 이제야 이해했음.  
  문제는 여러 사업 부서의 **다중 데이터베이스**를 다뤄야 해서, 매번 그 특이점을 맞추느라 고생함.  
  결국 `managed`를 끄고 `inspectdb`로 스키마를 가져온 뒤, 웹에 노출하고 싶지 않은 테이블을 수동으로 삭제하는 식으로 처리함.  
  새로 만드는 웹앱에는 Django가 여전히 최선의 선택임
  - 동의함. 하지만 **DB 마이그레이션 워크플로우**는 여전히 아쉬움  
    Django는 코드와 함께 스키마 상태를 저장하지 않아서, 매번 DB 명령을 실행할 때마다 현재 상태를 추론해야 함.  
    모델 코드로 DB 상태를 정의하는 건 본질적으로 한계가 있음.  
    나는 Rails처럼 명시적인 DB 명령으로 마이그레이션을 구성하고, 그 위에 모델을 얹는 방식을 더 선호함
  - Django의 [다중 데이터베이스 지원](https://docs.djangoproject.com/en/6.0/topics/db/multi-db/)을 쓰고 있는지 궁금함
  - 작은 프로젝트에서 [Aldjemy](https://github.com/aldjemy/aldjemy)를 써봤는데, Django ORM으로는 힘든 **복잡한 쿼리 조합**을 꽤 잘 처리해줬음
  - Django를 10년 넘게 써왔는데 ORM은 ‘괜찮은 편’ 정도임. 한때 SQLAlchemy로 바꾸자는 흐름도 있었지만, 그만한 가치가 없었음.  
    Manager 인터페이스는 처음엔 헷갈리지만, **마이그레이션 도구**는 정말 훌륭함
  - ORM을 통해 **뷰나 materialized view**를 설정해두면 성능 향상에 큰 도움이 됨.  
    SQL 튜닝의 유연함과 Django의 편리함을 동시에 얻을 수 있음.  
    단, 마이그레이션 스크립트 안에서 생성하는 걸 잊지 말아야 함

- Django가 매 릴리스마다 조금씩 **꾸준히 개선**되는 게 정말 마음에 듦.  
  특히 6.0 버전은 유용한 기능이 많아서 흥미로움.  
  믿을 수 있는 기술이 지루하다는 말은 틀렸음. 이런 식으로 발전하는 게 맞음
  - 나도 pre-1.0 시절부터 써왔고 여전히 좋아함.  
    지금 Django의 탄생지 근처에 살고 있음.  
    덧붙여, 어제부터 구직 중이니 **경험 많은 Django 개발자**를 찾는다면 연락 바람 (oldspiceap@gmail.com)

- 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을 써봤음  
    예시는 [여기 코드](https://github.com/simonw/simonwillisonblog/blob/faec3532183e993a5d143642225de045139b23a9/templates/includes/blog_mixed_list.html#L32-L59)에 있음
  - Django가 이런 기능을 **2025년에야 추가했다는 게 놀라움**

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

- Template Partials와 HTMX는 Django 버전의 **Rails View Components + Stimulus**처럼 느껴짐.  
  Tasks 기능이 정식 지원되는 것도 반가움
  - Rails의 partial 렌더링은 [공식 가이드](https://guides.rubyonrails.org/layouts_and_rendering.html#partial-layouts)에서 볼 수 있음
  - 프로덕션에서 Tasks를 쓰려면 [django-tasks](https://github.com/RealOrangeOne/django-tasks)도 함께 써야 하는지 궁금함

- Django 1.x 시절, **ORM이 없던 때**부터 써왔음.  
  이제서야 task 실행 기능이 추가된 게 정말 놀라움.  
  비판하려는 건 아니고, 그저 흥미로운 진화임
  - 오히려 신선함. Django는 기능을 **서두르지 않고 제대로 구현**함.  
    각 기능이 충분히 검증된 뒤에야 포함시키고, LTS와 API 안정성에 집중함.  
    덕분에 새 버전이 나와도 전체 앱을 다시 써야 할 일이 거의 없음
  - Django는 사실 **0.95 버전부터 ORM을 포함**하고 있었음.  
    당시엔 단순했지만, 꽤 오랫동안 raw SQL을 쓸 필요가 없었음

- 추가 토론은 [이 스레드](https://news.ycombinator.com/item?id=46153116)에서 이어지고 있음

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