요약

  • RIPE NCC에 따르면 새 RISwhois-rs는 기존에 테스트가 없던 경로 조회기에 테스트 스위트를 더했고, 데이터 갱신을 8시간마다에서 1시간마다로 바꿨다.
  • 서비스가 답하는 질문은 구체적이다. RIPE RIS 수집기가 어떤 프리픽스와 기원 AS를 어디서 언제 관측했는가. 공개된 자료에는 테스트 목록과 전환 일정이 아직 없다.

익숙한 명령어, 새 엔진

whois -h riswhois.ripe.net 193.0.0.1은 무대에서 박수를 받으려는 명령어가 아니다. 대시보드를 찾아 헤매기 전에 터미널에서 답을 확인하려는 명령어다. RIPE NCC의 RISwhois는 2003년부터 RIPE 경로 수집기가 받은 BGP 데이터를 빠르게 조회하는 창구였다. 응답은 RPSL과 비슷한 형식이라 네트워크 운영자와 기존 도구가 읽기 쉽다.

10월 26일 RIPE 93에서 RIPE NCC 개발자 Sam van Kampen이 후속 서비스 RISwhois-rs를 소개했다. 공식 회의 보고에 따르면 새 버전은 최근 몇 달 동안 만들어졌다. 기존 서비스에는 테스트 스위트가 없어 개발에 제약이 있었고, 팀은 이제 테스트를 추가했다. 데이터도 이전의 8시간 주기 대신 매시간 갱신할 수 있다.

RIPE NCC의 첫 Rust 프로덕션 서비스가 WHOIS 스타일 조회기라는 점은 제법 재미있다. 이용자에게 보이는 입구는 오래된 방식 그대로지만, 내부 엔진은 세대를 바꿨다. 코드를 고치는 사람은 이제 수동 조회 몇 번에 기대지 않고 반복 가능한 검사로 변경을 확인할 수 있다.

조회 결과가 보여주는 것

RISwhois는 관측된 라우팅 데이터를 조회한다. IP 주소, 프리픽스 또는 ASN을 입력하면 일치하는 프리픽스, 기원 AS, 경로를 본 수집기, 갱신 시각, 이를 관측한 RIS 피어 수 등이 응답에 들어갈 수 있다. -R 옵션은 RPKI 기원 검증 정보를 덧붙인다. 일부 traceroute 도구도 WHOIS 서비스를 이용해 홉마다 ASN을 표시한다.

출력 형식도 제품의 일부다. RIS가 특정 공지를 받았는지 확인하려고 새 웹 화면부터 배울 필요가 없다. 명령줄 클라이언트가 포트 43으로 요청을 보내면 RPSL 스타일의 구조화된 응답이 온다. 스크립트, 엔지니어, 진단 도구가 같은 입구를 공유한다.

2003년 발표부터 이 용도는 분명했다. RIPE NCC는 당시 10개의 원격 경로 수집기와 200개가 넘는 IPv4·IPv6 피어를 설명했다. RISwhois는 최근 라우팅 테이블 스냅샷을 합쳐 프리픽스가 어느 수집 지점에서 보였는지, 어떤 AS가 기원인지 보여줬다. 수집기의 관측을 기존 도구가 이해하는 형식으로 조회하게 하는 것이 목적이었다.

그러므로 답변을 읽을 때는 질문도 구체적으로 잡으면 된다. “이 수집 체계는 어느 지점에서 몇 시에 무엇을 받았나?” 그 관측 시각을 운영자의 로그와 경보에 맞춰 놓으면 된다. 응답은 참여 수집기가 받은 경로를 기록한다. 바로 그 외부 관측이 공지의 가시성을 조사할 때 쓰인다.

8시간을 1시간으로

기존 갱신 주기는 8시간이었다. 매시간 갱신하면 계획된 스냅샷 사이 간격이 줄어든다. 라우팅 변경이 진행 중일 때 담당자는 다음 데이터를 위해 근무 시간의 대부분을 기다리지 않고 조회를 다시 실행할 수 있다.

장애 조사 속도도 바뀐다. 새 공지가 관련 수집기에 도달했는지 더 빨리 확인하고, RIS 관측을 더 최근의 RPKI 결과와 비교할 수 있다. 자동 모니터링도 데이터 시계를 짧게 잡을 수 있다. 다음 계획 조회가 최대 일곱 시간 앞당겨진다.

RISwhois는 스냅샷을 매시간 갱신한다. RIPE NCC의 RIS Live는 BGP 메시지가 들어오는 흐름을 거의 실시간으로 보여준다. 앞쪽은 수집된 데이터 조회, 뒤쪽은 메시지 흐름이다. 이번에 공개된 주기는 8시간에서 1시간으로 줄었다.

dump, dump6 다운로드 파일도 별도의 경로다. 현재 문서는 파일이 요청 시 생성되며, 서비스의 같은 이름 명령에 대응한다고 설명한다. 조회 서비스 갱신 시각이 다운로드 파일의 생성 시각을 자동으로 알려주지는 않는다. 두 시각은 따로 표시돼야 한다.

테스트는 오래된 코드를 고칠 때 내는 통행료를 낮춘다

“테스트 스위트가 없었다”는 짧은 문장이지만 서비스 기능을 보면 무게가 달라진다. RISwhois는 여러 조회 방식을 받고, 구조화된 답을 내고, 호환 옵션을 유지하며, RPKI 필드를 추가할 수 있다. 각 기능은 코드 변경 때 기존 클라이언트가 깨질 수 있는 지점이다.

테스트 스위트는 유지할 동작을 기록하고 코드가 바뀔 때마다 다시 확인하는 기준을 제공한다. 주소·프리픽스 검색, 정확 일치와 더 구체적인 일치, IPv4·IPv6, 지속 연결, 시각 표시, 피어 수, RPKI 필드, 잘못된 입력 등이 테스트 대상이 될 수 있다. RIPE NCC의 회의 보고는 실제 목록을 공개하지 않아 어떤 호환 동작이 검증되는지는 아직 볼 수 없다.

Rust도 유지보수 이야기의 일부다. RIPE NCC는 RISwhois-rs를 첫 Rust 프로덕션 서비스라고 부르며, 이 언어가 제대로 만들기 쉬운 환경을 제공한다고 설명했다. 공식 보고는 속도, 유지보수성, 확장성을 목표로 든다. 지연시간 비교, 공개 저장소, 테스트 결과는 아직 공개되지 않았다.

눈에 보이는 운영 변화는 매시간 갱신이다. 덜 보이는 변화는 다음 수정부터 되풀이 가능한 검사를 할 수 있게 된 점이다. 20년 넘게 이어진 서비스가 다음 변화를 받아들이려면 이런 지루한 바닥 공사가 필요하다.

다음 릴리스 노트에는 확인할 영수증이 필요하다

RISwhois는 20여 년 동안 간단한 약속을 지켰다. 익숙한 옛 문법으로 묻고, 관측된 경로를 짧게 확인한다. RISwhois-rs는 익숙한 입구를 남긴 채 구현을 바꾸고 갱신 간격을 줄였다.

RIPE NCC의 다음 공지에는 프로덕션 전환일, 클라이언트 스크립트 수정 필요 여부, 테스트가 다루는 요청·응답 목록, 실제 측정한 조회시간 비교가 담겨야 한다. 버전이 붙은 호환성 표가 있으면 기존 서비스가 사라지기 전에 운영자가 파서를 점검할 수 있다. “다시 만들었다”는 말이 무엇이 바뀌었고 어떻게 확인할지 보여주는 배포 기록으로 바뀐다.

1차 자료: RIPE NCC의 2003년 RISwhois 출시 공지 · RISwhois 공식 문서 · RIPE 93 Sam van Kampen 발표 페이지 · 2026년 10월 26일 RIPE 93 회의 보고.