🕊️학수고대 프로젝트
FE 개발 기간 : 23.12.10 ~ 24.04.04
서비스 기간 : 24.04.04 ~ 24.05.26
백엔드, 디자이너와 협업 후 배포를 해서 사용자까지 받아 본 첫 프로젝트였습니다. 너무 많은 것을 배웠고, 돌아보니 많은 성장을 했습니다. 프로젝트를 통해 깨달은 점, 느낀 점 등을 회고로 작성하려고 합니다.
🔥기술은 필요에 의해 배워야.. (zustand & react-query)
- 상태 관리 라이브러리 zustand 도입!
하나의 api에서만 제공되는 값을 모든 컴포넌트에서 사용할 필요성이 생겼고, 이에 따라 상태 관리 라이브러리를 도입하게 되었습니다. 상태 관리 라이브러리의 대표는 역시 리덕스가 아닐까 싶습니다. 하지만 제게 리덕스는 늘 어렵고 낯선 존재이자 두려움의 존재였기에 쉽게 도입을 할 엄두가 나지 않았습니다.
Zustand 사용기
Zustand를 사용하는 이유 프로젝트에서 닉네임을 보내주는 api 로직이 하나인데, 닉네임을 다른 컴포넌트에서도 띄워야 했다. 그렇기에 해당 값을 전역적으로 관리할 필요를 느꼈고, 이에 따라 상
studysmart.tistory.com
하지만 zustand는 달랐습니다. 공식 홈페이지의 10줄 조금 넘는 예시코드만으로도 바로 전역 상태 관리를 적용할 수 있었습니다. 덕분에 적은 시간 투자 대비 빠른 적용을 할 수 있었고, 이를 통해 토큰과 로그인 여부, 유저 닉네임까지 3가지 상태를 관리할 수 있었습니다.
- 나의 빛.. react-query..
백엔드와 통신을 해서 배포까지 하는 경험은 이번이 처음이었습니다. 또한 서버비가 비싸다는 말을 여러 번 들어봐서 그런지 이에 대한 막연한 불안감이 있었습니다.
반복 요청 때문에 서버비 수십만원 나오면 어뜨케?!
혹시 모를 서버비 폭탄을 방지하기 위해 정보를 찾던 중, 리액트 쿼리라는 친구가 중복 요청을 도와줄 수 있다는 게시글을 발견했습니다. 아묻따... 바로 배워버려... 실제로 프로젝트에서 사용해 보니 기대 이상으로 큰 도움이 되었습니다.
우선 캐싱 기능 덕분에 마운트 될 때마다 불필요한 재요청을 보내지 않게 되었습니다. 이거 하나만으로도 서버비에 대한 불안감을 해소할 수 있었습니다. 게다가 마운트 시 로딩창이 나타내는 깜빡거림도 사라짐! ㅎ.ㅎ
또한 리액트 쿼리가 loading, error 같은 상태를 자동으로 관리해 주니, 코드가 훨씬 간결해졌고, 덕분에 굳이 ustState로 복잡하게 상태관리를 할 필요가 없어서 개발이 정말 정말 수월해졌습니다..
프로젝트가 끝난 지금, 우려했던 서버비 폭탄은 맞지 않았습니다😎 그래도 우려했기에 이런 좋은 기술을 알게 되었다고 생각합니다. 평생 가자 리액트 쿼리야..
- 깨달은 점
확실하게 목적과 필요에 의해 기술을 배우니, 습득과 적용이 빠르다는 것을 알게 되었습니다. 하지만 빠르게 적용할 수 있는 만큼 깊은 개념을 쌓을 시간은 부족했다고 느껴집니다. 이번 프로젝트를 통해 새로운 기술을 습득한 만큼, 이제는 더 효율적이고 '잘' 쓰는 방법을 익혀야겠습니다.
📚사용자 경험의 중요성을 깨닫다
- 서비스 시작까지 일주일.. 비상상황 발생
서비스 시작까지 일주일정도 남은 시점에서 마무리 작업을 하며 행복하게 지냈었습니다. 그러던 중 배포를 연습할 겸 Netlify를 통해 임시 배포를 시도해 보았습니다.
"잉? 왜 화면이 안 나와?"
처음에는 단순히 배포의 문제인 줄 알았지만, 문제의 본질은 화면이 너무 느리게 나오는 것이었습니다. 흰 배경에서 시간이 지나면서 화면이 뚝! 뚝! 뚝! 렌더링 되는 모습은 공포 그 자체...
- "아니 로컬에서는 잘되던데요?!"
로컬 환경과 배포 환경이 같은 줄 알았.. ㅋ... 로컬 환경에서 문제없이 잘 작동하던 프로젝트가 배포 후 이런 문제를 일으키니, 자칫하면 능력 없는 프론트엔드 하나 때문에 프로젝트를 전체를 망칠 수도 있다는 공포감이 엄습해 왔습니다. 어떻게든 서비스 시작 전까지 이 문제를 해결해야 했습니다.
눈물겨운 사용자 경험 개선하기
문제점 백엔드와 통신까지 잘 연결했기에 더 이상의 난관은 없을 거라 생각했지만, 사진이 늦게 렌더링 되면서 사용자 경험이 저하되는 문제가 생겼다. 대부분 페이지가 마운트 될 때, 빈 화면
studysmart.tistory.com
원인은 이미지의 느린 렌더링이었으나, 촉박한 시간 내에 이미지를 빠르게 렌더링 하는 방법을 찾을 수 없었습니다. 그래서 기다리는 동안 로딩창을 띄우는 방향으로 접근했습니다.
정말 신기하게도 로딩창만 넣었을 뿐인데 사용자 경험이 훨~씬 좋아졌습니다! 이미지가 완전히 렌더링 되기 전까지 로딩창이 나오기에 깜빡임을 안 볼 수 있으며, 또한 로딩창이 있으니 기다릴 수 있을 것 같은 느낌!
- 이것이 UX!
이 경험을 통해, UX의 중요성을 새삼 깨닫게 되었습니다. 페이지 로딩 속도는 여전히 느리지만, 로딩창을 도입함으로써 더 인내심을 가지고 기다릴 수 있게 되었습니다.
비록 이번에 적용한 방법이 이미지의 느린 렌더링을 해결하는 근본적인 해결책은 아니었지만, 사용자의 체감을 잘 고려하는 것의 중요성을 깨닫게 되었습니다.
프로젝트 막바지에 이르러서야 이런 점을 알게 되어 아쉽긴 하지만, 이번 경험을 통해서 단순히 UI를 예쁘고 보기 좋게 만드는 것을 넘어 사용자들이 어떻게 느끼고 반응하는지를 고려하고 개발을 해야 한다는 것을 확실히 깨달았습니다.. 공부 열심히 해야겠다 증말
😎악으로 깡으로 구현한 CSS.. 어렵다!
- 실력은 없지만 디자인은 살리고 싶어
피그마에 올라온 디자인 시안이 너~무 예뻐서 어떻게든 살리고 싶었습니다. 그런데 저는 실력도 없고 라이브러리를 쓸 생각도 못했던 바보였기에, 그저 제가 할 수 있는 건 깡으로 들이박는 것 밖에 없었습니다.
CSS의 일부 코드입니다. 애니메이션을 기대하는 것처럼 나타내고 싶어서 모든 경우의 수를 따지며 코드를 썼습니다. 이래도 되나 싶었지만 실력은 없고, 완성은 해야 했기에 어쩔 수 없었습니다.
동적인 효과가 들어가는 부분은 전부 위처럼 단순 무식하게 때려 박은 것 같습니다. 기대하는 효과는 얻었으나, 효율성과 클린함이 아주 박살..
- 효율적인 방법을 찾아봐야겠습니다..
완성품은 정말 예쁘고 만족스럽지만 매번 스타일링을 할 때마다 저렇게 할 수는 없을 것 같습니다.
회고를 쓰는 지금은 CSS의 여러 라이브러리가 있다는 것을 알게 되었고, MUI라는 좋은 것이 있다는 것을 또 알게 되었습니다. 악으로 깡으로 들이박아 본 경험을 얻은 만큼, 앞으로는 효율적으로 스타일링하는 방법을 익혀야 할 것 같아요. CSS는 역시 어렵습니다.
🤔 반응형 없는 반응형팀
- 난 내가 반응형을 하고 있는 줄 알았어
작년 겨울, 프로젝트를 처음 시작할 때만 해도 반응형이 뭔지 정확히 몰랐으며, flex와 상대 단위를 사용하면 자동으로 반응형이 된다고 생각했었습니다 핫..
또한 "그냥 모바일에서 웹을 앱처럼 볼 수 있으면 된다"라는 생각만 했었기에, 너비 414px, 높이 896px을 고정한 채로 개발을 시작했습니다. (정확히는 rem을 사용하긴 했지만, 피차일반..)
당연하게도 완성 이후 핸드폰 기종에 따라 여백의 차이가 생겼습니다. 반응형이라는 걸 조금 더 알아보고 시작했으면 좋았을 것이라는 아쉬움이 크게 남습니다.
- 그래도 flex는 조금 익숙해졌다!
flex가 곧 반응형이라는 무지한 착각을 한 덕분인지, 나름 flex를 많이 사용하게 되었습니다. 그래서 전보다 flex에 익숙해졌고, grid스러운 것도 전부 flex로 구현을 했습니다.
근데 막상 해보니 grid를 배워야 할 것 같다는 느낌이... flex로 하는 게 넘 어려웠음!
🤗 실제 사용자를 받아보다!
직접 개발한 서비스가 배포 이후 실제 사용자에게 닿았다는 점이 정말 신기했습니다.
배포 직전에 이미지가 느리게 렌더링 되는 바람에 스트레스도 많이 받고, 자신감도 많이 떨어졌었습니다. 배포를 미루자고 말해볼까 하다가 프론트가 원인인데 그래도 될까 싶기도 하고, 결국 프론트 역량 부족이구나 싶기도 하고.. 그저 무한 자책뿐
그래도 어찌어찌 배포를 하고 사용자를 받아봤는데, 예상외로 많은 긍적적인 피드백을 받았습니다. 덕분에 스트레스도 없어지고 다시 자신감을 얻을 수 있었습니다 ㅎㅎ
개발이 이래서 재밌구나 싶기도하고, 앞으로도 많이 배우고 성장해야겠다는 동기부여도 얻었습니다! 이번 배포를 통해 얻은 소중한 경험이 앞으로 개발할 때 큰 도움이 될 것 같은 느낌적인 느낌
🎊끝이지만 다시 시작
- 오래 걸려도 꼭 리팩토링과 마이그레이션을 하자!
프로젝트의 달력 라이브러리 부분에서 NaN이 넘어오는 부분이 있었던 걸로 기억합니다. 하지만 당장 원인도 모르겠고 일단 실행은 잘되니, 넘어갔었습니다. 현재 타입스크립트를 배우고 있는데, 이런 부분에 타입스크립트를 적용하면서 데이터 타입을 명확하게 정의해보고 싶습니다.
그리고 이미지로 마음고생을 해서 그런지 이미지 최적화도 리팩토링의 주요 목표 중 하나입니다. 최근에 글을 찾아보다가 Next.js가 이미지 최적화에 특화되어 있다는 글을 봤습니다. 한 번쯤 배워보고 싶었는데, 배울 명분을 얻은 것 같습니다 ㅎ.ㅎ Next도 배우고, 이미지 최적화에 대한 다양한 방법도 찾아봐서 이미지를 깔끔하게 렌더링 하는 것도 정말 정말 바라는 목표!
마지막으로는 반응형입니다. 화면이 작은 핸드폰은 가로 화면뿐만 아니라, 세로 화면도 잘린다는 피드백이 있었습니다. 미디어쿼리를 통해 어느 핸드폰에서도 동일한 화면을 렌더링 하는 것이 목표입니다.
정말 애정을 가지고 아끼는 프로젝트인 만큼, 시간이 걸려도 천~천히 완벽하게 리팩토링을 해보고 싶습니다. 위에 말한 부분 말고도 폴더구조 개편, 공통 컴포넌트 분리, 클린코드도 적용해보고 싶고요! 말만 하지 말고 시작해야 하는데, 급하게 하고 싶진 않습니다. 조용히 완전히 영원히 like 너드커넥션
- 나는야 야생형 개발자
프론트 내실이 부족함을 많이 느끼는 요즘이지만, 이를 채우기 위해 책을 보고 있자니 지루해서 미칠 것 같습니다. 그냥 코드를 치며 익히는 게 역시 제일 재밌습니다. 그렇기에 이번 프로젝트를 통해 많은 것을 배운 것처럼 리팩토링과 마이그레이션을 하면서도 많은 것을 배울 거라는 기대를 가지고 있습니다.
프로젝트는 끝이지만, 나만의 프로젝트는 다시 시작인 걸로~,~
23.12.10 ~ 24.04.04 학수고대 프로젝트 끝!
'회고 및 기록' 카테고리의 다른 글
| [회고] 2024년을 돌아보며 (1) | 2025.01.01 |
|---|