메시지를 중심으로 보는 설계의 정의

오늘날 대부분의 기기는 네트워크에 연결되어 있습니다.

단순히 데이터를 주고받는 수준을 넘어서, 각 기기는 실시간으로 메시지를 처리하고, 사용자와 상호작용하며, 하나의 ‘행위자’로 시스템 내에 존재하고 있습니다.

이러한 변화는 시스템의 구성 방식에도 큰 영향을 미치고 있습니다.

과거에는 기능 단위를 호출로 연결하는 구조가 주를 이루었지만, 지금은 수많은 기기들이 비동기적이고 느슨하게 연결된 구조를 필요로 하며, 메시지를 중심으로 하는 설계 방식이 점차 요구되고 있습니다.

저는 이 변화의 흐름 속에서 ‘메시지’라는 개념에 주목하고 있습니다.

메시지는 단순한 전송 단위가 아니라, 시스템 간의 상호작용을 정의하고 흐름을 구성하는 중요한 설계 요소입니다.

이 글에서는 메시지를 중심에 두는 시스템 설계가 어떤 의미를 가지는지, 그리고 그러한 관점이 실제 설계에서 어떤 차이를 만들어내는지를 정리하고자 합니다.

모든 기기가 브라우저가 되어가는 시대

최근 들어 디지털 기기들은 단순한 명령 수신기나 데이터 수집기를 넘어, 네트워크 상에서 실시간으로 반응하고 메시지를 주고받는 참여자로 변화하고 있습니다.

센서, 컨트롤러, 가전제품, 산업용 장비 등은

단지 동작을 수행하는 대상이 아니라, 자체적으로 상태를 표현하고, 외부와 통신하며, 시스템 전반에 영향을 주는 의미 있는 노드로 자리잡고 있습니다.

이러한 변화의 중심에는 ‘브라우저화’라는 흐름이 있습니다.

브라우저는 더 이상 사용자 인터페이스의 끝단이 아니라, WebSocket, MQTT over WebSocket, SSE 등의 기술을 통해 실시간 메시지 흐름에 직접 참여할 수 있는 클라이언트 플랫폼으로 확장되고 있습니다.

이제 많은 기기들이 브라우저처럼 동작합니다.

스스로 메시지를 구독하고, 조건에 따라 발행하며, 데이터를 받아 표현하거나 상태를 갱신합니다.

이는 곧, 모든 기기가 실시간 메시지 네트워크의 일원이 되어가고 있다는 의미입니다.

기기의 수는 계속해서 증가하고 있으며, 웹, 모바일, 임베디드, 엣지 디바이스 등 다양한 형태로 분산된 클라이언트들이 동시에 연결되어 움직이고 있습니다.

이러한 환경에서 시스템은 더 이상 정해진 흐름대로 작동하는 고정된 구조로는 유지되기 어렵습니다.

그 대신, 메시지를 중심으로 구성된 유연한 흐름과 분산된 참여자 간의 느슨한 연결이 필요하게 되었습니다.

이 글은 이러한 시대적 흐름 속에서, 시스템을 메시지를 중심으로 다시 바라보고 설계한다는 것이 어떤 의미를 가지는지

차례대로 풀어보고자 합니다.

시스템은 구조적으로 분산되고 있다

현대의 시스템은 하나의 일관된 환경 안에서 동작하지 않습니다.

클라이언트는 모바일, 웹, 엣지 디바이스 등으로 다양화되었으며, 서버 역시 클라우드, 온프레미스, 마이크로서비스 단위의 컴퓨팅 자원으로 분산되어 있습니다.

심지어 같은 시스템 내부에서도 서로 다른 기술, 언어, 인프라 환경을 사용하는 이질적인 구성 요소들이 공존하는 것이 일반적인 모습입니다.

이러한 물리적·논리적 분산 환경에서는 시간 지연, 연결 불안정, 처리 실패와 같은 상황을 예외가 아닌 기본값으로 수용해야 합니다.

다시 말해, 시스템은 항상 연결되어 있을 수 없으며, 요청은 즉시 처리되지 않을 수 있고, 응답은 예측할 수 없는 시점에 도착하거나 아예 생략될 수도 있습니다.

이러한 환경에서 고정된 요청-응답 구조는 한계에 봉착합니다.

시스템은 더 이상 순차적인 호출 관계로만 구성되어서는 안 되며, 각 구성 요소가 메시지를 통해 느슨하게 연결되고, 시간에 독립적으로 동작할 수 있는 구조가 되어야 합니다.

여기서 메시지는 단순한 통신 수단이 아닙니다.

메시지는 의도, 상태, 이벤트의 전달 단위이자, 분산된 요소 간의 상호작용을 가능하게 하는 설계적 연결 고리입니다.

그리고 이러한 메시지를 안정적으로 흐르게 하며, 필요 시 수집, 제어, 분배할 수 있는 인프라가 바로 메시지 브로커입니다.

결국 메시지 브로커는 단순한 미들웨어가 아니라, 분산된 시스템의 흐름을 유지하고 조율하는 핵심 구조로 자리잡아야 합니다.

메시지를 먼저 바라보면 달라지는 것들

기능 중심으로 시스템을 바라보는 기존의 방식은 구조를 먼저 정의하고, 이후 그 흐름에 맞춰 통신을 설계하는 방식입니다.

하지만 메시지를 먼저 바라보면, 시스템은 전혀 다른 시각으로 보이기 시작합니다.

1. 흐름이 먼저 보이고, 구조는 따라옵니다

메시지를 중심에 두면, 먼저 시스템이 어떤 메시지를 주고받으며 동작해야 하는지가 보입니다.

기능은 그 메시지 흐름을 구현하기 위한 단위로 정리됩니다.

즉, 구조는 고정된 틀이 아니라 메시지라는 흐름 위에 얹혀지는 결과물이 됩니다.

이로 인해 시스템 전체의 맥락이 선명해지고, 각 기능의 역할과 경계도 명확해집니다.

2. 결합이 줄고, 실험이 쉬워집니다

메시지 단위로 컴포넌트를 구분하면 기능 간의 직접적인 호출 관계가 사라지고, 발행과 구독을 통한 느슨한 연결이 가능해집니다.

이러한 구조는 새로운 기능을 기존 코드에 영향을 주지 않고 추가하거나 제거할 수 있게 하며, 작은 단위의 실험과 폐기를 안전하게 수행할 수 있는 기반이 됩니다.

이는 곧 메시지를 중심에 둔 설계가 삭제 준비(Expiry-Ready)된 코드로 이어지는 이유이기도 합니다.

메시지를 기준으로 흐름을 분리하면, 특정 기능을 생성부터 제거까지 독립적으로 관리할 수 있습니다.

3. 운영과 확장이 유연해집니다

모든 메시지 흐름이 구조적으로 드러나기 때문에, 이벤트를 추적하거나 상태를 관찰하기 쉬워집니다.

운영 중 발생하는 이슈에 대해 흐름 단위로 대응하거나, 개별 메시지 단위로 제어하는 것도 가능합니다.

또한 새로운 구독자를 메시지 브로커에 연결하기만 하면 기존 시스템을 변경하지 않고도 확장이 가능합니다.

이는 메시지 중심 설계가 운영과 확장 모두에서 유연성을 제공한다는 것을 보여줍니다.

4. 메시지를 설계한다는 것은, 시스템의 대화를 정의하는 일입니다

저는 메시지를 단순한 데이터 포맷이 아닌, 시스템 간의 대화 방식으로 이해합니다.

대화는 호출과 다릅니다.

순서가 보장되지 않더라도 이해할 수 있어야 하고, 때로는 기억되거나 무시될 수도 있어야 합니다.

메시지는 이러한 불완전하고 유연한 상호작용을 수용할 수 있는 구조를 제공합니다.

그래서 저는 시스템을 구성할 때, 무엇을 호출할지보다 어떤 메시지가 오가야 하는지를 먼저 설계합니다.

브로커는 흐름의 중심이 되어야 한다

메시지를 중심에 두고 시스템을 바라보면, 브로커는 단순한 전송 장치가 아니라

흐름을 조율하고 분리하는 핵심 구조로 보이게 됩니다.

브로커는 시스템 내부의 상호작용을 하나의 통로로 연결하면서도, 각 구성 요소를 서로 독립적으로 유지할 수 있게 해줍니다.

1. 연결을 분리하고 흐름을 통합합니다

브로커는 발신자와 수신자를 직접 연결하지 않습니다.

그 사이에서 메시지를 중계함으로써, 각 구성 요소가 서로를 몰라도 동작할 수 있는 구조를 만듭니다.

이러한 구조는 시스템의 유연성을 높여주며, 새로운 기능을 추가하거나 기존 기능을 교체하는 과정을 더 단순하게 만듭니다.

2. 흐름을 수집하고 제어할 수 있습니다

모든 메시지가 브로커를 통과한다는 것은, 시스템의 모든 움직임이 하나의 흐름 단위로 관찰 가능하다는 뜻입니다.

이를 통해 다음과 같은 통제 지점을 만들 수 있습니다:

• 메시지 필터링 및 라우팅
• 이벤트 로깅 및 추적
• QoS 적용 및 흐름 제어
• 일시적인 차단, 우선순위 처리 등

브로커는 단지 통신 경로가 아니라, 시스템의 대화 흐름을 관찰하고 제어할 수 있는 운영 지점이 됩니다.

3. 설계를 메시지 중심으로 이끕니다

브로커를 중심에 두면, 시스템은 기능 중심이 아닌 흐름 중심으로 구성됩니다.

이는 전체 구조를 더 단순하고 유연하게 만들며, 메시지라는 단위로 기능을 해석할 수 있게 해줍니다.

호출 기반의 인터페이스는 수직적인 계층을 구성하지만, 브로커 기반의 메시징은 수평적 구조 위에서의 상호작용을 가능하게 합니다.

이는 곧 시스템 전체의 관계 구조를 더 명확하고 느슨하게 만들어줍니다.

4. 변화 가능성을 수용하는 구조입니다

시스템은 항상 변화합니다.

새로운 기능이 추가되거나, 일시적인 실험이 수행되거나, 기존 기능이 제거되는 일은 자연스럽게 반복됩니다.

브로커는 이러한 변화에 대비할 수 있는 구조적 완충 지대입니다.

새로운 흐름을 추가할 때 기존 코드에 영향을 주지 않고, 실패하거나 종료된 기능은 메시지 흐름만 정리하면 제거할 수 있습니다.

이러한 특성은 메시지를 중심으로 구성된 시스템이 변화와 실험을 자연스럽게 수용할 수 있는 이유가 됩니다.

EMQX는 가능성을 품고 있는 실험 공간이다

지금까지 메시지를 중심으로 시스템을 바라보는 이유와 구조적 장점에 대해 설명드렸습니다.

이제 이러한 구조를 실제로 실현하기 위해서는, 그 흐름을 수용하고 중계할 수 있는 브로커가 필요합니다.

저는 이 지점에서 EMQX라는 MQTT 기반 브로커에 주목하고 있습니다.

EMQX는 단순한 MQTT 브로커 그 이상을 지향하며, 분산 환경에서 메시지 중심 설계를 실현할 수 있는 유연한 실험 공간을 제공합니다.

1. 웹 친화적입니다

EMQX는 MQTT뿐만 아니라 MQTT over WebSocket을 기본적으로 지원합니다.

이를 통해 브라우저 기반 클라이언트도 실시간 메시지 네트워크에 직접 참여할 수 있습니다.

웹과 IoT 장비가 동일한 메시지 흐름 안에서 유기적으로 통신할 수 있는 환경을 제공합니다.

2. 이식성과 확장성이 뛰어납니다

경량화된 클러스터 구조, 다양한 클라이언트 라이브러리 지원, 클라우드와 엣지 환경 모두에 배포 가능한 구조 덕분에, EMQX는 플랫폼 제약 없이 적용이 가능합니다.

운영 환경이 작든 크든, 실험부터 상용까지 이어지는 과정에 유연하게 대응할 수 있습니다.

3. 메시지 흐름을 정책으로 다룰 수 있습니다

EMQX는 메시지 흐름에 대해 다양한 정책 기반 설정과 필터링, 인증 제어 기능을 제공합니다.

이는 메시지 브로커를 단순한 중계기가 아닌, 설계와 운영의 규칙을 담는 실행 환경으로 활용할 수 있게 합니다.

메시지를 정의하고, 그 흐름을 설계하고, 그 흐름을 통제하며 운영할 수 있는 공간.

EMQX는 그 자체로 하나의 설계 실험실이자 관찰 지점이 됩니다.

4. 실험과 폐기가 가능한 구조를 만들어 줍니다

새로운 흐름을 붙이고, 임시 구독자를 구성하고, 성공하거나 실패한 기능을 제거하는 일련의 사이클은

EMQX 위에서 복잡한 재구성 없이 수행할 수 있습니다.

이는 앞서 말한 메시지 중심 설계의 핵심 철학인 “삭제 준비(Expiry-Ready)된 코드”와 “유연한 구조”를 실현할 수 있게 해주는 기반이 됩니다.

반드시 EMQX일 필요는 없다

저는 EMQX를 통해 메시지 중심 설계를 실현하고 있지만,

이 글의 목적은 특정 도구를 권장하거나, EMQX만이 유일한 해답이라고 주장하려는 것이 아닙니다.

중요한 것은 메시지를 구조의 출발점으로 삼는 관점이며, EMQX는 그 관점을 실현할 수 있는 유력한 수단 중 하나일 뿐입니다.

기술은 계속해서 바뀝니다

앞으로 더 나은 도구나 방식이 등장할 수 있습니다.

WebTransport, QUIC 기반의 새로운 메시징 프로토콜, 혹은 브라우저 자체가 브로커 역할을 수행하는 새로운 모델이 등장할 가능성도 충분히 존재합니다.

그런 변화는 자연스러운 흐름이며, 중요한 것은 그러한 변화에 유연하게 적응할 수 있는 구조와 관점을 갖추는 일입니다.

저는 구조를 먼저 보고 도구를 선택합니다

기술은 수단입니다.

어떤 도구든 그 구조적 목적을 실현할 수 있다면 선택의 여지는 열려 있습니다.

제가 EMQX를 선택한 이유는 그 구조가 지금 제가 설계하고자 하는 흐름과 철학에 가장 부합했기 때문입니다.

하지만 다른 환경, 다른 조건에서는 다른 도구가 더 적합할 수도 있습니다.

결국 중요한 것은 도구의 이름이 아니라, 그 도구가 어떤 구조를 가능하게 하느냐입니다.

유연한 태도가 구조적 사고를 지켜줍니다

도구에 집착하면 기술 변화에 취약해집니다.

반면 구조에 집중하면 도구는 바뀌어도 설계의 방향은 유지됩니다.

저는 설계자이자 개발자로서, 항상 도구보다 구조를 먼저 바라보는 태도를 유지하고자 합니다.

이 글에서 EMQX를 이야기하고 있지만, 그 이면에는 메시지를 중심으로 흐름을 정의하고자 하는 설계자의 사고와 기준이 자리하고 있습니다.

마무리: 메시지를 설계한다는 것

시스템을 설계한다는 것은 흐름을 정의하는 일입니다.

흐름은 단순한 기능의 순서가 아니라, 의도가 전달되고 반응이 발생하며 상태가 바뀌는 전체적인 상호작용입니다.

저는 이 흐름의 중심에 메시지를 둡니다.

메시지는 호출보다 유연하고, 상태보다 의미에 가깝습니다.

메시지는 시스템을 구성하는 요소들을 서로 느슨하게 연결하면서도, 구조적으로 조율할 수 있는 단위가 되어줍니다.

메시지를 설계한다는 것은 구조를 정의하는 일입니다

기능을 설계하는 것보다 먼저, 시스템이 어떤 메시지를 주고받아야 하는지를 정의합니다.

그 과정에서 자연스럽게 참여자 간의 경계, 역할, 흐름의 방향성이 드러납니다.

결국 메시지를 설계한다는 것은, 시스템이 어떤 방식으로 움직이고 소통할지를 먼저 결정하는 일입니다.

구조는 그 뒤를 따라오며, 도구는 그 구조를 실현하는 수단이 됩니다.

메시지는 시스템의 언어입니다

시스템은 외부와 내부 모두와 소통해야 합니다.

그 소통의 언어가 메시지입니다.

저는 이 언어가 명확하고, 관찰 가능하며, 삭제 준비되어야 한다고 생각합니다.

그러한 메시지 기반 구조는 실험과 변화, 확장과 축소, 실패와 복구를 모두 포용할 수 있는 유연한 시스템을 만듭니다.

마치며

이 글은 EMQX를 소개하기 위한 글이 아닙니다.

저는 메시지를 중심으로 시스템을 바라보는 관점을 공유하고자 했습니다.

그리고 그 관점을 실현하기 위한 하나의 실험 공간으로서 EMQX를 선택했을 뿐입니다.

시스템이 복잡해질수록 구조는 단순하고 견고해야 합니다.

그 구조를 구성하는 가장 작은 단위가 메시지라면, 저는 그 메시지를 가장 먼저 설계하겠습니다.