Claude Code / AI Shows Potential For Reverse-Engineering Hardware For Linux Support
Claude Code로 하드웨어를 역공학해 리눅스 지원 드라이버 만들기
Red Hat의 Christian Schaller는 Windows용 드라이버의 USB 동작을 살펴보며 Claude Code로 사진 스캐너용 SANE 드라이버를 만들었습니다. ThinkPad X1 Carbon Gen 14의 MIPI 카메라 문제도 수정했다고 밝혔으며, Reddit에서는 다른 기기의 드라이버와 주변기기 지원을 구현한 경험담과 코드·라이선스 우려가 나왔습니다.
- 주제
에디터 노트
이번 사례에서 설득력 있는 부분은 AI가 막연히 드라이버를 만들어 냈다는 이야기가 아니라, Windows 드라이버의 USB 동작을 관찰해 스캐너 지원을 구현하고 카메라 드라이버 결함도 고쳤다는 구체적인 작업입니다. 댓글의 프린터와 NUC 사례도 주변기기 지원에 활용하는 흐름을 보탭니다. 다만 경험담은 각 기기에서 작동했다는 보고이지, 생성 코드의 정확성이나 유지보수성, 업스트림 채택을 확인해 주지는 않습니다. 특히 한 댓글은 처음 시도한 접근이 /dev/mem에서 레지스터를 추측하는 방식이었다고 밝혔습니다. 코드 출처와 라이선스 우려도 제기됐지만 Reddit 토론만으로 법적 판단을 내릴 수는 없습니다. 실제 성과는 역공학 결과를 검증하고 다른 개발자가 검토할 수 있는 드라이버로 정리하는 데 달려 있습니다.
AI 요약
Red Hat의 Christian Schaller는 Linux에서 작동하지 않는 Pustek 8200i 필름 스캐너를 지원하려고 Claude Code를 활용했습니다. Windows 가상 머신에 제조사 드라이버를 설치한 뒤 USB 동작을 캡처하고 분석하도록 했고, 그 결과 SANE용 기본 스캐너 드라이버가 작동했습니다. 이어 Rust로 GNOME용 필름 스캐너 앱도 만들었습니다.
카메라 드라이버 수정
Schaller는 Lenovo ThinkPad X1 Carbon Gen 14 Aura Edition의 MIPI 카메라 문제에도 Claude Code를 사용했습니다. Intel IPU7에 연결된 Sony 센서가 어두운 이미지를 출력하는 등 문제가 있었고, AI를 활용해 Linux 드라이버 결함을 수정했다고 설명했습니다.
Reddit에서 나온 사례와 쟁점
댓글에는 P-Touch 라벨 프린터, Epson 프린터, Intel NUC의 임베디드 컨트롤러, Pakon 필름 스캐너, Surface Pro 7 적외선 센서 등을 역공학하거나 Linux에서 작동하도록 만든 경험담이 올라왔습니다. 일부는 AI가 기존 오픈소스 프로젝트에서 해결하지 못한 부분을 메웠다고 말했습니다. 반면 생성 코드가 제조사 코드와 비슷해질 가능성과 라이선스 문제가 오픈소스 프로젝트에 부담을 줄 수 있다는 우려도 나왔습니다. 실험 환경을 격리하고 결과를 검토해야 한다는 의견과, 수정 사항을 업스트림에 반영하는 일이 여전히 과제라는 지적도 있었습니다.
Reddit 반응
- @u/eMperror_ — 동생의 P-Touch 라벨 프린터에도 같은 작업을 했습니다. 이제 제조사 모바일 앱 대신 웹 인터페이스에서 라벨을 출력합니다.
- @u/maccam94 — Intel NUC의 임베디드 컨트롤러용 Windows 드라이버를 역공학해 Linux 드라이버로 바꿨습니다. Claude는 한 시간도 안 걸렸지만, 처음에는 팬 속도 값이 달라지도록 부하를 조절하면서 /dev/mem을 뒤져 레지스터를 찾으려 해서 방향을 바로잡아야 했습니다.
- @u/Grippentech — 저는 한동안 LLM으로 드라이버 결함을 수정해 왔습니다. 공급업체 구현이 엉성한 버그를 고칠 때 유용합니다. 다만 수정 사항을 업스트림에 올리는 데 필요한 시간과 노력은 여전히 문제입니다.
- @u/F3z345W6AY4FGowrGcHt — LLM에 SSH 접근 권한을 주는 건 꺼려집니다. 환각 한 번이면 얼마나 큰 피해가 생길지 모르니까요. 격리된 복제 VM을 말하는 거라면 모르겠습니다.
- @u/Teddy-Bloat — LLM이 학습 데이터에 있던 코드를 그대로 내놓는 경향을 생각하면 법적 위험이 있어 보입니다. 제조사도 드라이버 개발에 LLM을 쓸 수 있고, 그 코드가 학습 데이터에 들어가지 않았다고 장담하기 어렵습니다. 그런 코드를 GPL 프로젝트에 넣으면 위험할 수 있습니다.
- @u/unski_ukuli — AI에는 클린룸 방식이 없고 법적 지위도 불확실합니다. 널리 쓰이는 오픈소스 프로젝트에서 AI 생성 코드를 금지하는 것이 지속 가능한 유일한 방법입니다.
- @u/gartstell — Brother 공식 드라이버로 PDF 18부를 출력하려는데 작업이 시작되지 않고 오래 걸렸습니다. Claude에게 살펴보게 했더니 드라이버가 PDF를 네 번 변환해 파일을 계속 키웠고, 18페이지 파일을 7GB로 만든 뒤 같은 파일을 두 개 생성했습니다. 2분도 안 돼 고쳤습니다.
원문: Phoronix / 번역·요약: Trawling