소극적인 재무관리를 하는 20대를 위한 프로젝트, <Wallet Guardians> 최종 회고록

Wallet Guardians에 대하여

우리는 백엔드 개발자 3명, 프론트 개발자 2명으로 이루어진 팀이었다.

 

 개발은 정확히 2025년 1월 1일 부터 하였고, 같은 학교의 동아리 원들끼리 팀을 꾸려 하나의 프로젝트를 만들어보고자 팀을 만들었다.

 

필자는 팀장의 역할을 맡았고, 경험이 많지 않은 우리 모두였기에 모든 것이 서툴렀다. 팀장이라지만 나도 여러므로 경험이 부족하였고 학습 프로젝트지만 부담이 상당했던건 사실이다.

 

디자이너와 PM이 사실상 없었기에, 누군가는 했어야했고 우린 그것에 대한 해결책으로 단편영화감독 경험이 있던 내가 PM을 맡고, 디자이너는 프론트쪽에서 어떻게든 해보자 라는 선택을했다.

 

기획서과 유저시나리오 작성

개인적으로 기획서를 정말 잘썼다고 생각한다.

 

 내가 기획서 쓸때는 무조건 모든 팀원이 얼굴을 보고 회의를 해야한다고 강력하게 밀었고, 팀원들도 감사하게 다들 와주셔서 한 3시간을 무엇을 할 지 고민하고 또 고민했다.

 

그러다 백엔드 개발자님이 옛날에 구성하셨던 아이디어를 말해주셨는데 이걸 업그레이드하면 좋을 것 같다는 생각이었다.

 

 그 프로젝트의 이름은 “거지나기”였다. 말 그대로 가난한 사람의 자조적인 워딩이자, 씁슬한 워딩이 담긴 단어였고, 당연히 금전적인 고통을 얻는 학생들을 위한 프로젝트였다.

 

 내가 발표를 할때 꼭 넣었던 멘트, “한번이라도 가계부를 작성하는 사람을 본적 이 있는가? “ 또는 “돈 관리를 잘하고 있다고 생각하는 사람을 한명이라도 보았는가?”

 

난 개인적으로 없었다.

다들 그저 돈이 부족하다, 혹은 알바를 해야한다 뿐이었다.

 

그런 당연한 금전적 고통을 받을 학생들과 20대 사회초년생들을 위한 가계부 프로젝트를 해보자

 

근데 토스, 카카오뱅크와 같은 대기업이 만든 금융앱을 쓰면 되지않나?

우린 늘 편리하고 자동화된 시스템을 원했고, 저 위 두 훌륭한 대기업은 그걸 사용자에게 제공했다.

 

그러나, 거꾸로 생각하면 그러한 시스템은 아주 좋지만, 잘 활용하는가? 그걸로 인해 학생들의 금전상황이 나아졌는가?

난 아니라고본다.

 

많은 통계지표가 말해준다.

매년 20-30대의 명품이용 건수는 기하급수적으로 늘어나고있으며 최근엔 미국와 중국을 넘었다.

20-30대 명품 이용건수 와 명품 연령 이용 비중 (20대 +6.4%), 한국경제개발원

 

 

명품 지출 총 금액(한국 > 미국 > 중국 ), 모건스탠리 2022

이런 근거로 젊은 사람들은, 능동적으로 자신의 재무관리와 절제를 해야할 것이라 생각이 들어, 능동적으로 자신의 지출을 기록하고 비교하고 경쟁하는 프로젝트를 만들고 싶었다.

 

이걸 토대로 우린 기획서와 유저시나리오를 작성하였고, 실제 개발을 준비하였다.

 

실제 개발

프론트엔드를 공부하며 느낀 건, 늘 사용자가 봤을때 이뻐야한다였다.

디자이너가 없다고 위에 언급했었는데, 그에따라 내가 디자이너의 역할을 하게되었다.

 

디자인을 공부해본적도 없는 내가 어떻게 디자인을 하지와 같은 고민은 했다만, 내가 좋아하는 디자인의 철학을 확고하게 가지고 있었기에 이를 스스로 그려보고는 했었다.

 

그러나 당연하게도 너무 어려웠다. 또한 디자인을 그리면 뭐해 이걸 코드로 짜는것도 내가 해야되는데 와 같은 고뇌 무한궤도에 빠졌었는데..

 

어떻게든 되더라

난 차근차근 팀원들과 짱구를 굴리며, 레퍼런스를 찾기 시작했다. 그러다 찾은 좋은 레퍼런스 디자인을 백엔드 개발자 분이 보내주셔서, 그걸 보니 디자인 아이디어 마구마구 떠올랐다.

 

사용자 친화 제발..

내가 가장 싫어하는 웹사이트형태는 광고배너 와다닥 있고 안에 정보 더럽게 많은 것들을 제일 싫어한다.

프론트엔드 개발자든, 디자이너든, 백엔드든 모두 사용자 친화적인 것을 만들어야지, 화려한 기술, 화려한 코드는 어차피 우리만 아는 내용이다.

내가 이 프로젝트를 하며 느꼈던 생각은 심플하며, 한 눈에 볼 수있으며 ,예뻐야한다 였다.

 

여기까지 읽다니 대단하군요

긴 글 읽는데 쉬는시간입니다.

감사합니다. 하하

 

각설하고 실제 개발은 사용자가 보는 UI 순서대로 했다.

시작페이지 → 로그인 → 회원가입 → 메인페이지 → 내부 기능들(Navigation Bar)활용 → 로그아웃 이거겠다

같은 프론트엔드 동료분과 함께 업무를 분배했고, 서로의 코드를 컨펌했다.

 

주석을 많이 달게 했는데, 알다시피 협업하면 이게 뭔소린가 싶은 코드가 무지 많다.

걱정과 다르게 정말 주석이 과도할정도로 많았고, 서로에게 편지 주석에 쓸 정도였다. 그래서 최종때는 지웠다 많이.

 

프론트엔드의 꽃, API 통신

자부하고 말할 수 있다. API 통신의 효율 끝판왕이 되기 위해 매우 열심히 공부했다.

블로그에 API 통신 관련 글만 10개는 게시한것 같다.

왜 굳이 블로그 글 씀? 걍 코딩하면 되지 않나요?

API 연동은 나의 역할이었다. 어떻게든 백엔드 개발자 셋이 구축한 서버를 통신시켜야했고, 난 이걸 완벽하게 하고 싶었다.

쉽게 설명하면..

 

Axios Instance를 만들어서 최대한으로 중복될 코드를 다 줄였다.

Axios 통신객체와 , Api 함수 컴포넌트, UI 컴포넌트의 명확한 삼권분립 체제를 만들었고

더 변태같이 한건, Api 함수 컴포넌트의 매개변수도 단 하나로 통일시키게끔 했다.

-> 이건 모르셔도 괜찮음

 

나의 아이디어기에, 동료 프론트 개발자에게도 알려줘야했기에 글로 표현했다.

상당히 로맨틱하지 않는가

그러다보니 10개의 분량이 만들어졌고, 프론트엔드 개발자님도 이해하셨다.

 

이런식으로 한달이 지나다보니..

구조들이 갖춰지고, 기능들도 뭔가 빼고 넣고 하면 좋을 것 같은 아이디어가 모든 개발자의 뇌에서 샘솟았다.

그러다보니 초기 기획서와는 달라지는 아이디가 마구마구 발생하고 이것들을 조율하며, 갈등이 발생하고는했다.

 

동료들과의 첫 갈등

왜 싸웠음?

1. 백엔드 프론트엔드 간의 진도차이가 너무 발생 (하염없이 누굴 기다린다)
2. 코드 로직 통일하라했는데..
3. 깃허브 충돌
4. 아이디어 충돌
5. 역할 분담

지금 생각해보면 별거 아닌데 별거가 맞았다.

지금은 옳고 그때는 틀리다.

어떻게든 해결되더라 근데 갈등은 불가피하다.

그렇게 하다보니

누구는 열심히하고 누구는 열심히하지 않는 불상사가 일어날 수도 있었는데

우리팀은 정말 모두 다 너무 열심히 해주었다.

Love you GUYS❤️

우리들의 커밋내역

끝

프론트엔드 웹의 배포사이트와, 서버의 배포사이트가 완전히 합을 이뤄 한 몸같이 변하였다.

우리가 의도했던 모든 기능과 로직들이 정상작동 하였고, 무사히 최종발표를 하였다.

 

결과물

시작화면 → 회원가입 → 로그인 -> 목표 금액 설정

0

메인페이지 입성과 지출 추가

0

 

목표 금액 수정 , 프로필 페이지 수정

 

0

통계 그래프 , 제출한 영수증 사진 모음

 

0

친구 추가하기 & 이스터에그

 

0

마치며

제가 만들었던 피피티 일부를 첨부하며 끝냅니다.

부족한 프로젝트였을수도 있으나, 우리에겐 충분했고 과분했다 싶습니다.

여기까지 봐주셨다면 훌륭한 사람 , 제 깃허브입니다.

https://github.com/ChoiTheCreator