'syncOnCommand' 옵션이 데이터 무결성에 미치는 영향은?

'syncOnCommand' 옵션이 데이터 무결성에 미치는 영향은?

엔터프라이즈 메시징 시스템(ActiveMQ 등)은 단일 TCP 커넥션을 통해 초당 수만 건의 메시지를 비동기적으로 주고받는 극단적인 I/O 환경에서 동작합니다. 클라이언트 애플리케이션의 수많은 스레드가 동시에 메시지를 보내고, 동시에 브로커로부터 응답이나 새로운 메시지를 받아내는 과정에서 데이터의 순서가 뒤섞이거나 클라이언트 내부의 상태(State)가 오염되는 것을 막기 위한 정교한 락(Lock) 메커니즘이 필수적입니다.

이러한 네트워크 계층의 동시성을 제어하는 가장 깊숙하고 강력한 옵션 중 하나가 바로 전송(Transport) 설정에 숨겨져 있는 syncOnCommand 파라미터입니다. 이 가이드에서는 이 옵션이 클라이언트와 브로커 간의 데이터 무결성(Data Integrity)을 어떻게 사수하는지, 그리고 그 대가로 어떤 치명적인 성능적 희생을 요구하는지 상세히 해부합니다.

---

1. MutexTransport와 연결의 동시성 제어 (기초)

옵션의 영향을 이해하려면 먼저 ActiveMQ가 네트워크 커넥션을 보호하기 위해 사용하는 MutexTransport 계층을 이해해야 합니다.

클라이언트에서 여러 스레드가 동시에 send()를 호출하여 메시지를 보내려 한다고 가정해 보겠습니다. 이 요청들이 락(Lock) 없이 소켓으로 직행한다면, A 메시지의 바이트 조각과 B 메시지의 바이트 조각이 네트워크 선로 위에서 뒤섞여(Interleaving) 데이터 스트림이 완전히 파괴될 것입니다.

이를 막기 위해 MutexTransport는 내부에 writeLock이라는 배타적 잠금 장치를 두고 있습니다. 메시지를 브로커로 전송(송신)하려는 모든 스레드는 먼저 이 락을 획득해야 하며, 한 스레드의 전송이 완전히 끝날 때까지 다른 스레드들은 대기열에서 기다리게 됩니다. 이를 통해 송신(Outbound) 데이터의 무결성은 완벽하게 보장됩니다.

---

2. 'syncOnCommand'의 활성화: 반이중(Half-Duplex)으로의 전환

기본적으로 브로커에서 클라이언트로 들어오는 수신(Inbound) 메시지를 읽어 들이는 스레드(onCommand)는 위에서 언급한 writeLock의 영향을 받지 않습니다. 즉, 클라이언트가 데이터를 전송(Write)하는 와중에도 브로커가 보낸 메시지를 수신(Read)하여 처리하는 작업은 동시에 이루어지는 전이중(Full-Duplex) 통신으로 동작하여 성능을 극대화합니다.

하지만 커넥션 옵션에 syncOnCommand=true를 부여하는 순간, 아키텍처의 패러다임이 완전히 뒤바뀝니다.
브로커로부터 새로운 메시지나 응답 명령(Command)을 수신한 읽기 스레드는 클라이언트 내부 로직으로 이 명령을 전달하기 전에 반드시 송신 스레드들이 사용하는 것과 동일한 writeLock을 획득하도록 강제됩니다.

결과적으로 송신과 수신이 완전히 상호 배타적(Mutually Exclusive)으로 동작하게 되며, 통신 파이프라인은 한 번에 한 방향으로만 데이터가 흐를 수 있는 무전기 같은 반이중(Half-Duplex) 상태로 전환됩니다.

---

3. 데이터 무결성 측면에서의 절대적 이점

성능을 희생하면서까지 이 옵션을 켜야 하는 아키텍처적 이유는 무엇일까요? 바로 시스템 장애 상황이나 멀티스레드 환경에서 클라이언트 내부 상태의 '완벽한 정합성'을 지켜내기 위함입니다.

• 내부 상태 경합(Race Condition)의 원천 차단: 클라이언트 라이브러리는 브로커로부터 트랜잭션 롤백, 커넥션 제어 명령, 또는 특정 메시지에 대한 ACK를 수신할 때 자신의 내부 메모리 상태(Transaction Map, Session State 등)를 업데이트합니다. 만약 다른 스레드가 새로운 메시지를 보내며 이 상태를 동시에 수정하려 든다면, 미세한 타이밍 차이로 인해 내부 자료구조가 꼬이거나 ConcurrentModificationException이 발생할 수 있습니다. syncOnCommand는 송신과 수신 로직이 동시에 실행되는 것 자체를 물리적으로 차단하여 이러한 경합을 100% 제거합니다.
• 스트림의 완벽한 인과율 보장 (Strict Serialization): 클라이언트가 메시지를 보내는 행위와 브로커의 명령을 받는 행위가 일렬로 직렬화(Serialization)됩니다. 전송이 진행 중일 때는 브로커의 그 어떤 간섭도 클라이언트 로직에 도달하지 못하므로, 애플리케이션 입장에서는 데이터 흐름의 순서와 인과관계를 예측하고 통제하기가 매우 수월해집니다.
• 커넥션 종료(Teardown) 시의 안전성: 네트워크 불안정으로 브로커가 예외(Exception) 명령을 내려보냈을 때, 수신 스레드는 커넥션을 닫는 정리 작업을 시작합니다. 이 옵션이 켜져 있으면 다른 스레드들이 닫히고 있는 소켓에 메시지를 밀어 넣으려다 발생하는 파생 에러(Secondary Exception)들을 원천 차단하여 깔끔한 리소스 회수가 가능해집니다.

---

4. 도입 시 감수해야 할 치명적인 성능 트레이드오프

데이터 무결성 측면에서는 무결점의 방패지만, 이 옵션을 프로덕션 환경에 무턱대고 적용하면 인프라에 재앙이 닥칠 수 있습니다.

• 메인 스레드 블로킹(Thread Blocking)의 연쇄 반응: 브로커로부터 메시지가 도착하여 클라이언트의 MessageListener.onMessage() 콜백 로직이 실행되는 동안, 읽기 스레드는 writeLock을 계속 쥐고 있게 됩니다. 만약 비즈니스 로직(데이터베이스 저장, 외부 API 호출 등) 처리에 5초가 걸린다면, 그 5초 동안 해당 커넥션을 통해 다른 메시지를 전송하려는 클라이언트의 모든 스레드는 그 자리에 멈춰서(Blocked) 하염없이 기다려야 합니다.
• 초당 처리량(Throughput)의 극단적 저하: 수만 건의 메시지를 쏟아붓고 브로커의 ACK를 비동기로 받아내는 최신 비동기 파이프라인의 이점을 전혀 사용할 수 없습니다. 송신과 수신이 서로의 발목을 잡으며 시스템 전체의 병목 구간으로 전락하게 됩니다.

---

5. 언제 이 옵션을 고려해야 하는가? (운영 가이드)

현대의 고성능 마이크로서비스(MSA) 아키텍처에서는 이 옵션을 기본값인 false로 두고 사용하지 않는 것이 대원칙입니다. 최신 메시지 브로커 클라이언트 라이브러리들은 이미 내부 자료구조를 스레드 세이프(Thread-safe)하게 잘 관리하고 있어 수신과 송신이 겹치더라도 데이터가 오염되지 않기 때문입니다.

하지만, 레거시 시스템과 연동하기 위해 클라이언트 코드를 직접 커스텀 래핑(Wrapping)했거나, 멀티스레드 환경에서 원인 불명의 데이터 오염이나 예외(NullPointerException 등)가 간헐적으로 발생할 때 트러블슈팅을 위한 강력한 격리 조치로 이 옵션을 활용할 수 있습니다. 처리 속도보다 데이터의 순서와 상태 무결성이 0.001%의 오차도 없이 일치해야 하는 폐쇄망의 특수 금융 트랜잭션 등에서만 매우 제한적으로 아키텍처에 도입하시기 바랍니다.