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

[1lmean]

과제의 핵심취지

• 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의 책임에 맞도록 코드가 분리가 되었나요?

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

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

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

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

심화과제

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

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

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

• Context나 Jotai를 사용해서 전역상태관리를 구축했나요? >> Zustand 사용했습니다.

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

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

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

배포 링크

https://1lmean.github.io/front_7th_chapter3-2/

과제 셀프회고

뭔가 딥다이브하며 ... 공부해보려고 시도해보았으나 워낙 몰랐던 내용이 많아서 또 겉핥기가 됐다는 생각이 들었습니다. 항해 끝나고 이런 내용들 다 정리하려고 하면 아마 머리 터질 것 같은데 진짜 큰일난 것 같습니다.

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

1. 함수형 프로그래밍의 핵심: 데이터/계산/액션 분류

이론적인 것들이 항상 잘 와닿지 않는 편인데 적용하려고 노력해보니 감이 조금 왔던것 같습니다.

분류	설명	프로젝트 적용
📦 데이터 (Data)	불변의 값, 이벤트에 대한 사실	constants/index.ts (initialProducts, initialCoupons)
🧮 계산 (Calculation)	순수함수, 같은 입력 → 항상 같은 출력	models/cart.ts (calculateCartTotal, getMaxApplicableDiscount)
⚡ 액션 (Action)	부작용 있음, 외부 세계와 상호작용	hooks/useCart.ts, hooks/useProducts.ts

핵심 깨달음: 액션을 최소화하고, 가능한 많은 로직을 계산(순수함수)으로 옮겨야 테스트/재사용/이해가 쉬워집니다.

// ❌ Before: 액션 안에 계산이 섞여있음
const addToCart = (product) => {
  const discount = Math.max(...product.discounts.map((d) => d.rate)); // 계산
  const newItem = { ...product, appliedDiscount: discount }; // 계산
  setCart((prev) => [...prev, newItem]); // 액션
};

// ✅ After: 계산을 models/로 분리
// models/cart.ts
export const createCartItem = (product) => ({
  ...product,
  appliedDiscount: getMaxDiscount(product.discounts),
});

// hooks/useCart.ts (액션만 남음)
const addToCart = (product) => {
  const newItem = createCartItem(product); // 계산 호출
  setCart((prev) => [...prev, newItem]); // 액션
};

2. 계층 구조와 의존성 방향

┌─────────────────────────────────────────────────┐
│                    UI Layer                      │
│         (Components, Pages)                      │
│                     ↓                            │
├─────────────────────────────────────────────────┤
│                Features Layer                    │
│         (Hooks, Context, Store)                  │
│                     ↓                            │
├─────────────────────────────────────────────────┤
│                Entities Layer                    │
│     (Models, Pure Functions, Types)              │
└─────────────────────────────────────────────────┘

• 상위 계층은 하위 계층에 의존 가능
• 하위 계층은 상위 계층에 의존하면 안 됨
• Entities(models/)는 React에 의존하지 않음 → 테스트 가장 쉬움

3. Result 패턴으로 Cross-Cutting Concerns 처리

Result 패턴이란?

Result 패턴은 함수의 성공/실패를 **예외(Exception)**가 아닌 반환값으로 표현하는 함수형 프로그래밍 패턴입니다.

// ❌ 예외를 던지는 방식
const addToCart = (product) => {
  if (noStock) throw new Error("재고 없음"); // 예외 발생
  setCart(...);
};

// ✅ Result 패턴
const addToCart = (product): { success: boolean; message: string } => {
  if (noStock) return { success: false, message: "재고 없음" }; // 결과 반환
  setCart(...);
  return { success: true, message: "담았습니다" };
};

왜 예외 대신 Result 패턴을 사용하는가?

측면	예외(Exception)	Result 패턴
명시성	함수 시그니처에서 실패 가능성 안보임	반환 타입에서 실패 가능성이 명확히 드러남
제어 흐름	try-catch로 흐름이 복잡해짐	if-else로 명확한 분기
강제성	예외 처리를 잊을 수 있음	반환값을 처리해야 함 (TypeScript)
합성	예외는 합성하기 어려움	결과를 체이닝 가능

이 과제에서 Result 패턴을 사용한 이유

기본과제 조건: Context를 사용하지 않고 구현해야 함

문제 상황: useCoupons 훅에서 addNotification을 호출하려고 했는데, addNotification은 useNotification 훅에서 관리되어 접근할 수 없었습니다.

// hooks/useCoupons.ts - 문제 상황
const addCoupon = (newCoupon) => {
  if (existingCoupon) {
    addNotification("이미 존재하는 쿠폰", "error"); // 🚨 addNotification이 없음!
    return;
  }
  setCoupons((prev) => [...prev, newCoupon]);
  addNotification("쿠폰 추가됨", "success"); // 🚨 addNotification이 없음!
};

┌─────────────────────────────────────────────────┐
│                   문제 상황                       │
│                                                  │
│  useProducts ──┐                                │
│                │                                │
│  useCoupons ───┼──→ useNotification (공유 필요)  │
│                │                                │
│  useCart ──────┘                                │
│                                                  │
│  → Context 없이는 공유가 어려움!                   │
└─────────────────────────────────────────────────┘

해결: Result 패턴으로 결과만 반환하고 App에서 notification 처리

// hooks/useCoupons.ts - 결과만 반환
const addCoupon = (newCoupon): { success: boolean; message: string } => {
  if (existingCoupon) {
    return { success: false, message: "이미 존재하는 쿠폰" };
  }
  setCoupons((prev) => [...prev, newCoupon]);
  return { success: true, message: "쿠폰 추가됨" };
};

// App.tsx - notification 처리
const handleAddCoupon = (coupon) => {
  const result = addCoupon(coupon);
  addNotification(result.message, result.success ? "success" : "error");
};

┌─────────────────────────────────────────────────────────┐
│                        App.tsx                           │
│                                                          │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐  │
│  │ useProducts  │  │ useCoupons   │  │   useCart    │  │
│  │              │  │              │  │              │  │
│  │ return {     │  │ return {     │  │ return {     │  │
│  │   success,   │  │   success,   │  │   success,   │  │
│  │   message    │  │   message    │  │   message    │  │
│  │ }            │  │ }            │  │ }            │  │
│  └──────────────┘  └──────────────┘  └──────────────┘  │
│         │                 │                 │           │
│         └─────────────────┼─────────────────┘           │
│                           ▼                             │
│                   addNotification()  ← 한 곳에서 처리    │
│                                                          │
└─────────────────────────────────────────────────────────┘

Result 패턴의 장점

장점	설명
의존성 제거	도메인 훅이 notification에 의존하지 않음
테스트 용이	훅 테스트 시 notification mock 불필요
유연성	호출하는 쪽에서 결과를 원하는 방식으로 처리 가능
일관성	모든 notification이 App에서 처리되어 일관된 UX

비슷한 패턴들

함수형 프로그래밍에서는 비슷한 패턴들이 있습니다:

패턴	용도	반환값
Result	성공/실패 + 메시지	{ success, message } 또는 { success, data }
Either	성공/실패 + 타입이 다른 값	Left<Error> / Right<Value>
Option/Maybe	값이 있거나 없음	Some<Value> / None
Try	예외를 안전하게 감싸기	{ success, value } / { success, error }

더 복잡한 프로젝트에서는 neverthrow나 fp-ts 같은 라이브러리를 사용하면 체이닝, 에러 변환 등이 편리해집니다.

4. Props 제거 기준

심화과제에서 어떤 props를 남기고 어떤 props를 제거할지 기준을 세웠습니다:

Props 유형	제거/유지	이유
products, cart, coupons	❌ 제거	Store에서 직접 가져올 수 있음
addToCart, removeFromCart	❌ 제거	Store에서 직접 가져올 수 있음
addNotification	❌ 제거	Store에서 직접 가져올 수 있음
product, item	✅ 유지	도메인 엔티티 props - 재사용성
onEdit, onAddNew	✅ 유지	UI 흐름 제어 props
onClick, onChange	✅ 유지	이벤트 핸들러 props

5. Zustand vs Redux 비교 경험

실무에서 Redux를 사용해봤지만, 이번에 Zustand를 써보니 훨씬 간결하고 편리했습니다:

특성	Redux	Zustand
보일러플레이트	많음 (action, reducer, store 설정)	적음 (create 하나로 끝)
미들웨어	redux-thunk, redux-saga 등 별도 설정	내장 미들웨어 (persist, devtools)
학습 곡선	높음	낮음
번들 사이즈	큼	작음
타입 추론	수동 설정 필요	자동 추론

// Zustand: 심플!
export const useCartStore = create<CartState>()(
  persist(
    (set, get) => ({
      cart: [],
      addToCart: (product) =>
        set((state) => ({ cart: addItemToCart(state.cart, product) })),
      getTotals: () => calculateCartTotal(get().cart, get().selectedCoupon),
    }),
    { name: "cart" }
  )
);

6. Zustand 테스트 시 주의사항

Zustand store는 전역 싱글톤이므로 테스트 간에 상태가 공유됩니다.
각 store에 reset 메서드를 추가하고 beforeEach에서 호출해야 합니다:

// Store에 reset 메서드 추가
reset: () => {
  set({ cart: [], selectedCoupon: null });
},
  // 테스트에서 초기화
  beforeEach(() => {
    localStorage.clear();
    useCartStore.getState().reset();
    useProductStore.getState().reset();
    useCouponStore.getState().reset();
    useNotificationStore.getState().reset();
  });

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

1. 순수함수 분리와 테스트 가능성

models/cart.ts에 순수함수들을 분리할 때, 모든 의존성을 파라미터로 받도록 했습니다:

// ❌ 외부 상태 참조 (순수하지 않음)
const calculateCartTotal = () => {
  return cart.reduce((sum, item) => sum + item.price, 0); // cart를 직접 참조
};

// ✅ 파라미터로 전달 (순수함수)
export const calculateCartTotal = (
  cart: CartItem[],
  selectedCoupon: Coupon | null
) => {
  // 모든 필요한 데이터를 파라미터로 받음
};

이렇게 하면 React 없이도 단위 테스트가 가능합니다.

2. 훅의 책임 분리

각 훅이 어떤 상태를 "소유"해야 하는지 고민했습니다:

상태	소유 훅	이유
products	useProducts	상품 CRUD의 주체
coupons	useCoupons	쿠폰 CRUD의 주체
cart	useCart	장바구니 조작의 주체
selectedCoupon	useCart	cart 계산에 필요

처음에 selectedCoupon을 useCoupons에 넣었다가, cart 총액 체크가 필요해서 useCart로 이동했습니다.

3. Props Drilling vs 전역 상태의 균형

모든 props를 제거하는 것이 아니라, 도메인 엔티티 props는 유지했습니다:

// ❌ 이것까지 제거하면 재사용성이 떨어짐
<CartItem item={cartItem} />

// ✅ 도메인 엔티티는 props로 전달
<CartItem item={cartItem} />  // 재사용 가능

4. Compound Components 패턴 적용

저번주 준일 코치님께서 폼 분리 관련해서 Compound Components 패턴을 언급해주셔서 ProductForm에 적용해봤습니다:

<ProductForm.Root
  formData={formData}
  setFormData={setFormData}
  onSubmit={handleSubmit}
>
  <ProductForm.Title>
    {mode === "create" ? "새 상품 추가" : "상품 수정"}
  </ProductForm.Title>
  <ProductForm.Fields />
  <ProductForm.Discounts />
  <ProductForm.Actions>
    <ProductForm.CancelButton onClick={resetForm} />
    <ProductForm.SubmitButton>
      {mode === "create" ? "추가" : "수정"}
    </ProductForm.SubmitButton>
  </ProductForm.Actions>
</ProductForm.Root>

솔직한 평가: Create와 Edit의 차이가 제목/버튼 텍스트뿐이라 오버엔지니어링이었고 코드가 더 복잡해졌다고는 생각하지만 "언제 이 패턴이 필요한지 배웠다"에 더해 "해당 컴포넌트 설계 패턴을 경험해보았다"는 점에서 의미 있는 경험이었습니다.

적절한 상황: UI가 복잡하고 유연한 조합이 필요할 때 (예: 여러 레이아웃 옵션, 커스텀 섹션 추가 등)

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

1. 테스트 커버리지 강화

1. Zustand 전역 상태 설계 패턴 더 실험해 보기

   • 이번 과제에서는 productStore, cartStore, couponStore, notificationStore를 도메인별로 분리하는 데 집중했습니다.
   • 앞으로는 각 store의 책임 범위와 의존 방향을 더 명확히 나누고,
     • store 간 의존성이 필요할 때 getState()로 바로 물어보는 대신
       • selector 기반 합성 훅(useEnrichedCartItems처럼 cart + product join 전용 훅)
       • 도메인 서비스 레이어(domain/cartService.ts처럼 비즈니스 로직을 store 밖으로 분리)
     • 등을 사용하는 패턴을 더 의도적으로 실험해 보고 싶습니다.

2. 도메인 경계와 store 간 권한 설계

   • cart가 product의 전체 shape를 아는 대신, productId, quantity 같은 참조 정보만 들고 있게 만드는 구조가 더 낫다고 생각했는데, 적용까지 못한 점이 아쉽습니다.
   • 앞으로는
     • 어떤 도메인에서 “원시 상태(domain state)”까지만 들고 있고
     • 어떤 레이어에서 “조합된 뷰 모델(joined view model)”을 만들지
   • 이 경계를 더 잘 정의하는 연습을 해보고 싶습니다.

3. UI 설계 패턴 적용 기준 다듬기 (Compound Components 등)

   • ProductForm에 Compound Components 패턴을 적용해 보면서,
     • “패턴을 쓸 수 있는 상황”과
     • “굳이 안 써도 되는 상황(=심플한 props 분기가 더 나은 경우)”
   • 을 조금 체감할 수 있었습니다.
   • 앞으로는 폼이나 복잡한 UI를 만들 때
     • 언제 Compound Components / Context를 쓰고
     • 언제 단일 컴포넌트 + props만으로 푸는 게 맞는지
   • 이런 패턴 선택 기준을 실제 사례를 통해 더 정교하게 가져가 보고 싶습니다.

4. 전역 상태 범위를 결정하는 기준 잡기

   • searchTerm처럼 “전역으로도, 로컬로도 갈 수 있는 애매한 상태”를 보면서,
     • 어떤 상태를 store로 끌어올리고
     • 어떤 상태는 컴포넌트 내부 useState에 남길지
   • 명확한 기준이 아직 없다는 걸 느꼈습니다.
   • 필터, 검색어, 정렬 옵션, 선택 상태 등에서
     • “페이지 간 공유 필요 여부”
     • “URL/딥링크와의 연계 필요성”
   • 같은 관점으로 전역화 기준을 정리해 보고 싶습니다.

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

1. 훅의 의존성 주입 방식

basic 버전에서 useCart(products)처럼 의존성을 주입받았는데, advanced에서는 useProductStore.getState()로 다른 store에 접근했습니다:

// basic: 의존성 주입
export function useCart(products: Product[]) {
  const updateQuantity = (productId, quantity) => {
    const product = products.find((p) => p.id === productId);
    // ...
  };
}

// advanced: 다른 store 접근
updateQuantity: (productId, quantity) => {
  const { products } = useProductStore.getState();
  const product = products.find((p) => p.id === productId);
  // ...
};

질문: Zustand에서 store 간 의존성이 있을 때, getState() 방식이 적절한가요? 아니면 다른 패턴이 있나요?

2. Compound Components vs 심플한 Props 분기

ProductForm에 Compound Components를 적용했는데, 실제로는 심플한 분기가 더 나았을 것 같습니다:

// 심플 버전
const ProductForm = ({ mode }: { mode: "create" | "edit" }) => {
  const config = {
    create: { title: "새 상품 추가", submitText: "추가" },
    edit: { title: "상품 수정", submitText: "수정" },
  };
  // ...
};

질문: Compound Components 패턴이 정말 필요한 상황의 기준이 있을까요?

3. 전역 상태 범위 결정 기준

searchTerm을 전역 상태(Store)로 관리할지, 로컬 상태(useState)로 관리할지 고민했습니다. 현재는 ProductList 내부에서 로컬로 관리 중인데:

질문: 어떤 상태를 전역으로 올려야 하는지 판단 기준이 있을까요?

구현 내용 상세

📁 폴더 구조 (Basic)

src/basic/
├── models/           # 🧮 순수함수 (계산)
│   └── cart.ts       # calculateCartTotal, addItemToCart, getRemainingStock 등
│
├── hooks/            # ⚡ 커스텀 훅 (액션)
│   ├── useCart.ts
│   ├── useProducts.ts
│   ├── useCoupons.ts
│   ├── useProductForm.ts
│   ├── useDebounce.ts
│   └── useNotification.ts
│
├── features/         # 🎨 도메인 컴포넌트
│   ├── admin/        # ProductTable, ProductForm (Compound), Tabs
│   └── main/         # ProductList, CartList, CheckoutSection
│
├── components/       # 🎨 범용 UI 컴포넌트
│   ├── Header.tsx (Compound)
│   ├── Button.tsx
│   └── Toast.tsx
│
├── pages/
│   ├── MainPage.tsx
│   └── AdminPage.tsx
│
├── constants/        # 📦 데이터
│   └── index.ts      # initialProducts, initialCoupons
│
└── utils/            # 🔧 유틸리티
    └── formatter.ts

📁 폴더 구조 (Advanced - Zustand)

src/advanced/
├── store/            # 🏪 Zustand Stores
│   ├── useProductStore.ts
│   ├── useCartStore.ts
│   ├── useCouponStore.ts
│   └── useNotificationStore.ts
│
├── models/           # 🧮 순수함수 (동일)
│   └── cart.ts
│
├── features/         # 🎨 컴포넌트 (Store에서 직접 상태 가져오기)
│   ├── admin/
│   └── main/
│
└── pages/            # Props 완전 제거
    ├── MainPage.tsx   # 118줄 → 20줄 (83% 감소)
    └── AdminPage.tsx  # 88줄 → 51줄 (42% 감소)

📊 Props 제거 통계 (심화과제)

컴포넌트	Before	After	감소율
MainPage	6개	0개	100%
AdminPage	8개	0개	100%
CartList	3개	0개	100%
ProductList	4개	0개	100%
CheckoutSection	6개	0개	100%
CouponList	4개	0개	100%
총계	28개	8개	71% 감소

📊 App.tsx 간소화 (심화과제)

항목	Before	After	감소율
줄 수	1125줄	40줄	96% 감소
상태 관리	useState 10개+	isAdmin 1개	90% 감소
비즈니스 로직	컴포넌트 내부	models/ + store/	분리 완료

상태관리 라이브러리 선택 이유 (Zustand)

왜 Zustand를 선택했는가?

1. 트렌드: 현시점 가장 많이 사용되는 상태관리 라이브러리 중 하나
2. 경험 확장: 실무에서 Redux만 사용해봤기 때문에, 다양한 라이브러리 경험 필요
3. Context 경험 완료: 저번주 과제에서 Context API를 사용해봤음
4. 간결함: Redux 대비 보일러플레이트가 훨씬 적고 편리함

실제 사용 후기

현업에서는 Redux 설정 코드가 많아 유지보수 비용이 컸고, Redux Toolkit까지 혼재되면서 구조가 다소 더러운 상태로 프로젝트를 진행했었는데, Zustand를 사용해보니 create() 기반으로 상태 관리를 간결하게 구성하면서 보일러플레이트를 크게 줄였고, 개발 흐름이 훨씬 단순하고 직관적이라는 생각이 들었습니다.

// Zustand: 한 파일에 상태 + 액션 정의
export const useCartStore = create<CartState>()(
  persist(
    (set, get) => ({
      cart: [],
      selectedCoupon: null,

      addToCart: (product) => {
        const remaining = getRemainingStock(product, get().cart);
        if (remaining <= 0) return { success: false, message: "재고 부족" };
        set((state) => ({ cart: addItemToCart(state.cart, product) }));
        return { success: true, message: "담았습니다" };
      },

      getTotals: () => calculateCartTotal(get().cart, get().selectedCoupon),
    }),
    { name: "cart" }
  )
);

---

4팀 코드리뷰

• 다들 ... 어떤 상태관리 라이브러리를 추천하시나요, 혹은 현업에서 어떤 라이브러리를 사용하고 계신가요? 저는 Redux를 사용했던 터라 Zustand의 존재는 알고 있었지만 편의성의 체감은 이번에서야 했는데, Jotai는 더 편하다면 저는 왜 리덕스를 사용했었나 의문입니다.
  두 가지 라이브러리를 모두 사용해보신 분이 ... 있으실까요.