> **핵심요약:**  
> - Django App은 단순한 폴더 분리가 아님  
> - 배포 단위라기보다는 **비즈니스 도메인 분리 단위**  
> - [[DRF]]에서는 API 기능별 모듈처럼 동작해서 장점이 명확함  
> - 일반 Django 웹앱에서는 처음엔 필요성이 덜 느껴질 수 있음  
> - 하지만 프로젝트가 커질수록 모델, Admin, 테스트, 마이그레이션 관리에서 차이가 커짐  
> - 잘 만든 App은 나중에 다른 프로젝트로 옮길 수 있는 **재사용 가능한 자산**이 됨  


[[Django]] 프로젝트는 하나의 서버로 배포되더라도 `startapp`으로 여러 앱을 나눌 수 있음.
DRF 기반 Headless API 서버에서는 이 구조가 특히 자연스럽지만, 템플릿 기반 Django 웹앱에서도 앱 분리는 여전히 의미가 있음.


![Django 프로젝트 구조 개념도](/media/whitedec/blog_img/fc8aa3e622234c4689779c58a2b8b32e.webp)


## DRF에서 App 분리가 잘 맞는 이유 {#sec-f9d183702e4a}

* API 경계가 명확함

  * `accounts`
  * `posts`
  * `billing`
  * `notifications`

* 각 앱이 독립적인 API 묶음처럼 동작

  * models
  * serializers
  * views / viewsets
  * permissions
  * urls
  * tests

* 하나의 DRF 서버 안에서 여러 기능을 표준적인 방식으로 확장 가능

* 서로 다른 앱이 같은 프로젝트 안에 있어서 예상치 못한 시너지도 생김

  * 글 발행 → 알림 생성
  * 결제 상태 → 사용자 권한 변경
  * 사용자 설정 → 콘텐츠 노출 방식 변경

## 일반 Django 웹앱에서 생기는 의문 {#sec-5b615e36b016}

템플릿 기반 Django 웹앱에서는 앱을 나눠도 결국:

* 같은 서버에서 실행됨
* 같은 DB를 사용함
* 같은 settings를 공유함
* 같은 배포 단위로 묶임
* 템플릿 흐름도 서로 섞이기 쉬움

그래서 작은 웹앱에서는 “굳이 앱을 나눠야 하나?”라는 생각이 들 수 있음.

## 그래도 App을 나누는 이유 {#sec-ba9a6a819246}

* 모델이 너무 커지는 것을 막음
* Admin 화면이 도메인별로 정리됨
* migrations 이력이 앱별로 나뉨
* 특정 앱만 테스트하기 쉬움
* import 구조를 의식하게 되어 스파게티 코드 방지에 도움
* 나중에 기능을 분리하거나 API화할 때 경계가 이미 생겨 있음

## App은 재사용 가능한 부품이 될 수 있음 {#sec-0f9d2f3a0f0a}

Django의 앱 구조는 기능을 **Plug-and-Play 가능한 부품**처럼 만들 수 있게 해줌.

프로젝트 내부에서 만든 앱이라도 구조를 잘 잡으면, 나중에 다른 프로젝트로 옮기기 쉬움.

예를 들어:

* 알림 기능 → `notifications`
* 태그 기능 → `tags`
* 결제 기능 → `billing`

이런 앱을 독립적으로 만들어두면, 다음 프로젝트에서 다음처럼 재사용할 수 있음.

* 앱 폴더 복사
* `INSTALLED_APPS`에 추가
* 필요한 URL 연결
* migrations 실행
* 템플릿 또는 설정만 프로젝트에 맞게 조정

Django 생태계의 유명한 라이브러리들도 이런 방식으로 제공됨.

* `django-allauth` : 회원가입, 로그인, 소셜 로그인 기능을 앱 형태로 제공

* `django-taggit` : 태그 기능을 재사용 가능한 앱으로 제공

* `django-tailwind` :  Django 프로젝트 안에서 Tailwind 개발 환경을 앱 형태로 통합

즉, Django App은 단순히 “내 프로젝트 안의 폴더”가 아니라, 잘 설계하면 다른 프로젝트에서도 다시 쓸 수 있는 **기능 자산**이 될 수 있음.


## 좋은 분리 기준 {#sec-638181ef3b61}

앱을 나눌 만한 신호:

* 독립적인 데이터 모델이 있음
* 별도의 Admin 그룹이 필요함
* 자체 비즈니스 로직이 있음
* 테스트를 따로 돌리고 싶음
* 나중에 API 또는 별도 서비스로 분리될 가능성이 있음
* 기능 이름이 서비스 도메인으로 설명됨
* 다른 프로젝트에서도 다시 쓸 가능성이 있음

예:

* `accounts`
* `billing`
* `notifications`
* `support`
* `analytics`


## 결론 {#sec-85c066cfb297}

[[Django]] 프로젝트에서 App 의 구분은

> 프로젝트가 커졌을 때 사람이 이해할 수 있는 단위로 복잡도를 접어두는 구조

그리고 한 걸음 더 나아가면:

> 반복해서 사용할 수 있는 기능을 자산화하는 Django식 모듈 시스템

[[DRF]]에서는 이 장점이 API 경계와 잘 맞아서 바로 드러나고,
일반 Django 웹앱에서는 프로젝트가 커지거나 여러 프로젝트를 만들기 시작할 때 그 가치가 드러나는 경향이 있음.