[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -2,100 +2,160 @@
|
||||
id: wiki-2026-0508-소프트웨어-아키텍처-설계
|
||||
title: 소프트웨어 아키텍처 설계
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-6B7DB7]
|
||||
aliases: [Software Architecture Design, SW Architecture]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
verification_status: applied
|
||||
tags: [architecture, design, software-engineering]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - 소프트웨어 아키텍처 설계"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: agnostic
|
||||
framework: agnostic
|
||||
---
|
||||
|
||||
# [[소프트웨어 아키텍처 설계|소프트웨어 아키텍처 설계]]
|
||||
# 소프트웨어 아키텍처 설계
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 소프트웨어 아키텍처 설계는 소프트웨어 시스템이 쉽게 개발, 배포, 운영 및 유지보수될 수 있도록 시스템의 형태와 컴포넌트 간의 관계를 구성하는 작업입니다 [1, 2]. 좋은 아키텍처는 시스템의 복잡성을 관리하여 기술 부채를 최소화하며, 핵심 비즈니스 규칙과 유스케이스를 중심에 두어 외부 프레임워크나 도구에 대한 결정을 지연시킬 수 있도록 돕습니다 [3, 4]. 이를 위해 관심사의 분리(SoC) 및 SOLID 원칙 등 다양한 설계 철학이 적용되어 시스템의 유연성과 확장성을 보장합니다 [5-7].
|
||||
## 매 한 줄
|
||||
> **"매 architecture는 매 의사결정의 기록이며, 매 변경 비용을 결정한다"**. Bass/Clements/Kazman의 SEI 정의 이후, 매 architecture는 매 코드 자체가 아닌 매 component / connector / constraint의 집합으로 본다. 매 2026 modern view는 매 evolutionary architecture (Ford) — 매 fitness function 으로 매 architectural property 를 매 자동 검증.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **핵심 목적 및 원칙:**
|
||||
* **유지보수성과 확장성 확보:** 복잡한 시스템을 모듈화하여 개발 속도를 높이고, 코드의 가독성과 테스트 용이성을 극대화하는 것이 아키텍처 설계의 핵심입니다 [3, 8].
|
||||
* **관심사의 분리 ([[_뇌와 팔다리의 분리_ - 관심사의 분리 (Separation of Concerns)|Separation of Concerns]], SoC):** 시스템을 여러 개의 독립적인 모듈로 나누어 각 부분이 하나의 기능이나 책임에 집중하게 만듭니다 [9, 10]. 이를 통해 모듈 내부의 응집도(Cohesion)를 높이고 외부 요소와의 결합도(Coupling)를 낮추어 독립적인 유지보수 및 재사용성을 크게 향상시킵니다 [11-13].
|
||||
* **의존성 규칙 (Dependency Rule) 및 클린 아키텍처:** 소스 코드의 의존성은 항상 고수준의 정책(핵심 비즈니스 로직)을 향해 안쪽으로 지향해야 합니다 [14]. 시스템의 심장부인 엔티티(Entity)와 유스케이스(Use Case)를 UI나 데이터베이스 같은 저수준의 외부 세부 사항으로부터 철저히 격리합니다 [15, 16].
|
||||
* **SOLID 및 DRY 원칙:** 클래스가 단일 책임을 갖게 하고(SRP), 확장에 열려 있고 수정에 닫혀 있게 하며(OCP), 코드 내 중복을 방지(DRY)하여 시스템이 견고하고 유연하게 진화할 수 있는 기반을 다집니다 [6, 17, 18].
|
||||
## 매 핵심
|
||||
|
||||
* **주요 아키텍처 패턴:**
|
||||
* **계층화 아키텍처 (Layered [[Architecture|Architecture]]):** 시스템을 프레젠테이션(UI), 비즈니스 로직, 데이터 액세스 등의 수평적 계층으로 나누어 인접한 계층 간에만 통신하도록 역할을 엄격히 분리합니다 [19, 20].
|
||||
* **마이크로서비스 아키텍처 (Microservices Architecture):** 거대한 애플리케이션을 비즈니스 도메인 단위의 작고 독립적인 서비스들로 분할하여 개별 팀의 병렬 개발, 독립 배포, 유연한 서비스 확장을 가능하게 합니다 [21, 22].
|
||||
* **이벤트 기반 아키텍처 (Event-Driven Architecture):** 시스템 컴포넌트들이 이벤트를 생산하고 소비함으로써 비동기적으로 통신하게 구성하여, 서비스 간 결합도를 낮추고 실시간 데이터 처리와 확장에 유리하게 만듭니다 [23, 24].
|
||||
* **도메인 주도 설계 (DDD):** 기술적인 계층화뿐만 아니라 비즈니스 영역을 '바운디드 컨텍스트(Bounded Context)'라는 단위로 나누고 '유비쿼터스 언어'를 공유하여 복잡한 비즈니스 현실을 아키텍처에 정확히 반영합니다 [25-27].
|
||||
* **마이크로 프론트엔드 및 FSD 아키텍처:** 프론트엔드 영역에서도 기능(Feature) 단위로 코드를 슬라이싱하는 FSD([[Feature-Sliced Design|Feature-Sliced Design]])나 마이크로 프론트엔드 아키텍처를 도입하여 대규모 웹 애플리케이션의 복잡성을 줄이고 각 팀의 자율성을 확보합니다 [28-30].
|
||||
### 매 4+1 View (Kruchten)
|
||||
- **Logical**: 매 도메인 객체 / 책임 분배.
|
||||
- **Process**: 매 runtime concurrency / 매 thread / 매 process.
|
||||
- **Development**: 매 module / 매 package 구조.
|
||||
- **Physical**: 매 deployment topology.
|
||||
- **Scenarios (+1)**: 매 use case driven validation.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
### 매 Quality Attributes (ISO/IEC 25010)
|
||||
- **Performance**: latency, throughput.
|
||||
- **Scalability**: horizontal / vertical 확장.
|
||||
- **Availability**: SLA, MTBF, MTTR.
|
||||
- **Security**: CIA triad.
|
||||
- **Modifiability**: 매 변경 cost.
|
||||
- **Testability**: 매 격리 가능성.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[관심사의 분리 (SoC)|관심사의 분리(SoC]], 클린 아키텍처, 마이크로서비스 아키텍처, 도메인 주도 설계(DDD), [[SOLID 원칙|SOLID 원칙]]
|
||||
- **Projects/Contexts:** [[Netflix 마이크로서비스 전환|Netflix 마이크로서비스 전환]], 스포티파이 자율적 분대 모델, [[FSD (Feature-Sliced Design)|FSD (Feature-Sliced Design]]
|
||||
- **Contradictions/Notes:** 관심사의 분리 원칙은 코드 유지보수성과 확장성을 크게 높이지만, 과도한 분리나 추상화(오버엔지니어링)는 잦은 계층 간 데이터 변환과 네트워크 통신 증가를 유발하여 성능 오버헤드와 디버깅의 어려움을 초래할 수 있으므로 적절한 임계점을 찾는 것이 중요합니다 [31-33]. 또한 최근 도입되는 인공지능(AI) 시스템의 아키텍처에서는 모델의 결과가 확률적이라는 특성상, 전통적인 결정론적 단위 테스트(TDD) 방식 대신 허용 오차 범위 내의 통계적 속성을 검증하는 AI 특화 TDD 접근 방식이 요구됩니다 [34, 35].
|
||||
### 매 응용
|
||||
1. C4 model 으로 매 stakeholder communication.
|
||||
2. ADR (Architecture Decision Record) 으로 매 결정 추적.
|
||||
3. Fitness function 으로 매 architectural drift 방지.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-18*
|
||||
## 💻 패턴
|
||||
|
||||
---
|
||||
### ADR template
|
||||
```markdown
|
||||
# ADR 0042: Adopt CQRS for Order service
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## Status
|
||||
Accepted (2026-05-10)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## Context
|
||||
Read traffic 100x higher than write. Single Postgres table contention.
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
## Decision
|
||||
Split into command (Postgres) + query (Read replica + Redis cache).
|
||||
Event sourcing via Kafka.
|
||||
|
||||
## 🧪 검증 상태 (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
|
||||
## Consequences
|
||||
+ Read scales independently.
|
||||
- Eventual consistency window ~50ms.
|
||||
- Two data models to maintain.
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Fitness function (ArchUnit, Java)
|
||||
```java
|
||||
@AnalyzeClasses(packages = "com.shop")
|
||||
class ArchitectureTest {
|
||||
@ArchTest
|
||||
static final ArchRule domain_independent =
|
||||
noClasses().that().resideInAPackage("..domain..")
|
||||
.should().dependOnClassesThat().resideInAPackage("..infra..");
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
@ArchTest
|
||||
static final ArchRule controllers_only_call_services =
|
||||
classes().that().resideInAPackage("..controller..")
|
||||
.should().onlyDependOnClassesThat()
|
||||
.resideInAnyPackage("..service..", "java..");
|
||||
}
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### C4 Container diagram (Structurizr DSL)
|
||||
```
|
||||
workspace {
|
||||
model {
|
||||
user = person "Customer"
|
||||
shop = softwareSystem "Shop" {
|
||||
web = container "Web App" "React" "TypeScript"
|
||||
api = container "API" "Spring Boot"
|
||||
db = container "Database" "PostgreSQL 16"
|
||||
}
|
||||
user -> web "Browses"
|
||||
web -> api "Calls" "REST/JSON"
|
||||
api -> db "Reads/writes" "JDBC"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Hexagonal Architecture (Python)
|
||||
```python
|
||||
# domain/order.py — pure
|
||||
class Order:
|
||||
def confirm(self) -> "Order": ...
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
# application/ports.py
|
||||
class OrderRepo(Protocol):
|
||||
def save(self, o: Order) -> None: ...
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
# infra/postgres_order_repo.py — adapter
|
||||
class PostgresOrderRepo:
|
||||
def save(self, o: Order) -> None:
|
||||
self.conn.execute("INSERT ...")
|
||||
```
|
||||
|
||||
### Event Storming output → bounded contexts
|
||||
```
|
||||
[Order Placed] → [Payment Authorized] → [Inventory Reserved] → [Order Confirmed]
|
||||
Order BC Payment BC Inventory BC Order BC
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 small team, simple domain | Modular monolith (Shopify-style) |
|
||||
| 매 high read/write asymmetry | CQRS |
|
||||
| 매 audit critical | Event sourcing |
|
||||
| 매 polyglot / independent scaling | Microservices |
|
||||
| 매 latency critical, ML inference | Service mesh + sidecar |
|
||||
|
||||
**기본값**: 매 modular monolith → 매 evidence 기반 매 split.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[소프트웨어 공학]] · [[아키텍처 패턴 지식]]
|
||||
- 변형: [[Hexagonal Architecture]] · [[CQRS]] · [[Event Sourcing]]
|
||||
- 응용: [[Microservices]] · [[Modular Monolith]]
|
||||
- Adjacent: [[Domain-Driven Design]] · [[ADR]] · [[C4 Model]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 ADR 초안 / 매 trade-off 분석 / 매 quality attribute scenario 생성.
|
||||
**언제 X**: 매 production-grade fitness function 의 자동 작성 — 매 human review 필수.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Big design up-front**: 매 evolution 무시.
|
||||
- **Architecture astronaut**: 매 abstraction layer 과잉.
|
||||
- **Distributed monolith**: 매 microservice 의 분리 but 매 coupling 유지.
|
||||
- **No fitness function**: 매 drift 매 silently.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Bass/Clements/Kazman, *Software Architecture in Practice 4e*; Ford, *Building Evolutionary Architectures 2e*).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — 매 4+1, ADR, fitness function 패턴 추가 |
|
||||
|
||||
Reference in New Issue
Block a user