요약

  • LACNIC 46 발표 자료는 14초 회선 단절 뒤 원인을 찾는 데 약 90분이 걸리는 추정 사례를 제시한다. 첫 고객 불만까지 23분, 수동 진단에 다시 67분이다.
  • 제안된 시스템은 syslog, RouterOS v7, RADIUS 세션과 토폴로지를 ISP 내부에 모아 언어 모델이 읽기 전용 SQL로 조회하게 한다.

장애는 끝났는데 조사 시계는 그제야 돈다. LACNIC 46 · LACNOG 2026의 인터넷측정작업반(IMWG) 발표에서 Joaquín Tadeo Riedmaier와 Santiago Agustín Zualet은 14초짜리 링크 단절을 예로 들었다. 첫 고객 불만이 들어오기까지 23분, 라우터를 하나씩 열어 로그를 뒤지는 데 67분. 원인을 찾기까지 약 90분이라는 계산이다.

이 시간표는 측정값이 아니다. 발표 자료는 이를 중대 장애의 전형적 추정 경로라 부르고 시간대는 설명용이라고 적었다. 두 발표자는 Universidad Nacional de Misiones 공과대학 소속이다. 이들이 겨눈 문제는 말로 질문하는 AI보다 앞에 있다. 로그가 장비마다 흩어져 있고 재부팅 뒤 사라지며, 무관한 이벤트가 원인 신호를 덮는다는 점이다.

수집 방식은 밀어 넣기와 가져오기를 함께 쓴다. UDP syslog는 링크 상태 변화, 오류, 플래핑, PPPoE/RADIUS 연결 해제를 보낸다. RouterOS v7 REST API는 인터페이스와 VLAN별 트래픽·오류·드롭, CPU와 메모리, ARP, 연결 추적 정보를 읽는다. RADIUS 세션 정보까지 NAS별로 붙이면 한 포트의 짧은 단절과 가입자 접속 변화가 같은 시점에 있었는지 확인할 수 있다.

수집 노드는 ISP 내부 Docker 환경에 둔다. Django가 syslog를 받고 API를 조회하며, Python이 잡음을 거르고 이벤트 형식을 맞춘 뒤 중복을 제거하고 임계값을 평가한다. PostgreSQL은 조회용 뷰를 저장한다. 언어 모델은 이 뷰를 대상으로 SQL을 만든다. 뷰를 단순화해 조인을 줄이고 DB 계정은 SELECT만 허용한다. 자료는 32GB 메모리 장비에서 모델을 시험했다고 쓰지만 모델명과 요청량, 응답시간은 밝히지 않는다.

예시 화면은 지난 네 시간 동안 발생한 link-down을 묻고, NAS 6의 ether2에서 일곱 번 끊겼으며 PPPoE 세션 23개가 영향을 받았다고 답한다. 화면에는 예시라고 명시돼 있다. 별도 그림은 L2/L3 오류, 연결 추적, RADIUS, PPPoE 신호가 12시 04분에 함께 나타난 상황을 만든 뒤 물리적 링크 장애를 가설로 제시한다. 이 자료 역시 시뮬레이션이며 측정 결과가 아니다.

알림과 조사는 서로 다른 단계다. 임계값 경보가 고객 항의보다 먼저 도착하고, 이후 대시보드와 자연어 질문으로 사건을 되짚는 구조다. 모델은 기록을 찾아주는 창이지 원인의 증거 그 자체가 아니다. syslog가 이벤트를 놓치거나 API 폴링 간격이 14초 장애보다 길거나 장비 시간이 맞지 않으면, 그럴듯한 답변도 사라진 사건 순서를 되살리지 못한다.

발표는 90분을 추정치, 18분을 기대 효과라고 부르지만 ISP 사고 표본, API 수집 간격, 도입 전후 진단시간, 오탐률, ‘95% 이상’ 목표의 측정 기준은 공개하지 않았으며 사고별 수치를 담은 현장 파일럿이 나오면 평가가 달라질 수 있다.

다음에 필요한 것은 더 유창한 챗봇이 아니라 시간이 찍힌 운영 기록이다. 언제 이벤트가 도착했고, 어떤 경보가 먼저 울렸고, 기술자가 언제 원인을 확정했는지 한 사건씩 남겨야 한다. 그 기록이 있어야 18분이라는 숫자가 ISP의 시간을 돌려주는지, 수동 조사에 새 화면만 덧붙이는지 가릴 수 있다.

출처: LACNIC 46 공식 일정; IMWG 원본 발표 자료.