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>
This commit is contained in:
Antigravity Agent
2026-07-11 11:05:56 +09:00
parent 6549ead309
commit c24165b8bc
6193 changed files with 1717 additions and 31 deletions
@@ -0,0 +1,169 @@
---
id: wiki-2026-0508-service-oriented-architecture
title: Service-oriented Architecture (SOA)
category: 10_Wiki/Topics
status: verified
canonical_id: self
aliases: [SOA, Service-oriented Architecture, 서비스 지향 아키텍처]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
verification_status: applied
tags: [architecture, soa, integration, enterprise]
raw_sources: []
last_reinforced: 2026-05-10
github_commit: pending
tech_stack:
language: yaml
framework: none
---
# Service-oriented Architecture (SOA)
## 매 한 줄
> **"매 비즈니스 기능을 매 reusable, network-addressable service로 매 분해"**. 2000년대 enterprise integration의 매 dominant paradigm. SOAP/WS-* + ESB로 매 시작 → REST/event-driven으로 매 진화 → 매 microservices가 매 SOA의 매 fine-grained 후속. 2026년에도 매 large enterprise (banking, telecom)에 매 살아있음.
## 매 핵심
### 매 원칙
- **Service contract**: 매 명시적 interface (WSDL, OpenAPI).
- **Loose coupling**: 매 schema/protocol 만 의존.
- **Reusability**: 매 같은 service 매 다중 consumer.
- **Composability**: 매 service 합성으로 매 process 구성.
- **Discoverability**: 매 registry (UDDI, Consul, k8s DNS).
### 매 vs Microservices
| 측면 | SOA (classic) | Microservices |
|---|---|---|
| 크기 | 매 coarse-grained (business domain) | 매 fine-grained |
| Comm | ESB + SOAP | HTTP/gRPC/Event |
| Data | 매 shared DB 가능 | DB-per-service |
| Governance | 매 central | 매 decentralized |
### 매 응용
1. 매 banking core integration.
2. 매 telecom OSS/BSS.
3. 매 government legacy modernization (SOAP wrap).
4. 매 hybrid cloud (on-prem ↔ cloud SOA bridge).
## 💻 패턴
### 매 SOAP service (Java JAX-WS)
```java
@WebService
public class OrderService {
@WebMethod
public OrderResponse place(@WebParam OrderRequest req) {
return new OrderResponse("ok", req.getId());
}
}
```
### 매 WSDL contract (요약)
```xml
<wsdl:definitions targetNamespace="http://orders.example.com">
<wsdl:portType name="OrderService">
<wsdl:operation name="place">
<wsdl:input message="tns:placeRequest"/>
<wsdl:output message="tns:placeResponse"/>
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>
```
### 매 ESB routing (Camel)
```java
from("activemq:queue:orders.in")
.choice()
.when(xpath("/order/total > 1000"))
.to("activemq:queue:orders.high-value")
.otherwise()
.to("activemq:queue:orders.standard");
```
### 매 Modern REST SOA (OpenAPI)
```yaml
openapi: 3.1.0
info: { title: Orders, version: 2.0 }
paths:
/orders:
post:
requestBody:
content:
application/json:
schema: { $ref: "#/components/schemas/OrderRequest" }
responses:
"201":
content:
application/json:
schema: { $ref: "#/components/schemas/Order" }
```
### 매 Service registry — Consul
```bash
consul services register -name=orders -port=8080 -address=10.0.0.5
consul catalog services
# orders, billing, inventory
```
### 매 Saga (long-running process composition)
```typescript
// 매 SOA business process orchestration
async function placeOrderSaga(order: Order) {
await orderService.create(order);
try {
await paymentService.charge(order);
await inventoryService.reserve(order);
await shippingService.schedule(order);
} catch (e) {
await orderService.cancel(order.id); // 매 compensation
throw e;
}
}
```
### 매 BPMN/Camunda (process layer)
```xml
<bpmn:process id="OrderFulfillment">
<bpmn:serviceTask id="charge" camunda:topic="payment-charge" />
<bpmn:serviceTask id="reserve" camunda:topic="inventory-reserve" />
<bpmn:serviceTask id="ship" camunda:topic="shipping-schedule" />
</bpmn:process>
```
## 매 결정 기준
| 상황 | Approach |
|---|---|
| 매 enterprise legacy 통합 | SOA + ESB 매 정당. |
| 매 cloud-native greenfield | Microservices 우선. |
| 매 strict contract + governance | SOA + WSDL/OpenAPI. |
| 매 high autonomy | Microservices + event-driven. |
| 매 long-running biz process | SOA + BPM (Camunda). |
**기본값**: 매 greenfield → microservices. 매 legacy integration → SOA.
## 🔗 Graph
- 부모: [[Distributed Systems]]
- 변형: [[Microservices]] · [[Event-Driven Architecture]] · [[ESB]]
- 응용: [[API Gateway]] · [[BPM]]
- Adjacent: [[REST]] · [[Service Mesh]] · [[Bounded_Context]]
## 🤖 LLM 활용
**언제**: 매 enterprise 통합, 매 legacy modernization 설계, 매 BPM process 디자인.
**언제 X**: 매 small startup, 매 single-team product.
## ❌ 안티패턴
- **매 ESB 매 god-object**: 매 모든 logic을 ESB로 → 매 maintenance hell.
- **매 service 가 매 DB 직접 공유**: 매 loose coupling 깨짐.
- **매 WSDL 매 micro-version 폭발**: 매 versioning 전략 부재.
- **매 SOA를 매 microservices로 매 단순 rebrand**: 매 fine-grain 차이 무시.
## 🧪 검증 / 중복
- Verified (Erl, *SOA Principles of Service Design*; Newman, *Building Microservices*).
- 신뢰도 A.
## 🕓 Changelog
| 날짜 | 변경 |
|---|---|
| 2026-05-08 | Phase 1 |
| 2026-05-10 | Manual cleanup — SOA classic + modern REST/SOA + microservices comparison |