# [[Technical Debt]]

## 📌 Brief Summary
기술 부채(Technical Debt)는 단기적인 개발 속도를 위해 구조를 무시하거나 임시방편으로 코드를 작성할 때 장기적으로 발생하는 코드의 혼란과 유지보수 비용을 의미합니다 [1]. 궁극적으로 작성된 "모든 코드는 기술 부채(All code is tech debt)"로 간주될 수 있으며, 불필요한 잉여 코드를 제거하는 것이 중요합니다 [2]. 대규모 애플리케이션에서는 일관된 명명 규칙, 확장 가능한 아키텍처 도입, 그리고 지속적인 리팩토링을 통해 기술 부채를 관리하고 축소할 수 있습니다 [1, 3, 4].

## 📖 Core Content
* **기술 부채의 발생 원인:** 개발자가 파일 구조 설계를 건너뛰고 단기적으로 "그냥 이 파일을 여기에 두자"는 식으로 코드를 작성하면 단기적으로는 빠를 수 있으나, 장기적으로는 아키텍처의 붕괴와 심각한 기술 부채를 초래합니다 [1]. 또한 사용하지 않는 과도한 기능이나 코드를 남겨두는 것도 부채가 됩니다 [2].
* **구조적 접근을 통한 부채 관리:** 
  * **Feature-Sliced Design (FSD):** 애플리케이션을 도메인과 기능 범위에 따라 슬라이스하여 단방향 의존성을 강제합니다. 이 구조는 다른 기능에 부작용을 주지 않고 각 모듈을 독립적으로 수정하거나 재작성할 수 있게 하여 아키텍처적 기술 부채를 방지합니다 [5, 6].
  * **명명 규칙 준수 (Naming Conventions):** 케밥 케이스(kebab-case)나 파스칼 케이스(PascalCase) 등 일관성 있고 명확한 파일 명명 규칙을 적용하는 것만으로도 장기적으로 기술 부채를 크게 줄이고 팀원 간의 협업을 쉽게 만듭니다 [4].
* **리팩토링과 부채 상환:** 애플리케이션이 오래됨에 따라 코드베이스를 건강하게 유지하기 위해 전문적인 리팩토링이 필수적입니다. 이는 코드를 "고치는" 것이 아니라 동작을 유지하면서 구조를 개선하는 작업입니다 [3]. 특히 큰 컴포넌트의 비즈니스 로직을 '커스텀 훅(Custom Hooks)'으로 분리하는 것이 현대 React에서 리팩토링의 주요 단위가 됩니다 [7].

## ⚖️ Trade-offs & Caveats
기술 부채를 해결하기 위해 구형 기술에서 새 기술로 시스템을 이전할 때, **완전한 재작성(Complete rewrite)을 시도하는 것은 너무 위험한 선택(too risky)**이 될 수 있습니다 [3]. 대신 아키텍처를 현대화하면서도 기능 개발을 계속할 수 있도록 알림 같은 단순한 유틸리티부터 시작해 복잡한 도메인으로 나아가는 "재작성이 아닌 리팩토링(refactor, do not rewrite)" 형태의 점진적 마이그레이션을 채택해야 하는 제약이 따릅니다 [3]. 
또한, 중복 코드를 줄이기 위해(DRY 원칙) 지나치게 추상화하면 코드가 원래의 반복된 형태보다 이해하기 어려워져 KISS(Keep It Simple, Stupid) 원칙을 위배하고 새로운 형태의 구조적 부채와 복잡성을 낳을 수 있다는 부작용이 있습니다 [8, 9].

## 🔗 Knowledge Connections

### Related Concepts

#### [아키텍처 및 설계 원칙]
- [[Feature-Sliced Design]]
  - 연결 이유: 아키텍처의 책임을 분리하고 모듈화를 강제하여 코드 수정 시 부작용을 없앰으로써, 기술 부채 누적을 원천적으로 차단하는 방법론이기 때문입니다 [6, 10].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 대규모 React 시스템에서 기술 부채 없이 확장 가능한 구조를 설계하는 방법과 레이어(Layer), 슬라이스(Slice) 기반의 단방향 의존성 원리 [10, 11].

- [[KISS and YAGNI]]
  - 연결 이유: 코드를 단순하게 유지(KISS)하고, 미래에 필요할지도 모른다는 이유로 불필요한 기능(YAGNI)을 미리 구현하지 않음으로써 유지보수해야 할 부채 자체를 생성하지 않기 때문입니다 [8, 12].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 애자일 환경에서 사장되는 코드(Dead code)를 줄이고 지나친 추상화를 피하는 방법 [12].

#### [코드 유지보수 및 관리]
- [[Refactoring]]
  - 연결 이유: 누적된 기술 부채를 해결하고 코드베이스를 건강하게 유지하기 위한 직접적이고 필수적인 실천 방식이기 때문입니다 [3].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 커스텀 훅(Custom hook)을 단위로 비즈니스 로직과 UI를 격리하는 기술 및 점진적 마이그레이션(Incremental migration) 전략 [3, 7].

### Deeper Research Questions

- 완전한 재작성(rewrite)의 위험성을 피하기 위해 점진적 마이그레이션(incremental migration)을 통해 기술 부채를 해결하는 구체적인 실무적 절차는 어떠한가?
- DRY(Don't Repeat Yourself) 원칙의 과도한 적용이 오히려 코드 복잡성을 증가시키고 새로운 기술 부채를 생성하는 경계선은 어디인가?
- 컴포넌트의 크기가 커짐에 따라 단일 책임 원칙(SRP)을 적용해 기술 부채를 식별하고 분리하는 효과적인 기준은 무엇인가?
- 대규모 프로젝트에서 엄격한 폴더 계층과 파일 명명 규칙(Naming Conventions)이 기술 부채 감소에 기여하는 메커니즘은 무엇인가?
- "모든 코드는 기술 부채다"라는 관점에서, 유지보수 측면의 부채를 줄이기 위해 제거해야 할 잉여 코드(Surplus code)를 식별하는 방법은 무엇인가?

### Practical Application Contexts

- **Implementation:** 파일이나 컴포넌트를 만들 때 단기적인 개발 속도를 위해 구조 없이 배치하는 것을 지양하고, 일관된 명명 규칙과 폴더 구조를 철저히 지켜 추후 발생하는 부채를 예방합니다 [1, 4]. 잉여 코드는 부채이므로 식별하여 제거합니다 [2].
- **System Design:** Feature-Sliced Design과 같은 기능/도메인 중심의 계층형 아키텍처를 도입하여, 각 기능 단위가 서로 암묵적인 결합 없이 독립적으로 리팩토링될 수 있도록 시스템을 구성합니다 [6, 13].
- **Operation / Maintenance:** 레거시 코드를 최신 상태로 관리할 때 시스템 전체를 엎는 대신(Rewrite 지양), 로컬 상태부터 글로벌 상태 관리까지 한 번에 하나의 스토어나 모듈씩 점진적으로 이동하는 리팩토링을 수행합니다 [3, 7].
- **Learning Path:** React를 학습할 때 단순히 컴포넌트를 렌더링하는 것을 넘어 SOLID, DRY, KISS, YAGNI와 같은 소프트웨어 엔지니어링 원칙을 접목하여, 읽기 쉽고 부채가 적은 Clean Code 작성법을 훈련합니다 [14, 15].
- **My Project Relevance:** React 코드베이스를 관리하거나 넘겨받아 리팩토링할 때, 가장 먼저 거대한 컴포넌트에서 비즈니스 로직을 추출해 Custom Hooks로 분리하여 유지보수성과 테스트 가능성을 높이는 작업부터 착수합니다 [7].

### Adjacent Topics

- [[Automated Governance]]
  - 확장 방향: ESLint, Prettier, Husky와 같은 자동화 툴을 통해 팀원들의 실수나 임의적인 코드 구조 변경을 막아 기술 부채가 축적되는 것을 시스템적으로 방지하는 방법으로 지식을 확장할 수 있습니다 [16].

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