# [[YAGNI]]

## 📌 Brief Summary
YAGNI는 "You Aren't Gonna Need It(당신은 그것이 필요하지 않을 것이다)"의 약자로, 미래에 필요할지도 모르는 기능을 미리 구현하지 말라는 소프트웨어 엔지니어링 원칙입니다 [1, 2]. 개발자는 오직 현재의 요구사항에만 집중해야 하며, 나중에 사용될 수도 있다는 이유만으로 복잡한 기능을 사전에 추가하는 것을 피해야 합니다 [1, 3]. 이 원칙을 통해 개발자는 시간 낭비를 줄이고, 유지보수해야 할 코드의 양과 복잡성을 최소화할 수 있습니다 [1, 4].

## 📖 Core Content
*   **핵심 개념 및 목적**: YAGNI는 현재 명확히 요구되지 않은 기능에 대해 개발 시간을 낭비하지 않도록 돕는 실용주의적 방법론입니다 [3]. 미래를 대비해 선제적으로 작성한 추가 기능은 결국 실제 사용되지 않을 확률이 높으며, 추후 요구사항이 변경되면 애써 작성한 코드가 아예 불필요해질 수도 있습니다 [3]. 
*   **React 및 프론트엔드 생태계에서의 적용**: React 컴포넌트를 개발할 때, 현재 컴포넌트가 당장 필요로 하는 기능과 속성(props)만을 먼저 구현하는 방식으로 적용됩니다 [5]. 확장성은 추후 실제로 그 기능이 필요해졌을 때 고려하여 덧붙이는 형태를 취합니다 [5].
*   **적용 환경**: 특히 요구사항이 빠르고 빈번하게 변경되는 애자일(Agile) 개발 환경이나 스타트업 프로젝트에서 매우 중요한 원칙으로 작용합니다 [1, 5]. 현재 기능에 집중함으로써 프로젝트의 방향 전환 시 불필요한 레거시 코드가 발목을 잡는 것을 방지합니다.

## ⚖️ Trade-offs & Caveats
YAGNI 원칙을 준수하면 개발 과정에서 낭비되는 노력(wasted effort)을 크게 줄일 수 있고 시스템 내에 방치되는 데드 코드(dead code)를 최소화할 수 있다는 강력한 장점이 있습니다 [1, 4]. 

하지만 반대 급부(Trade-off)로 **미래의 확장성(future scalability)을 간과할 위험**이 있습니다 [4]. 당장의 요구사항에만 지나치게 초점을 맞추다 보면, 추후 시스템을 대규모로 확장하거나 근본적인 변경이 필요할 때 기존 구조가 유연하게 대응하지 못하여 오히려 더 큰 리팩토링 비용을 초래할 수 있는 제약 사항이 존재합니다 [4].

## 🔗 Knowledge Connections

### Related Concepts

#### [소프트웨어 엔지니어링 원칙 (Software Engineering Principles)]
- [[KISS]]
  - 연결 이유: "Keep It Simple, Stupid"의 약자로, 코드를 단순하게 유지하고 복잡성을 피하라는 원칙이므로 YAGNI와 방향성을 공유합니다 [2, 6].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: YAGNI가 기능의 '추가 여부(개발할 것인가 말 것인가)'를 결정한다면, KISS는 개발하기로 결정된 기능을 '얼마나 단순하게 구현할 것인가'를 규정하여 클린 코드 작성을 돕습니다 [2].
- [[DRY]]
  - 연결 이유: "Don't Repeat Yourself"의 약자로, YAGNI, KISS와 함께 반복을 줄이고 유지보수성을 높이는 또 다른 핵심 원칙으로 묶여 언급됩니다 [2, 6].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 중복 코드를 제거하기 위해 추상화(Custom Hooks 등)를 도입할 때, 과도한 추상화(Over-engineering)로 이어지지 않도록 YAGNI 원칙과 어떻게 상호 보완적으로 작용해야 하는지 이해할 수 있습니다 [5, 6].
- [[SOLID]]
  - 연결 이유: 확장성과 유지보수성이 높은 코드를 작성하기 위한 5가지 원칙 모음으로, React 환경에서도 컴포넌트를 분리하고 결합도를 낮추는 기반 기술로 작용합니다 [7, 8].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 아키텍처 수준에서 단일 책임 원칙(SRP)이나 개방/폐쇄 원칙(OCP)을 지키는 뼈대를 구축하면서도, YAGNI를 통해 불필요한 클래스나 인터페이스 확장을 어떻게 제어할 수 있는지 균형점을 학습할 수 있습니다 [8, 9].

### Deeper Research Questions
- YAGNI 원칙을 적용할 때, '미래를 대비한 유연한 아키텍처 설계'와 불필요한 '오버엔지니어링(Over-engineering)' 사이의 경계는 구체적으로 어떻게 정의하고 판단할 수 있는가?
- 애자일(Agile) 환경에서 YAGNI 원칙이 잦은 요구사항 변경에 대한 시스템의 대처 능력을 본질적으로 어떻게 향상시키는가?
- 미래의 확장성을 희생할 수 있다는 YAGNI의 단점(Trade-off)을 보완하면서도 초기 개발 속도를 유지하기 위한 아키텍처 패턴은 무엇인가?
- React 컴포넌트 설계 시 YAGNI 원칙을 고수하여 단순하게 만들었다가, 추후 대규모 비즈니스 로직이 추가되어 전면적인 리팩토링이 불가피해지는 상황을 완화할 방법은 없는가?
- "가장 단순한 해결책"을 요구하는 KISS 원칙과 "미래의 기능 배제"를 요구하는 YAGNI 원칙이 실무 코드 구현 중 서로 상충하거나 모순을 일으키는 사례는 무엇인가?

### Practical Application Contexts
- **Implementation:** React 등 프론트엔드 컴포넌트를 구현할 때, 당장 사용되지 않을 props 속성을 예상하여 선언해두거나 쓰이지 않을 헬퍼 함수를 미리 만들어두는 것을 금지함으로써 적용합니다 [5].
- **System Design:** 소프트웨어 설계 시 현재의 비즈니스 요구사항(Business Needs)에 직결되지 않는 부가적인 시스템 레이어나 복잡한 디자인 패턴의 도입을 보류합니다.
- **Operation / Maintenance:** 미래를 위해 남겨둔 미사용 코드(dead code)가 생기지 않으므로, 유지보수 시 개발자가 파악하고 테스트해야 할 코드의 양이 줄어들어 운영 효율성이 증가합니다 [1].
- **Learning Path:** 클린 코드(Clean Code)의 기초를 다지고, 객체지향 및 함수형 프로그래밍의 핵심 원칙(SOLID, DRY, KISS)을 학습하는 과정에서 실용주의적 개발 마인드셋을 갖추기 위해 필수적으로 함께 학습됩니다 [7, 10].
- **My Project Relevance:** 기획이 수시로 변경될 수 있는 스타트업 프로젝트나 MVP(Minimum Viable Product) 모델을 개발할 때, 개발 속도를 최적화하고 불필요한 기능 개발에 리소스를 낭비하지 않는 데 직접적으로 활용됩니다 [5].

### Adjacent Topics
- [[Agile Development]]
  - 확장 방향: YAGNI 원칙이 왜 애자일의 짧은 스프린트 및 반복적 개발 주기와 궁합이 잘 맞는지, 프로젝트 관리 및 개발 라이프사이클 관점에서 이해를 확장할 수 있습니다.
- [[Clean Code]]
  - 확장 방향: YAGNI, DRY, KISS와 같은 원칙들이 궁극적으로 가독성 높고 유지보수하기 쉬운 코드베이스(Clean Code)를 어떻게 완성하는지 통합적인 관점으로 확장해 볼 수 있습니다 [2].

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