1. gNMI의 위치: gRPC 위의 애플리케이션 계층
gNMI는 단순히 gRPC가 아니라, gRPC 위에 구축된 네트워크 관리 서비스 정의입니다. gRPC가 통신 전송 계층이라면, gNMI는 그 위에서 네트워크 장치 상태 조회, 설정 변경, 텔레메트리 스트리밍이라는 구체적인 RPC 동작과 의미론을 정의합니다. 따라서 gRPC 프레임워크의 HTTP/2 기반 멀티플렉싱, Protocol Buffers 직렬화 효율성을 상속하면서도, 네트워크 엔지니어링 도메인에 특화된 경로 기반 데이터 모델과 스키마 개념을 도입했습니다.
2. 경로 기반 데이터 주소지정과 트리 구조
gNMI가 NETCONF·SNMP와 차별화되는 핵심은 데이터가 항상 '경로'로 식별된다는 점입니다. OpenConfig 기반 gNMI는 YANG 모델 또는 임의의 트리 구조 데이터를 지원하되, 반드시 Path 메시지로 표현합니다. Path는 단순 문자열이 아니라 순서화된 PathElem 배열로 인코딩되며, 각 요소는 노드명과 키-값 쌍(예: name="eth0")을 포함합니다. 이 구조는 와일드카드 확장, 프리픽스 재사용을 통한 메시지 크기 절감(3~10배 XML보다 소), 스키마 진화에 대한 안정성을 동시에 제공합니다. 특히 Update 메시지의 중복 제거 카운터(duplicates 필드)는 느린 클라이언트가 따라잡지 못할 때 서버가 최신 값만 전달하면서도 상태 전이를 감지할 수 있게 설계되었습니다.
3. 다중 인코딩과 TypedValue의 유연성
gNMI는 JSON, Protobuf, Bytes, ASCII, JSON_IETF(RFC 7951) 다섯 가지 인코딩을 지원하며, 단일 메시지 내에서 혼합 사용은 금지됩니다. 핵심은 각 데이터 항목이 TypedValue oneof로 표현되어, 스칼라(string, int64, uint64, bool, double)에서 구조화 데이터(JSON 객체, Protobuf 메시지)까지 자동으로 직렬화된다는 점입니다. 클라이언트와 서버는 사전에 Capabilities RPC로 상호 지원 인코딩을 협상하며, 미지정 시 JSON이 의무 최소값입니다. 이 다중성은 기존 YANG 모델 기반 배포와 클라우드 네이티브 JSON 기반 신규 구축 사이 상호운용성을 제공합니다.
4. Set RPC의 트랜잭션과 원자성
gNMI SetRequest는 delete, replace, update 세 연산을 이 순서로 처리하며, 모두 하나의 트랜잭션으로 취급됩니다. 모든 변경이 성공하거나, 전부 실패하고 롤백되어야 합니다. 특히 replace는 스키마의 기본값을 복원하고 미지정 리프를 삭제하는 '완전 치환', update는 명시된 리프만 생성/변경하는 '부분 삽입'이라는 명확한 의미론을 갖습니다. 변경이 수락되기 전까지 텔레메트리 업데이트에 반영되지 않으며, 이는 클라이언트-서버 간 상태 일관성을 보장합니다. 경로가 여러 origin(스키마)을 지정하면 그들도 단일 트랜잭션으로 묶이는데, 이는 CLI 설정과 OpenConfig 설정이 동시에 수정될 때 원자성을 유지합니다.
5. Subscribe RPC와 세 가지 구독 모드
ONCE(일회성 스냅샷), POLL(클라이언트 주도 폴링), STREAM(서버 푸시)의 세 모드 각각에서 ON_CHANGE(상태 변화 시), SAMPLE(고정 주기), TARGET_DEFINED(리프별 최적화) 세부 트리거를 지원합니다. STREAM의 ON_CHANGE는 먼저 초기 상태 전체를 전송한 후 sync_response로 동기화 완료를 알린 뒤, 변화만 이후 전송합니다. suppress_redundant 플래그와 heartbeat_interval 조합은 샘플링 구독에서 불필요한 업데이트를 억제하면서도 주기적 확인을 가능하게 합니다. allow_aggregation은 스키마에서 명시적으로 표기된 관련 리프들만 하나의 Notification으로 번들링하여 메시지 오버헤드를 줄입니다. 클라이언트가 따라잡지 못하면 서버는 이전 값을 폐기하고 최신값만 전송하되 duplicates 카운터로 손실을 알립니다.