애플 실리콘용 리눅스 지원을 이끄는 개발자 코디 호(Cody Ho)와 니클라스(Niklas)가 M4 맥 미니와 맥북 네오에서 동작하는 OpenGL ES 3.0 호환 GPU 드라이버를 약 한 달 만에 만들었다고 밝혔다. GPU 드라이버 개발은 보통 수년이 걸리는 작업이다. 이번 결과물은 M4 맥 미니에서 크롬과 파이어폭스의 WebGL을 컴포지팅까지 정상 동작시켰고, 마인크래프트를 200fps로 돌릴 만큼 실사용에 가까운 성능을 냈다. 다만 아직 최종 사용자에게 배포할 수준은 아니며, 저자들은 배포를 목표로 작업을 이어가고 있다고 설명했다.
주목할 점은 개발 방식이다. 이들은 애플의 바이너리를 들여다보지 않았다. 자체 제작한 하이퍼바이저로 하드웨어 트레이스를 뜨고, 직접 작성한 셰이더만 사용하는 검증 가능한 클린룸 방식을 고수했다. 유저스페이스 리버스 엔지니어링에서 불가피하게 필요한 애플 블롭은 불투명한 객체로만 취급하고, 제3자가 작성한 문서를 바탕으로 독립 구현했다. 실험 과정 전체를 공개 저장소에 남겨 작업 출처를 누구나 검증할 수 있게 한 점도 라이선스 리스크를 관리해야 하는 실무자 입장에서 눈여겨볼 대목이다.
애플의 펌웨어 ABI라는 벽
애플 실리콘에서는 커널 드라이버가 하드웨어와 직접 통신하지 않는다. 대신 GPU 펌웨어가 RTKit이라는 자체 RTOS 위에서 돌아가고, 커널은 이 펌웨어와 대화한다. 저자는 이 펌웨어 ABI를 프로젝트에서 가장 골치 아팠던 부분으로 꼽았다. 애플이 사실상 기존 커널 드라이버를 반으로 잘라 절반을 GPU 안에 펌웨어로 넣고, 나머지 절반이 공유 메모리 구조체로 통신하도록 만들었기 때문이다. 이 구조체에는 절대 건드리면 안 되는 펌웨어 소유 필드와 호스트가 제어하는 필드가 뒤섞여 있다. 아사히 리나가 12시간씩 매달려 밝혀낸 M1/M2 ABI도 복잡했지만, A18 프로의 ABI는 그보다 훨씬 더 복잡했다고 한다.
접근법 자체는 M1/M2 때와 같았다. macOS가 하는 일을 하이퍼바이저로 관찰하고, 그대로 재현한 뒤, 스스로 재구성해 보는 것이다. 흥미로운 지점은 LLM(코덱스)이 '재현'을 문자 그대로 받아들였다는 것이다. 펌웨어가 처음 반응하는 이벤트(킥) 직후 GPU 메모리 상태 전체를 저장했다가 재부팅 후 그대로 되돌려 넣고, 출력 페이지가 바뀌는지 확인한 다음, 포인터를 따라가며 객체를 코드로 재구성했다. 실험을 거듭하며 복사하는 페이지 수를 줄여 결국 모든 것을 소스에서 생성하는 방식으로 옮겨갔다. 저자는 코덱스가 언제 하드웨어를 더 찔러봐야 하고 언제 상태만 캡처하면 되는지 판단하는 감각이 좋았다고 평가했다.
깨끗한 캡처가 전부였다
난관은 대부분 깨끗한 캡처를 얻지 못한 데서 비롯됐다. 펌웨어 시작 이후 제출된 렌더 작업이 실제로는 아무 일도 하지 않고 ACK 처리만 되는 문제는, 알고 보니 수명 주기 후반의 캡처를 재현하려 했기 때문이었다. 펌웨어 시작 직후의 가장 이른 캡처를 고르자 코덱스는 1바이트 디스크립터 누락을 거의 즉시 찾아냈다. 컴퓨트 작업은 GUI 경로에서 상당한 렌더 이후에야 스케줄링되는 탓에 깨끗한 캡처를 얻기 어려웠고, 336MB짜리 캡처는 재현이 불가능해 일주일 넘게 헤맸다. 해법은 결국 '가능한 한 작은 캡처를 싱글유저 모드에서 뜬다'는 단순한 원칙이었다. 기하 정보가 타일드 버텍스 버퍼(TVB)에 다 담기지 않을 때 발생하는 부분 렌더는, 사실상 GPU 드라이버에 저장·재개 기능을 추가하는 일이라 가장 까다로웠다.
실무적으로 새겨둘 교훈은 여기서 나온다. 저자는 렌더가 되니 컴퓨트는 몇 시간이면 되리라 자만해 작업을 제대로 쪼개주지 않았고, 그 결과 시간을 크게 낭비했다. 파이썬 프로토타입을 리눅스 드라이버로 옮기는 데는 사흘이 걸렸는데, 그중 하루는 코덱스가 가장 쉬운 컴퓨트가 아니라 가장 어려운 부분 렌더를 먼저 붙들었기 때문에 날렸다. 순서를 컴퓨트부터로 바로잡자 나머지는 순조로웠다. 에이전트에게 과제의 난이도 순서와 범위를 명확히 스캐폴딩해 주는 일이 결과를 좌우한다는 점을 보여준다.
에이전트를 붙잡아 두는 것은 '실제 목표'
유저스페이스 단계에서 저자와 니클라스는 상반된 전략을 택했다. 저자는 하드웨어를 먼저 완전히 이해해 명세를 쓰고 LLM에 구현을 맡기는 방식이었고, 니클라스는 Mesa를 먼저 쌓아 올리며 필요할 때만 리버스 엔지니어링을 하는 'Mesa 우선' 방식이었다. 결과적으로 니클라스가 훨씬 빨랐다. 저자의 에이전트는 완전성을 명분으로 리눅스가 쓰지도 않는 테셀레이션까지 열거하며 사소한 곁가지에 시간을 쏟은 반면, 니클라스의 에이전트는 'Mesa를 실제로 빌드해야 한다'는 제약에 묶여 자원을 효율적으로 썼기 때문이다. 저자는 코덱스의 한계를 '현학적(pedantic)'이라는 말로 요약했다. 늘 지나치게 철저해서 어떤 상황에선 강점이지만, 전체 목표를 해치면서까지 엉뚱한 곁길에 빠지곤 한다는 것이다.
이 사례는 코딩 에이전트를 다루는 팀에 구체적인 시사점을 준다. 하이퍼바이저로 정상 샘플과 주소 공간을 통째로 비교하는 체계적 디버깅처럼, 반복적이고 정형화된 검증 작업에서 LLM은 분명히 강력하다. 그러나 방향을 잡아주는 것은 여전히 사람의 몫이다. 추상적인 '완전성'보다 컴파일이 되는지, 벤치마크가 도는지 같은 검증 가능한 목표로 에이전트를 고정시킬 때 생산성이 극대화된다는 것이 핵심이다. 물론 이 결과는 성숙한 리버스 엔지니어링 방법론과 자체 하이퍼바이저라는 강력한 관측 도구, 그리고 두 숙련 개발자의 판단이 뒷받침된 성과라는 점도 함께 봐야 한다.