[3팀 주민수] Chapter 3-3 기능 중심 아키텍처와 프로젝트 폴더 구조

[Thomas97-J]

과제 체크포인트

기본과제

목표 : 전역상태관리를 이용한 적절한 분리와 계층에 대한 이해를 통한 FSD 폴더 구조 적용하기

• 전역상태관리를 사용해서 상태를 분리하고 관리하는 방법에 대한 이해
• Context API, Jotai, Zustand 등 상태관리 라이브러리 사용하기
• FSD(Feature-Sliced Design)에 대한 이해
• FSD를 통한 관심사의 분리에 대한 이해
• 단일책임과 역할이란 무엇인가?
• 관심사를 하나만 가지고 있는가?
• 어디에 무엇을 넣어야 하는가?

체크포인트

• 전역상태관리를 사용해서 상태를 분리하고 관리했나요?
• Props Drilling을 최소화했나요?
• shared 공통 컴포넌트를 분리했나요?
• shared 공통 로직을 분리했나요?
• entities를 중심으로 type을 정의하고 model을 분리했나요?
• entities를 중심으로 ui를 분리했나요?
• entities를 중심으로 api를 분리했나요?
• feature를 중심으로 사용자행동(이벤트 처리)를 분리했나요?
• feature를 중심으로 ui를 분리했나요?
• feature를 중심으로 api를 분리했나요?
• widget을 중심으로 데이터를 재사용가능한 형태로 분리했나요?

심화과제

목표: 서버상태관리 도구인 TanstackQuery를 이용하여 비동기코드를 선언적인 함수형 프로그래밍으로 작성하기

• TanstackQuery의 사용법에 대한 이해
• TanstackQuery를 이용한 비동기 코드 작성에 대한 이해
• 비동기 코드를 선언적인 함수형 프로그래밍으로 작성하는 방법에 대한 이해

체크포인트

• 모든 API 호출이 TanStack Query의 useQuery와 useMutation으로 대체되었는가?
• 쿼리 키가 적절히 설정되었는가?
• fetch와 useState가 아닌 선언적인 함수형 프로그래밍이 적절히 적용되었는가?
• 캐싱과 리프레시 전략이 올바르게 구현되었는가?
• 낙관적인 업데이트가 적용되었는가?
• 에러 핸들링이 적절히 구현되었는가?
• 서버 상태와 클라이언트 상태가 명확히 분리되었는가?
• 코드가 간결하고 유지보수가 용이한 구조로 작성되었는가?
• TanStack Query의 Devtools가 정상적으로 작동하는가?

최종과제

• 폴더구조와 나의 멘탈모데일이 일치하나요?
• 다른 사람이 봐도 이해하기 쉬운 구조인가요?

과제 셀프회고

배포주소 : https://thomas97-j.github.io/front_7th_chapter3-3/

이번 과제를 진행한 흐름대로 회고를 작성해보겠다.

과제를 시작할 때, 실제 내 프로덕트에 FSD를 적용한다고 생각하고, 우선 FSD를 제외한 로직 정리를 먼저 진행했다. 제일먼저 타입 세팅을 진행하고, 컴포넌트와 api를 분리해 지금 내가 자주 사용하는 폴더 구조대로 정리해 넣었다. 마지막으로 전역상태를 추가해 폴더간 자유로운 이동을 위해 컴포넌트간의 결합도를 낮춘 다음 FSD 도입을 시작했다.

첫번째로 정리한 것은 api들이었다. 엔티티/도메인 안으로 api들을 분리하며 지금 이 api는 피쳐로 가는게 맞겠는데? 싶은 api들이 있었지만 우선 한번에 완벽하게 정리하는 것이 아니라, 느낌 가는대로 편하게 정리한 다음 여러번 다시 정리하는것을 이번 과제의 목표로 삼았다. 처음부터 완벽하게 정리하려고 하면, 아무것도 못하고 그만둔다는 것을 이미 많이 겪어 보았기 때문이었다.

두번째로 정리한 것은 컴포넌트들이었다. 이미 components 폴더에 도메인별로 정리가 되어 있어 간단하게 옮길 수 있을 것 같았지만, 막상 이동을 하려고 보니 이게 위젯인지, 피쳐인지가 확신이 들지 않았다. 우선은 위젯으로 분류하고, 아직 덜 쪼개진 컴포넌트들은 내부 컴포넌트들을 분리해서 피쳐로 이동하면 되지 않을까? 하는 생각으로 대부분 위젯으로 옮겼다. 그랬더니 이제 Footer랑 Header가 문제였다.
현재 푸터와 헤더는 App.tsx 안에서 페이지보다 위에서 컴포넌트들을 감싼다. 원래라면 라우터가 들어갈 위치보다 위에서 사용되고 있다면, 이것은 App 폴더 하위에서 관리되어야 하는게 아닐까? 아니면 그냥 위젯으로 관리해야 할까? 나는 고민 끝에 팀원들에게 이를 투표에 부치고 팀원들의 결정대로 위젯으로 관리하기로 했다. 폴더구조는 설명을 듣고 이해가 되는 것 보다는 더 많은 이들의 직관대로 관리되는 것이 옳다고 생각하기 때문이었다.

그다음으로 고민하게 된 부분은 store를 어떻게 나누는가 였다. 처음에는 스토어를 엔티티에 보관해야 겠다는 생각이 들었다. 엔티티 하단에 적절하게 배치하는 것 까지는 간단한 일이었지만, 전역 상태들을 각 도메인/모델에 하나씩 쪼개서 넣는 일이 효율적인 정리라는 생각은 들지 않았다. 팀원분들께 물어봐도 다들 나와 동일하게 엔티티 하단에 하나씩 쪼개어 넣었다는 답변뿐이었다. 나는 고민 끝에 엔티티 별로 아톰들을 쪼개어 보관하기로 결정했다. 애초에 하나의 폴더에 모아서 정리하고 싶었으면 FSD를 사용하지 않았어야 했다는게 첫번째 이유였고, 이렇게 나누는 것이 명확한 경계를 구분하고 의존성 추적을 명확하게 해준다는 대현님의 클로드의 이야기를 믿어보기로 한 것이 두번째 이유였다. 아직은 눈에 익지 않아서 장점이 느껴지지 않는 것이 아닐까? 그런 마음으로 코드를 나누었다.
그렇게 다 나누고 나니 이번에는 스토어가 과연 엔티티에 있는게 맞는가? 하는 의문이 들었다. 지금의 엔티티 아래 스토어는 api에서 받은 값을 그대로 저장하기 때문에 엔티티 하단으로 위치시킨 것인데, 엔티티를 도메인 데이터 중심으로 간단하게 관리하려면 상태는 최소한 피쳐 레이어로 올라가야 할 것 같았다. 그렇게 피쳐로 옮기려는 준비를 하던 중 뭔가 이상한 기분이 들었다.

나는 원래 api에서 넘어온 값을 그대로 전역상태에 담는 패턴을 좋아하지 않는다. 때문에 리액트 쿼리를 사용하기 시작한 이후에는 이런 패턴을 지양해 왔다. 그런데 이번 과제에서는 탄스택 쿼리를 심화과제로 요구해서, 우선 jotai에 전역상태를 다 담고 리팩토링하기로 마음먹고 진행했기 때문에, 이런 서버 상태들 까지 전역상태에 담기게 된 것이었다. 그렇다면 탄스택 쿼리를 적용한다면 엔티티 아래 넣어둔 스토어들을 모두 대체할 수 있지 않을까? 엔티티 아래 전역변수들이 사용되는것을 확인해본 결과 탄스택 쿼리로 모두 대체 가능하다는 결론이 나왔다. 그래서 조금 이르게 탄스택 쿼리를 도입해서 엔티티 아래 스토어들을 모두 삭제하고 피쳐 아래 탄스택 쿼리 훅을 배치했다.

이러고 나니 얼추 FSD의 폴더 구조를 따라하는 정도까지는 진행할 수 있었다. 시간이 부족해 아직 컴포넌트 리팩토링이 덜 되었지만 여기서 과제를 마무리 지었다.

아직은 막연하다거나 더 고민이 필요한 부분을 적어주세요.

회사 코드에 요즘 FSD를 적용하려는 시도를 하고 있습니다. 그러면서 애초에 컴포넌트가 잘 분리되어 있지 않으면 FSD를 적용하는것이 쉽지 않아진다는 것을 느낄 수 있었습니다. 또 이렇게 FSD가 적용된 프로젝트가 내 멘탈 모델과 일치하나 생각을 해 보았을때, 아직까지는 그렇게 와닿지는 않는다는 생각이 듭니다. 더 많은 시간을 투자해야 할 것 같습니다.

이번에 배운 내용 중을 통해 앞으로 개발에 어떻게 적용해보고 싶은지 적어주세요.

FSD를 제대로 적용해 놓으면, 폴더 구조를 크게 어지르기 쉽지 않겠다는 생각이 들었습니다. 명확한 근거가 공유된다면 팀 내 폴더 정리 스타일을 정말 하나로 일원화 할 수 있겠다는 생각이 들어, 요즘 추가되는 신규 프로젝트에는 FSD를 넣어보고 있습니다.

챕터 셀프회고

클린코드와 아키테쳑 챕터 함께 하느라 고생 많으셨습니다!
지난 3주간의 여정을 돌이켜 볼 수 있도록 준비해보았습니다.
아래에 적힌 질문들은 추억(?)을 회상할 수 있도록 도와주려고 만든 질문이며, 꼭 질문에 대한 대답이 아니어도 좋으니 내가 느꼈던 인사이트들을 자유롭게 적어주세요.

클린코드: 읽기 좋고 유지보수하기 좋은 코드 만들기

• 더티코드를 접했을 때 어떤 기분이었나요? ^^; 클린코드의 중요성, 읽기 좋은 코드란 무엇인지, 유지보수하기 쉬운 코드란 무엇인지에 대한 생각을 공유해주세요

사실 이전 회사에서 이것보다도 심하게 더러운 코드를 많이 보았기 때문에, 그냥 이정도인가... 싶었습니다 ㅋㅋㅋㅋ
개발 일을 하면서 어떤 경우에 유지보수가 어려웠는지를 생각해 보면 보통 로직이 하고자 하는 바가 명확하게 느껴지지 않는 로직을 수정해야 할 때 인것 같습니다. 이경우에는 이름이 제대로 지어져 있지 않고, 로직이 너무 길고 복잡하고, 심지어는 가끔은 로직의 일부가 멀리서 알 수 없는 경로로 props를 타고 온다던지, 하는 경우들이 해당하는 것 같습니다. 사실 처음 제공된 코드는 복잡하기는 했으나 로직이 한데 뭉쳐있어 그렇게까지 이해하기 어렵다는 생각은 들지 않았습니다.

결합도 낮추기: 디자인 패턴, 순수함수, 컴포넌트 분리, 전역상태 관리

• 거대한 단일 컴포넌트를 봤을때의 느낌! 처음엔 막막했던 상태관리, 디자인 패턴이라는 말이 어렵게만 느껴졌던 시절, 순수함수로 분리하면서 "아하!"했던 순간, 컴포넌트가 독립적이 되어가는 과정에서의 깨달음을 들려주세요

사실 프론트엔드 개발자로서 백엔드 개발자들과 이야기를 할 때 디자인 패턴에 대한 이야기가 나오면 그다지 할 말이 없었습니다. 이번 세션들을 통해 어느정도 할 이야기와 근거를 마련할 수 있게 된 것이 내심 기분이 좋습니다.
컴포넌트가 독립적이 되어가는 과정의 깨달음에 대해 이야기하자면, 원래 알고 있던 기술들이 왜 핗요했고, 이것이 정확히 어떤 문제들을 해결하는지 다시 돌아볼 수 있는 기회가 되었다고 생각합니다. 내가 사용하는 기술을 왜 사용하는지 설명할 수 있는 개발자가 되어야겠다는 생각 또한 들었습니다.

응집도 높이기: 서버상태관리, 폴더 구조

• "이 코드는 대체 어디에 둬야 하지?"라고 고민했던 시간, FSD를 적용해보면서의 느낌, 나만의 구조를 만들어가는 과정, TanStack Query로 서버 상태를 분리하면서 느낀 해방감(?)등을 공유해주세요

탄스택 쿼리를 사용하지 않다가, 사용하게 되면 아. 이래서 이걸 쓰지 참 싶을 때가 많은 것 같습니다. 탄스택 쿼리 하나만으로 자연스럽고 편하게 api 훅을 생성할 수 있게 되고, 전역 상태의 남용을 줄일 수 있게 되고, 캐싱, 리패치 등의 로직을 간단하게 해결할 수 있게 됩니다. 탄스택이 점점 손대는 범위가 넓어지는 게 이해가 될 정도의 해방감입니다.
FSD를 적용하면서 느낀 점은 아주 라벨링이 잘 되어있는 작은 서랍에 부품들을 정리하는 듯한 기분이 들었습니다. 그려먼서 부품의 크기가 크고 형태가 지저분하다면, 서랍에 넣기 위해 부품을 다듬어야 하는 과정이 필요하다는 것 또한 느낄 수 있었습니다. 처음에는 FSD는 그냥 괜히 일을 복잡하게 만드는 폴더 구조라고 생각했는데, 장기적으로 프로젝트를 깔끔하게 유지할 수 있는 방법이 될 수 있겠다는 생각을 하게 되었습니다.