refactor(topics): 멀티 에이전트용 지식 재편 — _Common(공통 기본기) + Domain_* 구조

에이전트 8종(대화형/프로그래머 C·S/디자이너/설계자/기획자/QA/PD/PM)에게
[공통 기본 능력 + 롤별 Specialty] 2층으로 지식을 주입하기 위한 재분류.
문서 내용·포맷은 무수정, 폴더 이동만 (6,372개 문서 수 보존 확인).

- Topic_Programming → Domain_Programming (내부 구조 보존)
- Topic_Graphic → Domain_Design
- Topic_Business → Domain_Product
- Topic_General → Domain_General
- _Common 신설: Math(구 Topic_Math_Specialty), Reasoning(구 General/From_Thinking & Reasoning),
  Reasoning_Creativity(구 General/From_창의성), Communication(Poetic_Blog_Writing + From_writing)
- 타 도메인의 From_* 폴더는 유지 (출처 표기일 뿐, 이미 도메인에 맞게 분류된 문서)
- 빈 폴더 정리 (memory/procedures)
- 에이전트→폴더 매핑은 workspace의 .astra/agent-knowledge-map.json (9개 에이전트)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

10_Wiki/Topics/Domain_Programming/Architecture/Space-Based_Architecture.md

@@ -0,0 +1,137 @@
+---
+id: wiki-2026-0508-space-based-architecture
+title: Space-Based Architecture
+category: 10_Wiki/Topics
+status: verified
+canonical_id: self
+aliases: [Space-Based Architecture, SBA, Tuple Space Architecture]
+duplicate_of: none
+source_trust_level: A
+confidence_score: 0.85
+verification_status: applied
+tags: [architecture, scalability, in-memory-data-grid]
+raw_sources: []
+last_reinforced: 2026-05-10
+github_commit: pending
+tech_stack:
+  language: java
+  framework: hazelcast
+---
+
+# Space-Based Architecture
+
+## 매 한 줄
+> **"매 database bottleneck 의 제거 — 매 in-memory data grid (tuple space) + 매 processing units 의 horizontal scale"**. Linda tuple space (1985) 의 후예. 매 Gigaspaces, Hazelcast, Apache Ignite 가 매 commercial 구현. 매 high-volume, low-latency 의 trading, gaming, real-time bidding.
+
+## 매 핵심
+
+### 매 components
+- **Processing Unit (PU)**: 매 stateless application + 매 local in-memory data partition.
+- **Virtualized Middleware**:
+  - *Messaging Grid*: load balancer.
+  - *Data Grid*: 매 distributed in-memory cache (replicated/partitioned).
+  - *Processing Grid*: 매 orchestrate distributed work.
+  - *Deployment Manager*: 매 PU lifecycle.
+- **Data Pumps**: 매 data grid → DB async write-behind.
+- **Data Writers / Readers**: 매 eventual persistence.
+
+### 매 trade-off
+- **장점**: 매 elastic horizontal scale, 매 DB 의 single point of bottleneck X, 매 sub-ms latency.
+- **단점**: 매 eventual consistency, 매 complexity 의 폭발, 매 in-memory cost 의 high, 매 split-brain risk.
+
+### 매 응용
+1. Online ticketing (Ticketmaster).
+2. Real-time bidding (ad exchange).
+3. MMO game state (player position grid).
+
+## 💻 패턴
+
+### Hazelcast IMDG — distributed map (Java 21)
+```java
+HazelcastInstance hz = Hazelcast.newHazelcastInstance();
+IMap<String, Order> orders = hz.getMap("orders");
+orders.put("o-123", new Order("sku-1", 99));
+Order o = orders.get("o-123"); // 매 local or remote partition
+```
+
+### EntryProcessor — 매 data-local computation
+```java
+orders.executeOnKey("o-123", (EntryProcessor<String, Order, Void>) entry -> {
+    var o = entry.getValue();
+    o.markPaid();
+    entry.setValue(o); // 매 in-place mutation, 매 network round-trip 1회
+    return null;
+});
+```
+
+### Write-behind to RDBMS (data pump)
+```java
+MapConfig cfg = new MapConfig("orders")
+    .setMapStoreConfig(new MapStoreConfig()
+        .setClassName("com.acme.OrderMapStore")
+        .setWriteDelaySeconds(5)
+        .setWriteBatchSize(100));
+hz.getConfig().addMapConfig(cfg);
+```
+
+### Apache Ignite — SQL on data grid
+```java
+IgniteCache<Long, Order> cache = ignite.cache("orders");
+SqlFieldsQuery q = new SqlFieldsQuery(
+    "SELECT customerId, SUM(amount) FROM Order GROUP BY customerId");
+cache.query(q).forEach(row -> System.out.println(row));
+```
+
+### Affinity colocation — 매 join-friendly partition
+```java
+@AffinityKeyMapped Long customerId; // 매 same partition 의 customer + orders
+```
+
+### Near cache (read-heavy)
+```java
+NearCacheConfig near = new NearCacheConfig()
+    .setInMemoryFormat(InMemoryFormat.OBJECT)
+    .setTimeToLiveSeconds(30);
+```
+
+### Continuous query (event subscription)
+```java
+orders.addEntryListener((EntryAddedListener<String, Order>) e ->
+    eventBus.publish("order.created", e.getValue()), true);
+```
+
+## 매 결정 기준
+| 상황 | Approach |
+|---|---|
+| Sub-ms read/write @ 100k+ TPS | Space-based (Hazelcast/Ignite) |
+| Strong consistency 필요 | Traditional RDBMS / NewSQL (CockroachDB) |
+| Read-heavy, eventual OK | CDN + cache-aside (Redis) |
+| Stream-first | Kafka + Flink (event-driven) |
+
+**기본값**: 매 default 가 X — SBA 의 specialized. 매 일반 backend → microservices + Postgres + Redis.
+
+## 🔗 Graph
+- 부모: [[Software Architecture]] · [[Distributed Systems]]
+- 변형: [[Microservices]] · [[Event-Driven Architecture]]
+- 응용: [[In-Memory Data Grid]]
+- Adjacent: [[CAP Theorem & PACELC]] · [[Eventual Consistency]] · [[Apache Ignite]]
+
+## 🤖 LLM 활용
+**언제**: extreme write throughput, DB bottleneck, latency budget < 10ms.
+**언제 X**: 매 일반 CRUD, 매 strong consistency 의 필요, 매 small team — 매 complexity 의 cost 의 huge.
+
+## ❌ 안티패턴
+- **SBA for CRUD**: 매 over-engineering. Postgres 의 sufficient.
+- **Sync write-through to DB**: 매 SBA 의 point 의 lost — async write-behind 의 의도.
+- **Single PU instance**: 매 distributed grid 의 X — 매 SPOF.
+- **No backup partitions**: 매 node failure → data loss.
+
+## 🧪 검증 / 중복
+- Verified (Mark Richards, *Software Architecture Patterns* O'Reilly; Hazelcast 5.x docs 2025).
+- 신뢰도 A.
+
+## 🕓 Changelog
+| 날짜 | 변경 |
+|---|---|
+| 2026-05-08 | Phase 1 |
+| 2026-05-10 | Manual cleanup — full SBA spec with Hazelcast/Ignite patterns |