9.2.1.1 zenoh-c 설계 철학과 수동적 메모리 관리(Manual Memory Management) 체계

현대 소프트웨어 공학이 러스트(Rust), 파이썬, 고루틴 기반의 가비지 컬렉터(GC)에 심취해 있을 때, zenoh-c는 지독하리만치 고전적이고 원시적인 방법론으로 회귀한다. 그것은 바로 개발자가 바이트 공간(Byte Space)의 생사를 직접 통치하는 수동적 메모리 관리(Manual Memory Management)다.

로보틱스와 에지 인프라 환경에서 1바이트의 메모리 누수(Leak)는 곧 장비의 무기한 정지(Halt)로 이어지기에, zenoh-c는 단순한 래퍼(Wrapper)를 넘어서 개발자에게 무결성을 증명할 것을 강요하는 폭군에 가깝다. 본 절에서는 zenoh-c의 기반 설계 철학과, 이 잔혹한 수동 생태계 속에서 C 엔지니어가 메모리를 할당하고 회수하는 구체적인 행동 강령 체계를 도출한다.

1. Opaque Pointer 패턴과 불투명한 캡슐화

zenoh-c 환경에서 사용되는 대부분의 변수들(z_session_t, z_publisher_t, z_config_t)을 살펴보라. 개발자는 이 구조체 내부의 필드를 가리키는 멤버 연산자(->)를 직접 타이핑하여 값을 가져올 수 없다. 이 변수들은 철저하게 캡슐화되어 오직 C-ABI 이면에 있는 Rust 코어 엔진만이 그 해부도를 알고 있는 불투명 포인터(Opaque Pointer)로 은닉되어 있다.

이는 개발자가 호기심이나 편의성을 핑계로 내부 캐시 값에 손을 대어 메모리 배열 정렬을 파괴하는 행위를 헤더 단위에서부터 원천 차단(Segregation)해버린 것이다.
오직 zenoh-c가 오피셜하게 제공하는 게터(Getter) / 세터(Setter) 함수(z_info_xxx)만을 우회로로 통과해야 내부 데이터에 접근할 수 있으며, 이러한 벽이 있어야만 양 세계(C와 Rust) 간의 메모리 오염 없는 신뢰성 교환이 성립된다.

2. 함수 명명 규칙에 내포된 주권(Ownership) 양도 서약

수동 관리의 함정을 피하기 위해, zenoh-c는 매우 엄격하고 직관적인 함수 네이밍 프로토콜(Protocol)을 선언한다. 그 핵심은 _alloc, _drop, 그리고 _check라는 접미사에 존재한다.

• 특정 구성 요소나 상태 공간이 필요할 때 호출하는 z_config_default()나 z_publisher_declare()는 그 즉시 시스템 힙 영역을 소모한다.
• 할당된 자원의 생명이 다했다면 반드시 대응되는 폐기 함수인 z_config_drop(), z_publisher_undeclare()를 개발자가 수기로 타건하여야 한다.
• 만약 반환형의 타입 정의(typedef) 이름 자체에 owned 가 기재되어 있다면(예: z_owned_reply_t), 해당 구조체의 소멸 책임은 전적으로 당신(호출자)에게 양도되었음을 뜻하는 묵시적 서약서다.

// 소유권(Owned)을 양도받은 예제 플로우
z_owned_session_t session;
// 1. 메모리 공간 생성 및 세션 초기화
if (z_open(&session, config, NULL) < 0) {
    printf("세션 연결에 실패했습니다.\n");
    // 통신 초기화 실패 시에도 반환된 구조체가 있다면 반드시 해소
} else {
    printf("Zenoh 라우팅 패브릭 안착 성공\n");
    // ... 무한 통제 루프 ...
    
    // 2. 단말기 종료 시 명시적인 생명주기 사살 연산
    z_close(&session);
}

3. 메모리 클린업 타임라그(Cleanup Time-Lag) 및 지연 프리(Free) 오류

수동 관리 생태계의 가장 악랄한 함정은 다중 스레드 하의 지연 오류다. 구독(Sub) 네트워크 콜백 이벤트로 인해 다른 스레드에서 특정 핸들러 자원(z_subscriber_t)을 아직 열람 중일 때, 메인 함수에서 무참하게 z_undeclare()를 때려버리면 그 직후 커널은 해방된 주소값(Use-After-Free)을 뱉어내고 시스템 동반 추락(Segfault) 사태를 빚는다.

zenoh-c 개발자는 동시 트래픽 환경 안에서 소스 자원을 drop 하기 이전에, 백그라운드 태스크나 코루틴이 당해 주소 스페이스에 일절의 의존성을 띄지 않음을 확인하는 락킹(Locking) 절차를 설계해야 한다. 수동 메모리 제어는 단순히 free() 를 부르는 노동이 아니라, 우주선 모듈 이탈 시퀀스처럼 모든 결속이 안전하게 풀렸을 때에만 해제 스위치를 점화하는 초정밀 설계(Precision Engineering)의 영역임을 명심하라.