서비스 - 아름다운 할부
- Github: https://github.com/5th-Ne-o-rdinary-HACKATHON-team-I (리팩토링 이후 공개 예정)
리뷰에 들어가기 앞서..
해커톤이 마무리된지 2주가 넘어가고 있습니다. 이번 해커톤을 통해 많은 점을 느낄 수 있었습니다. 제 부족한 점을 발견할 수 있었고, 배워가는 점도 정말 많았습니다. 이때 느낀 점을 짧게 개인 메모장에 작성해두었는데, 이번 포스팅에서 글로 풀어가며 다시 한 번 정리하고자 합니다.
너디너리 해커톤은 CMC 부원들은 필수 참여, UMC 부원들은 신청을 받아 참여하였습니다. 그 외에도 여러 신청 방법을 통해 참여하는 분들도 많았습니다. 저희 팀은 CMC 개발자, UMC 개발자 (본인), 개인 참여한 개발자 3명이서 서버 파트를 담당했는데 두 분 모두 정말 잘하시는 분이라 많이 배울 수 있었습니다.
최근에 해커톤이 끝난 후에 프로젝트를 종료하지 않고, 개발자 전원이 참여하여 프로젝트 리팩토링을 하고 있습니다. 아무래도 하루만에 개발을 완료해야 하는 촉박한 상황이다 보니, 컨벤션을 지키지 못하거나, 구현하지 못한 기능들이 포함되어 있습니다. 팀원분들 모두 이번 프로젝트에 애정이 많아 프로젝트 리팩토링을 해서 아름답게 프로젝트를 마무리하자는 이야기가 나와 리팩토링을 진행하게 되었습니다.
위 사진은 저희 서비스의 마스코트였던 아이들입니다. 오른쪽 아이의 이름이 잘 기억나지 않는데, 왼쪽에 옷이 찢어지게 가난해보이는 친구 는 파산이었습니다. (귀엽습니다)
5th Ne(o)dinary Hackathon 소개
사실 이번 포스팅에선 개인적인 피드백에 대한 내용을 많이 담으려고 해서 해커톤 자체에 대한 소개는 많이 하지 않으려 합니다. 일반적인 해커톤과 똑같이 하루 밤을 새며 서비스를 만들어 발표하는 대회입니다.
5기의 너디너리 해커톤의 주제는 "뉴진스"였습니다.. 뉴진스의 노래 중 아무 노래를 선정해서 그 노래 제목을 서비스의 이름으로 선정해야 했습니다. 예를 들어 "쿠키"라는 제목을 보고, 다과 커뮤니티를 제공하는 "쿠키"라는 이름의 서비스를 만들 수 있겠죠. 저희는 좀 참신한 주제의 서비스를 고민하다 고정 지출 관리 서비스인 "아름다운 구속"을 제작하였습니다. 이후에 리팩토링을 하면서 구속을 할부로 변경했습니다.
개발 과정 회고
CARD 도메인 ENUM 처리
주제가 정해지고 erd 설계를 하는 과정에서 card라는 도메인을 table을 생성해서 db로 관리할 것인지, enum으로 처리할 것인지에 대한 이야기가 나왔습니다. 처음에는 이것도 도메인이니 table로 빼자고 이야기가 나왔지만, 해커톤 특성을 고려하여 간단하게 enum으로 처리해주는 것이 개발할 때 편할 것이라고 결론지어 enum으로 카드 도메인을 처리해주었습니다.
하지만 저는 이후에 개발하게 된다면 아무리 해커톤이라 하더라도 DB단에서 처리해줄 것 같습니다. 이유는 아래와 같습니다:
1. 도메인에 속하기 때문입니다.
CARD는 도메인으로, 비즈니스 로직에서 매우 다양하게 사용됩니다. 만약 CARD에 대한 정보가 고정되어 있고, 미래에도 카드에 대한 string 정도의 고정된 값만 전달해준다면 enum으로 처리해줘도 괜찮을 겁니다. 하지만 새로운 카드사가 생겨서 카드를 추가해야 할 가능성도 있죠.
이런 상황외에도, 관리자 기능을 고려해볼 수 있습니다. 갑자기 특정 카드의 입력을 막아야 한다고 했을 때 db로 관리하고 있다면, 그리고 status column이 있다면 이를 변경해주는 것만으로 간단하게 관리를 할 수 있습니다. (물론 로직과 관련된 코드는 작성되어 있어야 하겠죠) 하지만 enum으로 처리하고 있다면 어떻게 해야 할까요? 어떤 방식으로 처리하건 간에 결국 코드를 수정해야 합니다. 즉 배포를 다시 해야 하는 것이죠.
ERD를 작성할 때, 도대체 어디까지 table로 빼줘야 하는지 많이 고민하게 됩니다. 이때 고민하는 대상의 상태가 고정 불변할 것인지 깊이 고민해보는 게 좋을 것 같습니다. 개인적으로 "관리자 페이지에서 얘를 관리해야 한다면 어떻게 처리해야 하지?" 라는 질문을 스스로 던졌을 때 고정 불변할 것 같던 대상들이 모두 언제든 상태가 변할 수 있는 대상으로 바뀐 경험을 여러번 느꼈습니다.
2. 오히려 DB로 관리하는게 더 편합니다.
CARD를 테이블로 빼버리면, repository, service 레이어를 생성해야 하기 때문에 enum으로 관리하자고 이야기가 나왔었습니다. 그런데 개발 도중에 처음에 고려하지 못한 요구사항들이 새롭게 생겨나기 시작합니다. 그 중에는 "각 카드 별 한달 고정 지출 비용 정보 추출"도 이었습니다.
만약 card를 db로 관리했다면 SPRING JPA를 통해 간단하게 가져올 수 있었을 겁니다. 그런데 저희는 enum으로 처리했기 때문에, 사용자의 모든 지출 정보를 가져오고, 각 카드 별로 정보를 걸러주는 로직을 작성해줘야 했습니다.. 시간이 지난다면 이런 로직들이 추가될 것이 분명하죠.
그래서 리팩토링 과정에서 해당 CARD를 DB에서 관리할 수 있도록 리팩토링 중에 있습니다! 아래는 저희 ERD 수정 버전입니다.
Validation의 부재
작성 중...