가상 토픽 사용 시 물리적 큐의 명명 규칙은?

가상 토픽(Virtual Topics) 시스템에서 물리적 큐의 명명 규칙은 단순한 이름 짓기 이상의 의미를 갖습니다. 이는 브로커 내부의 인터셉터(Interceptor)가 메시지를 라우팅하는 '규칙' 그 자체이기 때문입니다. 명명 규칙이 정확하게 일치하지 않으면 브로커는 토픽으로 들어온 메시지를 어떤 큐로 복제해야 할지 판단할 수 없게 되어 팬아웃(Fan-out) 기능이 작동하지 않습니다.

가상 토픽의 물리적 큐 명명 규칙은 기본 표준 설정과 사용자 정의 설정, 그리고 차세대 엔진인 Artemis에서의 주소 지정 모델로 나누어 상세히 분석할 수 있습니다.

1. 표준 가상 토픽 명명 규칙 (ActiveMQ 5.x 기준)

가상 토픽 시스템의 기본 설정에서 발행자(Publisher)와 수신자(Consumer)가 사용하는 데스티네이션 이름은 엄격한 계층 구조를 따릅니다.

가장 먼저 발행자가 메시지를 전송하는 토픽의 이름은 반드시 VirtualTopic.이라는 접두사로 시작해야 합니다. 예를 들어 주문 시스템에서 발생하는 이벤트를 가상 토픽으로 처리한다면, 토픽의 이름은 VirtualTopic.Orders가 됩니다. 여기서 VirtualTopic. 뒤에오는 Orders 부분이 실제 비즈니스 도메인을 나타내는 식별자가 됩니다.

수신자가 이 메시지를 받기 위해 생성하거나 연결해야 하는 물리적 큐의 이름은 기본적으로 Consumer.<ClientId>.<VirtualTopicName> 형식을 따릅니다.

• Consumer: 가상 토픽 인터셉터가 이 큐를 '가상 토픽의 수신용 큐'로 인식하게 만드는 예약된 접두사입니다.
• : 해당 메시지를 수신하는 애플리케이션이나 그룹의 식별자입니다. 예를 들어 재고 시스템이라면 Inventory, 배송 시스템이라면 Shipping 등이 들어갑니다.
• : 앞서 발행자가 메시지를 보낸 토픽의 전체 이름입니다. 여기서는 VirtualTopic.Orders가 됩니다.

결과적으로 재고 시스템이 주문 이벤트를 받기 위해 연결해야 하는 물리적 큐의 최종 이름은 Consumer.Inventory.VirtualTopic.Orders가 됩니다. 브로커는 이 큐의 이름을 해석하여, VirtualTopic.Orders 토픽으로 들어오는 모든 메시지를 이 큐로 복제하여 넣어줍니다.

2. 와일드카드를 활용한 계층적 명명 규칙

가상 토픽의 명명 규칙에서 가장 중요한 요소 중 하나는 와일드카드(Wildcard)의 활용입니다. 메시징 시스템은 점(.)을 구분자로 사용하여 계층을 나눕니다.

• 애스터리스크(*): 한 단계의 계층을 의미합니다.
• 부등호(>): 해당 지점 이후의 모든 하위 계층을 의미합니다.

브로커 설정 파일인 activemq.xml에서 가상 토픽 인터셉터는 보통 다음과 같이 정의됩니다.
<virtualTopic name="VirtualTopic.>" prefix="Consumer.*." selectorAware="false"/>

여기서 name="VirtualTopic.>"는 VirtualTopic으로 시작하는 모든 토픽을 가상 토픽으로 취급하겠다는 의미입니다. 즉, VirtualTopic.Orders, VirtualTopic.Payments.Success, VirtualTopic.Inventory.Update 등 모든 하위 도메인이 가상 토픽의 대상이 됩니다.

물리적 큐의 명명 규칙에 포함된 prefix="Consumer.*." 부분은 브로커가 메시지를 복제할 대상 큐를 찾는 패턴입니다. 여기서 * 부분에 들어오는 문자열이 무엇이든 간에, 그 뒤에 토픽 이름이 붙은 큐가 존재한다면 브로커는 그 큐를 유효한 수신처로 간주합니다.

3. 명명 규칙의 커스터마이징 (Custom Interceptor)

표준 명명 규칙이 조직의 명명 표준과 맞지 않는 경우, 브로커 설정을 통해 이를 변경할 수 있습니다. virtualDestinationInterceptor 설정 내에서 prefix와 postfix 속성을 조절하여 물리적 큐의 이름을 결정합니다.

예를 들어, 큐의 이름 앞에 Consumer.를 붙이는 대신 뒤에 .Queue를 붙이고 싶다면 다음과 같이 설정할 수 있습니다.
<virtualTopic name="Orders.>" prefix="" postfix=".Queue" />

이 설정이 적용되면 발행자가 Orders.New 토픽으로 메시지를 보낼 때, 수신자는 Orders.New.Queue라는 이름의 큐를 생성하여 메시지를 수신하게 됩니다. 그러나 실무에서는 여러 수신 그룹(Group)을 지원해야 하므로, 접두사에 그룹 식별자를 포함하는 표준 방식(Consumer.*.)이 가장 널리 권장됩니다.

4. ActiveMQ Artemis에서의 명명 규칙과 FQQN

차세대 엔진인 Artemis는 '주소(Address)'와 '큐(Queue)'를 분리하여 관리하는 모델을 사용합니다. Artemis에서 가상 토픽은 '주소'에 해당하며, 물리적 큐는 그 주소에 바인딩된 '큐' 객체가 됩니다.

Artemis 환경에서는 FQQN(Fully Qualified Queue Name)이라는 고유한 명명 형식을 사용하여 물리적 큐에 접근합니다. 형식은 address::queueName입니다.

가상 토픽 모델을 Artemis에서 구현할 때, 발행자는 OrdersTopic이라는 주소(Address)로 메시지를 보냅니다. 이때 수신 측의 물리적 큐 이름은 설정에 따라 달라지지만, 보통 OrdersTopic::InventoryQueue와 같은 형식을 갖게 됩니다.

Artemis는 기존 ActiveMQ 5.x의 가상 토픽 명명 규칙과의 호환성을 위해 VirtualTopic.과 Consumer.*. 패턴을 자동으로 해석하는 기능을 포함하고 있습니다. 하지만 내부적으로는 이를 주소와 큐의 매핑 관계로 치환하여 처리합니다.

5. 엔터프라이즈 환경에서의 명명 전략 베스트 프랙티스

대규모 마이크로서비스 아키텍처(MSA)에서 가상 토픽을 운영할 때는 충돌을 방지하고 관리 효율성을 높이기 위한 전략적인 명명 규칙이 필요합니다.

첫째, 서비스 도메인 중심의 계층 구조를 설계해야 합니다.
VirtualTopic.<Domain>.<SubDomain>.<Action> 형식을 권장합니다.
예: VirtualTopic.Logistics.Delivery.Started

둘째, 수신 그룹 명명 시 서비스 이름과 환경 정보를 포함합니다.
Consumer.<Service>-<Environment>.<VirtualTopicName>
예: Consumer.Billing-Prod.VirtualTopic.Logistics.Delivery.Started
이렇게 이름을 지으면 모니터링 도구에서 어떤 환경의 어떤 서비스가 메시지를 소비하고 있는지 즉각적으로 파악할 수 있습니다.

셋째, 대소문자 구분 및 특수문자 사용을 엄격히 제한합니다. 브로커 운영 체제나 데이터베이스 저장소 설정에 따라 대소문자를 구분하지 못하는 경우가 발생할 수 있으므로, 가급적 모든 이름을 소문자로 통일하고 구분자는 점(.)만 사용하는 것이 안전합니다.

6. 잘못된 명명 규칙이 유발하는 문제점

명명 규칙을 정확히 따르지 않았을 때 발생하는 가장 큰 문제는 '메시지 증발'과 '오브젝트 누수'입니다.

발행자가 VirtualTopic.Orders로 메시지를 보내는데 수신자가 Consumer.Inventory.Orders라는 이름으로 큐를 만들었다면(중간에 VirtualTopic이 빠진 경우), 브로커는 이 큐를 수신처로 인식하지 못합니다. 결과적으로 메시지는 어떤 큐로도 복제되지 않고 버려집니다.

반대로, 수신자가 큐를 생성한 후 애플리케이션을 종료하고 큐를 명시적으로 삭제하지 않으면, 브로커에는 Consumer.* 패턴의 큐가 영구적으로 남게 됩니다. 브로커는 설정된 명명 규칙에 따라 해당 큐가 살아있다고 판단하여 계속해서 메시지를 복제해 넣습니다. 이는 불필요한 디스크 사용량 증가와 성능 저하의 주범이 됩니다. 따라서 가상 토픽을 사용할 때는 큐의 이름뿐만 아니라 해당 큐의 생명주기(TTL)나 자동 삭제(Auto-delete) 정책을 함께 고려해야 합니다.

7. 가상 토픽 명명 규칙의 내부 동작 원리

브로커가 가상 토픽으로 들어온 메시지를 물리적 큐로 라우팅하는 내부 알고리즘은 다음과 같습니다.

1. 메시지 도착: 발행자가 VirtualTopic.A로 메시지를 보냅니다.
2. 패턴 매칭: 가상 토픽 인터셉터가 이 목적지가 VirtualTopic.> 패턴에 부합하는지 확인합니다.
3. 큐 검색: 브로커에 등록된 모든 데스티네이션 중 Consumer.*.VirtualTopic.A 패턴과 일치하는 '물리적 큐' 목록을 검색합니다. 이때 와일드카드 * 위치에는 어떤 문자열이 와도 상관없습니다.
4. 참조 복제: 검색된 모든 큐에 메시지 본문의 참조를 추가합니다.
5. 개별 배달: 각 큐는 연결된 컨슈머들에게 메시지를 독립적으로 배달합니다.

이 과정에서 보듯, 명명 규칙은 브로커가 3단계(큐 검색)를 수행하기 위한 '검색 키' 역할을 합니다. 명명 규칙이 복잡할수록 검색 오버헤드가 발생할 수 있으므로, 계층을 너무 깊게 타지 않는 것이 성능 최적화 측면에서 유리합니다.

8. 결론 및 요약

가상 토픽의 물리적 큐 명명 규칙은 "발행처의 토픽 이름 앞에 수신자 식별자를 포함한 특정 접두사를 붙여 큐를 생성하는 것"으로 요약됩니다.

• 발행처: VirtualTopic.[TopicName]
• 수신처: Consumer.[GroupName].VirtualTopic.[TopicName]

이 규칙을 준수함으로써 개발자는 별도의 브로커 설정 변경 없이도 새로운 수신 그룹을 동적으로 추가할 수 있으며, 큐가 제공하는 부하 분산과 메시지 영속성의 이점을 팬아웃 구조에서 완벽하게 누릴 수 있습니다. 엔터프라이즈 환경에서는 도메인 중심의 계층적 설계를 접목하여 명명 규칙의 가독성과 관리 편의성을 동시에 확보하는 것이 핵심입니다.