클라우드 개발을 처음 접하는 분이라면 "이벤트 기반 아키텍처"라는 말이 낯설게 느껴질 수 있습니다. 하지만 일상생활에서 이미 익숙한 개념입니다. 카페에서 주문을 하면 바리스타가 알아서 커피를 만들고, 주문자는 기다리는 동안 다른 일을 할 수 있죠. 이처럼 "이벤트(주문)"가 발생하면 관련된 서비스들이 각자 반응하는 방식이 바로 이벤트 기반 아키텍처입니다.
모놀리식 vs 마이크로서비스
먼저 왜 이런 구조가 필요한지부터 이해해봅시다.
예전에는 하나의 거대한 프로그램 안에 모든 기능을 넣는 방식(모놀리식)을 많이 사용했습니다. 쇼핑몰을 예로 들면, 로그인, 상품 검색, 결제, 배송 추적이 모두 하나의 코드 덩어리 안에 있는 것입니다. 이 방식의 문제는 결제 기능 하나를 수정하더라도 전체 시스템을 다시 배포해야 한다는 점입니다. 마치 건물 한 칸을 수리하려면 전체 건물을 비워야 하는 것과 같습니다.
마이크로서비스는 이 문제를 해결합니다. 로그인, 결제, 배송을 각각 독립적인 작은 서비스로 분리합니다. 결제 서비스에 문제가 생겨도 로그인이나 상품 검색은 정상 작동합니다. 쉽게 말하면, 아파트 단지처럼 각 동이 독립적으로 운영되는 구조입니다.
결합 방식 — 서비스들이 서로 연결되는 방법
서비스를 여러 개로 나눴다면, 이제 어떻게 연결할지가 중요합니다.
긴밀한 결합(Tight Coupling)은 서비스 A가 서비스 B를 직접 전화로 연결하는 것과 같습니다. B가 전화를 받지 않으면(다운되면) A는 아무것도 못 합니다.
느슨한 결합(Loose Coupling)은 A가 메모를 우편함에 넣으면 B가 나중에 꺼내 처리하는 방식입니다. B가 잠시 자리를 비워도(다운되어도) A는 계속 메모를 쌓을 수 있고, B가 돌아오면 순서대로 처리합니다. AWS에서는 SQS(Simple Queue Service)라는 메시지 큐가 이 우편함 역할을 합니다.
동기 vs 비동기 처리
동기(Synchronous)는 커피를 주문하고 카운터 앞에서 나올 때까지 기다리는 방식입니다. API Gateway에서 Lambda를 직접 호출하고 응답을 기다리는 것이 대표적입니다.
비동기(Asynchronous)는 카페 앱으로 주문하고 자리에 앉아서 다른 일을 하다가 진동벨이 울리면 가져오는 방식입니다. SNS나 SQS를 통해 Lambda를 호출하면 바로 반환하고, 결과는 나중에 확인합니다.
비동기의 장점은 세 가지입니다. 첫째, 많은 요청이 한꺼번에 와도 처리할 수 있습니다(확장성). 둘째, 일부 서비스가 실패해도 전체가 멈추지 않습니다(내결함성). 셋째, 각 서비스가 서로 영향을 주지 않고 독립적으로 작동합니다(독립성).
핵심 패턴
팬아웃 (Fan-out)
쉽게 말하면 "방송"입니다. 하나의 이벤트를 여러 서비스에 동시에 전달합니다. 예를 들어 새 주문이 들어오면 재고 관리, 결제, 알림 서비스가 동시에 이 사실을 받아 처리합니다.
AWS에서는 SNS 토픽이 방송국 역할을 하고, 각각의 SQS 큐가 구독자 역할을 합니다. SNS 토픽 하나에 여러 SQS 큐를 연결하는 SNS + SQS 팬아웃 패턴은 DVA-C02 시험에서 가장 자주 출제됩니다.
오케스트레이션 vs 안무 (Choreography)
오케스트레이션은 오케스트라 지휘자처럼 중앙에서 "1번 서비스 시작, 끝나면 2번 서비스 시작" 하고 전체 흐름을 통제합니다. AWS Step Functions가 이 역할을 합니다. 복잡한 워크플로를 시각적으로 관리하고 각 단계의 성공/실패를 추적할 수 있습니다.
안무는 플래시몹과 같습니다. 음악이 시작되면(이벤트 발생) 각자 맡은 동작을 합니다. 중앙 지휘자 없이 각 서비스가 이벤트를 보고 알아서 반응합니다. AWS EventBridge가 이 이벤트 버스 역할을 합니다.
!오케스트레이션 vs 코레오그래피
Step Functions 상세
Step Functions는 여러 Lambda 함수나 AWS 서비스를 순서대로 연결하는 워크플로 서비스입니다. 실행 방식에 따라 두 가지 유형이 있습니다.
Standard 타입은 최대 1년까지 실행할 수 있고 모든 실행 이력을 감사 로그로 남깁니다. 중요한 비즈니스 프로세스에 적합합니다.
Express 타입은 최대 5분 실행이 가능하고 매우 빠르며 저비용입니다. 초당 수십만 건의 짧은 이벤트를 처리할 때 사용합니다.
상태 유형에는 작업을 실행하는 Task, 조건 분기를 담당하는 Choice, 병렬 처리를 위한 Parallel, 지연을 위한 Wait, 배열 처리를 위한 Map, 그리고 Succeed와 Fail이 있습니다.
시험 핵심 정리
"하나의 이벤트를 여러 서비스에 동시 전달" -- SNS 팬아웃
"중앙에서 워크플로를 관리" -- Step Functions (오케스트레이션)
"각 서비스가 독립적으로 이벤트에 반응" -- 안무 (EventBridge)
"B 서비스 장애 시 A 서비스 영향 없음" -- 느슨한 결합 (SQS 사용)
"상태를 저장하지 않는 컴포넌트" -- 무상태(Stateless) 설계
"요청 후 바로 반환, 결과는 나중에" -- 비동기 패턴
"짧은 실행, 높은 처리량 워크플로" -- Step Functions Express
SNS + SQS 팬아웃 = DVA-C02 최빈출 패턴