1장에서는 파이썬과 장고의 표준 스타일가이드에 대해서 공부하였다. 2장에서는 장고를 사용할 때 최적화된 로컬환경을 구성하는 간단한 가이드를 소개한다.


1. 같은 데이터베이스를 사용하라

개인 및 팀프로젝트를 진행할 때 로컬환경에서는 SQLite3을, 배포환경에서는 PostgreSQL을 각각 사용했었다. 하지만 도서에 따르면 이렇게 나누어 사용하는 것이 잘못된 방법이라 이야기한다. 어떤 데이터베이스를 선택하느냐에 상관없이, 로컬개발환경과 배포환경에서 사용하는 데이터베이스가 다를 경우 대비못한 상황이 발생할 수 있다는 이야기다.


같은 데이터로 개발과 운영을 동시에?

만약 위의 상황처럼 환경마다 다른 데이터베이스를 사용할 경우에는 로컬에서 테스트 및 개발을 위하여 운영환경 데이터베이스의 데이터를 가져올 수 없다. 운영 데이터베이스의 데이터를 SQL(Structured Query Language)로 덤프할 수는 있지만 익스포트와 임포트를 했다고 완전히 같은 복사본의 데이터를 가지고 있다고는 할 수 없다.


데이터베이스 간 제약조건의 차이?

데이터베이스 종류가 다르면 당연히 필드 데이터 타입도 다를 수 있다. 장고를 사용할 경우에는 ORM이 처리를 해준다고 가정하고 작업을 하고, 필자 역시도 그 편차를 장고에서 해결해준다고 생각하고 사용했다. 기본적으로 SQLite3은 동적이고 느슨한 타이핑을 지원하고 있으며 장고의 ORM이 작성한 코드와 SQLite가 좀더 엄격한 타입으로 작용하게 해준다. 문제는 좀더 엄격한 데이터베이스로 이전을 했을 경우 제약조건 에러(constraint error)를 발생시킬 수 있다는 것이다. 로컬 환경에서는 폼과 모델 사이에서 생기는 문제나 복잡한 쿼리가 문제없이 작동할 수 있지만 운영 환경의 데이터베이스로 가면서 로컬에서 본 적이 없는 오류들이 발생하게 된다. 그리고 프로젝트를 운영환경에서 실행하기 전까지는 대부분 이러한 문제를 감지할 수 없다는 점을 생각해보았을 때 로컬과 운영환경에서 동일한 데이터베이스를 사용하는 것이 최적의 해결책이라 생각된다.


최고의 조합은 장고 + PostgreSQL

장고를 사용하는 개발자들은 대부분 PostgreSQL을 선호한다.

PostgreSQL이란?

  • 15년 이상의 꽤 오랜 오픈소스 프로젝트의 역사를 가지고 있는 오픈소스 DBMS. 현재 9.2버전까지 출시됨.
  • 객체-관계형데이터베이스 시스템으로 Oracle과 비슷하지만 오픈소스이기 때문에 북미와 일본에서 많이 사용되고 있는 관계형데이터베이스시스템. 국내에서는 잘 사용하지 않고 있다.
  • 다른 제품과 비교하여 다양한 기능과 무난한 성능을 가지고 있으며 매뉴얼, 문서가 잘 정리되어 있다.
  • 사용자들이 꼽는 PostgreSQL의 장점은 ACID 및 트랜젝션 지원, 다양한 인덱싱 기법 지원, 유연한 Full-text search, 다양한 언어지원, 커뮤니티 및 문서의 뒷받침 등이 있다.
  • 아가사 크리스티의 소설 ‘코끼리는 기억한다’의 소설에서 따와 로고 모양이 코끼리다.(코끼리는 기억력이 좋다)
  • 더 읽어볼만한 링크 : 한눈에 살펴보는 PostgreSQL
  • 설치


fixture를 믿지 말자

장고에서 fixture는 장고가 DB에 임포트하는 방법을 알고 있는 데이터의 모음이다. 삽입할 데이터를 알고 있을 경우 manage.py dumpdata 명령어를 통해 fixture를 생성할 수 있다. 아니면 JSON, XML, YAML 등의 형식으로 직접 데이터 구조를 만드는 것 또한 fixture에 해당한다. 다음은 JSON 구조로 만든 fixture이다.

[
  {
    "model": "myapp.person",
    "pk": 1,
    "fields": {
      "first_name": "John",
      "last_name": "Lennon"
    }
  },
  {
    "model": "myapp.person",
    "pk": 2,
    "fields": {
      "first_name": "Paul",
      "last_name": "McCartney"
    }
  }
]

fixture 데이터를 장고 앱 내 fixtures 디렉토리에 저장해놓고 dumpdata, loaddata 명령어를 사용하여 데이터베이스에 삽입, 추출하는 것이다.

설명을 읽으면서 느꼈겠지만 fixture는 대량의 데이터를 삽입/추출할 때는 적절하지 않다. 대부분 fixture는 개발 초기 단계에서 운영 데이터베이스의 가짜 데이터셋을 개발환경으로 옮겨 사용할 때 사용하곤 한다. fixture는 그 목적 자체가 큰 크기의 데이터셋을 이전하기에는 그다지 신뢰할 만한 도구가 아니다.


2. pipvirtualenv

pip파이썬 패키지 인덱스(Python Package Index)와 그 미러 사이트에서 파이썬 패키지를 가져오는 도구이다. 즉, 파이썬 패키지를 설치하고 관리하며, virtualenv를 지원한다.

virtualenv특정 환경에서 파이썬 패키지 의존성을 유지할 수 있도록 독립 파이썬 환경을 제공하고 관리해주는 도구이다. 만약 virtualenv가 없다면 여러 버전의 프로젝트를 관리할 때 계속해서 장고를 설치해야하는 부담감이 생긴다.

블로그내 virtualenv 사용 및 설치 포스트 보러가기

pip 설치하기

virtualenv 설치하기


3. pip으로 패키지 관리하기

requirements.txt는 설치하려는/설치된 패키지 파일의 목록을 나열한 파일이다. 해당 파일에는 프로젝트에서 사용하고 있는 패키지 파일의 이름과 설치 버전 정보가 담겨있다. 해당 파일과 pip 명령어를 사용하면 requirements.txt 파일 내의 패키지들을 가상환경 내에서만 설치하고 관리할 수 있다.

# pip으로 현재 설치된 상태를 freeze 명령어로 긁어와 requirements.txt에 기록한다.
$ pip freeze > requirements.txt
# 해당 requirements.txt에 적힌 모든 패키지를 설치한다.
$ pip install -r requirements.txt


PYTHONPATH 설정

virtualenv의 PYTHONPATH를 설정해 django-admin.py를 여러 작업에서 사용할 수도 있다. virtualenv로 가상환경을 활성화하고 파이썬을 실행한 후 sys 모듈을 통해 site-packages 폴더 내에 심볼릭 링크를 형성해줄 수 있다.

# 가상환경 활성화
$ pyenv virtualenv 3.5.3 <env_name> 
$ pyenv local <env_name>

# ipython 설치 후 실행
$ pip install ipython
$ ipython

# 인터프리터에서 PYTHONPATH에 현재 디렉터리와 최신버전 pip 등록
In [1]: import sys  # sys 모듈 호출
In [2]: sys.path   # path 모두 출력
Out [2]:
['',
 '/usr/local/var/pyenv/versions/3.5.3/envs/twoscoops/bin',
 '/usr/local/var/pyenv/versions/3.5.3/lib/python35.zip',
 '/usr/local/var/pyenv/versions/3.5.3/lib/python3.5',
 '/usr/local/var/pyenv/versions/3.5.3/lib/python3.5/plat-darwin',
 '/usr/local/var/pyenv/versions/3.5.3/lib/python3.5/lib-dynload',
 '/usr/local/var/pyenv/versions/3.5.3/envs/twoscoops/lib/python3.5/site-packages',
 '/usr/local/var/pyenv/versions/3.5.3/envs/twoscoops/lib/python3.5/site-packages/IPython/extensions',
 '/Users/hwangseonjeong/.ipython']

In [3]: sys.path.append('new/path')

# 프로젝트 최상위 디렉터리에서 다음 명령어를 실행하면 
# 현재 디렉터리에서 패키지를 수정가능한 상태로 설치가능 
$ pip install -e .

또는 virtualenv의 site-packages 폴더 내에 .pth 확장자 파일을 삽입하여 절대경로로 기록하고자 하는 패키지만 작성하면 PYTHONPATH를 직접 설정하지 않아도 적용가능하다.


4. 버전 컨트롤 시스템 활용하기

대표적으로 장고 개발자 사이에서 사용되는 버전 컨트롤 시스템은 깃(Git)머큐리얼(Mercurial)이 있다. 장고 프로젝트를 시작할 때 코드의 변경내용 및 개발사항을 추적하기 위해서는 반드시 버전컨트롤 시스템을 사용해야한다.

버전 컨트롤 시스템은 다른 개발자들과 협업을 할 때도 변경사항을 서로 병합하는데 매우 유용하다. 또, 로컬에서 작업내용을 추적하는 것에 그치지 않고 백업을 위한 호스팅서비스를 사용해야한다. 주로 Github(깃허브)Bitbucket(비트버켓)을 사용한다.

Github은 프라이빗 저장소를 유료로 제공하는 반면 Bitbucket은 무료로 제공하고 있다. 실제 운영환경까지 제작할 프로젝트를 올릴 경우에는 해킹 및 도용방지를 위해 Github 유료 계정을 사용하거나 Bitbucket을 사용하는 것을 추천한다.


협업시 동일한 환경 구성하기

개발자 한 명의 로컬 개발환경과 운영환경을 통일하는 방식에 대해 이야기했다면 이제는 개발자 간의 개발환경을 통일하는 문제에 대해 이야기해본다.

서로 다른 운영체제를 사용할 경우 개발은 맥, 윈도우에서 하고 운영은 리눅스 및 우분투 서버에서 이루어진다면 장고앱은 분명히 다르게 작동할 여지가 있다. 개발자 간 서로 다른 파이썬 버전을 사용하는 경우도 마찬가지다. 또, 개발자 간 프로젝트 세팅이 미묘하게 다를 경우에도 디버깅에 시간을 소비할 수 밖에 없다.

앞서 열거한 경우들은 베이그런트(Vagrant)를 사용하여 쉽게 해결될 수 있는 문제들이다. 베이그런트재생산이 가능한 개발환경을 생성, 설정, 관리하는 데에 쓰는 대중적인 도구이다. 베이그런트는 다른 가상머신과 쉽게 연동된다는 장점이 있다.

예를 들어, 개발 환경이 OS X인데 운영환경은 우분투 환경일 경우 베이그런트와 프로젝트 내 Vagrantfile을 이용해 가상 우분투 환경을 로컬에서 바로 구성하고 프로젝트에 필요한 패키지 설치를 쉽게 끝낼 수 있는 것이다.

추가로 베이그런트를 사용할 지 망설이는 사람들은 다음 장단점을 읽어보고 선택하기 바란다.

장점

  • 프로젝트 개발팀원들에게 모두 같은 개발환경 제공 가능
  • 생성된 로컬 개발환경을 운영환경과 통일 가능

단점

  • 장고와 마찬가지의 문제로, 필요하지 않는 기능들도 함께 제공되어 복잡성이 더해진다. 단순한 프로젝트라면 이러한 가상화 환경을 적용하지 않는 것이 좋다.
  • 구형 개발기기의 경우에는 가상기기를 돌리는 것 자체가 속도저하를 가져올 수 있다.

또, 도커를 사용해 실행 환경만 가상화하여 서비스를 배포할 수도 있다. 그러나 운영체제 자체를 가상화하지는 않기 때문에 맥 -> 도커 -> 윈도우 실행과 같은 작업은 할 수 없다. 도커에 대해서는 추후에 따로 포스트할 예정이다.



Julia Hwang

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