Antigravity Agent
4.3 KiB
4.3 KiB
Frontend Refactoring
📌 Brief Summary
프론트엔드 리팩토링은 기존 프론트엔드 코드베이스의 외부 동작을 변경하지 않으면서 구조, 유지보수성, 품질을 개선하는 과정입니다 [1]. 이 과정에는 거대한 컴포넌트의 분할, 레거시 코드(예: 클래스형 컴포넌트)의 현대화, 더 나은 상태 관리 및 아키텍처 경계 도입 등이 포함됩니다 [2, 3]. 점진적인 마이그레이션 전략을 사용하고 사전에 테스트를 작성함으로써 개발자는 기술 부채를 안전하게 관리하고 애플리케이션을 확장할 수 있습니다 [1, 4].
📖 Core Content
- 사전 준비 및 테스트: 리팩토링을 시작하기 전에 코드 변경으로 인해 기존 기능이 손상되지 않도록 단위 테스트(Unit Test)나 UI 테스트를 먼저 작성하는 것이 필수적입니다 [4-6]. 또한 본격적인 리팩토링에 앞서 비즈니스 로직, 전역 상태, 라우팅 및 API 호출 구조를 파악하여 프로젝트에 대한 멘탈 모델을 명확히 구축해야 합니다 [7, 8].
- 점진적 마이그레이션 (Incremental Migration): 전면 재작성(Rewrite)의 위험을 피하기 위해 리팩토링은 "재작성하지 말고 리팩토링하라"는 철학에 따라 점진적으로 이루어져야 합니다 [1]. 예를 들어 Context API에서 Zustand로 전환할 때, 전체 코드를 한 번에 바꾸기보다는 알림과 같은 단순한 유틸리티부터 시작해 결제 흐름 같은 복잡한 도메인으로 한 번에 하나의 스토어씩 마이그레이션하는 것이 권장됩니다 [1].
- 코드베이스 현대화: 레거시 React 앱을 리팩토링할 때 수행해야 할 주요 작업으로는 TypeScript로의 전환, 클래스 기반 컴포넌트를 훅(Hooks)을 사용하는 함수형 컴포넌트로 변경, 노후화된 라이브러리를 최신 버전으로 업데이트, 그리고 불필요한
useEffect사용 제거 등이 있습니다 [3]. 또한, 여러 방식이 혼용된 CSS 스타일링(예: 외부 CSS, sx, style 속성 혼용)을 하나의 방식으로 통일하여 표준화해야 합니다 [9-11]. - 상태 관리 최적화: 서버 상태 관리를 위해서는 TanStack Query를 도입하고, 불필요해진 Redux 구현체를 제거하는 것이 좋습니다 [3]. 클라이언트 측 전역 상태는 Context나 Zustand로 관리하되, 로컬 상태는 가능한 한 개별 컴포넌트 내부에 국한시키는 방향으로 상태 관리 구조를 개선해야 합니다 [3].
- 커스텀 훅 및 컴포넌트 분할: 모던 React에서 리팩토링의 가장 중요한 단위는 '커스텀 훅(Custom Hooks)'입니다 [2]. 복잡한 데이터 페칭이나 폼 처리 로직을
useFetch나useForm같은 커스텀 훅으로 추출하면 비즈니스 로직을 UI에서 분리하고 단위 테스트 속도를 높일 수 있습니다 [2]. 더불어 300줄을 초과하거나 책임이 혼재되어 단일 책임 원칙(SRP)을 위반하는 컴포넌트는 작고 명확한 목적을 가진 여러 컴포넌트로 분할해야 합니다 [12, 13]. - 원칙 및 린팅 도구 적용: DRY 및 YAGNI 원칙을 적용하여 무의미한 주석이나 잉여 코드를 제거하고 기술 부채를 줄여야 합니다 [14, 15]. 또한 ESLint와 같은 린팅 도구(eslint-plugin-react 등)를 설정하여 일관된 코딩 표준을 자동으로 강제하고 더 나은 코드 품질을 유지해야 합니다 [14, 16].
🔗 Knowledge Connections
- Related Topics: Incremental Migration, Custom Hooks, Single Responsibility Principle, Technical Debt, State Management
- Projects/Contexts: Legacy React Codebase Modernization, Context API to Zustand Migration
- Contradictions/Notes: 소규모 코드베이스의 경우, 기존 코드를 리팩토링하는 것보다 아예 처음부터 새 앱을 작성하는 것이 더 쉬울 수도 있다는 의견이 존재합니다 [5]. 또한 리팩토링 시 TypeScript로의 전환이 널리 권장되지만[3], 인지적 복잡성을 가중시킬 수 있으므로 한 번에 전면 도입하기보다는 JS에서 TS로 개별 파일을 재작성하며 점진적으로 채택하는 것이 낫다는 시각도 있습니다 [17].
Last updated: 2026-04-26