AI가 단종된 프린터를 되살렸다: Claude가 직접 짠 macOS 드라이버 이야기

서랍 속에 잘 굴러가는데 못 쓰는 하드웨어, 하나쯤 있으실 겁니다. 프린터, 스캐너, 오래된 오디오 인터페이스 같은 것들이요. 기계는 멀쩡한데 제조사가 드라이버 지원을 끊었거나 애초에 윈도우용만 내놓은 경우죠. 그런데 최근 개발자 커뮤니티에 “Claude에게 시켰더니 macOS 드라이버를 짜주더라"는 사례가 돌았습니다. 서랍 속 물건들 운명이 조금 달라질 수도 있겠구나 싶은 이야기죠.

무슨 일이 있었나

시나리오는 단순합니다. 윈도우에서만 동작하는 HP 프린터가 있고, 사용자는 맥을 씁니다. HP는 해당 모델의 macOS 드라이버를 제공하지 않습니다. 보통 여기서 끝입니다. 프린터를 버리거나, 윈도우 노트북을 하나 켜두거나요.

이 사용자는 세 번째 길을 택했습니다. 윈도우에서 프린터로 나가는 USB 통신을 통째로 캡처한 다음, 그 로그를 AI에게 던졌습니다. “이게 무슨 프로토콜인지 알아내고, 맥에서 같은 동작을 하는 코드를 짜라"는 거죠.

핵심은 패킷 캡처입니다. 프린터가 어떤 언어로 말하는지 문서가 없어도, 실제 대화를 녹음해두면 규칙을 거꾸로 짚어낼 수 있습니다. “인쇄 버튼을 눌렀더니 이 바이트 뭉치가 나갔고, 프린터는 이렇게 답했다"는 기록이 쌓이면 그 안에서 명령어의 구조가 보이기 시작합니다. 사람이 하면 며칠에서 몇 주가 걸립니다. 바이너리를 노려보며 반복 패턴을 찾고, 헤더와 페이로드의 경계를 추측하고, 가설을 세워 실제 장치에 쏴봅니다. 실패하면 다시 처음으로 돌아가고요.

AI가 리버스 엔지니어링에 유독 잘 맞는 이유

이 작업은 사실 AI가 잘할 수밖에 없는 종류의 일입니다.

하나는 패턴 인식입니다. 리버스 엔지니어링의 8할은 “이 숫자 뭉치에서 반복되는 게 뭐지?“를 찾는 일입니다. 사람은 16진수를 오래 들여다보면 눈이 아프지만, 언어 모델에게 바이트 시퀀스는 그냥 또 하나의 토큰 배열입니다. 지치지 않고 전체를 훑습니다.

사전 지식도 큽니다. 프린터 프로토콜을 아예 새로 발명하는 제조사는 없습니다. PCL, PostScript, ZPL 같은 기존 규격을 조금 비틀거나, IEEE 1284 같은 표준 위에 자기 확장을 얹은 형태가 대부분이죠. 이런 배경을 폭넓게 학습한 모델은 “아, 이 구조는 PCL 계열이고 여기 이 부분만 커스텀이네"라고 빠르게 좁혀 들어갑니다. 백지에서 시작하지 않는다는 뜻입니다.

반복 실험 비용도 그렇습니다. 가설을 세우고 코드를 짜서 돌려보고 실패하면 고치는 루프를 사람이 돌리면 지칩니다. AI에게는 그냥 다음 요청일 뿐입니다. 프린터가 응답을 안 하면 로그를 보고 다른 가설을 세워 다시 짭니다.

그런데, 커널 근처는 좀 다르지 않나

커뮤니티 반응이 갈리는 지점이 여기입니다. 드라이버는 일반 앱과 성격이 다릅니다. 웹 서비스 코드는 버그가 나면 500 에러를 뱉고 끝이지만, 시스템 레벨 코드는 파장이 다릅니다.

물론 오해는 짚고 넘어가야죠. 요즘 macOS에서 프린터 드라이버를 만든다고 커널 모듈을 짜지는 않습니다. 애플은 이미 커널 확장(kext)을 사실상 폐기했고, 장치 접근은 대개 DriverKit이나 사용자 공간의 libusb, CUPS 필터가 맡습니다. 이번 사례의 코드도 대부분 유저 스페이스에서 돌아갑니다. 크래시가 나도 커널 패닉이 아니라 프로세스 하나가 죽는 정도죠. “AI에게 커널 코드를 맡겼다"는 표현은 다소 과장입니다.

그렇다고 위험이 없는 건 아닙니다. USB 통신 코드는 여전히 하드웨어에 직접 명령을 쏘는 일입니다. 잘못된 바이트 시퀀스가 장치 펌웨어를 이상한 상태에 빠뜨릴 수 있고, 최악의 경우 펌웨어 영역을 건드려 장치를 벽돌로 만들 수도 있습니다. 프린터라면 최대 손실이 프린터 한 대지만, 같은 방식으로 스토리지 컨트롤러나 네트워크 장비를 다룬다면 이야기가 달라집니다.

더 근본적인 문제는 검증입니다. AI가 짠 드라이버가 동작한다는 건 무슨 뜻일까요. 테스트 페이지가 제대로 나왔다는 것뿐입니다. 컬러 모드에서는? 양면 인쇄는? 용지 걸림 상황의 에러 처리는? 프린터가 슬립에서 깨어날 때는? 사람이 짠 드라이버도 이런 엣지 케이스에서 무너집니다. 하물며 리버스 엔지니어링으로 추론한 프로토콜은 애초에 명세가 없으니 “빠뜨린 게 있는지"를 확인할 방법 자체가 없습니다. 캡처하지 않은 동작은 없는 것이나 마찬가지니까요.

달라진 건 품값

이 사례가 흥미로운 건 기술적 난이도 때문이 아닙니다. 이런 리버스 엔지니어링은 예전에도 가능했습니다. 리눅스 커뮤니티가 수십 년간 해온 일이 정확히 이거죠. 문제는 드는 품이었습니다.

프린터 한 대 살리자고 개발자가 주말 세 번을 갈아 넣는 건 합리적이지 않습니다. 그래서 대부분의 “지원 종료된 하드웨어"는 그냥 버려졌습니다. 커뮤니티가 달라붙을 만큼 인기 있는 모델만 살아남았고, 나머지는 조용히 전자폐기물이 됐습니다.

AI는 이 계산식을 바꿉니다. 주말 세 번이 저녁 한나절이 되면, 아무도 신경 안 쓰던 롱테일 하드웨어에도 손댈 만해집니다. 니치한 모델, 소량 판매된 장비, 회사가 망해서 지원이 끊긴 제품 말입니다. 시장 규모가 작아서 여태 아무도 안 만들던 드라이버를, 필요한 사람 한 명이 직접 만들어 쓰면 그만입니다.

환경 쪽으로도 이야기가 이어집니다. 멀쩡한 하드웨어가 소프트웨어 지원 종료 하나로 폐기되는 건 꽤 큰 낭비입니다. 제조사 입장에서는 신제품을 팔아야 하니 굳이 구형 지원을 이어갈 이유가 없고요. 그 공백을 개인이 메울 수 있게 된다면 하드웨어 수명 자체가 길어집니다.

법적으로는 어떤가

법 이야기도 해야죠. 리버스 엔지니어링의 합법성은 나라마다, 목적마다 다릅니다.

대체로 상호운용성을 위한 리버스 엔지니어링은 넓게 허용되는 편입니다. 미국에서는 DMCA에 상호운용성 예외 조항이 있고, EU 소프트웨어 지침도 호환 프로그램 개발 목적의 역분석을 인정합니다. 내가 산 프린터를 내 컴퓨터에서 쓰겠다는 건 여기에 들어갈 가능성이 높습니다.

다만 애매한 구석이 있습니다. 제조사 드라이버 바이너리를 디컴파일해서 코드를 참고했다면? 펌웨어에 암호화나 서명 검증이 걸려 있는데 그걸 우회했다면? 결과물을 배포한다면? 개인이 자기 장치를 쓰려고 하는 것과, 그 결과물을 공개 저장소에 올리는 것 사이에는 꽤 큰 간극이 있습니다.

AI를 썼다는 사실 자체가 법적 지위를 바꾸지는 않습니다. 하지만 진입 장벽이 낮아져 이런 작업이 흔해지면, 제조사가 대응에 나설 수도 있습니다. 장치 인증을 강화하거나, 프로토콜에 서명을 넣거나 하는 식으로요.

마무리

AI가 드라이버를 짤 수 있다는 건 새로운 마법이 생겼다는 얘기가 아닙니다. 원래 가능했지만 비싸서 아무도 안 하던 일이 싸졌다는 얘기죠. 그리고 그 변화가 닿는 곳은 생각보다 넓습니다. 버려질 하드웨어, 사라진 회사의 제품, 아무도 관리하지 않는 레거시 시스템까지요.

동시에 검증 안 된 저수준 코드가 늘어난다는 뜻이기도 합니다. 프린터라면 최악의 경우 종이가 낭비되는 정도지만, 같은 접근법이 의료 기기나 산업 장비로 넘어가면 계산이 달라집니다. “동작한다"와 “안전하다"는 전혀 다른 문장이니까요.

여러분 서랍에도 드라이버가 없어서 못 쓰는 물건이 있으신가요. 그걸 되살리는 데 AI를 쓴다면, 어디까지가 합리적인 시도이고 어디부터가 무모한 실험일까요.