기능을 추가하며 모델을 변경해야 할 일이 새겼다. 테이블을 수정하고 migration을 적용하면서 dependency 오류부터 relationExists 오류까지 아주 난항을 겪었다. 사실 토이프로젝트에서는 migration이 꼬이면 그냥 전부 밀어버리고 다시 적용하면 그만이었다. 하지만 실제로 배포되고 데이터가 담겨 있는 DB의 테이블을 수정하는 경우에는 이런 1차원적인 방식으로 접근할 수는 없었다. 다소 긴 삽질의 과정을 경험하며, 내가 migration에 대하여 정확히 이해를 하지 못하고 있음을 깨달았다. Migration이란? 일종의 database version control log라고 이해하면 될 것 같다. 명령어를 수행하면 각 app의 모델에 대한 변경사항을 기록한 python script가 자동으로 생성되고 명령어를 수행하면 db에 변경사항을 반영할 수 있다. 이 migration script는 형식으로 네이밍되며, 모델 간의 관계(생성 순서, 참조 방향 등)를…

장고는 하나의 프로젝트 내에 여러 개의 app이 존재하는 구조이다. 명령으로 app을 생성한 뒤, 에 생성한 app을 등록하여 손쉽게 관리할 수 있다. 아래의 이미지는 명령어를 통해 app을 생성했을 떄의 기본 구조이다. 루트 디렉토리에 장고 서버를 구동하기 위해 필요한 파일이 존재하고, 생성된 app 디렉토리 내부에 , , , 과 같은 파일이 생성된다. 새로운 사이드 프로젝트를 사용하면서도 이러한 디렉토리 구조를 그대로 사용하고 있었는데, 프로젝트가 정리되어 있지 않은 느낌이 있다는 피드백을 들었다. 하지만 과 를 개발용/운영용 환경으로 분리하는 것 외에 프로젝트 구조를 유연하게 설정할 수 있는 방법이 어떤 것이 있을지 감히 잡히지가 않았다. “장고는 프로젝트를 app 단위로 나누어 관리하니까, app을 더 쪼개야 하는건가? 아니면 합쳐서 단순화해야 하는걸까?”와 같은 고민을 하다가.. app을 생성하고 디렉토리가 많아지면서 프로젝트 구조가 난잡하다라는 생각이 종종 들었으니,…