메시지 큐를 도입하면 어떤 장점과 복잡도가 생기나요?

메시지 큐는 생산자와 소비자를 분리해 비동기 처리와 부하 흡수를 돕습니다. 중복 처리, 순서 보장, 재시도, DLQ, idempotency 설계가 필요합니다.

핵심 개념

핵심 기준은 비동기 처리와 메시지 신뢰성입니다.

메시지 큐는 요청 처리와 후속 작업을 분리합니다. 주문 API는 주문 생성 후 이메일 발송이나 분석 이벤트를 큐에 넣고 빠르게 응답할 수 있습니다. 소비자는 자신의 속도로 처리하지만 메시지 중복, 순서, 재시도, DLQ, idempotency를 설계해야 합니다.

동작 흐름

1. 요구사항을 성능, 안정성, 보안, 복구 목표로 나눠 정의합니다.
2. 정상 흐름과 장애 흐름에서 각 구성 요소가 어떻게 동작하는지 확인합니다.
3. 자동화와 관찰 지표로 변경 결과를 검증합니다.
4. 롤백, 복구, 확장, 비용 관리까지 운영 절차로 문서화합니다.

실제 예시

await queue.publish('email.send', {
  messageId: 'order-confirmation:o-123',
  to: user.email,
});
// consumer는 messageId 기준으로 idempotent하게 처리

예시는 핵심 구조를 단순화한 것입니다. 실무에서는 운영 환경, 장애 상황, 보안 요구사항에 맞게 세부 설정을 조정해야 합니다.

실무에서 주의할 점

• 자동화가 있어도 롤백과 복구 절차를 실제로 연습하지 않으면 장애 때 동작하지 않을 수 있습니다.
• 관찰 지표가 없으면 장애 원인을 추측에 의존하게 됩니다.
• 확장은 애플리케이션 코드, 데이터베이스, 네트워크, 외부 의존성 한계를 함께 봐야 합니다.

함께 연결해서 보면 좋은 키워드

MessageQueue, Kafka, RabbitMQ, Idempotency

면접에서 짚으면 좋은 포인트

• 정상 동작뿐 아니라 장애, 롤백, 관찰 가능성까지 함께 설명하면 실무적인 답변이 됩니다.
• 설정 예시를 말할 때 보안, 비용, 운영 자동화의 trade-off도 함께 짚는 것이 좋습니다.

정리

한 줄로 정리하면, 메시지 큐는 생산자와 소비자를 분리해 비동기 처리와 부하 흡수를 돕습니다. 중복 처리, 순서 보장, 재시도, DLQ, idempotency 설계가 필요합니다. 개념의 정의뿐 아니라 장애 시 동작, 운영 지표, 자동화와 복구 전략까지 함께 이해하는 것이 중요합니다.