요약

  • RIPE NCC는 2026년 11월 3일 중앙유럽시간 21시 06분 58초 RPKI Dashboard 전용 유지보수 기록을 completed로 바꿨다. 시작 기록은 21시 00분 08초였다. Access, LIR Portal, 데이터베이스의 별도 작업은 21시 08분 이후에도 진행 중이었고 그 대상 목록에 같은 대시보드가 들어갔다.
  • 공개 구성 요소 목록은 전용 작업이 완료된 뒤에도 대시보드를 under_maintenance로 표시했다. RIPE는 로그인, 대시보드 열기, ROA 제출을 연속으로 성공했는지 보여 주는 테스트 결과를 내놓지 않았다.

운영 티켓 하나를 닫는 일과 회원이 실제 작업을 할 수 있는 상태는 같은 문장이 아니다. 11월 3일 RIPE NCC의 상태 기록은 그 차이를 한 화면에 펼쳐 놓았다. RPKI System Maintenance 전용 기록은 21시 06분 58초 CET completed가 됐다. in_progress가 된 지 약 6분 50초 만이다. 대상 구성 요소는 RPKI Dashboard. 이 기록만 읽으면 관리 화면의 유지보수는 깔끔하게 끝난 듯하다.

그러나 Access, LIR Portal, RIPE 데이터베이스 작업 기록에도 실행 중 RPKI Dashboard가 들어갔다. 21시 08분 58초 업데이트는 작업이 계속된다고 알렸고, 21시 41분이 지난 뒤 저장한 응답에서도 상태는 in_progress였다. 예정 종료는 21시 40분을 거쳐 21시 59분으로 바뀌었다. 구성 요소 상태 API는 Dashboard의 under_maintenance 표시가 21시 08분 58초에 갱신됐다고 기록한다. 전용 티켓 완료보다 약 2분 뒤다. Access는 21시 41분 21초 operational로 돌아왔지만 Dashboard, Portal, 데이터베이스에는 유지보수 표시가 남았다. 두 문구 모두 RIPE가 공개한 것이다.

두 번째 티켓의 구성도 바뀌었다. 작업 전 저장한 기록에는 데이터베이스, 포털, 계정 접근만 있었고 예정 종료는 21시 10분이었다. 진행 중 저장한 두 기록에는 대시보드가 네 번째 요소로 추가됐고 종료 예정은 21시 40분, 다시 21시 59분으로 바뀌었다. API에는 시작과 진행 상황 업데이트가 남아 있다. 대시보드를 언제 왜 추가했는지, 예정을 합계 49분 뒤로 옮긴 이유를 설명하는 날짜 있는 변경 내역은 없다. 이전 응답을 보관하지 않은 독자는 현재 티켓이 원래 무엇을 약속했는지도 알 수 없다.

실제 종료는 마지막 예정 시각보다 빨랐다. Dashboard 구성 요소는 21시 46분 51초 operational로 돌아왔고 두 번째 티켓은 21시 47분 19초 완료됐다. 21시 06분 58초 전용 RPKI 티켓 종료부터 구성 요소의 운영 상태까지 39분 52초, 두 티켓의 완료 공지 사이에는 40분 21초가 있었다. 21시 59분은 수정된 계획이지 실제 종료가 아니다. 이 간격은 공개 상태 표시의 차이이며 회원의 접속 불가 시간을 측정한 값은 아니다.

상태 단어를 사용자 경험의 측정값으로 바꾸면 사건을 잘못 읽는다. completed는 한 작업 기록에 종료 공지가 붙었다는 뜻이다. under_maintenance는 공개 상태 시스템이 그 순간 구성 요소에 달아 둔 이름이다. 어느 쪽도 회원이 21시 07분에 로그인하거나, 21시 22분에 화면을 열거나, 21시 31분에 ROA를 제출할 수 있었는지 증명하지 않는다. RIPE의 호스팅 RPKI 안내에 따르면 회원은 LIR와 연결된 RIPE NCC 계정으로 Dashboard에 들어가 경로 출처 인증을 관리한다. Access 안내도 Dashboard를 그 계정의 서비스로 둔다. 회원의 한 가지 행동이 두 티켓 사이를 가로지른다.

그래서 물어야 할 것은 단순히 어느 티켓이 먼저 끝났느냐가 아니다. 대시보드 전용 티켓을 닫은 뒤에도 두 번째 티켓이 그 구성 요소의 공개 상태를 붙잡고 있었는가? 아니면 표지가 이미 사용 가능한 서비스보다 늦게 바뀌었는가? 공식 자료에는 회원 경로를 끝까지 시험한 결과가 없다. 서비스가 실제로 작동했더라도, 상태 페이지를 읽는 회원은 그 사실을 확인할 수 없었다. 상태 페이지의 역할은 회원에게 둘 중 하나를 추측하게 하는 것이 아니다.

RIPE는 내부 작업마다 별도 티켓을 쓸 수 있다. 그 대신 구성 요소마다 권위 있는 상태 하나와 그것을 통제하는 열린 티켓을 보여 줘야 한다. 대상 구성 요소나 예정 종료 시간을 고칠 때도 시각과 이유를 남겨야 한다. 마지막에는 계정 로그인, Dashboard 로딩, ROA 제출을 시험했는지 적으면 된다. 그때 ‘완료’는 관리자 화면의 초록 도장이 아니라 운영자가 행동을 결정할 수 있는 정보가 된다.

RIPE NCC 원문 기록