동기 vs 비동기 & 메시지 브로커 개념 정리

 

✅ 동기(Synchronous) vs 비동기(Asynchronous)

구분 동기(Synchronous) 비동기(Asynchronous)

처리 방식	요청 → 응답 완료까지 대기	요청 후 즉시 반환, 결과는 나중에 처리
예시	함수 호출, REST API	콜백 함수, 이벤트 큐, Kafka
장점	구현 단순, 흐름 예측 쉬움	사용자 응답 속도 향상, 시스템 확장성 우수
단점	병목 발생 가능, 서버 부하 증가	흐름 추적 복잡, 장애 처리 고려 필요
사용 예	사용자 인증, 결제 등	로그 저장, 알림 처리, 비동기 이메일 발송

🔁 예시

[동기 방식]
클라이언트 → 서버에 요청 → 응답 받을 때까지 대기 → 다음 처리

[비동기 방식]
클라이언트 → 서버에 요청 → 응답 대기 없이 바로 다음 로직 수행
                    ↘ (결과는 메시지 큐 등으로 별도 전달)

 

---

✅ 메시지 브로커(Message Broker)란?

서로 독립적인 시스템 간 데이터를 전달해주는 중간 매개체

💬 언제 메시지 브로커를 쓸까?

• 비동기 알림 처리: 댓글, 채팅 알림 등 빠른 응답 + 느린 처리 분리
• 로그 처리/이벤트 스트리밍: 사용자 행동 분석, Clickstream 처리
• 시스템 간 통합: 서로 다른 서비스 간 데이터 전달 (예: 주문 → 결제 시스템)
• 장애 복구 고려: 처리 실패 시 재전송 및 메시지 적재 가능

🎯 메시지 브로커의 역할

• 생산자(Producer) → 메시지 생성 및 발행
• 브로커(Broker) → 메시지를 수신하고 보관 (예: Kafka, RabbitMQ)
• 소비자(Consumer) → 메시지를 비동기로 구독하고 처리

🔄 주요 특징

항목 설명

비동기 처리	요청과 응답이 분리되어 독립적으로 처리 가능
내결함성(Fault Tolerance)	메시지가 브로커에 일시 저장되므로 장애 시 재처리 가능
확장성	다수의 Consumer가 메시지를 병렬로 처리 가능
느슨한 결합	Producer ↔ Consumer 간 직접 의존성 없음

---

🔍 메시지 브로커별 장단점, 추천 사용 상황 및 프로젝트 규모

브로커 장점 단점 추천 사용 예 적합한 프로젝트 규모

종류	장점	단점	사용 사례	적합한 환경
Kafka	초고속 처리량, 대용량 스트리밍, 메시지 내구성 강함	운영 복잡도, 실시간성이 약간 느릴 수 있음	실시간 로그, Clickstream, 이벤트 소싱, 대용량 데이터 파이프라인	대규모 시스템, 데이터 중심 아키텍처, 마이크로서비스 기반 환경
RabbitMQ	다양한 라우팅 방식(Fanout, Topic 등), 메시지 우선순위 설정 가능	브로커 상태가 복잡할 수 있음, 처리량은 Kafka보다 낮음	단순한 큐잉, 알림 전파, 업무 시스템 메시징, RPC 스타일 통신	중소 규모 서비스, 워크플로우 기반 시스템, 유연한 메시징 필요 환경
Redis Pub/Sub	지연 시간 매우 짧음, 설정 단순, 의존성 최소화	메시지 내구성 없음(구독 중에만 수신 가능)	단순한 내부 이벤트 브로드캐스트, 캐시 기반 메시지 전파	소규모 서비스, 내부 통신, 빠른 알림 트리거 환경
Amazon SQS	완전 관리형, 확장성 뛰어남, 운영 필요 없음	실시간 처리에 적합하지 않음, 기본 큐는 순서 보장 없음	클라우드 기반 백오피스 처리, 느긋한 작업 큐, 비용 효율적 처리	클라우드 중심의 스타트업, 관리 부담 줄이고 싶은 중소 규모 서비스