메시지 큐란?
메시지 큐는 시스템 사이에서 메시지를 비동기적으로 주고받기 위한 통신 방식이다. 메시지를 만드는 쪽은 큐에 메시지를 넣고, 처리하는 쪽은 큐에서 메시지를 꺼내 작업한다. 두 컴포넌트가 같은 시간에 직접 연결되어 있을 필요가 없기 때문에, 시스템 간 결합도를 낮추고 장애 전파를 줄이는 데 도움이 된다.
예를 들어 주문이 들어왔을 때 결제, 알림, 재고 차감, 로그 적재를 모두 한 요청 안에서 처리하면 응답 시간이 길어지고 한 기능의 장애가 전체 요청에 영향을 줄 수 있다. 이때 주문 서비스는 “알림을 보내라”는 메시지만 큐에 넣고 바로 응답할 수 있다. 알림 서비스는 자기 속도에 맞게 메시지를 가져가 처리하면 된다.
메시지 큐의 핵심 장점은 비동기 처리, 트래픽 완충, 느슨한 결합이다. 갑자기 요청이 많이 들어와도 큐가 버퍼 역할을 하므로 소비자가 감당 가능한 속도로 처리할 수 있다. 또한 생산자는 소비자의 내부 구현을 몰라도 되고, 소비자는 생산자의 요청 흐름과 분리되어 독립적으로 확장할 수 있다.
사용할 때 주의할 점
메시지 큐를 사용하면 요청이 “전송됐다”는 사실과 “정상 처리됐다”는 사실이 분리된다. 그래서 비동기 구조에서는 에러 처리와 재처리 전략을 반드시 정해야 한다. 메시지를 큐에 넣는 데 성공했는지, 소비자가 메시지를 처리했는지, 처리에 실패했다면 다시 시도할 것인지를 명확히 해야 한다.
일시적인 네트워크 장애나 외부 API 오류라면 재시도가 효과적이다. 보통 재시도 횟수와 간격을 제한하고, 계속 실패하는 메시지는 별도의 Dead Letter Queue에 보내 원인을 확인한다. 반대로 단순 로그처럼 유실되어도 큰 문제가 없는 메시지는 실패를 기록하고 넘어갈 수도 있다.
중요한 메시지라면 알림과 수동 처리 절차도 필요하다. 자동 재처리만으로 해결되지 않는 데이터 오류나 비즈니스 예외가 생길 수 있기 때문이다. 이런 경우 운영자가 메시지 내용과 실패 원인을 보고 직접 보정하거나 재처리할 수 있어야 한다.
또 하나 중요한 점은 중복 처리다. 많은 메시지 큐는 장애 상황에서 at-least-once 전달을 선택한다. 이 방식은 메시지가 적어도 한 번은 처리되도록 보장하지만, 같은 메시지가 두 번 전달될 가능성도 있다. 따라서 소비자는 같은 메시지를 다시 받아도 결과가 깨지지 않도록 멱등성을 고려해야 한다.
구성할 때 고려할 것
메시지 큐를 도입할 때는 성능만 보면 안 된다. 메시지를 디스크에 저장해 장애 후에도 복구할 것인지, 메모리 중심으로 빠르게 처리할 것인지부터 결정해야 한다. 영속성을 높이면 안정성은 좋아지지만 지연 시간과 처리량에 영향을 줄 수 있다.
큐에 메시지가 계속 쌓이는 상황도 대비해야 한다. 소비자 처리 속도가 생산자 속도를 따라가지 못하면 pending 메시지가 늘어나고, 결국 메모리 부족이나 지연 증가로 이어질 수 있다. 모니터링에서는 큐 길이, 소비 지연, 실패 횟수, 재시도 횟수를 함께 봐야 한다.
트랜잭션과 순서 보장도 요구사항에 따라 달라진다. 모든 메시지의 순서가 중요한지, 특정 키 안에서만 순서가 중요하면 되는지에 따라 설계가 달라진다. 클러스터링과 페일오버 역시 운영 환경에서는 필수적으로 검토해야 한다.
정리하면 메시지 큐는 느슨한 결합과 안정적인 비동기 처리를 위한 좋은 도구지만, 넣기만 하면 자동으로 안전해지는 기술은 아니다. 재처리, 중복 처리, 모니터링, 장애 복구 전략까지 함께 설계해야 실무에서 안정적으로 사용할 수 있다.