요약

  • RFC 10035는 YANG Library에 읽기 전용augmented-by리스트를 추가하여, 서버가 동일한 모듈 세트 내에서 다른 모듈을 직접 augment하는 모듈의 이름을 보고할 수 있게 합니다. 기반 모듈은 자기 소스를 파싱해서는 발견할 수 없는 관계입니다.
  • 이 리스트는 의도적으로 전이적 폐쇄(closure)가 아닙니다. B가 A가 정의한 노드를 augment하고 C가 B가 정의한 자식을 augment한다면, A는 B를, B는 C를 보고합니다. C의 대상 경로가 A 아래에서 시작한다는 이유만으로 C가 A의 직접 리스트로 승격되지는 않습니다.
  • 결과는 한 서버의 버전이 지정된 직접 인접성으로 취급해야 합니다. 유효 스키마에 대한 주장에는 여전히 YANG Librarycontent-id, 모듈 리비전, 접근 결과, 클라이언트 탐색, 검색된 소스, 관찰된 적용 결과가 필요합니다.

대부분의 소프트웨어 의존성은 편안한 방향을 가리킵니다. 파일을 열면 무엇을 임포트하는지 알려줍니다. YANG 모듈을 읽으면import와include문이 자신이 호출하는 모듈이나 서브모듈을 드러냅니다. 독자는 소스에서 출발해 바깥으로 걸어갈 수 있습니다.

augment는 이 관점을 뒤집습니다. 별도의 모듈이 첫 번째 모듈의 스키마 트리에서 위치를 대상으로 지정하여 그곳에 새 노드를 삽입할 수 있습니다. 기반 모듈에는 누가 외부에서 들어왔는지 알려주는 줄이 생기지 않습니다. 따라서 그 유효 형태는 자신이 전혀 언급하지 않는 소스에 의존할 수 있습니다.

RFC 10035가 다루는 문제가 바로 이 좁은 지점입니다. 2026년 8월 IETF Standards Track으로 발표된YANG Library: Addition of the augmented-by List는 RFC 8525를 갱신합니다. 저자는 Zhuoyao Lin, Benoît Claise, Ignacio Dominguez Martinez-Casanueva입니다. 이 문서는 YANG Library의 모듈 항목 아래에 읽기 전용augmented-byleaf-list를 추가합니다. 이제 서버는 현재 모듈 세트에서 어떤 모듈이 해당 모듈을 직접 augment하는지 보고할 수 있습니다.

Claise가 여기서 관련 있는 이유는 YANG의 소유자이거나 이 추가 기능의 유일한 발명가이기 때문이 아니라, 모델이 운영 중인 네트워크와 어떻게 만나는지에 관한 오랜 운영 대화의 참여자 한 명이기 때문입니다. 2026년 8월 31일에 캡처된 그의 IETF Datatracker 페이지에는 RFC 10035를 포함한 45개의 RFC와 네트워크 관리·운영 작업, 성능 메트릭 검토, IAB 워크숍, YangCatalog 지원에 걸친 현재 역할이 나열되어 있습니다. IETF 104 약력은 2012년부터 2018년까지 Operations and Management Area 공동 디렉터로 재직했고 YANG, 텔레메트리, 네트워크 자동화 작업을 했다고 기록합니다. 이 날짜가 있는 기록들은 맥락을 제공합니다. RFC 저자에게 어떤 서버, 클라이언트, 배포에 대한 권한도 이전하지 않습니다.

의존성은 기반 쪽으로 되돌아옵니다

RFC 7950은 이 비대칭성을 구체적으로 만듭니다.import는 모듈이 다른 모듈의 정의를 사용할 수 있게 하고,include는 모듈이 서브모듈을 통합할 수 있게 합니다. 둘 다 필요로 하는 소스가 선언합니다. 그 소스를 보는 파서는 의존성을 볼 수 있습니다.

외부augment는 다릅니다. 그 저자는 대상이 다른 모듈에 있을 수 있는 스키마 노드 식별자를 제공합니다. augment하는 모듈은 대상을 알지만, 대상 모듈은 augment하는 모듈을 반드시 알지 못합니다. RFC 10035는 이를deviation과 함께 역방향 의존성으로 분류합니다. 다른 모듈이 기반과 연관된 사용 가능한 형태나 동작을 변경하는 것입니다.

YANG Library에는 이미 deviation 모듈을 식별하는 방법이 있었습니다. 빠져 있던 것은 augmentation에 대한 동등한 서버 보고 답변이었습니다. 그것이 없으면, 유효 스키마를 조립하려는 클라이언트는 기반을 올바르게 파싱하면서도 다른 곳에서 삽입된 노드를 여전히 누락할 수 있습니다. 전체 카탈로그를 검색하면 후보를 찾을 수 있지만, 카탈로그는 특정 서버가 구현한다고 선언하는 모듈 세트와 동일한 것이 아닙니다.

augmented-by는 답을 서버의 라이브러리로 옮깁니다. 각 모듈 항목마다 서버는 그 모듈을 직접 augment하는 모듈들의 이름을 나열할 수 있습니다. 기반 모듈과 augment 모듈은 둘 다 동일한 모듈 세트에 나타나야 합니다. 이 조건이 중요합니다. 이 엣지는 두 공개 모듈이 항상 결합되어 있다는 시간을 초월한 진술이 아니라, 하나의 보고된 배포 컨텍스트에서의 관계입니다.

이 때문에 이 리스트는 발견에는 유용하면서 증거 주장은 절제되어 있습니다. “이 모듈 세트의 어떤 모듈이 이 모듈을 직접 augment하는가?”에는 답합니다. “여기서 도달 가능한 모든 스키마 노드는 무엇인가?”, “이 구현이 적합한가?”, “내 자동화가 동작하기에 안전한가?”에는 답하지 않습니다.

직접이란 새 연결 지점을 소유한 부모를 뜻합니다

RFC 10035에서 가장 어려운 경계는 세 모듈 예제에 나타납니다. 모듈 A가foo-a를 정의한다고 가정합니다. 모듈 B는 A를 augment하며 그 아래에foo-b를 추가합니다. 모듈 C는 다시foo-b아래에 리프를 추가합니다.

C가 사용하는 경로는 A에서 시작된 영역에 뿌리를 둡니다. 따라서 C도 A를 augment한다고 말하고 싶어질 수 있습니다. RFC는 그 지름길을 거부합니다. C가 추가한 리프의 부모는foo-b이고, 그 부모를 정의한 것은 B입니다. YANG Library는 B를 A의augmented-by리스트에, C를 B의 리스트에 보고합니다. C를 A 아래에 나열하지 않습니다.

이것은 빠진 기능이 아닙니다. 엣지의 의미를 보존하는 것입니다. 모든 자손을 모든 조상에 복사한다면, 직접 관계는 전이적 결과와 구별할 수 없게 됩니다. 큰 스키마는 실제 연결이 어디서 발생했는지 더는 말해주지 않는, 팽창하고 반복적인 리스트를 만들어냅니다.

전체 폐쇄가 필요한 애플리케이션은 직접 계산할 수 있습니다. A에서 시작하고, A→B를 따르고, B→C를 따르며, 경로를 유지하고 오류에 대비하면 됩니다. 특정 노드가 관심인 애플리케이션은 모듈을 검색하여 스키마 트리를 검사할 수 있습니다. 이들은 클라이언트의 기능입니다. 서버는 모든 가능한 의존성 질문에 대한 완성된 답이 아니라 직접 인접성을 제공합니다.

이 분할은 최소 초기 사양(minimum-initial-specification) 규율을 따릅니다. 공유 메커니즘은 이전에 발견하기 어려웠던 가장 작은 상호운용 가능한 사실의 이름을 붙입니다. 재귀 탐색 정책, 순환 처리, 캐시 무효화, 노드별 분석, 리스크 결정은 애플리케이션마다 필요한 답이 다르기 때문에 로컬에 남습니다.

리스트는 변하는 라이브러리 인스턴스에 속합니다

직접 엣지는 그 버전을 알 수 있을 때만 유용합니다. RFC 8525는 각 YANG Library 인스턴스에content-id를 부여합니다. 이 값은 해당 서버의 현재 라이브러리 정보를 나타내며, 그 정보가 바뀌면 반드시 바뀌어야 합니다. 클라이언트는 하나의 식별자로 라이브러리를 캐시하고, 나중의 식별자를 인지하고, 갱신된 인스턴스를 검색할 수 있습니다.

RFC 10035는 운영상 기대를 추가합니다. 새 모듈이 온보딩될 때 YANG Library와 그augmented-by데이터가 갱신되어야 합니다. 이로써 신선도가 증거의 일부가 됩니다. 서버 식별자, 캡처 시각,content-id없이 찍힌 A→B 스크린샷은 어떤 라이브러리 상태가 그 엣지를 만들었는지 보여줄 수 없습니다. A→B가 없다는 것은 더 애매합니다. 직접 augment가 없다는 뜻일 수도 있지만, 오래된 라이브러리, RFC 10035를 지원하지 않는 구현, 필터링된 접근, 잘못된 보고를 반영할 수도 있습니다.

따라서 방어 가능한 증명서는 리스트를 서버와 관리 엔드포인트, 인증된 주체, 데이터스토어와 스키마, 모듈 세트, 모듈 이름, 리비전, 네임스페이스에 묶습니다.content-id와 정확한 직접 엣지를 보존합니다. 클라이언트가 폐쇄를 계산한다면, 탐색 알고리즘, 한계, 경로, 오류 처리, 출력을 서버 응답과 분리하여 기록합니다.

이 분리는 계산된 그래프가 서버가 선언한 것처럼 왜곡되는 것을 막습니다. 또한 나중의 결과를 재현 가능하게 만듭니다. 모듈 리비전이나 온보딩 이벤트 이후 A→B→C가 바뀐다면, 조사자는 바뀐 클라이언트 로직과 바뀐 라이브러리를 구별할 수 있습니다.

읽기 전용이 무해하다는 뜻은 아닙니다

새 leaf-list는 구성을 전혀 변경하지 않습니다. 읽기 전용입니다. 그러나 그 관계는 어떤 선택적 모듈, 기능, 구현 구성 요소가 존재하는지 드러낼 수 있습니다. RFC 10035는 이 구조가 공격자가 특정 구현을 표적으로 삼는 데 도움될 수 있다고 경고하며, 관리 접근 제어 경계를 통해 읽기를 권한 있는 사용자로 제한할 것을 권고합니다.

이 때문에 캡처된 리스트를 보편적 진실로 취급하지 않을 또 하나의 이유가 생깁니다. 두 주체는 정책이 라이브러리를 필터하기 때문에 서로 다른 정보를 볼 수 있습니다. 엣지를 받지 못한 클라이언트는 JSON이나 XML 값만큼 접근 결과가 필요합니다. “반환되지 않음”과 “존재하지 않음”은 동의어가 아닙니다.

크기 면의 비용도 있습니다. 보고된 역방향 의존성 하나하나가 YANG Library 인스턴스를 키웁니다. 운영자는 모듈이 바뀔 때 데이터를 갱신해야 하고, 클라이언트는 캐시가 언제까지 신뢰할 수 있는지 결정해야 합니다. 유용한 최적화는 라이브러리를 만능 분석 서비스로 만드는 것이 아니라, 컴팩트한 엣지를 제공하고 애플리케이션이 결정에 필요할 때만 더 깊은 증거를 가져오게 하는 것입니다.

인접성에서 운영 주장으로

YANG Library를 사용하여 서버의 구성 스키마를 이해했는지 판단하는 클라이언트를 생각해 봅시다. A→B를 보는 것은, 현재 라이브러리 인스턴스가 명명된 모듈 세트 내에서 B를 A의 직접 augmenter로 보고한다는 것을 증명합니다. 클라이언트가 B를 검색했고, 올바른 리비전을 선택했고, 모든 문장을 파싱했고, B→C를 따랐고, deviation을 조정했고, 올바른 데이터스토어를 매칭했고, 기능 조건을 처리했다는 것은 증명하지 않습니다.

또한 실행 중인 서버가 모델이 예측한 대로 동작한다는 것도 증명하지 않습니다. RFC 8342는 네트워크 관리 시스템이 추론해야 하는 의도(intended) 뷰와 운영(operational) 뷰를 구별합니다. 스키마 그래프는 기대를 조직할 수 있지만, 실제 구성, 상태, 자동화 결과에서 나온 관찰만 무엇이 일어났는지 보여줍니다.

따라서 증거 사슬은 발견을 지나 계속되어야 합니다. 소스 검색과 파서 결과를 보존합니다. 그래프를 소비한 애플리케이션 결정을 기록합니다. 기대한 노드나 제약을 접근 가능한 데이터스토어와 비교합니다. 구성, 텔레메트리 또는 자동화 결과와 함께 예외의 소유자를 보존합니다.

Running-Code Primacy는 모델을 거부하는 것이 아닙니다. 모델의 존재가 런타임 주장을 정할 수 있게 두지 않는다는 거부입니다.augmented-by는 모델 간 조인을 개선합니다. 선언된 스키마, 클라이언트 해석, 실행 동작 사이의 마지막 구간을 지우지는 않습니다.

출처