https://jangrubin2.github.io/front_6th_chapter2-3/
과제 체크포인트
기본과제
목표 : 전역상태관리를 이용한 적절한 분리와 계층에 대한 이해를 통한 FSD 폴더 구조 적용하기
- 전역상태관리를 사용해서 상태를 분리하고 관리하는 방법에 대한 이해
- Context API, Jotai, Zustand 등 상태관리 라이브러리 사용하기
- FSD(Feature-Sliced Design)에 대한 이해
- FSD를 통한 관심사의 분리에 대한 이해
- 단일책임과 역할이란 무엇인가?
- 관심사를 하나만 가지고 있는가?
- 어디에 무엇을 넣어야 하는가?
체크포인트
- 전역상태관리를 사용해서 상태를 분리하고 관리했나요?
- Props Drilling을 최소화했나요?
→ zustand, jotai, tanstack-query로 props 넘김 거의 없음! - 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가 정상적으로 작동하는가?
최종과제
- 폴더구조와 나의 멘탈모델이 일치하나요?
- 다른 사람이 봐도 이해하기 쉬운 구조인가요?
과제 셀프회고
이번 과제를 통해 이전에 비해 새롭게 알게 된 점이 있다면 적어주세요.
- FSD 구조를 실제로 적용해보니까, 단순히 폴더만 나누는 게 아니라 “관심사”를 기준으로 코드를 분리하는 게 진짜 중요하다는 걸 느낌.
- TanStack Query를 쓰면 서버 상태랑 클라이언트 상태가 확실히 분리돼서, 코드가 훨씬 깔끔해진다는 걸 체감함.
- zustand, jotai, tanstack-query 각각의 장단점이 확실히 다르다는 것도 실전에서 느꼈음.
본인이 과제를 하면서 가장 애쓰려고 노력했던 부분은 무엇인가요?
- 상태를 어디에 두는 게 맞는지, 그리고 그걸 어떤 라이브러리로 관리할지 고민을 진짜 많이 했음.
- FSD 구조에 맞게 폴더를 나누고, 각 계층에 맞는 책임만 갖도록 신경 썼습니다.
- 기존 fetch 로직을 tanstack-query로 바꾸면서, 기존의 동작을 해치지 않으려고 시행착오도 많았습니다.
아직은 막연하다거나 더 고민이 필요한 부분을 적어주세요.
- entities/feature/widget 레이어를 실제로 언제, 어떻게 나누는 게 좋은지 아직은 좀 헷갈립니다.
- “이건 shared냐, feature냐, entity냐” 경계가 애매한 경우가 종종 있어서, 더 많은 실전 경험이 필요할 듯 합니다.
- 폴더 구조가 커질 때, 실제로 협업에서 어떻게 유지보수할지 더 고민해보고 싶음.
이번에 배운 내용 중을 통해 앞으로 개발에 어떻게 적용해보고 싶은지 적어주세요.
- 앞으로는 무조건 “관심사 분리”를 먼저 생각하고 폴더 구조를 짤 것 같음.
- 서버 상태는 tanstack-query, 클라이언트 상태는 jotai/ zustand로 명확히 분리해서 관리할 예정.
- 코드가 커질수록 FSD 구조의 힘이 더 커진다는 걸 느꼈으니, 실무에도 적극적으로 적용해볼 생각임.
챕터 셀프회고
클린코드와 아키텍처 챕터 함께 하느라 고생 많으셨습니다! 지난 3주간의 여정을 돌이켜 볼 수 있도록 준비해보았습니다. 아래에 적힌 질문들은 추억(?)을 회상할 수 있도록 도와주려고 만든 질문이며, 꼭 질문에 대한 대답이 아니어도 좋으니 내가 느꼈던 인사이트들을 자유롭게 적어주세요.
클린코드: 읽기 좋고 유지보수하기 좋은 코드 만들기
- 더티코드를 보면 “이걸 내가 고쳐야 하나…” 싶어서 한숨부터 나오는...?
- 클린코드는 결국 “내가 나중에 다시 봐도 이해할 수 있는 코드”라고 생각하게 됨.
- 유지보수하기 쉬운 코드는 결국 “관심사 분리”랑 “명확한 네이밍”에서 시작된다는 걸 다시 한 번 느끼게 됨
결합도 낮추기: 디자인 패턴, 순수함수, 컴포넌트 분리, 전역상태 관리
- 거대한 단일 컴포넌트는 진짜… 보기만 해도 머리 아픔.
- 상태관리 처음엔 어렵고, 디자인 패턴도 추상적으로만 느껴졌는데, 직접 분리해보니까 “아 이래서 하는구나!” 싶었습니다.
응집도 높이기: 서버상태관리, 폴더 구조
- FSD 적용하면서, 내 나름의 기준이 조금씩 생겼다.
- TanStack Query로 서버 상태를 분리하니까, 코드가 훨씬 명확해지고, 협업할 때도 훨씬 편할 것 같다는 생각이 듭니다.
리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문
- 실제 실무에서 FSD 구조를 적용할 때, 팀원들과의 합의나 기준을 어떻게 맞추는 게 좋을지 궁금합니다.
- entities/feature/widget 레이어의 경계가 애매할 때, 어떤 기준으로 결정하면 좋을까요?
- tanstack-query와 jotai/zustand를 같이 쓸 때, 상태의 소유권(서버/클라)을 더 명확하게 구분하는 팁이 있을까요?
과제 피드백
루빈님 고생하셨습니다. 체크리스트를 모두 채워주시려고 노력했지만, 적절하게 나눠주셨다고 보기에는 어려운것 같아요. shared에 대부분의 로직들이 분포되어있고, 전체적인 구조를 초반부터 다시 잡아야 할 것 같네요 ㅠㅠ 이 부분에 대해서는 조금 더 고민을 해보고 다른 분들 코드를 참고해보셔도 좋을 것 같아요! 아쉽지만 체크리스트를 모두 완성했다고 보지 못할것 같아 통과하지 않은 것으로 처리하겠습니다.
실제 실무에서 FSD 구조를 적용할 때, 팀원들과의 합의나 기준을 어떻게 맞추는 게 좋을지 궁금합니다. entities/feature/widget 레이어의 경계가 애매할 때, 어떤 기준으로 결정하면 좋을까요?
여기서 중요한건 분명하게 FSD는 각각 합의가 필요한 부분이 명확하게 있지만, 기초적인 구획은 명확하게 있다는거 같아요. FE관점에서 특히 리액트 관점에서 명확하게 구획을 잡을 수 있도록 가이드가 있고 어느정도 복잡한, 그리고 외부 라이브러리들을 사용하는 경우에 협의가 필요한 부분들이거든요. (폴더 구조라거나) FSD 가이드 문서에 일단 명확한 설명이 있으니 이 부분을 따르도록 노력하고 작은 단위부터 구획을 잡아가는게 저는 이 구조에서는 편한것 같더라구요. entity는 무엇이 될 수 있는가! 부터 다시 고민을 해보면 도움이 많이 될 것 같습니다.
tanstack-query와 jotai/zustand를 같이 쓸 때, 상태의 소유권(서버/클라)을 더 명확하게 구분하는 팁이 있을까요?
단순하게 '서버와 동기화할 필요가 있는가'를 기준으로 보면 될 것 같아요 ㅎㅎ 그러다 보면 네트워크 요청같은것들은 자연스럽게 서버 상태가 되고 서버는 제외하고 컴포넌트끼리 넘나드는 상태는 전역 상태에 두는거죠. 그럼 서버상태를 전역상태에 넣어두고 쓰면 되는거 아닌가 라고 생각할 수는 있지만, 이렇게 될 경우 동기화를 시켜야 하는 작업이 중복해서 드니 그런것들을 쉽게 해주는 기능들이 포함된게 탠스택 쿼리인것 같아요! 그런 관점에서 일단은 접근하면 좋지 않을까 싶습니다 ㅎㅎ
고생하셨고 다음주도 화이팅입니다!