리눅스 7.3 네트워킹, VXLAN·Geneve에 BIG TCP 도입…AI 패치에 지친 유지관리자들

관련 BIG TCP 패치 시리즈에서는 터널 경로가 패킷 길이를 64KiB 미만으로 가정하거나 길이 정보를 16비트 필드에 저장해 잘라내는 문제도 손봤다. 이 작업은 VXLAN과 Geneve에서 BIG TCP 기반 IPv4·IPv6 트래픽을 처리하기 위한 기반이다.

FIB 규칙 변경에서 RTNL 경합 완화

또 다른 주요 변화는 FIB(Forwarding Information Base) 규칙 작업에서 전역 RTNL 잠금에 대한 의존도를 낮춘 것이다. 대상 작업에는 RTM_NEWRULE과 RTM_DELRULE이 포함된다.

여러 네트워크 네임스페이스의 라우팅 규칙을 동시에 조작하는 시스템에서는 전역 잠금이 병렬 처리를 가로막는 지점이 될 수 있다. 이번 구조 변경은 이런 작업이 하나의 전역 직렬화 지점에 묶이지 않도록 하는 데 목적이 있다. 다만 제공된 자료에는 IPv4 또는 IPv6에서의 정확한 성능 향상률이나 배수 benchmark 결과가 없다. 따라서 특정 퍼센트의 속도 향상을 제시하는 것은 근거를 넘어선다.

무선·네트워크 드라이버와 프로토콜 업데이트

이번 네트워킹 병합에는 다음과 같은 하드웨어 및 프로토콜 계층의 변화도 포함됐다.

• Morse Micro의 장거리 S1G 기기를 위한 mm81x 무선 드라이버가 추가됐다.
• 새로운 NXPWIFI 드라이버가 들어갔다.
• Intel E2100 이상 IPU와 FNIC의 Intel Control Plane PIC Function을 겨냥한 초기 단계의 Intel iXD 인프라가 포함됐다.
• MPTCP는 극심한 메모리 부족 상황에서 비순차 수신 큐를 정리하는 등 동작을 개선했다.
• 그 밖에도 네트워킹 하위 시스템 전반에 걸쳐 유선·무선 드라이버 개선과 버그 수정이 추가됐다.

다만 이는 리눅스 7.3 개발 주기의 머지 윈도우에 들어온 네트워킹 코드다. 완성된 안정 버전 리눅스 7.3이 이미 출시됐다는 의미는 아니다.

유지관리자들이 “완전히 압도됐다”고 말한 이유

Kicinski와 Abeni는 이번 네트워킹 풀에서 net 패치 632개와 net-next 패치 648개를 병합했다고 밝혔다. 합치면 1,280개다. 이 수치만으로도 규모가 크지만, 유지관리자들이 실제로 감당해야 하는 리뷰 부담과 후속 작업까지 모두 보여주는 것은 아니라고 덧붙였다.

더 큰 문제는 net-next 패치 중 3분의 1에서 절반가량이 AI가 생성한 것으로 보이는 저우선순위 수정, 코드 정리, 설명 보완 작업일 수 있다는 추정이다.

제출량 자체도 빠르게 늘었다. 9일 동안 네트워킹 하위 시스템에는

[PATCH net]

[PATCH net-next]

핵심은 AI가 코드를 작성할 수 있다는 사실만이 아니다. AI를 활용한 제출자는 그럴듯한 설명, 버그 보고서, 리뷰 요청까지 매우 낮은 비용으로 만들어낼 수 있다. 반면 인간 유지관리자는 각 변경 사항이 정말 필요한지, 정확하고 안전한지, 병합할 가치가 있는지를 여전히 직접 판단해야 한다.

LLM은 리뷰어가 아니라 작업 보조자로

유지관리자들은 Meta의 지원으로 여러 대규모 언어 모델을 패치 리뷰에 활용할 수 있는 예산과 접근 권한을 확보했다고 밝혔다. 우선 목표는 환각이 섞였거나 품질이 낮은 변경 사항을 초기에 걸러내 인간 리뷰에 투입되는 시간을 줄이는 것이다.

LLM에 맡길 예정인 반복 업무에는 다음이 포함된다.

• Patchwork 대기열 관리
• 자주 발생하는 제출 절차 문제에 대한 피드백
• 커밋 메시지 편집
• 신뢰할 만한 개발자의 리뷰 태그가 붙은 패치를 적용하는 작업

이는 LLM을 하위 시스템 유지관리자의 대체재가 아니라 개발 워크플로를 돕는 도구로 활용하려는 접근이다. 특히 동시성에 민감한 커널 코드에서는 이 차이가 중요하다.

유지관리자들은 PCIe 오류와 타임아웃처럼 드물게 발생하는 경로를 예로 들었다. 이런 경로에서는 특정 타이밍에서만 나타나는 경쟁 조건이 숨어 있을 수 있다. LLM이 의심스러운 코드 패턴을 찾는 데 도움을 줄 수는 있지만, 가능한 모든 드문 실행 순서에서 코드가 올바르다는 사실을 안정적으로 증명할 수는 없다.

아직 정해지지 않은 것

제공된 자료에는 리눅스 7.3의 첫 번째 릴리스 후보인 7.3-rc1이나 최종 안정 버전의 예상 날짜가 제시되지 않았다. 현재 확인되는 것은 7.3 개발 주기에 네트워킹 코드가 병합됐다는 사실이지, 공식 출시 일정이 아니다.

RTNL 변경 역시 여러 네트워크 네임스페이스에서 FIB 규칙을 병렬로 관리하는 작업의 확장성을 높이기 위한 구조적 개선으로 보는 것이 정확하다. 실제 성능 향상 폭은 작업 유형과 시스템 구성에 따라 달라지며, 현재 자료만으로 특정 IPv4·IPv6 수치를 단정할 수는 없다.