Fix: Restore unified Topics folder and reorganize specialized category folders
This commit is contained in:
Antigravity Agent
@@ -1,44 +1,69 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-ARCH-CLEAN-ARCHITECTURE
|
||||
title: "클린 아키텍처 (Clean Architecture)"
|
||||
category: Dev
|
||||
status: verified
|
||||
canonical_id: ""
|
||||
aliases: ["동심원 아키텍처", "Clean Architecture", "의존성 규칙"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: ["Architecture", "Software_Design", "Domain_Driven", "DIP", "Maintainability"]
|
||||
raw_sources: ["Datacollector_Export_2026-05-02"]
|
||||
last_reinforced: 2026-05-02
|
||||
github_commit: ""
|
||||
tags: [Architecture, Design Patterns, SOLID, Uncle Bob]
|
||||
title: Clean Architecture
|
||||
description: 프레임워크 독립성과 도메인 중심 설계를 통해 소프트웨어의 유지보수성과 테스트 용이성을 극대화하는 계층형 아키텍처
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
# [[클린 아키텍처 (Clean Architecture)]]
|
||||
# Clean Architecture
|
||||
|
||||
## 1. 개요
|
||||
클린 아키텍처(Clean Architecture)는 로버트 C. 마틴(Robert C. Martin)이 제안한 소프트웨어 설계 패턴으로, **도메인 중심 설계**와 **프레임워크 독립성**을 핵심 원칙으로 삼는다. 시스템을 동심원 형태의 계층으로 나누고, 의존성의 방향을 항상 안쪽(도메인)으로만 향하게 하여 외부 기술 변화에 강건한 구조를 만든다.
|
||||
## 📌 Brief Summary
|
||||
클린 아키텍처(Clean Architecture)는 로버트 C. 마틴(Robert C. Martin)이 제안한 설계 원칙으로, 시스템의 핵심 비즈니스 로직을 외부 프레임워크, 데이터베이스, UI 등 기술적 세부 사항으로부터 분리하는 것을 목표로 합니다. 시스템을 동심원 형태의 계층으로 나누고, **의존성의 방향이 항상 안쪽(도메인)으로만 향하게 하는 의존성 규칙(Dependency Rule)**을 적용하여, 기술 스택이 변경되더라도 핵심 로직은 영향을 받지 않도록 보호합니다.
|
||||
|
||||
## 2. 동심원 계층 구조
|
||||
- **Entities (엔티티)**: 가장 안쪽 원. 핵심 비즈니스 규칙을 담은 전사적 객체. 외부 변화에 가장 안정적임.
|
||||
- **Use Cases (유스케이스)**: 애플리케이션 특화 비즈니스 규칙. 엔티티를 조정하여 데이터 흐름을 오케스트레이션함.
|
||||
- **Interface Adapters (인터페이스 어댑터)**: 외부와 도메인 사이의 번역기. 컨트롤러, 프리젠터, 리포지토리 등이 포함됨.
|
||||
- **Frameworks & Drivers**: 가장 바깥쪽 원. DB, 웹 프레임워크, UI 등 세부 사항. 언제든 교체 가능한 플러그인처럼 동작해야 함.
|
||||
---
|
||||
|
||||
## 3. 핵심 원칙: 의존성 규칙 (Dependency Rule)
|
||||
- 소스 코드 의존성은 반드시 **안쪽 원(고수준 정책)**으로만 향해야 한다.
|
||||
- 안쪽 원은 바깥쪽 원에 대해 전혀 알지 못해야 하며, 바깥쪽 원의 함수, 클래스, 변수 등을 참조해서는 안 된다.
|
||||
## 📖 Core Content
|
||||
|
||||
## 4. 트레이드오프
|
||||
- **장점**: 프레임워크 독립성, 테스트 용이성, UI/DB 독립성 확보.
|
||||
- **단점**: 단순한 CRUD 애플리케이션에서는 과도한 엔지니어링(Overkill) 및 보일러플레이트 코드 양산 가능성.
|
||||
### 1. 동심원 계층 구조
|
||||
시스템은 추상화 수준에 따라 크게 4가지 계층으로 나뉩니다.
|
||||
|
||||
## 5. 지식 연결 (Related)
|
||||
- [[Hexagonal_Architecture]]: 유사한 철학(포트와 어댑터)을 공유하는 아키텍처.
|
||||
- [[Domain_Driven_Design]]: 엔티티와 Bounded Context를 정의하는 방법론.
|
||||
- [[SOLID_Principles]]: 클린 아키텍처를 지탱하는 5대 설계 원칙.
|
||||
* **Entities (엔티티):** 가장 안쪽 원으로, 핵심 비즈니스 규칙과 데이터를 캡슐화합니다. 특정 애플리케이션의 변경에 영향을 받지 않는 가장 일반적이고 고수준의 규칙입니다.
|
||||
* **Use Cases (유스케이스):** 애플리케이션에 특화된 비즈니스 규칙을 포함합니다. 엔티티 간의 데이터 흐름을 조정하며, 시스템의 동작(동작 시나리오)을 정의합니다.
|
||||
* **Interface Adapters (인터페이스 어댑터):** 외부 형식(DB, 웹)과 유스케이스/엔티티가 이해할 수 있는 내부 형식 사이를 번역합니다. Controller, Presenter, Repository 구현체가 여기에 속합니다.
|
||||
* **Frameworks & Drivers (프레임워크 및 드라이버):** 가장 바깥쪽 계층으로, 데이터베이스, 웹 프레임워크, UI 도구 등 구체적인 기술들이 위치합니다. 이들은 언제든 교환 가능한 '세부 사항'으로 취급됩니다.
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태**: 검증 완료 (Verified)
|
||||
- **출처 신뢰도**: A
|
||||
- **검토 이유**: 소프트웨어 아키텍처의 표준 모델로서의 정확성 확보.
|
||||
### 2. 의존성 규칙 (The Dependency Rule)
|
||||
* **안쪽으로의 의존성:** 소스 코드 의존성은 반드시 안쪽(고수준 정책)으로만 향해야 합니다.
|
||||
* **격리:** 안쪽 원(도메인)은 바깥쪽 원(프레임워크, DB)에 대해 어떤 지식도 가져서는 안 됩니다. 바깥쪽 원에서 선언된 함수, 클래스, 변수 등을 안쪽 원에서 언급해서는 안 됩니다.
|
||||
|
||||
### 3. 실전 적용 사례 (Flutter & NestJS)
|
||||
* **Flutter:** `Presentation` (UI/State), `Domain` (Entity/UseCase), `Data` (Repository impl/DataSource) 계층으로 명확히 분리하여 멀티 플랫폼 대응력을 높입니다.
|
||||
* **NestJS:** 모듈별로 계층을 분리하고, 인터페이스 주입을 통해 서비스 로직이 데이터베이스 라이브러리(TypeORM, Prisma)에 직접 의존하지 않도록 설계합니다.
|
||||
|
||||
---
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
|
||||
### ✅ Benefits
|
||||
* **프레임워크 독립성:** 프레임워크를 도구로 사용하며, 시스템을 프레임워크의 제약 사항에 끼워 맞추지 않습니다.
|
||||
* **테스트 용이성:** UI, DB, 웹 서버 등 외부 요소 없이도 비즈니스 로직을 테스트할 수 있습니다.
|
||||
* **UI/DB 독립성:** 비즈니스 로직 변경 없이 UI를 웹에서 모바일로, DB를 SQL에서 NoSQL로 교체할 수 있습니다.
|
||||
|
||||
### ⚠️ Challenges
|
||||
* **과도한 추상화:** 소규모 프로젝트에서는 단순한 기능을 위해 너무 많은 클래스와 인터페이스를 만들어야 하므로 생산성이 저하될 수 있습니다 (Overkill).
|
||||
* **데이터 변환 비용:** 각 계층을 통과할 때마다 데이터를 변환(Mapping)해야 하므로 런타임 오버헤드와 개발 공수가 증가합니다.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Hexagonal_Architecture]]: 클린 아키텍처와 철학을 공유하며, 포트와 어댑터를 통해 경계를 정의합니다.
|
||||
* [[Domain_Driven_Design]]: 엔티티와 유스케이스를 도출하는 강력한 방법론입니다.
|
||||
* [[SOLID_Principles]]: 특히 의존성 역전 원칙(DIP)이 클린 아키텍처의 핵심 메커니즘입니다.
|
||||
* [[Onion_Architecture]]: 인프라를 외곽으로 밀어내는 유사한 구조의 아키텍처입니다.
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Long-term Maintenance:** 대규모 시스템에서 기술 부채를 관리하고 장기적인 안정성을 확보하기 위한 표준 가이드라인으로 활용됩니다.
|
||||
* **Legacy Migration:** 기존 코드를 새로운 기술 스택으로 이전할 때, 도메인 로직을 클린 아키텍처로 먼저 추출하는 전략이 유효합니다.
|
||||
|
||||
---
|
||||
|
||||
## 💡 Adjacent Topics
|
||||
* [[Test_Driven_Development]]: 외부 의존성이 제거된 클린 아키텍처는 TDD를 수행하기에 가장 이상적인 환경입니다.
|
||||
* [[BLoC_Pattern]]: Flutter에서 프리젠테이션 계층과 도메인 계층을 연결하는 대표적인 상태 관리 방식입니다.
|
||||
* [[Microservices]]: 개별 서비스의 내부 품질을 유지하기 위해 클린 아키텍처를 적용합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -1,49 +1,68 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-ARCH-DDD
|
||||
title: "도메인 주도 설계 (Domain-Driven Design, DDD)"
|
||||
category: Dev
|
||||
status: verified
|
||||
canonical_id: ""
|
||||
aliases: ["DDD", "Domain-Driven Design", "도메인 주도 개발", "전략적 설계"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: ["DDD", "Architecture", "Software_Design", "Business_Logic", "Strategic_Design"]
|
||||
raw_sources: ["Datacollector_Export_2026-05-02"]
|
||||
last_reinforced: 2026-05-02
|
||||
github_commit: ""
|
||||
tags: [Architecture, Design Patterns, DDD, Modeling]
|
||||
title: Domain-Driven Design (DDD)
|
||||
description: 비즈니스 도메인의 복잡성을 해결하기 위해 기술과 비즈니스를 정렬하고 공통 언어를 기반으로 설계하는 방법론
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
# [[도메인 주도 설계 (Domain-Driven Design, DDD)]]
|
||||
# Domain-Driven Design (DDD)
|
||||
|
||||
## 1. 개요
|
||||
Domain-Driven Design(DDD)은 소프트웨어가 실제 비즈니스 로직과 규칙을 정확히 반영하도록 핵심 비즈니스 도메인(판매, 물류, 금융 등)을 모델링하는 데 집중하는 설계 철학이다. 기술적 세부 사항보다는 비즈니스의 복잡성을 해결하는 데 초점을 맞추며, 도메인 전문가와 개발자 간의 긴밀한 협업을 전제로 한다.
|
||||
## 📌 Brief Summary
|
||||
**도메인 주도 설계(Domain-Driven Design, DDD)**는 소프트웨어 개발의 중심을 기술이 아닌 **비즈니스 도메인**에 두는 설계 접근 방식입니다. 에릭 에반스(Eric Evans)에 의해 정립된 이 방법론은 도메인 전문가와 개발자 간의 간극을 줄이기 위해 공통의 언어(**Ubiquitous Language**)를 구축하고, 시스템을 논리적 경계인 **바운디드 컨텍스트(Bounded Context)**로 나누어 관리 가능한 수준의 복잡성을 유지합니다.
|
||||
|
||||
## 2. 주요 개념 및 구성 요소
|
||||
- **전략적 설계 (Strategic Design)**:
|
||||
- **보편적 언어 (Ubiquitous Language)**: 팀 전체가 공유하는 공통의 비즈니스 용어 체계.
|
||||
- **제한된 컨텍스트 (Bounded Context)**: 모델이 적용되는 명확한 경계. 컨텍스트마다 용어의 의미가 다를 수 있음을 인정.
|
||||
- **전술적 설계 (Tactical Design)**:
|
||||
- **엔티티 (Entity)**: 고유한 식별자를 통해 정체성이 유지되는 객체.
|
||||
- **값 객체 (Value Object)**: 속성값 자체로 정의되며 불변성을 가지는 객체.
|
||||
- **애그리게이트 (Aggregate)**: 데이터 변경의 단위로 묶인 객체들의 집합.
|
||||
- **리포지토리 (Repository)**: 애그리게이트의 영속성을 관리하는 인터페이스.
|
||||
---
|
||||
|
||||
## 3. 실전 아키텍처 결합
|
||||
- **육각형 아키텍처와의 조화**: 육각형 아키텍처는 도메인을 보호하는 '구조(Structure)'를 제공하고, DDD는 그 내부의 '내용(Content)'을 채우는 방식으로 결합된다.
|
||||
- **기술적 격리**: 도메인 엔티티는 프레임워크 의존성(예: JPA 어노테이션)이 없는 순수 객체(POJO)로 유지하여 비즈니스 로직의 순수성을 보존한다.
|
||||
## 📖 Core Content
|
||||
|
||||
## 4. 트레이드오프 및 주의사항
|
||||
- **장점**: 비즈니스 요구사항과 코드의 일치, 유지보수성 향상, 복잡한 로직의 체계적 관리.
|
||||
- **단점**: 높은 초기 설계 비용 및 학습 곡선, 단순한 CRUD 시스템에 적용 시 오버엔지니어링 위험.
|
||||
- **테스트 전략**: 도메인 로직 검증 시 과도한 모킹(Mocking)을 지양하고, 실제 동작을 담보하는 가짜 객체나 인메모리 테스트 권장.
|
||||
### 1. 전략적 설계 (Strategic Design)
|
||||
비즈니스 문제를 큰 틀에서 분석하고 시스템의 경계를 정의합니다.
|
||||
* **유비쿼터스 언어 (Ubiquitous Language):** 도메인 전문가, 기획자, 개발자가 프로젝트 전반에서 사용하는 공통 어휘입니다. 이 언어는 문서, 대화뿐만 아니라 코드(클래스명, 메서드명)에도 그대로 반영되어야 합니다.
|
||||
* **바운디드 컨텍스트 (Bounded Context):** 유비쿼터스 언어가 적용되는 논리적인 경계입니다. 동일한 단어(예: '상품')라도 컨텍스트(주문 vs 배송)에 따라 그 의미와 모델이 다를 수 있음을 인정하고 격리합니다.
|
||||
* **컨텍스트 맵 (Context Map):** 서로 다른 바운디드 컨텍스트 간의 관계(협력, 의존 등)를 시각화한 지도입니다.
|
||||
|
||||
## 5. 지식 연결 (Related)
|
||||
- [[Bounded_Context]]: 도메인 모델의 경계를 설정하는 전략적 도구.
|
||||
- [[Ubiquitous_Language]]: 협업과 모델링의 기초가 되는 공통 언어.
|
||||
- [[Hexagonal_Architecture]]: DDD 모델을 외부 기술로부터 격리하는 아키텍처 프레임워크.
|
||||
### 2. 전술적 설계 (Tactical Design)
|
||||
바운디드 컨텍스트 내부의 구체적인 모델링 도구들을 제공합니다.
|
||||
* **엔티티 (Entities):** 식별자(ID)에 의해 정의되는 객체입니다. 속성이 변하더라도 식별자가 같다면 동일한 객체로 간주합니다.
|
||||
* **값 객체 (Value Objects):** 속성값 그 자체로 정의되는 객체입니다. 식별자가 없으며 보통 불변(Immutable) 상태로 관리됩니다.
|
||||
* **애그리거트 (Aggregates):** 데이터 변경의 단위로 취급되는 도메인 객체들의 군집입니다. 각 애그리거트는 '루트(Root)' 엔티티를 통해 외부와 소통하며 데이터 일관성을 보장합니다.
|
||||
* **도메인 서비스 (Domain Services):** 특정 엔티티나 값 객체에 속하기 어려운 비즈니스 로직을 처리하는 무상태(Stateless) 서비스입니다.
|
||||
* **리포지토리 (Repositories):** 애그리거트 루트를 영구 저장소에 저장하고 조회하기 위한 메커니즘을 제공합니다.
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태**: 검증 완료 (Verified)
|
||||
- **출처 신뢰도**: A
|
||||
- **검토 이유**: 비즈니스 가치를 소프트웨어 구조로 전환하기 위한 가장 강력한 설계 패러다임 정립.
|
||||
---
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
|
||||
### ✅ Benefits
|
||||
* **비즈니스 정렬:** 기술적 구현이 실제 비즈니스 요구사항과 정확히 일치하게 됩니다.
|
||||
* **복잡성 관리:** 거대한 시스템을 독립적인 컨텍스트로 나누어 인지적 과부하를 줄입니다.
|
||||
* **유연성:** 각 도메인이 독립적으로 진화할 수 있어 변화에 빠르게 대응할 수 있습니다.
|
||||
|
||||
### ⚠️ Challenges
|
||||
* **높은 초기 비용:** 도메인 전문가와의 긴밀한 협업과 분석 과정에 많은 시간이 소요됩니다.
|
||||
* **설계 난이도:** 바운디드 컨텍스트의 경계를 잘못 설정할 경우, 시스템 간의 결합도가 높아져 더 큰 혼란을 야기할 수 있습니다.
|
||||
* **오버헤드:** 비즈니스 로직이 단순한 CRUD 앱에서는 구조적 복잡성만 높이는 과잉 엔지니어링이 될 수 있습니다.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Bounded_Context]]: DDD의 핵심적인 격리 단위입니다.
|
||||
* [[Ubiquitous_Language]]: 팀 내 소통의 오류를 제거하는 기반 언어입니다.
|
||||
* [[Clean_Architecture]]: 도메인을 중앙에 두고 인프라를 격리하는 구조적 틀을 제공합니다.
|
||||
* [[Event_Storming]]: 비즈니스 흐름을 분석하여 DDD 모델을 도출하는 워크샵 기법입니다.
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Microservices:** 바운디드 컨텍스트는 마이크로서비스를 나누는 가장 이상적인 기준점이 됩니다.
|
||||
* **Enterprise Systems:** 복잡한 비즈니스 규칙이 얽힌 대규모 금융, 이커머스 시스템의 필수 설계 사상입니다.
|
||||
|
||||
---
|
||||
|
||||
## 💡 Adjacent Topics
|
||||
* [[Microservices_Architecture]]: DDD의 전략적 설계를 통해 서비스 간 느슨한 결합을 구현합니다.
|
||||
* [[Layered_Architecture]]: 기술적 계층 분리와 도메인 중심 분리의 차이를 이해하는 비교군입니다.
|
||||
* [[Event_Driven_Architecture]]: 애그리거트 간의 상태 변경을 이벤트를 통해 전파하여 일관성을 유지합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -1,46 +1,69 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-ARCH-EDA
|
||||
title: "이벤트 기반 아키텍처 (Event-Driven Architecture, EDA)"
|
||||
category: Dev
|
||||
status: verified
|
||||
canonical_id: ""
|
||||
aliases: ["EDA", "이벤트 주도 설계", "비동기 메시징", "메시지 기반 아키텍처"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: ["Architecture", "EDA", "Asynchronous", "Message_Broker", "Scalability"]
|
||||
raw_sources: ["Datacollector_Export_2026-05-02"]
|
||||
last_reinforced: 2026-05-02
|
||||
github_commit: ""
|
||||
tags: [Architecture, Messaging, Microservices, Async]
|
||||
title: Event-Driven Architecture (EDA)
|
||||
description: 시스템 컴포넌트 간의 비동기적 이벤트를 통해 느슨한 결합과 높은 확장성을 구현하는 아키텍처 패러다임
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
# [[이벤트 기반 아키텍처 (Event-Driven Architecture, EDA)]]
|
||||
# Event-Driven Architecture (EDA)
|
||||
|
||||
## 1. 개요
|
||||
이벤트 기반 아키텍처(EDA)는 시스템의 상태 변화를 '이벤트(Event)'라는 메시지로 표현하고, 이를 비동기적으로 주고받으며 상호작용하는 아키텍처 스타일이다. 생산자(Producer)와 소비자(Consumer)가 서로의 존재를 직접 알 필요가 없는 느슨한 결합(Loose Coupling)을 통해 고도로 확장 가능하고 탄력적인 시스템을 구축할 수 있다.
|
||||
## 📌 Brief Summary
|
||||
**이벤트 주도 아키텍처(Event-Driven Architecture, EDA)**는 시스템의 상태 변화(Event)를 감지하고, 이를 비동기적으로 전파하여 관련 컴포넌트들이 반응하게 만드는 설계 방식입니다. 서비스 간의 직접적인 호출(Request-Response) 대신 메시지 브로커를 통한 **발행-구독(Publish-Subscribe)** 모델을 사용함으로써, 시스템 간의 결합도를 낮추고 대규모 트래픽 처리에 적합한 탄력성과 확장성을 확보합니다.
|
||||
|
||||
## 2. 핵심 구성 요소
|
||||
- **이벤트 생산자 (Event Producers)**: 상태 변화를 감지하고 이벤트를 생성하여 발행하는 주체.
|
||||
- **이벤트 브로커 (Event Broker)**: 생산자와 소비자 사이에서 이벤트를 수집, 저장, 라우팅하는 중계 인프라 (예: Kafka, RabbitMQ).
|
||||
- **이벤트 소비자 (Event Consumers)**: 브로커를 구독(Subscribe)하고 있다가 특정 이벤트가 발생하면 비즈니스 로직을 실행하는 주체.
|
||||
- **데드 레터 큐 (Dead Letter Queue, DLQ)**: 처리에 실패한 이벤트를 격리하여 분석 및 재처리를 가능하게 하는 보관소.
|
||||
---
|
||||
|
||||
## 3. 실전 적용 가치
|
||||
- **유연한 확장성**: 특정 소비자의 처리 성능이 부족할 경우, 생산자나 다른 소비자에게 영향을 주지 않고 해당 소비자만 수평 확장(Scale-out) 가능.
|
||||
- **실시간 반응성**: 주식 가격 변동, 결제 완료 알림, IoT 센서 데이터 처리 등 즉각적인 반응이 필요한 도메인에 최적화.
|
||||
- **시스템 복원력**: 특정 컴포넌트가 일시적으로 중단되어도 이벤트 브로커에 메시지가 보관되므로 시스템 전체의 데이터 유실 방지.
|
||||
## 📖 Core Content
|
||||
|
||||
## 4. 트레이드오프 및 주의사항
|
||||
- **운영 복잡도**: 분산 시스템 특유의 트랜잭션 관리(Saga 패턴 등), 이벤트 순서 보장, 메시지 유실 방지 등을 위한 고도의 운영 역량 필요.
|
||||
- **멱등성 (Idempotency) 보장**: 네트워크 장애나 재시도로 인해 동일한 이벤트가 여러 번 전달될 수 있으므로, 소비자는 중복 처리에 대한 방어 로직을 반드시 갖춰야 함.
|
||||
- **디버깅 및 추적의 어려움**: 직접적인 호출 스택이 존재하지 않으므로 분산 추적(Distributed Tracing) 도구 없이는 문제 발생 시 원인 파악이 힘듦.
|
||||
### 1. 핵심 메커니즘: 비동기 통신
|
||||
* **이벤트 생산자(Producer):** 상태 변화가 발생하면 이벤트를 생성하여 메시지 브로커에 발행합니다. 누가 이 이벤트를 받을지 알 필요가 없습니다.
|
||||
* **메시지 브로커(Message Broker):** 발행된 이벤트를 저장하고 관심 있는 소비자에게 라우팅합니다. (예: Apache Kafka, RabbitMQ, AWS EventBridge)
|
||||
* **이벤트 소비자(Consumer):** 자신에게 필요한 이벤트를 구독하여 비즈니스 로직을 수행합니다. 생산자의 상태나 위치를 알 필요가 없습니다.
|
||||
|
||||
## 5. 지식 연결 (Related)
|
||||
- [[Microservices_Architecture]]: EDA가 서비스 간 통신을 위해 가장 흔히 채택되는 아키텍처 환경.
|
||||
- [[CQRS_Pattern]]: 상태 변경 후 조회 모델을 업데이트하기 위해 EDA가 핵심 통신 수단으로 사용됨.
|
||||
- [[Event_Storming]]: EDA의 핵심인 도메인 이벤트를 도출하기 위한 설계 기법.
|
||||
### 2. 주요 설계 패턴
|
||||
* **발행-구독 (Pub-Sub):** 일대다 통신으로, 하나의 이벤트가 여러 소비자에게 전달됩니다.
|
||||
* **이벤트 소싱 (Event Sourcing):** 시스템의 현재 상태를 저장하는 대신, 발생한 모든 이벤트를 순서대로 저장하여 상태를 재구성합니다.
|
||||
* **CQRS:** 명령(상태 변경)과 조회(상태 반환)를 분리하고, 비동기 이벤트를 통해 두 모델 간의 동기화를 수행합니다.
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태**: 검증 완료 (Verified)
|
||||
- **출처 신뢰도**: A
|
||||
- **검토 이유**: 비동기 워크플로우와 고가용성 시스템 구축을 위한 현대적 분산 아키텍처의 핵심 패러다임 정립.
|
||||
### 3. 실전 고려 사항
|
||||
* **멱등성 (Idempotency):** 동일한 이벤트가 중복 전달되더라도 결과가 같아야 합니다.
|
||||
* **순서 보장 (Ordering):** 이벤트가 발생한 순서대로 처리되어야 하는 경우, 브로커의 파티셔닝 전략이 중요합니다.
|
||||
* **최종 일관성 (Eventual Consistency):** 분산 시스템 특성상 데이터가 즉시 일치하지 않을 수 있음을 전제로 설계합니다.
|
||||
|
||||
---
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
|
||||
### ✅ Benefits
|
||||
* **느슨한 결합 (Loose Coupling):** 서비스 간 의존성이 제거되어 독립적인 배포와 확장이 가능합니다.
|
||||
* **높은 확장성:** 소비자(Worker)를 늘려 처리량을 쉽게 조절할 수 있습니다.
|
||||
* **내결함성:** 특정 소비자가 다운되더라도 브로커가 메시지를 보관하므로 데이터 유실을 방지할 수 있습니다.
|
||||
|
||||
### ⚠️ Challenges
|
||||
* **디버깅 및 추적:** 분산된 비동기 흐름으로 인해 장애 발생 시 전체 실행 경로를 추적하기 어렵습니다.
|
||||
* **운영 복잡성:** 메시지 브로커 인프라 관리에 추가 비용과 전문 지식이 필요합니다.
|
||||
* **데이터 정합성:** 분산 트랜잭션 구현이 까다로우며, 최종 일관성 모델에 대한 이해가 필수적입니다.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Microservices_Architecture]]: 마이크로서비스 간의 통신을 최적화하는 핵심 패턴입니다.
|
||||
* [[Message_Broker]]: EDA를 가능하게 하는 인프라스트럭처 도구입니다.
|
||||
* [[Saga_Pattern]]: 분산 시스템에서 여러 서비스에 걸친 트랜잭션을 이벤트로 관리하는 방식입니다.
|
||||
* [[Dead_Letter_Queue]]: 처리 실패한 이벤트를 격리하여 관리하는 메커니즘입니다.
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Real-time Processing:** 주식 거래, IoT 센서 데이터 등 즉각적인 반응이 필요한 시스템에 활용됩니다.
|
||||
* **Complex Workflows:** 전자상거래 주문-결제-배송으로 이어지는 긴 프로세스를 비동기로 처리합니다.
|
||||
|
||||
---
|
||||
|
||||
## 💡 Adjacent Topics
|
||||
* [[Domain_Driven_Design]]: 도메인 이벤트를 식별하여 EDA 설계의 기반으로 삼습니다.
|
||||
* [[Cloud_Native_Architecture]]: 클라우드 환경에서 서버리스(Lambda)와 결합하여 효율적인 확장을 구현합니다.
|
||||
* [[CQRS]]: 상태 변경과 조회를 분리하는 아키텍처와 시너지를 냅니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -1,49 +1,70 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-ARCH-HEXAGONAL
|
||||
title: "헥사고날 아키텍처 (Hexagonal Architecture / Ports and Adapters)"
|
||||
category: Dev
|
||||
status: verified
|
||||
canonical_id: ""
|
||||
aliases: ["헥사고날 아키텍처", "포트와 어댑터", "Hexagonal Architecture", "Ports and Adapters"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: ["Architecture", "Hexagonal", "DIP", "Modularity", "Decoupling"]
|
||||
raw_sources: ["Datacollector_Export_2026-05-02"]
|
||||
last_reinforced: 2026-05-02
|
||||
github_commit: ""
|
||||
tags: [Architecture, Design Patterns, DDD, SOLID]
|
||||
title: Hexagonal Architecture (Ports and Adapters)
|
||||
description: 도메인 로직을 외부 인프라스트럭처로부터 격리하여 시스템의 유연성과 테스트 용이성을 극대화하는 아키텍처 설계 패턴
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
# [[헥사고날 아키텍처 (Hexagonal Architecture / Ports and Adapters)]]
|
||||
# Hexagonal Architecture
|
||||
|
||||
## 1. 개요
|
||||
헥사고날 아키텍처(Hexagonal Architecture)는 애플리케이션의 핵심 비즈니스 로직을 외부 기술(DB, UI, 프레임워크 등)로부터 분리하고 격리하여 유지보수성과 테스트 용이성을 극대화하는 설계 패턴이다. 모든 외부 요소는 인터페이스인 '포트(Port)'를 통해 시스템에 연결되며, 구체적인 기술적 세부 사항은 '어댑터(Adapter)'가 담당하는 구조적 특징을 가진다.
|
||||
## 📌 Brief Summary
|
||||
헥사고날 아키텍처(Hexagonal Architecture), 또는 **포트와 어댑터(Ports and Adapters)** 패턴은 소프트웨어의 핵심인 비즈니스 로직(도메인)을 데이터베이스, UI, 프레임워크와 같은 외부 요소로부터 완전히 격리하는 설계 방식입니다. 시스템을 내부(Inside/Domain)와 외부(Outside/Infrastructure)로 명확히 분리하며, 모든 상호작용은 정의된 인터페이스인 **포트(Port)**와 이를 구현하는 **어댑터(Adapter)**를 통해서만 이루어집니다. 이를 통해 기술 스택의 변경이 비즈니스 로직에 미치는 영향을 최소화하고, 독립적인 테스트가 가능한 견고한 시스템을 구축합니다.
|
||||
|
||||
## 2. 핵심 구성 요소
|
||||
- **도메인 (Inside)**: 시스템의 본질인 비즈니스 로직과 규칙. 외부 프레임워크나 인프라 기술에 전혀 의존하지 않는 순수한 코드로 구성된다.
|
||||
- **포트 (Ports)**: 외부 세계가 도메인과 소통하기 위한 명세(인터페이스).
|
||||
- **입력 포트 (Inbound)**: 외부 요청(API 호출, CLI 등)이 도메인 기능을 사용하기 위한 통로.
|
||||
- **출력 포트 (Outbound)**: 도메인이 외부 자원(DB, 메시지 큐 등)에 접근하기 위해 사용하는 통로.
|
||||
- **어댑터 (Outside)**: 포트 인터페이스를 구체적으로 구현하거나 호출하는 인프라 계층.
|
||||
- **입력 어댑터 (Driving)**: 컨트롤러, CLI 핸들러 등 요청을 도메인 명령으로 변환.
|
||||
- **출력 어댑터 (Driven)**: 영속성(Persistence) 구현체, 메시지 송신부 등 기술적 행위 수행.
|
||||
---
|
||||
|
||||
## 3. 실전 적용 가치
|
||||
- **기술 스택 교체 용이성**: 비즈니스 로직을 전혀 수정하지 않고도 DB를 교체하거나 API 스펙을 변경하는 등 유연한 운영 가능.
|
||||
- **테스트 격리**: 인프라 환경 없이도 도메인 로직만 고립시켜 단위 테스트를 수행할 수 있어 검증 속도와 신뢰성 향상.
|
||||
- **의존성 역전 (DIP)**: 도메인이 인프라에 의존하는 것이 아니라, 인프라(어댑터)가 도메인의 명세(포트)에 맞게 구현되도록 강제하여 코드의 순수성 보존.
|
||||
## 📖 Core Content
|
||||
|
||||
## 4. 트레이드오프 및 주의사항
|
||||
- **구현 복잡도**: 포트와 어댑터 계층을 나누고 다수의 인터페이스와 매퍼(Mapper)를 작성해야 하므로 초기 개발 리소스와 보일러플레이트 코드가 증가함.
|
||||
- **과잉 설계 (Over-engineering)**: 도메인 로직이 단순한 CRUD 수준일 경우, 헥사고날 아키텍처의 도입은 시스템을 불필요하게 복잡하게 만들 수 있음.
|
||||
- **학습 곡선**: 전통적인 계층형 아키텍처에 익숙한 개발팀에게는 패러다임 전환을 위한 교육 비용이 발생함.
|
||||
### 1. 핵심 원리: 의존성 역전 (DIP)
|
||||
전통적인 계층형 아키텍처(Layered Architecture)는 상위 계층이 하위 계층(특히 DB나 외부 라이브러리)에 직접 의존하여 기술적 변경에 취약했습니다. 헥사고날 아키텍처는 **의존성 역전 원칙(Dependency Inversion Principle)**을 극한으로 활용하여, 도메인과 인프라 모두가 추상화된 인터페이스(포트)에 의존하게 만듭니다.
|
||||
|
||||
## 5. 지식 연결 (Related)
|
||||
- [[Domain_Driven_Design]]: 헥사고날 아키텍처 내부(도메인)를 채우는 모델링 기법.
|
||||
- [[Clean_Architecture]]: 유사한 격리 철학을 동심원 모델로 표현한 아키텍처.
|
||||
- [[CQRS_Pattern]]: 조회와 명령의 효율성을 위해 헥사고날과 흔히 결합되는 패턴.
|
||||
### 2. 주요 구성 요소
|
||||
* **도메인 (Inside):** 애플리케이션의 핵심 비즈니스 로직과 규칙을 포함하는 순수 코드 영역입니다. 외부 프레임워크나 데이터베이스 기술에 대한 지식이 전혀 없는 상태로 유지됩니다.
|
||||
* **포트 (Ports):** 내부와 외부를 연결하는 명세(Interface)입니다.
|
||||
* **입력 포트 (Inbound/Driving Ports):** 외부(UI, API 호출 등)에서 도메인 기능을 호출할 때 사용하는 인터페이스입니다.
|
||||
* **출력 포트 (Outbound/Driven Ports):** 도메인이 외부 자원(DB, 메시지 큐, 외부 API)에 접근해야 할 때 사용하는 인터페이스입니다.
|
||||
* **어댑터 (Outside):** 포트를 구체적으로 구현하거나 호출하는 인프라 계층입니다.
|
||||
* **입력 어댑터:** REST Controller, CLI, WebSockets 등 외부 요청을 도메인이 이해할 수 있는 형식으로 변환하여 입력 포트를 호출합니다.
|
||||
* **출력 어댑터:** 도메인의 요청을 받아 실제 DB(JPA, MongoDB), 외부 메일 서버, 알림 서비스 등으로 전달하는 구체적인 기술 구현체입니다.
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태**: 검증 완료 (Verified)
|
||||
- **출처 신뢰도**: A
|
||||
- **검토 이유**: 기술 종속성에서 벗어나 비즈니스 로직의 수명을 극대화하기 위한 현대적 아키텍처의 표준 명세 정립.
|
||||
### 3. 실전 설계 전략 (Framework Specific)
|
||||
* **Spring Boot (Java):** 도메인 모델을 `@Entity` 등 프레임워크 어노테이션에서 분리하여 POJO로 구성합니다. `@Configuration`을 사용하여 어댑터 구현체를 런타임에 도메인 서비스에 주입합니다.
|
||||
* **NestJS (TypeScript):** 모듈 시스템과 DI를 활용합니다. `Domain`, `Application`, `Infrastructure`, `Presentation` 계층을 폴더 구조로 명확히 나누고, 인터페이스 기반 프로그래밍을 강제합니다.
|
||||
|
||||
---
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
|
||||
### ✅ Benefits
|
||||
* **높은 테스트 용이성:** 외부 DB나 API 없이도 모킹(Mocking)을 통해 도메인 로직만 완벽하게 테스트할 수 있습니다.
|
||||
* **기술 독립성:** 데이터베이스나 메시징 시스템을 교체할 때 도메인 코드를 수정할 필요가 없습니다.
|
||||
* **유지보수성:** 비즈니스 규칙이 한곳에 집중되어 있어 코드 파악과 변경이 용이합니다.
|
||||
|
||||
### ⚠️ Challenges
|
||||
* **초기 복잡성:** 단순한 CRUD 앱의 경우, 수많은 인터페이스와 매핑 객체(DTO/Mapper)가 오버헤드로 작용할 수 있습니다.
|
||||
* **보일러플레이트:** 계층 간 데이터 변환을 위한 코드가 늘어납니다.
|
||||
* **학습 곡선:** 전통적인 계층 구조에 익숙한 팀에게는 패러다임 전환을 위한 비용이 발생합니다.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Dependency_Inversion_Principle]]: 헥사고날 아키텍처의 기술적 토대가 되는 원칙입니다.
|
||||
* [[Clean_Architecture]]: 비즈니스 로직을 중심에 두는 유사한 철학의 아키텍처 패턴입니다.
|
||||
* [[Domain_Driven_Design]]: 헥사고날 아키텍처 내부(도메인)를 채우는 모델링 방법론을 제공합니다.
|
||||
* [[Dependency_Injection]]: 포트와 어댑터를 런타임에 결합하는 실무 도구입니다.
|
||||
|
||||
### Practical Application Contexts
|
||||
* **System Design:** UI나 DB를 먼저 설계하지 않고, 비즈니스 유스케이스와 포트를 먼저 정의하는 '도메인 중심' 접근을 권장합니다.
|
||||
* **Maintenance:** 레거시 시스템을 점진적으로 개선할 때, 외부 통신부를 어댑터로 격리하여 안전하게 로직을 추출할 수 있습니다.
|
||||
|
||||
---
|
||||
|
||||
## 💡 Adjacent Topics
|
||||
* [[Test_Driven_Development]]: 헥사고날의 격리성을 활용하여 테스트 중심 개발을 가속화합니다.
|
||||
* [[CQRS]]: 대규모 시스템에서 명령(Write)과 조회(Read) 포트를 분리하여 성능을 극대화하는 전략과 궁합이 좋습니다.
|
||||
* [[Microservices]]: 각 마이크로서비스 내부 아키텍처로 헥사고날을 적용하여 서비스 간 독립성을 확보합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -1,46 +1,69 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-ARCH-MICROSERVICES
|
||||
title: "마이크로서비스 아키텍처 (Microservices Architecture, MSA)"
|
||||
category: Dev
|
||||
status: verified
|
||||
canonical_id: ""
|
||||
aliases: ["MSA", "마이크로서비스", "Microservices", "분산 시스템"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: ["Architecture", "MSA", "Cloud_Native", "Scalability", "Agility"]
|
||||
raw_sources: ["Datacollector_Export_2026-05-02"]
|
||||
last_reinforced: 2026-05-02
|
||||
github_commit: ""
|
||||
tags: [Architecture, Microservices, Cloud Native, Scalability]
|
||||
title: Microservices Architecture (MSA)
|
||||
description: 대규모 애플리케이션을 독립적으로 배포 및 확장 가능한 작은 서비스 단위로 분할하여 관리하는 시스템 설계 방식
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
# [[마이크로서비스 아키텍처 (Microservices Architecture, MSA)]]
|
||||
# Microservices Architecture (MSA)
|
||||
|
||||
## 1. 개요
|
||||
마이크로서비스 아키텍처(MSA)는 거대한 단일 애플리케이션(Monolith)을 독립적으로 배포 및 확장 가능한 작은 서비스 단위들로 분할하여 구축하는 시스템 설계 방식이다. 각 서비스는 특정 비즈니스 기능(Bounded Context)에 집중하며, 가벼운 통신 프로토콜(HTTP/REST, gRPC, 메시지 큐 등)을 통해 상호작용한다.
|
||||
## 📌 Brief Summary
|
||||
**마이크로서비스 아키텍처(Microservices Architecture, MSA)**는 하나의 거대한 애플리케이션(Monolith)을 비즈니스 기능 단위로 쪼개어, 독립적으로 개발, 배포, 운영이 가능한 **작은 서비스들의 집합**으로 구성하는 방식입니다. 각 서비스는 자신만의 데이터베이스를 가질 수 있으며, API를 통해 서로 통신합니다. 이는 클라우드 네이티브 환경에서 대규모 시스템의 복잡성을 관리하고, 변화에 민첩하게 대응하기 위한 현대 소프트웨어 공학의 핵심 패러다임입니다.
|
||||
|
||||
## 2. 핵심 특징
|
||||
- **독립적 배포 및 확장**: 전체 시스템을 중단하지 않고 특정 서비스만 개별적으로 업데이트하거나, 트래픽에 맞춰 특정 모듈만 수평 확장(Scale-out) 가능.
|
||||
- **기술 자율성 (Polyglot)**: 각 마이크로서비스의 특성에 따라 서로 다른 프로그래밍 언어, 데이터베이스, 프레임워크를 선택할 수 있는 유연성 제공.
|
||||
- **격리된 실패 (Fault Isolation)**: 특정 서비스에 장애가 발생하더라도 서킷 브레이커 등을 통해 전체 시스템으로의 장애 전파를 차단하여 가용성 유지.
|
||||
- **조직 정렬 (Conway's Law)**: 비즈니스 도메인 단위로 팀을 구성하고, 팀별로 독립적인 서비스 소유권을 부여하여 개발 민첩성 극대화.
|
||||
---
|
||||
|
||||
## 3. 실전 아키텍처 결합
|
||||
- **클라우드 네이티브와 서버리스**: AWS Lambda, Kubernetes 등 클라우드 인프라를 활용하여 마이크로서비스의 배포와 운영 자동화.
|
||||
- **헥사고날 아키텍처의 확장**: 각 마이크로서비스 내부를 헥사고날 아키텍처로 설계하여 비즈니스 로직의 순수성을 지키고 외부 기술과의 결합도 최소화.
|
||||
- **API 게이트웨이**: 수많은 마이크로서비스의 엔드포인트를 단일 창구로 통합하고 인증, 로깅, 라우팅을 중앙 집중적으로 관리.
|
||||
## 📖 Core Content
|
||||
|
||||
## 4. 트레이드오프 및 주의사항
|
||||
- **분산 시스템의 복잡성**: 네트워크 지연, 분산 트랜잭션 처리(Saga 패턴 등), 데이터 일관성 유지(Eventual Consistency) 등 고난도의 기술적 과제 수반.
|
||||
- **운영 오버헤드**: 서비스 수가 늘어남에 따라 모니터링, 로깅, 배포 파이프라인 관리의 난이도가 급격히 상승함.
|
||||
- **분산 모놀리스 (Anti-pattern)**: 서비스 간의 의존성이 너무 강해 결국 함께 배포해야 하는 상황이 발생하지 않도록 바운디드 컨텍스트 설계를 정교하게 해야 함.
|
||||
### 1. 주요 특징
|
||||
* **독립성:** 각 서비스는 독립적으로 빌드, 테스트, 배포될 수 있습니다. 특정 서비스의 업데이트가 전체 시스템 중단으로 이어지지 않습니다.
|
||||
* **기술 다양성 (Polyglot):** 각 서비스의 특성에 맞는 최적의 언어와 데이터베이스를 선택할 수 있습니다. (예: 결제 서비스는 Java, 실시간 분석은 Python)
|
||||
* **탄력적 확장:** 트래픽이 몰리는 특정 서비스만 골라서 리소스를 확장(Scale-out)할 수 있어 비용 효율적입니다.
|
||||
* **책임의 분리:** 도메인 주도 설계(DDD)의 **바운디드 컨텍스트(Bounded Context)**를 기준으로 팀과 코드를 분리하여 전문성을 높입니다.
|
||||
|
||||
## 5. 지식 연결 (Related)
|
||||
- [[Hexagonal_Architecture]]: 마이크로서비스 내부를 설계하는 기반 패턴.
|
||||
- [[Event_Driven_Architecture]]: 서비스 간 느슨한 결합을 구현하기 위한 핵심 통신 방식.
|
||||
- [[Bounded_Context]]: 마이크로서비스를 나누는 논리적/비즈니스적 기준.
|
||||
### 2. 아키텍처 구성 요소
|
||||
* **API Gateway:** 클라이언트의 요청을 받아 적절한 마이크로서비스로 라우팅하고, 인증/인가, 속도 제한 등을 통합 관리합니다.
|
||||
* **Service Discovery:** 동적으로 변하는 마이크로서비스 인스턴스의 위치(IP, Port)를 자동으로 등록하고 찾아주는 기능을 합니다.
|
||||
* **Config Server:** 서비스별 설정 정보를 중앙에서 관리하여 동적으로 반영합니다.
|
||||
* **Message Broker:** 서비스 간 비동기 통신을 담당하여 결합도를 낮춥니다. (Kafka, RabbitMQ 등)
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태**: 검증 완료 (Verified)
|
||||
- **출처 신뢰도**: A
|
||||
- **검토 이유**: 대규모 트래픽과 복잡한 비즈니스 요구사항을 탄력적으로 수용하기 위한 현대적 아키텍처의 표준 명세 정립.
|
||||
### 3. 구현 철학: 헥사고날 아키텍처와의 관계
|
||||
각 마이크로서비스 내부는 **헥사고날 아키텍처**를 적용하는 것이 일반적입니다. 비즈니스 로직을 중심에 두고 외부 통신(API, DB)을 어댑터로 처리함으로써, 서비스 자체가 하나의 독립적인 '섬'처럼 동작하게 설계합니다.
|
||||
|
||||
---
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
|
||||
### ✅ Benefits
|
||||
* **민첩성:** 작은 단위의 배포가 가능하여 새로운 기능을 시장에 빠르게 출시할 수 있습니다.
|
||||
* **안정성:** 서비스 하나에 장애가 발생해도 전체 시스템으로 전파될 확률이 낮습니다 (Fault Isolation).
|
||||
* **조직의 확장:** 큰 팀을 작은 서비스 단위의 팀으로 나누어 커뮤니케이션 비용을 줄일 수 있습니다.
|
||||
|
||||
### ⚠️ Challenges
|
||||
* **분산 시스템의 복잡성:** 네트워크 지연, 데이터 정합성(최종 일관성), 분산 트랜잭션 처리 등 해결해야 할 기술적 난제가 많습니다.
|
||||
* **운영 오버헤드:** 관리해야 할 서비스, 컨테이너, 네트워크 설정이 기하급수적으로 늘어납니다.
|
||||
* **테스트의 어려움:** 여러 서비스가 얽힌 통합 테스트와 엔드 투 엔드(E2E) 테스트가 까다롭습니다.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Hexagonal_Architecture]]: 개별 마이크로서비스 내부의 견고한 설계 틀을 제공합니다.
|
||||
* [[Domain_Driven_Design]]: 마이크로서비스의 경계를 나누는 논리적 기준(Bounded Context)을 제공합니다.
|
||||
* [[Serverless_Computing]]: 인프라 관리 없이 마이크로서비스 기능을 실행할 수 있는 이상적인 배포 환경입니다.
|
||||
* [[Event_Driven_Architecture]]: 서비스 간 느슨하게 결합된 통신을 구현하는 핵심 패턴입니다.
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Cloud Native:** 컨테이너(Docker)와 오케스트레이션(Kubernetes) 도구를 필수로 사용합니다.
|
||||
* **JAMstack:** 프론트엔드에서 호출하는 다양한 백엔드 API 서비스들의 집합으로 MSA가 활용됩니다.
|
||||
|
||||
---
|
||||
|
||||
## 💡 Adjacent Topics
|
||||
* [[CI_CD]]: MSA 환경에서 수많은 서비스를 안전하게 배포하기 위한 필수 자동화 프로세스입니다.
|
||||
* [[Distributed_Tracing]]: 분산된 서비스 간의 요청 흐름을 추적하기 위한 기술(Zipkin, Jaeger 등)입니다.
|
||||
* [[API_First_Architecture]]: 서비스 간 협업을 위해 API 설계를 최우선으로 하는 개발 문화입니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
Reference in New Issue
Block a user