리눅스 무선 통신 유지보수자가 AI/LLM 생성 '잡다한 패치'에 대해 강경한 입장 표명

LINUX NETWORKING

johannes Berg는 Linux 커널의 802.11, mac80211, WWAN, rfkill 및 무선 네트워킹 드라이버(기타 커널 코드 포함)를 담당하는 유지보수자로서, syzbot과 같은 AI/LLM이 생성한 패치들을 바라보는 방식에 변화가 있음을 발표했습니다.

만약 이러한 AI 생성 패치들에 대한 '3초 검토'만으로도 진정한 수정 사항인지 명확하게 파악되지 않는다면, 해당 패치들은 무시될 것입니다. 그는 LKML(Linux Kernel Mailing List) 게시물을 통해 리눅스 무선 통신 패치에 대한 새로운 정책을 발표했습니다:

"기록으로 남기자면, 저는 패치를 무시할 수 있는 능력을 신중하게 사용할 것이며, '명백히 맞다'고 3초 검토가 말해주지 않는 한 거의 모든 syzbot-AI 생성 패치에 적용할 것입니다.

특히, 저는 평소처럼 '패치에 대해 논평하고' 다른 컴퓨터가 이메일로 보내주기 전에 코드를 더 빨리 지껄여낼 수 있는 LLM과 논쟁하지 않을 것입니다.

현재 루프 내의 인간 역할을 가장하는 사람은 패치들에 대해 반드시 생각해야 하며, 만약 그런 일이 일어나고 있다면 그것은 아마도 syzbot이 보낸 AI 생성물이 아닐 것이며, 당신은 그것을 재작성하여 제대로 보내야 합니다.

(즉: 사라져라, syzbot)"

syzbot에 대한 답변으로, Syzbot이 생성하는 모든 AI 패치는 인간의 사전 검토와 승인을 거쳤다는 점이 명확히 했습니다. 또한 Syzbot은 자동 답장을 보내지 않으며, 패치의 새 버전을 자동으로 제출하지도 않습니다. 이에 따라 syzbot은 리눅스 무선 통신 서브시스템을 다루는 AI 지원 패치를 전송하는 기능이 비활성화되고 있습니다.

johannes는 또한 자신이 바라보는 AI/LLM 패치 유입에 대한 더 많은 관점을 공유했습니다:

"이런 상황에서 시스템은 거의 확실하게 매우 좁고 타겟팅된 수정 사항(정확히 그것을 설명하는 짜증 나는 긴 텍스트 벽과 함께)을 제공할 것입니다. 하지만 저는 적어도 루프 내의 인간 (human in the loop)이 거기서 한 걸음 물러나 코드의 의미론 (semantics)이 무엇이어야 하는지를 물어야 한다고 생각합니다... 저 또한 Slawomir의 첫 번째 패치를 두고 이런 과정을 겪어보았지만, 원래의 중간 작업자 (intermediary)가 그렇게 하기를 원치 않는다면 이는 분명히 확장 (scale)될 수 없습니다.

어쩌면 LLM에게 어떻게든 그렇게 하라고 말해서 첫 번째 초안을 더 낫게 만들 수도 있을 것입니다. 예를 들어 이번 사례의 경우, 왜 도대체 동일한 switch 문 내에 여러 개의 분기(branch)를 두어 동일한 검증을 구현하는 것이 의미 있다고 결정한 것일까요? 심지어 분기는 단 두 개뿐입니다! 최소한 "인간 엔지니어"라면 한 걸음 물러나 생각하기를 기대할 것입니다.

이것이 제가 이 패치들을 거부하는 이유입니다. 패치를 하기 전이나 도중에 코드의 의미론 (semantics)을 실제로 살펴보려는 사람이 아무도 없기 때문입니다. switch 문 밖으로 검증 로직을 빼내는 것이 에러의 순서를 바꾸나요? 네. 그것이 중요한가요? 아니요, NL80211_TDLS_ENABLE_LINK에 대한 새로운 에러 순서는 — 잘 생각해 보면 (!) — 사실 훨씬 더 말이 됩니다! 타겟팅된 수정 (targeted fix)을 하라고 명령했을 때 LLM이 그렇게 하지 않는다는 사실에 제가 놀랐냐고요? 전혀 아닙니다.

하지만 저 혼자서 그런 모든 개별 이슈에 대해 판단을 내릴 수는 없습니다. 만약 그럴 수 있었다면, 위에서 언급했듯이 제가 이 모든 일을 직접 하고 있었을 것입니다. 기여자 (contributors)들이 그 역할을 해주어야 합니다. Slawomir는 제가 그렇게 하도록 유도 (prompted, 의도적인 언어유희!)한 후에 그렇게 했지만, 결과가 그리 좋지 않았고 우리는 이에 대해 심도 있는 논의를 나누었습니다. 하지만 다시 말하지만, 제가 항상 그런 지원을 제공할 수는 없습니다.

...

타겟팅된 수정 (targeted fixes)이라 할지라도 여전히 수정 사항이기에, 당신의 관점에서는 여전히 타당해 보일 수 있다는 점을 이해합니다. 하지만 제 관점에서는 장기적인 유지보수 측면(아키텍처를 무시하고 코드 곳곳에 검증 로직을 뿌려대는 것)과 리뷰 대역폭 (review bandwidth) 등의 측면 모두에서 이는 절대 확장될 수 없는 방식입니다."

따라서 앞으로 AI/LLM이 생성한 새로운 Linux 무선 패치(wireless patches)를 평가할 때 적용될 새로운 '3초 규칙(three second rule)'은 다음과 같습니다.