간략 소개
[구성]
FE 2, BE 1 상태로 시작했으며 추후 BE 담당분이 빠지게 되면서 풀스택으로 진행.
[스택]
FE : TypeScript, React, React-Redux, RTK, Tailwind, Mui
BE : Nodejs
[주제 및 개발 동기]
-자영업자들을 위한 커뮤니티가 대부분 네이버 카페에 형성되어있는 것을 확인, 하나의 독립된 자영업자들을 위한 사이트를 만들고자 하였음.
[구현 기능]
-
게시판 및 게시글 ui 전반
-재활용이 가능한 컴포넌트를 구성하기 위해 넘겨주는 props 값에 따라 category를 손쉽게 추가하고 수정 가능하도록 구현.
-유저의 기호에 맞는 topic 값에 해당하는 게시글만을 불러오는 기능 구현. -
페이지네이션
-일반 페이지네이션 : 기본 페지이네이션 방식 사용.
-무한 스크롤 : 홈 화면에서 카테고리 구분 없이 게시글들을 한 눈에 확인하도록 하기 위해 구현. 유저들이 사용하는 웹 사이트의 트레픽(속된 말로 글 리젠률)을 가시적으로 체감할 수 있어야 커뮤니티에 발길을 끊지 않을 거라 생각했기 때문. -
좋아요/싫어요
-서버에 저장된 유저의 oid 값을 배열에 저장, 좋아요 및 싫어요 수를 계산하여 기능 중복 사용 방지. -
댓글/답글
-로그인 중인 유저 정보가 댓글 및 답글 작성자와 같은 oid를 가질 경우 UI에 강조표시하여 유저가 쉽게 자신의 댓글/답글을 찾도록 구현. -
알림
-유저 활동에 다른 유저가 남긴 반응을 알림으로 전송.
-읽음 처리, 삭제 처리 기능 구현.
후기
[팀 프로젝트 해체 후 개선한 부분]
-
컴포넌트 개선 : UI와 Logic의 분리.
▷ 개선 사유
-UI와 Logic이 분리되어 있지 않아 잦은 랜더링 발생, 코드의 복잡도를 유발하여 개선 결심.
▷ 결과
-코드를 component(UI), container(Logic)로 분리. 가독성 및 유지보수 용이성이 개선 되었고 독립적으로 테스트가 가능했음. 또한 로직의 변경이 UI의 리렌더링을 불필요하게 유발하지 않았음.
-그러나 UI와 Logic이 완전 분리가 불가능한 컴포넌트도 존재하여 이들의 경우는 빈번한 수정이 불필요한 Logic이 들어가도록 코드를 개선함. -
구조 개선 : Feature-Based Structure 채택.
▷ 개선 사유
-명확하지 않은 구조로 인해 코드 참조시 기능 구현 시간이 길어지는 DX적 불편함을 겪어 개선 결심.
▷ 결과
-기능별로 component, container, hooks, redux를 분리함으로써 구조를 쉽게 파악하게 되어 작업 시간이 줄일 수 있었음. -
로그인 상태 개선 : 상태 관리 방식 Redux로 변경.
▷ 개선 사유
-팀원이 localStorage에 저장된 토큰 값을 통해 refresh token이나 만료 시간 없이 유저 로그인 정보를 다루는 것을 확인, Redux로 개편 결심.
▷ 결과
-로그인 상태 관리 방식을 Redux로 개편, 상태 관리 방법에 통일성 부여하여 Redux를 통한 유지 보수가 더욱 편해짐.
[개인으로서의 성장/깨달음]
1. 개발자에게 있어서 정말 중요한 것은 경험치를 쌓는 것이다.
이번 프로젝트에서 사용한 Redux 처럼 요구되는 러닝 커브가 높은 기술을 사용할 때 경험치를 쌓는 것이 중요하다는 것을 느꼈다.
사용하는 법을 익히니 구조가 눈에 보였고 구조가 눈에 보이고 나니 어떤 부분에서 문제가 발생하는지도 보였기 때문이다.
내가 실제로 저질렀던 실수는 asyncThunk함수를 작성하고 dispatch 사용 없이 axios로 함수를 직접 호출하는 실수였다.
기능은 작동하는데 왜 상태 관리가 파악이 안 되지? Redux Dev tool에 왜 잡히지 않는 거야? 하면서 시간을 보냈던 것이 아직도 생각난다.
2. 고민이 길어진다고 항상 좋은 코드가 나오지는 않는다. 공식 문서와 레퍼런스를 찾아보아야 한다.
기능을 구현할 때 고민을 하는 것은 좋은 습관이다. 그러나 고민을 통해 문제가 풀리지 않을 때는 개발자 생태계에 존재하는 다양한 레퍼런스를 찾아보는 것과 공식 문서를 확인하는 것이 중요하다.
공식 문서를 찾아보면 내가 구현하려는 방식이 이미 내장된 기능인 경우도 있고 기술적인 이해가 부족해 발생한 문제라면 이 부분을 고칠 기회가 생긴다.
그리고 레퍼런스를 찾아봄으로써 다른 사람은 어떤 방식으로 풀어냈는지, 왜 그런 방식이 유효했고 나는 생각해보지 못했는지 비교 분석하는 기회를 가질 수 있기 때문이다.
따라서 고민이 길어지고 쳇바퀴를 도는 것만 같다는 느낌이 들 때면 고민을 잠시 멈추고 공식문서와 레퍼런스를 꼭 봐야 한다.
3. 레퍼런스는 어디까지나 도구로 남아야 한다.
이 항목은 위 항목의 연장이라고도 볼 수 있다. 레퍼런스에 너무 의존해서는 안된다.
문제 해결 과정에서 openAI나 다른 블로그의 글을 가져와 사용하는 것은 당장 필요한 기능 구현에는 도움이 되곤 했다.
그러나 이런 식의 해결은 추후에 반드시 내 발목을 잡았다. 비슷한 문제 상황에서 내실이 다져지지 않았으니 또 다시 남의 코드를 복사하고 붙여 넣게 되었기 때문이다.
그래서 성장을 위해서는 도구를 사용하는 방법은 숙지하고 있으되 이에 휘둘리면 안 된다는 것을 배웠다.
고민이 필요한 순간에 고민 없이 적힌 코드는 절대로 내 코드가 아니다.
[팀원으로서의 성장/깨달음]
1. 마일스톤 설정과 팀원간 소통은 필수다.
명확한 목표와 기일을 설정하지 않아 하나의 기능을 개발하는데도 시간이 생각보다 오래 걸렸다.
팀원과 소통을 제대로 하지 않아 기본 기능이 구현되지 않았고 이는 팀원과의 갈등으로 이어지기도 했다.
2. 코드 컨벤션이 중요하다.
코드에 통일성이 없으니 전체적인 코드의 질이 떨어져 보였다.
특히나 팀원의 코드를 참고해 관련 기능을 개발해야 할 때 불필요하게 시간이 소요되곤 했다.
3. 제대로 된 설계와 문서화가 필요하다.
프로젝트 구조 설계를 제대로 하지 못해 '더 괜찮을 것 같은 구조'로 바꾸기를 반복했다.
그 결과 프로젝트 일정에 차질을 빚어 생각보다 더 오랜 시간을 할애해야만 했다.
문서화를 제대로 하지 못해 매번 팀원에게 질문을 던지거나 특정 코드를 반복적으로 확인하면서 맥락을 파악하는 일도 잦았다.
이는 개발 과정에서 큰 스트레스로 작용했다.
따라서 짜임새 있는 설계와 문서화, 즉 체계가 정말 중요하다는 것을 느꼈다.
4. 코드와 싸워야 하지 팀원과 싸우지 말아야 한다.
협업을 하다보면 스트레스가 쌓이기 마련인지라 팀원과 마찰을 빚는 경우도 생기곤한다.
그러나 팀원은 동료라는 사실을 잊지 말아야한다.
불편한 부분이 있다면 존중으로 대화를 나누고 내가 틀릴 수도 있다는 사실을 항상 염두에 두어야 한다.
내가 열심히 하는 만큼 혹은 그보다 더 팀원이 노력을 하고 있다는 것을 알아야 한다. 노력은 겉으로 드러나지 않는 성질도 가지고 있기 때문이다.
