[6팀 김보경] Chapter 2-3. 관심사 분리와 폴더구조

[bokim1004]

배포링크

https://bokim1004.github.io/front_5th_chapter2-3/index.html

과제 체크포인트

기본과제

목표 : 전역상태관리를 이용한 적절한 분리와 계층에 대한 이해를 통한 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가 아닌 선언적인 함수형 프로그래밍이 적절히 적용되었는가?
• 캐싱과 리프레시 전략이 올바르게 구현되었는가?

과제 셀프회고

과제에서 좋았던 부분

클린코드 과제의 마지막 단계에서 FSD 아키텍처를 활용해 폴더 구조를 나누고 코드를 분리하는 작업을 할 수 있어 좋았습니다.
그동안 FSD 아키텍처를 이렇게까지 체계적으로 적용해본 적은 없었기 때문에, "이렇게도 나눌 수 있구나" 하는 새로운 관점을 배울 수 있었습니다.
이전 과제에서는 entity 중심으로 위로 쌓아가는 계층 구조로 리팩토링을 진행했었는데, 이번에는 page 중심으로 코드를 나누어보았습니다.
가장 큰 목표는 코드가 커졌을 때 어떻게 구조화하면 좋을지 경험해보자는 것이었습니다.
관심사에 따라 코드를 분리하다 보니, entity도 자연스럽게 post, comment, user 등으로 나눌 수 있었고, 컴포넌트 분리 역시 엔티티별로 수월하게 진행할 수 있었습니다.

또한, zustand로 상태 관리를 하고 tanstack query를 활용해 API를 호출하면서, 이러한 도구들을 활용함으로써 코드가 훨씬 깔끔해지고 기능 구현도 훨씬 수월해진다는 점을 직접 체감할 수 있었습니다.

---

과제를 하면서 새롭게 알게된 점

이번 과제를 통해 FSD 아키텍처의 구조를 실전에서 적용해보면서, 그 장점과 한계모두를 체감할 수 있었습니다.
FSD는 관심사별로 코드를 분리함으로써 유지보수성과 확장성을 높여주는 아키텍처지만, 동시에 구조를 어떻게 나눌지에 대한 판단이 어렵다는 점도 느꼈습니다. 예를 들어, 특정 컴포넌트가 features에 들어가야 할지, widgets에 들어가야 할지, shared에 들어가야할지 명확하게 판단하기 어려운 순간들이 있었습니다.

또한, 컴포넌트나 로직이 점점 복잡해질수록 단순한 폴더 정리가 아닌 의도를 기준으로 코드를 설계하고 분리하는 사고방식이 중요하다는 것을 배웠습니다. 단순히 코드를 '어디에 둘 것인가'가 아니라, 이 기능은 어떤 책임을 가지는가, 어떤 계층에서 다루는 것이 적절한가를 먼저 고민하는 습관이 조금씩 생긴 것 같습니다.

결과적으로 이번 경험은 단지 FSD를 익힌 것을 넘어서, 어떻게 구조화하면 좋을지를 실감 있게 체득할 수 있었던 과정이었습니다. 앞으로도 프로젝트를 진행할 때 이런 구조적 고민을 자연스럽게 이어갈 수 있을 것 같습니다.

---

과제를 진행하면서 아직 애매하게 잘 모르겠다 하는 점, 혹은 뭔가 잘 안되서 아쉬운 것들

이번 과제를 통해 FSD 아키텍처를 직접 적용해보면서 느낀 것은, 명확한 기준 없이 폴더 구조를 나누는 것이 생각보다 어렵다는 점이었습니다.
FSD가 관심사별로 코드를 나누는 좋은 방식이라는 건 알겠지만, 어떤 기준으로 feature, widget, shared를 구분해야 하는지 여전히 애매하게 느껴지는 부분이 많았습니다.

예를 들어, Button 컴포넌트는 공통적으로 쓰이기 때문에 shared 폴더에 넣었는데, 한편으로는 재사용 가능한 UI 단위로 구성된 컴포넌트니까 widget에 넣는 게 더 맞지 않나 하는 생각도 들었습니다.
이처럼 디렉토리 구조를 만들면서 이 컴포넌트는 어디에 위치시켜야 할까?에 대한 판단이 쉽지 않았고, 그만큼 아키텍처에 대한 이해와 경험이 더 필요한 것 같다는 생각이 들었습니다.

또 하나 아쉬웠던 점은 tanstack query를 사용할 때 겪은 어려움입니다.
동일한 query key를 사용하는 다른 API들이 서로의 상태에 영향을 주는 문제가 있었고, 이로 인해 예기치 못한 결과가 발생하는 경우도 있었습니다.
그리고 캐싱과 상태 관리가 tanstack query의 강점이지만, 아직 그 흐름이나 전략을 명확히 이해하고 있진 못하다는 걸 깨달았고, 특히 query key 관리, 리프레시 타이밍, 데이터 동기화 방식 등에 대해 더 공부가 필요하다고 느꼈습니다.

이번 경험을 통해 단순히 도구를 사용하는 것을 넘어서, "왜 이렇게 사용하는가", 언제 어떻게 써야 문제를 피할 수 있는가를 이해하는 것이 정말 중요하다는 걸 느꼈습니다. 아직 부족한 부분이 많지만, 이번 과제가 그런 고민을 할 수 있는 좋은 기회가 되어 의미 있었습니다.

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

Button, Loading처럼 재사용 가능한 컴포넌트들을 shared 폴더에 넣었는데, 한편으로는 widget에 넣는 게 더 맞지 않을까 하는 고민도 들었습니다.
widget에는 재사용 가능한 UI 컴포넌트들이 들어가는 걸로 알고 있는데, 아직 이 둘의 기준이 조금 헷갈리는 부분이 있습니다.
widget 폴더는 보다 큰 단위의 공통 레이아웃이나 UI 블록을 넣는 것이 맞는 걸까요?
이 부분에 대해 명확한 기준이 있으면 알고 싶습니다.