Django 리뷰: 지금도 쓸 만한가?

Django는 2025년 12월부터 2026년 8월까지 여덟 달 사이에 기능 릴리스를 두 번 내놓았고, 릴리스 주기 전체를 다시 썼다.

그 모든 일이, 2023년 이후로 평판이 거의 달라지지 않은 프레임워크에 일어났다. 필요한 것이 다 들어 있고, 생산적이며, 고집이 있고, 동기 전용이며, FastAPI에 밀리고 있는 Python 프레임워크라는 평판이다. 동기 전용이라는 딱지는 이미 낡았고, 인기에 관한 이야기는 눈에 띄는 수치가 말하는 것보다 복잡하다.

그래서 6.1 시점에서 Django가 여전히 쓸 만한지에 대한 내 결론은 이렇다. 점수를 붙인 판단, 잘 맞는 프로젝트 형태, 그리고 이제는 FastAPI가 더 나은 선택인 형태다.

요약

조건부로 그렇다. 관리자, 인증, 폼, ORM이 작업의 대부분일 때 Django 6.1은 여전히 가장 강력한 기본 선택지이고, 비동기 격차도 "동기 전용"이라는 이유로 배제할 만큼 크지 않다. 관리자 화면이 없는 단일 고동시성 API에는 맞지 않는다. 5점 만점에 4점.

• 당신이 사는 것은 묶음 그 자체다. ORM, 마이그레이션, 권한이 딸린 세션 인증, 폼 계층, 그리고 자동 생성되는 관리자 화면이 한꺼번에, 이미 서로 맞물린 상태로 온다. 다섯 개의 라이브러리와 그 사이의 이음매가 아니다.
• 백그라운드 작업이 약한 축이다. Django 6.0의 Tasks 프레임워크는 데코레이터와 큐에 넣는 호출은 주지만 워커는 주지 않는다. 그래서 Celery나 그에 준하는 것을 고르는 일은 여전히 당신 몫이다.
• 비동기는 훨씬 나아졌지만, 분명히 미완성이다. Django는 비동기 뷰와 비동기 ORM 호출을 지원하지만, 트랜잭션은 비동기 모드에서 동작하지 않는다. WSGI 아래에서도 비동기 뷰는 요청 하나 안에서 동시적인 비동기 I/O를 돌릴 수 있으나, 완전한 비동기 요청 스택의 이점은 얻지 못한다. 오래 걸리는 요청과 높은 연결 동시성에는 ASGI가 필요하다.
• 2027년 이후를 계획하기가 쉬워졌다. 2028년 1월부터 Django는 매년 기능 릴리스를 하나씩 내고, 각각 3년의 지원을 받는다. 이제 모든 릴리스가 그 약속을 받기 때문에 "LTS"라는 딱지는 사라진다.
• 관리자 화면과 CRUD가 많은 제품, 그리고 소규모 팀에 맞다. 관리자 화면도 폼도 없는 단일 고처리량 또는 스트리밍 API에는 맞지 않는다. 그런 경우엔 FastAPI가 더 자연스러운 선택이다.

이 리뷰를 어떻게 썼는지: 이 글은 Django 6.1에 대한 평가로, 프로젝트 자체의 릴리스 노트와 문서, Django Software Foundation의 2026년 8월 거버넌스 발표, 2024년 JetBrains/PSF 및 2025년 Django 개발자 설문, 그리고 자신의 프로덕션 경험을 공개적으로 쓴 실명 실무자들을 바탕으로 했다. 이 글을 위해 몇 주짜리 프로덕션 시험 운영을 하지는 않았고, 여기에 벤치마크는 없다. 부하 테스트는 하지 않았다. Django는 무료이며 BSD 라이선스이고, 나는 이 프로젝트와 아무 관계가 없다.

2025년 이후 Django에서 실제로 달라진 것

Django 6.0은 2025년 12월 3일, 자체 Tasks 프레임워크와 코어에 대한 다른 추가 기능을 달고 나왔다. 비동기 ORM 인터페이스 는 그보다 오래됐다. Django 4.1이 2022년에 비동기 QuerySet 연산을 도입했다. Django 6.1은 2026년 8월 5일에 현재 안정 버전이 됐다. 이어서 2026년 8월 10일, 프로젝트는 연 1회 기능 릴리스를 2028년 1월부터 시행하고, 릴리스마다 3년의 지원을 주며, LTS 표기를 없앤다고 발표했다.

6.1 릴리스 노트 는 6.1이 Python 3.12, 3.13, 3.14를 지원하며 기본 지원은 2027년 4월에, 연장 지원은 2027년 12월에 끝난다고 확인해 준다.

버전 번호도 함께 바뀐다. 이제 연도를 담아서 Django 2028, 그다음 Django 2029가 된다(적어도 "지금 몇 버전이냐"는 질문에는 답하기 쉬워진다). 3년은 일반 버그 수정 1년에 이어 보안과 데이터 손실 수정 2년으로 나뉜다. 예전에 LTS가 뜻하던 바가 바로 그것이므로, 그 딱지는 사라진다.

이 때문에 오늘 시작하는 프로젝트에는 어정쩡한 구간이 생긴다. Django 5.2가 현재 LTS이고 2028년 4월까지 지원된다. Django 6.1은 현재 안정 버전이지만 연장 지원이 2027년 12월에 끝나는데, 이는 Django 5.2의 지원 기간이 끝나는 2028년 4월보다 약 넉 달 이르다.

정리하면, 가장 긴 지원 기간을 노린다면 5.2로 시작하는 것이다. Tasks 프레임워크와 최신 6.x 기능을 원한다면 6.1로 시작하고 더 이른 업그레이드를 감수하는 것이다. 둘 다 틀리지 않았고, 이 어정쩡한 선택은 2027년 4월 Django 6.2 LTS가 나오면 사라진다.

나는 이 주기 변경을 좋은 신호로 읽는다. 쇠퇴하는 프로젝트는 지원 약속을 조용히 늘려 잡을 뿐, 날짜가 박힌 계획을 들고 공개적으로 재편하지는 않는다. 이 프로젝트는 이미 지키고 있던 약속을 단순하게 정리한 것이다.

Django가 여전히 무엇보다 잘하는 것

Django 6.1 프로젝트를 시작하면, 기능을 하나도 쓰기 전에 권한 체계가 딸린 동작하는 세션 인증, 검증과 렌더링을 하는 폼 계층, 모델에 묶인 마이그레이션 체계, ORM, 그리고 자동 생성된 관리자 화면을 갖게 된다. 그게 이 프레임워크의 전부이고, 바뀔 필요가 없었던 Django의 부분이다.

가치는 그 조각들이 존재한다는 데 있지 않다. 서로를 겨냥해 설계됐다는 데 있다. 같은 모델 권한이 관리자 화면을 움직이고, 모델을 바꾸면 그 한 번에 마이그레이션이 만들어지고 관리자 폼도 갱신된다.

독립적인 라이브러리를 조합해 같은 범위를 갖추는 일은 결국 가능하다. 다만 이음매마다 영구적인 유지보수 표면이 함께 생기고, 버그는 바로 그 이음매에 산다.

관리자 화면은 내부 직원용 도구다. 관리자 화면 레퍼런스 문서 는 권장 용도가 조직의 내부 관리 도구에 한정되며, 프런트엔드 전체를 그 위에 짓기 위한 것이 아니라고 말한다. 일단 안에 들어간 스태프 사용자가 무엇을 할 수 있는지는 모델 권한이 정하고, 애초에 안에 들어가는 데 필요한 것은 is_staff 플래그다. 그것을 제약으로 받아들이면, 좋은 제약이다. 쓸 만한 내부 백오피스를 공짜로 얻고, 고객용 UI는 얻지 못하니 아무도 그런 걸 내보낼 유혹에 빠지지 않는다.

보안 기본값은 같은 주장의 나머지 절반이다. CSRF 보호, ORM을 통한 SQL 파라미터화, 템플릿의 XSS 이스케이프, 클릭재킹 방어가 기본으로 켜져 있다. 선임 개발자가 리뷰에서 요구하는 걸 잊지 말아야 하는 항목이 아니다. 작은 팀은 10년치 보안 보고서를 읽어 온 사람들이 내린 결정을 그대로 물려받는다.

그리고 나이가 있다. 흔히 부채로 읽히지만, 나는 생태계에 관한 논거로 읽는다. Django REST Framework는 존재하고, 인프라가 지루하기를 바랄 때의 그 지루함으로 지루하다.

넉 달째에 부딪히는 문제들을 위한 성숙한 패키지도 마찬가지다. 필터링, 스로틀링, 스토리지 백엔드, 멀티테넌시 패턴, 감사 로그. 그리고 어떤 문제가 어떤 패키지도 다루지 않을 만큼 특이하다면, 대개 그에 관한 15년 된 메일링 리스트 스레드가 있다. 폭이라는 면에서 Python 안의 다른 무엇도 근처에 오지 못한다고 보며, 애초에 사람들이 Django를 고르는 이유가 바로 이 축이다.

Django가 모자란 지점

Django에는 여전히 프레임워크 전반을 아우르는 자체 타입 지원이 없고, 신중한 속도는 "필요한 게 다 들어 있다"는 말이 경고해 주지 않는 구멍을 남기며, 6.0의 Tasks 프레임워크에는 워커가 없다. 6.1 시점의 부족한 점 셋이 그것이다. 타입 구멍은 매일 거슬리는 쪽이고, Tasks는 아키텍처 다이어그램을 바꿔 놓는 쪽이다.

타입에 관한 이야기의 상당 부분은 여전히 서드파티 도구로 직접 짜맞추게 된다. django-stubs 는 타입 스텁과 함께 Django의 동적 동작을 다루는 전용 mypy 플러그인을 제공한다. 현재 문서에는 mypy 완전 지원과 pyright, pyrefly, ty에 대한 기본 지원이 적혀 있다. 예전보다는 나아진 상황이지만, 여전히 Django 자체의 포괄적인 자체 타입 지원이 아니라 별도의 호환 계층이다.

타입 힌트를 중심으로 만들어진 프레임워크에서 넘어온다면, 이건 매일의 에디터 경험에서 확실히 체감되는 후퇴다.

신중한 속도는 미덕인 만큼 비용이기도 하다. Django는 조심스럽게, 늦게 무언가를 추가한다. 그래서 2019년에 배운 프레임워크를 오늘도 읽을 수 있다. 같은 이유로 배터리는 딱 거기까지다. 코어에 WebSocket 계층이 없고, 스케줄러가 없고, 비동기 작업 오케스트레이션에 대한 견해도 없다. 그 선을 하나라도 넘으면 다시 직접 조립하게 된다.

Django 6에도 여전히 Celery가 필요할까?

꼭 Celery는 아니다. Django 6.0의 Tasks 프레임워크는 작업을 정의하고 큐에 넣는 방식을 표준화하지만, 큐에 쌓인 일을 직접 실행하지는 않는다. 프로덕션에서는 여전히 작업을 실행할 백엔드나 워커 프로세스가 필요하다. Celery는 하나의 선택지일 뿐 프레임워크의 요구 사항이 아니다. Django 6.0의 릴리스 노트 는 그 경계에 대해 단도직입적이다. Django는 작업 생성과 큐 적재는 맡지만 워커 메커니즘은 제공하지 않으며, 실행은 별도의 프로세스나 서비스 같은 외부 인프라가 관리해야 한다.

당신이 얻는 것은 인터페이스다.

from django.core.mail import send_mail
from django.tasks import task

@task
def email_users(emails, subject, message):
    return send_mail(subject, message, None, emails)

email_users.enqueue(...) 는 작업을 설정된 백엔드로 보낸다. 6.0에 함께 실려 오는 두 백엔드는 개발과 테스트를 위한 것이다(그러니까 당신이 기대하던 그것은 아니다). 스케줄링, 반복 실행, 재시도, 내구성은 모두 범위 밖이다.

현업 Django 개발자 Kevin Renskers가 이를 가장 날카롭게 짚었다. 출처는 그가 쓴 Tasks 리뷰:

그 대신 우리가 받은 건 구현 없는 추상화였다.

형태에 관해서는 그의 말이 맞다. 다만 의도는 나라면 달리 규정하겠다. 출처는 DEP 14에 대한 Steering Council 투표다. 이 기능의 바탕이 된 Django 개선 제안에 대해 Simon Charette는 그것이 "Celery나 RQ 같은 프레임워크가 끼워 넣을 수 있는 무언가여야 한다"고 주장했고, 제안 작성자는 그것을 런타임이 아니라 백그라운드 워커 인터페이스라고 설명했다. 그러니 공정한 비판은 Tasks가 망가졌다는 게 아니다. "필요한 게 다 들어 있다"는 말이 사람들에게 기대하게 만든 것보다 훨씬 좁다는 것, 그리고 그것이 메우는 구멍은 지루한 쪽이라는 것이다. 애플리케이션 코드가 특정 큐 라이브러리를 임포트하지 않고도 일을 큐에 넣을 수 있다는 것.

그러니 재시도, 예약 작업, 실패 가시성이 필요한 Django 6.1 프로젝트라면 작업 큐를 예산에 넣어라. 6.0 이전과 똑같은 항목이고, 이번 릴리스가 그걸 아키텍처 다이어그램에서 지워 주기를 바랐다면 그런 일은 없다.

이미 Django가 맞다고 판단했고 서버 계층을 처음부터 조립하고 싶지는 않다면, Cloudzy의 Django VPS 는 Django, Gunicorn, Nginx, PostgreSQL이 준비된 자체 관리형 출발점을 주고, Redis나 Celery가 필요할 때 쓸 root 접근 권한도 준다. 서버를 운영하는 건 여전히 당신이다. 빈 서버 세팅을 건너뛰는 것이지, 운영 책임을 건너뛰는 게 아니다.

읽기

VPS Server에 Python을 설치하는 방법은? | 단계별 가이드

이제 Django의 비동기 지원은 충분한가?

"동기 전용"이라는 말이 더는 당신을 막지 않을 만큼은 좋고, 그 위에 완전한 비동기 데이터 계층을 올릴 만큼은 좋지 않다. 6.1에서는 두 절반이 모두 참이다. 어느 쪽이 당신에게 해당하는지는 무엇을 만드는지, 그리고 그것을 ASGI로 서비스하는지 WSGI로 서비스하는지에 달렸다. 완전한 비동기 요청 스택과 장기 연결의 효율적인 처리를 얻느냐는 그 선택이 결정하기 때문이다.

기능 자체는 논쟁거리가 아니다. SQL을 발생시키는 QuerySet 메서드에는 모두, 앞에 a가 붙은 비동기 변형이 있다. async for 는 QuerySet 전반에서 동작하며, 비동기 데이터베이스 API에는 asave() 같은 모델 메서드와 acreate()같은 QuerySet 메서드가 들어 있다. 스레드풀 래퍼 없이도 쿼리와 동시적인 외부 HTTP 호출을 await 하는 비동기 뷰를 쓸 수 있다. "동기 전용"이라는 비판이 쓰이던 시절의 Django와 비교하면, 이건 다른 프레임워크다.

동작을 결정하는 건 프레임워크 버전이 아니라 배포 프로토콜이고, 이건 Django 포럼이 계속 다시 설명해야 하는 대목이다. 비동기 주제 가이드 는 WSGI 서버 아래에서 비동기 뷰가 각자 일회성 이벤트 루프에서 실행된다고 밝힌다. 그래서 비동기 기능은 쓸 수 있지만 "비동기 스택의 이점은 얻지 못한다".

Python 스레드 없이 수백 개의 연결을 처리하는 것, 느린 스트리밍, 롱 폴링. 이런 것들에는 ASGI가 필요하다. 같은 코드, 다른 동시성 동작인데, 지금 어느 쪽을 쓰고 있는지 프레임워크는 알려 주지 않는다.

이 혼동은 수명이 길다. tomcypress라는 이름으로 글을 올린 사용자가 연 것이 Django 포럼의 한 스레드 비동기 뷰로 연달아 보낸 요청들이 왜 백그라운드 작업을 전부 실행하지 않는지 묻는 스레드였고, 포럼 단골인 KenWhitesell이 WSGI 이벤트 루프를 짚어 줬다. 그 대화는 2021년 것이고, 6.1에서도 달라진 건 없다.

게다가 바깥에서 이 혼동을 계속 강화하고 있다. TechVidvan의 Django 장단점 페이지는 독자에게 Django가 "여러 요청을 동시에 처리할 수 없다"고 말하는데, 이는 Django 6.1에 대해 틀린 말이고, 평가를 시작도 하기 전에 끝내 버리는 종류의 주장이다. 동시성은 프레임워크에 없는 무언가가 아니라, 배포가 결정하는 무언가다.

확실한 걸림돌은 트랜잭션이고, Django 자체의 비동기 문서 가 이를 분명히 밝힌다.

트랜잭션은 아직 비동기 모드에서 동작하지 않습니다. 트랜잭션 동작이 필요한 코드 조각이 있다면, 그 조각을 하나의 동기 함수로 작성하고 다음을 사용해 호출하기를 권합니다: sync_to_async().

같은 페이지는 프레임워크의 특정 핵심 부분을 "비동기에서 안전하지 않음"으로 분류하고 비동기 컨텍스트에서 실행되지 못하게 막는다. 시도하면 발생하는 것이 SynchronousOnlyOperation 다. 그러니 Django 6.1 비동기 애플리케이션의 모양은, 비동기 뷰와 비동기 읽기에 더해 쓰기에 원자성이 필요한 곳마다 동기 섬을 두는 형태다. 굴러는 가지만, 태생부터 비동기인 프레임워크와 같은 것은 아니다. 이 축에 대한 내 판단은 이렇다. 의미 있게 나아졌고, 끝나지는 않았으며, 동시성이 최우선이 아닌 모든 것에는 확실한 합격이다.

FastAPI가 Django를 잘못된 기본값으로 만들었나?

특정한, 그리고 늘어나고 있는 부류의 프로젝트에 대해서는 그렇다. 2024년 Python 개발자 설문 은 JetBrains와 Python Software Foundation이 2024년 10월과 11월에 걸쳐 3만 명이 넘는 참가자로부터 모은 것으로, 전체 응답자에서 FastAPI 38%, Django 35%, Flask 34%로 나왔다. Python을 가장 많이 쓰는 용도로 웹 개발을 고른 응답자 사이에서는 Django가 61%, FastAPI가 56%, Flask가 39%였다.

이 질문을 기획 회의에 들고 가기 전에 잘 들여다보라. 복수 선택 문항이기 때문이다. 응답자에게 물은 건 어떤 프레임워크를 쓰느냐이지 무엇을 골랐느냐가 아니고, Django 모놀리스를 유지보수하면서 FastAPI 서비스를 쓰는 개발자는 양쪽에 다 잡힌다. 이건 배타적인 시장 점유율이 아니며, 여기서 시장의 38%를 가진 사람은 아무도 없다. 이 수치가 보여 주는 건 갈라진 신호다. 전체 응답자에서는 FastAPI가 Django를 앞섰고, Python을 주로 웹 개발에 쓰는 응답자에서는 여전히 Django가 FastAPI를 앞섰다.

Django 전용 설문은 이미 이 프레임워크를 쓰고 있는 사람들에게서 나온 또 하나의 신호를 더한다. 2025년 Django 개발자 설문은 Django Software Foundation이 JetBrains와 함께, 2024년 11월부터 2025년 1월 사이에 모은 4,655건의 필터링된 응답을 대상으로 진행됐고, 82%가 Django로 업무 코드를 쓰고, 77%가 가장 많이 쓰는 프레임워크로 꼽았으며, 48%가 안정 릴리스마다 업그레이드한다는 결과가 나왔다. 1년 전의 40%에서 오른 수치다. 응답자가 자기 선택으로 참여했으므로, 이건 시장이 아니라 현재 사용자층을 설명한다. 사용의 폭과 헌신의 깊이는 다른 신호이고, Django의 두 번째 숫자는 첫 번째보다 건강하다.

FastAPI가 이기는 자리는 설문의 격차가 시사하는 것보다 더 좁고 더 날카롭다. Pydantic 모델이 검증 계층이고 생성된 OpenAPI 스키마가 계약서인, 타입이 주도하는 API 표면은 Django에 직렬화 계층을 얹은 것보다 낫다. FastAPI는 요청 계층에서 태생부터 비동기지만, 자체 문서 는 경로 연산을 어느 쪽으로든 쓸 수 있다고 분명히 밝힌다. 평범한 def 으로 선언된 핸들러나 의존성은 외부 스레드풀에서 실행된다.

그리고 관리자 화면도, 폼도, 템플릿도 없는 서비스는 Django의 배터리를 죽은 무게로 들고 다닌다. 프레임워크의 견해에 값을 치르고는 그 4분의 1만 쓰는 셈이다. 당신이 만드는 게 그런 것이라면, 그 흐름은 거품이 아니고 따라가는 게 맞다.

누가 Django를 골라야 하나?

관리자, 인증, 폼, ORM이 앞으로 할 일의 대부분이라면 6.1의 Django에 손을 뻗어라. 내부 도구, 마켓플레이스, 백오피스 SaaS 같은 것들이다. 그런 것들이 첫날부터 굴러가야 하는 소규모 팀에게도, 2029년에 자기 지원 기간이 어떤 모습일지 지금 알아야 하는 팀에게도 맞는 선택이다.

프레임워크의 견해가 실제 작업의 대부분을 덮어 주는 제품. 권한 행렬이 있고 로그인 뒤에 CRUD가 잔뜩 있는 모든 것. 여기서는 프레임워크가 구조적 결정을 대신해 주는 게 비용이 아니라 핵심이다. 그 결정들이야말로 어차피 당신이 만들었어야 할 것의 대부분이기 때문이다.

첫날부터 생산적이어야 하는 소규모 팀. 개발자 셋에 플랫폼 엔지니어가 없는 상황에서, 한 팀은 기능을 쓰기 시작하고 다른 팀은 인증 라이브러리를 검토하기 시작한다. 그 격차는 거기서부터 복리로 벌어진다.

이미 Django를 쓰면서 앞으로 3년을 계획하는 팀. Django 5.2는 2028년 4월까지 지원되는 바닥을 주고, 연간 주기는 그 이후로 예측 가능한 바닥을 준다. 읽히는 지원 활주로는 계획 단계에서 돈이 되는데, 이렇게 명확하게 손에 쥐여 주는 경우는 흔치 않다.

누가 Django를 고르지 말아야 하나?

뒤에 관리자 화면이 없는 고처리량 또는 스트리밍 API에 Django를 고르지 마라. 그런 형태의 프로젝트에는 FastAPI가 더 깔끔한 기본값이다. 올해 안에 트랜잭션까지 포함한 비동기 데이터 접근이 필요하다면 고르지 마라. 6.1에는 그게 없다. 그리고 배터리가 백그라운드 작업까지 돌려 줄 거라 기대하고 고르지도 마라.

관리자 화면도 폼도 없는 단일 고처리량 또는 스트리밍 API. Django가 잘하는 것 중 이런 형태의 프로젝트에서 하중을 받는 건 거의 없다. 그러니 라우터 하나와 검증기 하나면 됐을 서비스를 위해 프레임워크 하나의 구조 전체를 떠안고 유지보수하는 셈이 된다.

트랜잭션까지 포함해 완전한 비동기 데이터 접근이 지금 당장 필요한 팀. Django 6.1은 비동기 모드에서 트랜잭션을 지원하지 않는다. 쓰기 작업을 sync_to_async() 로 감싸는 건 정당한 패턴이지, 올해 안에 졸업할 임시방편이 아니다. 그게 용납되지 않는 곳에서는 잔상처가 아니라 차단 요인이다.

"필요한 게 다 들어 있다"는 말을 백그라운드 작업 실행까지 포함하는 것으로 읽는 팀. Tasks에는 워커가 딸려 오지 않는다. 6.0이 스택에서 큐를 없애 줬다고 가정한 계획이었다면, 이 프레임워크에 발을 담그기 전에 계획에 큐를 다시 넣어야 한다.

어떤 웹 프레임워크를 먼저 배울지는 답이 다른 별개의 질문이다. 아래 FAQ에 짧은 답이 있다.

Django가 어디서 멈추는지 아는 것이야말로 시작을 안전하게 만든다. 위의 출구들은 발을 담근 뒤에 발견되는 게 아니라, 담그기 전에 보인다.

자주 묻는 질문

Django는 죽었나?

아니다. Django는 2025년 12월과 2026년 8월 사이에 기능 릴리스를 두 번 냈고, 2030년대까지 이어지는 개편된 릴리스 계획을 발표했다. FastAPI는 빠르게 성장했고 2024년 Python 개발자 설문의 전체 응답자에서 38% 대 35%로 Django를 앞섰지만, Python을 주로 웹 개발에 쓰는 응답자에서는 Django가 61% 대 56%로 앞섰다. 더 새로운 프레임워크가 빠르게 자란다는 것과 더 오래된 것이 죽었다는 것은 다른 주장이다.

Django는 초보자에게 좋은가?

그렇다, 다만 한 번에 배울 게 가장 많다는 단서가 붙는다. Django를 생산적으로 만드는 건 그 폭인데, 그 말은 초보자가 뭔가를 내놓기도 전에 ORM, 마이그레이션, 템플릿 계층, 관리자 화면과 마주친다는 뜻이다. 반대편 주장도 읽어 볼 만하다. Bite Code! 글 은 초보자가 바로 그 기본값 때문에 Django로 시작해야 한다고 주장한다. 그 기본값이, 미니멀한 프레임워크라면 혼자 저지르게 내버려 두었을 아키텍처 실수를 막아 주기 때문이다.

Django가 Flask보다 빠른가?

보편적인 답은 없다. 이 리뷰를 위해 벤치마크는 돌리지 않았고, 워크로드와 배포 방식을 모르는 벤치마크는 나도 믿지 않는다. 많은 애플리케이션에서 데이터베이스 쿼리, N+1, 외부 API 호출이 프레임워크 오버헤드보다 더 큰 영향을 준다. 순수 요청 처리량이 결정에 중요하다면, 실제로 돌릴 애플리케이션과 서버 구성을 직접 측정하라.

새 프로젝트는 어느 Django 버전으로 시작해야 하나?

가장 긴 지원 기간이 가장 중요하다면 5.2로 시작하라. 현재 LTS이고 2028년 4월까지 지원된다. Tasks 프레임워크와 최신 6.x 기능을 원한다면 6.1로 시작하되, 기본 지원이 대략 2027년 4월까지, 연장 지원이 2027년 12월까지라는 걸 받아들이고, 2027년 4월에 나올 Django 6.2 LTS로의 업그레이드를 계획하라. Django 6.2는 연장 지원이 2030년 4월까지로 예정돼 있다. 2028년 1월부터는 해마다 나오는 기능 릴리스마다 3년의 지원이 붙는다.

Django와 FastAPI 중 무엇을 먼저 배워야 하나?

당신이 하고 싶은 일에 맞는 쪽을 배워라. Django는 완결된 웹 애플리케이션이 어떻게 맞물리는지를 가르친다. 데이터 모델링, 마이그레이션, 인증, 폼, 템플릿, 관리자 화면까지, 구조는 이미 정해진 채로다. FastAPI는 타입이 붙은 API 설계와 비동기 Python을 가르치는데, 정해진 건 거의 없다. 추상적으로 보면 둘 다 초보자에게 친절한 선택지가 아니며, 목표로 하는 일자리에 더 가까운 쪽을 고르는 편이 더 쉬운 쪽을 고르는 것보다 낫다.