[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -2,92 +2,194 @@
|
||||
id: wiki-2026-0508-모놀리식-아키텍처-monolithic-architectur
|
||||
title: 모놀리식 아키텍처 (Monolithic Architecture)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-C46007]
|
||||
aliases: [Monolith, Modular Monolith, 단일 서비스 아키텍처]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
verification_status: applied
|
||||
tags: [architecture, monolith, software-design, deployment]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - 모놀리식 아키텍처 (Monolithic [[Architecture]])"
|
||||
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: language-agnostic
|
||||
framework: Spring/Rails/Django/Next.js
|
||||
---
|
||||
|
||||
# [[모놀리식 아키텍처 (Monolithic Architecture)]]
|
||||
# 모놀리식 아키텍처 (Monolithic Architecture)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 모놀리식 아키텍처는 애플리케이션의 모든 기능이 단일하고 강하게 결합된 단위로 구축되는 전통적인 소프트웨어 설계 방식입니다 [1]. 개발자 팀이 소규모일 경우 협의를 통해 채택하기 적합한 구조이며, 대규모 엔터프라이즈 시스템을 구축하는 데에도 역사적으로 널리 사용되어 왔습니다 [2, 3]. 그러나 시스템 규모가 커짐에 따라 새로운 기능의 배포가 지연되고 유지보수가 어려워지는 한계가 있어, 현대에는 마이크로서비스 아키텍처 등으로 전환되는 추세입니다 [1, 4, 5].
|
||||
## 매 한 줄
|
||||
> **"매 단일 deployable unit 으로 묶인 application"**. 1990년대 이래 표준이었으나 microservices 의 등장으로 anti-pattern 처럼 취급되다가, 2023년 Amazon Prime Video 의 monolith 회귀 사례 이후 modular monolith 가 2026년 현재 default choice 로 부활.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **구조 및 특징:** 모놀리식 아키텍처는 모든 기능이 하나의 단일 단위에 통합되어 동작합니다 [1]. 애플리케이션의 규모를 확장(Scaling)할 때는 주로 전체 시스템을 수평적으로 복제 및 분할하는 X축 스케일링(X-Axis Scaling) 방식을 따릅니다 [6]. 또한, 대다수의 기존 개발 도구(IDE)들은 분산형 애플리케이션보다는 이러한 모놀리식 애플리케이션을 구축하는 데 명시적인 지원을 맞추고 있습니다 [7].
|
||||
* **장점 및 활용:** 신규 프로젝트를 시작하는 소규모 팀(예: 5명 규모)의 경우, 복잡한 분산 환경보다는 팀 내 협의하에 모놀리식 구조로 시스템을 개발하는 것이 효율적일 수 있습니다 [2]. 뿐만 아니라, 대규모 엔터프라이즈 시스템 역시 모놀리식 시스템으로 구축할 수 있음이 역사적인 사례들을 통해 증명되었습니다 [3].
|
||||
* **한계 및 복잡성 증가:** 시스템과 조직의 규모가 확장되면 모놀리식 아키텍처는 뚜렷한 한계를 보입니다. 코드가 강하게 결합된 거대한 모놀리식 웹 앱이나 취약한 스크립트는 새로운 기능의 개발과 전달을 크게 지연시킵니다 [5, 8, 9]. 또한, 수정 사항이 발생할 때마다 전체 애플리케이션 인스턴스를 다루어야 하므로, 독립적인 단위로 나뉜 마이크로서비스에 비해 유지보수와 배포가 까다롭습니다 [10-12].
|
||||
* **현대 아키텍처로의 전환 사례:** 이러한 단일 구조의 단점을 극복하기 위해 많은 기업이 분산형 구조로 전환하고 있습니다. 대표적으로 넷플릭스(Netflix)는 혁신, 신뢰성, 효율성을 향상시키기 위해 기존의 모놀리식 아키텍처를 독립적인 마이크로서비스로 분리했습니다 [4]. 스포티파이(Spotify) 역시 프론트엔드 측면에서 거대한 모놀리식 웹 앱을 쪼개어 독립적으로 개발된 작은 모듈들로 결합하는 방식을 채택하여 개발 병목을 해결했습니다 [9].
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
### 매 정의
|
||||
- 매 single codebase, single build, single deployment.
|
||||
- 매 모든 business capability 가 하나의 process 내 in-memory 호출.
|
||||
- 매 single database 공유 (보통 RDBMS).
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[마이크로서비스 아키텍처 (Microservices Architecture)]], X축 스케일링 (X-Axis Scaling)
|
||||
- **Projects/Contexts:** 넷플릭스 (Netflix), 스포티파이 (Spotify)
|
||||
- **Contradictions/Notes:** 소스에 따르면 대규모 엔터프라이즈 시스템을 모놀리식 구조로 구축하는 것이 가능하다고 증명되어 있지만 [3], 실제 급격히 성장하는 기업(넷플릭스 등)의 사례에서는 규모 확장에 따른 기능 전달 지연 및 유지보수 문제를 해결하기 위해 모놀리식 아키텍처를 포기하고 마이크로서비스 아키텍처로 전환(Migration)하는 한계를 보입니다 [4, 5].
|
||||
### 매 variant
|
||||
- **Big ball of mud**: 매 module boundary X. 매 anti-pattern.
|
||||
- **Layered monolith**: 매 controller / service / repo layer 분리. 매 일반적.
|
||||
- **Modular monolith**: 매 internal module boundary 명확. 매 microservices 직전 단계.
|
||||
- **Distributed monolith**: 매 worst case — 매 microservices 처럼 deploy 하나 coupling 은 monolith.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-18*
|
||||
### 매 응용
|
||||
1. Early-stage startup MVP — 매 fast iteration.
|
||||
2. Internal tools — 매 traffic low, complexity low.
|
||||
3. Modular monolith — 매 mid-size product (Shopify, Basecamp, GitHub).
|
||||
|
||||
---
|
||||
## 💻 패턴
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### Layered structure (Spring Boot)
|
||||
```java
|
||||
// src/main/java/com/example/app/
|
||||
// ├── controller/ ── HTTP boundary
|
||||
// ├── service/ ── business logic
|
||||
// ├── repository/ ── data access
|
||||
// └── domain/ ── entities
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
@RestController
|
||||
@RequestMapping("/orders")
|
||||
class OrderController {
|
||||
private final OrderService service;
|
||||
OrderController(OrderService s) { this.service = s; }
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
@PostMapping
|
||||
Order create(@RequestBody CreateOrderReq req) {
|
||||
return service.placeOrder(req);
|
||||
}
|
||||
}
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
@Service
|
||||
class OrderService {
|
||||
private final OrderRepository orders;
|
||||
private final PaymentService payments; // 매 in-process call
|
||||
|
||||
- **정보 상태:** 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
|
||||
@Transactional
|
||||
Order placeOrder(CreateOrderReq req) {
|
||||
var order = orders.save(new Order(req));
|
||||
payments.charge(order); // 매 same DB transaction
|
||||
return order;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Modular monolith (Rails-like, internal API)
|
||||
```ruby
|
||||
# app/modules/billing/
|
||||
# ├── public/ # 매 외부 module 가 import 가능
|
||||
# │ └── billing_api.rb
|
||||
# └── internal/ # 매 module 내부에서만
|
||||
# ├── invoice.rb
|
||||
# └── stripe_client.rb
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
# 매 module boundary enforcement (packwerk gem)
|
||||
module Billing
|
||||
module Public
|
||||
class BillingAPI
|
||||
def self.charge(user_id:, amount:)
|
||||
Internal::StripeClient.new.charge(user_id, amount)
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
# 매 Catalog module 가 Billing 호출 — 매 public API 만
|
||||
class CheckoutFlow
|
||||
def call(cart)
|
||||
Billing::Public::BillingAPI.charge(
|
||||
user_id: cart.user_id,
|
||||
amount: cart.total
|
||||
)
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Single binary deploy (Go)
|
||||
```go
|
||||
// main.go — 매 entire app one binary
|
||||
func main() {
|
||||
db := mustOpenDB()
|
||||
defer db.Close()
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
mux := http.NewServeMux()
|
||||
mux.Handle("/users/", users.NewHandler(db))
|
||||
mux.Handle("/orders/", orders.NewHandler(db))
|
||||
mux.Handle("/billing/", billing.NewHandler(db))
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
log.Fatal(http.ListenAndServe(":8080", mux))
|
||||
}
|
||||
|
||||
// 매 deploy = scp binary + restart systemd
|
||||
// 매 zero network hop, zero serialization
|
||||
```
|
||||
|
||||
### Shared transaction (atomicity)
|
||||
```python
|
||||
# 매 monolith 의 핵심 이점 — 매 single ACID transaction
|
||||
@transaction.atomic
|
||||
def transfer_funds(from_id, to_id, amount):
|
||||
src = Account.objects.select_for_update().get(id=from_id)
|
||||
dst = Account.objects.select_for_update().get(id=to_id)
|
||||
src.balance -= amount
|
||||
dst.balance += amount
|
||||
src.save(); dst.save()
|
||||
AuditLog.objects.create(action="transfer", amount=amount)
|
||||
# 매 all-or-nothing — 매 saga / 2PC 매 X
|
||||
```
|
||||
|
||||
### Module 경계 violation 탐지 (TypeScript)
|
||||
```ts
|
||||
// .dependency-cruiser.cjs
|
||||
module.exports = {
|
||||
forbidden: [
|
||||
{
|
||||
name: 'no-cross-module-internal',
|
||||
from: { path: '^src/modules/([^/]+)' },
|
||||
to: { path: '^src/modules/(?!\\1)[^/]+/internal' },
|
||||
},
|
||||
],
|
||||
};
|
||||
// 매 CI 에서 검증 — 매 module boundary 매 enforce
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 팀 < 20명, product 단일 | **Modular monolith** |
|
||||
| MVP / startup early stage | **Layered monolith** |
|
||||
| Independent scaling 필요 (e.g. ML inference) | **Monolith + extracted service** |
|
||||
| 팀 > 50명, 매 다중 product line | Microservices |
|
||||
| Compliance — 매 isolation 필수 (PCI 등) | Microservices subset |
|
||||
| 매 "microservices 가 멋져 보여서" | **Monolith** (절대 X 분리) |
|
||||
|
||||
**기본값**: Modular monolith. 매 boundary 가 stable 해진 후 strangler-fig pattern 으로 extract.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Software Architecture]] · [[Deployment Models]]
|
||||
- 변형: [[Modular Monolith]] · [[Layered Architecture]] · [[Distributed Monolith]]
|
||||
- 응용: [[Shopify Architecture]] · [[Basecamp HEY]] · [[GitHub Rails Monolith]]
|
||||
- Adjacent: [[Microservices]] · [[Service-Oriented Architecture]] · [[Strangler Fig Pattern]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: MVP 설계, 매 small-team product, 매 strong consistency 요구, 매 deployment simplicity 우선.
|
||||
**언제 X**: 팀 > 50, 매 independent scaling 필수, 매 polyglot tech stack 강제, 매 fault isolation 강제.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Premature microservices**: 매 100명 이하 팀이 매 microservices — 매 distributed monolith 직행.
|
||||
- **Big ball of mud**: 매 module boundary 없이 grow — 매 5년 후 rewrite.
|
||||
- **Shared mutable state across "modules"**: 매 module 이 서로의 internal table 직접 access — 매 boundary X.
|
||||
- **God service**: 매 OrderService 가 매 모든 domain 호출 — 매 modularity X.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Fowler "MonolithFirst" 2015, Amazon Prime Video case study 2023, Shopify modular monolith talk 2021).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — modular monolith 부활 perspective + 5 patterns |
|
||||
|
||||
Reference in New Issue
Block a user