리누스 토르발스가 예고한 대로 일요일 오후 리눅스 7.3 커널 정식판을 내놓았다. 특별한 막판 변수 없이 지난 한 주가 조용히 지나갔고, 그 결과 최종 릴리스가 예정대로 나왔다는 것이 그의 설명이다. 이로써 다음 날부터 7.4 개발을 위한 머지 윈도(merge window)가 열린다. 다만 토르발스 본인은 연례 가족 휴가 중이라 한동안 평소와 다른 일정으로 패치를 받을 예정이라고 덧붙였다. 아침에 곧바로 병합 작업을 시작하는 대신 대부분의 시간을 배 위와 물속에서 보내고 오후에야 작업에 복귀하겠다는 것이다. 커널 개발이 특정 개인의 일정에 좌우될 만큼 여전히 사람 중심으로 돌아간다는 점을 보여주는 대목이다.
숫자로 본 7.3
이번 릴리스는 여러 면에서 기록을 새로 썼다. 병합 커밋을 제외하고 1만 8,765건의 커밋이 들어왔으며, 참여 개발자는 3,021명에 달한다. 이 가운데 807명은 커널에 처음 기여한 신규 개발자다. 전체의 약 4분의 1이 신규 참여자라는 사실은 커널 생태계로의 진입 장벽이 낮아지고 있거나, 적어도 새로운 하드웨어·드라이버·기능을 들고 들어오는 외부 조직과 개인의 유입이 꾸준하다는 신호로 읽을 수 있다. 실무 관점에서 커밋 수 자체가 품질을 보장하지는 않지만, 특정 릴리스에 변경이 몰릴수록 초기 마이너 버전에서 회귀(regression) 가능성도 함께 커지는 경향이 있다. 운영 환경 도입을 검토한다면 7.3.0을 곧바로 올리기보다 몇 차례 안정화 패치를 지켜보는 편이 안전하다.
눈여겨볼 기능 변경
기능 측면에서 7.3은 성능과 관측성 양쪽을 건드린다. 우선 대규모 시스템의 성능 개선을 겨냥한 그룹 스케줄링 작업이 포함됐고, 사용자 공간에서 커스텀 스케줄러를 작성할 수 있게 해 주는 sched_ext 서브스케줄러 기능이 이번에 완성됐다. sched_ext는 BPF를 활용해 워크로드 특성에 맞춘 스케줄링 정책을 운영 중에 실험할 수 있다는 점에서, 데이터센터나 지연 시간에 민감한 서비스를 운영하는 쪽에서 특히 관심을 둘 만하다. BPF 프로그램을 위한 전역 per-CPU 데이터 지원이 추가된 점도 같은 맥락에서 관측·제어 도구를 만드는 개발자에게 실질적인 도구를 늘려 준다.
가상화 영역에서는 가상 머신에 대한 워킹셋(working-set) 추적이 들어왔다. 게스트가 실제로 활발히 사용하는 메모리 집합을 호스트가 파악할 수 있게 되면 메모리 과잉 할당 환경에서의 배치나 회수 판단이 정교해진다. 클라우드나 사내 가상화 기반을 운영하는 입장에서는 메모리 효율을 끌어올릴 여지가 생기는 변화다.
파일시스템과 상호운용 쪽 변화도 적지 않다. ntfs3 드라이버가 대체 데이터 스트림(ADS)을 지원하게 되어 윈도 환경에서 생성된 NTFS 볼륨을 다룰 때 호환성이 높아진다. SMB 서버에도 긴 목록의 개선이 들어가, 리눅스를 파일 서버로 쓰면서 윈도 클라이언트와 연동하는 환경에 도움이 될 전망이다. 시스템 콜 수준에서는 fchroot() 호출이 새로 추가됐는데, 기존 chroot가 경로를 받는 것과 달리 파일 디스크립터 기반으로 동작해 컨테이너나 샌드박스를 구성할 때 경쟁 조건을 줄이는 데 쓸 수 있다. binfmt_misc 확장도 포함돼 바이너리 포맷 처리 방식에 유연성이 더해졌다.
failfs라는 흥미로운 추가
다소 이례적인 항목은 모든 연산을 실패시키는 새 파일시스템 failfs다. 이름 그대로 어떤 요청이든 오류를 돌려주는 파일시스템으로, 실용적 저장 용도가 아니라 테스트와 디버깅을 위한 도구에 가깝다. 애플리케이션이 파일시스템 오류를 만났을 때 어떻게 반응하는지, 오류 처리 경로가 제대로 동작하는지를 검증하려는 개발자에게는 의도적으로 실패를 주입할 수 있는 수단이 된다. 견고성 테스트를 자동화 파이프라인에 넣고 싶은 팀이라면 실제로 쓸모를 찾을 수 있는 기능이다.
전체적으로 7.3은 극적인 단일 기능보다 성능·관측·상호운용성 전반을 조금씩 끌어올리는 성격의 릴리스로 보인다. 다만 지금 공개된 내용은 릴리스 공지 수준의 요약이며, 각 기능의 세부 동작과 설정 방법, 알려진 제약은 LWN의 머지 윈도 정리와 KernelNewbies 7.3 페이지 같은 상세 문서를 직접 확인해야 한다. 특히 sched_ext나 BPF 관련 기능처럼 운영 정책에 직접 영향을 주는 요소는 문서와 함께 충분한 사전 검증을 거쳐 도입하는 것이 바람직하다.