4주간의 파이널 프로젝트 회고
들어가기에 앞서..
이 회고는 2021년 2월 17일 ~ 2021년 3월 14일 까지 약 한 달 가량 진행했던 파이널 프로젝트를 주제로 담고 있습니다.
1) 드디어 시작됐다, 파이널 프로젝트!
파이널 프로젝트에 들어가기 앞서 진행했던 퍼스트 프로젝트 (2주) 에서 나는 백엔드 포지션을 맡았다.
해당 포지션을 맡으면서 배포는 직접 해보지 못했지만 API 문서화와 API 로직을 구현했고 이 과정들은 꽤나 내게 흥미롭게 다가왔었다.
그렇게 나름 만족스러운 퍼스트 프로젝트를 마무리하고 파이널 프로젝트를 들어가려던 찰나에 나는 고민에 빠졌다.
"이대로 백엔드를 파볼 것인가? 아니면 이번 프로젝트에서는 그동안 배웠던 프론트엔드 지식을 계속 살릴 것인가?"
프론트엔드 지식은 사용하지 않은지 거의 한 달이 넘어갔기 때문에 이전에 빠르게 습득한 지식들은 마찬가지로 빠르
게 휘발된 상태였고 따라서 저 때의 나는 프론트엔드 지식보단 백엔드 지식이 조금 더 머리에 많이 남아있는 상태였다.
그럼에도 불구하고 나는 내 개인적인 욕심 (정확히는 다양한 스택을 공부하고 싶은 마음) 때문에 파이널 프로젝트 때는
프론트엔드 포지션을 맡아 프로젝트를 진행하게 됐다.
2) 아이디어 구상
첫 아이디어는 Aube (프랑스어로 새벽) 라는 제목의 웹 사이트였다.
전체적인 컨텐츠는 일상생활에 지친 유저들에게 스트레스를 해소하는 방법과 힐링을 하는 법에 대해 알려주는 것이었다.
하지만 해당 아이디어를 개발 단계에 옮기려고 보니 프로젝트의 비중이 8:2 비율로 프론트엔드에게 치중되어
있다는 것을 알게 됐고 결국 해당 아이디어는 물거품이 됐다.
그 다음으로 나온 아이디어가 "가계부" 였다. 하지만 그냥 가계부는 조금 식상하니 지인들과 함께 만들 수 있는 가계부를 만들어보기로 결정했다.
그렇게 해서 지금의 파이널 프로젝트 주제인 Weconomy 가 나오게 됐다.
3) 사용한 스택들, 그리고 왜 썼는가?
일단 처음 스택을 정하는 기준은 "요즘 핫한 것" 이었다.
물론 "요즘 시장에서 이게 핫하다는데 우리도 써보자!" 라는 단순한 마인드로 끝까지 개발에 임했던 것은 아니다.
위 과정은 스택을 정하는데 필요한 시장 조사의 일부분이었고, 스택을 정한뒤엔 이 프로젝트에서 "왜" 사용해야 하며 이 스택으로 어떠한 기술적 효율을 얻을 수 있는지에 대한 충분한 정보를 같은 프론트엔드 팀원과 파악한 뒤에 채택했다.
다음은 각 스택들을 채택한 이유를 "왜 사용해야 하는가?" 와 "해당 스택을 통해 얻을 수 있는 이점은 무엇인가?" 를 중심으로 작성했다.
3-1. TypeScript
-
TypeScript는 JavaScript 의 슈퍼셋이다. 그 말인 즉슨 기존에 JS 를 알고 있다면 러닝 커브가 높지 않다는 것을 의미한다. 파이널 프로젝트는 4주 라는 짧은 기간을 가지고 있기 때문에 위 정보는 강점으로 다가왔다.
-
TS 는 JS 와 다르게 정적 타입 언어 (Static Type Language) 이다. 이는 동적 타입 언어인 JS 의 불안정한 타입 안정성을 보장해주며 결국 장기적으로 고려했을 때 프로젝트의 유지보수, 예상치 못한 버그, 시간적 효율의 면에서 이득을 취할 수 있을 것이라 판단했다.
3-2. Redux
-
이번 프로젝트에서는 기본적으로 SPA(Single Page Application) 을 기반으로 한 동적 웹을 구현할 것이기 때문에 React.js 를 사용하기로 했다. React 는 부모 컴포넌트에서 모든 상태를 관리하고 밑으로 상태를 내려다주기 때문에 직관적이라는 장점이 있지만 프로젝트의 규모가 커지다보면 부모 컴포넌트의 코드 양이 굉장히 길어지고 이는 유지보수 측면에서 불리하다는 단점 또한 가지고 있다. 따라서 우리는 이러한 단점을 보완할 Redux 를 사용하기로 했다.
-
Redux 는 상태 값을 특정 컴포넌트에 종속시키지 않고, 바깥에서 관리할 수 있다는 장점을 가지고 있다. React 만 썼다면 특정 컴포넌트에게 값을 전달하기 위해 수많은 props 를 계속해서 내려다 줘야하는 불편함이 있지만 Redux 는 상태를 바깥에서 관리 (상태의 중앙화) 하기 때문에 어떤 컴포넌트에서 불러오든 바로바로 상태를 관리할 수 있다는 장점이 있다. 이번 파이널 프로젝트의 규모를 가늠해 봤을 때 Redux 를 통해 얻을 수 있는 이점은 명확했다.
3-3. Redux-Saga
- Redux 는 동기적으로 실행된다. 이게 Redux-Saga 라는 미들웨어를 사용해야 했던 가장 큰 이유다.
특정 시간, 특정 동작 이후에 액션을 실행할 수 없다는 것은 동적 웹에서는 치명적인 단점으로 다가온다.
- Redux-Saga 는 비동기 처리가 필요한 액션이 발생할 때를 기다리다 해당 액션이 dispatch 되면 특정 작업을 진행한다. 여기서 특정 작업이란 자바스크립트 코드를 실행하거나 현재 상태를 불러오거나 다른 액션을 dispatch 하는 것들을 일컫는다.
3-4. GraphQL
-
기존 Restful API 에서는 불필요한 정보까지 받아오는 Over-Fetching 이나 특정 작업을 수행하기 위해 여러 API 를 호출하는 Under-Fetching 이 일어나기 쉽상이었다. GraphQL 은 이러한 Restful API 의 한계를 극복하고자 나온 것이었고 이는 프론트엔드 입장에서는 당연히 환영할 스택이었다.
-
GraphQL 은 클라이언트가 필요한 데이터만 가져올 수 있다는 강점이 있다. 예를 들어 Restful API 에서는 A,B 의 데이터를 가져오기 위해 서버에게 A,B,C,D,E 에 대한 데이터를 받아온 후 클라이언트가 A,B 를 골라서 사용해야 했다면 GraphQL 에서는 A,B 에 대한 요청만 보내면 A,B 에 대한 데이터만 가져올 수 있으므로 서버와 프론트 모두에게 효율적이다. 이러한 이점은 곧 스택의 사용 이유가 되었다.
3-5. Sass
-
기존 CSS 는 코드가 복잡할 수록 유지보수가 더 어려워진다는 단점이 있었다. 그리고 변수와 같은 기능이 없었기에 코드의 중복이 발생하기도 쉬운 구조였다. Sass 는 이러한 단점을 자연스럽게 보완해준다.
-
기본적으로 Sass 에서는 변수 사용이 가능하기에 유지보수가 쉬워진다. 예를 들어 내가 해당 웹 페이지에서 자주 사용하는 컬러가 있다면 해당 컬러를 특정 변수에 담아놓고 필요할 때 사용하면 된다. 하지만 사용하다보면 기존의 CSS 보다 로직이 더 복잡하게 작성 될 가능성도 충분히 있으므로 해당 스택을 처음 사용하는 내겐 양날의 검과 같은 존재였다.
4) 프로젝트 기능 시연 및 설명
4-1. 랜딩 페이지
.gif)
"유저의 입장에서 사이트에 접속했을 때 무엇을 가장 중요시하는가?" 라는 주제로 팀원과 같이 꽤 오랫동안 논의했었다.
그리고 이 논의의 끝은 "내가 유저일 때 무엇을 가장 중요시했는가?" 로 이어졌고 팀원과의 공통적인 의견은
"첫 랜딩 페이지에 해당 서비스를 잘 보여줄 수 있는 깔끔한 디자인의 사이트" 였다.
이 결론을 토대로 유저들에게 첫 인상을 심어줄 랜딩페이지는 최대한 깔끔하며 사이트의 핵심적인 기능을 담은
몇 가지 gif 와 함께 설명을 덧붙였다.
4-2. 가계부 작성 페이지
.gif)
가계부 작성 페이지는 나의 가계부 목록 중 하나를 선택해 해당 가계부의 수입, 지출을 작성할 수 있는 페이지다.
해당 페이지는 비회원도 경험할 수 있도록 로그인을 안했더라도 체험이 가능하지만, 작성 버튼 클릭 시 로그인이 필요하다는 모달창이 뜨게 된다.
왼쪽 아래에는 수입, 지출을 작성하면서 유저가 간단한 계산을 할 수도 있을 것이라는 아이디어에서 계산기를 추가했다.
4-3. 가계부 선택 페이지
.gif)
유저가 로그인을 했을 경우 나의 가계부를 생성, 혹은 가입되어 있는 가계부를 선택할 수 있는 페이지다.
가계부 생성시 가계부 이름과 가용금액을 적을 수 있으며 변경사항이 잦은 가용금액은 가계부의 어드민이 변경 가능하도록 했다.
가계부의 최대 개수는 4개로 제한했으며 유저의 가계부가 4개가 되면 가계부 생성 버튼이 사라지게 된다.
4-4. 가계 내역 확인 페이지
.gif)
유저가 가계부를 선택했다면 다음의 가계 내역 확인 페이지로 이동하게 된다.
왼쪽부터 해당 가계부의 구성원을 확인할 수 있다. 어드민의 경우 왼쪽에 노란색 마크가 붙게 된다.
그 다음 중간 부분에는 해당 가계부의 월 가용금액과 지출 금액을 산정한 남은 금액을 한 눈에 보기 쉽게 그래프 형태로 만들었으며 그 밑에는 이번 달 가장 많은 지출이 생긴 카테고리 순으로 그래프를 정렬했다.
오른쪽 부분에는 달력에서 해당 날짜를 선택하면 그 날짜의 수입, 지출 내역을 볼 수 있게 해뒀으며 해당 일의 수입과 지출을 계산해 얼만큼의 소비 또는 지출을 했는지 한 눈에 알 수 있게 해뒀다.
4-5. 가계 수정 및 삭제 기능
.gif)
이미 작성했던 지출, 수입 내역이더라도 잘못 작성됐을 경우를 대비해 내역을 수정 및 삭제가 가능하도록 만들었다.
4-6. 가계 구성원 추가 기능
.gif)
Weconomy (위코노미) 페이지의 가장 큰 특징인 지인과 함께 공유하는 가계부 기능이다.
친구들과 여행갈 때의 회비, 가족끼리 사용하는 공용 자금이 있을 때 등 다양한 경우에 활용이 가능하며
총무 한 명이 모든 가계 흐름을 파악하는 것이 아닌, 구성원 모두가 지출, 소비 흐름을 파악할 수 있다는 장점이 있다.
구성원 초대는 어드민 뿐만 아니라 해당 그룹에 포함된 유저라면 누구나 가능하며 초대할 사람의 이메일을 입력하면 간편하게 구성원 추가가 완료된다.
당연한 말이지만, 초대하려는 유저는 위코노미에 가입된 유저여야만 가능하다.
또한 그룹의 최대인원은 4인으로 설정 해 소규모 모임의 회비 관리에 탁월하다고 할 수 있다.
4-7. 문의 페이지
.gif)
서비스를 이용하는 유저가 특정 문제에 부딪혔을 경우 개발자에게 이메일을 보낼 수 있는 문의 페이지를 구현했다.
비회원이 사이트 이용 시 문제가 생길 수 있는 부분도 있으므로 로그인 유무와 상관없이 문의할 수 있도록 했다.
5) 💻 Overview
4주라는 짧다면 짧은, 길다면 긴 시간이 드디어 끝이 났다.
파이널 프로젝트를 시작하기 전부터 "내가 과연 어떤 서비스 하나를 만들어 낼 실력이 되는가?" 라는 의구심을 계속 품었던 기억이 난다.
퍼스트 프로젝트 때는 백엔드를 맡았던 내가 가장 대미를 장식할 파이널 프로젝트에서는 프론트엔드 역할을 맡으니 그 무게감은 배로 다가왔던 것 같다.
하지만 정말 좋은 팀원분들을 만난 것 때문일까, 위 생각에 초반부터 힘들어 했던 나를 계속 북돋아주고 응원해준 덕에 오히려 더 힘이 났고 이는 나 뿐만 아니라 팀원 모두에게 긍정적인 시너지 효과를 내주었다.
이번 프로젝트를 진행하면서 가장 크게 느낀건 프로젝트도 물론 중요하지만, 협업을 하면서 팀원과의 커뮤니케이션이 얼마나 중요한지에 대해 많은 깨달음을 주었다.
내 자신이 부족했던 커뮤니케이션 습관에 대해서도 돌아보게 되었고, 팀원과 협업시 특정 이슈에 대해 의견이 갈릴 때는 어떤 식으로 문제를 해결해 나가야 할지에 대해서도 꽤나 많은 고민을 했던 시간들이었다.
결국 초반에는 조금 절었지만, 4주간의 기간동안 프로젝트 외에 팀원들과 같은 사람으로써 소통하고, 웃고, 즐겁게 보낸 시간들 덕분에 생각 외의 더 좋은 결과가 나올 수 있던 것 같다.
이번 프로젝트를 무사히 마칠 수 있게 도와 준 우리 팀원들께 감사의 인사를 남기며 파이널 프로젝트 회고를 마무리한다.
고맙습니다!
