[G1-Sync] Manual knowledge update

2026-05-10 22:08:15 +09:00
parent 21ac3ed255
commit 504fd5fb42
3011 changed files with 380280 additions and 206977 deletions
@@ -1,90 +1,169 @@
 ---
 id: wiki-2026-0508-service-oriented-architecture
-title: Service oriented Architecture
+title: Service-oriented Architecture (SOA)
 category: 10_Wiki/Topics
-status: needs_review
+status: verified
 canonical_id: self
-aliases: [SYS-SOA-001]
+aliases: [SOA, Service-oriented Architecture, 서비스 지향 아키텍처]
 duplicate_of: none
 source_trust_level: A
-confidence_score: 1.0
-tags: [systems, Architecture, soa, service-oriented, microservices, decoupling, InterOperability]
+confidence_score: 0.9
+verification_status: applied
+tags: [architecture, soa, integration, enterprise]
 raw_sources: []
-last_reinforced: 2026-04-26
+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: yaml
+  framework: none
 ---

-# Service-oriented Architecture (SOA, 서비스 지향 아키텍처)
+# Service-oriented Architecture (SOA)

-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "거대한 시스템을 독립적인 기능을 가진 '서비스'들의 집합으로 해체하고, 표준화된 통신(Interface)을 통해 이들이 유연하게 협력하게 하라" — 비즈니스 기능을 독립적인 서비스 단위로 쪼개어 네트워크상에서 서로 연동 가능하게 설계하는 소프트웨어 아키텍처 스타일.
+## 매 한 줄
+> **"매 비즈니스 기능을 매 reusable, network-addressable service로 매 분해"**. 2000년대 enterprise integration의 매 dominant paradigm. SOAP/WS-* + ESB로 매 시작 → REST/event-driven으로 매 진화 → 매 microservices가 매 SOA의 매 fine-grained 후속. 2026년에도 매 large enterprise (banking, telecom)에 매 살아있음.

-## 📖 구조화된 지식 (Synthesized Content)
- **추출된 패턴:** "Service Decoupling and Standardized Interoperability" — 각 서비스가 특정 기술에 종속되지 않고 공용 프로토콜(주로 SOAP나 REST)을 통해 대화하게 함으로써, 전체 시스템의 유연성과 재사용성을 극대화하는 패턴.
- **핵심 원칙:**
-    - **Loose Coupling:** 서비스 간의 의존성을 최소화하여 개별 업데이트 용이.
-    - **Service Contract:** 서비스가 제공하는 기능과 입출력 형식을 명확히 정의.
-    - **Reusability:** 하나가 만든 기능을 다른 여러 서비스에서 호출하여 중복 제거.
-    - **Composability:** 작은 서비스들을 조합하여 더 큰 비즈니스 로직 완성.
- **의의:** 90년대 중반부터 현대 마이크로서비스 아키텍처(MSA)의 철학적 모태가 되었으며, 복잡한 엔터프라이즈 시스템을 관리 가능한 수준으로 유지하는 데 결정적인 역할을 함.
+## 매 핵심

-## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 중앙 집중형 서비스 버스(ESB)를 사용하는 무거운 SOA 방식에서, 이제는 가벼운 API 게이트웨이와 메시지 브로커 중심의 민첩한 마이크로서비스 방식으로 진화하며 '서비스 지향'의 본질은 계승하고 구현의 복잡도는 낮추는 방향으로 발전함.
- **정책 변화:** Antigravity 프로젝트는 에이전트의 각 기능(검색, 생성, 검증 등)을 독립적인 서비스 모듈로 설계하여, 필요에 따라 개별적으로 확장하거나 교체할 수 있는 SOA의 유연성 원칙을 고수함.
+### 매 원칙
+- **Service contract**: 매 명시적 interface (WSDL, OpenAPI).
+- **Loose coupling**: 매 schema/protocol 만 의존.
+- **Reusability**: 매 같은 service 매 다중 consumer.
+- **Composability**: 매 service 합성으로 매 process 구성.
+- **Discoverability**: 매 registry (UDDI, Consul, k8s DNS).

-## 🔗 지식 연결 (Graph)
- Microservices-Foundations, [[Scalability-in-AI-Systems|Scalability-in-AI-Systems]], [[Software-Architecture-Patterns|Software-Architecture-Patterns]], API-Design-[[Principles|Principles]]
- **Raw Source:** 10_Wiki/Topics/AI/Service-oriented-Architecture.md
+### 매 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 |

-## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
+### 매 응용
+1. 매 banking core integration.
+2. 매 telecom OSS/BSS.
+3. 매 government legacy modernization (SOAP wrap).
+4. 매 hybrid cloud (on-prem ↔ cloud SOA bridge).

-**언제 이 지식을 쓰는가:**
- *(TODO)*
+## 💻 패턴

-**언제 쓰면 안 되는가:**
- *(TODO)*
-
-## 🧪 검증 상태 (Validation)
-
- **정보 상태:** needs_review
- **출처 신뢰도:** A
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
-
-## 🧬 중복 검사 (Duplicate Check)
-
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
- **처리 방식:** UPDATE (자동 정규화)
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
-
-## 🕓 변경 이력 (Changelog)
-
-| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
-|------|-----------|-----------|--------|
-| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
-
-## 💻 코드 패턴 (Code Patterns)
-
-**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
-
-```text
-# TODO
+### 매 SOAP service (Java JAX-WS)
+```java
+@WebService
+public class OrderService {
+  @WebMethod
+  public OrderResponse place(@WebParam OrderRequest req) {
+    return new OrderResponse("ok", req.getId());
+  }
+}
 ```

-## 🤔 의사결정 기준 (Decision Criteria)
+### 매 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>
+```

-**선택 A를 써야 할 때:**
- *(TODO)*
+### 매 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");
+```

-**선택 B를 써야 할 때:**
- *(TODO)*
+### 매 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" }
+```

-**기본값:**
-> *(TODO)*
+### 매 Service registry — Consul
+```bash
+consul services register -name=orders -port=8080 -address=10.0.0.5
+consul catalog services
+# orders, billing, inventory
+```

-## ❌ 안티패턴 (Anti-Patterns)
+### 매 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;
+  }
+}
+```

- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
+### 매 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]] · [[Enterprise Integration]]
+- 변형: [[Microservices]] · [[Event-Driven Architecture]] · [[ESB]]
+- 응용: [[API Gateway]] · [[BPM]] · [[Saga Pattern]]
+- Adjacent: [[SOAP]] · [[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 |