---
id: wiki-2026-0508-refactoring-techniques
title: Refactoring Techniques
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: []
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [uncategorized]
raw_sources: []
last_reinforced: 2026-05-08
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
  language: unspecified
  framework: unspecified
---

## 📌 한 줄 통찰 (The Karpathy Summary)
리팩토링(Refactoring)은 소프트웨어의 외부 동작을 변경하지 않으면서 내부 구조, 가독성, 모듈성을 개선하는 정교한 공학적 작업이다. React 환경에서는 비대한 컴포넌트 분할, 커스텀 훅을 통한 로직 추출, 그리고 기술 부채 상환을 위한 점진적 마이그레이션을 통해 시스템의 확장성과 유지보수성을 극대화하는 것을 목표로 한다.

## 📖 구조화된 지식 (Synthesized Content)
1. **점진적 마이그레이션 (Refactor, Do Not Rewrite)**
   - 전체 시스템을 한 번에 재작성하는 위험을 피하고, 기능 단위나 도메인 단위로 하나씩 새로운 아키텍처로 옮긴다.
2. **커스텀 훅을 통한 로직 추출**
   - 비대한 컴포넌트 내의 데이터 패칭, 폼 처리, 복잡한 계산 로직을 커스텀 훅으로 추출하여 UI와 비즈니스 로직을 분리한다.
   - 이를 통해 독립적이고 빠른 단위 테스트(Unit Testing) 환경을 확보한다.
3. **안전망으로서의 테스트 구축**
   - 리팩토링 전 기존 기능의 동작을 보장하는 테스트 수트를 먼저 작성하여, 변경으로 인한 기능 파손을 즉각 탐지한다.
4. **구조적 표준화 및 거버넌스**
   - 클래스형 컴포넌트를 함수형으로 전환하고, TypeScript를 도입하여 정적 안정성을 강화한다.
   - ESLint 및 Prettier 등 자동화 도구를 통해 팀의 코드 컨벤션과 아키텍처 규칙을 강제한다.

## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **단기 생산성 저하**: 리팩토링은 당장의 비즈니스 기능 추가보다 많은 시간을 소요할 수 있으므로, 적절한 일정 조율과 경영진의 합의가 필요하다.
- **과도한 추상화의 위험**: 리팩토링 과정에서 DRY 원칙에만 집착하여 만든 지나치게 복잡한 추상화는 오히려 코드 가독성을 해칠 수 있다(KISS 원칙과의 충돌).
- **마이그레이션 중단의 위험**: 부분적인 리팩토링이 완료되지 않고 중단될 경우, 시스템 내에 두 가지 이상의 서로 다른 패턴이 혼재되어 유지보수 난이도가 상승할 수 있다.

## 🔗 지식 연결 (Graph)
### Related Concepts (Auto-Linked)
* [[Custom_Hooks]]
* [[ESLint]]
* [[Engineering_Principles]]
* [[Management]]
* [[Prettier]]
* [[Principles]]
* [[React]]
* [[Redux]]
* [[Refactoring]]
* [[Research]]
* [[Software Engineering Principles]]
* [[State]]
* [[Technical_Debt]]
* [[Testing]]

### Related Concepts
- **Custom Hooks**: 로직 분리의 물리적 단위 (관계: 실천 도구)
- **Incremental Migration**: 안전한 아키텍처 전환 전략 (관계: 핵심 방법론)
- **Unit Testing**: 리팩토링의 안전을 보장하는 장치 (관계: 필수 선행 조건)

### Deeper Research Questions
1. 리팩토링 과정에서 기존의 통합 테스트(E2E)를 유지하면서 내부 로직을 단위 테스트로 분리해 나가는 최적의 프로세스는?
2. 300줄 이상의 거대 컴포넌트를 분할할 때, 상태(State) 전달을 위해 Prop Drilling을 감수할 것인가, 아니면 전역 상태로 승격할 것인가에 대한 판단 기준은?
3. 리팩토링 중 발견된 레거시 코드의 '잠재적 버그'를 즉시 수정할 것인가, 아니면 리팩토링 완료 후 별도 작업으로 처리할 것인가?
4. 아키텍처 캡슐화(FSD 등)가 리팩토링 시 사이드 이펙트를 물리적으로 차단하는 구체적인 메커니즘은?
5. 성능 리팩토링 시, 가독성 좋은 코드와 고성능(메모이제이션 남발 등) 코드 사이의 적절한 타협점은 어디인가?

### Practical Application Contexts
- **레거시 코드 현대화**: 오래된 React 프로젝트의 기술 스택(Redux -> Zustand 등) 및 컴포넌트 스타일 개선.
- **지속적 품질 관리**: 기능 추가 전후로 관련 모듈을 SRP 원칙에 맞게 정돈하여 기술 부채 누적 방지.

### Adjacent Topics
- **Software Engineering Principles (SOLID)**
- **Technical Debt Management**
- **Automated Governance & Linting**

## 🤖 LLM 활용 힌트 (How to Use This Knowledge)

**언제 이 지식을 쓰는가:**
- *(TODO)*

**언제 쓰면 안 되는가:**
- *(TODO)*

## 🧪 검증 상태 (Validation)

- **정보 상태:** needs_review
- **출처 신뢰도:** A
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*

## 🧬 중복 검사 (Duplicate Check)

- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
- **처리 방식:** UPDATE (자동 정규화)
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.

## 🕓 변경 이력 (Changelog)

| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|------|-----------|-----------|--------|
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |

## 💻 코드 패턴 (Code Patterns)

**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*

```text
# TODO
```

## 🤔 의사결정 기준 (Decision Criteria)

**선택 A를 써야 할 때:**
- *(TODO)*

**선택 B를 써야 할 때:**
- *(TODO)*

**기본값:**
> *(TODO)*

## ❌ 안티패턴 (Anti-Patterns)

- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*