[2팀 장운서] Chapter 2-2. 디자인 패턴과 함수형 프로그래밍

[unseoJang]

배포 링크

https://unseojang.github.io/front_5th_chapter2-2/

과제의 핵심취지

• 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는 분리되어 있나요?

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

심화과제

• 재사용 가능한 Custom UI 컴포넌트를 만들어 보기

• 재사용 가능한 Custom 라이브러리 Hook을 만들어 보기

• 재사용 가능한 Custom 유틸 함수를 만들어 보기

• 그래서 엔티티와는 어떤 다른 계층적 특징을 가지는지 이해하기

• UI 컴포넌트 계층과 엔티티 컴포넌트의 계층의 성격이 다르다는 것을 이해하고 적용했는가?

• 엔티티 Hook과 라이브러리 훅과의 계층의 성격이 다르다는 것을 이해하고 적용했는가?

• 엔티티 순수함수와 유틸리티 함수의 계층의 성격이 다르다는 것을 이해하고 적용했는가?

과제 셀프회고

과제를 하면서 내가 제일 신경 쓴 부분은 무엇인가요?

이번 과제에서 가장 신경 쓴 부분은 기능 구현보다 구조적인 코드 리팩토링과 역할 분리였습니다. 기존 코드가 하나의 컴포넌트 내부에 상태와 로직, UI가 얽혀 있는 구조였기 때문에, 이를 어떻게 책임 단위별로 나누고 유지보수 가능하게 만들 것인지에 대한 고민을 많이 했습니다.

먼저, CartPage와 AdminPage는 상태와 UI 요소가 얽혀 있는 구조였기 때문에, 이를 ProductList, CartList, DiscountEditor, CouponAdmin, OrderSummary 등의 재사용 가능한 컴포넌트 단위로 분리하면서 UI 로직과 상태 관리 로직의 관심사를 분리하고자 했습니다. 이 작업은 단순히 컴포넌트를 나누는 것이 아니라 props 전달 흐름과 로컬 상태의 책임 분산까지 고려해야 했기 때문에 많은 테스트와 수정을 반복해야 했습니다.

또한, useCart 커스텀 훅을 중심으로 장바구니 상태를 관리하도록 구현하면서, 단순한 상태 저장을 넘어서 쿠폰 적용, 수량 업데이트, 할인율 계산 등의 로직을 모두 유틸리티 함수로 분리하여 추상화하였습니다. 이를 통해 로직이 분산되는 것을 방지하고 중앙 집중적으로 비즈니스 로직을 테스트하고 관리할 수 있게 하였습니다.

이처럼 단순히 UI를 잘 보이게 만드는 것보다는, 디자인 패턴의 관점에서 역할 분리와 확장성, 테스트 용이성을 가장 신경 쓰며 작업했습니다. 실제로 이후 기능이 추가되거나 수정될 때 훨씬 수월하게 대응할 수 있을 것이라는 확신도 생겼고, 이런 구조화를 통해 코드에 대한 자신감도 높아졌습니다.

1. UI와 로직의 관심사 분리

초기에는 CartPage와 AdminPage 컴포넌트 내부에 비즈니스 로직과 UI가 뒤섞여 있었기 때문에, 이를 ProductList, CartList, DiscountEditor, CouponAdmin, OrderSummary 등의 컴포넌트로 분리하였습니다. 각 컴포넌트는 순수 UI 출력과 최소한의 인터랙션만 처리하고, 로직은 커스텀 훅 또는 유틸 함수로 분리함으로써 역할이 명확해지도록 리팩토링했습니다.

2. 커스텀 훅 및 유틸리티 함수 작성

장바구니 상태와 관련된 로직은 useCart 훅에 통합하였고, 그 안에서도 createNewCartItem, increaseCartItemQuantity, calculateCartTotal 등의 유틸 함수를 통해 로직을 계층적으로 나누었습니다. 특히 calculateItemTotal, getMaxApplicableDiscount 등을 통해 할인 계산 로직을 재사용 가능한 구조로 추출했습니다.

또한 로컬 스토리지를 통해 장바구니 상태를 유지할 수 있도록 useLocalStorage 커스텀 훅을 직접 구현하고 적용했습니다. 이 훅은 제네릭 타입을 기반으로 되어 있어 다양한 타입의 데이터를 안전하게 저장하고 불러올 수 있도록 설계했으며, 실제로 장바구니 데이터를 localStorage에 반영하는 데 성공했습니다.

3. 테스트 코드 작성 및 통과 경험

테스트 측면에서는 useCart 훅에 대한 단위 테스트를 작성하며 상태 변경에 따른 계산 결과 검증을 시도했습니다. addToCart, updateQuantity, applyCoupon, calculateTotal 등의 기능별로 테스트를 나누어 작성했고, 비즈니스 로직이 명확히 분리되어 있었기에 테스트 작성이 훨씬 용이했습니다.

특히, calculateTotal() 함수의 결과값이 정확히 예상대로 동작하는지를 검증하면서 로직을 몇 차례 수정하게 되었고, 이를 통해 테스트가 코드 안정성을 확보하는 도구로서 어떤 역할을 할 수 있는지를 체감할 수 있었습니다.

4. msw를 활용한 목(mock) 서버 구현

외부 API 연동이 없는 과제였지만, 실제 서비스에 가까운 구조를 위해 msw(Mock Service Worker)를 도입해 목 서버를 구축했습니다. 초기 제품 목록과 쿠폰 목록은 mocks/mockData.ts에서 정의했고, 이를 기반으로 실제 fetch 요청을 대체하여 클라이언트 로직이 서버 의존 없이 동작할 수 있도록 했습니다.

또한 개발 환경에서만 msw가 동작하도록 main.tsx에 조건부 로딩 로직을 넣었고(if (import.meta.env.MODE === 'development')), 테스트에서도 동일한 데이터로 상태를 시뮬레이션하면서 테스트의 신뢰도와 유지보수성을 높였습니다.

과제를 다시 해보면 더 잘 할 수 있었겠다 아쉬운 점이 있다면 무엇인가요?

1. 만들어볼 수 있는 훅 혹은 함수 예시를 다 진행하지 못한점

만들어볼 수 있는 훅 혹은 함수 예시 중에
1. `useLocalStorage`: 로컬 스토리지를 사용하여 장바구니 상태를 저장하고 불러오는 훅
2. `useDiscountCalculator`: 할인 계산 로직을 분리한 훅
까지만 진행하고 
3. useProductSearch: 상품 검색 기능을 위한 훅
4. formatCurrency: 통화 형식을 지정하는 유틸 함수
5. 5. debounce: 입력 지연을 위한 유틸 함수
6. validateProductData: 상품 데이터 유효성 검사 함수
7. useForm: 폼 상태 관리를 위한 커스텀 훅
는 시간이슈로 진행해보지 못했던 것들이 좀 아쉽습니다.

2. React 상태관리 시스템 (Redux, Zustand)등을 써보지 못한점

컴포넌트 분리, 기본에 충실하기 위해 되도록 context를 써가면서 작업을 진행했습니다. 추후에 과제를 한번 더 진행해본다면 React 상태관리 시스템을 써서 다시 한번 진행해 볼 것 같습니다.

3. 공통 UI 컴포넌트화와 재사용성 부족

현재 `AdminInput`, `NewProductInput`, `select`, `input`, `button` 등 많은 UI 요소들이 반복적인 형태로 존재했지만, 공통 컴포넌트로 완전히 추상화하지 못했습니다.
예를 들어, `input`, `select`, `button`의 스타일과 유효성 검증 로직을 통합한 `FormInput` 컴포넌트와 custom hook을 만들었다면 생산성과 유지보수성이 높아졌을 것 같습니다.

4. 테스트 커버리지의 편차

핵심 로직에 대해서는 Vitest + RTL 기반 테스트를 작성했지만,
분리된 컴포넌트(ProductList, CartList, CouponSelector)들에 대한 단위 테스트는 미처 작성하지 못한 점이 아쉬웠습니다.
다음에는 각 컴포넌트 단위로 테스트를 구성해서 회귀 테스트에 강한 구조를 만들고 싶습니다.

5. 커스텀 훅의 테스트 작성 누락

`useLocalStorage` 훅이나 `useCart`의 내부 유틸 함수에 대한 테스트는 작성했지만, 각 훅 자체를 독립적으로 테스트하는 습관이 부족했던 것도 느꼈습니다.

특히 로컬스토리지와 같이 side effect가 있는 훅의 경우, mocking과 초기화에 대한 테스트 시나리오를 더 치밀하게 구성할 수 있었을 것 같아요.

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

• 컴포넌트 분리 기준이 적절했는지 피드백 받고 싶습니다. 예를 들어, CartList, ProductList, CouponSelector, OrderSummary를 별도 컴포넌트로 분리했는데, 이 정도 단위가 괜찮은지 혹은 더 세분화/통합할 수 있는 구조였는지 궁금합니다.
• 비즈니스 로직과 UI의 분리 방향이 적절했는지 궁금합니다. useCart 내부에서 계산/상태 업데이트 관련 로직을 처리하고, 계산 함수들을 유틸/모델 계층으로 분리했는데 이러한 구조가 명확하고 유지보수 측면에서 괜찮은지 궁금합니다.
• MSW를 활용해 mock 서버를 구성했는데, 이 방식이 과제처럼 UI 중심 개발에 효과적인 접근인지, 혹은 실제 실무에서 더 나은 방식이 있다면 알려주시면 감사하겠습니다.
• 전반적으로 제가 과제에서 보인 설계 관점/패턴 적용 방식이 적절했는지 평가해주시면 좋을 것 같습니다.

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

리뷰 수고하셨습니다~!!감사합니다 코치님
질문은 위에 모두 적었습니다