USB 동시 연결이 끊겨 무선으로 바꾼 일

기기를 찾을 수 없다는 보고

개인 서비스를 만들면서 AI 에이전트가 실제 기기를 조작해 화면을 확인하는 환경을 꾸렸다. 안드로이드와 아이폰을 함께 개발했고, 스마트폰·태블릿·폴더블의 서로 다른 화면 비율도 보고 싶었다. 여러 기기에서 스크린샷을 한꺼번에 찍으려고 USB로 연결했다.

그런데 에이전트가 기기를 찾을 수 없다고 보고했다. 전송 도중 연결이 끊기는 일이 반복됐다. 연결 방식을 바꾸고 전원을 직접 공급해보기도 했지만 같은 증상이 있었다. 허브나 독에 여러 대를 물렸을 때 특히 심했고 충전도 느려 보여, 전원이 모자라는 것은 아닌지 의심했다.

결국 문제가 있던 안드로이드 기기에 별도 전원을 공급하고 데이터 연결은 무선 ADB로 바꿨다. 그 뒤 여러 기기에서 동시에 캡처하는 작업을 끝까지 마쳤다. 다만 전원과 연결 방식을 함께 바꿨으므로, 처음 끊김의 원인이 허브·케이블·호스트·드라이버 중 정확히 무엇이었는지는 확정하지 못했다.

충전선과 데이터 연결을 나눴다

ADB(Android Debug Bridge)는 개발 PC에서 안드로이드 기기에 앱을 설치하거나 명령을 보내는 도구다. 무선 디버깅을 지원하는 기기에서는 PC와 기기를 페어링하고 Wi-Fi로 연결할 수 있다. 내가 바꾼 것도 이 데이터 통신 경로였다. 기기를 충전할 전원은 여전히 필요했다. Android 무선 디버깅 안내

페어링은 이 PC와 기기가 서로 연결하도록 허용하는 절차다. 한 번 페어링했다고 해서 어느 때나 연결돼 있는 것은 아니다. 무선 디버깅이 켜져 있고 같은 네트워크에서 서로를 찾을 수 있어야 한다. ADB는 페어링된 기기를 자동으로 찾을 때 mDNS를 사용한다. 내 운영 규칙에서도 연결 주소를 고정해두지 않고 그때그때 검색하도록 했다. USB 전송 문제를 피한 대신 무선 연결 상태도 살펴야 했다. ADB 연결 문제 확인

여기까지는 안드로이드 이야기다. 아이폰과 아이패드는 별도의 연결 도구와 WebDriverAgent를 사용하는 환경이었다. 여러 운영체제의 기기를 한 책상에 두었다고 해서 연결 방법까지 하나가 된 것은 아니었다.

다른 기기로 성공하면 다른 결과다

연결 문제를 다루면서 에이전트에게 한 가지 규칙을 더했다. 지정한 기기를 찾지 못하면 다른 기기나 다른 연결 방식으로 알아서 바꾸지 않도록 했다. 개발 중 다른 기기로 연결돼 로그인 상태나 설정이 달라진 것은 아닌지 의심한 일이 있었기 때문이다.

이 규칙의 이유를 예로 들어보면, 폴더블의 넓은 화면을 확인하려던 작업에서 연결이 안 된다고 일반 스마트폰을 골라 캡처할 수 있다. 사진은 얻었지만 원래 보려던 화면은 확인하지 못한 셈이다.

ADB에도 여러 기기 중 대상을 지정하는 방법이 있다. 기기 목록을 확인하고 -s 옵션으로 대상 식별자를 넘긴다. 다만 대상을 지정하는 명령만으로 에이전트가 작업 도중 다른 기기를 선택하는 것까지 막아주지는 않는다. 실패를 어떻게 보고하고 다음 행동을 어디서 멈출지는 작업 규칙에도 있어야 했다. ADB 대상 기기 지정

그래서 연결이 안 되면 그 기기에서 작업할 수 없다고 알리고, 재부팅이나 재연결을 시도하도록 했다. 그래도 안 되면 사람에게 확인을 요청한다. 다른 기기에서 성공한 결과로 원래 기기를 통과시키지는 않는다.

연결 다음에도 확인할 것이 남았다

개인 QA 문서에서는 연결됨, 도구로 접근 가능, 필요한 화면 준비, 검증 완료를 나눠두었다. 기기 목록에 이름이 보여도 조작 도구가 접근하지 못할 수 있다. 조작이 되더라도 필요한 계정으로 로그인돼 있는지, 확인할 화면까지 왔는지는 별개다. 캡처를 얻은 뒤에도 실제로 살피려던 동작이나 배치가 맞는지 봐야 한다.

이 구분은 화면 파일 하나를 받았을 때 무엇까지 확인됐는지 설명해준다. 같은 이유로 당시 캡처가 성공했다는 기록을 계속 연결이 안정적이라는 뜻으로 읽지는 않는다. 이후 상태를 확인한 날에는 일부 무선 기기가 목록에 없기도 했다.

노트북을 재부팅하면 다시 연결해야 했고, 노트북을 들고 나가면 연결 환경도 사라졌다. 그 불편 때문에 전용으로 쓸 작은 PC를 따로 두었다. 더 큰 PC나 전원 공급이 좋은 허브를 골랐으면 어땠을까 생각은 했지만, 대안별 비용과 성능을 측정해 비교한 것은 아니다. 내 상황에서는 별도 전원과 무선 연결로 작업을 이어갈 수 있었다.

로봇을 만들던 때에도 연결 실패를 보고 전원을 살핀 적이 있었다. 이번에는 거기에 확인할 대상이라는 문제가 더해졌다. 화면을 얻는 데 성공했는지와 원래 확인하려던 기기를 확인했는지를 따로 기록할 필요가 있었다.