공개된 netperf TCP_STREAM 측정 결과는 다음과 같다.

• 표준 MTU 환경에서 VXLAN 처리량은 34.44Gbit/s에서 39.56Gbit/s로 증가해 14.9% 개선됐다.
• 터널 하드웨어 오프로딩을 끈 환경에서는 VXLAN 처리량이 21.82Gbit/s에서 29.39Gbit/s로 늘어 34.7% 높아졌다.
• 표준 MTU 환경의 Geneve 처리량은 37.39Gbit/s에서 40.89Gbit/s로 증가해 9.4% 개선됐다.

다만 이 수치를 Linux 7.3 전체의 보편적인 성능 향상으로 해석해서는 안 된다. 실제 결과는 gso_max_size와 gro_max_size, NIC 기능, 오프로딩 설정, MTU, 터널 종류, 트래픽 패턴 등 종단 간 구성에 따라 달라진다. VXLAN이나 Geneve를 운영하는 팀이라면 동일한 개선 폭을 기대하기보다 자체 환경에서 먼저 벤치마크하는 편이 안전하다.

라우팅 규칙 업데이트의 RTNL 병목 완화

이번 병합에는 IPv4·IPv6 FIB(Forwarding Information Base) 규칙을 삽입하고 삭제할 때 광범위한 RTNL 잠금에 의존하는 정도를 줄이는 변경도 포함됐다. 가능한 경우 관련 fib_rules_ops에 연결된 뮤텍스 보호를 사용해 여러 작업이 병렬로 진행될 수 있도록 한 것이다. 다만 첫 번째 IPv4 규칙의 fib_unmerge() 경로를 포함해 일부 작업에는 여전히 RTNL이 필요하다.

극단적인 잠금 경합 상황을 재현한 합성 테스트에서는 성능 차이가 크게 나타났다. 네트워크 네임스페이스 4,096개를 만들고 각 네임스페이스에 규칙 1,024개를 병렬로 추가하는 데 걸린 시간은 다음과 같이 줄었다.

• IPv4: 22.752초 → 0.918초, 약 24.8배 향상
• IPv6: 35.181초 → 1.214초, 약 29.0배 향상

이 결과는 대규모 네임스페이스 관리에서 발생하는 심각한 잠금 경합을 측정한 것이다. 일반적인 컨테이너 시작 시간이 동일한 비율로 빨라진다거나 모든 라우팅 작업에서 같은 효과가 나온다는 의미는 아니다.

AI 생성 패치 급증에 대응하는 유지보수팀

Linux 네트워킹 서브시스템은 AI 보조 커널 개발의 시험대가 되고 있다. 네트워킹 유지보수 담당자인 야쿱 키친스키(Jakub Kicinski)는 net 패치 632개와 net-next 패치 648개를 집계했다. 또 net-next의 약 3분의 1에서 절반가량이 AI가 주도한 우선순위 낮은 수정, 코드 정리, 설명 보완 작업일 수 있다고 추정했다. 이는 대략 216~324개 패치에 해당한다. 키친스키와 파올로 아베니(Paolo Abeni)는 이로 인한 업무량을 “완전히 감당할 수 없는 수준”이라고 설명했다.

대응책은 단일 AI 모델로 유지보수자를 대체하는 것이 아니다. Meta가 여러 프런티어 모델을 활용할 수 있도록 예산과 접근 권한을 제공하고, 각 패치에 대해 여러 모델이 1차 검토를 수행하도록 하는 방안이 제시됐다. 한 모델의 환각이나 잘못된 해석이 검토 과정에서 걸러지지 않고 통과할 가능성을 줄이려는 목적이다.

자동화 대상으로는 Patchwork 관리, 반복적인 절차 피드백, 커밋 메시지 편집, 신뢰할 수 있는 사람이 이미 검토한 패치의 적용 등이 거론됐다. 이런 작업은 드문 장애 경로의 정확성을 판단하는 일보다 규칙화하기 쉽다.

하지만 커널 네트워킹에서는 이 차이가 특히 중요하다. PCIe 오류나 타임아웃 처리처럼 흔하지 않은 경쟁 조건과 하드웨어 복구 경로는 여전히 사람이 살펴봐야 한다. AI가 반복적인 분류와 절차 작업을 덜어줄 수는 있어도 동시성, API 계약, 복구 순서를 이해해야 하는 책임까지 없애지는 못한다.

새 드라이버와 프로토콜 개선

이번 네트워킹 병합에는 하드웨어와 프로토콜 지원 확대도 포함됐다.

• Morse Micro의 mm81x Wi-Fi HaLow 드라이버 초기 버전이 USB와 SDIO 장치를 지원한다.
• NXP의 새 무선 드라이버인 NXPWIFI가 추가됐으며, 멀티링크 동작 관련 작업도 계속된다.
• Intel은 E2100 이상 IPU와 FNIC에서 Control Plane PIC Function을 지원하기 위한 iXD 드라이버의 초기 뼈대를 도입했다.
• 유선 네트워킹에는 AMD/Solarflare NIC를 위한 초기 CXL 지원과 AMD Pensando 하드웨어의 펌웨어 플래시 기능이 추가됐다.

세부 기능 중에는 메모리 압박이 극심할 때 MPTCP의 순서가 뒤바뀐 패킷 큐를 최후의 수단으로 정리하는 메커니즘도 있다. 이는 제한된 자원에서 복구와 재전송을 돕는 기능이지, 평상시 처리량을 높인다는 약속은 아니다.

AF_UNIX의 파일 디스크립터 전달 진단도 개선된다. SCM_RIGHTS 배열에 포함된 특정 파일 디스크립터를 LSM이 차단했을 때 SO_RIGHTS_NOTRUNC를 사용하면 수신 측에서 거부된 디스크립터와 errno를 확인할 수 있다. 기존처럼 첫 번째 거부 지점에서 배열의 나머지 항목까지 잃는 상황을 피할 수 있다.

Linux 7.3은 언제 사용할 수 있나

첫 번째 Linux 7.3 릴리스 후보인 7.3-rc1은 2026년 8월 30일 전후, 안정 버전은 정상적인 개발 일정이 유지될 경우 10월 말 출시가 예상된다.

다만 안정 버전이 나온다고 해서 대부분의 서버와 데스크톱이 곧바로 이 네트워킹 기능을 받는 것은 아니다. 각 배포판은 커널 버전을 자체적으로 선택하고, 일부 변경 사항을 백포트한 뒤 별도 테스트와 배포 절차를 거친다. 롤링 릴리스 배포판은 비교적 빠르게 패키지를 제공할 수 있지만, 고정 릴리스 배포판은 상당히 더 오래 걸릴 수 있다.

롤링 모델을 따르는 CachyOS는 조기 도입 가능성이 있는 배포판으로 볼 수 있다. 그러나 8월 공개 이미지가 Linux 7.3을 채택했다는 확정 일정은 확인되지 않았으며, 당시 이미지는 Linux 7.1을 사용하고 있었다.

실제로 주목할 부분

인프라 운영자에게 가장 직접적인 의미가 있는 변화는 BIG TCP의 오버레이 경로 지원과 대규모 네트워크 네임스페이스 관리에서의 경합 완화다. VXLAN 또는 Geneve를 통해 고속 트래픽을 처리하거나, 많은 네임스페이스를 동시에 생성·설정하는 환경이라면 특히 검토할 가치가 있다.

커널 개발자에게는 AI 패치 검토 실험이 그에 못지않게 중요하다. 이번 병합은 역할 분담의 한 가지 방향을 보여준다. 모델은 반복적인 분류와 절차 피드백을 맡고, 유지보수자는 시스템 교착, 복구 순서 오류, 암묵적인 동기화 규칙 위반처럼 겉보기에는 그럴듯하지만 치명적일 수 있는 예외 상황을 책임지는 방식이다.

Linux 7.3은 상당한 네트워킹 기능을 갖추고 다음 단계로 넘어갔다. 그러나 실제 사용자가 안심하고 활용하려면 릴리스 후보 테스트, 하드웨어 검증, 각 배포판의 통합 작업을 더 거쳐야 한다.

공개된 netperf TCP_STREAM 측정 결과는 다음과 같다.

• 표준 MTU 환경에서 VXLAN 처리량은 34.44Gbit/s에서 39.56Gbit/s로 증가해 14.9% 개선됐다.
• 터널 하드웨어 오프로딩을 끈 환경에서는 VXLAN 처리량이 21.82Gbit/s에서 29.39Gbit/s로 늘어 34.7% 높아졌다.
• 표준 MTU 환경의 Geneve 처리량은 37.39Gbit/s에서 40.89Gbit/s로 증가해 9.4% 개선됐다.

다만 이 수치를 Linux 7.3 전체의 보편적인 성능 향상으로 해석해서는 안 된다. 실제 결과는 gso_max_size와 gro_max_size, NIC 기능, 오프로딩 설정, MTU, 터널 종류, 트래픽 패턴 등 종단 간 구성에 따라 달라진다. VXLAN이나 Geneve를 운영하는 팀이라면 동일한 개선 폭을 기대하기보다 자체 환경에서 먼저 벤치마크하는 편이 안전하다.

라우팅 규칙 업데이트의 RTNL 병목 완화

이번 병합에는 IPv4·IPv6 FIB(Forwarding Information Base) 규칙을 삽입하고 삭제할 때 광범위한 RTNL 잠금에 의존하는 정도를 줄이는 변경도 포함됐다. 가능한 경우 관련 fib_rules_ops에 연결된 뮤텍스 보호를 사용해 여러 작업이 병렬로 진행될 수 있도록 한 것이다. 다만 첫 번째 IPv4 규칙의 fib_unmerge() 경로를 포함해 일부 작업에는 여전히 RTNL이 필요하다.

극단적인 잠금 경합 상황을 재현한 합성 테스트에서는 성능 차이가 크게 나타났다. 네트워크 네임스페이스 4,096개를 만들고 각 네임스페이스에 규칙 1,024개를 병렬로 추가하는 데 걸린 시간은 다음과 같이 줄었다.

• IPv4: 22.752초 → 0.918초, 약 24.8배 향상
• IPv6: 35.181초 → 1.214초, 약 29.0배 향상

이 결과는 대규모 네임스페이스 관리에서 발생하는 심각한 잠금 경합을 측정한 것이다. 일반적인 컨테이너 시작 시간이 동일한 비율로 빨라진다거나 모든 라우팅 작업에서 같은 효과가 나온다는 의미는 아니다.

AI 생성 패치 급증에 대응하는 유지보수팀

Linux 네트워킹 서브시스템은 AI 보조 커널 개발의 시험대가 되고 있다. 네트워킹 유지보수 담당자인 야쿱 키친스키(Jakub Kicinski)는 net 패치 632개와 net-next 패치 648개를 집계했다. 또 net-next의 약 3분의 1에서 절반가량이 AI가 주도한 우선순위 낮은 수정, 코드 정리, 설명 보완 작업일 수 있다고 추정했다. 이는 대략 216~324개 패치에 해당한다. 키친스키와 파올로 아베니(Paolo Abeni)는 이로 인한 업무량을 “완전히 감당할 수 없는 수준”이라고 설명했다.

대응책은 단일 AI 모델로 유지보수자를 대체하는 것이 아니다. Meta가 여러 프런티어 모델을 활용할 수 있도록 예산과 접근 권한을 제공하고, 각 패치에 대해 여러 모델이 1차 검토를 수행하도록 하는 방안이 제시됐다. 한 모델의 환각이나 잘못된 해석이 검토 과정에서 걸러지지 않고 통과할 가능성을 줄이려는 목적이다.

자동화 대상으로는 Patchwork 관리, 반복적인 절차 피드백, 커밋 메시지 편집, 신뢰할 수 있는 사람이 이미 검토한 패치의 적용 등이 거론됐다. 이런 작업은 드문 장애 경로의 정확성을 판단하는 일보다 규칙화하기 쉽다.

하지만 커널 네트워킹에서는 이 차이가 특히 중요하다. PCIe 오류나 타임아웃 처리처럼 흔하지 않은 경쟁 조건과 하드웨어 복구 경로는 여전히 사람이 살펴봐야 한다. AI가 반복적인 분류와 절차 작업을 덜어줄 수는 있어도 동시성, API 계약, 복구 순서를 이해해야 하는 책임까지 없애지는 못한다.

새 드라이버와 프로토콜 개선

이번 네트워킹 병합에는 하드웨어와 프로토콜 지원 확대도 포함됐다.

• Morse Micro의 mm81x Wi-Fi HaLow 드라이버 초기 버전이 USB와 SDIO 장치를 지원한다.
• NXP의 새 무선 드라이버인 NXPWIFI가 추가됐으며, 멀티링크 동작 관련 작업도 계속된다.
• Intel은 E2100 이상 IPU와 FNIC에서 Control Plane PIC Function을 지원하기 위한 iXD 드라이버의 초기 뼈대를 도입했다.
• 유선 네트워킹에는 AMD/Solarflare NIC를 위한 초기 CXL 지원과 AMD Pensando 하드웨어의 펌웨어 플래시 기능이 추가됐다.

세부 기능 중에는 메모리 압박이 극심할 때 MPTCP의 순서가 뒤바뀐 패킷 큐를 최후의 수단으로 정리하는 메커니즘도 있다. 이는 제한된 자원에서 복구와 재전송을 돕는 기능이지, 평상시 처리량을 높인다는 약속은 아니다.

AF_UNIX의 파일 디스크립터 전달 진단도 개선된다. SCM_RIGHTS 배열에 포함된 특정 파일 디스크립터를 LSM이 차단했을 때 SO_RIGHTS_NOTRUNC를 사용하면 수신 측에서 거부된 디스크립터와 errno를 확인할 수 있다. 기존처럼 첫 번째 거부 지점에서 배열의 나머지 항목까지 잃는 상황을 피할 수 있다.

Linux 7.3은 언제 사용할 수 있나

첫 번째 Linux 7.3 릴리스 후보인 7.3-rc1은 2026년 8월 30일 전후, 안정 버전은 정상적인 개발 일정이 유지될 경우 10월 말 출시가 예상된다.

다만 안정 버전이 나온다고 해서 대부분의 서버와 데스크톱이 곧바로 이 네트워킹 기능을 받는 것은 아니다. 각 배포판은 커널 버전을 자체적으로 선택하고, 일부 변경 사항을 백포트한 뒤 별도 테스트와 배포 절차를 거친다. 롤링 릴리스 배포판은 비교적 빠르게 패키지를 제공할 수 있지만, 고정 릴리스 배포판은 상당히 더 오래 걸릴 수 있다.

롤링 모델을 따르는 CachyOS는 조기 도입 가능성이 있는 배포판으로 볼 수 있다. 그러나 8월 공개 이미지가 Linux 7.3을 채택했다는 확정 일정은 확인되지 않았으며, 당시 이미지는 Linux 7.1을 사용하고 있었다.

실제로 주목할 부분

인프라 운영자에게 가장 직접적인 의미가 있는 변화는 BIG TCP의 오버레이 경로 지원과 대규모 네트워크 네임스페이스 관리에서의 경합 완화다. VXLAN 또는 Geneve를 통해 고속 트래픽을 처리하거나, 많은 네임스페이스를 동시에 생성·설정하는 환경이라면 특히 검토할 가치가 있다.

커널 개발자에게는 AI 패치 검토 실험이 그에 못지않게 중요하다. 이번 병합은 역할 분담의 한 가지 방향을 보여준다. 모델은 반복적인 분류와 절차 피드백을 맡고, 유지보수자는 시스템 교착, 복구 순서 오류, 암묵적인 동기화 규칙 위반처럼 겉보기에는 그럴듯하지만 치명적일 수 있는 예외 상황을 책임지는 방식이다.

Linux 7.3은 상당한 네트워킹 기능을 갖추고 다음 단계로 넘어갔다. 그러나 실제 사용자가 안심하고 활용하려면 릴리스 후보 테스트, 하드웨어 검증, 각 배포판의 통합 작업을 더 거쳐야 한다.