Refactor: Consolidate directory structure into 5 main categories and update metadata
This commit is contained in:
Antigravity Agent
@@ -1,25 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-662214
|
||||
category: "10_Wiki/💡 Topics/Software [[Architecture|Architecture]]"
|
||||
confidence_score: 0.95
|
||||
tags: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Mega Batch - Wikified API-Contract-Definition"
|
||||
---
|
||||
|
||||
# [[API-Contract-Definition|API-Contract-Definition]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 핵심 요약 작업 진행 중
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
본문 상세 구성 진행 중
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
|
||||
- **정책 변화:** Software Architecture 카테고리의 전문성 확보 및 링크 밀도 최적화.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
|
||||
---
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-E43C2B
|
||||
category: "10_Wiki/💡 Topics/Software [[Architecture|Architecture]]"
|
||||
confidence_score: 0.95
|
||||
tags: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Mega Batch - Wikified API-First Architecture"
|
||||
---
|
||||
|
||||
# [[API-First Architecture|API-First Architecture]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> **API-First Architecture**는 애플리케이션 프로그래밍 인터페이스(API)를 시스템의 최우선 제품으로 취급하는 소프트웨어 설계 방식입니다 [1]. 제품을 먼저 구축하고 나중에 API를 덧붙이는 대신, API의 설계와 문서화부터 개발을 시작합니다 [1]. 이러한 계약 우선(contract-first) 방법론을 통해 API의 일관성과 재사용성을 보장하며, 프론트엔드와 백엔드 개발 팀이 분리되어 병렬로 효율적인 작업을 진행할 수 있도록 지원합니다 [1, 2].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **작동 방식 및 주요 원칙**
|
||||
* **계약 주도 개발 (Contract-Driven Development):** 개발 팀들은 OpenAPI나 AsyncAPI와 같은 사양을 사용하여 엔드포인트, 데이터 모델, 인증 방법 등을 명시한 API 계약(contract)에 동의합니다 [3]. 이렇게 정의된 사양은 이후의 모든 개발 및 통합 작업의 명확한 지침이 됩니다 [3].
|
||||
* **독립적인 개발 주기:** API 계약이 정의되면, 프론트엔드 팀은 모의(Mocked) 버전의 API를 기반으로 즉시 UI 개발과 테스트를 진행할 수 있고, 동시에 백엔드 팀은 실제 비즈니스 로직을 구현할 수 있어 개발 주기가 효과적으로 분리됩니다 [2, 3].
|
||||
* **일관된 클라이언트 경험 제공:** 웹 프론트엔드, 모바일 앱, 서드파티 서비스 등 모든 클라이언트를 위한 중앙 통합 지점 역할을 수행하여, API 소비주체들에게 일관되고 예측 가능한 경험을 보장합니다 [1, 3].
|
||||
|
||||
* **실행 가능한 구현 팁 (Actionable Implementation Tips)**
|
||||
* **API 사양 언어 사용:** REST 아키텍처의 경우 OpenAPI, 이벤트 주도 아키텍처의 경우 AsyncAPI와 같은 표준화된 사양을 사용하여 명확하고 기계가 읽을 수 있는 계약을 생성해야 합니다 [4].
|
||||
* **코드 및 문서 자동 생성:** API 사양 파일에서 직접 서버 스텁(stubs), 클라이언트 SDK 및 대화형 문서를 자동으로 생성하는 도구를 활용하면 수동 작업을 줄이고 문서가 구식이 되는 것을 방지할 수 있습니다 [4].
|
||||
* **병렬 개발을 위한 API 모킹(Mocking):** Postman이나 Stoplight 같은 도구를 사용하여 사양에 기반한 기능적인 모의 서버(Mock server)를 생성해야 합니다 [4]. 이는 프론트엔드 개발자의 작업 병목을 해소하고 조기 테스트와 피드백을 가능하게 합니다 [4].
|
||||
|
||||
* **이상적인 활용 사례 및 기대 효과**
|
||||
* 공개 API([[Public APIs|Public APIs]]) 환경, 다중 팀의 통합이 필요한 프로젝트, 프론트엔드와 백엔드의 병렬 작업이 요구되는 현대적인 분산 시스템에 가장 이상적인 아키텍처입니다 [2, 5].
|
||||
* 명확한 계약의 확립, 병렬 개발을 통한 속도 향상, 더 나은 문서화를 도출할 수 있습니다 [5].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
|
||||
- **정책 변화:** Software Architecture 카테고리의 전문성 확보 및 링크 밀도 최적화.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** Contract-Driven Development, OpenAPI, AsyncAPI
|
||||
- **Projects/Contexts:** Stripe, Twilio (이 철학으로 잘 문서화된 API를 구축하여 비즈니스를 성장시킨 대표적인 기업 사례 [3])
|
||||
- **Contradictions/Notes:** 소스 내에 상충되는 주장은 존재하지 않습니다. 다만, 이 구조의 구현 복잡성은 '중간(Medium)' 수준이며, 성공적인 도입과 유지를 위해서는 스펙 우선(spec-first)의 규율과 명확한 거버넌스가 요구된다고 명시하고 있습니다 [5].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-18*
|
||||
|
||||
---
|
||||
@@ -1,38 +0,0 @@
|
||||
## 📌 Brief Summary
|
||||
애자일 개발(Agile Development)은 불확실한 요구사항과 급변하는 환경 속에서 반복적이고 점진적인 프로세스를 통해 가치를 창출하는 소프트웨어 개발 방법론이다. 불필요한 사전 설계를 지양하는 YAGNI 원칙과 기능 중심의 코드 구조화를 통해 개발 속도와 유연성을 극대화하는 것을 핵심으로 한다.
|
||||
|
||||
## 📖 Core Content
|
||||
1. **YAGNI 원칙의 철저한 준수 (You Aren't Gonna Need It)**
|
||||
- 애자일 환경에서는 미래의 불확실한 사용 사례를 위해 미리 복잡한 기능을 구축하는 오버엔지니어링을 지양해야 한다.
|
||||
- 현재의 요구사항에 집중함으로써 불필요한 복잡성을 제거하고 작업 낭비를 최소화한다.
|
||||
2. **기능 기반 구조(Feature-Based Structure) 설계**
|
||||
- 파일 유형(Type)이 아닌 비즈니스 기능(Feature) 또는 모듈을 중심으로 폴더 구조를 설계하는 것이 애자일 방법론과 높은 정합성을 갖는다.
|
||||
- 각 기능이 독립적으로 생성, 구현, 배포될 수 있도록 보장하여 팀 간의 병렬 협업 효율성을 높인다.
|
||||
3. **반복적 품질 확보**
|
||||
- 단일 책임 원칙(SRP)과 같은 SOLID 원칙을 기반으로 컴포넌트를 설계하여, 빠른 스프린트 주기 속에서도 코드의 유지보수성과 확장성을 유지한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
- **기술 부채의 위험**: YAGNI를 지나치게 엄격하게 적용할 경우, 미래의 확장성을 고려하지 않은 설계로 인해 추후 대규모 리팩토링 비용이 발생할 수 있는 트레이드오프가 존재한다.
|
||||
- **초기 설계 오버헤드**: 소규모 프로젝트에서 기능 기반 구조를 채택할 경우, 단순한 파일 유형 기반 구조보다 폴더 깊이가 깊어지고 초기 구성 비용이 증가할 수 있다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts
|
||||
- **YAGNI**: 애자일 개발의 핵심적인 효율성 추구 원칙 (관계: 하위 실천 지침)
|
||||
- **Feature-Based Structure**: 애자일 팀의 독립적 협업을 돕는 아키텍처 (관계: 구조적 구현체)
|
||||
- **KISS Principle**: 복잡성을 최소화하여 변경에 신속히 대응하는 철학 (관계: 가치 공유)
|
||||
|
||||
### Deeper Research Questions
|
||||
1. 기능 기반 폴더 구조가 마이크로 프론트엔드 아키텍처로의 전환 시 어떤 이점을 제공하는가?
|
||||
2. YAGNI 원칙과 장기적인 코드 품질(Clean Code) 사이의 균형을 맞추는 구체적인 결정 프레임워크는 무엇인가?
|
||||
3. 애자일 반복 주기 내에서 단위 테스트와 통합 테스트의 비중을 어떻게 조절해야 하는가?
|
||||
4. 스프린트 중 발생하는 기술 부채를 백로그에 효과적으로 반영하고 해소하는 프로세스는?
|
||||
5. 기능 독립성이 강화된 구조에서 공통 모듈(Shared)의 비대화를 막기 위한 전략은 무엇인가?
|
||||
|
||||
### Practical Application Contexts
|
||||
- **스프린트 설계**: 새로운 기능을 추가할 때 미래의 확장성보다는 현재 스프린트 목표 달성에 집중하여 코드를 단순하게 유지.
|
||||
- **팀 협업 구조**: 기능별로 폴더를 나누어 개발자 간의 코드 충돌을 최소화하고 독립적인 기능 배포 환경 구축.
|
||||
|
||||
### Adjacent Topics
|
||||
- **SOLID Principles**
|
||||
- **Lean Software Development**
|
||||
- **Extreme Programming (XP)**
|
||||
-29
@@ -1,29 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-4BB54E
|
||||
category: "10_Wiki/💡 Topics/Software [[Architecture|Architecture]]"
|
||||
confidence_score: 0.98
|
||||
tags: [AlphaGo, MCTS, Reinforcement Learning, Simulation, [[Robotics|Robotics]]]
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Substantial content added to AI Simulation Bundle."
|
||||
---
|
||||
|
||||
# [[AlphaGo (Monte Carlo Tree Search RL)] [Autonomous Driving Simulation] [Robotic Manipulation|AlphaGo (Monte Carlo Tree Search + RL)], [Autonomous Driving Simulation], [Robotic Manipulation]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 복잡한 의사결정 문제는 '모든 경우의 수'를 계산하는 것이 아니라, '승리(성공) 가능성이 높은 경로'를 시뮬레이션으로 탐색하고 그 경험을 신경망(RL)에 내재화하는 과정이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **AlphaGo (MCTS + RL)의 정수**:
|
||||
- **Monte Carlo Tree Search (MCTS)**: 무작위 시뮬레이션을 통해 유망한 수(Node)를 확장하고 통계적으로 최적의 수를 찾는다.
|
||||
- **Reinforcement Learning (강화 학습)**: 자가 대국(Self-play)을 통해 정책망(Policy Network)과 가치망(Value Network)을 고도화하여, 인간의 기보를 뛰어넘는 직관을 형성한다.
|
||||
- **자율주행 시뮬레이션 (Autonomous Driving Simulation)**:
|
||||
- 현실에서의 사고는 치명적이다. 디지털 트윈 환경에서 수백만 마일의 가상 주행을 통해 코너 케이스(Edge Cases)를 학습시키고, 이를 현실 세계의 제어 알고리즘으로 이식(Sim-to-Real)한다.
|
||||
- **로봇 조작 (Robotic Manipulation)**:
|
||||
- 물체의 마찰력, 중력, 촉감을 물리 엔진 내에서 물리 법칙으로 구현하고, 강화 학습을 통해 로봇 팔이 정교한 동작을 수행하도록 훈련시킨다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
- 시뮬레이션은 정교할수록 좋지만, 현실과의 괴리인 'Reality Gap'이 항상 존재한다. 이를 해결하기 위해 Domain Randomization(시뮬레이션 환경에 무작위 변동을 주어 강건함을 확보) 기법이 필수적으로 동반되어야 한다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Digital Twins|Digital Twins]] , Reinforcement Learning , [[Systemic_Simulation_Principles|Systemic_Simulation_Principles]]
|
||||
- Foundation: [[Information Theory|Information Theory]]
|
||||
@@ -1,25 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-4F930E
|
||||
category: "10_Wiki/💡 Topics/Software [[Architecture|Architecture]]"
|
||||
confidence_score: 0.95
|
||||
tags: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Mega Batch - Wikified Architectural-Constraint-Enforcement"
|
||||
---
|
||||
|
||||
# [[Architectural-Constraint-Enforcement|Architectural-Constraint-Enforcement]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 핵심 요약 작업 진행 중
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
본문 상세 구성 진행 중
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 지식 자산화 및 기존 네트워크 연동 단계.
|
||||
- **정책 변화:** Software Architecture 카테고리의 전문성 확보 및 링크 밀도 최적화.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
|
||||
---
|
||||
@@ -1,43 +0,0 @@
|
||||
## 📌 Brief Summary
|
||||
Clean Code와 SOLID 원칙은 유지보수성, 가독성, 확장성을 확보하기 위한 소프트웨어 공학의 핵심 설계 지침이다. 현대의 React 생태계에서 이러한 원칙들은 비즈니스 로직과 UI의 결합도를 낮추고, 예측 가능한 컴포넌트 아키텍처를 구축하며, 기술 부채 누적을 방지하는 기반 역할을 한다.
|
||||
|
||||
## 📖 Core Content
|
||||
1. **SOLID Principles in React**
|
||||
- **SRP (단일 책임)**: 컴포넌트나 훅은 하나의 명확한 목적만 가져야 한다 (300줄 기준).
|
||||
- **OCP (개방-폐쇄)**: 코드 수정 대신 컴포넌트 합성(Composition)을 통해 기능을 확장한다.
|
||||
- **ISP (인터페이스 분리)**: 필요한 Props만 전달하여 컴포넌트 간 불필요한 결합을 차단한다.
|
||||
- **DIP (의존성 역전)**: 구체적 구현이 아닌 추상화(Context, Props)에 의존하여 주입받는다.
|
||||
2. **Clean Code & 핵심 원칙**
|
||||
- **DRY (중복 제거)**: 커스텀 훅으로 공통 로직을 추출하되, 과도한 추상화는 경계한다.
|
||||
- **KISS (단순성 유지)**: 복잡한 로직보다 직관적이고 단순한 코드를 우선시한다.
|
||||
- **YAGNI (불필요 기능 배제)**: 당장 필요하지 않은 미래의 확장성을 미리 구현하지 않는다.
|
||||
3. **실무적 가이드라인**
|
||||
- 명확한 네이밍(PascalCase, camelCase)과 낮은 중첩 구조를 유지한다.
|
||||
- 동일 패턴이 3번 이상 반복될 때(`Rule of Three`) 비로소 추상화를 진행하여 섣부른 최적화를 방지한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
- **추상화 vs 단순함**: DRY 원칙을 지키려다 만든 고차원적인 추상화가 오히려 코드의 흐름을 파악하기 어렵게 만들어 KISS 원칙을 위반할 수 있다.
|
||||
- **초기 개발 속도**: 엄격한 원칙 준수는 초기 보일러플레이트와 설계 시간을 증가시키나, 장기적인 유지보수 비용을 획기적으로 줄여준다.
|
||||
- **오버엔지니어링의 위험**: YAGNI를 무시하고 설계한 '미래 대비용' 코드는 결국 사용되지 않는 'Dead Code'가 되어 시스템의 짐이 될 가능성이 높다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts
|
||||
- **Component Composition**: OCP 실현의 핵심 (관계: 구현 패턴)
|
||||
- **Custom Hooks**: DRY 및 SRP를 위한 물리적 단위 (관계: 실천 도구)
|
||||
- **Feature-Sliced Design (FSD)**: 원칙의 구조적 강제 (관계: 아키텍처 프레임워크)
|
||||
|
||||
### Deeper Research Questions
|
||||
1. 함수형 React 환경에서 상속 없이 리스코프 치환 원칙(LSP)을 준수하는 인터페이스 설계 전략은?
|
||||
2. 섣부른 추상화(Premature Abstraction)가 전체 프로젝트의 인지 부하와 유지보수 비용에 미치는 정량적 영향은?
|
||||
3. DIP(의존성 역전)를 위해 Context를 남발할 때 발생하는 성능 저하와 이를 방지하기 위한 'Inversion of Control' 패턴의 조화는?
|
||||
4. Clean Code를 강제하기 위한 정적 분석 도구(ESLint, SonarQube)의 규칙을 팀의 기술적 성숙도에 따라 어떻게 커스터마이징하는가?
|
||||
5. YAGNI 원칙 하에서 '나중에 고치기 쉬운 코드'를 작성하기 위한 아키텍처적 유연성(Flexibility)의 최소 단위는?
|
||||
|
||||
### Practical Application Contexts
|
||||
- **코드 리뷰 기준 수립**: 팀 전체의 코드 품질 상향 평준화를 위한 명확한 체크리스트 제공.
|
||||
- **대규모 리팩토링 가이드**: 복잡하게 얽힌 레거시 코드를 단일 책임 원칙에 따라 분해하고 정돈.
|
||||
|
||||
### Adjacent Topics
|
||||
- **Software Engineering Principles**
|
||||
- **Refactoring Techniques**
|
||||
- **Test Driven Development (TDD)**
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
id: DDD-MASTER-001
|
||||
category: "10_Wiki/💡 Topics/Software [[Architecture|Architecture]]"
|
||||
confidence_score: 1.0
|
||||
tags: [architecture, ddd, strategic-design, tactical-design, ubiquitous-language]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# Domain-Driven Design (DDD, 도메인 주도 설계)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "복잡한 비즈니스 로직을 소프트웨어의 심장으로 만들어라" — 기술적 복잡성보다 비즈니스 도메인의 복잡성을 우선시하며, 개발자와 전문가가 동일한 언어(Ubiquitous Language)로 소통하며 설계하는 방법론.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** 거대한 시스템을 독립적인 의미를 가진 '바운디드 컨텍스트(Bounded Context)'로 나누고, 그 내부를 핵심 도메인 모델 중심으로 구축하는 아키텍처 패턴.
|
||||
- **전략적 설계 (Strategic Design):**
|
||||
- **Ubiquitous Language:** 개발자, 기획자, 도메인 전문가가 모두 사용하는 공통 언어 정의.
|
||||
- **Bounded Context:** 특정 모델이 적용되는 논리적인 경계 설정. 컨텍스트 간의 관계는 Context Map으로 정의.
|
||||
- **Core Domain:** 비즈니스의 가장 핵심적인 가치를 창출하는 영역에 자원 집중.
|
||||
- **전술적 설계 (Tactical Design):**
|
||||
- **Entity & Value Object:** 식별자 기반의 객체와 속성 기반의 값 객체 구분.
|
||||
- **Aggregate:** 데이터 변경의 단위로 묶인 객체들의 집합. Root 엔티티를 통해서만 접근.
|
||||
- **[[Repository|Repository]]:** 도메인 객체의 생명주기를 관리하고 저장소 추상화 제공.
|
||||
- **Domain Service:** 특정 엔티티에 속하기 어려운 비즈니스 로직 처리.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 과거의 데이터베이스 중심 설계(ERD 중심)에서 행위와 도메인 로직 중심의 설계로 전환.
|
||||
- **정책 변화:** Antigravity 프로젝트는 '지식 관리', '게임 엔진', '데이터 수집'을 각각의 Bounded Context로 분리하고, 컨텍스트 간 통신은 메시지 큐를 통한 비동기 방식을 지향함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent:** 10_Wiki/💡 Topics/Software Architecture
|
||||
- **Related:** Bounded-Context, Microservices, Clean-Architecture, Event-Sourcing
|
||||
- **Merged Sources:**
|
||||
- 10_Wiki/Topics/AI/Domain-Driven Design (DDD) in TypeScript.md
|
||||
- 10_Wiki/Topics/AI/Domain-Driven Design (DDD) Type Safety.md
|
||||
- 10_Wiki/Topics/AI/도메인 주도 설계 (Domain-Driven Design DDD).md
|
||||
- 10_Wiki/Topics/[[Frontend|Frontend]]_[[Mastery|Mastery]]/Domain-Driven Design (DDD).md
|
||||
@@ -1,9 +0,0 @@
|
||||
# Index: Topics > Software Architecture
|
||||
|
||||
## 📝 Documents
|
||||
- [[API-Contract-Definition|API-Contract-Definition]]
|
||||
- [[API-First Architecture|API-First Architecture]]
|
||||
- [[AlphaGo (Monte Carlo Tree Search RL)] [Autonomous Driving Simulation] [Robotic Manipulation|AlphaGo (Monte Carlo Tree Search RL)] [Autonomous Driving Simulation] [Robotic Manipulation]]
|
||||
- [[Architectural-Constraint-Enforcement|Architectural-Constraint-Enforcement]]
|
||||
- [[Domain-Driven-Design-DDD|Domain-Driven Design (DDD]]
|
||||
- [[Microservices-Architecture|Microservices-Architecture]]
|
||||
@@ -1,43 +0,0 @@
|
||||
## 📌 Brief Summary
|
||||
레거시 시스템 마이그레이션은 낡은 아키텍처와 코드를 최신 기술 표준으로 전환하여 시스템의 유지보수성, 안정성, 성능을 개선하는 공정이다. 프론트엔드 환경에서는 전체 시스템을 한 번에 재작성하는 위험을 피하기 위해, 기능 개발과 병행 가능한 **점진적 마이그레이션(Incremental Migration)** 전략을 핵심으로 한다.
|
||||
|
||||
## 📖 Core Content
|
||||
1. **점진적 마이그레이션 전략 (Refactor, Do Not Rewrite)**
|
||||
- 시스템 전체를 중단시키지 않고 기능 단위로 하나씩 새로운 스택으로 옮기는 방식을 취한다.
|
||||
- 예: Context API에서 Zustand로 전환 시, 단순한 전역 알림 기능부터 시작하여 점진적으로 복잡한 결제/상태 로직으로 범위를 확대한다.
|
||||
2. **현대화 체크리스트 (Solid Wins)**
|
||||
- JavaScript 코드를 TypeScript로 전환하여 정적 안정성 확보.
|
||||
- 클래스 기반 컴포넌트를 함수형 컴포넌트 및 Hooks로 현대화.
|
||||
- 불필요한 `useEffect`를 제거하고 서버 상태 관리를 Tanstack Query로 이관.
|
||||
3. **커스텀 훅을 통한 로직 격리**
|
||||
- 컴포넌트 내부에 복잡하게 얽힌 비즈니스 로직을 커스텀 훅으로 추출하여 UI와 분리한다.
|
||||
- 이를 통해 UI와 무관하게 비즈니스 로직에 대한 고속 단위 테스트(Unit Test) 수행이 가능해진다.
|
||||
4. **안전망으로서의 테스트**
|
||||
- 마이그레이션 시작 전 기존 동작을 검증하는 테스트 코드를 우선 작성하여, 변경 과정에서 발생할 수 있는 기능 회귀(Regression)를 방지한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
- **과도기적 복잡성**: 점진적 마이그레이션 중에는 두 가지 이상의 기술 스택(예: Redux와 Zustand)이 공존하게 되어 번들 사이즈가 일시적으로 증가하고 데이터 동기화 로직이 복잡해질 수 있다.
|
||||
- **개발 속도 저하**: 새로운 기능 개발과 마이그레이션을 병행할 경우, 리팩토링 비용으로 인해 단기적인 제품 출시 속도가 느려질 수 있다.
|
||||
- **기술 부채의 잔존**: 부분적인 마이그레이션이 중단될 경우, 오히려 시스템이 더 파편화된 상태로 남게 될 위험이 있으므로 명확한 마이그레이션 로드맵이 필요하다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts
|
||||
- **Incremental Migration**: 리스크 최소화를 위한 단계적 전환 기법 (관계: 핵심 전략)
|
||||
- **State Management Architecture**: 레거시 전환의 가장 빈번한 대상 (관계: 주요 마이그레이션 영역)
|
||||
- **Unit Testing**: 마이그레이션의 안정성을 보장하는 안전 장치 (관계: 필수 선행 작업)
|
||||
|
||||
### Deeper Research Questions
|
||||
1. 전체 재작성(Big Bang Rewrite)이 점진적 마이그레이션보다 경제적으로 유리해지는 기술 부채의 임계점은 어디인가?
|
||||
2. 마이그레이션 과도기에서 서로 다른 상태 관리 도구 간의 일관성을 유지하기 위한 'Bridge' 패턴의 구현 방법은?
|
||||
3. 대규모 JS 코드베이스를 TS로 전환할 때, 'any' 타입을 최소화하면서 빌드 오류를 막는 단계적 타입 강화 전략은?
|
||||
4. 마이그레이션 중 발생한 버그가 기술적 결함인지, 기존 레거시의 의도된 동작인지 판별하는 기준은 무엇인가?
|
||||
5. 서버 사이드 렌더링(SSR) 환경에서의 레거시 프레임워크와 최신 프레임워크 간의 트래픽 라우팅 처리 방안은?
|
||||
|
||||
### Practical Application Contexts
|
||||
- **레거시 React 앱 현대화**: 클래스 컴포넌트와 Redux 기반 앱을 함수형 컴포넌트와 Zustand/Query 체제로 전환.
|
||||
- **기술 스택 교체**: 기존 라이브 서비스를 유지하면서 백엔드 API 명세 변경에 따른 프론트엔드 데이터 레이어 리팩토링.
|
||||
|
||||
### Adjacent Topics
|
||||
- **Technical Debt Management**
|
||||
- **Clean Code & Refactoring Patterns**
|
||||
- **Strangler Fig Pattern in Software Architecture**
|
||||
@@ -1,33 +0,0 @@
|
||||
---
|
||||
id: [[P-Reinforce|P-Reinforce]]-AI-048
|
||||
category: "10_Wiki/💡 Topics/Software [[Architecture|Architecture]]"
|
||||
confidence_score: 0.99
|
||||
tags: [microservice, architecture, distributedSystem, [[Scalability|Scalability]]]
|
||||
last_reinforced: 2026-06-XX
|
||||
github_commit: "[P-Reinforce] Processed Microservices-Architecture.md"
|
||||
---
|
||||
|
||||
# [[Microservices-Architecture|Microservices-Architecture]] (마이크로서비스 아키텍처)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 하나의 거대한 애플리케이션을 작고 독립적인 서비스들의 집합으로 나누어, 각 서비스를 독립적으로 개발, 배포, 확장할 수 있게 하는 분산 시스템 설계 방식이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **정의:** 단일 책임 원칙(SRP)을 아키텍처 수준까지 끌어올린 개념이다. 비즈니스 도메인별로 독립적인 서비스 경계(Bounded Context)를 설정하고, 각 서비스를 자체 데이터베이스와 통신 메커니즘으로 운영한다.
|
||||
- **장점 (Scalability & [[Resilience|Resilience]]):**
|
||||
1. **독립적 배포:** 특정 기능의 장애가 전체 시스템에 영향을 미치지 않는다 (Fault Isolation).
|
||||
2. **기술 스택 자유도:** 각 서비스는 가장 적합한 언어와 데이터베이스를 선택할 수 있다 (Polyglot Persistence/Programming).
|
||||
3. **확장성:** 트래픽이 몰리는 특정 서비스만 독립적으로 자원을 증설할 수 있다.
|
||||
- **주요 과제 및 해결책:**
|
||||
1. **분산 트랜잭션 관리:** 여러 서비스에 걸친 데이터 일관성 유지가 어렵다. (해결책: Saga 패턴, 이벤트 기반 아키텍처).
|
||||
2. **서비스 간 통신 오버헤드:** 네트워크 호출이 빈번하여 지연 시간이 발생할 수 있다. (해결책: API Gateway 도입, 메시지 큐 활용).
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 마이크로서비스가 모든 문제의 해결책은 아니다. 서비스 경계 설정 실패(Poor Bounded Context Identification)는 오히려 복잡성만 높이는 '분산 트랜잭션 지옥'을 만들 수 있다.
|
||||
- **정책 변화:** MSA 도입 시, 서비스 간 통신 규약 (API Contract) 정의가 가장 중요한 첫 번째 단계이며, 이를 위한 API 게이트웨이 및 서비스 메시(Service Mesh)의 활용이 표준으로 자리 잡고 있다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Parent: [[Microservices-Architecture|Microservices-Architecture]]
|
||||
- Related: [[Bounded Contexts|Bounded Contexts]] , Event Storming , [[API-First Architecture|API-First Architecture]]
|
||||
|
||||
---
|
||||
@@ -1,41 +0,0 @@
|
||||
## 📌 Brief Summary
|
||||
개방-폐쇄 원칙(Open/Closed Principle, OCP)은 소프트웨어 개체(클래스, 모듈, 함수 등)가 **확장에는 열려 있어야 하고, 수정에는 닫혀 있어야 한다**는 설계 원칙이다. 이는 기존 소스 코드를 변경하지 않고도 시스템의 기능을 확장할 수 있어야 함을 의미하며, React에서는 컴포넌트 합성(Composition)과 주입 패턴을 통해 이를 실현한다.
|
||||
|
||||
## 📖 Core Content
|
||||
1. **확장성과 폐쇄성 (Open & Closed)**
|
||||
- 신규 기능 추가 시 기존 코드를 건드리지 않음으로써 의도치 않은 버그 발생(Side Effects)을 원천 차단한다.
|
||||
- 기존 기능의 안정성을 유지하면서도 변화하는 요구사항에 유연하게 대응하는 것이 핵심 목적이다.
|
||||
2. **React에서의 구현: 컴포넌트 합성 (Composition)**
|
||||
- 상속이 아닌 합성을 권장하는 React의 특성에 따라, `children` prop을 활용하여 외부에서 렌더링 내용을 주입받는 방식으로 확장성을 확보한다.
|
||||
- 예: 기본 Modal 컴포넌트를 수정하지 않고, 내부 콘텐츠를 `children`으로 전달하여 다양한 형태의 모달로 확장.
|
||||
3. **Render Props 및 Slot 패턴**
|
||||
- 구체적인 로직이나 UI 조각을 함수나 객체 형태로 주입받아 컴포넌트 내부 소스 코드의 수정 없이 동작을 변경한다.
|
||||
4. **선언적 추상화**
|
||||
- 조건문(`if/else`)을 통해 컴포넌트 내부에서 모든 케이스를 처리하는 대신, 외부에서 주입된 컴포넌트가 각자의 책임을 다하도록 설계한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
- **추상화 오버헤드**: OCP를 엄격히 지키기 위해 모든 컴포넌트를 합성 구조로 만들면, 컴포넌트 트리가 깊어지고 `props` 전달 경로가 복잡해지는 'Prop Drilling'이나 인지적 부하가 발생할 수 있다.
|
||||
- **KISS 원칙과의 충돌**: 단순한 기능 추가를 위해 복잡한 Render Props나 고차 컴포넌트(HOC)를 도입하는 것은 'Keep It Simple' 원칙에 어긋날 수 있으므로 적절한 균형이 필요하다.
|
||||
- **초기 설계 비용**: 확장을 고려한 인터페이스 설계는 초기 개발 시간을 더 많이 소요하게 만들며, 미래에 발생하지 않을 확장을 대비하는 YAGNI 위반 가능성이 존재한다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts
|
||||
- **Component Composition**: OCP를 실현하는 React의 핵심 기술 (관계: 실천 방법)
|
||||
- **SOLID Principles**: OCP를 포함한 5대 설계 원칙 (관계: 상위 철학)
|
||||
- **Render Props / Children Prop**: 기능 주입을 위한 구체적 API (관계: 구현 도구)
|
||||
|
||||
### Deeper Research Questions
|
||||
1. 컴포넌트 합성을 통해 OCP를 준수할 때, 깊은 트리에 의한 리렌더링 성능 저하를 방지하기 위한 메모이제이션 전략은?
|
||||
2. 함수형 패러다임에서 'Dependency Injection' 개념이 OCP 구현에 어떻게 적용되는가?
|
||||
3. 수백 개의 조건부 UI가 필요한 엔터프라이즈 환경에서 OCP를 지키기 위한 'Strategy Pattern'의 프론트엔드적 해석은?
|
||||
4. 코드 수정 없이 확장만 허용하는 원칙이 대규모 리팩토링이나 기술 스택 교체 시에는 어떻게 유연하게 적용되어야 하는가?
|
||||
5. CSS-in-JS 환경에서 스타일 확장을 OCP 관점에서 설계하는 모범 사례는?
|
||||
|
||||
### Practical Application Contexts
|
||||
- **UI 라이브러리 설계**: 공통 버튼, 모달, 테이블 컴포넌트 제작 시 스타일과 동작을 외부에서 주입 가능하도록 설계.
|
||||
- **복잡한 폼(Form) 엔진**: 새로운 입력 타입이 추가되어도 메인 폼 로직을 수정할 필요 없는 플러그인 방식 구조 구축.
|
||||
|
||||
### Adjacent Topics
|
||||
- **Single Responsibility Principle (SRP)**
|
||||
- **KISS (Keep It Simple, Stupid)**
|
||||
- **Inversion of Control (IoC)**
|
||||
@@ -1,44 +0,0 @@
|
||||
## 📌 Brief Summary
|
||||
Software Engineering Principles(소프트웨어 엔지니어링 원칙)는 유지보수 가능하고 확장 용이한 시스템을 구축하기 위한 핵심 설계 지침이다. 프론트엔드 및 React 생태계에서는 **SOLID**, **Clean Code**, **DRY**, **KISS**, **YAGNI** 원칙을 통해 코드 복잡성을 제어하고 비즈니스 로직과 UI의 명확한 분리를 달성한다.
|
||||
|
||||
## 📖 Core Content
|
||||
1. **SOLID Principles**
|
||||
- **SRP (단일 책임)**: 하나의 컴포넌트/모듈은 하나의 책임만 갖는다 (300줄 룰 등).
|
||||
- **OCP (개방-폐쇄)**: 코드 수정 없이 컴포넌트 합성 등을 통해 기능을 확장한다.
|
||||
- **ISP (인터페이스 분리)**: 필요한 속성(Props)만 전달하여 불필요한 의존성을 제거한다.
|
||||
- **DIP (의존성 역전)**: 구체적 구현이 아닌 추상화(Props, Context)에 의존한다.
|
||||
2. **Clean Code**
|
||||
- 명확한 네이밍, 낮은 중첩 구조, 이해하기 쉬운 함수 작성을 통해 가독성을 확보한다.
|
||||
3. **효율적 개발 원칙 (DRY, KISS, YAGNI)**
|
||||
- **DRY**: 커스텀 훅 등으로 로직을 재사용하되 과도한 추상화는 경계한다.
|
||||
- **KISS**: 단순함을 유지하여 디버깅 용이성을 확보한다.
|
||||
- **YAGNI**: 당장 필요하지 않은 기능(미래 예측)을 미리 구현하지 않아 기술 부채를 방지한다.
|
||||
4. **아키텍처적 적용 (FSD)**
|
||||
- 엔지니어링 원칙을 폴더 구조와 의존성 규칙으로 구현하여 모듈 간 캡슐화를 극대화한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
- **DRY vs KISS**: 중복을 제거하기 위해 만든 복잡한 추상화가 오히려 코드의 가독성을 떨어뜨릴 수 있으므로, 'Rule of Three'(3번 반복 시 추출)를 권장한다.
|
||||
- **YAGNI vs 확장성**: 미래를 대비하지 않는 것이 자칫 아키텍처의 유연성을 떨어뜨려 나중에 더 큰 수정 비용을 발생시킬 수 있으므로 적절한 밸런스가 필요하다.
|
||||
- **추상화의 비용**: 인터페이스 분리와 의존성 역전을 철저히 지키려다 보면 보일러플레이트 코드가 증가하여 개발 속도가 일시적으로 저하될 수 있다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts
|
||||
- **SOLID**: 세부 설계 원칙의 집합 (관계: 상위 원칙)
|
||||
- **Clean Code**: 궁극적인 코드 상태 (관계: 품질 목표)
|
||||
- **Feature-Sliced Design (FSD)**: 원칙의 물리적 구현 (관계: 구조적 방법론)
|
||||
|
||||
### Deeper Research Questions
|
||||
1. 함수형 React 환경에서 상속이 없는 LSP(리스코프 치환)와 DIP(의존성 역전)의 실질적인 구현 패턴은?
|
||||
2. '추상화의 비용'이 실제 프로젝트의 유지보수 비용(TCO)을 앞지르는 임계점은 어떻게 판단하는가?
|
||||
3. 애자일 환경에서 YAGNI 원칙을 지키면서도 '기술적 런웨이(Architectural Runway)'를 확보하는 방법은?
|
||||
4. 인터페이스 분리 원칙(ISP)을 위반하여 거대 객체를 Props로 넘길 때 발생하는 리렌더링 성능 저하의 메커니즘은?
|
||||
5. Clean Code 원칙을 팀원들 사이에서 동기화하기 위한 자동화된 '코드 스멜' 탐지 도구 활용 방안은?
|
||||
|
||||
### Practical Application Contexts
|
||||
- **신규 프로젝트 초기 설계**: 아키텍처 원칙 수립 및 코드 컨벤션 강제를 통한 품질 기반 마련.
|
||||
- **레거시 코드 리팩토링**: 냄새나는 코드를 식별하고 엔지니어링 원칙에 따라 구조화 및 분해.
|
||||
|
||||
### Adjacent Topics
|
||||
- **Design Patterns in Frontend**
|
||||
- **Refactoring Techniques**
|
||||
- **Test Driven Development (TDD)**
|
||||
@@ -1,40 +0,0 @@
|
||||
## 📌 Brief Summary
|
||||
스타트업 프로젝트(Startup Projects)는 제한된 리소스와 시간 내에 빠른 시장 검증(MVP)을 목표로 하는 고속 개발 환경이다. 요구사항이 수시로 변하는 특성에 맞춰, 단순하면서도 확장성 있는 기술 스택(Zustand 등)과 실용적인 개발 원칙(YAGNI, 단순 브랜치 전략)을 채택하여 민첩성을 확보하는 것이 핵심이다.
|
||||
|
||||
## 📖 Core Content
|
||||
1. **상태 관리 도구의 실용적 선택**
|
||||
- 초기부터 복잡한 Redux를 도입하기보다, 보일러플레이트가 적고 빠른 배포가 가능한 **Zustand**를 활용하여 MVP를 신속히 구축한다.
|
||||
2. **YAGNI 원칙의 철저한 준수**
|
||||
- 미래의 불확실한 요구사항을 미리 대비한 오버엔지니어링을 지양하고, 현재 당장 필요한 핵심 기능 구현에만 집중한다.
|
||||
3. **비용 효율적 모니터링**
|
||||
- Sentry의 무료 티어나 초기 비용이 저렴한 오픈소스/클라우드 대안(SigNoz 등)을 활용하여 프로덕션 안정성을 확보하면서 지출을 관리한다.
|
||||
4. **민첩한 협업 프로세스**
|
||||
- 복잡한 Git Flow 대신 단순한 **Feature-branch workflow**를 사용하여 코드 리뷰 속도를 높이고 병합 충돌을 최소화한다.
|
||||
- 짧은 수명의 브랜치와 Squash Merge를 통해 깨끗한 main 이력을 유지한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
- **기술적 부채의 축적**: 빠른 배포를 위한 단순한 설계가 서비스 성장 시점에서 성능이나 확장성 병목을 유발할 수 있으므로, 적절한 시기의 리팩토링 계획이 병행되어야 한다.
|
||||
- **도구의 한계**: Zustand와 같은 가벼운 도구는 규모가 커질 때 엄격한 구조적 제약이 부족하여 상태 관리가 파편화될 위험이 있다.
|
||||
- **오버엔지니어링의 유혹**: 최신 기술이나 복잡한 아키텍처(FSD 등)를 무분별하게 도입할 경우 스타트업의 최대 자산인 '속도'를 잃을 수 있다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts
|
||||
- **Zustand**: 스타트업에 적합한 가벼운 상태 관리 (관계: 권장 도구)
|
||||
- **YAGNI**: 자원 낭비를 막는 핵심 원칙 (관계: 설계 철학)
|
||||
- **Feature-branch workflow**: 소규모 팀 협업 최적화 (관계: 프로세스 모델)
|
||||
|
||||
### Deeper Research Questions
|
||||
1. Zustand 기반 MVP가 대규모 엔터프라이즈급(Scale-up)으로 전환될 때 마주하는 기술적 임계점과 전환 시나리오는?
|
||||
2. YAGNI를 고수하면서도 '수정하기 쉬운 코드'를 작성하여 미래의 변화 가능성을 열어두는 구체적 기법은?
|
||||
3. 스타트업 환경에서 FSD와 같은 엄격한 아키텍처가 개발 속도에 미치는 실제 영향과 도입 시점은 언제인가?
|
||||
4. 초기 비용을 아끼기 위해 채택한 오픈소스 모니터링 도구가 운영 부하로 돌아올 때의 트레이드오프 계산법은?
|
||||
5. 소수 인원 팀에서 코드 리뷰의 품질과 속도 사이의 균형을 맞추기 위한 자동화(Lint, CI)의 최소 범위는?
|
||||
|
||||
### Practical Application Contexts
|
||||
- **MVP 신속 구축**: 수 주 내에 시장 반응을 확인해야 하는 신규 서비스 런칭.
|
||||
- **소규모 개발팀 리드**: 2~5인 규모의 조직에서 협업 효율을 극대화하는 워크플로우 수립.
|
||||
|
||||
### Adjacent Topics
|
||||
- **Agile Development & Scrum**
|
||||
- **Minimum Viable Product (MVP) Strategy**
|
||||
- **Technical Debt Management**
|
||||
Reference in New Issue
Block a user