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

[LEE-jm96]

배포 링크

https://lee-jm96.github.io/front_7th_chapter3-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가 정상적으로 작동하는가?

최종과제

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

과제 셀프회고

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

1. 서버 상태와 클라이언트 상태의 명확한 분리

이전에는 모든 상태를 useState나 Context API로 관리했는데, 이번 과제를 통해 서버 상태와 클라이언트 상태를 명확히 구분해야 한다는 것을 깨달았습니다.

서버 상태 (TanStack Query)는 서버에서 가져온 데이터로, 캐싱, 동기화, 백그라운드 업데이트가 필요합니다. 반면 클라이언트 상태 (Jotai)는 UI 상태, 필터링 옵션, 페이지네이션 등 사용자 인터랙션에 의한 상태입니다.

예를 들어, 게시물 목록 데이터는 서버 상태로 관리하고, 검색어나 정렬 옵션은 클라이언트 상태로 관리했습니다. 이렇게 분리하니 각 상태의 생명주기와 업데이트 전략을 명확하게 설계할 수 있었습니다.

2. FSD 아키텍처의 실전 적용

FSD(Feature-Sliced Design)를 이론으로만 알고 있었는데, 실제 프로젝트에 적용하면서 각 레이어의 역할과 의존성 규칙을 체험했습니다.

entities는 비즈니스 도메인 모델, features는 사용자 기능, widgets는 복잡한 UI 블록, shared는 공통 요소로 구분하면서, 코드의 재사용성과 유지보수성이 크게 향상되었습니다. 특히 "어디에 무엇을 넣어야 하는가?"라는 질문에 대한 답을 찾는 과정에서 아키텍처의 중요성을 깨달았습니다.

3. 관심사의 분리와 단일 책임 원칙

이전에는 하나의 컴포넌트에 모든 로직이 섞여 있었는데, 이번 과제를 통해 관심사의 분리가 얼마나 중요한지 알게 되었습니다.

• API 호출은 entities/api에서
• 쿼리 로직은 entities/model/queries에서
• 비즈니스 로직은 features/model에서
• UI는 각 레이어의 ui 폴더에서

이렇게 분리하니 각 파일이 하나의 명확한 책임만 가지게 되어, 테스트하기 쉽고 수정하기 쉬운 코드가 되었습니다.

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

Fsd 구조를 잡기 위해 노력하였습니다.

src/
├── shared/ # 공통 레이어
│ ├── ui/ # 공통 UI 컴포넌트 (Button, Input, Card 등)
│ └── lib/ # 공통 유틸리티 (highlightText)
│
├── entities/ # 비즈니스 엔티티
│ ├── post/
│ ├── comment/
│ ├── user/
│ └── tag/
│
├── features/ # 사용자 기능
│ ├── post-list/
│ ├── post-search/
│ ├── post-add/
│ ├── post-edit/
│ ├── post-detail/
│ ├── comment-management/
│ ├── user-profile/
│ └── pagination/
│
├── widgets/ # 재사용 가능한 복잡한 UI 블록
│ ├── header/ # 헤더 네비게이션
│ │ ├── ui/
│ │ │ └── Header.tsx
│ │ └── index.ts
│ │
│ ├── footer/ # 푸터
│ │ ├── ui/
│ │ │ └── Footer.tsx
│ │ └── index.ts
│
└── pages/ # 페이지 (진입점)
└── PostsManagerPage.tsx

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

FSD를 도입해보긴 하였지만, 어떤 기준으로 엔티티에 넣어야 하고 어떤 걸 피처에 넣어야 하는지 구분하는 게 아직도 쉽지 않은 것 같습니다. 특히 FSD 구조를 적용하려고 할 때 “이 로직이 도메인 핵심인가?”, “아니면 특정 화면에서만 필요한 기능인가?”를 판단하는 과정이 생각보다 어려웠던 것 같습니다. 그래서 폴더 구조를 짜거나 코드를 배치하는 데 시간이 걸렸던 것 같습니다.

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

아주 작은 기능 하나를 FSD로 쪼개보기
-> React로 간단한 기능(예: Todo 추가/삭제, 좋아요 버튼, 필터링 등)을 만든 뒤, 이를 FSD 구조로 직접 나눠보면서 차근차근 FSD를 공부해보고 싶습니다.

챕터 셀프회고

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

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

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

한 파일에 여러 줄의 소스가 빼곡하게 있으면 시작부터 피로감을 느끼는 편입니다.
제가 생각하는 ‘읽기 좋은 코드’란 관심사에 따라 컴포넌트가 명확히 분리되어 있고, 그 안에서 사용하는 상태나 비즈니스 로직 역시 커스텀 훅 또는 해당 컴포넌트의 자체적인 상태 관리로 잘 구조화되어 있는 코드입니다.

또한 유지보수하기 좋은 코드를 만들기 위해서는 재활용 가능한 컴포넌트를 공통 영역으로 분리하고, 앞서 말한 것처럼 관심사 기준으로 컴포넌트가 명확하게 나뉘어 있는 구조가 중요하다고 생각합니다.

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

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

1. 재사용성 향상

순수함수는 특정 컴포넌트에 의존하지 않기 때문에, 동일한 계산이나 규칙이 필요한 다른 컴포넌트에서도 그대로 사용할 수 있었습니다.
그 결과 중복 코드를 줄이고 재사용 가능한 로직을 개발할 수 있었습니다.

2. 가독성 향상

컴포넌트에서 계산이나 조건 처리 같은 복잡한 로직을 분리하면, 컴포넌트는 UI 중심의 코드만 남게 되는 걸 확인할 수 있었습니다. 그 덕분에 컴포넌트 구조가 깔끔해지고, 어떤 일을 하는 코드인지 더 빠르게 파악할 수 있었고, 또한 계산 로직은 별도 파일로 정리되어 있어 비즈니스 로직이 더 명확하게 드러남을 확인했습니다.

3. 유지보수성 향상

계산 로직이 여러 곳에 흩어져 있지 않고 순수함수 하나에 모여 있으므로, 한 곳만 수정하면 되는 장점이 있었습니다. 이로 인해 버그가 발생할 가능성이 줄고, 문제가 생기더라도 원인을 쉽게 추적하고 수정할 수 있었습니다.

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

FSD 패턴이 실제로 실무에서 많이 사용되는지 궁금합니다. 이론적으로는 어느 정도 이해했지만, 막상 도입하려고 보니 구조를 잡는 과정에서 고민할 부분이 많았고 정해진 정답도 없다 보니 개발자마다 폴더 구조가 크게 달라질 수 있겠다는 생각이 들었습니다.
이런 변동성 때문에 실제 기업에서는 과연 얼마나 FSD를 채택하고 있는지, 실무에서도 안정적으로 적용 가능한 패턴인지 더 궁금해졌습니다.

회사에서 도입한다면 개발자들이 기준을 합의해 어느 정도 틀을 먼저 정하고 시작해야 할 것 같은데, 과연 이런 과정까지 거치면서 FSD를 사용하는 것이 기존 구조보다 더 효과적인지 궁금증이 생겼습니다. 특히 관심사를 어떻게 나누는지가 사람마다 다르고 모호할 수 있다고 생각합니다.

추가적으로 FSD 패턴을 제외한 현재 실무에서 일반적으로 많이 사용되는 다른 구조적 패턴은 무엇인지도 알고 싶습니다!