[회고] 오롯이 혼자서 커뮤니티 만들어 본 후기

😚 프로젝트 소개!

 

테니스 커뮤니티 "Tenning"

 

테니스가 취미인 내가 직접 만들어본 테니스 커뮤니티

다양한 게시판으로 테니스인들이 소통할 수 있는 공간을 만들었다!

 

로그인 후 글쓰기, 댓글, 북마크 기능을 사용할 수 있으며

마이페이지를 통해 정보수정과 활동 내역 모아보기가 가능하다

 

✨ 개발 계기

프로젝트를 만들게 된 계기는 내 진짜 실력에 대한 불안감이 들었기 때문이다.

누군가의 도움없이 혼자서 고민하고 배우는 과정이었기에 잘 하고 있는 건지에 대한 의구심이 들었다.

 

기여도 100%의 서비스를 만들 수 있게 된다면 서비스 개발과정 전체의 흐름을 알면서 얻는 것이 많지 않을까? 그래서 불안을 좀 잠재울 수 있지 않을까? 싶은 마음에 시작하게 되었다.

 

 

🙄 기술 선택에 대한 고민

우선 CSR을 선택할 지 SSR을 선택할 지 고민을 했었다.

SSR의 초기 구동 속도가 빠르다는 점이 매력적이었고, 한번도 사용해본 적 없었기에 사용해보고 싶단 욕심이 생겼다. 하지만 프로젝트 주제 특성상 사용자와 상호작용이 많아 TTV와 TTI 사이 간극이 치명적이라는 점과 SSR의 장점인 검색엔진 최적화가 이번 프로젝트에서는 굳이 필요하지 않겠다는 판단을 내려 CSR 방식을 선택하게 되었다.

 

어떤 DB를 사용해야 할 지도 고민이 되었다.

기여도 100%라는 목적에 걸맞게 서버부터 직접 만들고 싶은 마음이 있었으나, 거의 경험해본 적 없는 백엔드를 무턱대고 시작했다가는 프론트엔드보다 더 시간을 많이 쓰게 되겠구나 싶은 우려가 생겼다.

그래서 백엔드 인프라를 지원하는 파이어베이스 플랫폼을 사용하기로 결정하였다.

rules를 설정하고 어렵지 않은 쿼리문을 통해 비교적 간단히 사용할 수 있었다.

 

+ 디자인에 대한 고민도 잠깐 했었지만 최대한 UX를 생각하면서 깔끔하게 가는 것으로 결정했다.

 

 

😀 개발 스탓뚜

간략하게 와이어프레임을 생성하고 개발에 들어갔다. KPT에 따라 그 과정을 되새겨보려 한다.

 

마주한 수많은 이슈들이 있었는데 시간이 지나고 회고를 작성하려 하다 보니 명확하게 기억이 안 나는 것이 많다..😭

꼭 그때 그때 기록하는 습관을 들이겠다고 또 다짐..

👍🏻 Keep : 프로젝트 중 잘한 점 / 좋았던 점

⭐⭐⭐어떤 고난에도 포기는 생각도 안 해본 점

가장 칭찬할 점!! 한순간도 포기를 생각한 적 없는 점을 스스로 가장 칭찬한다.

나를 죽이지 못한 고통은 나를 성장시킬 뿐이라고 했던가..? 상당히 많은 고난이 있었지만 오히려 오기로 더 덤벼들게 되었다.

완성시키고 정말 마음 속으로 눈물 한방울 흘려버림...

 

 

react hook form을 활용한 효율적인 input 관리

게시판 글쓰기 기능 특성상 꽤 많은 input이 있었다. 하나의 input에 하나의 state가 할당되는데 이걸 각각 다 관리하기에는 효율적이지 못하다는 생각을 했다.

 

react-hook-form을 통해서 이를 쉽게 개선할 수 있었다.

뿐만 아니라 이미지나 카테고리 같은 비정형 타입의 input에도 usecontroller 훅을 사용하여 한번에 처리할 수 있었다. 

 

 

성능 최적화로 lighthouse 개선

성능 최적화는 처음 진행해본 것인데 결과가 꽤 괜찮게 나와 뿌듯했던 기억이 있다.

 

 

로딩 성능과 렌더링 성능 저하에 원인이 되는 요소를 찾아 제거하는 과정을 거쳤다.

1. 큰 번들 사이즈로 인한 로딩 성능 저하가 발생하는 것 같아 코드 분할과 개별 react-icons 파일 사용으로 개선하였다.

2. 레이아웃 쉬프트로 인한 렌더링 성능 저하는 skeleton UI로 개선하였다.
3. 추가적으로 외부 리소스 preconnect로 리소스 로드 시간을 축소하였다.

 

그 결과 lighthouse 퍼포먼스 점수가 42점에서 97점으로 향상된 것을 볼 수 있었다! 자세한 과정은 이쪽에!

 

 

반응형 구현

기존에 구현했었던 반응형은 화면 크기에 따라 단순히 레이아웃을 조정하는 정도였다.

이번에는 조금 더 UX를 향상시키기 위하여 모바일 환경을 위한 컴포넌트를 별도 생성하여 미디어 쿼리 값에 따라 컴포넌트가 조건부노출이 될 수 있도록 구현하였다.

 

예를 들어

햄버거 버튼으로 만든 반응형 애니메이션 메뉴라던가

검색어 입력창 확대축소 버튼이라던가

확실히 UX가 좋아진 것 같아 만족하였다.

 

 

북마크 액션에 대한 optimistic update으로 사용성 개선

북마크를 누르면 서버 요청에 의해서 딜레이가 발생해 사용성이 떨어지는 문제를 발견하였다.

 

 이를 개선하기 위해 예측결과를 미리 UI에 반영하는 optimistic update를 도입하게 되었다

useState를 사용하여 구현하였는데,

state에 북마크 선택 유무 값을 받아둔 뒤 북마크를 눌렀을 때 서버 응답 전에 미리 state값이 변경되어 즉각적인 피드백이 가능하도록 하였다.

 

 

반복되는 로직 분리

드롭다운 기능을 분리하여 페이지 여러곳에서 편리하게 쓰는 등 로직 분리로 재사용성을 높였다.

 

👎🏻 Problem : 프로젝트 중 어려움 / 아쉬움

혼자여서 무계획적으로 진행된 개발

개발에 계획이 크게 존재하지 않았다. 큰 덩어리의 계획은 있어도 작은 단위의 계획은 세우지 못해 진행 당시 개발 흐름이 혼란스러웠던 것 같다.

프로젝트 설계 자체도 진행 중 계속 즉흥적으로 추가하니 명확한 프로세스가 없다는 것에 아쉬움이 남는다.

 

 

테스트의 부재

그렇게 큰 서비스가 아니라고 생각하였기에 테스트의 필요성을 크게 느끼지 못했다.

내가 인간 테스트기가 되어 기능 하나하나 확인하겠다는 그런 마음이었달까..?

 

하지만 진행할수록 뭔가 섣부르게 수정하기가 겁이 났다. 작은 수정을 거쳤다가 미처 예상치 못한 버그가 발생하게 될 수 있고, 그 버그를 나중에 발견하게 되면 어디서부터 디버깅을 해야 하는 건지 예측할 수가 없기 때문이다.

 

그래서 테스트의 필요성을 크게 느끼게 되었고, 애초에 도입하지 않은 것에 후회가 남았다.

 

미숙한 사용자 DB 설계

DB 설계는 사실상 처음이었다. 설계된 DB를 보고 api 요청을 한 적은 있어도 백지에서 DB를 생성하려니 애를 먹었던 것 같다.

그래서 효율을 크게 따지지 못했고, 어떤 설계가 api 요청 시 비용이 덜 드는 지에 대해서 크게 생각하지 못했다. 

프론트엔드지만 기본적인 DB 설계에 대해서는 알고 있는 게 좋겠다는 것을 뼈저리게 느꼈다.

 

 

부족했던 에러처리

서버 데이터를 받아올 때 에러처리가 미흡한 것 같다.

try-catch문을 써서 모두 동일하게 에러 처리를 하고 있는데, 에러 코드 별 에러 처리를 다르게 해야 하지 않나 싶다.

 

💪🏻 Try : 해결 방법 / 해결되지 않은 사항에 대한 피드백

Problem 작성을 통해 어떤 부분이 미숙했는 지에 대해 생각해보게 되었고,

다음 프로젝트를 진행하게 된다면 이번에 신경쓰지 못한 에러 처리와 테스트를 경험해보고 싶단 생각을 했다.

 

 

 

( KPT 이렇게 작성하는 거... 맞나? )

 

📌 후기와 느낀점

이가 없으면 잇몸으로라도! 🦷🦷🦷 "안 된다"는 말은 하지 않는 걸로

진행 중 파이어베이스 api 함수의 한계로 인하여 구현하고자 했던 기능에 어려움을 겪은 적이 있다. 

정말 불가능이 아닐까, 이 기능은 뺄까 싶을만큼 해결 방법이 보이지 않았는데,

생각을 조금 고쳐 api 함수의 한계를 겪지 않게 db 테이블에 컬럼을 추가해서 해결할 수 있게 되었다.

정말 오래 고민했는데 생각보다 간단하게 해결되어버리니 스스로 허무했던 경험..이었다

 

그러면서도 이게 개발자에게 강조되는 문제해결능력인가? 싶었다. 문제를 더 넓게 바라보는 시선이 중요한 것 같았다.

 

베이스는 무조건 공식문서다

새로운 기술을 사용할 때 무조건 공식문서를 먼저 본 뒤 공식문서 기반으로 다른 자료를 참고하여야 한다.

블로그 글에는 명확하지 않은 개념이 종종 있고,

글 작성 시간 때와는 다르게 업데이트 된 기술에 따라 예상치 못한 오류가 발생하기도 한다.

( 이걸 어떻게 알았냐면... 나도 알고 싶지 않았다...😭😭😭 )

 

성취감에 중독되어버렸다. 최고의 도파민 자극제

이슈를 부딪혔을 때나 기능 구현에 어려움을 겪었을 때 쉽게 해결되지 않는 경우가 있다. 그럴 때 고통받곤 하지만 결국 해결하게 되면 그 성취감은 겪었던 고통의 3배는 된다.

정말 중독적이다....

이것 때문에 개발을 못 끊어 진짜

 

큰 숲을 보는 방법을 조금은 알아버린 것 같다. 하지만 나무도 놓치면 안된다는 사실

프로젝트를 진행 하다보면 시간에 쫓겨 바쁘게 기능 구현에만 집중하는 나를 발견하곤 한다.

이번 프로젝트는 혼자서 차근차근 조급하지 않게 해보자는 다짐으로 시작했었기에, 너무 시간에 쫓기지 않으려 애썼다.

성능도 신경 쓸 수 있게 되었고,

컴포넌트 하나를 만들 때도 관심사의 분리가 잘 지켜졌는 지, 재사용성에 따라 적절히 분리 되었는 지에 대해 생각할 수 있게 되었다. 조금 더 서비스 전체를 보게 된 기분이다..!

한단계 더 성장해버린 그런 느낌,,?!