--- id: wiki-2026-0508-마이크로서비스-아키텍처의-의존성-관리 title: 마이크로서비스 아키텍처의 의존성 관리 category: 10_Wiki/Topics status: verified canonical_id: self aliases: [Microservice Dependency Management, Service Dependencies, MSA 의존성] duplicate_of: none source_trust_level: A confidence_score: 0.9 verification_status: applied tags: [microservices, architecture, dependency-management, distributed-systems] raw_sources: [] last_reinforced: 2026-05-10 github_commit: pending tech_stack: language: Go framework: gRPC/Kubernetes --- # 마이크로서비스 아키텍처의 의존성 관리 ## 매 한 줄 > **"매 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. ### 매 응용 1. 매 dependency graph 의 visualize (Backstage, Grafana service map). 2. 매 contract testing 의 CI integration (Pact, Schemathesis). 3. 매 chaos engineering 의 통한 cascading failure 의 test. ## 💻 패턴 ### Circuit Breaker (Go, gobreaker) ```go 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 ```proto 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 ```typescript 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) ```go 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) ```yaml 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 ```bash # Backstage catalog scan + 매 OpenTelemetry trace 의 통한 actual call graph otel-cli export --format=json | jq '.spans[] | {service, downstream}' ``` ### SBOM for transitive deps ```bash 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 |