# [[Technical Debt Management]]

## 📌 Brief Summary
기술 부채 관리(Technical Debt Management)는 개발자가 장기적인 코드 구조보다 단기적인 개발 속도를 우선시할 때 축적되는 비효율적인 코드를 예방하고 재구성하는 지속적인 과정입니다 [1]. 최신 프론트엔드 환경에서 이를 관리하려면 엄격한 폴더 아키텍처와 명명 규칙을 적용하고, 애플리케이션의 기존 동작을 유지하면서 구조를 개선하는 점진적인 리팩토링 전략을 채택해야 합니다 [1-3]. 궁극적으로 작성된 "모든 코드는 기술 부채"라는 인식을 바탕으로, 잉여 코드를 제거하고 구조를 현대화하는 데 집중하는 것이 핵심입니다 [4].

## 📖 Core Content
*   **원인과 예방 (Causes and Prevention):**
    기술 부채는 개발 과정에서 구조적 원칙을 무시하고 파일을 무분별하게 배치할 때 조용히 스며들며, 장기적으로 유지보수의 혼란을 초래합니다 [1]. 이를 예방하려면 일관성 있는 폴더 구조를 갖추어 개발자에게 규율을 부여하고, 일관된 명명 규칙(Naming Conventions)을 적용하여 시간이 지남에 따라 쌓이는 기술 부채를 줄여야 합니다 [1, 3].
*   **점진적 리팩토링 전략 (Incremental Refactoring Strategy):**
    애플리케이션이 오래될수록 코드베이스를 건강하게 유지하기 위해 리팩토링이 필수적입니다 [2]. 전체 시스템을 완전히 다시 작성(Complete rewrite)하는 것은 위험도가 매우 높기 때문에, "재작성이 아닌 리팩토링(refactor, do not rewrite)" 철학을 기반으로 한 번에 하나의 모듈이나 스토어씩 변경하는 점진적 마이그레이션을 수행해야 합니다 [2]. 
*   **커스텀 훅을 통한 모듈화 (Custom Hooks as Refactoring Units):**
    React 개발에서 리팩토링의 주요 단위는 커스텀 훅(Custom Hook)입니다 [5]. 복잡한 컴포넌트에서 데이터 페칭이나 폼 핸들링 등의 비즈니스 로직을 추출하여 훅으로 분리하면, UI와 로직이 분리되어 코드를 독립적으로 테스트하기 쉬워지고 기술 부채가 완화됩니다 [5].
*   **아키텍처 부채 관리 (Architectural Debt Management):**
    기능 분할 설계(Feature-Sliced Design, FSD)와 같은 아키텍처 방법론을 도입하면 각 모듈을 다른 부분에 대한 부작용(Side effects) 없이 독립적으로 수정하거나 리팩토링할 수 있습니다 [6]. 명확한 경계와 단방향 의존성을 강제함으로써, 새로운 기능 추가나 성능 최적화 작업 시 아키텍처 부채가 누적되는 것을 방지합니다 [6, 7].

## ⚖️ Trade-offs & Caveats
*   **전면 재작성(Complete Rewrite)의 위험성:** 오래된 기술이나 구조를 한 번에 교체하는 것은 매력적으로 보일 수 있으나, 기존의 안정성을 훼손할 위험이 커서 권장되지 않으며 느리더라도 점진적으로 개선해야 하는 제약이 따릅니다 [2].
*   **과도한 추상화의 역효과:** 코드의 중복을 줄이기 위한 DRY(Don't Repeat Yourself) 원칙을 너무 일찍 적용하면, 코드가 지나치게 복잡해지는 과도한 추상화라는 새로운 기술 부채를 낳을 수 있습니다 [8]. 패턴이 세 번 반복될 때까지 기다렸다가 추상화하는 것이 조기 최적화로 인한 부작용을 막는 방법입니다 [9].
*   **단순성(Simplicity) 중심 조기 최적화의 함정:** 초기 개발 속도와 단순성을 위해 손쉬운 도구(예: 전역 상태에 무분별한 Context API 사용)를 선택하는 것은, 애플리케이션이 커졌을 때 고통스러운 대규모 리팩토링을 유발할 수 있습니다 [10].
*   **기능 분할 설계의 초기 도입 비용:** Feature-Sliced Design 같은 엄격한 구조는 대규모 앱의 부채를 막는 데 탁월하지만, 소규모 프로젝트나 경험이 적은 팀에게는 학습 곡선이 가파르고 불필요한 오버헤드로 작용할 수 있습니다 [11, 12].

## 🔗 Knowledge Connections

### Related Concepts

#### [아키텍처/기반 기술]
- [[Feature-Sliced Design]]
  - 연결 이유: 프로젝트를 기능과 도메인 스코프에 따라 분할하여, 코드를 변경할 때 시스템 전체로 파급 효과가 퍼지는 것을 막고 부채를 국소화합니다 [6, 13].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 예측 가능한 의존성 경계를 설계하여 어떻게 대규모 리팩토링을 안전하게 수행할 수 있는지 이해할 수 있습니다.
- [[Incremental Migration]]
  - 연결 이유: 레거시 기술을 현대화할 때 전체를 폐기하는 대신 점진적으로 부채를 청산해 나가는 가장 실용적이고 권장되는 방식입니다 [2].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 새로운 기능 개발과 기술 부채 상환을 동시에 진행하는 실무 전략을 파악할 수 있습니다.

#### [구현/코드 품질 원칙]
- [[DRY (Don't Repeat Yourself)]]
  - 연결 이유: 중복 코드 제거는 부채 관리의 기본이지만, 맹목적인 적용은 코드를 'KISS' 원칙에서 멀어지게 하여 오히려 유지보수 부채를 증가시킵니다 [8, 9].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 올바른 추상화 타이밍과 원칙 간의 상충 관계(Trade-off)를 배울 수 있습니다.
- [[Custom Hooks]]
  - 연결 이유: 뚱뚱해진 React 컴포넌트를 작고 테스트 가능한 단위로 쪼개는 핵심적인 리팩토링 도구입니다 [5].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: UI 컴포넌트에서 비즈니스 로직과 상태 관리를 분리하는 실용적인 기법을 배울 수 있습니다.

### Deeper Research Questions
- 전체 시스템을 점진적으로 마이그레이션(Incremental Migration)할 때, 신구 상태 관리 도구(예: Context API와 Zustand) 간의 데이터 동기화 및 하위 호환성을 어떻게 유지할 것인가?
- 대규모 모놀리식(Monolithic) 폴더 구조를 가진 레거시 프로젝트에 [[Feature-Sliced Design]]을 도입하기 위한 가장 안전하고 효율적인 단계별 절차는 무엇인가?
- "모든 코드는 기술 부채다"라는 관점에서, 사용되지 않는 데드 코드(Dead Code)나 불필요한 렌더링 요소를 자동 식별하여 제거하기 위해 어떤 분석 도구(Profiler 등)를 활용할 수 있는가?
- 추상화를 적용하는 기준이 되는 'Rule of Three(세 번 반복 시 추상화)'를 복잡한 프론트엔드 비즈니스 로직에 적용할 때 마주치는 한계와 예외 사례는 무엇인가?
- 초기 스타트업 환경에서 시장 출시 속도를 높이기 위해 발생하는 '의도적인 기술 부채'를 추후 상환하기 위해 개발팀이 도입해야 할 프로세스는 무엇인가?

### Practical Application Contexts
- **Implementation:** 비대해진 React 컴포넌트 내부에서 상태 관리나 API 호출 로직을 발견했을 때, 이를 별도의 Custom Hook으로 추출하여 UI 로직을 단순화하고 테스트 가능성을 높이는 리팩토링을 수행합니다 [4, 5].
- **System Design:** 프로젝트 셋업 단계에서 미리 명명 규칙(Naming Convention)과 기능 단위의 폴더 아키텍처를 강제하여, 개발자들이 아무 폴더에나 파일을 추가하여 발생하는 구조적 부채를 사전에 차단합니다 [1, 3].
- **Operation / Maintenance:** 상태 관리 라이브러리를 마이그레이션할 때 전체 앱을 한 번에 바꾸지 않고 알림(Notification) 기능 등 작은 유틸리티부터 시작하여 결제 흐름 같은 복잡한 도메인으로 단계적으로 리팩토링을 진행합니다 [2].
- **Learning Path:** 리팩토링을 학습할 때 먼저 코드에 단위 테스트(Unit Tests)를 작성하여 기존의 동작을 보장한 뒤에, SOLID 원칙과 Clean Code 원칙을 염두에 두고 레거시 코드를 작게 분할해 나가는 방법을 훈련합니다 [14, 15].
- **My Project Relevance:** 현재 유지보수하거나 인수받은 낡은 코드베이스를 개선해야 한다면, 우선 기능별로 코드를 그룹화하고 중복 코드를 찾아내어 점진적으로 덜어내는 방향(Remove surplus)으로 작업을 설계합니다 [4, 16].

### Adjacent Topics
- [[Automated Testing]]
  - 확장 방향: 기술 부채를 리팩토링하는 과정에서 애플리케이션의 동작이 깨지지 않았음을 자동으로 검증하여 리팩토링의 안정성을 보장하는 방법.
- [[Static Code Analysis (ESLint/Prettier)]]
  - 확장 방향: 정적 분석 도구를 CI/CD 파이프라인에 통합하여 아키텍처 규칙과 클린 코드 원칙을 자동 강제함으로써 기술 부채의 유입을 원천 차단하는 방안.

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