refactor: Archive_Orphans 정리 및 Frontend/Backend/Architecture 분류 재배치 [2026-05-08]

2026-05-08 19:58:53 +09:00
parent 5ba5a55c78
commit 718dde7ec4
207 changed files with 3130 additions and 2961 deletions
@@ -0,0 +1,25 @@
+---
+id: P-REINFORCE-503A13
+category: "[[10_Wiki/💡 Topics/Game Design]]"
+confidence_score: 0.95
+tags: []
+last_reinforced: 2026-04-20
+github_commit: "[P-Reinforce] Mega Batch 2 - Wikified Arkane Studios"
+---
+
+# [[Arkane Studios]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> 지식 요약 작업 중
+
+## 📖 구조화된 지식 (Synthesized Content)
+본문 구조화 작업 중
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
+- **정책 변화:** Game Design 카테고리의 전문성 확보 및 링크 밀도 최적화.
+
+## 🔗 지식 연결 (Graph)
+
+- Raw Source: [[00_Raw/2026-04-20/Arkane Studios.md]]
+---
@@ -0,0 +1,25 @@
+---
+id: P-REINFORCE-375B82
+category: "[[10_Wiki/💡 Topics/Economics & Algorithms]]"
+confidence_score: 0.95
+tags: []
+last_reinforced: 2026-04-20
+github_commit: "[P-Reinforce] Mega Batch 2 - Wikified Auction Theory"
+---
+
+# [[Auction Theory]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> 지식 요약 작업 중
+
+## 📖 구조화된 지식 (Synthesized Content)
+본문 구조화 작업 중
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
+- **정책 변화:** Economics & Algorithms 카테고리의 전문성 확보 및 링크 밀도 최적화.
+
+## 🔗 지식 연결 (Graph)
+
+- Raw Source: [[00_Raw/2026-04-20/Auction Theory.md]]
+---
@@ -0,0 +1,36 @@
+---
+category: Architecture
+tags: [auto-wikified, technical-documentation, architecture]
+title: Dependency Injection
+description: "의존성 주입(Dependency Injection, DI)은 클래스가 필요로 하는 의존성(객체)을 직접 생성하지 않고 프레임워크나 외부 컨테이너를 통해 주입받도록 하는 소프트웨어 아키텍처 패턴이다 [1-3]."
+last_updated: 2026-05-04
+---
+
+# Dependency Injection
+
+## 📌 Brief Summary
+의존성 주입(Dependency Injection, DI)은 클래스가 필요로 하는 의존성(객체)을 직접 생성하지 않고 프레임워크나 외부 컨테이너를 통해 주입받도록 하는 소프트웨어 아키텍처 패턴이다 [1-3]. 이를 통해 시스템 컴포넌트 간의 강한 결합을 방지하고 유연성을 높일 수 있다 [1]. Spring Boot, NestJS, Vue 3 등 현대 프레임워크 전반에서 핵심 구조로 채택되어 코드의 테스트 가능성과 모듈성을 극대화하는 데 사용된다 [2-4].
+
+## 📖 Core Content
+* **설계 원칙과 테스트 가능성 확보**: 
+  DI는 의존성 역전 원칙(Dependency Inversion Principle)을 구현하는 구체적인 수단이다 [1]. 구체적인 구현체에 직접 의존하는 대신 생성자 등을 통해 필요한 의존성을 주입받도록 함으로써, 시스템의 결합도를 낮추고 유연성을 제공한다 [1, 3]. 특히 단위 테스트(Unit testing) 환경에서 비즈니스 로직을 변경하지 않고도 실제 서비스를 모의(Mock) 객체로 손쉽게 교체할 수 있는 강력한 이점을 제공한다 [2, 3].
+
+* **Spring Boot의 IoC 컨테이너 기반 DI**: 
+  Spring Boot는 Java 어노테이션을 활용하는 제어의 역전(IoC) 컨테이너를 통해 DI를 구현한다 [5, 6]. 애플리케이션 시작 시 컨테이너가 어노테이션을 읽어 의존성 그래프를 구성하며, 수동 연결(Manual wiring) 없이 생성자를 통해 빈(Bean)을 자동으로 주입한다 [6, 7]. 
+
+* **NestJS의 데코레이터 기반 DI**: 
+  Node.js 생태계의 NestJS는 Angular의 설계 철학을 도입하여 TypeScript 데코레이터 기반의 강력한 의존성 주입 컨테이너를 제공한다 [3, 5, 8]. 클래스의 생성자에 필요한 의존성(예: 데이터베이스 서비스, 캐시 서비스 등)을 선언하기만 하면 프레임워크가 알아서 이를 제공하여 코드의 응집도를 높인다 [2, 3].
+
+* **Vue 3의 Provide/Inject를 통한 의존성 주입**: 
+  프론트엔드 환경인 Vue 3에서는 Provide/Inject 시스템이 DI의 역할을 수행한다 [4]. 이 패턴을 통해 글로벌 로거, API 클라이언트, 상태 등 공유 서비스를 최상위 공급자에서 깊게 중첩된 하위 컴포넌트로 직접 "텔레포트"할 수 있으며, 이로 인해 중간 계층 컴포넌트들이 불필요한 데이터를 전달받는 'Prop Drilling' 현상을 방지한다 [4, 9].
+
+## ⚖️ Trade-offs & Caveats
+* **성능 오버헤드**: 
+  의존성 주입 시스템과 이를 위한 데코레이터 처리는 런타임 성능에 약간의 오버헤드를 유발할 수 있다 [10]. 예를 들어, NestJS의 경우 DI 시스템의 추상화 계층으로 인해 순수 Express 프레임워크를 사용할 때보다 초당 요청 처리량(Throughput)이 약 10~15% 정도 감소할 수 있다 [10].
+* **과도한 스캐폴딩과 구조적 복잡성**: 
+  DI 컨테이너와 모듈 시스템을 올바르게 구축하려면 많은 설정과 보일러플레이트 코드 작성이 요구된다 [11, 12]. 2~5명 규모의 소규모 팀이나 단순한 기능의 프로젝트에서는 이러한 구조적 제약이 실제 비즈니스 가치 창출보다 프레임워크 배선(Wiring) 작업에 더 많은 시간을 쏟게 하는 비용(기술 부채)으로 작용할 수 있다 [11].
+* **프레임워크 우회 시 발생하는 안티 패턴**: 
+  DI를 지원하는 프레임워크 환경에서 개발자가 DI 컨테이너를 우회하여 직접 의존성을 인스턴스화(예: `new UsersService()`와 같이 객체를 수동 생성)하는 방식은 시스템의 이점을 파괴한다 [13]. 이와 같은 수동 의존성 연결은 아키텍처의 일관성을 해치고 테스트 가능성을 완전히 상실하게 만든다 [13].
+
+---
+*Last updated: 2026-05-03*