과제 체크포인트
jungwoo0203.github.io/front_6th_chapter2-3/
기본과제
목표 : 전역상태관리를 이용한 적절한 분리와 계층에 대한 이해를 통한 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가 정상적으로 작동하는가?
최종과제
- 폴더구조와 나의 멘탈모데일이 일치하나요?
- 다른 사람이 봐도 이해하기 쉬운 구조인가요?
과제 셀프회고
이번 과제를 통해 이전에 비해 새롭게 알게 된 점이 있다면 적어주세요.
- FSD (Feature-Sliced Design) 을 실제 프로젝트에 적용해 보니 “도메인 첫 분리 → 역할 분리”의 흐름이 훨씬 자연스럽다는 것을 체감했습니다.
- TanStack Query가 useQuery / useMutation 만으로 캐싱·리프레시·낙관적 업데이트를 모두 해결해 줘서, 서버 상태 관리를 위한 로직이 얼마나 줄어드는지를 몸소 느꼈습니다.
본인이 과제를 하면서 가장 애쓰려고 노력했던 부분은 무엇인가요?
- “클라이언트 UI 상태(Zustand) vs 서버 원본 상태(React Query)”를 명확히 분리해서 의도치 않은 데이터 중복을 만들지 않도록 설계했습니다.
- 폴더 이동과 별칭 변경이 많았는데, 기존 import 경로를 최대한 자동화(검색·일괄 치환)하면서도 각 단계별 커밋을 작게 유지하려고 신경 썼습니다.
- 위젯 단위로 UI를 쪼개고, 페이지는 “배치용”으로만 남기는 단일 책임 원칙을 끝까지 지키려 노력했습니다.
아직은 막연하다거나 더 고민이 필요한 부분을 적어주세요.
- 기능이 많아졌을 때 modules 내부 서브 레이어(ui/api/hooks 등) 명명법을 더 세분화할지, 아니면 컨벤션을 단순화할지 고민이 남습니다.
이번에 배운 내용 중을 통해 앞으로 개발에 어떻게 적용해보고 싶은지 적어주세요.
챕터 셀프회고
to be continued..
클린코드와 아키테쳑 챕터 함께 하느라 고생 많으셨습니다! 지난 3주간의 여정을 돌이켜 볼 수 있도록 준비해보았습니다. 아래에 적힌 질문들은 추억(?)을 회상할 수 있도록 도와주려고 만든 질문이며, 꼭 질문에 대한 대답이 아니어도 좋으니 내가 느꼈던 인사이트들을 자유롭게 적어주세요.
클린코드: 읽기 좋고 유지보수하기 좋은 코드 만들기
- 더티코드를 접했을 때 어떤 기분이었나요? ^^; 클린코드의 중요성, 읽기 좋은 코드란 무엇인지, 유지보수하기 쉬운 코드란 무엇인지에 대한 생각을 공유해주세요
결합도 낮추기: 디자인 패턴, 순수함수, 컴포넌트 분리, 전역상태 관리
- 거대한 단일 컴포넌트를 봤을때의 느낌! 처음엔 막막했던 상태관리, 디자인 패턴이라는 말이 어렵게만 느껴졌던 시절, 순수함수로 분리하면서 "아하!"했던 순간, 컴포넌트가 독립적이 되어가는 과정에서의 깨달음을 들려주세요
응집도 높이기: 서버상태관리, 폴더 구조
- "이 코드는 대체 어디에 둬야 하지?"라고 고민했던 시간, FSD를 적용해보면서의 느낌, 나만의 구조를 만들어가는 과정, TanStack Query로 서버 상태를 분리하면서 느낀 해방감(?)등을 공유해주세요
리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문
- 대규모 프로젝트에서 Query 캐시 키를 어떻게 체계적으로 관리하시는지?
- 디자인 시스템을 별도 패키지로 뺄 때 파일/버전 구조 팁이 있다면?
- FSD 쓰실 때 “이건 공통인가? 기능 폴더인가?” 경계 기준을 어떻게 정하시는지 듣고 싶어요.
과제 피드백
정우님 고생하셨습니다. 체크리스트를 모두 채워주시려고 노력했지만, 적절하게 나눠주셨다고 보기에는 어려운것 같아요. 모두 한 곳에 상태가 모여있어서요 ㅠㅠ 이 부분에 대해서는 조금 더 고민을 해보고 다른 분들 코드를 참고해보셔도 좋을 것 같아요! 아쉽지만 체크리스트를 모두 완성했다고 보지 못할것 같아 통과하지 않은 것으로 처리하겠습니다.
대규모 프로젝트에서 Query 캐시 키를 어떻게 체계적으로 관리하시는지?
지금의 키 관리 방식도 좋고 라이브러리를 사용하는 것도 좋을 것 같아요. 리스트와 디테일을 계층으로 구조화해서 무효화 할때 함께 처리할 수 있는 구조를 늘 염두해서 작성하면 좋을것 같아요!
디자인 시스템을 별도 패키지로 뺄 때 파일/버전 구조 팁이 있다면?
요거는 따로 뭔가 과제와 직접적으로 연결이 되는 질문은 아닌것 같은데요! 버전은 가능하다면 semver를 따르도록 하는게 이상적인것 같고, 파일 관련되서는 각각 컴포넌트를 구성하시는 것과 크게 다르지는 않을것 같아요. 대신 디자인 시스템이니까 외부에서 사용할 수 있는 API 인터페이스를 늘 고려해서 작성해야 한다 라는게 중요하지 않을까! 이 관점에서 요즘 radix ui나 shadcn같은 개념이 많이 인기가 있으니 이것도 참고해봐도 좋겠네요!
FSD 쓰실 때 “이건 공통인가? 기능 폴더인가?” 경계 기준을 어떻게 정하시는지 듣고 싶어요.
이 부분은 미리 예측을 하고 처리를 하는것도 좋지만, 작성을 하고 중복되는 것이 관찰될 때 옮기는게 가장 좋은 방식이에요. 중복해서 사용할것이라고 예측을 하고 분리했는데도, 사용성이 달라져 따로 다시 작성하는 경우들도 많거든요. 비슷한 구조가 여러번 등장하게 되면 순수함수로 분리해보고 비즈니스 로직에 있어서 만약 여러번 등장하게 된다면, 같은 이유로 수정을 하게 되는지 검토한 다음 공통 함수로 분리하면 좋을 것 같아요!
고생하셨고 다음주 테스트 과제에서 인사드리겠습니다. 화이팅!