예전에 근무했던 조직에는 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 기반 빌드 프로세스를 선호하게 되었음
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 설정은 기본값으로 넣지 않았는데, 좀 더 검토 후 추가할 예정임
Django의 “batteries included” 철학은 AI 코드 생성에 완벽히 어울림
관리자 패널, 로그인, 비밀번호 재설정 등 기본 기능이 이미 잘 갖춰져 있어서, AI가 작은 코드베이스로도 완전한 사이트를 만들 수 있음
코드가 작고 명확하니 AI가 반복적으로 개선하기도 쉬움
거대한 컴포넌트 대신 명확한 모델과 템플릿이 있어서, AI가 생성한 코드를 리뷰하기도 쉬움
또 Django admin이 독립된 ground truth로 존재하므로, 프론트엔드가 망가져도 데이터를 다룰 수 있음
다만 Python 생태계가 gevent 모델을 채택하지 않은 건 아쉬움. 그랬다면 비동기 전환이 훨씬 매끄러웠을 것임
Flask나 FastAPI처럼 느슨하게 연결된 프레임워크보다 훨씬 통합적임
이런 차이가 결국 수많은 작은 불편함(papercuts) 을 줄여줌
오래된 .NET 앱을 리라이트했는데 Rails는 거의 완벽하게 변환했지만 Django는 어려워했음
이번 릴리스의 template partials 기능은 꽤 괜찮아 보임
하지만 타입 주석(type annotations) 상태는 여전히 불편함
django-stubs는 mypy 플러그인이 필요하고, django-types는 pyright용 포크지만 동기화가 잘 안 됨
pylance는 또 자체 포크를 씀
다음 버전에서는 HttpRequest, HttpResponse, View, Model 같은 기본 타입이라도 공식적으로 포함되길 바람
Django 덕분에 웹 개발이 정말 즐거웠음
다른 프레임워크로 바꿔도 결국 Django로 돌아오게 됨. 후회 없는 선택이었음
다른 프레임워크를 써봐도 Rails의 편리함 때문에 다시 돌아오게 됨
다만 Rails에는 기본 Admin UI가 없다는 게 아쉬움
완전한 풀스택을 원한다면 Laravel이나 Rails를 보는 게 나음
PHP 시절부터 웹을 해왔는데 Django는 항상 그저 그런 느낌이었음
Django는 내 첫 프리랜스 대형 프로젝트였고, 여전히 편안하게 느껴짐
여러 실험적인 시도를 해봤지만 항상 잘 작동했음. Django에게 감사함
15년 가까이 Django를 거의 독점적으로 써왔음
다른 프레임워크도 많이 시도했지만 Django만큼 손에 맞는 것은 없었음
이번 릴리스에서 task framework를 추가했지만, 백엔드와 워커가 포함되지 않은 건 아쉬움
차라리 다음 버전에서 완전한 형태로 포함되길 바람
Django의 포함형 구성(batteries included) 덕분에 규모와 상관없이 어떤 프로젝트에도 적합함
팀과 기여자들에게 찬사를 보냄
우리는 어떻게 SPA 시대에 들어오게 되었는지 궁금함. 단순히 로딩 스피너를 없애려던 건지, 더 깊은 이유가 있었는지 알고 싶음
웹·iOS·Android가 하나의 백엔드를 공유하도록 만들면서, 자연스럽게 SPA 패턴이 확산됨
나도 여전히 SPA를 만들지만, 언젠가 Django + htmx로 큰 프로젝트를 해보고 싶음
페이지 리로드 없이 앱처럼 동작하는 게 매력적이었지만, 실제로는 강제 새로고침이 필요한 경우도 많았음
그래도 데이터와 표현을 분리하는 구조는 우아하다고 생각함
그래서 JS로 문서를 앱처럼 바꾸려는 시도가 이어졌음
결국 프론트엔드와 백엔드를 분리하고, API 계약과 검증 절차가 생겼음
나중엔 다시 서버 컴포넌트로 통합하려는 흐름이 생겼고, 지금 우리가 그 지점에 있음
참고로 예전식 웹폼 예시는 이 링크에서 볼 수 있음
그래서 나는 TypeScript 기반 빌드 프로세스를 선호하게 되었음
Django를 쓸 때마다 단순히 즐거움을 느낌. 그게 전부임