React의 확장성은 구조에 달려 있다

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

웹 개발

대상자

React 개발자, 팀 리더, 대규모 코드베이스 관리자

(난이도: 중급 이상)

핵심 요약

• React의 확장성은 컴포넌트 크기와 무관하고, 구조의 분리에 달려 있다
• 하나의 훅(hook)에 4가지 책임이 담긴 useSubscriptionFlow 예시는 분리 불가능한 코드의 대표 사례
• 데이터 fetching과 UI 로직 분리(useCustomerDashboard), 이펙트 분리(useBillingWarning), 임페리티브 오케스트레이션(AccountMigrationManager)의 3가지 핵심 패턴 제시

섹션별 세부 요약

1. 문제점: 대규모 컴포넌트

• 900+ 라인의 CustomerDashboard 컴포넌트는 데이터 fetching, feature flag 처리, date formatting, analytics 트리거, 모달 관리 등 다양한 책임을 한 곳에 집중
• UI 로직과 비즈니스 로직이 혼합되어 유지보수 어려움 발생
• 팀 내에서 어떤 파일을 수정해도 위험한 상황 발생

2. 역할 분리: 확장성의 핵심

• Rendering vs orchestration vs logic 분리

- useSubscriptionFlow 예시: 1개의 훅에 4가지 책임(analytics, fetch, navigation, state 관리) 집중

• Effects vs queries vs business flows 분리

- useCustomerDashboard 훅은 UI 로직이 아닌 데이터 fetching 복합체로 설계

• Triggers vs processors 분리

- createCustomerAndLog 함수는 컴포넌트가 트리거하고, 프로세서가 실행하는 구조

3. 데이터 fetching 복합체 패턴

• useCustomerDashboard 훅은 useCustomerProfile, useCustomerUsage, useCustomerTags 등 데이터 fetching용 훅을 조합
• UI와 분리된 컨테이너 패턴(container pattern) 적용

- useCustomerDashboard는 컴포넌트가 아닌 데이터 fetching 기능만 제공

- Vercel, Sentry, Stripe 등 실제 프로덕션 시스템에서 사용

4. 이펙트 분리: 플러그 가능한 설계

• useBillingWarning 훅은 UI 로직이 아닌 이펙트만 처리

- customer.balance > 1000 조건에 따라 경고 메시지 트리거

- 이펙트가 비즈니스 로직과 분리되어 유지보수성 향상

- 명확한 책임 분담(toast.warning은 UI, customer.balance는 비즈니스 로직)

5. 임페리티브 오케스트레이션 패턴

• AccountMigrationManager 클래스는 모듈화된 비동기 작업 처리

- exportData, deleteLegacyAccount, createNewAccount 등 단일 책임 원칙 적용

- AccountMigrationManager 인스턴스는 useMemo로 생성 후 handleMigrate에서 실행

- 복잡한 워크플로우(예: Replay.io, 관리형 대시보드)에 적합

결론

• React는 렌더링만 담당하므로, 시스템 아키텍처는 개발자가 명시적으로 설계해야 함
• 역할 분리(Rendering/Orchestration/Logic), 데이터 fetching 복합체, 이펙트 분리, 임페리티브 오케스트레이션 패턴 적용
• 대규모 프로젝트에서 유지보수성과 확장성을 위해 구조를 명확히 정의해야 함