AI로 하드웨어 드라이버 직접 만든다… 리눅스 사용자 새 길 열려

GNOME 개발자 우라우스, AI로 드라이버 벽을 넘다

GNOME 프로젝트 참여자 우라우스가 자신의 블로그에 올린 글이다. 그는 어머니 유품인 필름 네거티브를 스캔하려 플루스텍 8200i를 샀다. 리눅스 지원 모델이라 샀는데 칩셋이 바뀌어 드라이버가 없었다. 몇 달을 끙끙대다 포기했다.

전환점은 X에서 톰 크라이더의 글을 본 뒤다. 그는 마우스 드라이버를 AI로 고쳤다고 썼다. 윈도 가상머신에 실제 기기를 연결해 USB 통신을 캡처하고 AI에게 분석을 맡긴 방식이었다. 우라우스는 이 글을 클로드에 붙여넣고 같은 환경을 만들어 달라고 했다. 몇 시간 만에 첫 스캔이 떴다. 며칠 뒤엔 적외선 스캔까지 지원하는 거의 완성된 드라이버가 나왔다. 마침 그 사이 누군가 세인 공식 저장소에 같은 스캐너 지원을 커밋해 버렸다.

그는 같은 방식으로 노트북 내장 MIPI 카메라 드라이버도 손봤다. 아침에 시작해 저녁에 커널 패치와 리브카메라 패치가 준비됐다. 이 과정을 일반화한 도구가 hw-harness다.

쉽게 풀어보면

GNOME 개발자 우라우스가 클로드 코드라는 AI 도구를 써서, 리눅스 드라이버가 없는 하드웨어를 이틀 만에 되살렸다. 비유하면 이렇다. 윈도에서는 기기가 잘 작동한다. 그 작동 방식을 엿듣기해서 리눅스에 가르쳐 주는 것이다.

구체적으로는 윈도 가상머신(KVM, 커널 기반 가상머신)에 실물 기기를 넘겨준다. 리눅스 호스트에서 usbmon(USB 버스 모니터링 도구)으로 USB 버스 트래픽을 기록한다. 게스트 OS는 이 기록을 모른다. 같은 조작을 리눅스 쪽 드라이버로도 해 본다. 두 트레이스를 비교하면 차이점이 곧 버그 리스트다. 내부 카메라처럼 버스가 안 보이는 장치는 윈도 쪽 INF 파일(드라이버 설치 정보), 레지스트리, ACPI 테이블(하드웨어 설정표)을 뜯어본다.

이 모든 분석을 클로드 코드가 맡았다. 수천 줄 헥스 덤프에서 반복 패턴을 찾고, 레지스터 의미를 추측하고, 검증 코드까지 짠다. 사람은 무엇을 만들지 정하고, 실물에서 작동하는지 확인만 하면 된다.

hw-harness 4단계 워크플로

도구는 네 단계로 요약된다. 첫째, 벤더 윈도 드라이버를 KVM에서 돌리며 usbmon으로 캡처한다. 둘째, 직접 짠 드라이버로 똑같이 작동해 보고 캡처한다. 셋째, 두 트레이스를 비교한다. 같은 계측기에서 나왔으니 바로 비교 가능하고, 차이점이 버그 리스트가 된다. 넷째, 버스 없는 장치는 윈도 쪽 설정 파일·레지스트리·ACPI로 대체 분석한다.

저자는 이 방식이 코드 복제가 아니라 하드웨어 동작 관찰이라 라이선스 문제에서 자유롭다고 본다. 드라이버 상수마다 기록된 근거가 남는다.

프로젝트 1: 플루스텍 옵틱필름 8200i

두 윈도 드라이버 출력을 비교해 만들었다. 페도라 RPM으로 자동 빌드된다. 테스트는 직접 만든 네거티브 바이브스 앱으로 했다. 리눅스용 네거티브 스캔 앱이 마땅치 않아서다. 업스트림 세인의 genesys 백엔드에도 지원이 들어갔다.

프로젝트 2: 노트북 MIPI 카메라

내장 카메라는 USB 버스가 없다. MIPI(모바일 산업 프로세서 인터페이스, 스마트폰·노트북 내장 카메라 표준 규격) 방식이다. 윈도 쪽 펌웨어·ACPI 정보를 뽑아 커널 드라이버와 리브카메라를 고쳤다. 하루 만에 의미 있는 패치 두 세트가 나왔다.

커뮤니티 반응은 엇갈린다

해커뉴스 댓글 중 눈에 띄는 것들. "스마트 TV도 해 달라. 광고와 거주형 프록시를 걷어낼 기회다." "오래된 하드웨어가 더 쉽다. 문서가 많고 단순하니까." 반론도 있다. "애플·엔비디아 같은 폐쇄적인 최신 하드웨어를 겨냥해야 의미 있다"는 댓글이 달렸다.

이전 기사와 연결되는 점

본지가 13일 전 다룬 **AI가 레고 설계도 그려준다… 오픈소스 'ldraw-nova' 등장**도 AI가 전문 영역 진입 장벽을 낮추는 도구라는 점에서 같다. 당시는 조립 설명서 생성, 이번에는 드라이버 역설계다. 둘 다 반복·패턴 인식이 핵심인 작업을 AI에 넘기고 사람은 판단을 남긴다는 구조다.

나에게 미치는 영향

리눅스 쓰는 일반 사용자라면 지원 안 되는 USB 기기가 있을 때 이 흐름을 시도해 볼 수 있다. 준비물은 윈도 라이선스, KVM/QEMU 가상머신, USB 패스스루 설정 지식, 클로드 코드(또는 코덱스) 접근 권한이다.

서랍 속 안 쓰는 USB 기기 하나 꺼내 lsusb 찍어 보는 일부터 시작한다. 지원 여부 확인만 1분 걸린다. 안 되면 위 흐름 중 1~2단계만이라도 해 두면 나중에 AI 도움 받을 때 자료가 된다.

흔한 막힘 지점과 해결법 USB 패스스루가 안 잡히면 IOMMU 커널 파라미터(intel_iommu=on 등)를 확인한다. usbmon 권한 없으면 sudo setfacl -m u:$USER:r /sys/kernel/debug/usb/usbmon/*로 풀거나 root로 캡처한다. AI가 헥스 덤프를 못 읽으면 앞 200바이트만 잘라 "이 패킷 의미 추측해 줘"부터 시작한다.

내장 카메라·터치패드 같은 버스 없는 장치는 이 방법대로 안 된다. 그때는 윈도에서 devmgmt.msc → 장치 속성 → 자세히 → 하드웨어 ID·호환 ID·위치 경로·ACPI 테이블을 메모해 AI에 주면 된다.

남은 쟁점

• hw-harness 저장소 주소는 글에 없다. 공개 시점 미정.
• 윈도 라이선스 비용·가상머신 성능이 병목이 될 수 있다. ARM 맥 등에서 윈도 ARM 돌려도 되는지 미확인.
• AI가 생성한 드라이버가 업스트림 품질 기준 통과할지는 검증 필요하다. 저자도 "사람이 최종 확인 필수"라고 썼다.

이 글은 성공담을 넘어 재현 가능한 워크플로를 보여 준다. 리눅스 하드웨어 호환성 문제가 "기다리면 누군가가 해주겠지"에서 "내가 하루 만에 해 볼 수 있다"로 바뀐 지점이다. 이 대목이 걸린다. 검증된 드라이버가 업스트림에 합류하려면 여전히 사람의 손이 필요하다.