# [[React Codebase Refactoring|React Codebase Refactoring]]

## 📌 Brief Summary
React 코드베이스 리팩토링은 기존 앱의 외부 동작을 변경하지 않으면서 유지보수성, 성능, 가독성을 향상시키기 위해 코드를 재설계하고 정리하는 과정입니다. 대규모 React 앱에서 자주 발생하는 논리 결합, 불필요한 재렌더링, 전역 상태의 남용 등의 아키텍처 문제를 해결하는 데 중점을 둡니다. 성공적인 리팩토링을 위해서는 단위 테스트로 안전망을 확보한 후, 컴포넌트 책임 분리, TypeScript 도입, 상태 관리 도구의 현대화를 점진적으로 수행하는 것이 권장됩니다 [1-3].

## 📖 Core Content
*   **테스트 주도 접근 (Test-Driven Approach):** 리팩토링 도중 기존 기능이 손상되는 것을 방지하기 위해 가장 먼저 단위 테스트(Unit Test)나 UI 테스트 스위트를 작성해야 합니다. 이를 통해 코드의 기존 동작을 보장하며 안전하게 수정할 수 있습니다 [2, 4, 5].
*   **점진적 마이그레이션 (Incremental Migration):** 전체 코드를 한 번에 재작성(Rewrite)하는 것은 위험도가 높으므로, 점진적인 접근이 필요합니다. 예를 들어 Context API에서 Zustand로 상태 관리를 변경할 때, 하나의 스토어나 기능 단위로 단계별 마이그레이션을 진행해야 비즈니스 개발의 중단 없이 아키텍처를 현대화할 수 있습니다 [1].
*   **구조 및 컴포넌트 책임 분리 (Separation of Concerns):** 300줄 이상의 방대한 컴포넌트는 단일 책임 원칙(SRP)에 따라 더 작고 초점이 맞춰진 컴포넌트로 분리해야 합니다 [6, 7]. 데이터 페칭이나 폼 처리와 같은 비즈니스 로직은 커스텀 훅(Custom Hooks)으로 추출하여 UI 컴포넌트와 완전히 분리하는 것이 좋습니다 [8, 9].
*   **상태 관리의 현대화:** 과거의 거대한 단일 전역 상태를 역할에 맞게 분리해야 합니다. API에서 가져오는 '서버 상태'는 TanStack Query(React Query)와 같은 데이터 페칭 라이브러리에 위임하고, '클라이언트 상태'는 Zustand와 같은 가벼운 라이브러리나 지역 상태(Local State)를 활용하여 관리하도록 개선해야 합니다 [10-12].
*   **도구 및 컨벤션의 적용:** JavaScript 기반 코드는 TypeScript로 마이그레이션하여 타입 안정성을 확보하는 것이 좋습니다 [3, 11]. 또한, ESLint와 같은 도구를 도입해 코드 포맷팅과 아키텍처 규칙(예: 모듈 간 의존성 규칙)을 자동으로 강제해야 하며, 인라인 스타일이나 여러 방식이 혼재된 CSS를 한 가지 방식(예: CSS Modules, Tailwind 등)으로 통일해야 합니다 [13-15].
*   **과거의 패턴 제거:** 클래스형 컴포넌트가 있다면 함수형 컴포넌트와 훅(Hooks)으로 교체해야 합니다 [11]. 최신 React(예: React 19)나 React Compiler를 사용하는 환경이라면 불필요한 `useEffect`, `useMemo`, `useCallback` 등을 제거하여 코드를 더욱 간결하게 만들 수 있습니다 [11, 16, 17].

## ⚖️ Trade-offs & Caveats
*   **추상화의 함정과 오버엔지니어링 (KISS vs DRY):** DRY(Don't Repeat Yourself) 원칙을 따르기 위해 성급하게 공통 로직을 추상화하면, 코드가 원래의 반복된 코드보다 더 복잡해지고 이해하기 어려워지는 부작용이 발생할 수 있습니다. 전문가들은 패턴이 3번 이상 반복될 때까지 기다렸다가 추상화(Custom Hook 등)를 진행할 것을 권장합니다 [18].
*   **TypeScript 채택의 인지적 부하:** 리팩토링 시 TypeScript를 도입하는 것은 장기적 안정성을 보장하지만, 경험이 부족한 개발팀에게는 새로운 복잡성 레이어로 작용하여 초기에 생산성을 늦출 수 있습니다. 따라서 강제 도입보다는 개별 파일부터 점진적으로 전환하는 것이 추천됩니다 [3].
*   **아키텍처 도입 비용:** Feature-Sliced Design(FSD)과 같이 엄격한 계층 구조를 강제하는 아키텍처로 폴더 구조를 리팩토링하는 것은 큰 학습 곡선과 설정 비용을 수반합니다. 팀 전체의 이해도가 없으면 오히려 시스템이 엉망이 되거나 소규모 프로젝트에서는 과도한 설계(Overkill)가 될 수 있습니다 [19-21].
*   **완전 재작성(Rewrite)의 위험성:** 프로젝트가 매우 작다면 아예 처음부터 새로 작성하는 것이 빠를 수도 있으나 [4], 일반적인 환경에서는 기존 기능을 그대로 유지하면서 코드를 개선해야 하므로 전면 재작성보다는 안전성을 담보한 점진적 리팩토링이 필수적입니다 [1].

## 🔗 Knowledge Connections

### Related Concepts

#### [관계 유형 A (아키텍처/기반 기술)]
- [[Feature-Sliced Design|Feature-Sliced Design]]
  - 연결 이유: 리팩토링 과정에서 기술 단위(Component, Hooks 등)로 흩어진 기존 폴더 구조를 기능(Feature) 중심으로 모듈화하고 재편할 때 기준이 되는 현대적인 프론트엔드 아키텍처론입니다 [22, 23].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 확장성을 위한 단방향 의존성 규칙과 도메인 중심의 코드 캡슐화 설계 방법.
- [[SOLID Principles|SOLID Principles]]
  - 연결 이유: 거대한 React 컴포넌트를 작게 분리하고 인터페이스를 구성할 때, 단일 책임 원칙(SRP)과 같은 클린 코드의 기반 지침을 제공합니다 [6, 24].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 리액트 컴포넌트의 책임을 올바르게 분리하고 유지보수하기 쉬운 추상화를 설계하는 기준.

#### [관계 유형 B (구현/활용 도구)]
- TanStack Query
  - 연결 이유: 기존의 비효율적인 Context API나 거대한 Redux 스토어를 리팩토링할 때, 서버 상태(캐싱, 동기화 등)를 깔끔하게 분리해 주는 핵심 도구입니다 [10, 11].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 서버 데이터 페칭 로직의 분리와 컴포넌트 내 복잡한 상태 관리 감소 방법.
- Zustand
  - 연결 이유: 불필요한 재렌더링을 유발하는 기존의 Context API 기반 상태 관리를 리팩토링할 때 주로 도입되는 경량 클라이언트 상태 관리 라이브러리입니다 [1, 25].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 상태 선택자(Selector)를 통한 렌더링 최적화 구조 및 보일러플레이트 없는 상태 관리 로직 작성법.
- Unit Testing
  - 연결 이유: 리팩토링 시 코드를 변경하더라도 기존의 비즈니스 로직이 파괴되지 않음을 보장하기 위해 리팩토링 작업에 선행되어야 하는 기술입니다 [2, 5].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 기존 코드를 검증 가능한 형태로 쪼개고 안전성을 확보하는 실질적인 엔지니어링 절차.

### Deeper Research Questions
- 레거시 React 앱에서 Context API를 Zustand로 점진적으로 마이그레이션할 때(Incremental Migration), 상태 충돌을 방지하기 위한 가장 안전한 전략은 무엇인가?
- 대규모 리팩토링 진행 시, Feature-Sliced Design(FSD) 아키텍처를 도입할 때 기존 컴포넌트 간의 결합(Cross-cutting concerns)을 어떻게 계층적으로 분리할 수 있는가?
- React Compiler 환경이 도입되었을 때, 리팩토링 시 기존 코드에 남용된 `useMemo`와 `useCallback`을 제거하는 것이 런타임 성능 및 코드 가독성에 어떤 구체적인 이점을 주는가?
- 비즈니스 로직이 혼재된 거대한 폼(Form) 컴포넌트를 리팩토링할 때 단일 책임 원칙(SRP)과 YAGNI 원칙 간의 균형을 맞추는 기준은 무엇인가?
- 대규모 TypeScript 마이그레이션을 진행할 때 개발 생산성 저하를 방지하면서 점진적 타입 정의를 적용하는 모범 사례는 무엇인가?

### Practical Application Contexts
- **Implementation:** 비대해진 React 컴포넌트에서 API 호출과 상태 관리 로직을 분리하여 Custom Hook으로 작성하고, ESLint를 도입하여 코드 컨벤션과 아키텍처 규칙 위반을 린트(Lint) 단계에서 차단합니다.
- **System Design:** 프로젝트의 파일 디렉토리 구조를 단순한 기능별(File-type based) 분류에서 Feature-Sliced Design과 같은 도메인/비즈니스 중심의 계층형 구조로 재설계합니다.
- **Operation / Maintenance:** 서비스를 중단하지 않기 위해 한 번에 모든 시스템을 바꾸지 않고, 하나의 스토어나 특정 기능 모듈 단위로 리팩토링을 수행하는 점진적 접근법을 운영합니다.
- **Learning Path:** React 기초 습득 ➔ Clean Code 및 SOLID 원칙 이해 ➔ 상태 관리의 세분화(서버 데이터 vs UI 상태) ➔ 단위 테스트 작성 ➔ 점진적 리팩토링 적용 순으로 엔지니어링 역량을 확장합니다.
- **My Project Relevance:** 현재 유지보수하고 있는 복잡한 레거시 React 프로젝트의 성능 및 유지보수성 저하 원인을 분석하고, 컴포넌트 분리와 상태 관리 라이브러리(Zustand, React Query) 교체 작업을 체계적으로 기획할 때 직접 적용할 수 있습니다.

### Adjacent Topics
- [[Web Performance Optimization|Web Performance Optimization]]
  - 확장 방향: 리팩토링의 궁극적 결과물 중 하나인 초기 로딩 속도 향상, 렌더링 최적화, 그리고 불필요한 번들 사이즈를 줄이는 코드 스플리팅(Code Splitting) 기법 등으로 개념을 확장하여 학습할 수 있습니다.
- Git Workflow & CI/CD
  - 확장 방향: 대규모 리팩토링 시 발생할 수 있는 브랜치 충돌 방지와 코드 리뷰 자동화, 그리고 Pull Request 과정에서 Visual Regression Testing을 연동하는 등 협업 전략으로 확장할 수 있습니다.

---
*Last updated: 2026-04-30*