요약

  • recommended-min-version는 숫자형 임포트 힌트이다. YANG Semantic Versioning 드래프트 개정판 28은 비교 시_compatible,_non_compatible, 프리릴리스 및 빌드 메타데이터를 무시하며, 더 높은 주 버전이 조건을 충족하는 것을 의도적으로 허용한다고 명시한다.
  • 따라서 리졸버는 하위 호환성이 아니라 적격성을 확정한다. 컴파일러는 적격한 버전을 찾지 못할 때 경고를 발생한 뒤 RFC 7950 규칙에 따라 계속 진행할 수도 있으므로, 스키마가 완성되었다는 사실이 권고가 충족되었다는 증거가 되지는 않는다.
  • 배포 전에 운영자는 요청을 모든 후보, 정확히 선택된 바이트, 전체 모듈/패키지 집합, 기능, 편차(deviation), 경고 상태, 클라이언트 테스트, 결정 책임자, 롤백 대상과 연결하는해결 영수증이 필요하다. 이 영수증은 Daniel Kade의 제안이며, IETF 요구 사항이 아니다.

임포트 라인에서 가장 작은 단어가 가장 큰 가정을 품고 있다

"최소(minimum)"는 호감을 주는 단어다. 조달에서는 그 아래로 내려가면 제품이 기각되는 문턱처럼 들리고, 보안에서는 강제되는 기준선처럼 들리고, 일반적인 소프트웨어 의존성 시스템에서는 흔히 익숙한 주 버전 관례를 전제로 그보다 큰 값이라면 호출자가 필요로 하는 것을 보존한다는 뜻으로 읽힌다. 이 단어를 시맨틱 버전 옆에 놓으면 많은 독자는 알고리즘을 읽기도 전에 하나의 약속을 먼저 떠올린다.

현행 NETMOD 드래프트는 더 정확하고 덜 안심시키는 입장이다. 2026년 7월 21일에 공개되어 현재 RFC Editor Queue에 있는draft-ietf-netmod-yang-semver-28은recommended-min-version을 YANGimport문 아래의 확장(extension)으로 정의한다. 그 인자는 주, 부, 패치 세 개의 정수뿐이다. 리졸버가 후보를 비교할 때는 YANG 고유의 두 호환성 수식자와 모든 프리릴리스·빌드 메타데이터를 무시한다.

적격 판정은 의도적으로 넓다. 숫자 삼중항이 정확히 같으면 통과한다. 주와 부가 같은 채 패치가 더 크면 통과한다. 주가 같은 채 부가 더 크면 통과한다. 주가 더 크면 부와 패치 값에 관계없이 통과한다. 권고가 3.1.0인 경우, 드래프트 자체가 3.1.2_non_compatible와 4.1.2를 조건을 충족하는 버전으로 나열한다. 첫 번째는 하위 호환되지 않는 분기 변경을 선언한 것이고, 두 번째는 더 큰 주 버전을 가진 것으로, YANG Semver에서 주 버전은 하위 호환되지 않는 변경을 의미한다. 둘 다 숫자상으로는 적격하다.

이는 명세의 모순이 아니다. 5.2절은 이 승인이 의도적이라고 설명한다. 임포트 규칙은 단순하게 유지하고, 일관된 모듈 버전 집합을 고르는 책임은 예컨대 YANG 패키지처럼 확장 밖에 두도록 기대한다는 것이다. 문제는 통사적이 아니라 제도적이다. 도구는 권고가 충족되었다고 사실대로 보고할 수 있지만, 변경 심의회·컨트롤러 팀·자동화 파이프라인은 전혀 다른 주장, 즉 "만들어진 스키마가 현재 운영 중인 것과 호환된다"는 주장을 듣게 된다.

버전 신호는 판결이 아니기 때문에 유용하다

YANG Semver는 유용한 정보를 더한다. 주 버전 변경은 메인 라인 전체에서 하위 호환되지 않는 개발을 식별한다. 부 버전 변경은 대체로 하나의 주 라인 내에서 하위 호환되는 추가를 나타낸다. 수식자 없는 패치 변경은 편집상의 변경이다._compatible과_non_compatible접미사는 제한된 유지보수 분기를 판독 가능하게 만들며, 후자는 분기 내에서 고착(sticky)되어 이후의 편집상 변경이 경고를 지우지 않는다.

이러한 규칙은 사람이나 도구가 저자가 선언한 변경 클래스를 이해하려고 모든 파일을 열어 보는 일을 막아줄 수 있다. 드래프트는 또한 아티팩트 이름과 시맨틱 버전의 조합이 하나의 개정판을 식별해야 하며, 다른 콘텐츠가 같은 쌍을 재사용해서는 안 된다고 요구한다. 이는 의미 있는 수명 주기 규율이다.

그러나 라벨은 여전히 하나의 입력일 뿐이다. 라벨은 버전 관리 정책에 따라 부여되는 것이며, 모든 소비자의 동작을 증명하는 계산 결과가 아니다. 하위 호환되는 스키마 변경도 생성된 코드의 버그를 노출시킬 수 있고, 로컬 명명 가정과 충돌할 수 있으며, 열린 열거형을 닫힌 것으로 취급하던 애플리케이션을 바꿔 놓을 수 있다. 기술적으로 편집상의 변경도 지나치게 경직된 공급망 통제에는 서로 다른 바이트로 인식될 수 있다. 정확한_non_compatible라벨은 크게 경고하지만, 최소 버전 비교는 그 경고를 사용하지 않도록 설계되어 있다.

파일 식별조차도 위험의 전부는 아니다. 드래프트는 서브모듈 자체의 콘텐츠나 개정판이 바뀌지 않았는데도, 다른 서브모듈이 공급하는 그룹핑이나 typedef가 바뀌면서 서브모듈의 의미가 크게 달라질 수 있다고 지적한다. 단일 파일 해시는 어떤 파일을 받았는지는 증명하지만, 그것만으로 포함하는 모듈이 만들어낸 유효 스키마가 무엇인지는 증명할 수 없다.

그래서 올바른 독해는 소박하다. 시맨틱 버전은 아티팩트 저자가 선언한 계보의 구조화된 증거일 뿐이며, 암호학적 다이제스트도, 패키지 잠금(lock)도, 적합성 결과도, 배포 승인도 아니다.

해결에는 서로 다른 세 가지 성공 상태가 있다

운영 파이프라인은 대시보드가 흔히 "해결됨"으로 압축하는 결과 중 적어도 세 가지를 구분해야 한다.

첫째는권고 충족이다. 어떤 후보가 시맨틱 버전 드래프트의 숫자 규칙을 충족했다. 이것이 가장 좁은 성공이며, 이를 소비하는 클라이언트에 대해서는 아무것도 말해주지 않는다.

둘째는폴백 완료이다. 컴파일러가 자신이 유효하다고 판단한 후보를 찾지 못해 경고를 발생시키고, 확립된 RFC 7950 임포트 규칙에 따라 계속 진행한 경우다. RFC 7950에서 명시적revision-date결합은 정확히 일치해야 하며, 이 하위 명세문이 없으면 언어 수준에서 개정판은 정의되지 않는다. 경고 후 완료된 컴파일러는 사용 가능한 스키마를 만들어냈을 수 있지만, 그렇다고 폴백이 누락된 권고의 충족으로 전환되는 것은 아니다.

셋째는배포 수용이다. 정확히 해결된 스키마가 그것에 의존할 클라이언트, 컨트롤러, 구성, 운영 절차에 대해 검토되고 실제로 실행되어 본 경우다. 이 판단은 배포 환경의 몫이다.

이 세 상태는 갈라질 수 있다. 권고는 현재 컨트롤러가 파싱할 수 없는 버전에 의해 충족될 수 있다. 폴백은 기본 문법 검사는 통과하지만 모듈 저자가 기대했던 것보다 오래된 typedef를 포함하는 스키마를 만들어낼 수 있다. 패키지는 깨끗하게 해결되는데 활성화된 기능이 클라이언트에게 보이는 노드를 바꿔 놓을 수 있다. 셋 모두 초록불 빌드로 표시되면, 조직은 자신이 임포트 의도를 존중했는지, 단지 컴파일을 마쳤는지, 아니면 운영 전환을 증명했는지를 구별할 능력을 잃는다.

호환성의 대상은 하나의 숫자가 아니라 해결된 스키마이다

RFC 8525의 YANG Library가 더 넓은 틀을 제공한다. 데이터스토어 스키마는 모듈 집합의 합집합이다. 모듈 집합에는 구현된 모듈, 임포트 전용 모듈, 그리고 이들의 서브모듈이 포함되고, 구현된 항목은 지원 기능과 편차 모듈도 광고한다.content-id는 YANG Library 콘텐츠가 바뀔 때 바뀐다. 따라서 유효 관리 표면은 하나의 임포트에서 승리한 개정판 이상에 달려 있다.

YANG 패키지 드래프트는 이 구성을 명시적으로 만든다. 패키지는 모듈들이 집합적으로 하나의 스키마를 정의하는 버전화된 계층 구조다. 다른 패키지, 구현된 모듈, 임포트 전용 모듈, 활성화된 기능을 포함할 수 있고, 상속된 모듈이나 기능을 제외할 수 있다. 패키지 충돌 시 더 최신 모듈 버전을 자동으로 고르는 해결 규칙을 가질 수 있는데, 이는 핫픽스에 유용하다. 더 오래된 버전을 고르는 데는 수동적인 선호가 아니라 명시적인 정제(refining) 패키지가 필요하다.

패키지는 일관된 집합에 이름과 해결 가능한 구조를 부여하므로 거버넌스를 개선한다. 그러나 결과를 검사할 필요를 없애지는 않는다. 드래프트는 핫픽스나 논리적 그룹핑 같은 용도를 위해 불완전한 패키지를 허용하며, 의존성은 컨텍스트에서 해결될 수 있다. 패키지가 데이터스토어 스키마에 결합될 때는 해결된 패키지 스키마와 추가 기능이 YANG Library 모듈 집합과 정확히 일치하고 참조적으로 완전해야 한다. 이는 강한 검증이지만, 스키마 구성에 대한 검증일 뿐 특정 클라이언트가 안전하게 동작한다는 증명은 아니다.

편차(deviation)가 이 구분을 구체적으로 만든다. 모듈 개정판은 익숙한데 서버의 편차 집합이 컨트롤러가 기대하는 노드에 대한 지원을 제거하거나 제약하거나 바꿀 수 있다. 기능 선택도 마찬가지로 어떤 분기가 존재하는지를 바꿀 수 있다. 패키지 버전, 모듈 버전, content-id는 변경 기록이 자신이 식별하는 컨텍스트를 명명할 때만 유용하다.

스키마 비교는 변화를 측정하지 결과를 측정하지 않는다

관련 스키마 비교 작업은 YANG 스키마 간 차이에 대한 어휘와 기계 가독 출력을 제공한다. 이는 버전 번호가 답할 수 없는 질문, 즉 어떤 명세문이 바뀌었고 그 변화가 비교 모델에서 어떻게 분류되는지를 답할 수 있다. 진지한 업그레이드 검토에 포함될 자격이 있다.

그러나 여전히 마지막 한 구간 앞에서 멈춘다. 디프는 클라이언트의 생성된 바인딩을 실행하지 않는다. 어떤 자동화 스크립트가 리프가 항상 존재한다고 가정하는지, 어떤 인벤토리 수집기가 낯선 아이덴티티를 거부하는지, 어떤 컨트롤러가 오류를 파괴적인 재시도로 사상하는지 알지 못한다. 대표 구성이 검증되는지, 상태 구독이 안정적인지, 롤백이 모델과 애플리케이션 상태를 모두 복구하는지 관찰할 수 없다.

호환성은 관계적이다. 그것은 해결된 스키마와, 어떤 워크로드와 어떤 가정 아래의 소비자 사이에 성립한다. 같은 스키마가 유연한 브라우저에는 수용 가능하고, 닫힌 타입으로 컴파일된 컨트롤러에는 안전하지 않을 수 있다. 따라서 증거는 이 관계의 양쪽을 모두 명명해야 한다. "스키마 4.1.2가 비교를 통과했다"는 기록은, 어느 이전 스키마에 대해, 어떤 비교 정책으로, 어느 소비자들을 위해 테스트되었는지를 말해주지 않으면 불완전하다.

배포 권한을 부여하기 전에 해결 영수증을 만들어라

recommended-min-version가 빌드, 테스트 또는 프로덕션에 도달하는 임포트에 영향을 줄 때마다해결 영수증을 작성해야 한다. 영수증은 또 하나의 전역 레지스트리가 아니며 리졸버를 느리게 할 필요도 없다. 리졸버가 무엇을 했는지, 그리고 배포 소유자가 그 이후 무엇을 증명했는지에 대한 내구성 있는 기록이다.

임포팅 모듈부터 시작하라: 정확한 이름, 개정판, 존재하는 경우 전체 시맨틱 버전, 콘텐츠 해시, 원본 위치. 요청된 숫자 삼중항을 쓰인 그대로 기록하라. 그다음 도구에 보이는 전체 후보 목록을 전체 버전 문자열과 위치를 포함해 캡처하라. 이는 결정 알고리즘이 정보를 버리기 때문에 중요하다. 영수증은 수식자와 메타데이터가 무시되었다고 명시하면서 그 원래 값을 보존해야 하며, 검토자가 3.1.2_non_compatible가 다른 선택보다 우선했거나 공존했음을 볼 수 있어야 한다.

선택된 개정판에 대해서는 정확한 바이트 또는 안정적인 콘텐츠 다이제스트, 개정일, 시맨틱 버전, 취득 출처를 보존하라. 기록을 해결된 전체 집합으로 확장하라: 포함된 모듈과 임포트 전용 모듈, 서브모듈, 패키지의 포함과 제외, 활성화된 기능, 편차, 마운트 컨텍스트, YANG Library의 content-id 또는 오프라인 등가물. 각 패키지가 해결 전에 완전했는지, 어떤 충돌 규칙이 각 승자를 골랐는지 표시하라.

도구의 동작도 같은 증거 사슬에 속한다. 컴파일러 또는 리졸버의 이름과 버전을 명명하라. 경고를 보존하라. 시맨틱 권고가 충족되었는지, 아니면 실패 후 RFC 7950 폴백으로 계속되었는지 명시하라. 스키마 비교의 기준선, 정책, 결과를 저장하되, 그 결과를 클라이언트 보증으로 격상시키지 마라.

마지막으로 소비자 증명을 기록하라: 어느 컨트롤러, 에이전트, 생성기 또는 검증 서비스가 테스트되었는지; 어느 대표 구성, RPC, 알림, 상태 경로가 실행되었는지; 무엇이 실패했는지; 남은 불확실성을 누가 수용했는지; 롤백 대상이 어느 이전 해결 집합인지. 배포 범위와 만료가 중요하다. 하나의 실험실 컨트롤러에 대한 승인이 같은 저장소를 공유하는 모든 클라이언트를 묶어서 승인하지는 않는다.

이 영수증은 편리한 단어 — 최소 — 를 감사 가능한 사슬로 바꾼다. 시맨틱 버전 확장에게 패키지 관리, 클라이언트 테스트, 조직적 권한까지 해결하라고 요구하지 않는다. 대신 그 책임들이 존재한다는 사실을 가시화한다.

출처