리눅스 스테이징 트리: Greg Kroah-Hartman, LLM 생성 패치 차단

AI « onslaught »의 파도 속에 휩쓸린 Linux staging tree 유지 관리자는 이제 보안상 진정한 수정 사항이 아닌 한 LLM으로 생성된 기여는 무조건 거부하고 있습니다. 그럼에도 불구하고 그는 직접 LLM을 사용하고 있습니다.

Linux의 staging tree란 무엇인가?

리눅스 커널 조직에서 staging tree를 이해해야만 Greg Kroah-Hartman(별칭 gregkh)의 결정을 이해할 수 있습니다. 이는 아직 메인라인에 적합하지 않은 드라이버와 코드를 위한 임시 공간입니다. 품질이 불충분하거나, 안정적이지 않은 API, 정리해야 할 의존성 등이 해당됩니다. 역사적으로 신규 기여자들의 입문 장소이기도 하며, 커널 개발 전문가 15년의 경력이 없어도 기여를 배울 수 있는 곳입니다.

Greg Kroah-Hartman은 이 staging tree의 유지보수 담당자입니다. 그는 패치를 읽고, 중재하며, 승인하거나 거부합니다.

일어난 일

그는 "onslaught"—LLM(대형 언어 모델)에서 생성된 패치 폭주—에 직면해, gregkh가 staging tree에 대한 새로운 정책을 발표했습니다. 이제 AI가 생성한 패치는 staging tree에 거부됩니다.

이 결정이 흥미로운 이유는 이것이 AI에 대한 이념적 거부가 아니라는 점입니다. Gregkh 자신도 커널 기여에 LLM을 사용하며 공개적으로 인정합니다. 그가 거부하는 것은 생성된 내용을 평가할 능력이 없는 기여자들이 LLM을 사용하는 것입니다.

논리는 명확합니다: staging tree는 기여자를 양성해야 합니다. AI가 생성한 패치를 이해하지 못한 채 제출하는 것은 그 목적에 완전히 반합니다. 또한 유지보수 담당자에게는 점점 증가하는 저가치 패치를 검토하고 수정하며 거부하는 추가 작업이 발생합니다.

단 한 가지 예외가 있습니다: 진짜 보안 문제 수정(genuine security fixes)은 출처에 관계없이 환영받습니다.

staging tree를 넘어선 중요성

이는 자유 소프트웨어 커뮤니티에서 수개월간 커지고 있는 긴장의 가장 구체적인 manifestation입니다. 한쪽으로는 문법적으로 올바른 코드를 생성할 수 있는 LLM이 있습니다. 다른 한쪽으로는 점점 증가하는 저질 패치를 흡수하는 유지보수 담당자들이 있습니다. 이들은 맥락에 대한 진정한 이해 없이 생성된 패치들입니다.

리눅스 커널은 평범한 코드베이스가 아닙니다. 모든 줄이 수백만 시스템에 영향을 미칠 수 있습니다. 패치의 품질은 코드뿐만이 아니라, 해당 코드가 존재하는 이유, 통합되는 맥락, 발생할 수 있는 부작용을 작성자가 이해하는지에 달려 있습니다. kvalifik된 인적 검토 없이 제출된 LLM 패치는 종종 이 "왜"를 놓칩니다.

이는 커널에서 AI의 종말이 아닙니다—아주 멀리 있습니다. 이는 AI를 도구로 사용하는 경우(자신이 하는 일을 아는 기여자)와 기술 대체로 사용하는 경우(기본 지식도 없는 경우)를 명확히 구분하는 정책의 시작입니다. 이 미묘한 차이는 Gregkh가 직접 실천하고 있습니다.