요약

  • BIRD CLI를 JSON으로 바꾸는 도구를 쓰던 사용자들은 변환 규칙까지 관리해야 했고, 표준 API를 요구했다.
  • 통합 API의 승부처는 접속 방식보다 여러 구성 요소의 모델을 잇고 각 값의 기준을 보존하는 데 있다.

BIRD 사용자들은 명령행 출력을 읽어 JSON으로 바꾸는 외부 도구를 이용했다. 관리 프로그램은 BIRD가 보여주는 CLI 형식을 이해한 다음 자기 데이터에 맞게 값을 변환해야 했다. 사용자들이 표준 API를 요구한 이유가 여기에 있다. 데이터마다 별도 해석기를 붙이는 일은 라우팅 데몬 바깥에서 반복되는 통합 작업이었다. Maria Matejka는 RIPE 93에서 그 요구를 출발점 삼아 라우터 전체의 API 설계를 짚었다.

클라이언트의 접속 조건은 그 설계를 세 갈래로 나눴다. 설정을 다루는 NETCONF은 SSH 세션을 유지한다. 브라우저처럼 요청 뒤 연결을 닫는 클라이언트에는 HTTP 기반 RESTCONF이 맞는다. 제약이 큰 장비를 위한 CORECONF은 CoAP과 CBOR을 택한다. 이 차이는 어떤 경로로 데이터를 주고받을지 정한다. 그 경로가 정해진 뒤에도 남는 질문은 어느 데이터 모델을 기준으로 삼느냐다.

Matejka의 Linux 라우터 예에는 BIRD, NetworkManager, systemd가 함께 등장한다. 각 소프트웨어는 다른 기능을 맡고 자체 데이터 트리를 관리한다. 라우터를 조립하는 통합자는 이 트리들을 하나의 고객용 엔드포인트로 연결해야 한다. 그때 API는 세 통로를 한 화면에 보여주는 데서 끝날 수 없다. 각 필드가 어느 모델에 속하는지와 어떤 값이 기준인지도 유지해야 한다.

IPv6 주소의 사례가 그 기준을 드러낸다. 주소는 내부에서 16바이트로 저장되고 외부 인터페이스에서는 문자열로 표현될 수 있다. YANG 데이터 저장소와 프로그램 내부 구조 중 어느 쪽을 정본으로 삼을지, 둘의 값이 달라질 때 무엇을 따라야 하는지 결정해야 한다. Matejka는 스키마 없이 프록시를 만들 수 없다고 설명했고, XML이나 JSON으로 형식만 바꾸는 방식도 의미 연결을 대신하지 못한다고 했다. 그래서 YANG 기반 파서와 인코더가 미래 프록시의 후보로 등장한다. 통합 규칙의 기준도 결국 각 필드의 출처와 모델 소유권이다.

이 기준을 어떤 프로토콜 위에 구현할지 검토할 때 CORECONF의 일정이 영향을 준다. 2026년 10월 31일 IETF Datatracker에는 21판이 만료된 Internet-Draft로 남아 있었고, IESG 제출은 다음 달 워킹그룹 일정으로 표시됐다. 예정된 제출과 실제 새 초안은 다른 상태다. CoAP과 CBOR을 선택하는 팀은 이 기록이 갱신되는지 확인해야 표준화 경로의 기준점을 잡을 수 있다.

이 발표가 통합자에게 남긴 일은 명확하다. 단일 엔드포인트가 각 구성 요소에서 값을 읽고 제한된 설정 변경을 처리하면서, 어떤 모델이 그 값을 소유하는지 보여줘야 한다. BIRD, NetworkManager, systemd를 함께 다루는 시험에서 IPv6 주소의 기준과 필드 출처가 일관되게 유지되면, 운영자는 그 인터페이스가 실제 관리 계약인지 확인할 수 있다.

1차 자료: RIPE 93 세션 · 공식 녹취록 · BIRD 팀 · RFC 6241 · RFC 6242 · RFC 8040 · RFC 7950 · RFC 7951 · RFC 9254 · CORECONF 초안 상태.