VRAM 할당자가 CCS 저장 공간을 사용 가능한 메모리로 오인하면서 일반 할당이 예약 영역과 겹칠 수 있었다. 그 결과 GPU가 사용하는 압축 메타데이터가 덮어써졌고, 페이지 테이블 관련 데이터까지 손상됐다. 증상은 화면 깨짐부터 디스플레이 관리자 GDM의 무한 재시작까지 다양하게 나타났다. 문제의 하드웨어는 인텔 Battlemage G21 그래픽 카드였다.
따라서 근본 원인은 단순한 산술 실수라기보다 값의 의미와 정렬 방식이 어긋난 것에 가까웠다. 코드가 해당 값을 메모리의 시작점처럼 정렬했지만, 실제 역할은 사용 가능한 메모리가 끝나는 한계값이었다. 최종 패치가 작았던 만큼 오히려 문제의 의미를 파악하기가 어려웠던 셈이다.
토발즈와 AI 보조 도구는 드라이버의 메모리 계산 과정을 추적하고, 하드웨어가 보고한 CCS 위치와 VRAM 할당자에 전달된 경계를 비교했다. 이를 위해 특정 지점을 관찰하는 계측 코드를 추가하고 수정하는 작업을 반복했다. 총 24개의 디버그 패치 버전과 18번의 재부팅·테스트를 거친 뒤에야 잘못된 정렬 방향이 드러났다.
이 과정에서 반복적인 부팅 테스트는 특히 중요했다. 문제는 소스 코드 한 줄만 살펴봐서는 확정하기 어려웠고, 실제 하드웨어와 디스플레이 시스템에서 메모리 손상이 어떻게 나타나는지 확인해야 했기 때문이다. 각각의 실험은 VRAM 할당 문제가 다른 그래픽 오류나 디스플레이 구성 문제와 어떻게 다른지 구분하는 데 도움을 줬다.
토발즈는 AI를 대화형 디버깅 파트너로 활용했다. AI는 계측 방법을 제안하고, 코드 경로를 따라가며, 반복되는 실험 결과를 정리·분석하는 데 기여했다. 사람이 일일이 수행해야 할 기계적인 작업을 줄여 디버깅 순환을 빠르게 만든 것이다.
그러나 AI가 항상 믿을 만한 판단을 내린 것은 아니었다. 토발즈에 따르면 AI는 여러 차례 문제를 “불가능하다”거나 “해결할 수 없다”고 결론 내렸고, 차라리 보고서를 작성하자고 제안하기도 했다. 토발즈는 다음 실험을 선택하고, 잘못된 해석을 걸러내며, 해당 값이 메모리 모델에서 시작 주소가 아닌 한계값이라는 점을 이해해야 했다.
이번 사례에서 역할 분담은 분명했다. AI는 가능성을 제시하고 반복 작업을 처리했지만, 전문가는 문제의 맥락을 제공하고 검증 가능한 실험을 설계했으며 최종 판단과 책임을 맡았다.
토발즈는 인텔 Xe 드라이버 수정 사항을 직접 작성해 업스트림 리눅스 커널에 커밋했다. 보도에 따르면 영향을 받는 유지보수 대상 안정 커널 계열에도 통상적인 백포트 절차를 통해 수정 사항이 적용될 예정이지만, 현재 제공된 자료만으로는 어떤 안정 버전에 언제 포함되는지 정확히 확인하기 어렵다.
따라서 현 단계에서 특정 안정 버전이나 배포판 커널을 수정 사항이 포함된 버전이라고 단정하는 것은 안전하지 않다. 해당 하드웨어 사용자는 배포판 또는 커널 유지보수자의 공지를 통해 자신의 커널 빌드에 패치가 포함됐는지 확인하는 편이 좋다.
이번 일은 AI가 작성한 커널 코드를 무조건 받아들여야 한다는 근거가 아니다. 오히려 더 좁고 현실적인 활용법을 보여준다. 전문 개발자가 AI를 어려운 디버깅 과정의 속도를 높이는 도구로 사용하되, 가설 수립과 실험 설계, 코드 검토, 패치 검증은 직접 맡는 방식이다.
이는 테스트하지 않은 AI 생성 패치나 검증되지 않은 취약점 보고서를 유지보수자에게 무차별적으로 보내는 것과는 전혀 다르다. 리눅스 커널 개발자들은 이런 제출물이 “쇄도”하고 있다고 표현했으며, 스테이징과 네트워킹 영역의 유지보수자들은 가치가 낮거나 맥락이 부족한 AI 생성 패치가 검토 부담을 키우고 있다고 지적했다.
일부 보도에서 반복적으로 언급된 제출량 2,700% 증가라는 수치는 신중하게 받아들일 필요가 있다. 제공된 자료만으로는 측정 방식과 기간, 전체 제출물인지 특정 하위 시스템이나 패치 유형을 가리키는지 확인되지 않는다. 다만 AI가 코드와 보고서를 만들어내는 비용은 낮췄지만, 이를 검토하고 분류하는 비용은 여전히 사람인 유지보수자가 부담한다는 일반적인 결론은 충분히 뒷받침된다.
토발즈 역시 리눅스가 AI 도구를 원칙적으로 배척하는 프로젝트는 아니며, 코드 리뷰 같은 작업에서는 AI가 유용할 수 있다고 말해왔다. 이번 인텔 Xe 디버깅 사례가 보여주는 실질적인 기준도 여기에 있다. AI는 체계적인 엔지니어링 과정 안에서 유용한 조수가 될 수 있지만, 서브시스템에 대한 지식과 재현 가능한 테스트, 결과에 대한 인간의 책임을 대신할 수는 없다.
최종 패치는 한 줄이었다. 그러나 진짜 성과는 어떤 한 줄을 바꿔야 하는지 알아내고, AI가 해결 불가능하다고 말한 뒤에도 탐색을 멈추지 않은 데 있었다.