Software Architecture Styles

시스템을 어떤 구조로 설계할 것인가?

"Software Architecture Styles" 은 시스템을 구조적으로 설계할 때 반복적으로 사용되는 설계 패턴을 말한다.

이 "Software Architecture Styles" 은 시스템 설계의 '지도'라고 할 수 있다. 이 지도를 잘 아는 사람은 시스템이 사용되는 규모와 목적에 따라 올바른 길을 선택하고, 유지보수성과 확장성을 높이는데 큰 도움을 줄 수 있다.

 

 

Software Architecture Styles 의 목적별 활용 사례

최적의 설계 패턴 선택	시스템 규모, 팀 상황, 트래픽 특성에 맞는 아키텍처 선택 가능	스타트업 MVP → Layered, 글로벌 서비스 → Microservices
개발 생산성과 유지보수성 향상	코드 구조 명확, 책임 분리, 유지보수 쉬움	Layered: UI/비즈니스 로직 분리, Event-Driven: 새로운 기능 추가 시 기존 코드 영향 최소화
성능·확장성·보안 설계	아키텍처 스타일별로 성능과 보안 최적화 전략 적용 가능	Microservices: 서비스별 독립 확장, Client-Server: 인증·보안 로직 집중 관리
의사소통 효율성 증가	팀 내 전문 용어로 빠르고 명확한 설계 논의 가능	“이 서비스는 Event-driven 구조로 구현합니다”
레거시 시스템 개선	기존 모놀리식 시스템을 효율적으로 분리·개선 가능	Monolithic → Microservices, Event-driven로 리팩토링
기술 선택 가이드라인 제공	프레임워크·라이브러리·인프라 선택 시 방향성 제공	REST API → Layered, 실시간 데이터 스트리밍 → Event-driven, 클라우드 네이티브 → Microservices + Serverless

 

 

Software Architecture Styles

Layered (계층형)	시스템을 Presentation, Business, Data 등 계층으로 나눔. 유지보수 용이, 전통적인 엔터프라이즈 앱에 많이 사용.
Client-Server	클라이언트(사용자 인터페이스)와 서버(데이터·로직 처리)를 분리. 웹 서비스, 모바일 앱의 기본 구조.
Microservices	애플리케이션을 작고 독립적인 서비스 단위로 나눠 배포. 확장성과 유연성이 뛰어남.
Event-Driven	이벤트(메시지)에 반응하는 비동기 시스템. IoT, 실시간 데이터 처리에서 자주 사용.
Pipe-and-Filter	데이터를 처리하는 파이프라인 구조. 빅데이터 처리, 미디어 스트리밍 등에서 사용.
Service-Oriented (SOA)	재사용 가능한 서비스 단위로 구성. 마이크로서비스 이전 세대의 서비스 아키텍처.
Peer-to-Peer (P2P)	클라이언트-서버 구분 없이 모든 노드가 동등. 블록체인, 토렌트 등에 활용.
Message-Bus	메시지 브로커를 통한 컴포넌트 간 통신 구조. 이벤트 드리븐 아키텍처와 연계.
MVC (Model-View-Controller)	UI 중심의 아키텍처. 웹 앱, 데스크탑 앱 설계 표준.
Serverless	서버 관리 없이 이벤트 기반으로 클라우드 함수 실행. 비용 효율적이고 확장성 높음.

 

 

Event-Driven Architecture

정의	이벤트(Event)를 중심으로 컴포넌트가 비동기적으로 통신하는 아키텍처 스타일	이벤트 발생 → Event Bus → 여러 Subscriber 처리
핵심 특징	1. 비동기 처리2. 느슨한 결합3. 확장성 높음4. 유연성	주문 완료 이벤트 → 재고, 결제, 알림 시스템 각각 독립 처리
필요성 / 원인	- 실시간 데이터 처리 필요- 시스템 결합도가 높음 - 여러 서비스가 동시에 반응해야 함 - 비동기 처리로 시스템 부하 완화	IoT 센서 데이터, 전자상거래 주문, 주식 거래 시스템 등
구성 요소	- Event (상태 변화) - Event Producer / Publisher - Event Consumer / Subscriber - Event Channel / Event Bus / Message Broker	Kafka, RabbitMQ, AWS SNS/SQS, NATS
적합한 시스템	- 실시간 처리 시스템 - 확장성이 중요한 시스템 - 여러 서비스가 동시에 반응해야 하는 시스템 - 비동기 처리로 시스템 부하 완화	IoT, 마이크로서비스, 클라우드 네이티브, 전자상거래, 알림/통계 시스템
핵심 기술	1. 이벤트 생성(Publisher) → 코드, 라이브러리, 웹훅 2. 이벤트 전송(Message Broker / Pub-Sub) → Kafka, RabbitMQ, SNS/SQS 3. 이벤트 처리(Subscriber) → Worker, Serverless, 비동기 프레임워크 4. 이벤트 기록/관리 → Event Store, 모니터링, 재처리	Python Celery, FastAPI Background Tasks, Spring Events, Event Sourcing, Kafka Topics, ELK Stack, OpenTelemetry
주요 고려 사항	- Idempotency(중복 처리 방지) - Retry / Dead Letter Queue - Event Schema 정의 - Loose Coupling 유지	JSON/Avro/Protobuf로 이벤트 스키마 정의, 실패 이벤트 재처리 전략

 

 

Event-Driven Architecture 의 구성요소 상세

구성요소	역할	구현 기능	대표 기술
Event (이벤트)	시스템에서 발생한 상태 변화	- 모델 저장, 사용자 액션 등 상태 변경 발생 - 이벤트 이름과 관련 데이터 포함	Python dict/JSON, Pydantic 모델, Django Signals payload
Event Producer / Publisher	이벤트를 생성하고 발행	- Django 모델의 post_save/post_delete signal 사용 - 특정 작업 완료 시 이벤트 발행 - Celery task로 브로커에 이벤트 전송	Django Signals, Celery send_task, Webhook, REST API
Event Consumer / Subscriber	이벤트를 받아 실제 작업 수행	- Celery worker에서 이벤트 수신 후 처리 - 비동기 task로 이메일 발송, 알림, DB 업데이트 수행 - 여러 subscriber 독립 실행	Celery tasks, Django Channels Consumers, Django Background Tasks, Asyncio + Django
Event Channel / Event Bus / Message Broker	이벤트를 전달하고 구독자에게 배포	- 이벤트 큐/브로커를 통해 Publisher와 Subscriber 연결 - 순서 보장, 재시도 가능	RabbitMQ, Redis Queue (RQ), Celery Broker, Kafka, AWS SQS
Event Store / 로그	이벤트 기록 및 재처리	- 이벤트 데이터를 DB에 저장하여 재처리 가능 - 모델 이벤트 기록/audit trail 활용	Django models(예: EventLog), PostgreSQL/Redis, Kafka Topics
Monitoring / 관리 도구	이벤트 흐름 및 상태 추적	- Celery task 모니터링, 실패 task 재시도 - 이벤트 처리 상태 및 시스템 성능 확인	Flower(Celery 모니터링), Sentry, Prometheus/Grafana, Django admin 로그

 

 

Event-Driven Architecture 구현을 위한 활용 기술

역할	목적	기능	활용 기술
이벤트 생성 (Event Producer / Publisher)	이벤트 발생, 시스템 상태 변화를 브로커로 전달	- 특정 상태 변화 시 이벤트 발행 - 코드 내에서 이벤트 구조 정의- 다른 시스템과 직접 연결 없이 이벤트 발행	Python: Django Signals, FastAPI Event, Celery send_taskWebhook, REST API
이벤트 전송 / 브로커 (Event Channel / Message Broker)	이벤트를 안전하게 전달하고 구독자에게 배포	- 이벤트 전달 보장, 큐잉, 브로드캐스트 - Pub/Sub 패턴 지원 - 순서 보장/재시도 기능	RabbitMQ, Apache Kafka, AWS SNS/SQS, Google Pub/Sub, Redis Streams
이벤트 처리 (Event Consumer / Subscriber)	이벤트 수신 후 실제 작업 수행	- 이벤트를 받아 비즈니스 로직 수행 - Worker나 서버리스 함수 등 독립적 실행 - 여러 subscriber가 독립적으로 처리 가능	Celery Worker, Django Channels Consumers, Asyncio, Serverless (AWS Lambda)
이벤트 기록 / 스토리지 (Event Store / Logging)	이벤트 기록, 재처리, 상태 복원	- 이벤트 영구 저장 - 실패 이벤트 재처리, 시스템 감사(audit trail) 활용 - Event Sourcing 적용 가능	Kafka Topics, Event Sourcing, Django models (EventLog), PostgreSQL/Redis
모니터링 / 관리 (Monitoring / Management)	이벤트 흐름 및 처리 상태 추적	- 이벤트 처리 상태 확인, 실패 이벤트 재처리 알림 - 성능 모니터링, 장애 분석	ELK Stack, OpenTelemetry, Jaeger, Zipkin, Flower(Celery), Sentry
추가 고려 사항	안정성과 신뢰성 보장	- Idempotency: 중복 처리 방지 - Retry / Dead Letter Queue: 실패 이벤트 처리 - Event Schema 정의: JSON, Avro, Protobuf - Loose Coupling: 서비스 간 직접 호출 최소화	Event schema 관리 툴, Celery Retry, Dead Letter Queue, Kafka Schema Registry

 

 

 

Architectural Styles in History

역사 속 건축 양식들