[23-2]개발 환경 설정, 개발 설계, 구현
이번 포스팅에서는 이번 프로젝트의 개발 계획과 간단한 진척사항을 기술하는 시간을 가져보기로 한다.
프로젝트 아이디어 구상과 개발 계획을 수립하는데에 많은 시간을 할애했다.
멘토님께 조언 들은 바에 따라 세부 기능보다는 주요기능의 동작을 목표로 작업하게 되었고, 나는 계획 관리, 개발환경 구축, DB와 백엔드 구현, AI모델 경량화 부분에 힘을 쏟게 되었다.
어플리케이션 1차 설계
개발 환경 상세
사실 개발환경 구축에 많은 시간을 할애했다. 초기 구상 프로젝트에서 이전에 사용해보지 않았던 프레임워크와, 환경, 파이썬 버전을 사용했기 때문에 검증 과정에서 시간이 오래 걸렸고 많은 수정이 있었다.
전체적으로 현재 상태의 애플리케이션 개발 환경은 다음과 같이 구성되어있다.
Framework
개발 프레임 워크의 경우 Django를 사용하여 개발한다.
Django는 파이썬의 웹 프레임워크로, 이전의 프로젝트에서 사용해왔던 springboot와는 달리 MTV 디자인 패턴을 가지고 있다.
언어
Django를 사용할 계획이므로 당연히 언어는 python을 사용하여 개발한다.
Database 환경
기존 계획은 MongoDB를 사용할 예정이었으나 Django와의 버전충돌과 Django의 장점인 MTV를 활용하기 어렵다고 판단해 MySQL을 사용하기로 했다.
따라서 우리는 AWS의 RDS instance를 통해 MySQL을 사용한다.
작동을 위한 초기 개발을 완료하고 Redis를 활용하여 질을 높이는 방향으로 계획을 세웠다.
배포 환경
배포환경으로는 AWS EC2 인스턴스를 활용하여 배포할 예정이다.
개발의 경우 로컬에서 진행하고, 동계계절학기에 EC2를 이용해 배포할 계획이다.
외부 플러그인
크게는 JS의 j쿼리와, CSS, Openai, stablity_sdk를 활용한다. 여기에 머신러닝을 위한 라이브러리들이 추가될 수 있겠다.
개발 환경 구축 과정
개발환경을 구축하는데에 있어서 문제는 2가지 정도가 있었다.
첫번째는 mongodb와 django의 문제였고, 두번째는 가상환경을 통한 버전관리와 충돌 해결에 있었다.
개발환경을 구축하는것이 처음이었기 때문에, 어께 너머로 보며 배운 정도에서는 사실 예상치 못한 부분에서 잦은 오류사항들이 발생했던 것 같다.
MongoDB와 Django
사실 이 둘을 보았을때 별개로는 전혀 문제가 없어 보인다. 실제로도 별개로 생각한다면 문제가 없다.
Mongodb의 경우 NoSQL이기 때문에 SQL의 간단하고 명세화 하기 쉽고, 관계파악이 용이하다는 장점을 이용하기 힘들지만(알아본 바에 따르면 NoSQL을 SQL처럼 활용하는 방안이 있긴 하지만, Join이 불편하다.) 효율적인 데이터 관리가 가능하다는 점에서 매력적이다.
Django의 경우 트렌젝션 관리와 쉬운 문서화가 가능하다는 장점이 있고, 무엇보다 다양한 템플렛 엔진과 사용자 인증 기능, ORM을 제공한다는데에 있다.
문제는 둘을 함께 사용할 경우에 있다.
Django는 SQL데이터베이스를 염두해 두고 설계되었다. 따라서 MongoDB와 같은 NoSQL데이터베이스를 함께 사용하게 될 때에는 장고 어플리케이션들의 구조 일관성을 유지하기가 어렵다는 것이다. 또한 Django에서는 그런 이유로 MongoDB에 대한 지원 툴이 상대적으로(매우매우) 적다는것이다.
https://he-kate1130.tistory.com/42
이전에 작성했던 포스팅을 통해 Django와 MongoDB의 연겨롸정을 살펴보면 그 근거를 더 쉽게 알 수 있다.
Django와 MongoDB를 함께 쓰기 위해서는 대략 3가지 정도의 방식을 쓸 수 있으며, 이는 MongoDB의 문서를 보면 안내되어있다. 하지만 개발을 위해 많이 사용되는 djongo는 이슈(깃허브)가 너무 많다는 점에 있어서 안정성이 떨어진다.
MongoDB문서에서 나왔듯이 Pymongo를 활용할 수 있으나, 이렇게 되면 django의 MTV디자인 패턴 중 M(model)과 V(view)를 합쳐버려야 한다는 것이다.(view에서 모든걸 해결해야 한다. 비대해지는 view...) 결국 django를 사용하는 이점이 사라진다 판단했다.
어떻게든 View에서 해결을 한다고 해도 django의 ORM이 SQL에 적합하도록 되어있다는 것과, 인증등의 유용한 기능을 직접 구현해야 한다는 점에서 우리는 관계형 데이터베이스인 MySQL로 데이터베이스를 변경하게 되었다.
가상환경과 버전 충돌
처음 DB를 MongoDB로 생각하고 있었기 때문에 MongoDB권장 파이썬 버전인 3.12.0을 사용하게 되었다. 그러나, 머신러닝 파트에서 여러 충돌 문제로 이전에 사용하고 있던 파이썬 3.10을 사용하는 것으로 의견이 좁혀졌고, 가상환경을 재구성 하게 되었다.
백엔드에서 작업을 하면서 버전 충돌을 겪고, 에러를 보는 것은 흔한 일이다(아마도...)
3.12.0에서 3.10으로 버전을 다운그레이드하는것에 대해서 많은 에러가 발생할 것이라고 생각지 않았지만, 파이썬과, MS빌드 툴과 .whl파일들 등 많은 시도를 통해 다운그레이드와 환경 설정을 마칠 수 있었다.
트러블 슈팅에 정말 시간이 많이 들었고, 이전에 발생한 적 있는 에러들이 재발생하는 상황이 몇번 벌어지다 보니 트러블슈팅에 대한 기록을 남기는것이 매우 중요하다는 사실을 알았다. (그리고 문제를 자주 일으키는 친구가 누군지 알아냈다)
또한 venv를 통해 로컬에서 가상환경을 만들어 작업할 수 있지만 conda를 앞으로는 더 애용할 것 같다.
RDS, MySQL Workbench
MySQL을 사용하기 위해 RDS 인스턴스를 생성하고 django와 연결한다.
이후 MySQL workbench를 통해 손쉽게 데이터베이스를 관리할 수 있다.
RDS를 생성하는 것은 다음 포스팅을 참조하자.
EC2 인스턴스 생성
우리 팀은 개발은 깃허브를 활용해 로컬에서 진행하도록 하고, 개발 후 정돈하여 EC2를 이용해 서버를 배포해보기로 했다.
따라서 현재 우리 팀의 코드는 로컬에서 돌리지만, 나는 혹시모를 개발 템포를 대비해 미리 EC2 인스턴스를 생성했다.
생성 과정은 다음을 참조하자.
https://he-kate1130.tistory.com/43
모델 설계
이번학기 우리 팀의 핵심 기능 작동을 위해서 핵심 기능인 일기구현과 유저에 대해서 간단한 임시 모델을 설계하게 되었다.
구현의 편의를 위해서 MTV와 웹 페이지 구성에 대해서 간단하게 일기와 유저 두가지로 나누어 브리핑해본다.
먼저 유저의 경우 이미 장고에 인증기능이 지원되고 있기 때문에 이를 활용한다.
데이터베이스는 다음을 이용한다.
Model은 따라서 AbstractUser를 사용하여 따로 정의 없이 사용한다
View의 경우 테스트를 할 수 있도록 회원가입, 회원관리, 로그인, 로그아웃만 선행 구현한다.
Urls의 경우 또한 View에 맞춰 다음처럼 구성한다.
일기의 경우 일기의 CRUD기능과, 일기 내용을 prompt 생성AI와, 감정분석용 KoBert에 입력하고, 생성 이미지를 띄우는 것까지를 목표로 두고 작업하였다.
테이블은 다음과 같이 구성한다.
Model은 다음과 같이 구성한다.
View의 경우 다음과 같이 필수 기능을 구현한다
view에 따라서 url은 다음과 같이 구성한다.
디테일보다는 기능의 작동에 중점을 두고 빠르게 구현했다. 이후에는 디테일과, 데이터 처리의 효율을 높이는 방향으로 작업이 진행될 것이다.
상세 코드는 깃허브를 통해 확인할 수 있다 :)
마지막으로 필수 기능 구현을 위한 1차 웹 페이지를 다음과 같이 구성했다.
