feat: Knowledge Gardening Milestone 470 (Batch #24 - 40% Achieved)
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,27 @@
|
||||
# [[Clean Code]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
클린 코드(Clean Code)는 소프트웨어를 작성할 때 누구나 읽기 쉽고 유지보수하기 편하도록 코드를 명확하고 단순하게 작성하는 방법론입니다 [1]. 프론트엔드 및 리액트(React) 생태계에서 애플리케이션의 규모가 커질 때 코드의 복잡성을 관리하고 예측 가능성을 높이기 위한 필수적인 기반 역할을 합니다 [2]. 이를 위해 개발자들은 간결하고 의미 있는 이름을 사용하며 깊게 중첩된 구조를 피해야 하고, 단일 프로젝트에 국한되지 않고 가독성을 보장하기 위해 모든 프로젝트에 적용해야 합니다 [3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **클린 코드의 기본 적용 방식:**
|
||||
* 클린 코드는 명확성과 단순성을 최우선으로 합니다 [1]. React 컴포넌트를 작성할 때는 코드를 간결하게 유지하고, 목적이 명확히 드러나는 이름을 사용하며, 로직이 과도하게 깊게 중첩되는 구조를 피하는 것이 핵심입니다 [3].
|
||||
|
||||
* **SOLID 원칙을 통한 React 코드의 구조화:**
|
||||
* **SRP (단일 책임 원칙):** 컴포넌트나 훅은 오직 하나의 명확한 목적만 가져야 합니다 [4]. 만약 컴포넌트가 300줄을 넘어선다면, 이는 상태 관리, 데이터 페칭, 렌더링 등 너무 많은 역할을 짊어지고 있다는 신호이므로 더 작고 집중된 컴포넌트로 분리해야 합니다 [5].
|
||||
* **OCP (개방/폐쇄 원칙):** 기존 컴포넌트의 소스 코드를 직접 수정하는 대신, 컴포넌트 합성(composition)이나 `children`, `render props` 패턴을 사용하여 새로운 기능을 확장할 수 있어야 합니다 [4, 6].
|
||||
* **ISP (인터페이스 분리 원칙):** 컴포넌트는 자신이 사용하지 않는 props에 의존해서는 안 됩니다 [6, 7]. 큰 객체를 통째로 전달하기보다는 컴포넌트가 필요로 하는 명확하게 분리된 특정 데이터만 전달해야 결합도를 낮출 수 있습니다 [4, 6].
|
||||
* **DIP (의존성 역전 원칙):** 하나의 컴포넌트가 다른 컴포넌트에 직접적으로 의존하는 것을 피하고, props나 context를 통해 의존성을 주입받도록 설계해야 합니다 [4, 7].
|
||||
|
||||
* **DRY, KISS, YAGNI 원칙과 균형:**
|
||||
* **DRY (Don't Repeat Yourself):** 반복되는 코드를 피하고 재사용성을 높이기 위해, 공통 로직을 커스텀 훅이나 고차 컴포넌트(HOC)로 추출해야 합니다 [1, 3, 8, 9].
|
||||
* **KISS (Keep It Simple, Stupid):** 복잡성보다 단순함을 선택해야 합니다 [1]. 디버깅과 이해가 쉽도록 코드를 단순하게 유지해야 하며, 너무 이른 최적화를 피해야 합니다 [3, 9].
|
||||
* **YAGNI (You Aren't Gonna Need It):** 미래에 발생할지도 모르는 요구사항을 위해 복잡한 기능을 미리 구축해서는 안 됩니다 [10, 11]. 현재의 요구사항과 오늘 필요한 것들만 구현하여 추후의 데드 코드 발생을 최소화해야 합니다 [1, 3, 10].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[SOLID Principles]], [[React Architecture]], [[Refactoring]]
|
||||
- **Projects/Contexts:** [[Frontend Scalability]], [[Large-scale React Systems]]
|
||||
- **Contradictions/Notes:** 너무 철저하게 DRY 원칙을 지키려다 보면 불필요하고 복잡한 추상화를 낳게 되어, 오히려 코드를 단순하게 유지하라는 KISS 원칙을 위반할 위험이 있습니다. 소스는 이러한 문제를 방지하기 위해 특정 패턴이 최소 3번 반복될 때까지 기다렸다가 추상화하는 방식을 권장합니다 [8, 12].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,18 @@
|
||||
# [[Component Composition]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
컴포넌트 합성(Component Composition)은 작은 선언적 컴포넌트들을 조립하여 더 크고 복잡한 컴포넌트 트리를 구성하는 React의 핵심 패턴입니다 [1]. 이는 `children` prop이나 렌더 프롭(render props)을 활용하여 내부 소스 코드 수정 없이 컴포넌트에 새로운 기능을 확장할 수 있게 함으로써 개방-폐쇄 원칙(OCP)을 충족시킵니다 [2, 3]. 확장 가능한 프론트엔드 아키텍처(예: Feature-Sliced Design)에서는 비즈니스 로직을 포함하지 않고 하위 모듈들을 오케스트레이션하여 UI를 조립하는 방식으로 널리 활용됩니다 [4].
|
||||
|
||||
## 📖 Core Content
|
||||
* **선언적 UI 조립:** React의 JSX는 컴포넌트 트리 관점에서 생각하도록 장려하며, 상태(state)와 프롭스(props)의 순수 함수로서 UI를 표현합니다. 이러한 합성을 통한 선언적 접근은 예측 가능성과 테스트 용이성을 높여줍니다 [1].
|
||||
* **개방-폐쇄 원칙(OCP)의 구현:** SOLID 원칙 중 개방-폐쇄 원칙은 React에서 컴포넌트 합성을 통해 구현됩니다. 기존 컴포넌트를 직접 수정하는 대신 `children` prop이나 렌더 프롭(render props)을 통해 컴포넌트를 구성하면, 기존 코드를 손상시키지 않고도 새로운 기능을 쉽게 확장할 수 있습니다 [2, 3].
|
||||
* **기능 분할 설계(Feature-Sliced Design)에서의 역할:** 확장성을 위한 FSD 아키텍처에서 합성은 명확한 책임을 가집니다. '위젯(Widgets)' 레이어는 비즈니스 규칙을 직접 구현하지 않고, 하위의 '기능(Features)'과 '엔티티(Entities)'를 재사용 가능한 UI 블록으로 합성(compose)하여 오케스트레이션하는 역할을 수행합니다 [4]. 그 위 레이어인 '페이지(Pages)'와 '앱(App)' 역시 위젯들을 모아 전체 화면과 글로벌 설정을 합성하는 역할을 맡습니다 [4, 5].
|
||||
* **서버 및 클라이언트 컴포넌트의 합성:** Next.js의 App Router와 같은 최신 아키텍처에서는 React 서버 컴포넌트(RSC)가 일반 클라이언트 컴포넌트와 원활하게 합성될 수 있습니다 [6]. 이를 통해 정적인 UI는 서버에서 렌더링하고, 상호작용이 필요한 부분만 클라이언트 컴포넌트로 분리하여 결합할 수 있습니다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Open/Closed Principle (OCP)]], [[Feature-Sliced Design (FSD)]], [[JSX]], [[React Server Components]]
|
||||
- **Projects/Contexts:** [[Scalable React Architecture]], [[Frontend System Design]]
|
||||
- **Contradictions/Notes:** 컴포넌트 합성에 대해 소스 간의 모순점은 발견되지 않았으며, 제공된 자료들은 모두 합성이 코드의 재사용성을 높이고 아키텍처의 결합도를 낮추는 핵심 원칙이라는 점에 동의하고 있습니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,25 @@
|
||||
# [[Custom Hooks]]
|
||||
|
||||
## 📌 Brief 시
|
||||
Custom Hooks는 React 애플리케이션에서 반복되는 로직을 추출하여 재사용성과 모듈성을 높이는 핵심적인 리팩토링 단위입니다 [1]. 주로 데이터 패칭, 폼 처리, 전역 상태 구독과 같은 공통 로직을 캡슐화하는 데 사용되며, 비즈니스 로직을 UI와 격리시켜 독립적이고 빠른 단위 테스트를 가능하게 합니다 [1]. 스케일러블한 프로젝트 구조에서는 별도의 디렉토리에 관리되며, 일관된 명명 규칙을 통해 코드베이스의 가독성과 유지보수성을 크게 향상시킵니다 [2-4].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
* **리팩토링 및 모듈성 향상:**
|
||||
최신 React 개발에서 Custom Hook은 리팩토링의 주요 단위로 작용합니다 [1]. 거대한 컴포넌트 내부에 있는 복잡한 데이터 패칭이나 폼 처리 로직을 `useFetch`, `useForm`과 같은 Custom Hook으로 추출하면, 비즈니스 로직이 UI 컴포넌트로부터 완전히 분리됩니다 [1]. 이러한 격리는 느린 통합 테스트에 의존하는 대신 빠르고 고립된 단위 테스트를 가능하게 하여 코드의 모듈성과 테스트 용이성을 극대화합니다 [1].
|
||||
* **DRY(Don't Repeat Yourself) 원칙의 실천:**
|
||||
동일한 코드를 반복하지 말라는 DRY 원칙을 React 컴포넌트에 적용하는 가장 대표적인 방법이 바로 재사용 가능한 로직을 Custom Hook이나 고차 컴포넌트(HOC)로 추출하는 것입니다 [5, 6]. 또한, 복잡한 상태 관리를 위해 단순히 `useState`를 남용하기보다는 `useReducer`나 Custom Hook을 활용하여 상태 관리 로직을 깔끔하게 유지하는 것이 권장됩니다 [7].
|
||||
* **폴더 구조 (Folder Structure) 모범 사례:**
|
||||
확장 가능한 애플리케이션 아키텍처에서 Custom Hook은 주로 `src/hooks/` 폴더 내에 중앙 집중화되어 배치됩니다 [2, 4]. 이 폴더에는 `useAuth`, `useLocalStorage`, `useWindowSize`와 같이 여러 컴포넌트와 도메인에 걸쳐 재사용되는 횡단 관심사(Cross-cutting logic)들이 위치하게 되며, 이를 통해 코드 재사용이 촉진되고 애플리케이션 로직 관리가 쉬워집니다 [2, 4].
|
||||
* **명명 규칙 (Naming Conventions):**
|
||||
클린 코드와 일관성을 위해 Custom Hook의 이름은 반드시 `camelCase`로 작성해야 하며, `use` 접두사로 시작하여 훅이라는 목적과 정체를 명확히 나타내야 합니다 (예: `useAuthState`) [3, 8-10].
|
||||
* **성능 최적화 고려사항:**
|
||||
의존성(dependencies)이 변하지 않는 상황에서 성능을 최적화하기 위해, Context Provider나 Custom Hook 자체를 메모이제이션(memoizing)하는 전략이 활용되기도 합니다 [11].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[DRY Principle]], [[React Folder Structure]], [[Clean Code]], [[Naming Conventions]]
|
||||
- **Projects/Contexts:** [[React Refactoring]], [[Scalable Frontend Architecture]]
|
||||
- **Contradictions/Notes:** 소스 내에 Custom Hook과 관련한 특별한 모순점은 발견되지 않았으며, 여러 출처에서 공통적으로 관심사 분리, 코드 재사용 및 리팩토링을 위해 Custom Hook의 적극적인 활용을 권장합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,21 @@
|
||||
# [[DRY Principle]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
DRY는 "Don't Repeat Yourself"의 약자로, 동일한 코드를 두 번 이상 작성하지 않고 기존 코드를 재사용하여 코드 중복을 피하는 소프트웨어 엔지니어링 원칙입니다 [1, 2]. 이를 통해 코드의 가독성을 높이고, 향후 변경 사항이 발생했을 때 여러 곳을 수정할 필요 없이 단일 지점에서만 변경할 수 있도록 하여 유지보수성을 극대화합니다 [2]. React 애플리케이션에서는 주로 공통 로직을 커스텀 훅(Custom Hooks)이나 고차 컴포넌트(Higher-Order Components)로 추출하는 방식으로 적용됩니다 [3, 4].
|
||||
|
||||
## 📖 Core Content
|
||||
- **개념과 장점**: DRY 원칙을 따르지 않아 중복된 코드가 많아지면, 향후 코드 변경 시 여러 부분을 동시에 수정해야 하는 어려움이 따릅니다 [2]. 이 원칙을 적용하여 코드를 별도의 컴포넌트나 함수로 분리하면, 단 한 곳에서만 변경을 수행하면 되므로 코드의 반복을 줄이고 관리가 용이해집니다 [2, 5]. 특히 반복적인 로직이 많은 애플리케이션에서 매우 유용하게 쓰입니다 [4].
|
||||
- **React에서의 적용 방법**: React 개발에서 DRY 원칙은 로직을 재사용 가능한 형태로 추출하는 것을 장려합니다. 구체적으로는 반복되는 코드를 커스텀 훅이나 고차 컴포넌트(HOC)로 분리하여 컴포넌트 간의 결합도를 낮추고 로직의 예측 가능성을 높입니다 [3, 4, 6].
|
||||
- **적용 시 주의점 및 타 원칙과의 조화**:
|
||||
- DRY 원칙을 지나치게 맹신하면 지나치게 복잡한 추상화(overly complex abstractions)를 초래할 수 있습니다 [5].
|
||||
- 재사용 가능한 추상화가 본래의 반복된 코드보다 이해하기 어려워진다면, 이는 코드를 단순하게 유지하라는 **KISS (Keep It Simple, Stupid)** 원칙을 위배한 것입니다 [3].
|
||||
- 성급한 최적화를 피하기 위해, 코드 패턴이 세 번 이상 반복될 때까지 추상화를 보류하는 것이 일반적인 권장 지침입니다. 이렇게 함으로써 코드를 단순하고 디버깅하기 쉽게 유지할 수 있습니다 [3].
|
||||
- 모듈형 아키텍처인 **Feature-Sliced Design (FSD)** 같은 방법론에서도 DRY 원칙과 지역적인 커스터마이징(local customization) 사이에서 적절한 균형을 유지하는 것을 핵심으로 삼고 있습니다 [7].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[KISS Principle]], [[YAGNI Principle]], [[Clean Code]], [[Custom Hooks]]
|
||||
- **Projects/Contexts:** [[React Architecture]], [[Feature-Sliced Design]], [[Frontend Refactoring]]
|
||||
- **Contradictions/Notes:** 소스에 따르면 DRY 원칙을 통해 반복을 줄일 수 있지만, 무리하게 적용할 경우 지나치게 복잡한 추상화로 이어질 수 있습니다 [5]. 이는 코드를 단순하게 유지하려는 KISS 원칙과 상충될 수 있으므로, 패턴이 세 번 이상 반복될 때 추상화를 적용하는 등 두 원칙 사이의 균형이 필요합니다 [3].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,18 @@
|
||||
# [[KISS Principle]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
KISS(Keep It Simple, Stupid) 원칙은 복잡성보다는 단순성을 항상 선택하여 코드를 이해하고 유지보수하기 쉽게 만드는 소프트웨어 엔지니어링 원칙입니다 [1, 2]. React 개발 환경에서는 컴포넌트 로직을 단순화하고 조기 최적화(premature optimization)를 피하는 방향으로 적용됩니다 [3]. 함수나 컴포넌트가 비대해질 경우, 코드를 '단순하고 멍청하게(simple and dumb)' 남겨두기 위해 더 작고 직관적인 논리적 부분으로 분할할 것을 권장합니다 [2].
|
||||
|
||||
## 📖 Core Content
|
||||
* **단순성 우선:** KISS 원칙은 코드를 명확하고 단순하게 작성하는 것을 핵심으로 합니다 [1]. 코드가 단순할수록 직관적으로 이해하기 쉽고 디버깅이 수월해집니다 [4]. 이 원칙은 빠른 프로토타이핑을 진행하거나 단순한 애플리케이션을 개발할 때 특히 유용하게 사용됩니다 [3].
|
||||
* **React 환경에서의 적용:** React에서 KISS 원칙을 준수하려면 컴포넌트의 로직을 복잡하게 만들지 않고 조기 최적화를 피해야 합니다 [3]. 컴포넌트와 함수가 성장함에 따라 논리를 분리하여 작고 이해 가능한 단위로 유지하는 것이 중요합니다 [2].
|
||||
* **DRY 원칙과의 균형 및 한계:** "Don't Repeat Yourself"를 뜻하는 DRY 원칙을 무리하게 적용하다 보면 KISS 원칙을 위반하기 쉽습니다 [5]. 코드의 중복을 피하려고 재사용 가능한 추상화(예: 커스텀 훅)를 만들었을 때, 그 추상화된 코드가 원본 코드보다 이해하기 어렵다면 추상화의 목적을 상실한 것입니다 [5]. 따라서 패턴이 최소 3번 반복될 때까지 추상화를 미루는 전략이 권장되며, 이를 통해 너무 이른 최적화를 방지하고 코드를 쉽게 디버깅할 수 있는 상태로 유지할 수 있습니다 [5].
|
||||
* **트레이드오프:** 단순하고 직관적인 구조 덕분에 디버깅이 용이해진다는 큰 장점이 있지만, 복잡한 문제에 대해 해결책을 지나치게 단순화(oversimplify)해버릴 위험이 있다는 단점도 존재합니다 [4].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[DRY Principle]], [[Clean Code]], [[Refactoring Techniques]]
|
||||
- **Projects/Contexts:** [[React Component Optimization]], [[Frontend Architecture]]
|
||||
- **Contradictions/Notes:** 코드 중복을 제거하기 위한 [[DRY Principle]]과 충돌할 여지가 있습니다. 과도한 추상화가 코드의 가독성을 해친다면, 무리한 중복 제거보다는 [[KISS Principle]]을 따라 직관성을 유지하는 것이 더 권장됩니다 [5].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,22 @@
|
||||
# [[Large-scale Application Architecture]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
대규모 애플리케이션 아키텍처(Large-scale Application Architecture)는 단순한 스크립트를 넘어 복잡한 분산 소프트웨어 시스템으로 진화한 현대 프론트엔드를 지탱하기 위한 엄격한 구조적 기반입니다 [1]. 이는 유지보수성, 확장성, 성능을 극대화하기 위해 코드를 기술적 역할이 아닌 비즈니스 기능(Feature)과 도메인 중심으로 구성하는 것을 핵심으로 합니다 [1-3]. 대표적으로 Feature-Sliced Design(FSD)과 같은 방법론을 통해 명확한 경계와 캡슐화, 단방향 의존성을 강제하여 시스템의 예측 가능한 성장을 가능하게 합니다 [4-7].
|
||||
|
||||
## 📖 Core Content
|
||||
* **아키텍처의 필요성과 실패 요인**: 리액트 시스템이 대규모로 성장할 때 마주하는 가장 흔한 실패 원인은 렌더링 속도 등의 기술적 요인이 아닌 '아키텍처의 붕괴'입니다 [8, 9]. 비즈니스 로직이 UI 컴포넌트로 새어나가거나, 상태 소유권이 중복되고 불분명해지면, 하나의 변경 사항이 시스템 전체에 영향을 미치는 숨겨진 결합(Hidden coupling)을 생성하여 개발 속도를 급격히 저하시킵니다 [8-10].
|
||||
* **기능 기반 구조와 Feature-Sliced Design (FSD)**: 폴더를 컴포넌트, 훅 등 기술적 파일 유형별로 분리하는 방식은 소규모 앱에서는 직관적이나 대규모 환경에서는 확장성이 매우 떨어집니다 [2, 11-13]. 이에 대한 해결책으로 비즈니스 기능과 사용자 흐름을 중심으로 코드를 구성하는 FSD가 도입되었습니다 [3, 4, 14]. FSD는 프로젝트를 `app`, `pages`, `widgets`, `features`, `entities`, `shared`의 6가지 계층(Layer)으로 엄격히 나눕니다 [5, 7]. 특히 상위 계층은 하위 계층에 의존할 수 있지만 하위는 상위에 의존할 수 없는 '단방향 의존성'과 명시적인 Public API(`index.ts`)를 강제하여 모듈 간의 안정적인 격리를 보장합니다 [5, 6, 15, 16].
|
||||
* **상태 관리(State Management)의 파편화 및 전문화**: 대규모 환경에서는 상태를 단일 스토어에 넣기보다 용도에 맞게 분리하여 관리합니다 [17]. 서버 API로부터 가져오는 데이터(서버 상태)는 TanStack Query를 통해 캐싱과 동기화를 처리하고, 테마와 같은 정적이고 전역적인 상태는 Context API를, 알림이나 장바구니처럼 빈번하게 변하는 동적 애플리케이션 상태는 Zustand를 사용하는 것이 권장됩니다 [18-22]. 단, 개발자가 10명 이상인 대규모 팀에서 얽혀있는 복잡한 상태를 다루고 일관된 패턴을 강제해야 할 때는 Redux가 산업 표준으로서 효과적입니다 [23-25].
|
||||
* **클린 코드와 설계 원칙 (SOLID & DRY)**: 기능형 리액트 컴포넌트에서도 소프트웨어 공학 원칙은 필수적입니다 [16, 26]. 단일 책임 원칙(SRP)에 따라 컴포넌트는 한 가지의 역할만 해야 하며, 300줄이 넘어간다면 여러 개의 작은 컴포넌트로 분리해야 합니다 [27]. 중복 로직은 커스텀 훅으로 추출하여 DRY 원칙을 지키되, 과도한 추상화보다는 직관적이고 단순하게 유지하는 KISS, YAGNI 원칙의 균형이 필요합니다 [28-30].
|
||||
* **성능 최적화 및 빌드 엔지니어링 (Performance & Build)**: 거대한 자바스크립트 번들은 초기 로드를 지연시킵니다 [31-33]. Vite 등의 번들러를 이용해 `manualChunks`로 무거운 벤더 라이브러리(React core 등)를 분리하고, `React.lazy`와 `Suspense`를 결합해 라우트나 기능 수준의 코드 스플리팅을 적용하여 성능을 높여야 합니다 [34-38]. 또한 2025년의 React Compiler는 빌드 타임에 자동으로 메모이제이션을 적용하여 수동 성능 최적화의 번거로움을 줄여줍니다 [34, 39-41].
|
||||
* **복원력 (Resilience) 및 모니터링**: 대규모 앱은 단일 컴포넌트의 런타임 오류가 전체 화면을 백지화하는 것을 막기 위해 Error Boundaries를 주요 위젯이나 불안정한 섹션마다 전략적으로 배치해야 합니다 [42-45]. 또한 프로덕션 레벨에서는 Sentry, LogRocket, Datadog과 같은 도구를 통해 사용자의 에러 발생 맥락(Session Replay)과 메모리 누수 등을 추적하여 디버깅을 고도화합니다 [45-48].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Feature-Sliced Design]], [[State Management]], [[SOLID Principles]], [[Performance Optimization]], [[Clean Code]], [[Error Boundaries]]
|
||||
- **Projects/Contexts:** [[React]], [[Next.js]], [[Vite]], [[Bulletproof React]]
|
||||
- **Contradictions/Notes:**
|
||||
- FSD 아키텍처의 적용에 대해 "모든 코드를 처음부터 세밀하게 슬라이싱하는 것보다 모놀리식으로 시작한 뒤 기능의 경계가 명확해졌을 때 분리하는 것이 낫다"는 상반된 의견이 존재합니다. 처음부터 무리하게 분할하면 3개면 충분할 조각이 수백 개로 나뉘는 부작용이 발생할 수 있습니다 [49].
|
||||
- FSD의 `shared` 계층에 대해서도, 조직이 커짐에 따라 관리가 통제 불능이 되고 버그의 온상이 되어 시스템 변경을 오히려 어렵게 만들 수 있다는 실무적 비판이 있습니다 [50].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,26 @@
|
||||
# [[YAGNI Principle]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
YAGNI는 "You Aren't Gonna Need It"의 약자로, 개발자가 미래에 필요할지도 모른다고 추측하여 복잡한 기능을 미리 구축하는 것을 피하라는 소프트웨어 설계 원칙입니다[1, 2]. 이 원칙은 오직 현재의 요구사항에만 집중함으로써 유지보수해야 할 데드 코드(dead code)와 복잡성을 최소화하는 데 목적이 있습니다[1]. 특히 요구사항이 자주 변경되는 애자일(Agile) 환경이나 스타트업 프로젝트에서 매우 중요하게 다뤄집니다[1, 3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **핵심 개념 및 도입 이유**:
|
||||
YAGNI의 핵심은 "정말로 필요해지기 전까지는 기능을 추가하지 말라"는 것입니다[2]. 언젠가 쓰일지도 모른다는 이유로 추가 기능을 작성하게 되면 코드를 작성하는 시간만 낭비될 뿐만 아니라, 결국 해당 기능이 필요 없어지거나 요구사항이 변경될 가능성이 큽니다[4]. 따라서 개발자는 현재 당장 필요한 기능만 구현하여 불필요한 기술 부채(tech debt)와 잉여 코드를 줄여야 합니다[5].
|
||||
|
||||
* **React 환경에서의 적용 (YAGNI in React)**:
|
||||
React 컴포넌트를 설계할 때도 YAGNI 원칙을 통해 코드를 간결하게 유지할 수 있습니다. 컴포넌트는 오늘 당장 필요한 것만 구현하고 확장은 나중으로 미뤄야 합니다[3].
|
||||
* 예를 들어 현재 날짜의 원시 데이터(raw date)만 필요한 상황이라면, 나중에 쓰일 것 같다는 이유로 날짜 포맷팅 함수를 미리 추가하지 말아야 합니다[2].
|
||||
* 마찬가지로 `<UserProfile />` 컴포넌트가 현재 사용자 정보(`user`)만 필요로 한다면, 아직 화면에 쓰이지 않는 `userSettings`나 `userPosts` 같은 여분의 props를 선제적으로 넘겨주거나 구현하지 않는 것이 좋은 사례입니다[3].
|
||||
|
||||
* **장단점(Trade-offs) 및 최적의 사용 환경**:
|
||||
* **장점**: 낭비되는 개발 노력을 줄여주고 코드베이스를 가볍게 유지할 수 있습니다[6]. 코드 자체가 부채가 되는 상황을 방지하고 불필요한 부분을 제거하는 리팩토링의 훌륭한 기준이 됩니다[5].
|
||||
* **단점**: 미래의 확장성(future scalability)을 간과하게 될 위험성도 내포하고 있습니다[6].
|
||||
* **사용 환경**: 요구사항이 계속해서 변화하는 스타트업 프로젝트나 빠른 릴리스가 중요한 애자일 개발 환경에서 사용하는 것이 가장 적합합니다[3].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[KISS Principle]], [[DRY Principle]], [[Clean Code]], [[Refactoring]]
|
||||
- **Projects/Contexts:** [[React Component Design]], [[Agile Development]], [[Startup Projects]]
|
||||
- **Contradictions/Notes:** YAGNI 원칙은 불필요한 노력의 낭비를 막아주지만, 미래의 확장성을 고려하지 못하게 만들 수 있다는 점이 단점으로 지적되므로 설계 시 균형을 잡는 것이 필요합니다[6].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
Reference in New Issue
Block a user