feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]
This commit is contained in:
@@ -1,24 +1,42 @@
|
||||
---
|
||||
id: wiki-2026-0508-large-scale-application-refactor
|
||||
title: Large scale Application Refactoring
|
||||
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
|
||||
---
|
||||
|
||||
# [[Large-scale Application Refactoring|Large-scale Application Refactoring]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
대규모 애플리케이션 리팩토링은 코드의 동작 방식을 보존하면서 내부 구조를 개선하여 오래된 코드베이스의 유지보수성과 확장성을 회복하는 과정이다 [1]. 이는 단순히 코드를 '수정'하는 것이 아니라, 복잡한 비즈니스 로직을 분리하고 구조적 결합도를 낮추는 것을 목표로 한다 [2]. 성공적인 리팩토링을 위해서는 점진적인 접근 방식, 엄격한 아키텍처 적용, 그리고 코드 변경을 뒷받침할 수 있는 테스트 구축이 필수적이다 [1, 3].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **점진적 마이그레이션 전략 (Incremental Migration):** 대규모 애플리케이션을 한 번에 전면 재작성(Rewrite)하는 것은 리스크가 매우 크기 때문에, "재작성이 아닌 리팩토링" 전략이 권장된다 [1]. 예를 들어 상태 관리 도구를 Context API에서 Zustand로 마이그레이션할 때, 알림과 같은 단순한 유틸리티 스토어부터 시작해 결제 흐름과 같은 복잡한 도메인으로 한 번에 하나의 스토어씩 점진적으로 이동해야 한다 [1].
|
||||
* **기능 및 도메인 기반 구조로의 개편:** 레거시 앱에서 흔히 쓰이는 파일 타입 기반 구조(components, hooks 등을 따로 모으는 방식)는 앱이 커질수록 탐색과 유지보수를 어렵게 만든다 [4, 5]. 따라서 비즈니스 기능별로 코드를 모으는 기능 기반 구조나, 단방향 의존성을 강제하는 엄격한 계층 모델인 Feature-Sliced Design(FSD)으로 폴더 구조를 재편하는 것이 핵심적인 리팩토링 목표가 된다 [6-8].
|
||||
* **커스텀 훅을 통한 로직 캡슐화:** 현대 React 리팩토링의 기본 단위는 커스텀 훅이다 [9]. 복잡한 데이터 페칭이나 폼 핸들링 로직을 거대한 UI 컴포넌트에서 추출하여 `useFetch`, `useForm` 등의 훅으로 분리하면, UI와 비즈니스 로직이 격리되어 더 빠르고 독립적인 유닛 테스트가 가능해진다 [9, 10].
|
||||
* **테스트를 통한 안전망 확보:** 코드를 본격적으로 수정하기 전에 테스트(Unit Test, UI Test 등)를 작성하는 것이 최우선 방어선이다 [3, 11, 12]. 기존 기능이 깨지지 않았는지 검증할 뿐만 아니라, 테스트 코드를 작성하는 과정 자체가 개발자가 기존 애플리케이션의 비즈니스 로직과 흐름을 깊이 이해하도록 강제하는 학습 도구가 된다 [13, 14].
|
||||
* **레거시 안티패턴 및 스택 제거:** 효율적인 구조를 위해 불필요하게 렌더링을 유발하는 다수의 `useEffect`를 제거하고, 클라이언트와 서버 상태를 분리하기 위해 TanStack Query와 같은 도구를 도입해야 한다 [15]. 또한, 가능할 경우 클래스 기반 컴포넌트를 함수형 컴포넌트와 훅으로 변환하고, 일관성 없는 CSS 적용 방식을 하나로 통일하는 작업도 수반된다 [15, 16].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **DRY와 KISS 원칙의 충돌:** 중복을 제거하려는 DRY(Don't Repeat Yourself) 원칙을 과도하게 적용할 경우, 추상화가 지나치게 복잡해져 코드를 단순하게 유지해야 하는 KISS(Keep It Simple, Stupid) 원칙을 위반하게 된다 [17]. 따라서 특정 패턴이 세 번 반복될 때까지 기다렸다가 추상화를 진행하는 것이 조기 최적화로 인한 부작용을 막는 방법이다 [17].
|
||||
* **재작성(Rewrite) vs 리팩토링(Refactoring)의 기로:** 리팩토링 대상인 앱의 규모가 비교적 작다면 처음부터 새로 앱을 구축하는 것이 오히려 효율적일 수 있다 [11]. 그러나 대형 앱의 경우 전체 재작성은 위험이 커서 점진적 마이그레이션을 해야 하는데, 이 경우 전환 기간 동안 두 가지 다른 기술이나 아키텍처 패턴이 공존해야 하는 과도기적 기술 부채를 감당해야 한다 [1].
|
||||
* **컴파일러 자동화 도입의 장벽:** React Compiler와 같이 성능 최적화(메모이제이션)를 자동화해 주는 도구를 도입하면 수동 최적화 코드를 지워 코드를 간결하게 만들 수 있다 [18]. 하지만 기술 부채가 많은 레거시 코드베이스의 경우, 기존 코드가 'React의 규칙(Rules of React)'을 광범위하게 위반하고 있다면 컴파일러가 제대로 작동하지 않으므로, 도입 전 대대적인 사전 리팩토링이 선행되어야 하는 제약이 따른다 [19].
|
||||
* **공유(Shared) 모듈의 비대화:** 기능 기반 아키텍처(예: FSD)로 분리할 때, 공통으로 쓰이는 코드를 무분별하게 'Shared' 계층에 넣으면 해당 계층이 복잡한 스파게티 코드가 되고 변경 시 영향 범위(Blast Radius)가 기하급수적으로 커지는 위험이 있다 [20, 21].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
|
||||
#### [아키텍처 및 기반 원칙]
|
||||
@@ -63,4 +81,53 @@
|
||||
- 확장 방향: 레거시 앱의 거대한 단일 전역 상태를 분석하여 로컬 컴포넌트 상태, 전역 UI 상태, 서버 캐시 상태, URL 상태 등으로 파편화 및 전문화하여 각각에 맞는 도구(Zustand, React Query 등)로 이관하는 설계 방법론을 조사한다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-30*
|
||||
*Last updated: 2026-04-30*
|
||||
|
||||
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
Reference in New Issue
Block a user