2014년에 Django로 개발하면서 실수한 부분

저 같은 뉴비에게는 꽤나 도움이 되는 가이드여서, 더 잘 이해하고자 번역을 해보았습니다. (이미 looah에 올렸던 글을 제 블로그로 옮겨와서 포매팅했어요.) 번역을 허락해 준 Joseph Misiti 님께 고마움을 전합니다.

원문 - Django Development Mistakes in 2014

2015년이 얼마 남지 않은 시점에, 저는 2014년 동안 개발에 대한 접근법이 어떻게 달라졌는지를 생각해보았습니다. 이전 글(회사를 시작하기 전 Django에 대해 알았으면 좋았을 11가지 사실)에서 시작한 목록을 추가할 시점이 된 것이죠.

1. Postgres를 주 DB로 선택하세요

네. 제가 이전 글에서 주 DB로 MongoDB를 추천했던 사실을 잘 알고 있습니다. 그런데 1년 반 정도 사용하다 보니 추천하지 않을 이유들이 좀 생겼습니다.

• Django 1.7에서도 Django ORM은 여전히 MongoDB를 지원하지 않습니다. Mongoengine나 PyMongo를 사용해야 하죠. 이 두 라이브러리는 훌륭하지만, Django admin 같은 도구를 사용할 수는 없습니다. 이건 정말 끔찍하며, 제가 MongoDB를 주 DB로 사용하지 않게 된 이유이기도 합니다.
• 2014년 12월 18일부터 Postgres는 JSONB 데이터 타입을 지원합니다. 이를 통해 Postgres에 "문서"를 저장할 수 있으며, MongoDB에서처럼 비슷하게 쿼리를 실행할 수도 있습니다. 성능 문제를 겪지 않고서도 말이죠.
• (MongoDB를 선택하는 순간) Django ORM을 사용한다고 가정하는 대다수 서드파티 라이브러리가 쓸모 없게 됩니다. 이는 Django의 생태계 대다수를 사용할 수 없다는 의미입니다. Django 생태계는 매우 훌륭하며, 매일 발전하고 있습니다. 이걸 사용할 수 없다니!

OSX에서 개발하고 있다면 Postgres 코드를 다운받아 빌드하지 마시고, Postgres 앱(http://postgresapp.com/)을 사용하세요. 시간을 많이 절약해줄 겁니다.

2. 유닛 테스트를 작성하기 쉽게, 유닛 테스트 인프라를 구성하세요.

Django와 테스트 주도 개발(TDD) 방식에 대해 수많은 찬반 논쟁이 벌어지고 있습니다. 저는 어느 한 쪽 편을 들 생각은 없지만, 모든 프로젝트에서 유닛 테스트를 작성하기 쉽게(또한 재미있게) 해주는 프레임워크도 구성을 해두려고 노력합니다. 프로젝트에는 먼저, 모든 테스트 케이스에 대해 믹스인처럼 작동하는 클래스를 하나 만듭니다. 이 믹스인을 상속받는 각 유닛 테스트(와 클래스)에는, 테스트용 데이터를 생성할 인스턴스 메서드도 만듭니다. 이러한 가짜 데이터를 만드는 데는 django_faker 프로젝트가 안성맞춤입니다. 데이터는 setUp() 메서드에서 생성된 후, tearDown() 메서드에서 삭제됩니다. 여기에 좀더 관심이 있다면 제 블로그에서 Django에서의 유닛 테스트라는 글을 읽어 보세요.

django_faker 말고 model_mommy나 factory_boy 등도 좋습니다.

3. Django Tastypie를 사용해서 Restful 인터페이스를 만드세요.

Ember.js, Backbone.js, Angular.js 등 클라이언트 MVC 프레임워크의 수가 급증하는 시기이므로, 여러분의 웹 애플리케이션에서도 RESTful을 지원하면 좋습니다. Django에서 REST API를 구현한 두 개의 훌륭한 프레임워크가 있는데요, django-rest-framework와 django-tastypie입니다. django-rest-framework가 더 많이 사용되고 있는 것 같지만, 저는 아직 django-tastypie를 사용합니다. 이유는 django-tastypie가 좀더 간명해 보이며, 제가 경험도 많이 해봤기 때문입니다. 하지만 여러분이 공개 API를 만들고 있다면 두말 할 필요 없이 django-rest-framework를 사용하세요. 문서화 기능도 제공됩니다. 혹시나 django-tastypie를 시작해야 한다면 제가 쓴 튜토리얼을 참고하세요.

4. 문서화 작업이라고 생각하고, Django 모델 필드의 속성인 help_text를 사용하세요.

Django 모델 필드에는 help_text 속성이 존재합니다. 이 속성은 Django의 폼 화면이나 admin 화면에 나타나죠. 설령 폼 화면이나 admin 화면에 사용하지 않는다하더라도 이 속성을 꼭 사용하길 권합니다. 왜냐하면 여러분이 만든 모델의 문서화에도 안성맞춤이거든요. 앞으로 새 개발자를 채용할 예정이라면, help_text 속성이 인수인계에 드는 수많은 시간을 단축시켜 줄 겁니다.

5. 사용자에게 드러나는 URL에는 쿼리 문자열을 사용하지 말고 Django의 URL 모듈을 적용하세요.

웹 개발자들에겐 너무 당연한 사실이겠지만, 어쨌든 저는 url에 더이상 쿼리 문자열을 사용하지 않습니다. 대신 url 파라미터로 전달하죠. Django의 url 디스패처를 사용하여 이렇게 할 수 있습니다.

예를 들어 다음의 URL은

https://www.example.com/user?id=20

다음과 같이 바꿀 수 있습니다.

https://www.example.com/user/20/

이렇게 하면 컨트롤러에서 타입 검사 같은 코드를 덜 작성해도 됩니다. id 자리에 정수가 없다면 Django의 URL 모듈이 404 HTTP 오류를 던질 테니까요. 간혹 이 규칙을 따르지 못할 사정이 있을 수도 있겠지만, 저는 할 수 있는 한 이 규칙을 따릅니다.

6. Django ORM으로 DB의 제약 조건을 지정하세요.

네, 네, 이제와서 또 언급하기엔 바보 같은 말이죠. 여러분이 DB의 제약 조건을 정확히 지정해 둔다면, 수많은 문제들을 해결할 수 있습니다.

• null 값을 가질 수 없는 필드에는 null=True를 설정하지 마세요.
• 고유한 값을 저장하는 필드들은 unique_together로 지정해주세요.
• unique 파라미터도 적절히 사용해 주세요.
• max_length도 알맞게 지정하세요.
  데이터베이스의 스키마를 설계하는 데 공을 들이고, Django ORM을 최대한 사용하세요. 그러면 잘못된 데이터가 저장되는 일은 없을 겁니다.

7. 모든 프로젝트에 django_model_utlis와 djagno_extensions를 사용하세요.

django-extensions는 settings 출력, shell_plus, 덤프용 스크립트, 암호화 등 굉장한 기능들이 담긴 라이브러리입니다. 저는 이 기능들을 날이 갈수록 더 많이 사용하고 있습니다.

django-model-utils는 Django ORM에서 지원하지 않거나 구현 방식이 조금 다른 유용한 기능들을 제공합니다. TimeStampField, MonitorField, Choices 등이 있습니다.

바퀴를 새로 발명하기 전에 이 프로젝트들을 꼭 살펴보세요.

8. Sentry는 프론트엔드와 백엔드의 오류를 검출하는 데 사용하세요.

Sentry는 Django로 만들어진 모니터링용 오픈소스 소프트웨어입니다. getsentry.com에서 비용을 지불하고 사용하는 가입형과 직접 운영하는 설치형으로 나뉩니다. Sentry는 프론트엔트와 백엔드의 오류를 진단하는 데 없어서는 안 될 도구입니다. Sentry로 다음과 같은 유용한 정보들을 추적할 수 있습니다.

• 이 오류가 몇 번이나 발생했었나
• 브라우저 정보
• 시간/지역에 따른 발생 빈도
• 500 오류 등의 스택 트레이스(stack traces)
• 404/403 오류
• 프론트엔드 자바스크립트의 undefines 오류

가입형은 한 달에 $24부터 시작하며, 이 돈을 낼 만한 가치가 충분합니다.

9. 최적화와 디버깅에는 django-debug-toolbar를 사용하세요.

django-debug-toolbar는 놀라운 디버깅 도구입니다. 성능에 문제가 있는 SQL 쿼리와 요청, 템플릿, 캐시 등을 모두 추적할 수 있습니다. 저는 미리부터 최적화를 시도하는 편이 아니지만, 뭔가 느려졌다 싶을 땐 django-debug-toolbar가 문제점을 찾도록 도와줄 겁니다. 이 프로젝트에 대해 더 알고 싶다면 Unit Testing Best Practices in Django를 읽어 보세요.

10. Django의 커스텀 User 모델을 첫 번째 커밋부터 도입하세요.

Django의 기본 User 모델을 사용하기보다는 Django 1.6에서 도입된 커스텀 User 모델을 사용하길 적극 권합니다. User 모델에 필드를 추가할 때도 기존의 방법(기본 User 모델과 OneToOne으로 엮인 새 모델을 만드는 방법)보다 직관적입니다. Django를 이미 사용하고 있다면 기본 User 모델의 email과 username 필드가 30 글자로 제한되어서 답답했을 겁니다. 커스텀 User 모델을 도입하면 이런 문제들이 모두 해결됩니다. 기본 User 모델을 커스텀 User 모델로 마이그레이션할 수도 있겠지만 재미는 없을 겁니다. 제 말을 명심하세요.

11. Django admin에 대체품을 도입해보세요.

Django의 admin은 훌륭하지만, 겉모습은 철 지난 디자인입니다. 외주 일을 맡아서 진행했다면 admin 화면을 좀더 전문가 답게 바꿔줄 도구들이 있습니다. 저는 django-grapelli와 django-suit를 애용합니다. 더 많은 목록은 다음 링크를 참고하세요.

저는 Django와 머신 러닝에 대해 블로깅합니다. 이 주제에 관심이 있다면 제 트위터 계정 @josephmisiti를 follow해주세요.

Django나 머신 러닝 관련 업무를 도와드립니다. 컨설팅도 가능합니다. Math & Pencil 홈페이지를 참고하세요.