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

[jumoooo]

과제의 핵심취지

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

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

과제 셀프회고

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

이번 과제를 진행하면서 “순수 함수 중심의 구조”가 테스트 가능성과 유지보수성에 얼마나 큰 영향을 주는지 체감했습니다. 입력과 출력이 명확한 형태로 구성하니 로직 검증이 쉬워졌고, 부수효과가 필요한 부분은 뒤쪽에서 한 번에 처리하는 흐름으로 정리되면서 코드가 한결 안정적으로 보였습니다.
컴포넌트끼리 props drilling이 많아지기 쉬운 구조였는데, 특정 도메인 단위로 props를 묶어 전달하는 방식으로 정리하다 보니 컴포넌트 응집도가 높아지고 사용성도 좋아졌습니다. 특히 Selector 컴포넌트는 구조가 깔끔하게 잡혀서 만족스럽게 완성할 수 있었습니다.

또한 장바구니 로직을 구현하면서 useMemo를 적절히 사용해 사전에 계산된 데이터를 넘겨주는 방식(예: filledItems)이 렌더링 비용을 확실히 줄여준다는 것도 배웠습니다. 특정 엔티티에 강하게 묶인 로직을 유틸 함수나 커스텀 훅으로 분리하는 기준도 자연스럽게 익힐 수 있었고, 클린 코드의 핵심이 “언제든 깔끔하게 지울 수 있을 정도로 단순하고 응집도 높은 구조”라는 점을 다시 확인할 수 있었습니다.

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

가능한 한 순수 함수 형태로 로직을 구성하고, 컴포넌트가 너무 많은 책임을 지지 않도록 계층을 나누는 데 가장 많은 신경을 썼습니다.
특히 ProductList → ProductItem에서 발생하는 props drilling 문제를 줄이기 위해 구조를 고민했고, 기존 Header처럼 지나치게 분리하기보다 필요한 정보를 각 도메인 단위로 묶어서 전달하는 방식으로 정리해 불필요한 의존을 줄였습니다.
또한 각 기능에서 전달되는 시그니처 함수들이 최소한의 역할만 가지도록 구조를 단순화했고, 전역 상태는 Zustand를 이용해 관리하며 불필요한 상태 전달을 최소화했습니다. 다만 Zustand를 도입하면서 아직 충분히 숙련되지 못해 상태 설계나 분리 기준을 더 깔끔하게 잡지 못한 아쉬움도 있었습니다.

상태 변경은 가능한 뒤쪽에서 한 번에 처리하도록 흐름을 잡았고, 재계산 비용이 많은 장바구니 영역은 useMemo로 선계산한 데이터를 내려 렌더링 성능을 신경 썼습니다. 전역적으로 사용될 가능성이 있는 가격 표시 함수(getDisplayPrice)도 분리해야겠다는 필요성을 느꼈고, 앞으로 개선할 예정입니다.

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

도메인별로 로직을 더 정교하게 분리하고, 공통으로 사용할 수 있는 유틸 함수 모음이나 테이블 컴포넌트 같은 공통 모듈을 직접 설계해 보고 싶습니다. 또 전역 상태 관리자로 Zustand를 도입해보면서 전반적인 흐름을 이해하게 되었기 때문에, 앞으로는 더 복잡한 상태 구조도 설계해보고 싶습니다.
추후에는 가격 계산, 할인 처리와 같은 반복되는 로직을 전역 레벨에서 재사용할 수 있도록 정리해 안정적인 구조를 계속 넓혀가보고 싶습니다.

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

도메인 단위로 props를 묶어서 전달하는 방식이 과하게 뭉친 형태는 아닌지, 더 나은 구조가 있을지 궁금합니다.