AWS Solutions Architect · 강의

안무 방식과 오케스트레이션 패턴 비교

이벤트 안무 방식(각 서비스가 독립적으로 반응)과 오케스트레이션(중앙 조정자가 서비스를 지시)을 비교하고 아키텍처에 적합한 패턴을 선택합니다.

안무 방식과 오케스트레이션 패턴 비교은(는) CoddyKit의 무료 AWS Solutions Architect 강의입니다. 이것은 4개 중 4번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 AWS Solutions Architect 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. AWS Solutions Architect 강의에는 총 4개의 강의가 포함되어 있습니다.

마이크로서비스 조정을 위한 두 가지 접근 방식

마이크로서비스가 함께 작동하여 비즈니스 프로세스를 완료해야 할 때는 두 가지 기본 조정 패턴이 있습니다. Orchestration은 중앙 조정자(예: Step Functions)가 각 서비스를 명시적으로 지시하는 방식입니다. Choreography에는 중앙 조정자가 없으며 서비스가 이벤트를 수신하고 독립적으로 반응합니다. 어떤 방식을 언제 사용하고 어떻게 조합할지 이해하는 것은 SAA-C03 시험에서 평가되는 핵심 아키텍처 역량입니다.

오케스트레이션 패턴 설명

orchestration에서는 중앙 서비스(orchestrator)가 작업 순서를 제어합니다. 서비스 A를 호출하고 응답을 기다린 다음 서비스 B를 호출하는 식으로 진행합니다. orchestrator는 프로세스 상태를 전체적으로 파악하고 오류와 재시도를 처리하며 중간 결과에 따라 결정을 내릴 수 있습니다. AWS에서는 Step Functions가 대표적인 orchestrator입니다. 전체 워크플로를 상태 머신으로 정의하고 각 단계를 실행합니다.

# Orchestration: Step Functions state machine drives order processing
# StepFunctions -> ValidateOrder Lambda -> ChargePayment Lambda -> NotifyShipping Lambda
# Each arrow is an explicit command from the orchestrator
# If ChargePayment fails, Step Functions catches the error and routes to NotifyFailure
# The orchestrator (Step Functions) knows the full state of the order at every moment

안무 방식 패턴 설명

choreography에서는 중앙 조정자 없이 서비스가 이벤트를 통해 통신합니다. 서비스 A가 작업을 완료하고 이벤트(예: OrderValidated)를 이벤트 버스나 주제에 게시합니다. 서비스 B는 OrderValidated 이벤트를 수신하여 결제를 처리한 다음 PaymentCharged를 게시합니다. 서비스 C는 PaymentCharged를 수신하고 주문을 배송합니다. 각 서비스는 자율적이고 결합도가 낮으며, 다른 서비스가 아니라 자신이 소비하고 생성하는 이벤트만 알고 있습니다.

# Choreography: EventBridge bus connects services without central coordinator
# OrderService -> publishes 'OrderPlaced' to EventBridge
# PaymentService -> listens for 'OrderPlaced', charges card, publishes 'PaymentCharged'
# ShippingService -> listens for 'PaymentCharged', creates shipment, publishes 'OrderShipped'
# NotificationService -> listens for 'OrderShipped', sends email
# No service calls another service directly — all communication is via events

각 패턴에 사용되는 AWS 서비스

AWS에서는 Step Functions가 주요 오케스트레이션 도구입니다. 안무 방식에서는 Amazon EventBridge(내용 기반 필터링을 사용하여 서비스 간 이벤트 라우팅), Amazon SNS(간단한 팬아웃), Amazon SQS(서비스 간 일대일 메시지 전달)가 주요 도구입니다. 패턴을 조합할 수도 있습니다. 제한된 컨텍스트 간 도메인 간 안무에는 EventBridge를 사용하고, 단일 도메인 내 단계 오케스트레이션에는 Step Functions를 사용하세요.

트레이드오프: 관찰 가능성

오케스트레이션은 중앙 집중식 가시성을 제공합니다. Step Functions 실행 기록에는 워크플로가 현재 어느 위치에 있는지, 각 단계에 얼마나 걸렸는지, 무엇이 실패했는지가 정확히 표시됩니다. 디버깅도 간단합니다. 안무 방식은 여러 서비스와 이벤트 버스에 걸쳐 가시성을 분산하므로 단일 비즈니스 트랜잭션을 추적하려면 여러 서비스의 로그와 이벤트를 연관 지어야 합니다. 따라서 안무 방식 시스템은 종단 간 가시성을 위해 상관관계 ID와 분산 추적(AWS X-Ray)에 크게 의존합니다.

# Correlation ID pattern for choreography observability
# Every event includes a correlationId that flows through the entire chain
{
  'source': 'com.myapp.orders',
  'detail-type': 'OrderPlaced',
  'detail': {
    'orderId': 'ORD-123',
    'correlationId': 'CORR-abc-456',  # propagated to every downstream event
    'customerId': 'CUST-789',
    'total': 99.99
  }
}

트레이드오프: 결합도

안무 방식은 더 느슨한 결합을 제공합니다. 기존 이벤트를 수신하는 새 서비스를 추가해도 기존 서비스를 변경할 필요가 없습니다. 예를 들어 OrderPlaced 이벤트를 수신하는 분석 서비스를 추가해도 주문 서비스나 결제 서비스에는 영향이 없습니다. 오케스트레이션은 orchestrator와 호출 대상인 모든 서비스 사이에 더 긴밀한 결합을 만듭니다. 새 단계를 추가하려면 상태 머신 정의를 수정해야 하지만 개별 서비스는 격리된 상태로 유지됩니다.

트레이드오프: 오류 처리

오케스트레이션은 오류 처리를 명시적으로 만듭니다. Step Functions Catch 블록은 각 오류 유형에 대한 대체 상태를 정의하며 전체 워크플로 기록에는 실패 상황이 표시됩니다. 안무 방식에서는 오류 처리가 분산됩니다. 각 서비스가 자체 실패를 처리해야 하며, 필요한 경우 다른 서비스가 반응할 수 있도록 실패 이벤트를 게시합니다. saga(단계가 실패했을 때 작업을 되돌리는 보상 트랜잭션)를 구현하는 일은 오케스트레이션보다 안무 방식에서 훨씬 복잡합니다.

# Saga pattern in choreography: compensating events
# Happy path:
# OrderPlaced -> PaymentCharged -> InventoryReserved -> OrderShipped
#
# Failure path (InventoryReservation fails):
# InventoryReservationFailed event published
# PaymentService listens -> issues refund -> publishes PaymentRefunded
# OrderService listens -> cancels order -> publishes OrderCancelled
#
# In orchestration (Step Functions), the compensating logic is in explicit Catch states

오케스트레이션을 선택할 때

다음과 같은 경우 orchestration을 선호하세요. 비즈니스 프로세스에 명확한 선형 또는 분기 순서와 명시적인 성공·실패 결과가 있는 경우, 운영 또는 규정 준수를 위해 프로세스 상태에 대한 중앙 집중식 가시성이 필요한 경우, 오류 처리에 복잡한 보상 로직이 포함된 경우, 또는 워크플로가 장시간 실행되며 서비스 재시작 후에도 계속되어야 하는 경우입니다. 예로는 주문 이행, 환자 등록, 보험 청구 처리가 있으며, 모두 명확한 시작과 종료 및 감사 요구 사항이 있는 워크플로입니다.

안무 방식을 선택할 때

다음과 같은 경우 choreography를 선호하세요. 서로 다른 팀이 서비스를 소유하여 긴밀하게 조정해서는 안 되는 경우, 기존 서비스를 수정하지 않고 새 서비스로 확장할 수 있어야 하는 경우, 이벤트가 명령이 아닌 사실을 나타내는 경우(예: 'OrderShipped'가 아닌 'ShipOrder'), 또는 중앙 병목이 없어 최대한의 확장성을 원하는 경우입니다. 예로는 분석 수집, 알림 팬아웃, 감사 로깅이 있으며, 여러 독립 소비자가 동일한 이벤트에 반응하는 모든 사례가 해당합니다.

Hybrid Architectures

실제 AWS 아키텍처의 대부분은 서로 다른 세분화 수준에서 두 패턴을 모두 사용합니다. 일반적인 하이브리드 방식은 다음과 같습니다. EventBridge choreography를 사용해 경계가 지정된 컨텍스트를 분리합니다(예: Order 도메인이 이벤트를 생성하면 Inventory, Payment, Shipping 도메인이 각각 독립적으로 응답). 한편 Payment 도메인 내부에서는 Step Functions orchestration을 사용해 내부 결제 워크플로 단계(청구, 사기 확인, 결제 승인, 정산)를 조정합니다. 이렇게 하면 도메인 간 결합도는 낮추면서 내부 프로세스는 명확하게 유지할 수 있습니다.

# Hybrid: EventBridge for inter-domain + Step Functions for intra-domain
#
# EventBridge bus (choreography):
#   Order domain publishes 'OrderPlaced'
#   Payment domain receives it, starts Step Functions execution
#
# Step Functions (orchestration inside Payment domain):
#   ValidateCard -> FraudCheck -> AuthorisePayment -> SettlePayment
#   On success: PaymentDomain publishes 'PaymentCharged' to EventBridge bus
#   On failure: Step Functions Catch -> publishes 'PaymentFailed' event

SAA-C03 Exam Signals

시험에서는 다음과 같은 신호를 찾아보셔야 합니다. Choreography 키워드: 'loosely coupled', 'services react to events', 'teams own independent services', 'fan-out to multiple consumers', 'add new service without changing existing ones'. Orchestration 키워드: 'coordinate steps in sequence', 'track workflow state', 'handle partial failures with compensation', 'human approval step', 'long-running process with error handling'. 중앙 조정자가 다른 서비스를 지시하는 내용의 문제는 항상 orchestration을 의미합니다.

Quick Check

이 레슨에서 다룬 AWS Solutions Architect (SAA-C03) 개념을 얼마나 이해했는지 확인해 보세요.

Lesson Recap

이 레슨에서는 다음을 배웠습니다. orchestration은 중앙 조정자(Step Functions)를 사용해 명시적이고 가시적인 워크플로 제어를 수행합니다. choreography는 이벤트(EventBridge)를 사용해 느슨한 결합과 확장성을 제공합니다. 또한 대부분의 운영 아키텍처는 서로 다른 세분화 수준에서 두 패턴을 결합합니다. 다음 레슨에서는 SAA-C03 시험 형식과 도메인별 비중에 따른 학습 전략을 살펴보겠습니다.

자주 묻는 질문

“안무 방식과 오케스트레이션 패턴 비교” 강의는 무료인가요?

네 — “안무 방식과 오케스트레이션 패턴 비교” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 AWS Solutions Architect 강의 전체를 잠금 해제할 수 있습니다. AWS Solutions Architect 강의에는 총 4개의 강의가 포함되어 있습니다.

“안무 방식과 오케스트레이션 패턴 비교”에서 뭘 배우나요?

이벤트 안무 방식(각 서비스가 독립적으로 반응)과 오케스트레이션(중앙 조정자가 서비스를 지시)을 비교하고 아키텍처에 적합한 패턴을 선택합니다. 브라우저에서 직접 실행하는 실습 코드로 AWS Solutions Architect을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

AWS Solutions Architect을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 AWS Solutions Architect은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 4번째 강의입니다.

“안무 방식과 오케스트레이션 패턴 비교” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 AWS Solutions Architect 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 AWS Solutions Architect 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← AWS Solutions Architect(으)로 돌아가기