2.4 데이터 모델과 리소스 네이밍(Naming)

2.4 데이터 모델과 리소스 네이밍(Naming)

네트워크를 구성하는 인프라 노드들이 어떻게 연결되고(토폴로지) 데이터를 주고받는지(라우팅)를 살펴보았다면, 이제는 그 네트워크 위를 흘러 다니는 ‘데이터(Data)’ 그 자체의 본질을 규명할 차례이다.

전통적인 소켓(Socket) 통신이나 ROS 1의 통신 방식은 데이터를 주고받기 전에 수신자와 발신자의 물리적 주소를 먼저 확립해야 하는 노드 중심(Node-Centric) 방식이었다. 반면, **Zenoh(제노)**는 철저한 데이터 중심(Data-Centric) 철학을 표방한다. Zenoh 네트워크에서 가장 중요한 시민(First-class Citizen)은 디바이스가 아니라 ’데이터’이다.

이러한 철학을 기술적으로 구현하기 위해, Zenoh는 분산 네트워크상의 수많은 데이터 조각들을 고유하게 식별하고, 질의(Query)하고, 수정할 수 있는 독창적인 데이터 모델과 리소스 네이밍(Resource Naming) 체계를 도입하였다. 이는 마치 전 세계의 웹 페이지들이 URI(Uniform Resource Identifier)를 통해 식별되고 접근 가능한 것과 유사한 개념이다.

본 장에서는 Zenoh가 전역 스케일의 거대한 분산 시스템을 하나의 거대한 가상 데이터베이스처럼 다루기 위해 채택한 키-값(Key-Value) 기반의 글로벌 데이터 공간 개념부터, 계층적 URI 스타일의 식별자 설계, 그리고 와일드카드를 활용한 강력한 동적 구독 및 쿼리 매커니즘인 셀렉터(Selector) 문법까지, Zenoh 데이터 모델의 핵심 원리들을 상세히 파헤친다.

1. 키-값(Key-Value) 기반의 글로벌 데이터 공간(Global Data Space) 추상화

Zenoh(제노)가 지향하는 분산 시스템의 최종 목표는 수만 대의 로봇, 센서, 엣지 서버, 클라우드 데이터베이스가 얽힌 복잡한 물리적 네트워크를 개발자의 시야에서 완전히 지워버리는 것이다. 개발자는 오직 “어떤 정보(Data)가 필요한가?“에만 집중해야 한다. 이를 가능케 하는 핵심 개념이 바로 **글로벌 데이터 공간(Global Data Space, GDS)**이다.

1.1 전역적 단일 뷰 (Global Single View)

글로벌 데이터 공간은 네트워크에 흩어져 있는 모든 데이터를 하나의 거대한, 눈에 보이지 않는 백엔드 스토리지 시스템처럼 추상화(Abstraction)한다.

  • 일본 공장의 컨베이어 벨트에 있는 온도 센서 데이터든,
  • 한국 데이터센터의 포스트그레스큐엘(PostgreSQL) DB에 저장된 과거 이력 테이블이든,
    Zenoh 네트워크에 연결되어 있는 한 이 모든 정보는 ‘단일한 글로벌 데이터 공간’ 내에 존재하는 리소스(Resource)로 간주된다. 애플리케이션 개발자는 이 데이터들이 지구상 어디에 위치하는지, 어떤 물리적 라우터를 거쳐 들어오는지 전혀 알 필요가 없다.

1.2 키-값 (Key-Value) 데이터 모델

이 거대한 가상 공간을 통제하기 위해 Zenoh는 가장 단순하고 수학적으로 명료한 키-값(Key-Value) 데이터 모델을 채택했다.

모든 데이터는 고유한 **키(Key)**에 의해 식별되며, 그 키에 대응하는 **값(Value, Payload)**을 갖는다.

  • 키(Key): 데이터의 논리적인 ’이름’이자 ’주소’이다. 앞선 라우팅 챕터에서 살펴보았듯이, Zenoh 엔진은 오직 이 ’이름’만을 보고 데이터를 라우팅한다 (Name-based Routing).
  • 값(Value): 해당 키가 지칭하는 실제 데이터 바이트 배열(Byte Array)이다. 이는 숫자 10일 수도 있고, 고화질 CCTV 영상 프레임일 수도 있으며, 복잡한 JSON 객체일 수도 있다. Zenoh 레이어 자체는 이 Value가 무엇인지(Agnostic) 신경 쓰지 않으며, 온전히 페이로드(Payload)로서 전송만 책임진다.

이러한 극단적인 구조적 단순함은 MQTT나 Redis 같은 고성능 캐시 시스템과 철학적 궤를 같이하면서도, 라우팅 레이어와 직접 결합되어 있다는 점에서 그 어떤 스토리지 시스템보다 파괴적인 확장성(Scalability)을 보여준다. 결과적으로 Zenoh 네트워크 전체가 하나의 거칠고 방대한, 그러나 초고속으로 동기화되는 분산형 Key-Value NoSQL 데이터베이스처럼 동작하게 되는 것이다.

2. 계층적 URI 스타일 리소스 식별자(Path-like ID) 설계 규칙

앞서 글로벌 데이터 공간의 모든 데이터가 ’키(Key)’에 의해 식별된다고 설명했다. 그렇다면 수억 개의 데이터 조각이 혼재하는 분산 시스템에서 키들 간의 충돌을 방지하고, 직관적으로 맥락을 이해할 수 있는 키 이름 체계(Naming Convention)를 어떻게 설계해야 할까?

**Zenoh(제노)**는 가장 검증된 인간 직관적인 명명법인 계층적 URI 스타일(Path-like, URI-style) 식별자 구조를 표준 규격으로 강제한다. 이는 우리가 매일 접하는 웹사이트의 URL이나 리눅스 파일 시스템의 디렉터리 경로와 정확히 동일한 방식이다.

2.1 식별자 표현 (Key Expression)의 구조

Zenoh의 키 구조(Key Expression)는 슬래시(/)를 구분자(Delimiter)로 사용하여 논리적 범위를 대분류에서 소분류로 좁혀나가는 하향식 트리를 구성한다.

[도메인] / [서브시스템] / [디바이스_ID] / [센서_유형] / [데이터_종류]

  • 예시 1: smartcity/seoul/mapo/traffic_light/7/status (마포구 7번 신호등의 현재 상태)
  • 예시 2: factory/line_a/robot_arm/3/joint/elbow/angle (A라인 3번 로봇팔의 팔꿈치 관절 각도)

2.2 계층적 설계의 이점

이러한 경로형(Path-like) 명명 규칙은 단순한 가독성 향상을 넘어, 아키텍처적으로 막대한 효용을 창출한다.

  • 이름 공간(Name Space)의 격리: 글로벌 환경에서 여러 시스템이 섞이더라도, 식별자의 제일 앞단(Prefix)에 factory_1/ 또는 robot_os/와 같은 독립적인 도메인 이름을 배치함으로써 이름 충돌(Naming Collision)을 원천 차단한다.
  • 라우팅 병합(Aggregation) 효율 극대화: 2.3.2장에서 강조했던 바와 같이, 라우터 포워딩 엔진은 트라이(Trie) 자료구조를 기반으로 동작한다. 계층적 식별자는 이 트리 구조에 완벽하게 부합한다. 만약 로봇팔 3번에 달린 100개의 센서 데이터가 각각 .../robot_arm/3/joint/1 ~ 100으로 명명되었다면, 상위 라우터는 이를 일일이 알 필요 없이 단일 경로 .../robot_arm/3/** 하나만으로 트래픽을 효율적으로 요약해버릴 수 있다.
  • 접근 통제(ACL)의 용이성: 보안 정책을 적용할 때도, 특정 디바이스나 서브시스템 식별자 하위의 모든 데이터(factory/secure_zone/**)에 대한 일괄적인 암호화, 읽기/쓰기 권한 부여를 직관적으로 수행할 수 있게 해 준다.

3. 셀렉터(Selector) 문법 구조 및 쿼리 파라미터 매핑

분산 시스템 내의 키(Key Expression) 구조를 정립했다면, 이제 이 거대한 데이터 트리에서 원하는 정보만을 스나이퍼처럼 정확하게 표적화하여 가져올(Query) 차례이다. **Zenoh(제노)**는 특정 단일 Key를 지칭하는 것을 넘어, 와일드카드와 쿼리 문자열을 결합하여 복소적인 질의를 던질 수 있는 강력한 문법 체계인 **셀렉터(Selector)**를 제공한다.

셀렉터는 HTTP GET 요청의 URL과 매우 유사한 구조를 가지며, 크게 **키 매칭부(Key Matching Part)**와 **파라미터부(Parameter Part)**의 두 축으로 구성된다.

3.1 셀렉터의 기본 해부학 (Anatomy of a Selector)

[키_매칭부(Key Expression)] ? [파라미터부(Query Parameters)]

  • 키 매칭부: factory/robot/+/status처럼 특정 데이터나 집합을 와일드카드와 결합하여 지정한다.
  • 물음표(?): 이 기호를 기점으로 쿼리의 추가적인 맥락(Context)이나 논리가 시작됨을 파서(Parser)에게 알린다.
  • 파라미터부: k1=v1&k2=v2 형식으로 구성되며, 구독 또는 쿼리 행위에 부여하는 부가적인 조건이나 명령어(Directive)를 의미한다.

3.2 파라미터(Parameter)의 활용

셀렉터의 진짜 위력은 물음표(?) 뒤에 붙는 쿼리 파라미터에서 폭발한다. 이 파라미터는 대상의 데이터를 필터링하거나, 스토리지 백엔드에게 특정 SQL 유사(SQL-like) 동작을 지시하는 데 사용된다.

3.2.1 맥락 기반 데이터 트리거

로봇 1번에게 상태 보고를 요청(Query)할 때 파라미터를 붙여 특수한 동작을 유도할 수 있다.
factory/robot/1/status?level=critical&format=json
Zenoh 라우터는 이 매핑된 URL 전체를 응답자(Responder) 노드로 전송한다. 데이터를 쥐고 있는 퍼블리셔(또는 스토리지 백엔드 플러그인)는 파라미터를 읽어, ‘매우 중요한 상태(critical) 정보만’, ‘JSON 형태로’ 필터링 가공하여 회신한다.

3.2.2 메타데이터와 시스템 쿼리 플래그

파라미터는 Zenoh 내부 시스템 제어용으로도 쓰인다.
예를 들어 factory/robot/1/status?_time=[10:00..12:00]와 같은 메타-파라미터를 던지만, In-flux DB와 연동된 Zenoh 백엔드가 시간 범위(Time-range) 조건절을 해석해 해당 시계열 구간의 과거 데이터(Data at Rest)를 긁어서 사용자에게 뿌려준다.

이처럼 Zenoh의 셀렉터 문법은 단순한 ’이름 부르기’를 넘어, 전 세계에 흩어진 분산 데이터베이스에게 정교한 질의 명령(SQL Query)을 하달하는 고차원적인 추상화된 제어 인터페이스(Abstract Control Interface) 역할을 수행한다.

4. 와일드카드(*, )를 활용한 동적 리소스 매칭 및 그룹 필터링

Zenoh(제노)의 네이밍 시스템이 제공하는 가장 강력한 기능 중 하나는 와일드카드(Wildcard)를 활용한 동적인 그룹핑(Grouping) 지원이다. 단일 디바이스나 단일 스케줄만 고정해서 불러오던(Hard-coded) 기존의 정적 토픽(Topic) 구독 방식과 달리, Zenoh는 계층 구조(Path)의 특성을 십분 활용하여 **“내가 원하는 조건에 맞는 모든 리소스”**를 와일드카드로 매칭해 낼 수 있다.

Zenoh가 공식적으로 지원하는 와일드카드 연산자는 자식 노드 레벨을 제어하기 위해 두 가지(*, **)로 세분화되어 있는데, 이들의 미세한 차이를 이해하는 것은 효율적인 라우팅 테이블 구성에 필수적이다.

4.1 단일 레벨 와일드카드 (*)

*(Asterisk)은 계층형 URI에서 **정확히 단일 레벨(One Level)**의 디렉터리 경로, 즉 슬래시(/)와 슬래시 사이의 한 마디만을 대체하는 와일드카드이다.

  • 사용 예시: factory/line_A/robot/*/status
  • 매칭 성공: .../robot/1/status, .../robot/arm_B/status
  • 매칭 실패: .../robot/1/joint/status (경로의 깊이가 다름)

디바이스의 ID나 모델명만 다르고 나머지 계층 트리의 깊이(Depth)가 완전히 동일하게 규격화된 다수의 디바이스 플릿(Fleet) 데이터를 병합(Aggregation)하여 구독할 때 주로 사용된다.

4.2 다중 레벨 와일드카드 (``)

단일 레벨 와일드카드가 ’형제 노드’들을 수평적으로 묶어준다면, 이중 와일드카드 **(Double Asterisk)는 해당 경로 아래로 뻗어 나가는 모든 자손(Descendants) 노드들을 수직적으로 통째로 묶어버리는 역할을 한다. 깊이(Depth)에 제한이 없다.

  • 사용 예시: factory/line_A/robot/1/**
  • 매칭 성공: .../robot/1/status, .../robot/1/joint/elbow/angle, .../robot/1/camera/front/frame

** 연산자는 주로 특정 디바이스나 서브시스템에서 파생되는 ’모든 데이터’를 백업 데이터베이스(Storage Backend)에 로깅(Logging)하거나, 모니터링 시스템(Dashboard)이 특정 장비의 모든 생체 징후(Telemetry)를 샅샅이 빨아들일 때 강력한 위력을 발휘한다.

4.3 동적 리소스 매칭의 라우팅 이점 (병합의 극대화)

와일드카드의 진정한 가치는 단순히 개발자의 타이핑 수고를 덜어주는 데 있지 않다. 와일드카드가 포함된 셀렉터(Selector)는 Zenoh 노드의 라우팅 테이블(Trie 구조)에서 **라우팅의 요약과 병합(Aggregation)**을 유발하는 기폭제로 작용한다.

  1. 클라우드 서버에서 factory/**를 구독(Subscribe)한다.
  2. 이 관심사(Interest)는 네트워크를 타고 공장에 위치한 라우터에 도달한다.
  3. 공장 라우터의 밑단에 붙은 1만 대의 센서들이 factory/sensor/1부터 각자의 고유 키로 데이터를 퍼블리시한다.
  4. 공장 라우터는 1만 개의 서로 다른 데이터가 올라오더라도 상위 클라우드 라우터에게 1만 번 경로를 갱신하지 않는다. 상위 라우터의 테이블에는 이미 factory/** 하나만 기록되어 있기 때문이다.

이처럼 와일드카드 셀렉터는 거대한 분산 시스템에서 발생하는 O(N)의 라우팅 상태 정보를 O(1) 수준으로 극단적으로 압축함으로써, Zenoh 네트워크가 대역폭의 붕괴 없이 지구적 스케일로 스케일 아웃(Scale-out)할 수 있는 수학적 근간을 제공한다.

5. 데이터 표현 방식(Encoding) 및 페이로드 메타데이터 구조

강력한 식별자(Resource Name)와 유연한 셀렉터(Selector)를 통해 데이터 패킷을 정확한 목적지까지 배달하는 라우팅 인프라를 갖추었다고 해서 통신의 여정이 끝나는 것은 아니다. 배송된 소포의 내용물이 무엇인지(JSON 텍스트인지, 압축된 동영상 바이너리인지, 혹은 암호화된 센서 데이터인지) 수신자가 정확히 인지하고 파싱(Parsing)할 수 있어야만 진정한 의미의 상호 운용성(Interoperability)이 확보된다.

**Zenoh(제노)**는 데이터(Payload) 그 자체의 형식에는 전혀 관여하지 않는 형식 불가지론(Format-Agnostic)적 태도를 견지한다. 대신 네트워크를 넘나드는 모든 데이터 덩어리에 표준화된 페이로드 메타데이터(Payload Metadata) 구조를 씌워, 수신 측이 이진(Binary) 데이터를 안전하게 해석할 수 있는 길잡이 역할을 제공한다.

5.1 데이터 인코딩(Encoding) 속성의 명시

Zenoh의 데이터 패킷 헤더에는 반드시 인코딩(Encoding) 식별자가 동봉된다. 이는 HTTP의 Content-Type 헤더나 MIME 타입과 유사한 역할을 수행한다.
개발자가 데이터를 퍼블리시할 때 명시적으로 인코딩 타입을 지정하지 않으면 Zenoh는 기본적으로 원시 바이트스트림(application/octet-stream)으로 취급하지만, 다음과 같이 구체적인 인코딩 규격을 덧붙일 수 있다.

  • application/json : 문자열 기반의 JSON 데이터
  • application/x-protobuf : 구글의 Protocol Buffers에 의해 직렬화된 데이터
  • text/plain : 인간이 읽을 수 있는 평문 텍스트
  • application/x-cdr : ROS 2 생태계와의 호환성을 위한 Common Data Representation 형식

수신 측(Subscriber 혹은 쿼리 응답 수신자)은 바이트 배열의 본문을 역직렬화(Deserialize)하기 직전에 이 인코딩 속성부터 확인하여 적절한 파서(Parser)를 안전하게 배정할 수 있다.

5.2 사용자 정의 메타데이터 (Custom Attachment) 삽입

인코딩 정보 외에도, Zenoh는 애플리케이션 개발자가 페이로드와는 별개로 추가적인 비즈니스 메타데이터를 끼워 넣을 수 있는 Attachment 기능을 기본으로 제공한다.
Attachment는 크기가 제한된 헤더 확장의 일종으로, 무거운 페이로드를 압축 해제하거나 파싱해보기 전 미리 확인해야 하는 초경량 제어 지시자 역할을 한다.

  • 활용 예시 1 (보안): 페이로드 본문은 완전히 암호화되어 있지만, Attachment에 ’키 ID’나 ‘암호화 알고리즘 버전’ 정보를 평문으로 적어두어 수신 측 보안 모듈이 즉각 대처하도록 유도한다.
  • 활용 예시 2 (라우터 필터링): Attachment에 priority: high와 같은 긴급 플래그를 달아두면, 중간 기착지의 에지 라우터들이 페이로드를 열어보지 않고도 큐(Queue)의 우선순위 최적화(Quality of Service)에 개입할 근거를 마련할 수 있다.

5.3 정합성과 타임스탬프 (Timestamping)

분산 시스템에서 시간이란 절대적이지 않으며 상대적이다. 무인기(Drone) 10대가 쏜 위치 데이터들이 제각기 다른 시간의 궤적을 갖기 때문이다.
Zenoh 프로토콜 헤더에는 옵션으로 고정일 타임스탬프(Network Time Protocol 동기화 기반) 계층이 내장되어 있다. 1밀리초의 시간적 선후가 시스템의 존망을 가르는 자율주행 데이터 결합(Sensor Fusion) 환경에서, 수신 측은 데이터가 네트워크 큐를 통과한 ’도착 시간’이 아니라 발행자가 데이터를 찍어낸 ‘고유 생성 타임스탬프’ 메타데이터를 기반으로 이벤트를 정확하게 순차 정렬(Ordering)할 수 있다.