9148c358d0
Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를 Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류. - 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로 자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거, 동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거. - 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming, Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business, Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로, 나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는 title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백). 원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지. - 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서. - 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는 지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지. - Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경. - 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.
5.4 KiB
5.4 KiB
id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack
| id | title | category | status | canonical_id | aliases | duplicate_of | source_trust_level | confidence_score | verification_status | tags | raw_sources | last_reinforced | github_commit | tech_stack | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| wiki-2026-0508-마이크로서비스-아키텍처의-의존성-관리 | 마이크로서비스 아키텍처의 의존성 관리 | 10_Wiki/Topics | verified | self |
|
none | A | 0.9 | applied |
|
2026-05-10 | pending |
|
마이크로서비스 아키텍처의 의존성 관리
매 한 줄
"매 service 간 coupling 의 minimize, 매 explicit contract 의 enforce.". 매 monolith 의 internal call 의 network call 의 transform 의 후, 매 transitive dependency · version skew · cascading failure 의 새로운 challenge 의 emerge. 2026 modern stack 은 매 OpenAPI/Protobuf contract + service mesh (Istio/Linkerd) + 매 SBOM-driven dependency tracking 의 combine.
매 핵심
매 dependency 의 종류
- Build-time: 매 shared library 의 dependency (avoid — leads to coordinated deploys).
- Runtime sync: 매 HTTP/gRPC call 의 직접 의존 (latency · failure propagation).
- Runtime async: 매 event/queue 의 통한 loose coupling (Kafka, NATS).
- Data: 매 shared DB schema 의 의존 (anti-pattern — own your data).
매 핵심 원칙
- Bounded context: 매 서비스 의 own 의 data + 매 logic 의 own.
- Explicit contract: 매 OpenAPI/gRPC schema 의 source-of-truth.
- Backward compatibility: 매 N-2 version 의 support.
- Failure isolation: 매 circuit breaker · timeout · bulkhead.
매 응용
- 매 dependency graph 의 visualize (Backstage, Grafana service map).
- 매 contract testing 의 CI integration (Pact, Schemathesis).
- 매 chaos engineering 의 통한 cascading failure 의 test.
💻 패턴
Circuit Breaker (Go, gobreaker)
import "github.com/sony/gobreaker"
cb := gobreaker.NewCircuitBreaker(gobreaker.Settings{
Name: "payment-service",
MaxRequests: 3,
Interval: 60 * time.Second,
Timeout: 30 * time.Second,
ReadyToTrip: func(c gobreaker.Counts) bool {
return c.ConsecutiveFailures > 5
},
})
result, err := cb.Execute(func() (interface{}, error) {
return paymentClient.Charge(ctx, req)
})
gRPC contract via Protobuf
syntax = "proto3";
package payment.v1;
service PaymentService {
rpc Charge(ChargeRequest) returns (ChargeResponse);
}
message ChargeRequest {
string order_id = 1;
int64 amount_cents = 2;
string currency = 3;
}
Pact consumer-driven contract test
import { PactV3 } from "@pact-foundation/pact";
const provider = new PactV3({ consumer: "checkout", provider: "payment" });
provider
.uponReceiving("a charge request")
.withRequest({ method: "POST", path: "/v1/charge", body: { amount: 1000 } })
.willRespondWith({ status: 200, body: { id: "ch_123", status: "ok" } });
Async event via Kafka (decouple)
producer.Send(&kafka.Message{
Topic: "order.placed.v1",
Value: marshal(OrderPlaced{ID: orderID, Items: items}),
})
// payment, inventory, notification 의 own pace 의 consume.
Service mesh policy (Istio)
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
hosts: [payment]
http:
- timeout: 2s
retries:
attempts: 3
perTryTimeout: 500ms
retryOn: 5xx,reset,connect-failure
Dependency graph extraction
# Backstage catalog scan + 매 OpenTelemetry trace 의 통한 actual call graph
otel-cli export --format=json | jq '.spans[] | {service, downstream}'
SBOM for transitive deps
syft packages dir:. -o cyclonedx-json > sbom.json
grype sbom:sbom.json --fail-on high
매 결정 기준
| 상황 | Approach |
|---|---|
| Strong consistency 의 required | Sync gRPC + saga compensation |
| 매 latency-sensitive read | Sync + cache (Redis) |
| 매 cross-service workflow | Async event + saga orchestrator (Temporal) |
| Shared reference data | Read replica or 매 cached projection |
| Tight build coupling | Refactor — extract 매 shared concept 의 own service |
기본값: 매 async event-driven + 매 contract testing + 매 service mesh resilience.
🔗 Graph
- 부모: Microservices · Distributed Systems
- 변형: Service Mesh · Event-Driven Architecture
- 응용: Circuit_Breaker · Contract_Testing
- Adjacent: API_Versioning · Observability
🤖 LLM 활용
언제: 매 service decomposition 의 design, 매 dependency graph 의 review, 매 contract evolution 의 plan. 언제 X: 매 small monolith — 매 premature decomposition 의 cost > benefit.
❌ 안티패턴
- Distributed monolith: 매 service 의 split 의 했지만 매 deploy 의 still coordinated.
- Shared DB: 매 두 service 가 same table 의 write — coupling worst case.
- Chatty API: 매 single user action 의 N개 service call 의 fan-out.
- No timeout: 매 default infinite timeout — cascading hang.
- Synchronous chain: A → B → C → D 매 single failure 의 entire chain 의 break.
🧪 검증 / 중복
- Verified (Sam Newman Building Microservices 2nd ed, CNCF service mesh landscape 2026).
- 신뢰도 A.
🕓 Changelog
| 날짜 | 변경 |
|---|---|
| 2026-05-08 | Phase 1 |
| 2026-05-10 | Manual cleanup — dependency types, contract testing, mesh resilience patterns |