[Django 핵심 원리] MTV 공부 전에 알면 좋을 것들

Django로 개발하다 최근에 Spring으로 개발하고 있습니다. Spring 공부를 시작하며 우선적으로 IoC, DI, AOP 등 Spring 핵심 원리들을 MVC 패턴 전에 먼저 공부해야 했습니다. 또한 MVC 이외에 Sevlet, Bean 등 Spring 내부 구성 요소와 디자인 패턴 개념까지 필요했습니다. Spring 개발을 위해서 알아야 할 원리가 많다는 것입니다.

Django를 공부할 때는 바로 MTV부터 시작했던 기억이 있어 Django에는 왜 핵심 원리를 먼저 공부하지 않았을까 궁금증이 생겼습니다. 있긴 할 텐데 별로 주목받지 못하는 느낌입니다. 구글에 이것저것 키워드로 검색해도 MTV 패턴 이외에 Spring과 같은 깊이의 문서가 잘 안보였습니다. (제가 못 찾았을 수도 있습니다.)

그래서 Django 핵심 원리를 정리해 보았습니다. 편하게 개발했던 Django에 이런 이유가 있었구나 생각할 수 있어 꽤 재밌었습니다. 은근히 Python 색깔을 많이 느낄 수 있습니다. Django 개발을 배우는 초기 과정에서 MTV를 시작하기 전 이러한 개념을 알았으면 좋겠습니다.

대부분 Mozilla와 Django 공식 문서를 번역&정리하였습니다.

 

🔹 Django 프레임워크 특징

• 완벽한 (Complete)
  • Django는 개발자가 ‘즉각적으로’ 수행할 수 있는 기능을 제공하는 것을 목표합니다.
  • 필요한 기능 단위로 만들어서 공식 문서로 관리하며, 개발자가 import 해서 사용할 수 있게 합니다.
  • 개발을 위해 Complete한 기능을 제공하지만, 확장에 열려있어 원하는 구성 요소를 추가하여 사용할 수 있습니다.
• 다재다능한 (Versatile)
  • Django는 모든 유형의 웹 사이트를 구축하는데 도움이 되도록 개발되었습니다. 뉴스 사이트, SNS, 쇼핑몰 등 원하는 목적에 맞게 개발할 수 있습니다.
  • 대부분의 형식으로 (HTML, RSS, JSON, XML) 요청/응답을 주고받을 수 있어, 다양한 프레임워크와 함께 동작시킬 수 있습니다.
• 안전한 (Secure)
  • Django는 웹사이트를 보호하기 위해 개발자가 올바른 선택을 할 수 있게 도와줍니다.
  • 예를 들면 쿠키에 세션 정보를 넣거나 암호를 그대로 저장하는 것 같은 일반적인 실수를 방지하여 사용자 계정과 암호를 안전하게 관리해 줍니다.
  • 이외에도 SQL 인젝션, 사이트 간 스크립팅, 요청 위조, 클릭재킹 등 다양한 공격들로부터 보호해줍니다.
• 확장 가능한 (Scalable)
  • Django는 Shared-nothing architecture를 사용합니다. 구성요소들이 독립적으로 있다는 의미입니다.
  • 독립적인 구성요소로 인해 아키텍처 변경이 유리합니다. 대규모 Web 개발 프레임워크들의 특징답게 캐싱 서버, DB 서버, 애플리케이션 서버 등 분리하여 scale out이 가능합니다.
  • Django로 큰 스케일을 감당한 서비스는 Instagram, Disqus 등이 있습니다.
• 유지보수성이 높은 (Maintainable)
  • Django는 코드 재사용을 높이는 디자인 패턴을 추구합니다.
  • DRY(Don’t Repeat Yourself) 원칙으로 중복을 최대한 줄여야 합니다.
• 이식성 좋은 (Portable)
  • 번역이 가장 애매한데, 호환성이 좋다고 생각해도 좋습니다.
  • 특정 서버나 플랫폼에 얽매이지 않고 Linux, Windows, Mac 등 다양한 버전에서 실행이 가능합니다.

 

🔹 Django는 다소 독단적입니다

독단적이라는 것은 어떤 문제에 대해 프레임워크가 가진 ‘의견’이 있다는 것입니다. Django는 특정 작업을 하는데 ‘올바를 방법’을 제시하여 해당 개념이 적은 개발자가 우선은 쉽게 기능을 도입할 수 있도록 도와줍니다. 이 때문에 특정 영역에서 빠른 개발이 가능하다는 장점이 생깁니다. 하지만, 의견에 약점이 있을 때 덜 유연해진다는 단점도 있습니다.

반대로 독단적이지 않은 프레임워크들은 문제를 해결하기 위해 개발자가 알아서 구성요소를 쓰도록 어떠한 의견은 제시하지 않습니다. Django는 스스로 ‘다소 독단적’이라고 표현하고 있습니다. 대부분의 문제에서 한두 가지 선호하는 방법을 제공하나, 다른 기능을 사용하도록 확장성을 열어줍니다.

 

🔹 왜 MVC가 아닌 MTV일까요?

Spring 등 다양한 웹 프레임워크는 MVC 패턴을 일반적으로 사용합니다. 하지만 Django는 이를 알고 있음에도 MTV 패턴을 표준으로 하였습니다. Django 공식문서 설명을 살펴봅시다.

Django 개발자는 MVC의 View를 ‘사용자들이 보는 데이터’로 생각했습니다. 여기서 ‘어떻게’ 데이터가 보이는지 보다는 ‘어떤’ 데이터를 보여줄지 아는 것이 더 중요합니다. 따라서 Django에서 View는 특정 URL에 대한 파이썬 콜백 함수입니다. 왜냐하면, 콜백 함수가 어떤 데이터를 보여주는지 설명하기 때문입니다. Django Template은 ‘어떻게’ 데이터가 보이는지를 구현합니다. Django View가 '어떤' 데이터를 보여주는지 관장한다는 것을 기억합시다.

그렇다면 Controller는 어디 있을까요? Django에서 Controller는 프레임워크 자체라고 합니다. 프레임워크가 urls.py를 보고 요청을 적절한 view에게 전달하기 때문입니다.

 

🔹 Django 개발 철학

이제 개발 철학을 살펴보겠습니다. 개발 철학을 알아야 프레임워크를 사용할 때, 소위 좋은 코드를 작성할 수 있다고 생각합니다. 전체 개발 철학은 Django 공식문서에서 확인 가능합니다. 여기서는 놓치기 쉬운 중요한 것만 다루겠습니다.

• 적은 코드로 신속한 개발을 추구합니다. 파이썬의 철학을 많이 상속받았습니다. 적은 코드를 사용하지만 틀에 박힌 코드는 배제합니다.
• 명시적인 것이 묵시적인 것보다 좋습니다. 이 역시 파이썬 철학입니다. Django가 소위 ‘마법’을 부리지 말아야 한다는 것이며 개발자가 명시적으로 흐름을 알도록 개발되어야 합니다. (PEP 20에 더 자세한 개념 설명이 있습니다.)
• SQL문이 가능한 적은 횟수로 실행되도록 내부적으로 최적화되어야 합니다. 저장을 프레임워크에서 묵시적으로 처리해주는 대신 개발자가 save()를 사용하도록 명시화했습니다. Django는 이러한 최적화를 위해 select_related() QuerySet 메서드를 제공합니다.
• URL 설계 시 하부 python 코드와 결합되어서는 안 됩니다. 모든 이름을 일치시킬 필요가 없다는 말입니다. 사용자 관점과 개발자 관점이 만나는 부분을 느슨하게 처리해야 합니다.
• Template는 반복적인 컴포넌트를 분리해야 합니다. Nevbar, Footer 등이 이에 해당할 수 있습니다.
• View를 작성하는 것은 python을 작성하는 것만큼 단순해야 합니다. 개발자는 함수로 처리할 수 있는 일을 하기 위해 클래스의 인스턴스를 굳이 생성하지 않아도 됩니다. (Spring과 차이!)

 

🔹 Django 성능 최적화

‘성능’의 의미를 명확히 이해하는 것이 중요합니다. 속도가 프로그램에 중요한 지표일 수 있지만, 때로는 메모리 소비를 줄이거나 네트워크의 자원을 아끼는 것이 더 유익할 때가 있습니다. 또한 프로그램 외적으로 개발자의 시간을 줄이는 게 더 유익할 때도 있습니다. 목표하는 성능 향상이 무엇인지, 성능이 어디서 나빠지는지 명확하게 확인해야 합니다.

Django는 SQL 쿼리에 소요되는 시간을 측정하는 django-debug-toolbar를 제공합니다. 또한 많은 웹 프레임워크가 제공하는 캐싱, lazy, ORM 최적화, 미들웨어 설정 등 다양한 방법을 제공합니다.

 

🔹 Django 배포

Django가 독단적인 스텐스를 취하지만 배포까지 지침으로 제공하기는 어렵습니다. Django는 개발 테스트로 사용하는 runserver를 배포에 사용하지 말라는 것만 지침으로 제공합니다.

현재 Django에서 공식적으로 배포에 지원하는 인터페이스는 WSGI, ASGI 두 가지입니다. WSGI는 동기적 방식으로 python 코드를 웹 서버에 제공하는 인터페이스입니다. 반면, ASGI는 비동기 기능을 제공하는 표준입니다.

Django 공식문서에서 WSGI, ASGI를 다양한 툴(Gunicorn, uWSGI, Apach 등)에서 어떻게 쓰는지 안내하고 있습니다. 여기서 다루지는 않겠습니다.

배포 전 체크리스트

Django는 자동으로 배포 시 문제가 있는 부분을 확인해줍니다. manage.py check —deploy 명령어를 통해 아래와 같이 결과를 볼 수 있습니다. Django의 철학을 공부했기에 이러한 안내가 자연스럽게 생각됩니다.

공식 문서에 에러들과 주의점을 참고하시기 바랍니다.

 

참고한 문서

• https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django
• https://docs.djangoproject.com/en/4.0/