[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -2,111 +2,193 @@
|
||||
id: wiki-2026-0508-component-based-architecture-cba
|
||||
title: Component Based Architecture (CBA)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [CBA, Component-Based Software Engineering, CBSE]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [architecture, components, modularity, reuse]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: typescript
|
||||
framework: react-vue-angular
|
||||
---
|
||||
|
||||
# [[Component-Based Architecture (CBA)|Component-Based Architecture (CBA]]
|
||||
# Component Based Architecture (CBA)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
컴포넌트 기반 아키텍처([[Component-Based Architecture|Component-Based Architecture]], CBA)는 독립적이고 모듈화된, 재사용 가능한 소프트웨어 컴포넌트들을 조립하여 애플리케이션을 구축하는 최신 소프트웨어 설계 패러다임입니다[1-3]. 레고 블록을 맞추듯 각 컴포넌트가 특정 기능을 수행하며, 명확히 정의된 인터페이스(API)를 통해 서로 통신합니다[2, 4]. 이 접근 방식은 소프트웨어를 처음부터 개발하는 대신 표준화된 부품을 재사용함으로써 유지보수성을 높이고 개발 속도를 앞당기며 뛰어난 확장성을 제공합니다[4-6].
|
||||
## 매 한 줄
|
||||
> **"매 시스템 = 매 independent, replaceable, composable component 의 합."**. CBSE는 1960s OOP의 reuse 약속을 modular contract로 실현한 패러다임. 2026년 frontend (React/Vue/Angular), microservices, design systems, embedded (OSGi), game engines (Unity ECS) 모두 CBA의 변형.
|
||||
|
||||
## 📖 Core 소스 Content
|
||||
## 매 핵심
|
||||
|
||||
* **컴포넌트의 정의 및 핵심 특징**
|
||||
컴포넌트는 특정 기능을 캡슐화한 재사용 가능하고 독립적인 소프트웨어 단위입니다[7]. 주요 특징으로는 내부 구현과 데이터를 숨기고 필요한 인터페이스만 노출하는 **캡슐화(Encapsulation)**, 여러 언어나 플랫폼 간에도 표준 인터페이스를 통해 통신할 수 있는 **상호 운용성([[Interoperability|InterOperability]])**, 더 큰 시스템을 구성하기 위해 쉽게 플러그인 할 수 있는 **조립성(Composability)**, 그리고 기존 기능을 손상시키지 않고 교체할 수 있는 **대체 가능성(Replaceability)**이 있습니다[8-13].
|
||||
### 매 component 의 정의
|
||||
- **Encapsulation**: state + behavior + interface = 단일 unit.
|
||||
- **Well-defined contract**: input props/events, output events, side effects 명시.
|
||||
- **Replaceable**: 동일 interface 의 다른 impl 으로 swap 가능.
|
||||
- **Independently deployable** (microservices) 또는 **independently versionable** (libraries).
|
||||
|
||||
* **컴포넌트 기반 개발의 주요 장점**
|
||||
* **개발 속도 향상 및 비용 절감(Faster Time-to-Market):** 기존 컴포넌트를 재사용하여 반복적인 코딩을 방지함으로써 제품 출시를 가속화하고 개발 비용을 낮춥니다[14, 15].
|
||||
* **확장성([[Scalability|Scalability]]):** 트래픽이나 요구사항이 증가할 때 시스템 전체가 아닌 장바구니, 결제 등 특정 컴포넌트만 개별적으로 추가 및 확장할 수 있습니다[16-18].
|
||||
* **유지보수 및 병렬 개발(Maintainability & Collaboration):** 한 컴포넌트의 버그 수정이나 업데이트가 전체 시스템에 미치는 영향을 최소화합니다. 또한, 여러 팀이 서로 다른 컴포넌트(프론트엔드, 백엔드 등)를 동시에 개발할 수 있어 협업이 효율적입니다[14, 16, 18-20].
|
||||
### 매 4 properties (Szyperski)
|
||||
1. **Independent deployment** unit.
|
||||
2. **Composition** by third parties.
|
||||
3. **No persistent state** (pure or state-injected).
|
||||
4. **Explicit context dependencies** (interface 로 명시).
|
||||
|
||||
* **설계 원칙 및 구현 방법**
|
||||
CBA 시스템을 구현할 때는 모듈성, 추상화, 그리고 역할에 따른 '관심사 분리([[_뇌와 팔다리의 분리_ - 관심사의 분리 (Separation of Concerns)|Separation of Concerns]])'를 원칙으로 삼아야 합니다[8, 21]. 시스템의 기능 및 비기능적 요구사항을 분석한 후 도메인 주도 설계(DDD) 등의 기법을 사용해 컴포넌트 경계를 식별합니다[22, 23]. 이후 명확한 API 및 통신 프로토콜(예: REST, gRPC 등)을 설계하고, 각각 독립적으로 개발 및 유닛 테스트를 진행한 뒤, CI/CD 파이프라인을 통해 통합 및 배포를 수행합니다[24-26].
|
||||
### 매 응용
|
||||
1. Frontend UI (React component tree).
|
||||
2. Microservices (service = component).
|
||||
3. Plugin systems (VSCode extensions, Figma plugins).
|
||||
4. Game engines (Unity GameObject + Components).
|
||||
5. Web Components (Custom Elements, Shadow DOM).
|
||||
|
||||
* **구현 시 직면하는 한계 및 과제**
|
||||
* **초기 설계의 복잡성과 통합 오버헤드:** 시스템을 모듈화하고 인터페이스와 의존성을 명확히 정의하는 초기 계획 단계가 까다롭습니다[27-29]. 서로 다른 팀이 개발한 컴포넌트 간의 통신과 매끄러운 통합을 보장하는 것에도 오버헤드가 발생합니다[29, 30].
|
||||
* **성능 저하 및 의존성 관리:** 네트워크 호출이나 프로세스 간 통신 등 컴포넌트 상호작용으로 인해 성능 오버헤드와 지연(Latency)이 발생할 수 있습니다[27, 30, 31]. 또한, 다수의 컴포넌트가 다양한 버전의 라이브러리에 의존할 경우 버전 충돌 및 관리가 매우 복잡해집니다[31, 32].
|
||||
* **보안 및 과잉 엔지니어링 위험:** 각 컴포넌트의 업데이트 주기가 달라 최신화되지 않은 컴포넌트가 전체 시스템의 보안 취약점이 될 수 있으며[33], 유연성만을 추구하다 보면 시스템을 너무 잘게 쪼개어 과잉 엔지니어링(Over-engineering)으로 이어질 위험도 존재합니다[34].
|
||||
## 💻 패턴
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** Microservices Architecture, Service-Oriented Architecture (SOA), Monolithic Architecture, Object-Oriented Architecture
|
||||
- **Projects/Contexts:** React, Angular, Vue.js, PayPal, Spotify, Uber, Walmart
|
||||
- **Contradictions/Notes:** 소스에 따르면, 객체 지향 아키텍처(Object-Oriented Architecture)와 CBA는 원칙을 일부 공유하지만 차이가 있습니다. 객체 지향 아키텍처가 단일 애플리케이션 내에서 데이터와 동작을 캡슐화하는 데 중점을 둔다면, CBA는 여러 시스템 및 애플리케이션 전반에서 상호작용하고 재사용할 수 있는 독립적인 단위 생성을 강조합니다[35]. 또한 기존의 모놀리식 아키텍처(Monolithic Architecture)는 시스템 전체를 하나의 코드베이스로 묶어 확장 및 유지보수가 어렵지만, CBA는 느슨하게 결합된 모듈을 통해 독립적인 배포와 병렬 개발을 가능하게 합니다[36, 37].
|
||||
### React functional component
|
||||
```typescript
|
||||
type ButtonProps = {
|
||||
variant: 'primary' | 'ghost';
|
||||
onClick: () => void;
|
||||
children: React.ReactNode;
|
||||
};
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
export function Button({ variant, onClick, children }: ButtonProps) {
|
||||
return (
|
||||
<button
|
||||
className={`btn btn-${variant}`}
|
||||
onClick={onClick}
|
||||
>
|
||||
{children}
|
||||
</button>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Web Component (framework-agnostic)
|
||||
```typescript
|
||||
class TodoItem extends HTMLElement {
|
||||
static observedAttributes = ['done', 'label'];
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
attributeChangedCallback(name: string, _old: string, value: string) {
|
||||
this.render();
|
||||
}
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
connectedCallback() {
|
||||
this.attachShadow({ mode: 'open' });
|
||||
this.render();
|
||||
}
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
private render() {
|
||||
if (!this.shadowRoot) return;
|
||||
const done = this.hasAttribute('done');
|
||||
this.shadowRoot.innerHTML = `
|
||||
<style>:host { display: block; }</style>
|
||||
<label>
|
||||
<input type="checkbox" ${done ? 'checked' : ''} />
|
||||
<span>${this.getAttribute('label') ?? ''}</span>
|
||||
</label>
|
||||
`;
|
||||
}
|
||||
}
|
||||
customElements.define('todo-item', TodoItem);
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### Composition over inheritance
|
||||
```typescript
|
||||
// Bad: deep inheritance
|
||||
class AdminButton extends IconButton extends Button { }
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
// Good: composition
|
||||
function AdminButton({ icon, ...rest }: AdminButtonProps) {
|
||||
return (
|
||||
<Button {...rest}>
|
||||
<Icon name={icon} />
|
||||
<span>{rest.children}</span>
|
||||
</Button>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
### Dependency injection (explicit context)
|
||||
```typescript
|
||||
type Logger = { info(msg: string): void };
|
||||
|
||||
export function createPaymentService({ logger, gateway }: {
|
||||
logger: Logger;
|
||||
gateway: PaymentGateway;
|
||||
}) {
|
||||
return {
|
||||
charge: async (amount: number) => {
|
||||
logger.info(`charging ${amount}`);
|
||||
return gateway.charge(amount);
|
||||
},
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
### ECS component (Unity / Bevy style)
|
||||
```rust
|
||||
// Bevy ECS
|
||||
#[derive(Component)]
|
||||
struct Position { x: f32, y: f32 }
|
||||
|
||||
#[derive(Component)]
|
||||
struct Velocity { dx: f32, dy: f32 }
|
||||
|
||||
fn movement_system(mut query: Query<(&mut Position, &Velocity)>) {
|
||||
for (mut pos, vel) in &mut query {
|
||||
pos.x += vel.dx;
|
||||
pos.y += vel.dy;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Microservice as component
|
||||
```typescript
|
||||
// Each service exposes a typed contract (gRPC / OpenAPI)
|
||||
interface OrderService {
|
||||
createOrder(req: CreateOrderRequest): Promise<Order>;
|
||||
getOrder(id: string): Promise<Order>;
|
||||
}
|
||||
|
||||
// Replaceable impl: REST, gRPC, in-memory mock
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| UI rendering | React/Vue functional components |
|
||||
| Cross-framework UI | Web Components (Lit) |
|
||||
| Backend domain split | Microservice components (gRPC contract) |
|
||||
| Game logic | ECS components (Bevy, Unity DOTS) |
|
||||
| Plugin systems | Component + manifest + sandbox (VSCode model) |
|
||||
|
||||
**기본값**: React 19 functional components + composition; backend은 module 단위 component → 필요 시 microservice 로 추출.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Modularity]] · [[Software Architecture]]
|
||||
- 변형: [[Microservices]] · [[Web Components]] · [[Entity Component System]]
|
||||
- 응용: [[Component Library Architecture]] · [[Compound Components]] · [[Design Systems]]
|
||||
- Adjacent: [[Conceptual Integrity]] · [[Dependency Injection]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: UI/system 의 reusable units 으로 분해, contract-driven team work, plugin ecosystem.
|
||||
**언제 X**: 단일 prototype, throwaway script, 하나의 tight algorithm (component overhead 가 cost > benefit).
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **God component**: 하나의 component 가 too many props/responsibilities — split.
|
||||
- **Prop drilling**: 5+ levels 깊이 prop 전달 — Context/store 로 lift.
|
||||
- **Hidden coupling**: component A 가 component B 의 internal state 의 직접 접근 — contract violation.
|
||||
- **Premature genericization**: 1번만 쓰는 것을 generic 으로 추상화 — YAGNI.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Szyperski "Component Software" 1998 / Brooks 1995 / React docs 2026).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — CBA 4-property canonical + React/ECS/microservice 패턴 |
|
||||
|
||||
Reference in New Issue
Block a user