장고에서는 하나의 프로젝트를 생성하고, 그 내부에 프로젝트에서 필요한 기능을 수행하는 앱들을 구성한다. 이 앱들이 상호작용하는 과정을 짜는 것이 장고 웹 프레임워크를 사용한 개발이라 봐도 무방하다. 각각의 앱들은 개발자가 부여한 기능을 충실히 수행하며, 필요시에는 다른 앱과의 상호작용을 하기도 한다. 만약 하나의 앱을 설명하는 데에 말이 필요 이상으로 길어진다면 해당 앱은 더 작은 규모의 앱들로 나누어질 수 있다는 말이다. 이번 포스트에서는 장고 앱을 디자인하는 데에 필요한 기본적이고 필수적인 조건들에 대해서 알아보자.


장고 앱의 정의

장고에서의 앱(App)은 다음을 지칭한다.

  • 장고 프로젝트 : 장고 프레임워크를 기반으로 한 웹 어플리케이션 하나를 지칭할 수 있다.
  • 장고 앱 : 프로젝트 내부 하나의 기능을 표현하기 위해 디자인된 작은 라이브러리다. 장고의 프로젝트는 여러 개의 장고 앱으로 구성되어 있으며 때로는 외부 장고 패키지를 지칭하기도 한다.
  • INSTALLED_APPS : 프로젝트에서 사용하기 위해 세팅파일에 등록한 장고 앱들을 말한다.
  • 서드파티(외부) 장고 패키지 : 파이썬 패키지 도구(ex_ pip)에 의해 재사용이 가능한 플러그인 형태로 이용할 수 있는 장고 앱을 말한다.


1. 앱 구성 가정하기

현재 장고를 사용하여 웹서비스 Wordy Gallery의 앱구조를 들여다보면 다음과 같다.

  • art : 웹서비스의 주요 자원인 작품에 대한 정보를 기록하고 웹서비스에 보여준다.
  • motif : 작품에 대한 댓글 공간을 구성하고 그 안에서 사용자들이 댓글로 소통한다.
  • member : 사용자 정보를 저장하고 인증을 통해 해당 웹서비스를 사용할 수 있게 한다.

각각의 앱들은 하나의 역할만 수행하지만 서론에서 말했듯이, 서로 상호작용을 할 수 있다. 이렇게 세분화하여 앱을 구성할 경우에는 각각의 기능을 모듈화하여 관리하기에도 쉽고 나중에 사이트를 확장하더라도 앱을 추가해나가면 되므로 관리상의 이점이 크다.


2. 장고 앱 이름 작명하기

  1. 독특한 이름보다는 일반적인 이름을 사용하자
  2. 앱의 이름은 곧 URL에 표시되는 이름일 수도 있다. 따라서 주소를 고려하여 이해하기 쉬운 단어를 사용하자.
  3. 앱을 임포트하여 사용할 경우를 대비하여 적절한 작명 규칙을 따른다. - 예를 들어, 숫자, 대시, 마침표, 스페이스, 특수문자 등은 PEP-8의 작명규칙에 어긋나므로 띄어쓰기가 필요한 이름의 경우에는 _를 사용한다.
  4. 되도록이면 앱을 나타낼 수 있는 명료한 하나의 단어로 작명하는 것이 좋다.


3. 앱 규모 가늠하기

앱을 디자인하는 것은 매우 주관적인 작업이다. 프로젝트 규모를 먼저 고려한 후에 기능을 얼마나 세분화할 것인가는 개발자의 결정에 달려있기 때문이다. 도서에 따르면 좋은 장고 앱을 설계하는 것은 더글러스 맥글로이의 유닉스 철학을 따르는 것과 같다고 한다.

즉, “한번에 한 가지 일을 하고 그 한 가지 일을 출실히 하는 프로그램을 짜는 것”이다. 앱 하나의 크기를 작게 유지하여 프로젝트를 진행해나가다 보면 이것이 관리 및 설계 측면에서 큰 앱 하나를 관리하는 것보다 더 확장적이고 유연한 선택이었다는 것을 알게 될 것이다.


4. 앱 내부 모듈 살펴보기

startapp 명령어를 사용하여 앱을 생성할 경우 공통적으로 생성되는 모듈이 있고 따로 생성하여 앱 기능 구현에 사용할 수 있는 비공통 모듈들이 있다. 평소에 접해보지 못한 비공통 모듈들에 대해 요약해보았다.

django_app/
  art/ 
    # 모델 믹스인 위치에 대한 옵션
    behaviors.py
    
    # 앱 별 세팅을 저장해놓는 파일
    constants.py
    
    # 렌더할 정보를 전송하는 커스텀 프로세서 생성파일
    context_processors.py
    
    # 커스텀 데코레이터를 정의해놓은 파일
    decorators.py
    
    # 프로젝트에서 사용되는 커스텀 모델이나 컴포넌트 저장
    db/
    
    # 커스텀 예외처리를 정의해놓은 파일
    exceptions.py
    
    # 커스텀 폼 필드, 모델 필드 등을 정의해놓은 파일
    fields.py
    
    # 테스트 데이터 팩터리 파일
    factories.py
    
    # 뷰와 모델을 가볍게 하기 위해 코드를 따로 저장하는 파일
    helpers.py
    
    # models.py가 커질 경우 커스텀 모델 매니저를 따로 관리
    managers.py	 



Julia Hwang

디발자를 꿈꾸는 웹개발자의 블로그입니다.