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

[piggggggggy]

과제의 핵심취지

• 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는 잘 제거했나요?

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

배포 링크

링크

과제 셀프회고

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

1. '나 함수형 프로그래밍/사고 잘 모르네..?'

React / Vue 위주로 개발 해왔지만, 스스로 함수형 사고를 잘 하고 있나? 라는 고민은 많이 해보지 않은 것 같습니다. 어떻게 보면 '당연하게 하고 있지 않을까?' 라는 생각으로 해왔던 것 같습니다. 이번에 가볍게라도 함수형 사고를 시도해보며, 부족함을 많이 느꼈습니다. 때문에 함수형 사고를 본격적으로 관심을 갖고 시도해볼 좋은 기회였다고 생각합니다.

2. 함수형 사고 / 함수형 프로그래밍이란?

이번에 배운 Functional Programming을 정리해보자면,

• 복잡성을 관리/통제하기 위함
• '어떻게'가 아닌 '무엇을'의 관점에서 사고하는 선언적인 방식
• 예측 가능성 (순수함수, 예측 가능한 변경)
• 테스트 용이성 (입/출력만 검증)
• 디버깅과 추론 (변하는 것과 변하지 않는 것을 구분, 부수 효과 격리)

일단, 이렇게 정리해볼 수 있을 것 같습니다.

조금 더 과제에 실용적인 관점으로 대입해보자면,

• 최대한 순수하게 분리된 비즈니스 로직
• 불변성을 고려한 비즈니스 로직과 상태 관리
• 단일 책임 원칙을 고려한 함수 작성
• 부수효과 격리
• 테스트 용이성, 매직 넘버 관리... 등...

일 것 같습니다.

처음에는 '이렇게 까지 분리해야할까? 내 눈에는 충분히 가독성 좋고, 문제 없어 보이는데...?' 라는 생각을 갖었습니다. 코드를 보는 관점이 협소해서 그런지 어느정도 리팩터링된 코드에 함수형 사고를 적용해 개선하는 것이 잘 납득 되지 않아, 실제로 작업을 시작하는데까지 시간이 오래 걸렸습니다. 특히 계산을 액션과 분리하는 것 자체는 납득이 되는데, 이를 모조리 추상화하고 더 나아가서 반복되는 계산 패턴을 한단계 더 추상화하는 것은(HOC, 합성 함수 등) 오버엔지니어링이 아닐까? 라는 생각을 하기도 했습니다. (이제 와서는 '너무 이론에 얽매여서 접근했나?'라고 생각하기도 합니다.)

무튼 이런 병목을 어느정도 깨준 것은 경험에 기반한 '테스트 용이성'이라는 접근이었습니다. 실제로 하나의 액션 함수에 계산과 액션이 추상화되지 않은 상태로 혼재할 때, 테스트 관점에서는 문제가 많겠다 라고 생각했고, 이렇게 작성된 코드에 추가 기능이 붙고 다른 누군가에 의해 수정되었을 때, 그리고 코드가 점점 규모화가 이뤄질 때 문제가 될 수 있겠구나 라는 생각을 하게 되었습니다. (물론 무조건적으로 이런 생각을 절대 진리로 코드를 작성하지는 않았고, 기본적으로 YAGNI 원칙을 준수하려고 노력했습니다.. -> HOC, 합성 함수 등은 패턴이 3개 이상 보이지 않으면 시도하지 않음)

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

**"납득 가능한 수준의 함수형 사고 적용"**에 집중했습니다. 테오가 예전에 준 피드백처럼 '과제라는 포멧에서 오버엔지니어링이 나쁜 것은 아니다'에 동의하지만, 이번엔 무작정 적용해보는 것보단, '왜 이렇게 해야 할까?'를 스스로 설명할 수 이쓴 범위 내에서 작업을 진행했습니다. 납득 없이 적용한 패턴은 체화되지 않을 것 같다고 생각했기 때문입니다...

하지만 앞으로의 코드 작성에 기본적인 함수형 사고를 자연스럽게 할 수 있겠다 라는 생각과, HOC / 합성 함수 같은 패턴들을 어디에 어떻게 제대로 활용해볼 수 있을까 라는 고민을 해볼 예정입니다.

적용 사례

1. 계산과 액션의 분리

// Origin : App.tsx - 컴포넌트 내부에 계산 로직 
  const getMaxApplicableDiscount = (item: CartItem): number => {
    const { discounts } = item.product;
    const { quantity } = item;
    
    const baseDiscount = discounts.reduce((maxDiscount, discount) => {
      return quantity >= discount.quantity && discount.rate > maxDiscount 
        ? discount.rate 
        : maxDiscount;
    }, 0);
    
    const hasBulkPurchase = cart.some(cartItem => cartItem.quantity >= 10);
    if (hasBulkPurchase) {
      return Math.min(baseDiscount + 0.05, 0.5); // 대량 구매 시 추가 5% 할인
    }
    
    return baseDiscount;
  };

  const calculateItemTotal = (item: CartItem): number => {
    const { price } = item.product;
    const { quantity } = item;
    const discount = getMaxApplicableDiscount(item);
    
    return Math.round(price * quantity * (1 - discount));
  };

// Advanced : entites/cart/utils.ts - 독립된 순수 함수 
export const getApplicableDiscount = (item: CartItem): number => {
  const { discounts } = item.product;
  const { quantity } = item;

  const baseDiscount = discounts.reduce((maxDiscount, discount) => {
    return quantity >= discount.quantity && discount.rate > maxDiscount
      ? discount.rate
      : maxDiscount;
  }, 0);

  return baseDiscount;
};

export const getBulkPurchaseDiscount = (cartItems: CartItem[]): number => {
  return cartItems.some(cartItem => cartItem.quantity >= BULK_PURCHASE_QUANTITY)
    ? BULK_PURCHASE_DISCOUNT
    : 0;
};

export const calculateItemTotal = (item: CartItem, cartItems: CartItem[]): number => {
  const { price } = item.product;
  const { quantity } = item;
  const baseDiscount = getApplicableDiscount(item);
  const bulkPurchaseDiscount = getBulkPurchaseDiscount(cartItems);
  const discount = Math.min(baseDiscount + bulkPurchaseDiscount, MAX_DISCOUNT);

  return Math.round(price * quantity * (1 - discount));
};

차이점:

• Origin: 컴포넌트의 cart 상태에 암묵적 의존
• Advanced: 모든 의존성을 매개변수로 명시 → 테스트 용이성

2. 매직 넘버 상수화

// Origin : App.tsx - 하드코딩된 값
  if (hasBulkPurchase) {
    return Math.min(baseDiscount + 0.05, 0.5);  // 매직 넘버
  }

  // App.tsx:309 - 분산된 매직 넘버
  if (currentTotal < 10000 && coupon.discountType === 'percentage') { ... 

// Advanced
  const BULK_PURCHASE_DISCOUNT = 0.05;
  const BULK_PURCHASE_QUANTITY = 10;
  const MAX_DISCOUNT = 0.5;
 ...
  const MIN_TOTAL_FOR_PERCENTAGE_COUPON = 10000;

3. 상태 관리 - Prop Drilling vs Context

// Origin (Prop Drilling) - addNotification이 모든 함수에 의존
  const addToCart = useCallback((product: ProductWithUI) => {
    // ...
    addNotification('장바구니에 담았습니다', 'success');
  }, [cart, addNotification, getRemainingStock]);

  // 사용처에 Prop Drilling으로 전달 필요

// Advanced (Context Provider)
export const NotificationProvider = ({ children }) => {
  const addNotification = useCallback(...);
  return <NotificationContext value={value}>{children}</NotificationContext>;
};

// 필요한 곳에서 직접 사용
const { addNotification } = useNotificationContext();

4. 부수효과 격리

// Origin - ID 생성 로직의 분산
const id = Date.now().toString();
...
const orderNumber = `ORD-${Date.now()}`;
...
id: `p${Date.now()}`

// Advanced - 중앙화된 ID 생성기
// utils/id-generator.ts
export const generateId = (prefix: string) =>
  `${prefix ? `${prefix}-` : ''}${Date.now().toString()}`;

5. 단일 책임 원칙 (SRP)

## Origin (하나의 파일이 모든 책임)

  App.tsx (1,123줄)
  ├── 상품 CRUD
  ├── 쿠폰 CRUD
  ├── 장바구니 로직
  ├── 알림 로직
  ├── 검색/필터
  ├── 가격 계산
  ├── localStorage 동기화
  ├── 폼 핸들링
  └── UI 렌더링 (500줄+)

## Advanced (책임별 분리)

  entities/
  ├── cart/utils.ts      → 장바구니 계산
  ├── coupon/utils.ts    → 쿠폰 검증/계산
  ├── product/utils.ts   → 상품 CRUD
  └── notification/      → 알림 타입/컴포넌트

  providers/
  ├── CartProvider.tsx   → 장바구니 상태
  ├── ProductProvider.tsx → 상품 상태
  ├── CouponProvider.tsx → 쿠폰 상태
  └── NotificationProvider.tsx → 알림 상태

  hooks/
  ├── useLocalStorageState.ts → 저장소 동기화
  └── useDebounce.ts → 검색 디바운스

6. 불변성

// Origin - 직접 배열 수정 패턴
  const newDiscounts = [...productForm.discounts];
  newDiscounts[index].quantity = parseInt(e.target.value) || 0;  // 객체 mutate
  setProductForm({ ...productForm, discounts: newDiscounts });

// Advanced - 새 배열 반환
export const getDeletedDiscounts = (discounts: Discount[], index: number): Discount[] =>
  discounts.filter((_, i) => i !== index);

...
const newDiscounts = productForm.discounts.map((d, i) => i === index ? { ...d, quantity: parseInt(value) } : d);

7. 재사용 가능한 훅

// hooks/useLocalStorageState.ts
// 커스텀 훅으로 추상화
import { Dispatch, SetStateAction, useEffect, useState } from 'react';
export const useLocalStorageState = <T>(key: string, initialValue: T) => {
  const [state, setState] = useState<T>(() => {
    const saved = localStorage.getItem(key);
    if (saved) {
      return JSON.parse(saved);
    }
    return initialValue;
  });

  useEffect(() => {
    localStorage.setItem(key, JSON.stringify(state));
  }, [state, key]);

  return [state, setState] as [T, Dispatch<SetStateAction<T>>];
};

8. 검증 로직 분리

// Origin (인라인 검증)
const addCoupon = useCallback((newCoupon: Coupon) => {
  const existingCoupon = coupons.find(c => c.code === newCoupon.code);
  if (existingCoupon) {
    addNotification('이미 존재하는 쿠폰 코드입니다.', 'error');
    return;
  }
  ...
}, [coupons, addNotification]);

// Advanced (검증 함수 분리)
export const canAddCoupon = (coupons: Coupon[], newCoupon: Coupon) => {
  const existingCoupon = coupons.find(c => c.code === newCoupon.code);
  return !existingCoupon;
};

// 사용처 - 검증과 액션 분리
if (!canAddCoupon(coupons, couponForm)) {
  addNotification('이미 존재하는 쿠폰 코드입니다.', 'error');
  return;
}

-> canAddCoupon은 순수 함수로 단위 테스트 가능

등...

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

실제 업무에서도! 당장 활용하고 개선해 볼 수 있을 것 같습니다. 그리고 이렇다 할 '좋은 코드란?'의 기준이나 문화가 없는 현재 팀에서 조금 더 뚜렷한 기준을 가지고 의견을 개진해 볼 수 있겠다 라는 생각을 했습니다.

남은 3주차 과제에 적극적으로 함수형 사고를 활용해 볼 생각입니다. 절대 코드량을 늘려서 밀도있게 함수형 사고/프로그래밍을 체화 해보고 싶습니다.

개인적으로 체화할 질문들

코드 작성/리뷰 시 스스로에게 던질 질문:

• "이 함수, 테스트 짜기 쉬울까?"
  → 어렵다면 분리 신호
• "이 함수가 알아야 할 것 vs 몰라도 되는 것은?"
  → 의존성 최소화, 필요한 것만 매개변수로
• "이 액션에서 '결정'과 '실행'이 분리되어 있나?"
  → 검증/계산(순수) → 상태변경(액션) 순서로 흐르는지
• "이 컴포넌트가 '무엇을' 하는지 한 문장으로 설명되나?"
  → 안 되면 책임이 섞여 있을 가능성

구체적으로 적용해볼 것들

• Claude Code의 Commit Workflow 활용
  • 함수형 사고 관점의 Review Process 추가/적용
  • 함수형 활용의 적절성, 추가 개선 포인트를 심층 리뷰 혹은 힌트 제공
• 업무에서 제품 코드에 점진적 적용
  • 새로 작성하는 코드부터 우선 적용
  • 기존 코드는 수정 기회가 올 때 부분적으로 개선

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

1. 고급 패턴(HOC, 합성 함수) 적용 기준에 대해

이번 과제에서 HOC나 합성 함수 같은 고급 패턴은 의도적으로 적용하지 않았습니다.

적용하지 않은 이유:

• 패턴화할 만큼 반복되는 케이스가 2개 이하였음
• YAGNI 관점에서 현재 필요하지 않은 추상화라고 판단
• 과제 규모 대비 오버엔지니어링이라는 생각

질문:

• 이런 고급 패턴을 "지금 적용해야 할 때"와 "아직 이르다"를 판단하는 기준이나 신호가 있을까요?
• 실무에서 이런 패턴들을 자연스럽게 활용하려면, 어떤 경험이나 연습이 도움이 될까요?

2. 비즈니스 로직 훅 분리의 필요성에 대해

현재 구조에서 비즈니스 로직을 담은 커스텀 훅(예 - useCartActions,useProductForm)은 분리하지 않았습니다. 계산 로직은 utils로 분리했지만, 상태 변경을 포함한 액션 로직은 컴포넌트에 남겨두었습니다.

현재 구조:

• entities/cart/utils.ts → 순수 계산 함수
• pages/CartView.tsx → 상태 변경 액션 (removeFromCart, updateQuantity 등)

고민했던 점:

• 훅으로 분리하면 컴포넌트는 더 얇아지지만, 오히려 로직 추적이 한 단계 더 들어가는 것 아닐까?
• 현재 규모에서 훅 분리가 실질적인 이점을 준다고 볼 수. 있을까?
• "충분히 복잡해졌을 때" 분리해도 괜찮지 않을까?

질문:

• 비즈니스 로직의 훅 분리, 어느 시점에서 하는 게 적절할까요?
• 훅으로 분리했을 때의 이점이 "로직 추적 복잡도 증가"를 상쇄할 만큼 명확한 기준이 있을까요?