시작하며,
사이드 프로젝트 링크 - https://www.pilleat.com/
2022 5월, 처음으로 사이드 프로젝트를 시작했다.
처음엔 단순히 밀크시슬을 사려고 인터넷에 찾아봤는데, 막상 사려고 했을때 뭘 사야할지 몰랐다. 가격이 싸야 좋은지, 해당 성분이 뭐가 들어있는지 봐도 몰랐고, 비교하기가 쉽지가 않아서 성분을 봐도 더 좋은건가 안좋은건가를 알 수 없었다.
한국은 공공데이터가 참 잘 되어있다는 것을 프랜차이즈 정보를 찾아보면서 느꼈는데, 건강기능 식품도 역시나 공공 API가 존재했다.
화해가 소비자의 알 권리를 화장품 성분 비교사이트를 만들어서 성공했듯, 건강기능 식품으로 사이트를 만들어보면 사람들에게 유용하겠다고 생각해서 사이드 프로젝트를 시작하게 되었다.
핵심기능
내가 정의한 사이드 프로젝트의 핵심기능(사용자가 이 서비스를 이용해야할 이유)은"가장 가성비 있는 제품이 무엇인지 데이터적으로 알려준다."였다.
- 성분을 기준으로 비타민 B를 먹을때 한알의 가격이 가장 싸면서, 가장 성분이 많이 들어있는 건강기능 식품 찾기 기능을 만든다.
- 예를들어, 비타민D 제품을 찾을때, 해당 성분이 가장 많이 들어있으면서 한알의 가격이 가장 싼 제품은 OO제품이다.
시작할땐생각보다 어렵지 않을꺼라 생각했지만.. 오산이였다..
1. Back-end [node.js]
사이드 프로젝트를 시작할때, 이미 Django를 한번 써본적이 있어서, node.js와 Django 사이에서 뭘로 백엔드를 만들지 고민을 했다. 이 두 프레임워크의 차이를 고려해본 결과, 앞으로 나는 프론트엔드 개발자가 되고싶다는 점, API서버와 프론트를 분리해서 따로 운영해보고 싶다는 생각, 새로운 컴포넌트를 만드는것을 즐긴다는 내 개인적 성향을 고려해서 node.js로 프로젝트를 진행하기로 결정했다.
2. Front-end [React]
프론트앤드 프레임워크로는 React와 Vue가 있다. 2개의 프레임워크가 몇 가지 차이점이 있지만, React가 현재 가장 인기 있는 프레임 워크라는 점과, React Native를 활용해서 IOS나 Android앱을 만들수 있다는 점이 가장 매력적인 포인트라고 생각해서 React로 프로젝트를 진행하게 되었다.
3. API [GraphQL]
Front-End와 Back-End를 이어줄 API로는 graphQL로 제작했다. 많은 기업이 현재 graphQL을 활용하기도 하고, GraphQL이 갖고있는 장점중, front단에서 원하는 데이터를 수정해가며 요청할 수 있기 때문에 front-end 개발자로서 graphQL을 마스터하는게 더 유용하다 생각했다.
4. 공공데이터 API로 데이터 파싱 [Fetch]
건강기능 식품 정보를 알려주는 사이트이기 때문에, 최초 건강기능 식품 데이터가 필요했다. 다행히 공공데이터 포털에 해당 데이터가 있었고, 공공데이터 API를 fetch를 이용해서 파싱했다.
최초 데이터를 parsing할때와 카카오톡 API, 네이버 API를 사용할때, cors 문제로 고생을 했다.
5. 데이터 생성 [Apollo Client]
추가적으로 생기는 데이터들이 있을꺼기 때문에 기존에 존재하지만 업데이트 날짜가 다른 경우엔 Update를, 기존 정보가 없을 경우 새로운 model을 생성하고, 기존 데이터와 업데이트 날짜가 같은 경우엔 Pass를 하는 식으로 로직을 설계했다.
Step 1 데이터 파싱
Step 2 건강 목표 연결
Step 3 핵심 원료 연결
Step 4 성분 양 정리
Step 5 상품 가격 parsing
순으로 어드민 페이지에서 API를 호출할 수 있게 설계했다.
실제 UI화면
최초 데이터를 가져오는거 자체는 어렵지 않았으나, 데이터를 가져와서 데이터 형식에 맞게 가공해야 했었다.
6. 데이터 정리 [Apollo Client]
가성비 있는 제품을 추천하는 로직을 짜는데 있어서, 공공 데이터 API의 문제는 약 3가지정도였다.
- 유효성분 데이터가 array나 object형식이 아니라 그냥 string이기 때문에 유효성분 데이터를 정렬해줘야한다.
- 유효기능 데이터도 string으로 되어있어서 하나하나 map을 해서 다시 정렬을 한 후에 건강목표와 연결해야한다.
- 가격정보와 한통에 몇알이 들어있는지 정보가 없다.
데이터를 정리하면서 computed field를 이용해서 성분별 양을 수치화해서 성분양을 기준으로 order을 해서 products를 가져오려 했지만, 필터링이 먹히질 않았다. 따라서 step3에서 성분양 정리를 통해 모든 유효성분을 정리한 컬럼을 하나 추가했고, 그 컬럼을 기준으로 성분 양이 많은것부터 적은순서로 건강기능 식품을 가져올수 있었다.
6-1. 정규식으로 데이터 분류 [RegExp]
API로 정보를 긁어올때, 제공한 데이터의 포맷과, 내가 저장해야하는 포맷이 다를 경우가 있는데, 내가 딱 그 경우였다. 이 웹사이트의 핵심기능중에 하나인, 내가 원하는 영양소 대비 가장 싼 제품을 찾아야 하는데, 그러려면 정확히 특정 영양소가 한 알에 몇 mg이 들어있고, 가격이 얼마인지를 알았어야 했다. 따라서 데이터가 최초 넘어올때 정규식을 이용해서 데이터를 원하는 형식에 맞춰서 분류하는 작업을 진행했다.
6-2. 건강목표 및 영양소 연결
최초 데이터를 가져온 이후에 건강기능 식품이 유효성분이 있는 경우, 유효성분과의 의존성을 추가하는 식으로 many-to-many 관계를 디자인 했다. 따라서 피부 개선 이라는 건강목표는 여러개의 상품을 가질 수 있고, 상품 또한 피부 개선, 면역력 증진 등의 여러가지 건강목표를 가질 수 있는 데이터 디자인을 만들었다.
마찬가지로 영양소도 같은 맥락으로 정리해서 유저가 건강목표 혹은 영양소로 제품을 찾을 수 있게 기능을 만들었다.
6-3. 가격정보와 한통에 몇알이 들어있는지 연결
이부분은 정말 오랜시간 고민을 해보고, 네이버 검색 API를 이용도 해봤지만, 제품명을 검색했을때 다른 제품을 crawling하거나, 1통 정보가 아닌 2통,3통에 대한 가격을 가져올때도 있어서, 일단 각 성분별 100개까지는 수동으로 할 계획이다.
7. 필터링 구현 [react apollo client]
필터링을 구현함에 있어, 상태관리가 중요했다. 한 컴포넌트에서 모든걸 관리할땐 useState만 써도 크게 문제가 없었지만, 프로젝트가 커짐에 따라 컴포넌트별 js파일을 추가로 만들었고, 그러다보니 필터링을 구현하는 파일만 봐도
Component
ㄴhealthGoal
ㄴWebSideBar
ㄴMobileFilterBar
Screen
ㄴhealthGoal
ㄴWebList
ㄴMobileList이렇게 구성이 되어있었다. 따라서 healthGoal.js파일 하나에서만 상태관리를 할 순 없었고 전역상태관리를 찾아보던 중, react apollo client에 있는 makeReactiveVar을 사용해서 전역 상태관리를 했다. Redux와 Recoil같은 전역 상태관리 라이브러리는 추후에 도입해볼 예정이다.
8. 회원가입 구현 [useForm]
리액트 라이브러리인 useForm을 이용해서 회원가입을 구현했다. 추후에 설문으로 어떤 건강기능 식품을 먹으면 좋을지 추천해주는 서비스가 완료되면 유저들도 회원가입을 해서 정보를 저장해놔야 하기 때문에 미리 만들었다.
9. 로그인 구현 [use Hook]
회원가입과 로그인에는 모두 보안을 위해 JWT를 사용해서 구현을 완료했다.
로그인을 한 이후에 권한관리를 위해 hook을 사용해서
1. 유저가 로그인을 했는지 안했는지,
2. 유저의 권한에 따라 기능에 따른 access권한을 나눠놓았다(adimin).
10. 아키텍쳐 설계 [MVVM Model]
처음엔 별 생각 없이 1개의 js파일에서 모든걸 처리하려 했는데, 프로젝트가 커짐에 따라 유지보수가 급격하게 힘들어졌었다. 몇가지 디자인 패턴을 찾아봤는데 MVVM이 가장 유용할거 같아서 도입을 해봤는데,
나에겐 뷰 모델이 여전히 너무 크게 느껴졌다.
예를들어 내가 signUp.js에서 갖고 있는 components는
- 이름
- 생년월일
- 성별
- 아이디
- 비밀번호
- 핸드폰 문자확인
이기 때문에 한가지 폼에서 저 정보를 관리하기가 쉽지가 않았다.
따라서
model, view, view model에서 3개의 view모델로 관리를 하고있는데, 이부분은 조금 더 고민은 해봐야할거 같다.
12. 반응형 디자인 [useMediaQuery]
핸드폰과 컴퓨터로 봤을때의 스크린 크기 차이 때문에 useMediaQuery를 사용해서 스크린 사이즈별 디자인을 하기위해 screen 폴더 내에 mobile과 tablet & computer을 따로 분리해서 관리했다.
13. 배포 [Netlify, Heroku]
사이드 프로젝트로 시작한만큼, 초반에 지출이 없이 사이트를 운영해보는게 베스트라고 생각을 했다. 다행히 front를 netlify로 런칭할 경우 도메인을 제외한 비용지출이 없었고, heroku도 hoby용으로 배포할땐 비용이 들지 않았다.
마치며,
드디어 5개월동안 몰두했던 프로젝트를 복기해보는 시간이 왔다. 최초에 프로젝트 기간을 6개월 정도로 잡았고, 완벽하게 모든 기능과 정리를 끝내는 것까지 목표한게 아니라, 최초 정의한 내가 찾는 카테고리(영양분, 건강목표)안에서 가성비 있는 제품을 찾는 기능을 구현하는 것이기 때문에, 일단은 V1.0을 배포하는걸로 프로젝트 1을 마무리하려 한다.
만족도는?
-
서비스 (90%만족!)
최초에 원하는 기능이 가성비 있는 제품 찾기였고, 실제로 공공데이터 15,000건을 기준으로 가장 가격이 저렴하면서, 영양분이 한알당 많이 포함되어 있는 제품을 찾을 수 있기 때문에 건강기능 식품을 찾는 사람들에겐 도움이 될 수 있는 사이트라고 생각한다. -
개발
a. 성장(100% 만족)
프로젝트를 진행하면서 많은 문제를 마주하고, 해결했는데, 단순하게 에러와 기능적인 부분에서 문제를 마주쳤다기 보다 상태관리를 전역으로 할지, 컴포넌트 내에서 하는게 좋은지, 디자인패턴이 MVVM이 왜 효율적인지, graphQL을 쓰면 어떤어떤 장점이 있는지, 왜 객체지향 프로그래밍을 해야하는지 등을 알게 되었다.
다른 누군가가 그게 좋으니까, 그게 프로그래밍적으로 효율적이니까 그렇게 해라 가 아니라, "프로젝트를 유지보수 할때, 실제로 저렇게 하지않는다면 프로젝트를 만드는 시간보다 유지보수 하는데 시간을 더 쓰겠구나" 라는걸 직접 경험해보니까 잘 이해가 안가던 이론적인것들이 더욱 친숙하게 다가오는 경우가 많았다.
해설을 보지 않은채로 문제를 주먹구구식으로 해결하다가, 좋은 해설집을 만났을때의 기분같은걸 느꼈다.
b. 코드(20%)
프로젝트 범위가 너무 넓었던건지 모르겠지만, 내가 봤을때 나의 코드는 엉망이다. 지금까지의 초점은 내가 원하는 기능이 작동하게 였다면, 앞으로 내가 해야할 작업은 내가 원하는 기능이 "효율적으로"작동하게 코드를 변경하는것이다.
이에 따라 추가로 해야할것들이 있는데,
- git 버전관리
- refactoring
- MVVM패턴 적용
- recoil or redux
- normalization
- typeScript
- website speed insight 개선
- google page speed insight
- next.JS
- 권한설정
- react custom hook
- 사용자 버그 추적 및 개선
- sentry
등을 사용해서 v1.1, v.1.2 등으로 클린 코드와 버그 수정등을 할 계획이다.
마지막으로,
사이드 프로젝트를 하면서 가장 좋았던 점은, 내가 어디까지 알고, 어디까지 모르는지가 명확해진다는 점이다. 특히나, 초기 개발자일수록 내가 쓰고 있는 기술이 누군가의 추천 혹은 대세가 그렇기 때문에 해당 기술을 사용할때가 많은데, 직접 프로젝트를 만들고 문제를 해결하다보니까
- 로딩이 느려서 유저 이탈이 처음에 많이 일어날것 같아, 좀 더 빠르게 로딩이 되는 기술이 없을까? --> next.js (server side rendering)을 도입해볼까?
- 프로젝트를 하다보니 전역상태의 변수가 너무 많아졌어, 해당 변수들을 모아서 어떤 규칙을 만들고 사용하고 싶은데 좋은 기술이 없을까? --> redux or recoil
- 프로젝트의 규모가 커지다보니, 객체 지향 프로그래밍이 좋다는걸 알게됬어, 자바스크립트를 사용해서 객체지향 프로그래밍을 하고싶은데 좋은 툴이 없을까? --> typeScript
와 같은, 기술을 먼저 생각하기보다 문제점이 뭔지에 대해 먼저 생각하고, 그 문제점을 해결하기 위한 기술을 나중에 생각하는 관점이 생겼다.
