키보드를 살렸더니 마이크가 죽었다
전편은 "무엇이 고쳤는지 모른다"는 관찰 대기로 끝났다. 그 대기는 아침을 넘기지 못했다 — 키 밀림이 이번엔 계측기 앞에서 재발했고, 도망친 곳에서는 마이크가 죽었다. 알고 보니 원인은 하나가 아니라 셋이었고, 전부 벗겨 내는 데 USB 컨트롤러 세 개가 필요했다. 종착지에 도착한 기록.
도미노 — 마이크가 넘어뜨리고 키보드가 받았다
전편의 처방은 키보드 체인을 다른 포트로 옮기는 것이었다. 그런데 그 체인 안에는 키보드만 사는 게 아니었다. 마이크가 키보드와 같은 허브에 살고 있었고, 체인이 이사하자 마이크도 함께 이사했고 — 새 동네에서 먹통이 됐다. 마이크가 급해서 체인을 원래 포트로 되돌렸더니, 이번엔 21분 만에 키 밀림이 재발했다. 한쪽을 살리면 다른 쪽이 죽는 진퇴양난.
수확이 없진 않았다. 이번 재발은 계측기가 도는 채로, 사용자 마커까지 찍혀서 왔다. 로그 재구성: C 를 짧게 쳤는데 해제 리포트가 유실됐고, OS 는 C 를 눌린 것으로 붙든 채 513ms 뒤 키 리피트를 돌리기 시작해 32ms 간격으로 C 가 18번 쏟아졌다. 그리고 다음 실제 키(M)를 누르는 순간 새 리포트가 도착하며 유령 C 가 풀렸다 — RAW UP C 와 DN M 이 1ms 간격. 전편에서 이론으로 그렸던 타임라인이 실측으로 그대로 재현됐다.
재발의 조건이 중요하다. 장치는 21분 전에 막 다시 꽂혀 신선하게 재열거된 상태였고, USB 선택적 절전은 전부 꺼 둔 뒤였다. 전편에서 "셋이 같이 바뀌어 모른다"던 변수 중 재열거와 절전이 이걸로 죽었다. 남는 것은 경로 — 그 온보드 허브(0608)를 지나는 것 자체다.
관찰 대기가 길어질 줄 알고 로그 감시를 느슨하게 걸어 뒀는데, 반나절도 안 돼 재발해 주었습니다. 수고를 덜었으니 고맙다고 해야 할지 아직 정리가 안 됩니다.
착시 1 — Windows 는 이사한 마이크를 새 마이크로 취급한다
키보드가 밀리는 포트를 계속 쓸 수는 없으니 체인은 다시 이주했고, 마이크 조사가 시작됐다. 첫 번째 층은 하드웨어가 아니었다. USB 오디오 장치는 꽂힌 경로가 바뀌면 Windows 가 완전히 새 장치로 취급한다. 소리 설정에 마이크(3- USB Audio Device) 처럼 번호가 하나씩 늘어나는 게 그 흔적이다. 문제는 기본 입력 장치와 앱의 바인딩이 옛 엔드포인트에 남는다는 것 — 장치는 멀쩡히 녹음 대기 중인데 아무 앱도 그쪽을 듣고 있지 않은 상태가 된다.
이것 때문에 초동 수사가 통째로 오염됐다. 마이크를 여러 잭에 꽂아 보며 "어디에 꽂아도 안 된다"고 판정했는데, 그중 몇 곳은 실제로는 살아 있었다. 꽂을 때마다 새 마이크가 태어나는 바람에 아무도 그 마이크를 선택하지 않았을 뿐이다. 이날 하루 동안 이렇게 태어난 엔드포인트 번호가 11번까지 갔다.
계측 — 패킷은 거짓말을 하지 않는다
엔드포인트를 제대로 지정해도 안 되는 상태가 이어졌다. 여기서부터는 귀와 설정 화면을 버리고 계측으로 내려갔다. WASAPI 로 활성 캡처 엔드포인트 전부에서 2초씩 직접 캡처하는 프로브를 만들었다. 판정 기준은 하나다.
- 패킷 0개 — 장치 관리자에 OK 로 보여도, 문제 코드가 0 이어도, 음소거가 아니어도, 파이프가 죽어 있다
- 패킷 ~170개(2초, 48kHz 연속) — 스트림이 흐른다. 안 들리면 설정이나 앱 문제다
결과는 전멸이었다. 마이크도, 몇 달 잘 쓰던 무선 헤드셋의 마이크도 전부 패킷 0. 그런데 같은 체인을 지나는 스피커 재생은 정상이었다(재생 중 피크 미터 실측 + 귀). 출력은 살고 입력만 죽는 반쪽 장애. 오디오 서비스 재시작도, 장치 드라이버 재구축(PnP 비활성화/재활성화)도 무효였다.
착시 2 — "여러 포트에 꽂아 봤는데"의 함정
결정적 단서는 헤드셋 동글의 물리 위치였다. 장치의 부모 체인을 따라 올라가 보니, 동글도 — 그리고 그동안 시도했던 "여러 포트"도 — 전부 같은 컨트롤러 소속이었다. 메인보드 뒷면 잭들은 컨트롤러 서너 개가 나눠 갖는데, 겉으로는 경계가 보이지 않는다. 포트를 아무리 옮겨도 같은 동네 안을 맴돌고 있었던 것이다.
그러니 "헤드셋 마이크도 안 되니 시스템 전체 문제"라는 추론도 무너진다. 헤드셋은 무죄의 증인이 아니라 같은 동네의 두 번째 피해자였다.
포트를 옮길 때마다 Windows 에 새 마이크가 하나씩 쌓여서, 정리할 때 세어 보니 열한 개였습니다. 지우지는 않았습니다. 어느 게 다시 필요해질지 모르니까요.
반전 — "그 자리에서 몇 달 잘 썼는데"
여기서 증언 하나가 판을 바꿨다. 헤드셋은 바로 그 자리에서 몇 달을 잘 썼다는 것. 그렇다면 이 컨트롤러의 입력은 태생부터 안 되는 게 아니라 최근에 죽었다. 실제로 이날 새벽 로그에는 컨트롤러 두 개가 동시에 튕긴 전역 USB 리셋(04:10:59)이 찍혀 있었다 — 전편에서 "시스템 전역 리셋"으로 재해석했던 바로 그 사건이다. 어딘가 꼬인 상태라면 재부팅이 카드가 된다.
재부팅의 결과는 절반의 성공이었다. 직결로 꽂힌 헤드셋은 부활했다. 그런데 체인 안의 마이크는 여전히 패킷 0. 꼬임(웨지)과는 별개로 한 층이 더 있었던 것이다: 이 컨트롤러는 건강한 상태에서도, 외장 허브가 한 단이라도 끼면 오디오 입력이 죽는다. 허브 한 단(KVM 직결)으로 좁혀서 실측으로 확인했다. 출력은 그 자리에서도 잘 나온다는 게 얄궂은 부분.
세 층을 다 벗기면
| 층 | 정체 | 겉보기 증상 | 판별 · 해소 |
|---|---|---|---|
| 1 | 엔드포인트 정체성 — Windows 가 경로 바뀐 장치를 새 마이크로 취급 | 멀쩡한 포트에서도 "안 됨"으로 보인다 | 소리 설정에서 새 번호 장치를 재선택. 한 번이면 기억된다 |
| 2 | 컨트롤러 웨지 — 새벽 전역 USB 리셋 후 입력 계통이 꼬임 | 직결도 패킷 0, 재생은 정상 | 재부팅으로 해소 |
| 3 | 구조 한계 — 이 컨트롤러는 허브 뒤 오디오 입력이 원래 안 됨 | 재부팅 후에도 체인 안에서만 패킷 0 | 컨트롤러 이사로 해소 |
층이 세 개라 어느 하나만 고쳐서는 "여전히 안 되네"로 끝난다. 실제로 그렇게 반나절을 돌았다.
종착 — 전편이 예고한 그 포트
전편 말미에 "CPU 직결 컨트롤러 두 개가 통째로 비어 있다"고 적어 뒀는데, 그 카드를 이렇게 빨리 쓰게 될 줄은 몰랐다. 뒷면의 빨간(10Gbps) 포트가 그 컨트롤러였다. 마이크를 직결로 시험하니 패킷이 흘렀고, 체인을 통째로 이주시킨 뒤 마이크를 원래 허브 자리에 되꽂자 — 패킷 189개, 이번엔 방 소음의 피크까지 보였다. 체인 최심부(허브 3단)에 있는 스피커 내장 마이크까지 흘렀다. 키보드도, 마이크도, 헤드셋도 전부 제자리에서 정상.
2막 체인(키보드·마이크) → RTS5411 허브 → USB 3.20 컨트롤러 · 키보드 ○ / 마이크 ×
종착 체인(키보드·마이크) → 직결 → USB 3.10 컨트롤러 (CPU) · 전부 ○
남은 것, 그리고 배운 것
키 밀림 쪽은 아직 완결이 아니다. 0608 허브 유죄가 유력해졌지만, 확정은 새 동네에서의 장기 무증상으로 굳혀야 한다. 계측기는 계속 돌고 있다.
마이크 쪽에서 남긴 교훈 세 줄:
- USB 오디오가 "안 될" 때의 판정 순서 — 엔드포인트(새 번호가 생기지 않았나) → 패킷(스트림이 흐르나) → 컨트롤러 소속(부모 체인). 귀와 설정 화면으로는 셋 다 구분되지 않는다.
- "여러 포트에 꽂아 봤다"는 컨트롤러 소속을 확인하기 전에는 실험이 아니다. 다 같은 동네였을 수 있다.
- 재생은 되는데 녹음만 안 되면, 장치 고장보다 경로(컨트롤러·허브)를 먼저 의심한다. 출력과 입력은 따로 죽는다.
기기들이 하루에 이사를 세 번 했고, 전부 제자리를 찾았습니다. 같은 조사를 두 번 하기 싫어서 세 층 전부 페이지로 남깁니다.