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 개발자를 찾는다면 연락 바람 (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을 써봤음
    예시는 여기 코드에 있음
  • 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 웹 프레임워크에서 쓸 수 있고, 훨씬 쾌적한 개발 경험을 줌