블로그를 쉬는동안 리액트 공부를 했다.
기존의 강의를 듣고 클론코딩하는 방식이 아니라 새로운 도전을 해보고 싶었다. 그래서 잘 듣고 있던 유데미 리액트강의를 멈춰두고 한달정도 기간을 잡고 느긋하게 만들기 시작했다.
(강의를 멈춰둔 시점은 useEffect를 배우기 직전 쯤인데 이 프로젝트를 만들다보니 자연스레 useEffect에 대해서 공부할 수밖에 없게 되더라...)
프로젝트 소개
이번에 만든 프로젝트는 일기를 쓰는 사이트 이다... (https://hamsoter.github.io/diaryapp/)
이름은 없다. 그냥 말 그대로 일기를 쓰는 사이트이며, 정말 일기를 쓸 수 있고. 귀엽다.
하지만 브라우저 탭에 덩그러니 'React App' 이라고 뜨는 건 좀 아닌 거 같아서 급하게 '끄적끄적' 이라는 이름? 아닌 이름을 붙였다. 근데 안 어울린다. 한 유저분께서는 쁘띠빠띠 유령일기 사이트라는 귀여운 애칭으로 사이트를 부르시더라. 귀여움...
사용한 기술 (라이브러리)
- React (FE)
- React Router Dom
- Chakra UI
- formik
- react color
- datepicker
- ... 그외 몇가지 css 관련 라이브러리
- Firebase (BE)
크게는 리액트와 파이어베이스 두 가지를 사용했으며, 그 외 리액트에서 여러 라이브러리를 사용해보았다.
프로젝트 시작
우선 처음엔 정말 가벼운 마음으로 만들기 시작했다. 그런데 생각보다 무거워지기 시작해서 스스로 좀 당황. 이럴거면 프로젝트 시작부터 블로그에 개발일지를 쓸 걸... 하며 후회했으나 이미 늦어버린 걸 뭐 어째. 지금 이렇게 회고라도 쓸 기력이 있는 것을 감사하기로 한다.
처음에는 간단하게 db없이... 그러니까 새로고침하면 데이터가 전부 날아가는 방식으로 개발을 하려고 했다. 그리고 실제로 그렇게 코드를 짰고. 그러니까... 처음엔 간단한 UI만 그려내고자 했다. 물론 큰 문제 없이 잘 동작했다. 여기까지 만드는 데엔 시간이 얼마 걸리지 않았다. 그리고 이 과정에서 state, props등의 리액트 기초 개념이 많이 익숙해졌다.
그렇게 프로젝트를 마무리 지을까 하던 차에... 줄곧 같이 공부해온 산소님께서 firebase를 같이 공부해보자며 제안해주셨고, 오 그럼 지금 만든 거 firebase로 바꿔볼까요? 로 대화가 이어지며 그렇게... 두근두근한 마음으로 지옥문을 열게 되었다.
눈물나는 지옥들
1. 비동기 지옥
우선 난 비동기에 대한 지식이 많이 없었다. 그야 그럴 것이 끽해봐야 노마드코더의 무료강의인 리액트 무비앱을 만들었던 기억... 거기서 ajax를 약간 찍먹해봤다는 정도. 그때도 손은 코드를 따라치고 있었지만 머리는 어버버... 잘 이해가 가지 않았다. 아무튼 그러고 잊고 있다가 이번에 firebase db의 데이터를 get 해오는 과정에서 꽤나 골머리를 앓았다. 데이터는 잘 가져왔으나
데이터를 db에서 받아옴 => state에 저장 => 화면에 출력
이것이 순서대로 멋지게 착착 일어난다면 얼마나 좋을까?
'외부에서 데이터를 받아오기' 라는 사건 하나가 개입되었을 뿐인데... 코드의 실행순서가 극명하게 중요해졌다. 조금만 수서가 잘못되어도 화면이 멈추며 마구마구 고장나기 시작했다. 별 수 없이 useEffect를 공부해서 사용해보았는데 그럼에도 한 번에 해결되지 않아서 여러 블로그들을 떠돌았다. 그래도 이 과정에서 리액트의 생명주기에 대해 깊은 학습을할 수 있었다.
2. Formik 지옥
Formik은 리액트에서 Form의 유효성 검사를 간편하게 해주는 라이브러리다. 물론 익숙해지면 정말 간편하다. 익숙해지기까지 너무 낯선 게 문제다. 공식 문서를 번역해서 열심히 돌려보고. 코드를 복사 => 붙여넣기 했는데. 에러가 난다. 근데 왜 나는 건지...? 구조가 왜 이렇게 생겼지? 이 메서드를 고치면 되는 건가? (이러고 모든게 와장창)
아무튼 코드의 생김새가 너무 낯설어서 여기서 많은 시간을 허비했다.
3. 장풍식 db 구조 지옥
맨 처음의 db 구조를 보자면 굉장히... 장풍처럼 생겼다.
└ users
└ user1
└ diaries
└ diary1
└ pages
└ page1...
└ page2...
└ diary2...
...
└ user2
...
└ user3
...
이런 식이었다. 그러니까 유저 A의 '개발일지'다이어리의 '5월 2일 회고' 페이지를 찾으려면
먼저 모든 유저의 모든 데이터가 담긴... users에 접근한다.
거기서 그 유저의 모든 다이어리가 담겨 있는 diaries에 접근한다.
그리고 거기서 해당 page를 집어온다.
최하위 데이터(페이지)를 가져오기 위해서 최상위 데이터(모든 유저)를 가져와야 했는데 아무 생각 없이 개발하다보니 이게 문제될 거라고 처음엔 생각하지 못했다. 실제로 코드도 잘 동작하고...
그렇지만 하지만... 역시... 이건... 이건 좀 아니지 않나? 하는 마음에 산소님께 조언을 구했고 결국 db 구조를 얕게 수정했다.
- users
- users1
- users2
- ...
- diaries
- diary1
- diary2
- ...
- pages
- page1
- page2
- ...
결국 user와 diary와 page가 반복되고 있기에 이들을 분류에 맞게 최상위 카테고리로 두었다.
user엔 user의 정보가 담겨 있고, diaries엔 다이어리가 담겨 있고, pages는 다이어리 속 페이지들이 담겨 있다.
훨씬 깔끔하다.
4. 배포시 404페이지 적용이 안됨
이건 바로 어제까지 골머리를 앓던 부분이다. github pages를 이용해서 배포를 하려고 했다. 이번엔 특별히 커스텀 404페이지를 만들어서, 적용할 생각에 아주 신이 났다. 그런데 원하는 커스텀 404페이지가 뜨지 않았다. 로컬에서는 제대로 귀여운 화면이 나왔으나
배포 후에는 React의 서버 사이드 렌더링을 사용할 수 없기 때문에 배포된 파일에서 올바른 라우트로 이동하게 하는 작업을 따로 해주어야 했다.
따라서 배포 후 index.html 파일을 수정하고 404.html도 따로 넣어서 내가 의도한 404페이지가 나오는 트릭 코드를 추가했다.
이 문제에 대해서 아주 자세히 다룬 블로그가 있다. (https://velog.io/@ausg/gh-pages-react-router)
이 블로그를 보고 문제를 해결할 수 있었다.
5. React Router Dom 버전 업데이트 지옥
갑자기 업데이트 해버리는 게 어딨어요... React Router Dom v6이 정말 얼마 전에 나왔다. 나에겐 history 기능이 절실한데 history가 사라졌다고 한다. 그리고 문법이 꽤나 파격적으로 바뀌었더라. 이 과정에서도 많이 헤매게 되었다. 하지만 좋은 공부가 되었다. 덕분에 영어 공식문서 발번역을 견디는 경험치가 쬐끔 올랐다.
아쉬운 점들
개발하면서 아쉬웠던 점들. 반성하는 점들이다.
1. 시멘틱 태그를 어떻게 쓰지
UI라이브러리를 쓰다보니 시멘틱 태그를 사용하고 싶어도 어떻게 해야 할지 감이 안 잡혔다.
이 부분은 결국 해결하지 못한 채로 지금까지 나의 사이트는 div 지옥에 빠져 있다... 크게 아쉬운 점 중 하나.
2. 컴포넌트를 깔끔하게 나누지 못함
처음부터 디자인 유형을 깔끔하게 분리해두어 (일정한 마진값 등)
디자인별로 UI 컴포넌트를 깔끔하게 나눠뒀다면 정말 좋았을 것이다.
일정한 margin과 border radius를 가진 컴포넌트들을 하나로 묶을 생각을 너무 뒤늦게 해버렸다.
손대기엔 개발 기간이 다시 너무 길어질 것 같아서 여기서 만족하기로 했다.
하는 방법은 알고 있으니 다음 프로젝트엔 이 점을 잘 지키고 싶다.
3. 오프라인 환경에서 사용할 수 없음
db에 직접 접근하는 코드가 최상단에 있기 때문에, 오프라인 환경에서는 서비스를 이용할 수 없다. 오프라인 환경에서 사이트 접속은 당연히 안되는 게 맞지만... 차후 리액트 네이티브를 이용하여 앱으로 배포할 경우, 어떻게 해야 좋을지 생각을 하지 못했다. 당장 취업이 급해서 사이트에서 마무리지었지만 아쉬움이 남는다.
4. UX개판, UI구림
물론 디자인을 배워본 적이 없어서... 어쩔 수 없다고 생각하지만. 아냐 어쩔 수 없는 게 어디 있으랴. 아쉬운 건 아쉬운 거다. 우선, 모바일에서 보면 헤더부분이 링크창에 가려서 안 보이는 일이 발생한다. 모바일창에서 테스트를 해보지 않고 무작정 개발한 탓에 이걸 나중에야 발견하고 만다. 다음엔 좀 더 꼼꼼하게 모바일에서의 사용성을 신경써봐야겠다.
뿌듯한 부분에 대하여
반성할 부분도 썼으니 이제 칭찬을 해봐도 좋지 않을까? 이젠 내가 좋아하는 이 사이트의 귀여운 부분을 소개해볼까 한다. (사실 이걸 쓰고 싶어서 빌드해온 거임)
귀여운 그림들
우선 여기 나온 일러스트들은 전부 내가 그렸다. 오타쿠의 힘을 발휘 :)
안아줘요 유령부터, 파비콘까지 직접 도트를 찍고 그렸다.
보다시피 디자인은 메인화면의 책 표지 모양을 그대로 가져온 것이다.
귀엽다. 로그인창에서 만나볼 수 있다.
그렇게 만든 404 페이지가 귀엽다
수상할 정도로 공들인 404페이지다.
궁금하신 분들은 사이트 링크 뒤에 임의의 이상한 말(https://hamsoter.github.io/diaryapp/메롱)을 붙여 확인해보시길 :)
자세히 보면 길을 잃은 횟수도 db에서 카운트중이다. 특정 카운트에 축하 이벤트를 넣어보고 싶다고 생각중. 역시 이상한 곳에 힘빼기란 내가 너무 좋아하는 일이다.
영어를 최소화함!
모두가 영어를 할 수 있는 건 아니다. 그러니 이 사이트엔 영어를 안 넣을 거야. 라는 이상한 고집을 가지고 시작했다.
로그인, 로그아웃 같이 대체할 말이 잘 떠오르지 않는... 설령 있다고 해도 그 말이 더 생소한 케이스는 그냥 그대로 사용했다. 별 거 아니지만 만족하는 부분이다.
느낀점
기존의 강의를 듣고 기능을 배운 후 클론코딩 하는 방식이 아닌, 직접 만들고 싶은 걸 만들기 위해서 맨땅에 헤딩하며 기술을 배워가는 과정은 마치 정글을 탐험하는 것처럼 즐거웠다.
늘 프로젝트를 시작할때 두려워서, 내가 이 기능을 구현하지 못할 것 같아서, 강의에서 배우지 않은 내용이 나오면 어떻게 해야 할지 잘 몰라서! 자신감 부족으로 만들기 시작하는 걸 굉장히 주저했는데, 역시 그냥 만들고 싶은 거 뭐든 부딪혀보는 게 빠른 성장의 길인듯 하다.
사실 강의(클론코딩)는 결국 좋은 모범답안지가 있다는 거고... 그 사실 자체가 사람을 되게 해이하게 만드는 듯 하다. 적어도 난 그랬다. 실제로 일을 하면서는 모범답안지가 있는 경우는 거의 없을텐데 말이다.
그리고 생각보다 나는 멍청하다. 강의를 본다고 지식을 100% 꼭꼭 씹어먹은 게 아니다. 이번 프로젝트도 절반은 강의에서 배운 지식 + 남은 절반은 새로운 지식을 배워가며 만들었는데 원래 알고 있다고 생각했던 그 절반의 지식도 되게 빈약하다고 느꼈다... 간단한 UI를 그릴 때도 강의랑 좀 다르다고 생각지도 못한 시나리오로 날 너무 괴롭혔다.
그냥 막상 그런 상황이 닥쳐도 쫄지 않고 새 기술을 적용해보기도 하고. 오류가 나면 구글링도 하고 영어문서도 어거지로 번역해서 찾아보고... 그래 이번 프로젝트는 난생 처음 보는 오류가 뜨고... 도무지 구현을 어떻게 해야 할지 모르겠어서 머리를 싸매는... 그냥 그런 헤매는 과정 자체를 겁먹지 않도록 훈련을 하는 느낌이었다.
역시 무엇이든 완성해보는 경험이 중요하구나. 완성까지 가는 과정 자체가 전부 배움이구나. 정말로 잘 만드려는 생각으로 시작하고자 한다면 결국 부담감에 시작 자체를 두려워하게 되는구나. 라는 걸 깨달았다.
한 달이라는, 심히 느긋한 시간을 가지고 만든 프로젝트지만. 만족한다.
그리고, 축하!
SNS에서 소소하게 관심을 받아 5월 2일 기준 가입자수가 100명을 돌파했다 :)
정말 내 서비스에서 일기를 쓰는 사람이. 유의미한 데이터를 남기는 사람이 있다는 것이다. 이게 뭐라고 두근두근!
일기 수정 관련 버그 제보도 받아서 어제 급하게 고쳤다. 귀여운 서비스를 만들어줘서 고맙다는 인사도 받았다. 영광입니다... (firebase를 쓰자고 제안해주신 산소님께 너무나 감사)
작은 토이프로젝트라고 생각해서 처음엔 소소하게 친구들 10명정도가 가입할 줄 알았다. 그래서 아 세상에 또 딥 웹 하나 뿌렸군. 하고 생각했는데 정말 모르는 사람들이 들어와서 일기를 쓰기 시작했다. 따라서 어깨도 좀 무거워졌다. 데이터의 안전에 대한 고민이라던가. 내가 데이터를 관리하는 방식이 과연 올바른 방식인가? 이거에 대해서 확신할 수가 없다. 당연히도 아직 모르니까... 갑자기 어느날 데이터가 사라져버리면 어떡하지? 어떤 식으로 책임을 져야할까... 고민되기 시작했다. 따라서 '일기 백업하기' 기능의 필요성을 느꼈다. 이 부분은 회고를 올린 후에 업데이트를 해볼 생각이다.
업데이트한 부분을 팝업으로 알려주는 업데이트 노트 기능을 넣어도 좋을 것이다.
즐거웠다. 역시 뭔가를 만드는 일은 즐겁다. 다른 사람과 나누면 더더욱.
'회고' 카테고리의 다른 글
| React와 Node.js + MongoDB로 쇼핑몰을 만들어보며... (1) | 2022.05.19 |
|---|
