민첩한 개발을 위한 Django 마이그레이션 전략

진행 배경

기존에 스프링 + mybatis 조합으로 웹 개발을 배운 상태로 새롭게 진행하는 프로젝트에서는 장고를 사용해야 했습니다. 장고의 orm과 마이그레이션 기능은 넘어야 할 산으로 다가왔습니다. 아직 JPA를 접하지 못한 상황에서 django ORM을 먼저 접했기 때문에 빠른 개발을 위해 복잡한 마이그레이션을 포기하고 설계 시 몇 가지 선택을 했습니다.

기존에 개발을 진행했던 단계는 요구사항 분석 -> 데이터베이스 설계 -> 코드개발 -> 테스트 -> 배포 순으로 진행 하였는데 django를 처음보고 느낀 것은 코드개발 -> 데이터 베이스 설계로 기존 개발 스텝이 꼬이는 느낌을 받았습니다.

아직 기존 개발단계를 버리지 못한 단계에서 갑자기 순서를 바꿔 진행 할 수 없었기 때문에
기존처럼 DB설계 후 개발 하는 순서로 진행하였습니다.

마이그레이션(Migration)이란?

장고는 migrate 명령을 통해 app 안의 모델들을 자동으로 데이터베이스 스키마를 생성 혹은 관리 해줍니다.

단독으로 개발을 할 경우에 마이그레이션을 이용하여 개발을 진행하면 보다 빠르고 편하게 개발을 진행할 수 있지만 여러명이 하나의 데이터베이스를 바라보고 개발을 진행 할 경우 종종 마이그레이션이 꼬이거나 다른 사람이 수정한 마이그레이션 때문에 프로젝트가 실행이 되지 않는 경우가 발생하기도 합니다.

기존 스프링으로 웹 개발을 진행하고 장고에 익숙치 않은 상태에서 빠른 개발과 꼬임 방지를 위해 몇 가지 전략적 선택을 하였고 이 경험을 공유하고자 합니다.

마이그레이션을 포기하고 선택한 것

초기 migration (최초 1회)

python manage.py migrate

장고에선 필수적으로 생성 되어야하는 테이블이 존재합니다. 최초 한번은 migration을 진행하여 장고에서 내부적으로 사용하는 테이블을 생성시킬 필요성이 있습니다.

inspectedb 활용

python manage.py inspectie > models.py

장고에는 inspectdb라는 기능이 있습니다. 기존 단계대로 모든 DB설계를 마친 후 데이터 베이스를 생성하고 inspectdb 명령으로 연결된 데이터베이스의 모든 테이블 정보를 기준으로 생성된 모델 class들이 자동으로 생성됩니다.
생성된 모델을 VO처럼 사용하여 개발을 진행합니다.

*마이그레이션을 하지 않아도 해당 모델로 db에 접근하는 것이 가능합니다.

git 커밋

마이그레이션을 진행하고 나면 app폴더 하위에 migrations폴더가 생성됩니다.
해당 폴더를 git으로 관리하지 않도록 하여 다른 사람이 영향을 받지 않도록 합니다.

장고 마이그레이션을 보고 느낀 점

기존 설계방식은 데이터베이스가 1순위로 설계되는 느낌이었는데 Django ORM에서는 데이터베이스보다 WAS의 기능에 중심을 맞춰서 설계가 되는 느낌이였습니다. 막상 개발을 진행하며 여러 라이브러리들을 보니 Model 자체도 순수 VO처럼 사용되는 것이 아니라 각자 객체로써 역할을 수행하는 것 같았습니다. 처음 설계 시 조금 더 경험이 있었다면 보다 django의 패러다임에 맞춘 개발을 진행 할 수 있지 않았을까 생각됩니다.