[3팀 김효진] Chapter 2-3. 관심사 🧦분리와 폴더구조🦍

by hyojin-k2025. 8. 12.

https://hyojin-k.github.io/front_6th_chapter2-3/

과제 체크포인트

기본과제

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

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

체크포인트

심화과제

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

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

체크포인트

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

최종과제

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

과제 셀프회고

이번 과제를 통해 이전에 비해 새롭게 알게 된 점이 있다면 적어주세요.

FSD 이전에 역할로만 분리했던 폴더 구조를 FSD를 사용하여 각 계층이 어떤 역할을 가지고 있어야하는지에 대해 학습할 수 있었습니다. 다만, 그 계층 구분의 기준을 명확하게 잡기가 애매하다는 부분이 고민이 많이 되는 부분이었습니다. 사람마다 서로 묘하게 조금씩 다른 기준을 가지고 있다보니 갈팡질팡하는 경우도 많았고, 스스로 정한 기준도 과제를 진행하다보면서 흐트러지는 경우도 있었던 것 같습니다. 어느정도 정답이 정해져있는 듯 하면서 각자 다른 정답을 가지고 있을 수 있는 아키텍처라는 생각이 들었습니다. 그럼에도 불구하고 그 과정에서 고민할 수 있고 학습할 수 있는 경험이 된 것 같습니다.

본인이 과제를 하면서 가장 애쓰려고 노력했던 부분은 무엇인가요?

지금까지 클린코드 과제를 진행하면서 컴포넌트를 분리하는 방식은 큰 단위에서 작은 단위로 나누는 방식이었는데, 이 과정에서 느꼈던 불편함을 최소화하고자 이번에는 작은 단위에서 큰 단위로 분리하는 방향으로 진행해보려고했습니다. 이 과정에서 함께 계층 분리에 대한 고민을 많이 했습니다. 특히 entities와 features의 구분에 대한 고민이 많았습니다.

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

FSD 아키텍처를 사용해보긴 했지만 명확한 기준을 정하기도 힘들고, 그걸 유지하는 것도 쉽지않았습니다. 계층 분리에 대해서 정확하게 정립이 되지 않은 채로 과제를 진행하다보니 그런 고민이 더욱 깊었던 것 같습니다. 우선 이번 과제에서는 CRUD 중에서 단순 R 부분을 entities로 분리하고 C,U,D 부분을 features 로 분리하는 방법으로 진행했는데, 이 방식도 여러 방식 중에 제가 이해하기 가장 쉬운 방법을 택한 거라 좀 더 깊은 이해도가 있었다면 좀 더 세밀한 계층분리를 할 수 있지않았을까 싶습니다.

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

tanstack query를 사용하면서 쿼리 키를 관리하는 방법이 실무에서 사용하던 방식과 다른 방식을 사용해보았습니다. 기존에는 쿼리 키들 간의 변별력을 위해, 각 api의 url를 쿼리 키로 사용했었습니다. 이번 과제에서는 키들을 묶어서 관리하는 방법을 사용했는데, 이 방식이 한번에 관리하기에 효율적인 것 같아서 적용해보면 좋을 것 같습니다.

export const commentQueryKeys = {
  all: ["comments"] as const,
  lists: () => [...commentQueryKeys.all, "list"] as const,
  list: (postId: number) => [...commentQueryKeys.lists(), { postId }] as const,
  details: () => [...commentQueryKeys.all, "detail"] as const,
  detail: (id: number) => [...commentQueryKeys.details(), id] as const,
} as const;

챕터 셀프회고

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

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

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

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

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

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

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

리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문

props drilling을 써야하는 상황과 전역상태관리를 써야하는 상황이 구분될 수 있는 걸까요? 아니면 개발자가 선호하는 방향에 따라 정해지는 걸까요?

과제 피드백

효진님 고생하셨습니다~ 말씀해주신것처럼 이런 구조를 잡는데 있어서는 프로젝트를 관통하는 공통 규칙을 만들고 그것을 최대한 지켜서 작성하는게 가장 중요한 것 같아요. 실제로 회사에서 적용을 할 때에도 팀원 각자가 생각하고 적용하는 범위가 다르게 될 때가 많거든요. 예를 들어서 탠스택 쿼리를 현재는 entity에 속해있는 경우가 있는데, 이 부분도 해석하는 사람마다 다르겠지만 단순히 해당 엔티티에 대한 페칭이 아닌 여러 액션을 담고 있는 부분이 있어 각 피처에서 다뤄야 한다는 얘기가 많은 것처럼요! 지금의 구조가 단순히 데이터를 조회하는 맥락이라면 엔티티의 위치도 좋지만 이렇게 되면 왔다갔다 하니까 규칙을 아예 만들어버리는 경우도 있구요 ㅎㅎ 추가로 타입의 영역일 수 있지만, 현재 엔티티에서 엔티티를 import하는 경우도 있어서 위치를 잘 잡아야 할 것 같네요 ㅎㅎ 이런 것들을 미리 잡기 어려우니까 eslint 도구들을 잘 활용해봐도 좋을것 같아요. 결국 레이어를 나누고 그 레이어간의 의존 방향을 강제하면서 확장성 있는 구조는 어디서 나오는지 등에 조금 더 집중해도 좋을것 같습니다. 전반적으로 잘하셨어요!

props drilling을 써야하는 상황과 전역상태관리를 써야하는 상황이 구분될 수 있는 걸까요? 아니면 개발자가 선호하는 방향에 따라 정해지는 걸까요?

절대적인 규칙은 없지만, 일반적으로 2-3뎁스 이상 들어가거나 함께 드릴링이 되는 갯수가 많은 경우 사용을 고민하게 되는 것 같아요. 다른 복잡한 규칙보다는 프로젝트 자체에서 드릴링되는 것을 운영하는 비용보다 전역 상태를 유지하는 비용이 적어진다고 판단하면 사용하는거라 생각해요ㅎㅎ

고생하셨고 다음주 테스트도 화이팅입니다~~

항해플러스 프론트엔드

hyojin-k 님의 상세페이지 ＞ [3팀 김효진] Chapter 2-3. 관심사 🧦분리와 폴더구조🦍