내 Django Rapid Architecture 간략 개요
Source: Dev.to
며칠 전, Reddit을 탐색하던 중 Django Rapid Architecture 라는 Django 프로젝트용 아키텍처 제안을 발견했습니다. 짧은 문서에 몇 가지 가이드라인과 원칙이 정리되어 있었죠. 저는 Django를 좋아하고 Django는 여러분이 사용해야 할 최고의 도구 중 하나입니다 라고 생각하기 때문에, 해당 문서를 읽고 여러분을 위해 요약했습니다.
Django Rapid Architecture는 유지보수 가능한 Django 코드베이스를 만들기 위해 선별된 패턴과 관용구를 모아둔 컬렉션입니다. 저자는 이것이 15년 이상의 경험과 100개 이상의 실전 프로젝트에서 도출된 것이라고 주장합니다.
Django 기본 아키텍처에 문제점은 무엇인가?
저자에 따르면 Django의 앱은 재사용 가능한 컴포넌트를 위해 설계된 것이지, 프로젝트 고유의 비즈니스 로직을 위한 것이 아닙니다. 모든 코드를 앱에 강제로 넣으면 유연성이 떨어집니다:
- 마이그레이션은 초기 경계 결정을 되돌릴 수 없게 만들며, 이는 동적인 프로젝트에 필요한 유연한 리팩터링을 방해합니다.
- 앱은 수직적 캡슐화를 선호하여 뷰와 모델을 기능별로 묶습니다. 서로 연결된 비즈니스 도메인과 인터페이스를 가진 실제 시스템에서는 이것이 이상적이지 않습니다.
Django Rapid Architecture에 따른 프로젝트 구조화 방법
Django의 기본 패러다임 대신 레이어별로 구조화합니다:
- Data – 모델 및 마이그레이션
- Interfaces – HTTP 뷰, 관리 명령어 등
- Business logic – 리더 및 액션 (모델과 분리)
Remember: Django는 모놀리식입니다.
파일‑구조 예시
Below is a typical layout that follows the proposed approach:
project/
├── actions
│ └── some_domain.py
├── data
│ ├── migrations
│ │ └── 0001_initial.py
│ └── models
│ └── some_model.py
├── interfaces
│ ├── management_commands
│ │ └── management
│ │ └── commands
│ │ └── some_management_command.py
│ └── http
│ ├── api
│ │ ├── urls.py
│ │ └── views.py
│ └── urls.py
├── readers
│ └── some_domain.py
├── settings.py
└── wsgi.py핵심 아이디어는 코드가 actions, data, interfaces, readers 로 구분된다는 것입니다.
Django Rapid Architecture의 레이어
데이터를 어떻게 다룰까?
모델은 어떻게 할까?
- 모든 모델을
data라는 단일 앱에 넣는다. - 메서드가 많은 초대형·복잡한 모델은 피하고, 복잡한 로직은 모델 밖에 두어야 한다.
- Django의
Model기본 클래스를 제외하고는 상속을 사용하지 않는다. 이렇게 하면 어떤 개발자라도 모델의 목적을 빠르게 파악할 수 있다.
비즈니스 로직은 어디에 두어야 할까?
비즈니스 로직 코드는 모델 인스턴스, QuerySet, 혹은 일반 값 위에서 동작하는 명확한 인터페이스를 가진 일반 함수에 두어야 한다. 꼭 필요하지 않은 한 복잡한 상속, 믹스인, 데코레이터, 커스텀 매니저는 사용하지 않는다.
리더(읽는 부분)는 어떻게 다룰까?
Django 응답을 제공하는 과정은 세 가지 핵심 파트로 구성된다:
- 쿼리 – 뷰에서 QuerySet을 사용해 만든다; 어떤 DB 행·열을 가져올지 정의하고, 필터링·조인·최적화를 적용한다. 일부 로직은 커스텀 QuerySet에 들어갈 수 있다.
- 값 – 클라이언트에 전달할 데이터. 기본 값은 모델 필드에서 나오며, 복잡한 비즈니스 로직은 종종 모델 메서드(예:
get_absolute_url)에 들어가 원시 데이터를 사용 가능한 형태로 변환한다. - 프로젝션 – 클라이언트를 위한 최종 데이터 형태 지정. JSON API라면 dict/list 로 직렬화하고, HTML이라면 템플릿 렌더링을 수행한다. 두 경우 모두 2단계에서 만든 값을 사용한다.
리더에서 사용하는 함수 유형
원본 자료에는 다양한 예시가 있지만, 주요 카테고리는 다음과 같다:
- QuerySet 함수 – QuerySet 구성을 캡슐화하고, 합성 및 고차 함수를 활용한다.
- Producer 함수 – 모델 인스턴스를 받아 파생 값을 반환한다.
- Projector 함수 – Producer 위에 구축되어, 필드 이름을 파생 값에 매핑한 딕셔너리를 반환한다.
TL;DR – Django Rapid Architecture는 단일 모놀리식 Django 프로젝트 안에서 수평적·레이어 기반 레이아웃(
data | readers | actions | interfaces)을 권장한다. 모델은 단순하게 유지하고, 비즈니스 로직은 일반 함수에 두며, 관심사를 분리해 유지보수와 리팩터링을 용이하게 만든다.
Source: …
개요
작업
REST APIs는 복잡하고 일관성이 없습니다. 따라서 모든 보조 HTTP 동사를 잊고 POST와 GET만 사용해야 합니다.
단일 URL은 GET 또는 POST에만 응답하는 단일 뷰에 매핑되어야 하며, 두 가지를 모두 지원해서는 안 됩니다. 이는 여기에 설명된 RPC/gRPC 패러다임을 반영합니다.
인터페이스
Django를 이용한 서버‑사이드 렌더링 (SSR)
React와 같은 API를 사용하는 대신 서버에서 HTML을 생성하면 생산성을 높일 수 있습니다.
HTMX와 Django의 결합을 권장합니다; 해당 글에서는 이 접근법이 React 사용보다 우수하다고까지 평가합니다.
복잡성을 피하기 위한 인터페이스 중첩
코드를 URL 세그먼트 계층 구조를 모방하도록 구성합니다:
project/interfaces/http/urls.py
project/interfaces/http/api/urls.py
project/interfaces/http/api/admin/urls.py
project/interfaces/http/api/admin/widgets/urls.py
project/interfaces/http/api/admin/widgets/views.py관리 명령어
Django Management commands도 하나의 인터페이스이며, 뷰와 동일하게 다루어야 합니다.
Django Rapid Architecture에 대해 더 배우려면?
이 텍스트는 주요 아이디어에 대한 개요에 불과합니다. Django Rapid Architecture 제안에 대해 더 깊이 탐구하려면 원본을 읽어보세요:
- 공식 사이트: (원문에 링크가 제공되지 않음)
문서는 짧으며—몇 페이지 정도—추가 예시와 설계 결정에 대한 근거를 포함하고 있습니다.