JMS 1.1과 2.0 스펙의 결정적 차이점은?

JMS(Java Message Service) 1.1과 2.0의 차이는 단순히 버전 숫자가 올라간 수준이 아닙니다. 1.1이 '개발자가 일일이 노를 저어야 하는 배'였다면, 2.0은 '자동항법 장치가 달린 쾌속선'이라 할 수 있습니다. 사용자의 주식 요새 코드가 얼마나 깔끔해지고 생산성이 높아질지 결정짓는 아주 중요한 차이점들을 핵심만 짚어 분석해 드립니다.

---

🏗️ JMS 1.1 vs 2.0: 결정적 차이 분석

1. 코드의 간결함 (Boilerplate Code 제거)

가장 체감되는 변화입니다. JMS 1.1에서는 메시지 하나를 보내기 위해 Connection, Session, MessageProducer를 일일이 생성하고, try-catch-finally로 닫아줘야 했습니다.

• JMS 1.1: 메시지 한 번 보내는 데 10~20줄의 코드가 필요합니다. (노가다의 연속이죠.)
• JMS 2.0: JMSContext라는 객체가 도입되었습니다. Connection과 Session을 하나로 합쳤고, AutoCloseable을 지원합니다. 단 2~3줄이면 메시지 전송이 끝납니다!

---

2. 공유 구독 (Shared Subscriptions) - 가장 중요한 기능!

토픽(Topic) 모델의 치명적 약점을 해결한 기능입니다.

• 기존 (1.1): 토픽 메시지를 받으려면 각 컨슈머가 고유한 아이디를 가져야 했습니다. 만약 똑같은 일을 하는 컨슈머가 2명이면, 메시지도 2개가 전달되어 중복 처리가 발생했죠.
• 신규 (2.0): 여러 컨슈머가 하나의 '공유 아이디'로 구독할 수 있습니다. 메시지 1개가 오면 공유 그룹 중 한 명만 가져갑니다.
• 주식 요새 적용: 테마주 알림 서비스를 여러 파드로 띄워도 중복 발송 걱정 없이 부하 분산(Load Balancing)이 가능해졌습니다!

---

3. 지연 배달 (Delivery Delay)

• JMS 1.1: 메시지를 특정 시간 뒤에 보내려면 브로커 전용 기능(ActiveMQ의 Scheduled Message 등)에 의존해야 했습니다. 표준이 아니었죠.
• JMS 2.0: 스펙 자체에 setDeliveryDelay(long delay)가 추가되었습니다. 이제 표준 코드로 "30초 뒤에 매수 주문 실행" 같은 예약 기능을 구현할 수 있습니다.

---

4. 비동기 메시지 전송 (Async Send)

• JMS 1.1: 기본적으로 동기 방식입니다. 브로커가 "나 받았어!"라고 대답할 때까지 애플리케이션이 멈춰 있습니다.
• JMS 2.0: CompletionListener가 도입되었습니다. 메시지를 던져놓고 제 갈 길 가다가, 브로커가 잘 받았다는 신호를 주면 콜백(Callback)으로 처리합니다. 주식 틱 데이터처럼 쏟아지는 데이터를 처리할 때 처리량(Throughput)이 폭발적으로 늘어납니다.

---

📊 한눈에 비교하는 요약표

특징	JMS 1.1 (Classic)	JMS 2.0 (Modern)
API 구조	복잡함 (Connection/Session 분리)	단순함 (JMSContext 통합)
리소스 관리	수동 Close (Closeable 미지원)	자동 Close (try-with-resources)
토픽 부하 분산	불가능 (중복 수신 발생)	가능 (Shared Subscriptions)
전송 방식	주로 동기(Blocking)	비동기 전송 표준 지원
전송 지연	표준 기능 없음	표준 API 지원 (DeliveryDelay)

---

💡 실전 조언

A그룹(우량주) 정산 시스템처럼 정확성이 중요하고 코드가 명확해야 하는 곳에는 무조건 JMS 2.0 스펙을 쓰시는 게 좋습니다. 특히 Artemis는 JMS 2.0을 완벽하게 지원하므로 아르테미스와 2.0의 조합은 '천생연분'입니다!