2nd/10_Wiki/Topics/Domain_Programming/Architecture/마이크로서비스 아키텍처의 의존성 관리.md

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	Microservice Dependency Management Service Dependencies MSA 의존성	none	A	0.9	applied	microservices architecture dependency-management distributed-systems		2026-05-10	pending	language framework Go 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)

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