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

[아키텍처 및 설계 원칙]

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

7.3 KiB Raw Blame History