[5팀 박수범] Chapter3-2. 디자인 패턴과 함수형 프로그래밍 그리고 상태 관리 설계

[parksubeom]

배포링크:advanced

[구조 변경]

• FSD 폴더 구조 초기화 (shared, entities, widgets)
• 공통 타입과 유틸리티 함수를 shared 레이어로 이동

[Entities]

• ProductCard UI 생성 및 도메인 로직(재고 확인) 캡슐화
• 장바구니 계산 로직을 entities/cart/lib으로 분리

[Widgets]

• Header 위젯 추출: UI 렌더링과 상태 분리
• ProductList 위젯 추출: 목록 렌더링 및 검색 결과 없음 처리 분리
• CartSidebar 위젯 추출: 자율적인 가격 계산 로직 구현

[리팩토링]

• App.tsx의 원시 JSX 코드를 위젯 컴포넌트 조합으로 교체
• 애플리케이션 전체의 가격 표기 방식 표준화
• UI 컴포넌트의 TSX 확장자 관련 에러 수정

과제의 핵심취지

• React의 hook 이해하기
• 함수형 프로그래밍에 대한 이해
• 액션과 순수함수의 분리

과제에서 꼭 알아가길 바라는 점

• 엔티티를 다루는 상태와 그렇지 않은 상태 - cart, isCartFull vs isShowPopup
• 엔티티를 다루는 컴포넌트와 훅 - CartItemView, useCart(), useProduct()
• 엔티티를 다루지 않는 컴포넌트와 훅 - Button, useRoute, useEvent 등
• 엔티티를 다루는 함수와 그렇지 않은 함수 - calculateCartTotal(cart) vs capaitalize(str)

기본과제

• Component에서 비즈니스 로직을 분리하기

• 비즈니스 로직에서 특정 엔티티만 다루는 계산을 분리하기

• 뷰데이터와 엔티티데이터의 분리에 대한 이해

• entities -> features -> UI 계층에 대한 이해

• Component에서 사용되는 Data가 아닌 로직들은 hook으로 옮겨졌나요?

• 주어진 hook의 책임에 맞도록 코드가 분리가 되었나요?

• 계산함수는 순수함수로 작성이 되었나요?

• Component에서 사용되는 Data가 아닌 로직들은 hook으로 옮겨졌나요?

• 주어진 hook의 책임에 맞도록 코드가 분리가 되었나요?

• 계산함수는 순수함수로 작성이 되었나요?

• 특정 Entitiy만 다루는 함수는 분리되어 있나요?

• 특정 Entitiy만 다루는 Component와 UI를 다루는 Component는 분리되어 있나요?

• 데이터 흐름에 맞는 계층구조를 이루고 의존성이 맞게 작성이 되었나요?

심화과제

• 이번 심화과제는 Context나 Jotai를 사용해서 Props drilling을 없애는 것입니다.

• 어떤 props는 남겨야 하는지, 어떤 props는 제거해야 하는지에 대한 기준을 세워보세요.

• Context나 Jotai를 사용하여 상태를 관리하는 방법을 익히고, 이를 통해 컴포넌트 간의 데이터 전달을 효율적으로 처리할 수 있습니다.

• Context나 Jotai를 사용해서 전역상태관리를 구축했나요?

• 전역상태관리를 통해 domain custom hook을 적절하게 리팩토링 했나요?

• 도메인 컴포넌트에 도메인 props는 남기고 props drilling을 유발하는 불필요한 props는 잘 제거했나요?

• 전체적으로 분리와 재조립이 더 수월해진 결합도가 낮아진 코드가 되었나요?

과제 셀프회고

리팩토링 청사진

제가 집중한 이번 리팩토링의 핵심 목적은 수직적 분리 와 수평적 분리 를 통해 입체적인 코드 구조를 만드는 것입니다.

수직적 분리 (레이어 위계)

Widgets (조립)
   ↓
Features (액션)
   ↓
Entities (데이터)
   ↓
Shared (공통)

상위 레이어만 하위 레이어를 참조할 수 있는 단방향 의존성 규칙 을 세워 데이터 흐름을 통제했습니다.

수평적 분리 (내부 역할)

각 폴더 내부에서 책임을 다시 분리합니다:

feature/cart/
├── ui/          # 사용자 액션 (View)
├── model/       # 상태 관리 (State)
└── lib/         # 순수 계산 (Logic)

이는 함수형 프로그래밍의 "데이터와 로직의 분리" 원칙을 파일 시스템에 적용한 것입니다.

입체적 메트릭스

수직과 수평을 조합하면, 코드의 위치만으로도 "어떤 계층의, 어떤 역할" 인지 즉시 파악할 수 있습니다:

• widgets/ProductList/ui → 상위 레이어의 UI 조립
• features/cart/model → 중간 레이어의 상태 관리
• entities/cart/lib → 하위 레이어의 순수 계산 로직

이 구조는 파일 경로 자체가 명세서 역할을 합니다.

시행착오: 수평적 분리에 대한 오해

처음에는 FSD의 레이어 구조만 이해했습니다. 그래서 단순히

• Entities = 데이터
• Features = 액션
• Shared = 계산

이렇게 함수형 프로그래밍의 3단계 분리(데이터, 계산, 액션)와 1:1로 매핑된다고 생각했습니다.

하지만 이건 잘못된 이해였습니다.

영서님과의 대화를 통해 깨달은 것은:

• 수직적 분리(Layer): '권력(의존성)'을 기준으로 나눈다

  • 누가 누구를 참조할 수 있는가?

• 수평적 분리(Slice): '주제(도메인)'를 기준으로 나눈다

  • product, cart, user 등

• 내부 분리(Segment): '직무(역할)'를 기준으로 나눈다

  • ui, model, lib 등

코드를 분리할 때는 "이건 어떤 Layer의 어떤 Slice에 있는 어떤 Segment가 해야 할 일인지" 를 생각하면 됩니다.

예를 들어, 장바구니 총합 계산 로직은:

• Layer: entities (데이터 레이어)
• Slice: cart (장바구니 도메인)
• Segment: lib (순수 계산 로직)
  → entities/cart/lib/calculateCartTotal.ts

FSD 설계 + 함수형 프로그래밍은 3차원 좌표계 처럼 코드의 정확한 위치를 지정하는 시스템같다고 느껴졌습니다.

설계 의사결정 과정

폴더 구조의 큰 틀은 FSD 공식 문서와 레퍼런스를 통해 파악했지만, 실제로 중요한 것은 "어떤 설계를 선택할 것인가" 에 대한 의사결정이었습니다.

예를 들어:

• calculateCartTotal 로직을 entities/cart/lib에 둘 것인가, shared/lib에 둘 것인가?
• ProductCard의 재고 확인 로직은 컴포넌트 내부에 둘 것인가, 별도 lib로 분리할 것인가?
• onAddToCart 핸들러는 어느 레이어가 소유해야 하는가?

이런 질문들은 정답이 명확하지 않았고, 각 선택마다 트레이드오프가 있었습니다.
함수형 프로그래밍 블로그 와 FSD 설계 블로그를 정독한 후 →

• 특정 도메인에 강하게 결합된 로직은 해당 Entity에 두는 것이 응집도가 높다
• 범용적으로 쓰이는 유틸리티만 Shared로 올린다
• Feature 레이어 없이 Entity가 액션을 소유하면 재사용성이 떨어진다

이런 인사이트를 얻을 수 있었고, 설계 결정의 타당성을 검증 할 수 있었습니다.

결국 좋은 아키텍처는 폴더를 어떻게 나누느냐의 문제가 아니라, "왜 이렇게 나눴는가"를 설명할 수 있는가 의 문제라는 것을 배웠습니다.

---

과제를 하면서 내가 알게된 점, 좋았던 점은 무엇인가요?

FSD 패턴: 폴더 구조가 곧 명세서다 [Screaming Architecture]

로버트 C. 마틴(Uncle Bob)이 주창한 "Screaming Architecture" 개념이 있습니다.

"프로젝트의 폴더 구조를 봤을 때, '우리는 리액트를 씁니다!'라고 소리치지 말고, '우리는 쇼핑몰입니다!'라고 소리쳐야 한다."

기술이 아닌 비즈니스가 보여야 한다

기존 구조:

src/
├── components/
├── hooks/
├── utils/
└── contexts/

이 구조는 "우리는 리액트를 씁니다!"라고 소리칩니다.

• 컴포넌트를 쓰는구나
• 훅을 쓰는구나
• 컨텍스트를 쓰는구나

하지만 정작 중요한 질문에는 답하지 못합니다:

• 이게 쇼핑몰인가요? SNS인가요? 투두리스트인가요?
• 어떤 기능이 있나요?
• 어떤 데이터를 다루나요?

FSD 구조:

src/
📦advanced
 ┣ 📂entities           # [도메인 모델] 비즈니스 데이터 & 순수 계산
 ┃ ┃                    # 원칙: 데이터 구조와 순수 함수만. 상태나 액션을 모름.
 ┃ ┣ 📂cart             # 장바구니 도메인
 ┃ ┃ ┣ 📂lib            #   └─ calculateCartTotal (순수 함수)
 ┃ ┃ ┗ 📂model          #   └─ CartItem 타입
 ┃ ┣ 📂coupon           # 쿠폰 도메인
 ┃ ┃ ┣ 📂lib            #   └─ canApplyCoupon (검증 로직)
 ┃ ┃ ┗ 📂model          #   └─ Coupon 타입
 ┃ ┗ 📂product          # 상품 도메인
 ┃ ┃ ┣ 📂lib            #   └─ getRemainingStock (재고 계산)
 ┃ ┃ ┣ 📂model          #   └─ ProductWithUI 타입
 ┃ ┃ ┗ 📂ui             #   └─ ProductCard (멍청한 컴포넌트)
 ┣ 📂features           # [비즈니스 액션] 사용자 행동 & 상태 관리
 ┃ ┃                    # 원칙: '동사(Verb)'를 담당. Entity와 Shared로 가치 창출.
 ┃ ┣ 📂app              # 통합 기능
 ┃ ┃ ┗ 📜useShop.ts     #   └─ Facade Hook (모든 Hook을 하나로 묶음)
 ┃ ┣ 📂cart             # 장바구니 기능
 ┃ ┃ ┗ 📂model          #   └─ useCart (담기/삭제/수량 변경)
 ┃ ┣ 📂coupon           # 쿠폰 기능
 ┃ ┃ ┣ 📂model          #   ├─ useCoupons (CRUD 로직)
 ┃ ┃ ┗ 📂ui             #   └─ CouponManagementForm (입력/검증 UI)
 ┃ ┗ 📂product          # 상품 기능
 ┃ ┃ ┣ 📂model          #   ├─ useProducts (CRUD & 동기화)
 ┃ ┃ ┃ ┣ 📜useProductFilter.ts  #   ├─ 검색/필터링 로직
 ┃ ┃ ┃ ┗ 📜useProductForm.ts    #   └─ 폼 상태 (Headless)
 ┃ ┃ ┗ 📂ui             #   └─ ProductManagementForm (입력 폼)
 ┣ 📂shared             # [인프라] 도메인을 모르는 범용 도구
 ┃ ┃                    # 원칙: 프로젝트 공용. 비즈니스(쇼핑몰)를 전혀 모름.
 ┃ ┣ 📂lib              # 범용 함수 & 훅
 ┃ ┃ ┣ 📜format.ts          #   ├─ 포맷터 (순수 함수)
 ┃ ┃ ┣ 📜useDebounce.ts     #   ├─ UI 최적화 (시간 지연)
 ┃ ┃ ┣ 📜useLocalStorage.ts #   ├─ 저장소 추상화
 ┃ ┃ ┣ 📜useNotification.ts #   ├─ 알림 (레거시)
 ┃ ┃ ┗ 📜useNotificationSystem.ts # └─ 알림 (개선)
 ┃ ┣ 📂model            # 범용 데이터
 ┃ ┃ ┗ 📜types.ts           #   └─ Notification 등 공용 타입
 ┃ ┗ 📂ui               # 범용 UI
 ┃ ┃ ┗ 📜NotificationSystem.ts #   └─ 알림 렌더러
 ┣ 📂widgets            # [조립] 독립적인 UI 블록
 ┃ ┃                    # 원칙: Entity + Feature를 조립해 완성된 덩어리 생성.
 ┃ ┣ 📂AdminDashboard   # 관리자 패널
 ┃ ┃ ┗ 📂ui
 ┃ ┃ ┃ ┣ 📜CouponListGrid.tsx   # ├─ 쿠폰 목록 그리드
 ┃ ┃ ┃ ┣ 📜ProductListTable.tsx # ├─ 상품 목록 테이블
 ┃ ┃ ┃ ┗ 📜index.tsx            # └─ 위젯 진입점
 ┃ ┣ 📂CartSidebar      # 장바구니 사이드바
 ┃ ┃ ┗ 📂ui             #   └─ 결제 정보 포함
 ┃ ┣ 📂Header           # 헤더
 ┃ ┃ ┗ 📂ui             #   └─ 네비게이션, 카트 아이콘
 ┃ ┗ 📂ProductList      # 상품 목록
 ┃ ┃ ┗ 📂ui             #   └─ 검색 결과 표시
 ┣ 📂__tests__          # 테스트
 ┃ ┗ 📜origin.test.tsx  #   └─ 통합 테스트 (E2E)
 ┣ 📜App.tsx            # [페이지] 레이어 조립 & 데이터 주입
 ┃                      # 원칙: 로직 없음. useShop 호출 → Widget 주입만.
 ┗ 📜main.tsx           # 앱 진입점

이 구조는 "우리는 쇼핑몰입니다!"라고 소리칩니다.

• 상품이 있구나
• 장바구니가 있구나
• 쿠폰을 적용할 수 있구나
• 결제 기능이 있구나

폴더 이름만 봐도 기획서의 목차가 보입니다.

FSD는 기술 스택이 아닌 비즈니스 도메인이 앞으로 나옵니다.

레이어 자체가 기능 명세서

FSD의 각 폴더는 기획서의 섹션과 정확히 매칭됩니다.

FSD 레이어	기획서/명세서의 항목	우리 프로젝트의 실제 폴더 (예시)
Pages	사이트맵 / 라우팅	App.tsx (현재 메인)
Widgets	와이어프레임 (UI 블록)	widgets/Header, widgets/ProductList, widgets/CartSidebar, widgets/AdminDashboard
Features	유저 스토리 (비즈니스 액션)	features/cart (담기/수량변경), features/product (상품 CRUD), features/coupon (쿠폰 적용)
Entities	도메인 모델 (데이터 구조)	entities/product (ProductCard, 재고파악), entities/cart (가격계산)
Shared	인프라 / 공통 규약	shared/model (types.ts), shared/lib (format.ts, useNotification)

특히 features 폴더는 그 자체로 "이 애플리케이션이 수행할 수 있는 동작 목록"입니다.

신규 입사자가 왔을 때, 두꺼운 위키 문서를 던져주는 것보다 src/features 폴더를 열어보라고 하는 게 훨씬 빠르고 정확합니다.

강제된 의존성 규칙이 곧 설계도

일반적인 프로젝트에서는 개발자마다 "이 코드를 어디에 둘까?"에 대한 기준이 달라 스파게티가 되기 쉽습니다. 하지만 FSD는 상위 레이어만 하위 레이어를 참조할 수 있다는 엄격한 규칙이 있습니다.

이 규칙 자체가 "코드의 흐름도" 역할을 합니다:

• Widget을 보면 → "아, 이 기능(Feature)과 저 데이터(Entity)를 조립했구나."
• Feature를 보면 → "아, 이 데이터(Entity)를 조작하는구나."

폴더 위치만으로도 데이터의 흐름과 의존 관계를 파악할 수 있습니다. 폴더구조가 하나의 명세로 사용된다는 게 신기하고 충격이었습니다.

---

FSD 구조 + 함수형 프로그래밍 기반의 코드로 찢는과정

리팩토링을 진행하면서 가장 어려웠던 건 "이 코드를 어느 폴더에 넣을까?" 였습니다.
이 코드가 어느 레이어에 속해야 하며, 뷰데이터인지, 엔티티데이터인지 액션인가? 계산인가? 등 컴포넌트를 찢는 과정에 명확한 기준이 필요했습니다.
5가지 원칙을 세우고, 원칙에 의해서 판단 후 파일을 분리했습니다.

1. "이 코드가 외부환경을 바꾸는가?" (액션 vs 계산의 분리)

함수형 프로그래밍의 제1원칙

가장 먼저 적용한 기준입니다. 코드를 분리할 때 가장 중점적으로 적용한 원칙입니다.

질문:

"이 함수를 100번 실행하면 외부 세상(DB, 화면, 전역변수)에 영향을 미치는가?"

분리 기준:

• NO (순수함): 입력만 같으면 결과가 늘 같고, 아무것도 안 건드린다.
  → lib (Entities/Shared) 으로 격리

  • 예: calculateCartTotal, formatCurrency, canApplyCoupon

• YES (부수효과): 상태를 바꾸거나(setState), 저장하거나(localStorage), 화면을 그린다.
  → model (Hook) 또는 ui (Component) 에 남김

  • 예: addToCart, useLocalStorage

왜 중요한가?
순수 함수는 테스트하기 쉽고, 재사용하기 좋고, 버그가 적습니다.
lib 폴더만 열면 "아, 이건 어디든 가져다 써도 계산함수구나"라는 생각이 듭니다.

---

2. "이 코드는 '쇼핑몰'이라는 사실을 아는가?" (도메인 지식 유무)

FSD 레이어 결정 기준

코드가 비즈니스(도메인)와 얼마나 얽혀있는지 봤습니다.

질문:

"이 코드를 떼어내서 다른 서비스에 가져가면 에러 없이 작동하는가?"

분리 기준:

• YES (작동함): 도메인을 모르는 멍청한 도구다.
  → Shared

  • 예: useLocalStorage (저장만 함), useDebounce (시간만 끔), formatCurrency (숫자만 바꿈)

• NO (에러남): '상품', '쿠폰' 같은 단어를 알아야 한다.
  → Entities / Features

  • 예: ProductCard, useCart

왜 중요한가?
Shared는 다른 프로젝트에서도 복붙할 수 있는 "범용 인프라"입니다.
반면 Entities/Features는 "이 쇼핑몰만의 고유한 지식"입니다.
이 경계가 명확해야 코드를 재사용하거나 교체하기 쉬워집니다.

---

3. "책임이 너무 무겁지 않은가?" (단일 책임 원칙)

컴포넌트 분할 기준

AdminDashboard나 App.tsx를 찢을 때 적용한 기준입니다.

질문:

"이 컴포넌트가 변경되어야 하는 이유가 2개 이상인가?"

분리 기준:

• App.tsx는 "라우팅/배치"가 바뀌면 수정되어야 하는데, "검색 로직" 때문에도 수정되어야 했다.
  → 분리 대상

• AdminDashboard는 "레이아웃" 때문에 수정되어야 하는데, "상품 입력 폼의 유효성 검사" 때문에도 수정되어야 했다.
  → ProductManagementForm으로 분리

왜 중요한가?
하나의 파일이 여러 이유로 수정되면, 팀원들끼리 Git 충돌이 나고, 버그 수정 시 예상치 못한 부분이 깨집니다.
"한 가지 이유로만 변경되는 파일"은 안전하고 예측 가능합니다.

---

4. "구현(How)인가, 의도(What)인가?" (추상화 레벨)

훅(Hook) 분리 기준

useCart 내부를 정리할 때 쓴 기준입니다.

질문:

"이 코드가 '무엇을 하는지' 설명하는가, '어떻게 하는지' 구구절절 설명하는가?"

분리 기준:

• Before: localStorage.getItem('cart')... JSON.parse...
  → 이건 "어떻게(How)"에 집착하는 저수준 코드

• Action: 저수준 코드를 useLocalStorage로 숨김

• After: usePersist("cart")
  → "저장한다(What)"는 의도만 남김
  → 비즈니스 로직이 선명해짐

왜 중요한가?
비즈니스 로직에 JSON.parse, try-catch 같은 저수준 코드가 섞이면 "진짜 중요한 로직"이 묻힙니다.
추상화를 통해 "쿠폰을 적용한다", "장바구니에 담는다" 같은 비즈니스 언어만 남겨야 합니다.

---

5. "자주 함께 바뀌는가?" (응집도)

파일 위치 선정 기준

타입(types.ts)을 찢어서 각 폴더에 넣을 때 쓴 기준입니다.

질문:

"Product 타입이 바뀌면 누가 가장 귀찮은가?"

분리 기준:

• Product 타입이 바뀌면 ProductCard와 useProducts가 귀찮아진다.
  → 그들 곁(entities/product)에 둔다.

• 서로 관련 없는 코드들이 한 파일(shared/types.ts)에 모여 있으면, 하나 고칠 때마다 부가적인 수정소요가 생긴다.
  → 찢는다

왜 중요한가?
"함께 변경되는 것은 함께 둔다"는 원칙은 개발 속도를 올립니다.
Product 관련 코드를 수정할 때, entities/product 폴더만 열면 모든 게 거기 있습니다.
여러 폴더를 헤매지 않아도 됩니다.

---

5가지 원칙 요약표

상황	질문	결정 (Action)
로직	결과가 늘 같은가?	✅ → lib (순수함수) ❌ → hook (액션)
위치	쇼핑몰인 걸 아는가?	✅ → Entities/Features ❌ → Shared
UI	역할이 2개 이상인가?	✅ → 하위 컴포넌트로 분리 (Form, List)
상태	구체적 구현인가?	✅ → 커스텀 훅으로 추상화 (useLocalStorage)
데이터	누구랑 친한가?	친한 애 옆(model)으로 이동

---

1. 전역 상태 관리 도입 배경: "Props Drilling 지옥 탈출기"

① 마주한 한계 (The Pain Points)

FSD 아키텍처를 도입해 폴더 구조는 깔끔해졌지만, 데이터 흐름(Data Flow)은 여전히 복잡했습니다. 특히 App.tsx에서 정의된 상태와 핸들러가 말단 컴포넌트까지 전달되는 과정에서 'Props Drilling' 문제가 심각하게 대두되었습니다.

"택배 기사가 되어버린 중간 컴포넌트들"

가장 대표적인 예시는 addNotification 함수였습니다.

• 정의: 최상위 App.tsx
• 사용: 저 깊은 곳의 ProductManagementForm (상품 추가 실패 시 알림)
• 경로: App → AdminDashboard → ProductManagementForm

이 과정에서 AdminDashboard는 본인이 알림 기능을 쓰지도 않으면서, 단지 자식에게 넘겨주기 위해 Props 인터페이스에 onNotification을 정의해야 했습니다. 이는 불필요한 결합도(Coupling)를 높이고 코드를 지저분하게 만들었습니다.

거대한 허브가 된 App.tsx

모든 도메인 상태(cart, products, coupons)를 App.tsx가 관리하다 보니, App 컴포넌트는 UI 렌더링보다는 데이터를 엮어주는 작업에 치중하게 되었습니다. 이는 "페이지 레이아웃"이라는 본연의 책임에서 벗어난 것이었습니다.

② 해결책: Zustand 도입과 제어의 역전

이러한 문제를 해결하기 위해 Zustand를 도입하여 상태 관리의 패러다임을 전환했습니다.

• Before (Push 방식): 부모가 자식에게 데이터를 억지로 밀어넣음 (Props)
• After (Pull 방식): 필요한 컴포넌트가 전역 스토어에서 직접 데이터를 가져다 씀 (Subscribe)

결과:

• App.tsx는 더 이상 상태 관리자가 아닌, 순수한 조립자(Assembler)가 되었습니다.
• 중간 컴포넌트들은 '택배 기사' 역할에서 해방되어 본연의 UI 로직에만 집중할 수 있게 되었습니다.

---

2. 기술적 도전: 전역 상태 도입과 테스트 격리 문제

하지만 전역 상태 관리를 도입하여 구조를 개선하자마자, 예상치 못한 새로운 문제가 발생했습니다.

① 문제 상황 (Problem)

알림 시스템(Notification)을 useState 기반의 지역 상태에서 Zustand 기반의 전역 상태로 리팩토링한 직후, 기존에 잘 통과하던 통합 테스트(origin.test.tsx)가 실패하는 현상이 발생했습니다.

"알림이 하나만 떠야 하는데 여러 개가 발견됨 -> Notification관련 파일을 뒤져봐도 여러 개가 보이게 될만한 코드는 없는데? -> 알림이 남아있나? -> App컴포넌트가 언마운트 될 때 같이 사라질텐데? -> 어? 근데 이제는 Notification상태를 Zustand로 관리하고, Zustand 스토어는 컴포넌트 외부에 있으니까 같은 생명주기를 공유하지 않는건가?"

② 원인 분석 및 추론 (Reasoning)

디버깅 결과, 원인은 지역 상태와 전역 상태의 '생명주기(Lifecycle)' 차이에 있었습니다.

전역 상태 관리 전 (useState):

• 컴포넌트 인스턴스에 종속됩니다.
• 테스트가 끝날 때마다 App 컴포넌트가 언마운트되면서 상태도 함께 메모리에서 소멸합니다.
• 결과: 매 테스트는 항상 깨끗한 상태에서 시작했습니다.

전역 상태 관리 후 (Zustand):

• 스토어는 컴포넌트 외부(모듈 스코프)에 존재합니다(Singleton).
• 컴포넌트가 언마운트되어도 스토어의 데이터는 메모리에 그대로 남아있습니다.
• 결과: 앞선 테스트 케이스에서 생성된 알림 데이터가 지워지지 않고 다음 테스트 케이스로 넘어가는 '상태 오염' 이 발생했습니다.

왜 문제가 되었는가?

[1번째 테스트] 쿠폰 적용 → 알림 1개 생성 → 테스트 종료   └─> Zustand 스토어에는 알림 1개가 남아있음 (좀비 데이터)
[2번째 테스트] 할인 적용 → 알림 1개 생성 (예상)   └─> 실제로는 알림 2개가 표시됨 (이전 알림 + 새 알림)   └─> ❌ 테스트 실패: "알림요소 중복" 

③ 해결 방법 (Solution)

이 문제를 해결하기 위해 '마운트 시 초기화(Reset on Mount)' 전략을 선택했습니다.

접근법:

App.tsx가 마운트되는 시점(useEffect)에 전역 알림 스토어를 빈 배열로 강제 초기화했습니다.

// src/App.tsx useEffect(() => {   // 앱이 시작될 때(혹은 테스트가 새로 시작될 때) 스토어를 초기화하여 좀비 데이터를 방지함   useNotificationStore.setState({ notifications: [] }); }, []); 

선택 근거:

언마운트 시점의 cleanup 함수를 활용할 수도 있었으나, 테스트 도중 에러 발생 등으로 비정상 종료될 경우 뒷정리가 실행되지 않을 위험이 있습니다.

반면, 마운트 시점의 초기화는 이전 상황과 관계없이 현재 실행 환경의 순수성을 확실하게 보장합니다.

부가적인 효과:

실제 사용자 경험에서도 페이지 새로고침 시 이전 세션의 불필요한 알림이 남지 않도록 하는 UX 개선 효과를 얻었습니다.

④ 배운 점 (Lesson Learned)

전역 상태 관리 라이브러리를 도입할 때는 단순히 "편리함"만 생각해서는 안 된다는 것을 깨달았습니다.

• 싱글톤은 자유로운 만큼 책임이 따른다:

  전역 스토어는 컴포넌트 경계를 넘어 데이터를 공유할 수 있지만, 그만큼 생명주기 관리의 책임도 개발자에게 넘어옵니다.

• 테스트의 중요성:

  "왜 예전엔 되던 테스트가 갑자기 깨지지?" 즉, 회귀 테스트를 실패하게 되면서 수정 직후 빠르게 문제를 파악할 수 있고 해당 문제에 대한 즉각적인 고민과 해결이 가능해서 너무 좋았습니다.

이 조치를 통해 전역 상태를 사용하면서도 각 테스트 케이스의 독립성을 보장할 수 있었고, 코드의 신뢰성을 유지할 수 있었습니다.

이번 과제에서 내가 제일 신경 쓴 부분은 무엇인가요?

이번 과제를 진행하며 가장 신경쓰고, 또 고민했던 부분은 단순한 코드 이동이 아니라 "설계 원칙의 적용" 과정이었습니다. 특히 제가 가장 공을 들였던 부분은 'FP의 순수성' 과 'FSD의 위계질서' 를 실제 코드에 녹여내는 것이었습니다.

1. 액션(Action)과 계산(Calculation)의 엄격한 분리 (FP)

가장 공을 들인 부분은 컴포넌트와 훅에 뒤섞여 있던 비즈니스 로직을 '부수 효과가 없는 순수 함수(계산)' 와 '상태를 변경하는 함수(액션)' 로 명확히 구분하는 것이었습니다.

Before:
formatPrice나 applyCoupon 같은 함수들이 내부에서 전역 상태(isAdmin)나 컴포넌트 상태(cart)를 직접 참조(암묵적 입력)하고 있어 테스트가 불가능했습니다.

After:

• 계산: entities/**/lib 폴더로 추출하여 외부 의존성을 모두 제거하고 인자(Explicit Input)만으로 동작하도록 리팩토링했습니다.
  예: canApplyCoupon, calculateCartTotal

• 액션: 상태 변경이나 사이드 이펙트는 features/**/model의 Custom Hook에 위임하여, 계산 로직을 호출하고 결과를 반영하는 역할만 수행하도록 했습니다.

이를 통해 비즈니스 로직의 테스트 용이성을 확보 하고, UI 컴포넌트가 로직에 종속되지 않도록 만들었습니다.

2. FSD 아키텍처의 '의존성 규칙' 준수와 '응집도' 강화

단순히 파일을 폴더에 나누는 것을 넘어, "각 레이어가 서로를 어떻게 참조해야 하는가" 에 대한 규칙을 세우고 지키는 데 집중했습니다.
FSD 아키텍처로 보여지는것보다 각가의 레이어의 위계가 확실히 정립되고, 관련있는 파일끼리 최대한 모아서 높은 응집도의 구조가 되도록 노력했습니다.

Shared:
도메인을 모르는 순수 도구(useLocalStorage, useDebounce)로 정의하여 범용성을 확보했습니다.

Features:
useCart가 useProducts의 데이터가 필요할 때, 인자로 주입받거나 전역 스토어를 구독하게 하여 결합도를 낮췄습니다.

Widgets:
AdminDashboard 같은 거대 컴포넌트를 ProductManagementForm(Feature UI)과 ProductListTable(Sub-Widget)로 쪼개어, 위젯이 '직접 그리기'보다는 '조립하기' 에 집중하도록 설계했습니다.

3. 전역 상태(Zustand) 도입과 생명주기 관리

useState에서 Zustand로 마이그레이션하며 발생한 테스트 격리 문제를 해결하는 과정에 깊은 고민을 담았습니다.

• 컴포넌트가 언마운트되어도 메모리에 남는 전역 스토어의 특성 때문에 통합 테스트가 실패하는 현상을 겪었습니다.
• 이를 해결하기 위해 App.tsx 마운트 시점에 스토어를 강제로 초기화하는 전략을 사용하여, 전역 상태의 편리함과 테스트 환경의 독립성을 모두 확보했습니다.

---

이번 과제를 통해 앞으로 해보고 싶은게 있다면 알려주세요!

Server State와 Client State의 분리

이번 과제에서는 localStorage를 사용하여 클라이언트 사이드에서 데이터를 저장했습니다. 하지만 실제 서비스 환경을 고려하여, React Query(TanStack Query) 를 도입해 비동기 데이터와 UI 상태를 FSD 아키텍처 안에서 어떻게 효율적으로 관리할지 고민해보고 경험해보고 싶습니다.

이번 과제를 통해 얻은 가장 큰 깨달음:

"좋은 아키텍처는 코드의 위치가 곧 의도를 말한다."

FSD와 FP 원칙을 적용하면서, 폴더 구조 자체가 하나의 명세서이자 설계도 가 될 수 있다는 것을 체감했습니다. 비록 모든 폴더 구조가 FSD 일수도 없고, 항상 정답도 아니지만 FSD 경험을 토대로 더 복잡한 비즈니스 로직과 사용자 경험을 다루는 프로젝트에 도전하고 싶습니다.
무엇보다 어떤 설계나 디자인 패턴이 좋아보여서 따라하고 적용하는게 중요한게 아닌, 어떤 관점과 기준에서 내 프로젝트에 적용했고 그 적용한 이유를 설명가능하며 그 이유가 나의 팀원과 조직을 설득시킬 수 있는지 여부가 더 중요하다고 느꼈습니다.
세상엔 정말 많은 패턴과 설계방법, 프로그래밍 패러다임이 존재하며 이번 FSD + FP는 좋은 경험이였지만 "항상 이 설계, 이 방법으로 프로그래밍 하겠어" 라는 생각으로 매몰되지는 말아야지 생각했습니다.

리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문 편하게 남겨주세요 :)

1. 아키텍처 및 구조 관점 (FSD)

Q. Feature와 Entity의 경계 및 위젯의 역할 축소에 대해 의견이 궁금합니다.
이번 리팩토링에서 장바구니 계산 로직(calculateCartTotal)은 entities로, 상태 관리(useCart)는 features로 분리했습니다.
특히 AdminDashboard 위젯이 가지고 있던 폼 상태와 유효성 검사 로직까지 features 레이어(ProductManagementForm 등)로 내리면서 위젯이 오로지 조립 역할만 하게 되었는데요.
이 구조가 FSD의 의도에 부합하는지, 혹은 위젯이 너무 껍데기만 남은 것은 아닌지 아키텍처 관점에서의 피드백이 궁금합니다.

2. 상태 관리 및 동기화 관점 (Zustand & Sync)

Q. App.tsx에서의 수동 데이터 동기화 패턴이 적절한지 궁금합니다.
Zustand의 persist 미들웨어를 사용하는 대신, persist를 제거하고 App.tsx에서 useEffect를 통해 로컬스토리지와 스토어를 수동으로 동기화하는 방식을 택했습니다.
이는 테스트 환경에서의 격리와 레거시 데이터 호환성을 확보하기 위함이었는데요. 이 패턴이 장기적인 유지보수 측면에서도 유효할지, 혹은 더 나은 대안이 있을지 의견이 궁금합니다.