머니로그 | 좋은 소비를 유도하는 가계부

 

드디어 작성하는 파이널 프로젝트 후기!

주제를 선정한 과정부터 차례대로 후기를 작성하려고 한다.
진행을 할수록 변화된 과정을 공유하고 싶었다!

Final Project

머니로그 (MoneyLog)

기간 : 5월 20일 ~ 6월 20일(수료)

💰 1. 주제 정하기

주제선정과 요구분석까지 일주일정도 걸렸다 😓
브레인스토밍 과정을 통해 자유롭게 주제를 생각했는데 다양한 아이디어들이 쏟아졌다. 대략 20개 정도ㅋㅋㅋㅋㅋ

여기서 우리는 두 가지 포인트를 잡아서 주제를 선정하였다.
1. 웹 어플리케이션에 적합한 아이디어
2. 관리자가 아닌 이용자가 컨텐츠를 생산하는 것

1-1 첫 번째 주제

맨 처음 선택된 주제는 여행일기 관련한 것이었다.

모두 안전하게 가고 싶었던 걸까 그냥 무난한 주제로 골랐던 것. 그러다가 점점 욕심이 나서 다시 한번 주제에 대해 생각해보자고 처음으로 돌아갔다. 물론 무난한 주제가 잘못된 건 아니다. 하지만 우린 욕심이 나서 그만 🤧

 

1-2 두 번째 주제

그다음 주제는 소규모 당근마켓(?)
당근마켓이 동네 단위라면 우리가 생각했던 것은 한 건물 단위였다. 그러다가 주택 이용자는? 가구수가 별로 없는 건물은? 등 점점 의문점이 생기면서 펑! 🤯 컨셉 자체가 명확하지 않았다.

 

1-3 세 번째 주제

동네 사람들끼리 택비, 배달비를 쉐어하는 서비스로 변경이 됐다.
그런데 우리가 우려했던 것이 자칫 잘못하면 데이팅 어플이 될 것 같았다.

예를 들면 배달비를 쉐어한다는 것 → 음식이든 뭐든 받으러 가야 한다는 것 → 만나야 한다는 것

= 🙄만남 어플?!! (게임과 데이팅은 금지 주제였다)

물론 정책적으로 혹은 UI의 힘으로 데이팅 어플 느낌을 피할 수 있었겠지만, 우리의 머리에 '데이팅'이란 단어가 들어온 순간부터 성별에 집착하기 시작했다. 결국 같은 성별끼리만 배달비 쉐어하자는 말도 안 되는 정책까지 생각했다 ㅋㅋㅋㅋㅋ

 

 

후 .... 안 되겠다 싶어서 새로운 주제를 찾아보았다..
🥺 우리 이러다가 주제도 못 정하고 수료하는 거 아니야?? ...

 

 

1-4 네 번째 주제 ⭐ 비장의 카드

사실 난 예전부터 꼭 만들고 싶었던 것이 있었다. 그냥 추상적으로만 생각했던 것인데, 그게 뭐냐면 ...

https://soft.plusblog.co.kr/192

[경제공부] '시발비용', '멍청비용', '쓸쓸비용'이란?

 

신조어인 'X발비용', '멍청비용', '쓸쓸비용'에 대한 기사를 보고 떠올랐던 것이다.

홧김에 쓴 비용 혹은 실수로 쓴 비용에 대한 가계부를 씀으로써 불필요한 지출을 바로 확인할 수 있고, 이용자끼리 사용한 비용에 대한 사연을 공유하여 서로 위로할 수 있으며  ‘김생X의 가계부’처럼 소비에 대해 조언할 수 있는 사이트를 구상했다.

 

이걸 팀원들에게 설명하니 모두가 괜찮다고 생각을 하여 드디어 소비 공유 사이트로 주제를 최종 선정했다.

 

 

---

💰 2. 요구분석

요구분석! 정한 주제에 대해 구체화하는 단계다. 우리 사이트만의 정책을 만든다던가 어떤 기능이 있는지 구체화하는 것이다. 개인적으로 주제 선정보다 훨씬 더 중요한 단계라고 생각한다.

 

2-1 위기

그런데 아무리 이 서비스가 실질적인 도움을 주는 사이트가 아니라 공유와 위로를 목적으로 했다고 해도 FLEX 같이 요즘의 소비지향적인 문화 트렌드 덕에 혹시나 과시하는 사이트로 변질될 수 있다고 생각을 했고, 그것 말고도 여러 가지 모순적인 점을 발견하게 되었다. 😵

 

우리 .. 또 주제 바꿔?
아니다.

구체화를 진행하며 주제는 그대로지만 내부적으로 완전히 갈아엎었다.

 

그 결과 자신의 정보와 공통적으로 갖고 있는 집단의 가계부 평균치를 구해서 사용자에게 평균 금액을 알려주는 가계부 사이트로 최종확정이 되었다. 예를 들면 ... 너 또래 다른 애들은 식비로 이 정도 쓰는데 너는 좀 많이 쓰네~  라며 넌지시 잔소리를 해주는 기능을 추가하였다. 

또한 지출 정보 공유하던 기능은 서브 기능으로서 조건을 충족한 사람에게만 머니리뷰라는 게시판에 등록할 수 있는 걸로 살렸다.

아래는 요구분석서 일부 내용이다. (누르면 커져요)

출처 : '머니로그' 요구분석서 일부

 

 

 

---

💰 3. 스토리보드

주제 구체화를 하며 조금씩 병행 작업을 했던 스토리보드! 스토리보드는 무조건 필수다. 처음부터 같이 주제를 정해왔지만 의외로 다르게 이해하는 부분이 굉장히 많았기에 시각적으로 보면서 정리를 해야 당장은 귀찮겠지만 나중에 가서 피 눈물을 면한다. 😭

 

예를 들면 '버튼을 클릭하고 점수를 보여준다.' 라는 부분이

단순 안내 텍스트인지 팝업인지 페이지 이동인지 

정리를 안한다면 큰 혼란을 줄 수 있음!

https://ovenapp.io/

OvenApp.io

 

스토리보드는 OvenApp을 활용하여 제작하였다. 장점은 여러 가지 샘플이 있어서 쉽게 만들 수 있지만, 단점은 한 명만 편집이 가능하다. 그래서 우리는 한 명의 계정으로 한꺼번에 편집을 하기는 했는데 중간에 저장이 안 되는 이슈들도 많았기 때문에 유의하면서 작업하면 될 것 같다.

 

아! 그리고 스토리보드는 샘플 디자인이 아니다.

그러니까 스토리보드가 이쁠 필요가 없으니, 미적으로 너무 힘쓰지 않아도 된다.

 

---

💰 4. 플로우 차트

스토리보드를 기반으로 플로우 차트를 그려보았다. (누르면 커져요)

플로우 차트는 흐름의 이해를 용도로 만들었다.
여기서 볼 것은

1. 게시판 글 작성 조건 내 가계부 공유(게시글) :  가게부 내역 60개 이상만 공유하기 댓글 : 공유한 게시글 수 3개 이상만 이모티콘 : 아무나 작성 가능	2. 신고처리 신고처리는 게시글과 댓글 각각 따로 설계하였다.

 

게시글 한 번 작성하기도 빡센데, 댓글은 더 빡세다.

왜냐면 가계부를 주기적으로 작성한 사람들의 훈수(?), 충고 권한이라고 생각했다.

이모티콘은 누구나 작성이 가능하여 간접적인 피드백을 할 수 있다.

 

---

💰 5. 데이터베이스 모델링

이제 정해진 요구분석서와 스토리보드를 토대로 데이터베이스 모델링을 시작했다. 일단 ERD는 우리 팀원 전부 자신 없어하는 분야였기 때문에 따로 ERD 세미 스터디를 진행했다 ㅋㅋㅋㅋㅋㅋ 스터디라기엔 그냥 같이 인강 듣고 필기하고 그런 거였지만... 아 그게 스터디긴하지

 

스터디까지 거치며 DB설계에 한 일주일 매달린 끝에 이렇게 설계할 수 있었다. (누르면 커져요)

 

DB를 설계하며 우리가 어려웠던 세 가지가 있었다.

 

첫 번째는 회원 탈퇴

회원이 탈퇴하게 되면 회원이 기록했던 모든 데이터가 사라지게 된다.
흠 ... 우리 서비스는 데이터가 생명인데 ..

 

두 번째는 게시글 신고 & 댓글 신고

게시글을 신고하면 그냥 게시글 코드만 있으면 되고, 댓글을 신고하면 해당 댓글 코드만 있으면 되는데 이걸 하나의 신고 테이블로 접수를 받다 보니까.. 게시글 신고를 하면 댓글 코드 부분이 null 이고, 댓글을 신고하면 게시글 코드 부분이 null 이 되는 상황 ...
흠 ... null 값이 생겨버리네

 

세 번째는 가계부 등록 시 카테고리

가계부를 쓸 때 ... 1차 카테고리가 '카페/간식' 그리고 2차 카테고리는 '베이커리'라고 하면

처음에는 가계부 테이블에 1차 카테고리를 참조하고 1차에는 2차를 참조하게 했다.
흠.. 이러니까 값을 받아오려면 1차 카테고리를 받고 2차 카테고리까지 받아와야하는 번거로움


😎 그래서 이렇게 해결했다!

이용자 식별 테이블을 중간에 만들어서 이용자가 탈퇴를 해도 데이터를 살릴 수 있게 하자!	게시글 신고 테이블과 댓글 신고 테이블을 분리해서 null 을 없애자!	처음부터 2차 카테고리를 참조하면 알아서 1차 카테고리를 알 수 있네?!

 

이렇게 ERD가 통과가 되고 본격적으로 구현 단계가 시작되었다.

---

💰 6. 개발 시작 ( DB물리 설계 & 뷰페이지 제작 )

이제는 어느 정도 잡혀서 업무를 분리해야 했다.

팀원	업무
팀원1	기획/스토리보드/ERD/DB물리설계/내 가계부/코드취합
팀원2	기획/스토리보드/ERD/DB물리설계/마이페이지/고객센터/문서작업/회의록
팀원3 (팀장)	기획/스토리보드/ERD/뷰페이지 제작/발표/디자인/업무분담/전체총괄
팀원4	기획/스토리보드/ERD/뷰페이지 제작/회원가입/로그인/문서작업
김테이 (나)	기획/스토리보드/ERD/뷰페이지 제작/머니리뷰/신고하기/디자인/PPT

급한 대로 백엔드와 프론트엔드 희망하는 둘로 나뉘어서, 한 쪽은 물리 설계 마무리와 쿼리문을 작성하고, 한 쪽은 뷰페이지를 제작하기로 하였다.

나는 프론트엔드를 희망했기에 뷰페이지를 제작! 근데 뷰페이지의 개수가 108개!! 이걸 며칠 만에 만들어야 했다.
하지만 난 프론트엔드를 희망만 할 뿐 자신 있는 건 아니었고 ... 그렇다고 어디서 그대로 가져와서 쓰는 건 싫었다.

 

구려도 우리가 만들어서 쓰자!

 

결국 완전 바쁜 와중에 강.의.신.청! 함께 뷰 페이지를 맡은 팀장의 소개로 유데미의 웹 디자인 마스터 코스 결제 완료 🤑

html, css, 부트스트랩, 제이쿼리 복습이 필요했다.

 

이렇게 바쁜 와중에 강의를 듣자고?? 반신반의했지만 결과는 대만족 (물론 화면 디자인은 구렸다 ... ^^;)

모든 뷰페이지를 다 만들 수 있었다 👍

한 편, DB 설계를 맡은 팀원들은
DB 계정 설정부터 테이블 생성, 뷰 생성, 쿼리문까지 DB 연동에 필요한 기본적인 것들을 다 만들어줘서 이후 작업에 굉장히 큰 도움이 되었다.

 

무려 144페이지가 나온 모든 쿼리문들 ...

 

---

💰 7. 기능 구현 (Spring MVC)

대망의 컨트롤러 구성
이제는 각자 맡은 부분들에 컨트롤러를 구성하여 DB로 데이터를 보내거나 가져올 수 있도록 기능 구현을 하였다.

위에 업무 분담 표에 적은 내용처럼 내가 맡은 부분은 '머니리뷰'

머니리뷰는 머니로그의 다양한 것들을 구현해야 했다.

 

머니리뷰

1. 페이징 처리 2. 가계부 분석하여 통계로 표현하기 3. 이용자들의 게시글 리스트 (게시판 형태) 4. 게시글 (입력, 수정) 기능 5. 이모티콘(입력, 수정, 삭제) 기능 6. 댓글(입력, 수정, 삭제) 기능 7. 게시글 신고, 댓글 신고 기능

Spring MVC의 흐름에 대해서도 간략하게 설명하면
사용자 요청 → DispatcherServlet → HandlerMapping에주소 분석 요청
DispathcerServlet → 특정 Controller 객체 호출 및 결과 수신
결과는 ModelAndView 객체로!

이러한 Spring MVC를 활용하여 거의 구현 성공! ... 거의 🤫

사실 .. ajax를 구현하지 못했다...

---

💰 8. 마무리

아쉽지만 수료를 해야 했기 때문에 마무리 작업을 하였다.

팀장이 발표, 팀원 1, 4가 코드 마무리, 팀원 3이 전체 문서 작업

그리고 내가 피피티를 만들며 급하게 마무리를 하였다 🤣

---

 

💰 9. 후기

🥰 좋았던 점

 

힘들었지만 한 달동안 너~무 재밌게 작업을 할 수 있어서 좋았고, 케미가 좋았던 땡그랑 팀원들에게 너무 고마웠다! 확실히 코딩을 하면 할수록 실력이 는다고, 컨트롤러 연결하는 게 어느 순간 익숙해졌을 때왠지 모르게 기분이 좋았다. 이렇게 직접 한 프로젝트를 기획하고 코딩까지 해보니까 다른 것들도 만들고 싶다는 생각이 들었다! 또한 메인 기능이었던 가계부를 담당했던 팀원이 취업을 하게 되어서 해당 기능까지 맡아서 구현하게 되었다. 그리하여 아이디어부터 메인 기능 두 가지 모두 직접 개발하게 되어서 더 뿌듯했던 경험이었다.

 

 

😥 아쉬웠던 점

1. 기간 내에 100% 못 끝낸 것
: 거의 완성을 했지만 조금 남은 부분들이 너무 아쉽다 ... 그래서 앞으로 취업이 되기 전까지 팀원들과 주기적으로 만나며 나머지 기능들을 구현해볼 예정이다. ajax라던가 .. ajax라던가 ... ajax라던가 ...

2. html, css를 급하게 한 점
: 강의를 보면서 제작하긴 했지만 아직도 미흡하다. 아니 존X 구리다. 언젠가 정말 맛깔난 디자인으로 구현을 하고 싶다.

 

이로써 국비 끝!

 

---

로고 디자인 후기

https://taylog.tistory.com/130

[로고] 머니로그 로고 디자인

 

캐릭터 디자인 후기

https://taylog.tistory.com/135

[캐릭터] 머니로그 캐릭터 디자인