DB 설계완료 & 초기 개발환경 세팅

jihan kong·2023년 11월 7일

가계부 웹 어플리케이션 팀 프로젝트

목록 보기

3/3

새로운 Back-end 팀원 합류

팀 프로젝트를 시작한지 한 달하고 2주가 넘어가고 있는 이 시점...
Backend 팀원이 절실해졌다...😭 개발 분량도 분량이지만 혼자서 개발을 하게된다면 일단 피드백을 받을 수 없기 때문에 내가 현재 올바른 방향으로 개발하고 있는지에 대한 확신이 안서게 된다. 또한, 팀플을 하면서 백엔드 개발에 대해 다양한 시각을 접하고 더 나은 개발 방법에 대해 알고 싶은 생각도 분명히 있었다.

아예 초면의 개발자분을 모시는 것도 좋지만 어느 정도의 커뮤니케이션을 통해 서로에 관해 정보를 알면서 팀과도 잘 어우러질 수 있는 개발자와 팀웍을 이루고 싶었다. 그러던 중, 전에 개발자 모임을 통해 처음으로 알게된 현재 백엔드 인턴을 하고 있고 나와 같은 스프링을 사용하고 있는 동생에게 넌지시 팀프로젝트에 관하여 흘려줬던게 생각났다. 다시 한번 연락을 취했고, 감사하게도 동생이 함께 하겠다는 의사를 밝혔다!

(Ok...아주 Nice해요)

동료를 얻었으니 이제 국밥처럼 든든하다.
이 후,기획 단계에서 확정된 flow와 IA, ERD 등등에 대해 설명하고 온보딩하는 시간들을 가졌다. 확정된 사안에 대해서는 다음과 같다.

서비스 이름

사실 팀원들과 서비스 이름에 대해서 가장 많이 고민했다. 어떤 서비스를 제공하는지 그 의미를 쉽게 알 수 있으면서도 함축적인 네이밍이었으면 좋겠다라는 생각을 했다. 말이 쉽지.. 정말 떠오르지 않았다. 한 기업의 브랜드라는 것은 좋은 이름에서부터 온다는 것을 회의를 하며 많이 깨달았다.
(치열한 사투의 흔적...)

결국 최종 이름은 FINNI가 되었는데, 그 뜻은 Mini와 Finance의 합성어이다. 어린이들을 위한 용돈 기입 앱이니 만큼 용돈과 같이 포켓머니. 즉, 작고 귀여운 느낌을 주고 싶었고, 경제 관련 앱이라는 것을 알려주고 싶었다. 정말 잘 지은것 같다!

최종 확정된 Wireframe

기능과 관련된 기획안들은 거의 확정이 되었는데, 이를 어떤 화면으로 구성할지에 대해서는 이야기가 계속 진행되었다. 그리고 마침내 Wireframe이 최종적으로 확정되었다.
(방대한 양의 Wireframe...이를 통해 flow를 이해하는데 너무나도 큰 도움이 되고 있다. 기획적으로 그리고 디자인적으로도 뛰어난 친구와 팀플을 할 수 있다는 것은 큰 축복이 아닐까..🤭)

ERD

사실 ER 다이어그램이 가장 감이 오지 않았던 부분이다.
DB를 어떻게 설계할지에 대해 팀원과 의논하면서 계속 고민하고 또 고민했다. 어떤 Entity를 추가해야할지, 어떤 속성을 추가시켜야할지에 대한 고민과 Cardinality 적인 고민들... 학부때 어려웠던 건 지금도 어렵다ㅠㅠ 결국 여러 과정을 거쳐 다음의 ERD로 결론을 지었다.

(가장 많은 도움을 받은 블로그 (https://velog.io/@sontulip/how-to-db-design) 감사합니다!)

V2.

V3.

잘 안보이지만 V2 -> V3로 넘어오면서 많은 것들이 바뀌었다. 잘못 생각하고 있던 것들이 많아서였던것 같다. 우리의 앱에서는 가계부에서 저금 또는 용돈에 관한 정보를 직접 항목을 추가하는 방식과 전에 입력한 정보에 따라 자동으로 기입을 시켜주는 기능이 있는데, 이를 구분할 필요성이 있었다.

또한, 저금 기능의 경우도 총 현재 저금한 양에 따라 캐릭터가 움직이는 시각화 Feature가 있었기 때문에 저금 항목들의 총액을 속성으로 가져야할 필요가 있었다. 이를 반영했다. 가계부 는 단순히 조회하는 측면을 가진 Entity라서 Entity로 따로 뺄 필요성은 없는것 같지만 일단은 추가해두었다.

팀프로젝트의 기획 단계는 이제 거의 마무리되었으니 이제는 슬슬 개발을 위한 환경과 이것저것을 세팅하는 시간이다.

Git branch 전략

우리는 현재 개인이 아닌 팀프로젝트를 하고 있다. 이말인 즉슨, 프론트와 백의 협업을 어떻게 할지를 생각해야 한다는 것이다. 버전 관리를 Git으로 하게 된다면 다음 두 가지의 branch 전략이 있다.

Git Flow

Github Flow

각 flow마다 장단점이 있지만 간략하게 설명하면 Git Flow의 경우에는 명시적으로 버전관리가 필요한 프로젝트의 적합하다. 스마트폰 앱이나 오픈소스 라이브러리 등의 프로젝트에 적합하다. branch도 목적에 따라 Main, Develop, Supporting, Release, Hotfix 등등이 생성될 수 있다.

그러나, 우리의 앱은 소규모의 팀이 개발하고, 버전에 경우도 여러개가 쓰이는 것이 아니라 가장 최신의 버전 하나만을 사용자가 사용하게 될 것이다. 이 경우, Github flow가 보다 적합하다. 브랜치 또한, 항상 stable한 Main 브랜치 하나와 새로운 기능을 개발할 때만 생성되는 브랜치로만 구성하는 방식이라 훨씬 단순하다. 브랜치 생성시 기능을 설명해주는 네이밍만 잘하고 PR을 꾸준히 해준다면 문제가 없을거라고 생각했다. 팀원들도 모두 동의~! 우리는 Github flow를 도입하기로 했다.

서버 확정

(저 로고는 볼때마다 저 썩은미소가 "훗~ 돈 없는 니가?" 라고 하는 것 같다...)

서버는 나와 팀원이 제일 많이 사용해서 익숙하기도 하고, 커뮤니티가 많은 Amazon AWS를 사용하기로 했다. 배포를 해봤던 경험도 aws에서였기 때문에 선택하지 않을 이유가 없다. 다만 문제는 비용인데, 지금 프리티어를 사용하고 있긴 하지만 만약, 1년이상 운영을 하게된다면 비용이 들지 않는 Oracle Cloud로 갈아탈지도...?