이번 주 LWN.net 위클리 에디션(10월 15일자) 주요 내용이다. 프라하에서 열린 2026 메인테이너 서밋은 거의 모든 시간을 LLM 이야기에 썼다. Sashiko 리뷰 방식, 새 기여자 우선순위 낮추기, Assisted-by 태그 폐지, 보안 패치 홍수, 그리고 리누스 토발즈의 은퇴 이후를 대비한 승계 논의까지 나왔다. 같은 주 GNU Tools Cauldron에서는 LLM 생성 코드를 받지 않는 GCC가 그래도 LLM을 어디에 쓰고 있는지, Kees Cook이 GCC에 커널용 KCFI를 직접 구현한 과정이 소개됐다. 여기에 systemd의 1년 결산, LTTng가 빠진 out-of-tree 트레이서의 딜레마, zswap 낭비를 없애려는 vswap과 xswap의 경쟁, Rust 프로젝트 목표 현황, C에서 할당한 객체를 Rust가 소유하는 Owned 포인터, 두 살이 된 KDE Linux까지 정리한다.
- The 2026 Maintainers Summit — “LLM 탓이 아니라 쓰는 사람 탓”, 새 기여자는 후순위로,
Assisted-by는 폐지, 그리고 토발즈 이후의 승계 - GCC development with large-language models — LLM 코드는 받지 않는 GCC, 대신 버그 원인 추적·프로토타이핑·코드 생성 품질 분석에 쓴다
- Adding kernel control-flow-integrity checking to GCC — 아무도 안 하길래 직접 했다, Kees Cook의
-fsanitize=kcfi - The state of systemd: 2026 edition — 분기별 릴리스, 버그 바운티 183건 중 13건만 인정,
dlopen()전환 완료와 cloud-init 대체재 - Collaborating with out-of-tree tracers — 들어오려면 조금씩 넣으라는데, 넣은 기능은 쓸 수 없는 LTTng의 캐치-22
- The [vx]swap showdown — zswap 때문에 비워둬야 하는 스왑 공간, vswap과 xswap 중 무엇이 먼저 들어갈까
- An update on Rust’s project goals — Rust for Linux 로드맵의 13개 목표와 그것들이 진행되는 방식
- Owning C types from Rust code — C 풀에서 꺼낸 객체를 Rust가 유일 소유하는
Owned와Ownable, 22번째 버전 - KDE Linux at two — 롤백이 있어 알파도 주력으로 쓴다는 KDE의 이미지 기반 배포판, 베타까지 85%
- 짧은 소식: Let’s Encrypt 64일 인증서, Nix/Lix 권한 상승 취약점, 커널 7.3-rc7과 ext4
data=journal폐기 예고, 토발즈의 첫 LLM 보조 패치, Asterinas 0.19, LineageOS 24, KDE Plasma 6.8, PostgreSQL 19 기능 대량 revert, Python 3.15
2026 메인테이너 서밋
메인테이너 서밋(Maintainers Summit)은 커널 개발자 약 30명이 초청받아 하루 동안 모이는 행사다. 메일로는 결론이 잘 안 나는 정책 문제를 다룬다. 올해는 10월 8일 프라하에서 열렸고, 예상대로 LLM과 그것이 개발 커뮤니티에 미치는 영향이 대부분을 차지했다. 보안 버그와 장기 승계 계획에도 시간을 썼다. 예년과 달리 주제별 발제자를 정해두지 않고 자유롭게 대화가 흘렀다.
Jonathan Corbet이 기사 서두에 정리한 요약(공식 입장이 아니라 그의 해석)은 다음과 같다.
| 주제 | 결론 |
|---|---|
| Sashiko 리뷰 | 기존 버그는 더 이상 패치 리뷰에 포함하지 않는다. 반응은 엇갈렸고, 리뷰를 받자마자 고쳐서 다시 보내는 악순환을 부추긴다는 우려가 있다 |
| LLM 책임론 | 토발즈: 문제는 LLM이 아니라 LLM도 커널도 모르는 사용자다. 잘 길들인 LLM은 유용하지만 그 단계까지 시간이 많이 든다 |
| 새 기여자 | 저품질 기여는 후순위로. 기여를 쉽게 만들려는 노력은 그만두자. 이런 기여자 멘토링은 대부분 시간 낭비라는 의견이 반복됐다 |
| 사설 커널 | LLM으로 사설 커널을 유지하는 기업에 대한 우려가 있지만 할 수 있는 일은 별로 없다 |
| LLM 사용 의무 | LLM 사용을 강제하지 않는다. 다만 쓰는 사람은 쓸 만한 결과를 낼 만큼의 자원을 갖춰야 한다 |
Assisted-by | 태그 요구는 폐지. 그래도 메인테이너는 패치가 어떻게 만들어졌는지 알고 싶어 한다 |
| 보안 패치 | 홍수는 당분간 계속된다. 가장 급한 수정은 메인테이너를 거치지 않고 토발즈에게 바로 갈 수 있다. 공개 전 취약점을 고용주에게 알리지 말 것 |
| 승계 | 토발즈가 몇 년 뒤 은퇴할 때를 대비해 리더십 승계 방식을 지금부터 생각하자 |
Sashiko와 기존 버그 보고
첫 주제는 자동 패치 리뷰, 그중에서도 Sashiko였다. Sashiko는 패치를 보면서 그 패치가 건드리는 코드에 원래 있던 문제까지 찾아 보고하곤 한다. 버그를 아는 건 좋지만, 정작 넣고 싶은 변경을 머지하려면 넘어야 할 장애물처럼 긴 목록을 받는 건 누구도 반기지 않는다. 최근 개발자 Roman Gushchin은 기존 버그를 리뷰에서 빼고 별도 데이터베이스에 모아 메인테이너가 볼 수 있게 하겠다고 발표했다.
Ted Ts’o가 이 변경을 꺼내자 Peter Zijlstra는 그 버그들도 알아야 하는데 왜 뺐냐고 물었다. Christoph Hellwig는 리뷰에 남기되 “고칠 의무 없음”으로 구분 표시하자고 했고, Mark Brown도 오타 수정 하나 넣으려고 구조적 문제를 고칠 필요는 없다고 동의했다. Dave Airlie는 패치 리뷰와 기존 문제 목록을 메일 두 통으로 나누자고 제안했다. Ts’o는 정답이 서브시스템마다 다르다고 봤다. 큰 서브시스템의 서브 메인테이너는 리포트가 맞는지 판단할 역량이 부족해 오탐(false positive)에 더 고생하고, 전문가 메인테이너가 있는 작은 서브시스템은 이를 잘 소화한다.
회의 내내 반복된 불만도 여기서 나왔다. David Hildenbrand는 사람 리뷰어가 패치의 방향이 맞는지 말하기도 전에 제출자가 Sashiko 지적을 반영한 새 버전을 계속 보낸다고 했다. Sashiko 리뷰가 사람 리뷰를 위축시킨다는 것이다. 그는 Sashiko를 첫 방어선이 아니라 마지막 방어선으로 두고, 자동 리뷰 시점을 메인테이너가 정하자고 했다. Thomas Gleixner는 최악의 제출자는 리뷰를 그대로 자기 LLM에 넣고 그 답을 보낸다고 꼬집었다. 반면 Paolo Abeni는 자동 리뷰 덕분에 버그를 들여오는 패치가 크게 줄었다고 옹호했고, Zijlstra도 LLM 리뷰를 읽으면 “뇌가 꺼지지만” 진짜 문제를 찾는 유용한 도구라고 했다.
토발즈: LLM이 아니라 사용자가 문제다
리뷰 우선순위 이야기가 이어지던 중 그때까지 침묵하던 토발즈가 입을 열었다. 커널을 모르는 사람의 패치가 늘고 있는 것이 문제인데, LLM을 탓하는 건 엉뚱한 곳을 가리키는 것이라고 했다. LLM은 일을 잘할 수 있지만 아무것도 모르는 사람이 운전하면 결과가 흉해진다. 그는 Sashiko 리포트를 24시간 늦추자고 제안했다. 즉각 응답을 받고 새 버전을 찍어내는 일을 막자는 것이다.
그는 몇 달간 별도 프로젝트로 LLM을 익혀왔고, 커널에는 지난주에 처음 썼다. 오래된 패치를 LLM으로 다듬어 봤더니 이제 LLM 없이는 일하기 싫어졌다고 했다. 방금 고친 함수의 호출 지점을 일일이 찾을 필요 없이 도구가 다 고쳐준다. 다만 나쁜 응답을 내지 않도록 도구를 세팅하는 데 6개월이 걸렸다. 유능한 개발자에게 LLM은 훌륭한 도구지만 그 노력을 들인 뒤의 이야기다. 학습 자료를 공개해 달라는 요청은 각자 그 과정을 거쳐야 한다며 거절했다.
Hildenbrand가 “당신은 전문가지만 우리는 비전문가 패치도 상대해야 한다”고 하자 토발즈는 그냥 후순위로 미루라고 답했다. Zijlstra는 패치에 답장을 보내 LLM이 쓴 글이 돌아오는지 보면 된다고 했고, Greg Kroah-Hartman은 include 순서 같은 사소한 지적의 가치가 거기 있다고 했다. Christian Brauner는 지나치게 장황한 체인지로그가 LLM 사용의 징후라고 했다. 코드는 LLM이 쓰더라도 체인지로그는 사람이 써야 한다는 데 대체로 합의했고, Sasha Levin은 LLM이 체인지로그를 쓰지 못하게 하는 가이드를 저장소에 넣는 작업을 이어가기로 했다.
Kroah-Hartman은 앞으로 18개월은 소방 호스를 맞는 상황이 이어지고, 그 뒤엔 버그 대부분이 고쳐져 나아질 것이라고 했다. Laurent Pinchart는 버그만 고쳐선 부족하다며, 커널에는 올바르게 쓰기보다 잘못 쓰기가 더 쉬운 나쁜 API가 가득하다고 반박했다.
사설 커널, 그리고 기여 문턱
Brauner는 기업들이 업스트림을 신경 쓰지 않고 사설 포크를 유지하는 데 관심을 키우고 있다고 했다. Zijlstra는 그게 얼마나 잘 되는지 Google에 물어보라고 했고, Gleixner는 커널 유지보수의 근본 경제학은 바뀌지 않았다고 했다. Miguel Ojeda는 LLM으로 Rust로 된 커널 전체를 “소환”한 사람을 안다며, 업스트림 작업이 그보다 쌀 수 있냐고 물었다. Alexei Starovoitov는 이렇게 생성된 동작하는 커널을 다섯 개 안다고 했지만, 토발즈는 걱정할 필요가 없다고 답했다. Ts’o는 특정 용도의 빠른 마이크로커널은 지금도 만들 수 있지만, 온갖 코너 케이스를 다루는 범용 커널은 다른 이야기라고 했다.
Corbet은 아껴둔 일화를 꺼냈다. 새 계정이 한 시간 안에 커널 트리 전역을 크게 바꾸는 패치 100여 개를 보냈다. 모아 보면 풀려난 봇이 분명하지만, 메인테이너 대부분은 몇 개만 보고 진지하게 응대했고 상당수가 적용됐다. 7.3에서만 첫 기여자가 800명 가까이 된다. 그의 걱정은 아무도 이해하지 못하는 코드가 쌓여 어느 날 커널의 통제권을 완전히 잃는 것이다. Airlie는 원래 통제한 적이 없다고 받았다.
토발즈는 이제 새 사람이 커널에 코드를 기여하기 더 어렵게 만들 때라고 했다. Kroah-Hartman처럼 기여 방법을 가르치느라 수년을 쓴 일을 그만두자는 것이다. 그는 커널 코드 생성을 비싸게 만드는 AGENTS.md를 넣자고도 했다. 그는 매 세션을 코드와 주석이 맞는지 확인하는 등 몇 시간짜리 정리 단계로 끝내는데, 무료 LLM 계정으로는 그 분량을 감당할 수 없다. 뛰어난 신인을 놓칠 위험을 묻자 커널은 진지한 개발자만 원하며, 그 세계에서 일할 자원을 갖추는 것도 거기 포함된다고 답했다. Pinchart가 LLM을 안 쓰는 개발자를 밀어내려는 게 아니냐고 확인하자 토발즈는 아니라고 했다. 코드를 쓰고 메일을 보내는 건 언제나 가능하다. 그의 메시지는 “배우는 노력을 들이거나, LLM에 큰돈을 들이거나”다.
반론도 있었다. Ojeda는 우선순위를 낮추더라도 재능 있는 사람은 찾아야 한다고 했다. 시간을 내 컨퍼런스에 오는 사람은 오래 남을 가능성이 높다. Shuah Khan은 남을 사람을 꽤 빨리 알아볼 수 있고 새로 온 사람 중에도 훌륭한 이가 있다며 여전히 오타 수정 제출자에게 시간을 쓴다고 했다. Airlie는 아이디어가 나오자마자 누군가 LLM으로 구현을 소환해버리면 그 사람들이 쓸 게 남지 않을 수 있다고 걱정했다. LLM 코드 생성이 의미 있는 곳으로는 명확한 명세가 있는 구체적 문제, 개념 시험(결과 코드를 보지도 않고 버린 뒤 제대로 구현), 테스트 생성, 프로토타이핑이 꼽혔다.
Assisted-by 태그 폐지
7.0에서 추가된 Documentation/process/coding-assistants.rst는 LLM 보조로 만든 패치의 체인지로그에 Assisted-by 태그를 붙이라고 요구한다. 7.3은 -rc7까지 머지 제외 체인지셋 18,533건(역대 최다)이 들어갔고, 그중 1,884건(약 10%)에 이 태그가 있다. 실제 LLM 보조 패치는 훨씬 많을 것이다. Corbet은 규칙을 몰라서든 일부러 숨기려서든 태그를 안 붙이는 기여자가 많고, 확인하는 메인테이너도 드물어 태그가 쓸모 있는 신호가 못 된다고 지적했다. 강제할 방법을 찾든지 아예 없애자는 것이다.
Airlie는 지금 기여자의 90%가 LLM을 쓸 것이고 많은 이가 반 LLM 마녀사냥을 두려워한다고 했다. 토발즈는 많은 제출자가 그냥 쓴다고 인정하기 부끄러워한다고 봤다. Gleixner가 반쯤 농담으로 Not-assisted-by 태그를 제안하자 Arnd Bergmann은 그게 시간을 들여 도와줄 개발자를 알려주는 유용한 지표가 되겠다고 했다. Khan은 여전히 태그가 유용하다고 했지만, 태그가 수명을 다했고 요구를 없애도 된다는 강한 합의가 있었다. 다만 어떤 모델을 개발의 어느 단계에서 썼는지, 사람이 관여했는지는 알고 싶다는 의견이 많아 체인지로그 대신 커버 레터에 적자는 방향이 나왔다.
보안 버그와 긴급 수정
Kroah-Hartman은 보안 버그가 훨씬 더 쏟아질 것이라고 했다. 지금 도구는 취약점을 많이 찾지만 절반은 틀리고, 그 성능을 높이는 일을 하는 학생들과 수정 처리를 도울 인력·자금도 있다. 다음 1년은 이 더미를 처리하는 데 집중된다. Levin은 LLM이 새로 하는 일이 두 가지라고 했다. 패치에서 익스플로잇을 만드는 것, 그리고 메일링 리스트를 감시해 어떤 수정이 보안 의미가 있는지 알아내는 것이다. 그 결과 자동으로 익스플로잇을 찍어내는 기계가 생겼고, 문제가 발견되는 순간 엠바고는 이미 끝난 것이며, 지금 알려진 익스플로잇만 수천 개다.
할 수 있는 건 수정을 최대한 빨리 메인라인에 넣는 것뿐이다. Brauner가 그러면 -rc1 이후 큰 풀 리퀘스트가 생기는데 토발즈가 불평하지 않았냐고 하자, 토발즈는 진짜 문제의 수정임을 확인했다고 믿을 수 있는 사람이 보내면 괜찮다고 했다. 풀 한 번의 비용은 거의 0이고 그게 그의 일이다. 실제 커널 개발자가 관여한 가장 급한 패치는 메인테이너를 우회해 토발즈에게 바로 보낼 수 있다. Hildenbrand는 메인테이너가 자기 서브시스템 수정을 리뷰할 기회를 잃는다고 걱정했지만, 토발즈는 그걸 다 리뷰하는 건 모두에게 스트레스만 더한다고 답했다.
Kroah-Hartman은 이제 홍수를 따라가려고 보안 버그를 비밀로 두지 않고 바로 메인테이너에게 공유한다고 했다. 대신 공개 전에 고용주에게 알리면 프로젝트 전체가 각국 정부 기관과 마찰을 빚을 수 있다고 경고했다. 수정이 푸시되면 엠바고는 끝난다. 새 버그를 막는 쪽으로는 Rust 사용 확대(버그 다수가 에러 경로에 있고 Rust가 이를 더 잘 다룬다)와 C 코드 하드닝 확대가 언급됐다. Ojeda는 최신 컴파일러의 하드닝 기능을 개발자와 linux-next가 쉽게 쓸 수 있도록 미리 빌드된 툴체인(kernel.org 컨테이너 이미지)을 늘리는 작업을 소개했다.
메인테이너들의 고충
토발즈는 참석자마다 가장 큰 고충을 1분 안에 말하도록 미리 요청했다. 토론 없이 30분간 이어진 발표의 요지는 다음과 같다.
| 발표자 | 고충 |
|---|---|
| Greg Kroah-Hartman | CC: stable 태그는 안 붙이면서 중요한 수정은 stable 팀이 알아서 가져가길 기대하는 서브시스템. stable 팀은 이미 과부하라 그렇게 못 한다 |
| Laurent Pinchart | 패치가 언제 어느 트리에 적용됐는지 제출자가 모른다. 적용 시 메일을 보내달라 |
| Eric Biggers | 적용하기 어렵고 base도 명시하지 않은 패치. 적용해봐야 제대로 리뷰할 수 있다 |
| Rafael Wysocki | 피드백 부족. 의견은 있어도 공유하지 않는다 |
| Dave Airlie | 서브 메인테이너들이 꼽은 1위는 자기 자신. 진지하게는 DRM의 회귀가 여전히 많다. CI를 쓰려고 GitLab 이전 움직임이 있다 |
| Ted Ts’o | 볼 게 너무 많다. patchwork에 메인테이너용 우선순위 태그가 있었으면 |
| Alice Ryhl | 패치를 보낸 뒤 얼마나 기다려야 문제가 없다고 판단할 수 있는지 모르겠다 |
| Jonathan Corbet | 문서 디렉터리를 건드리는 패치 중 무엇을 자기가 적용할지 알기 어렵다. 토발즈도 같은 문제를 겪는다 |
| Shuah Khan | 테스트 패치를 누가 가져갈지 불분명하다 |
| David Hildenbrand | 리뷰 부하. 봇에 넘길 수 없고 전문가를 더 키워야 하는데 그럴 사람을 찾기 어렵다 |
| Arnd Bergmann | 리뷰 과정이 무너지고 있다. LLM을 쓰는 사람은 배우지 않아 가르치려는 의욕이 꺾였고, 배울 사람이 피드백을 못 받는다. 반대로 있어선 안 될 패치를 50번(말 그대로) 고쳐 보내는 사람도 있다 |
| Alexei Starovoitov | 버그나 코딩 스타일은 이제 봇 몫이다. 리뷰는 “왜”, 올바른 위치인지, 좋은 취향인지에 집중해야 한다 |
| Konstantin Ryabitsev | MAINTAINERS의 마지막 항목 “THE REST”가 모든 패치를 linux-kernel 리스트로 보내 하루 수백만 통의 발신 메일과 전달 문제를 만든다. 이후 다른 리스트가 없을 때만 linux-kernel을 넣도록 get_maintainer.pl 패치를 보냈다 |
| Sasha Levin | 서브시스템별 관행이 갈라져 각자 매뉴얼이 생겼다. 다시 하나로 모였으면 |
| Christoph Hellwig | Sashiko 리뷰 워크플로가 깨져 사람들이 계속 재전송한다 |
| Mark Brown | 테스트가 있는 서브시스템은 linux-next에서 깨지지 않게 실제로 빌드·실행해달라 |
| Jiri Kosina | 제출물 처리 우선순위를 정할 더 나은 방법. Ts’o의 아이디어는 좋지만 patchwork 없이 |
| Will Deacon | 더 이상 재미가 없다. 개선 방법을 설명해도 무시당한다 |
| Danilo Krummrich | 짧은 기간의 여러 버전은 괜찮지만, Sashiko 리뷰를 LLM에 넣어 버전을 만드는 건 문제다 |
| Paolo Abeni | 네트워킹은 자체 Sashiko를 돌려 결과가 더 좋지만 모든 네트워킹 서브시스템에 돌릴 수는 없다 |
| Eric Dumazet | 방금 은퇴했고, 모든 고충이 사라졌다 |
| Roman Gushchin | Sashiko는 실험에서 널리 쓰이는 도구가 됐다. 토큰 확보, 경영진 설득까지 해야 하니 사람과 피드백이 더 필요하다 |
| Julia Lawall | 버그를 찾고 고쳐온 자기 연구가 앞으로도 의미 있을지 모르겠다 |
| Miguel Ojeda | 트리 전역 리팩터링이 까다롭고 Rust 코드가 늘면 더 어려워질 것이다 |
| Thomas Gleixner | 설계 패턴을 긴 메일로 설명해왔지만 이제 대부분 무시된다. “설계할 시간 없고 코드는 돌아간다”는 세상에서 25년간 해온 정리 작업을 또 하게 될 코드는 머지하고 싶지 않다 |
| Christian Brauner | 코드 제거. 덜 고치고 더 많이 지울 때다 |
승계와 서밋 자체에 대한 논의
토발즈는 곧 2주 휴가를 가는데 머지 윈도와 겹쳐 머지 윈도를 3주로 늘릴까 생각 중이라고 했고, 반대는 거의 없었다. 이어 승계 이야기를 꺼냈다. 2025년 서밋의 승계 논의는 그가 갑자기 일을 못 하게 될 경우에 초점이 있었다. 올해는 당장 어디 가지 않지만, 토발즈 없는 미래로의 부드러운 이행을 미리 생각해도 이르지 않다고 했다. 그 준비로 메일을 일부러 더 무시하고 개발 질문에서 한발 물러나 커뮤니티의 반응을 보고 있다고 한다.
그의 역할은 “패치 원숭이(patch monkey)”(풀 리퀘스트 실행)와 개발자 간 갈등 조정(그 자신은 잘 못한다고 했다) 두 가지로 요약된다. 둘을 나누거나, 새 자비로운 독재자(benevolent dictator)를 세우거나, 위원회 모델로 갈 수도 있다. 결정은 없었고 지금 필요하지도 않다. 서밋 참석자로 시작하는 메일링 리스트를 만들어 논의를 이어가기로 했다. Gushchin은 1년 만에 세상이 이렇게 달라졌는데 몇 년 뒤의 일을 의미 있게 계획하기는 어려울 것이라고 덧붙였다.
마지막 주제는 서밋 자체였다. 8월 James Bottomley가 행사 존속 자체를 물은 스레드가 출발점이었다. 폐지하자는 사람은 드물었지만 참석자 선정이 닫힌 파벌 같다는 우려가 있었다. 토발즈는 150명까지 갔던 옛 커널 서밋 형식은 감당이 안 됐다고 했다. Ts’o는 LPC와 함께, 그리고 LPC 뒤에 여는 게 가장 좋다고 했고, Hellwig는 서브시스템별 “오피스 아워”를 제안해 호응을 얻었다. 내년 토픽 공모 문구는 선정 방식을 더 설명하고 다른 사람을 추천할 수 있음을 분명히 하는 쪽으로 바뀔 수 있다.
후속으로 토발즈는 이번 주에 첫 LLM 보조 패치 시리즈를 실제로 올렸다(아래 짧은 소식 참고). Brief items에 실린 Pinchart의 인용문은 서밋 이후 메일 스레드 분위기를 보여준다. “자기 영지에서 마음대로 쓰고 남용할 권력을 얻었다며 기뻐하는 사람들이 보인다. … 제출자가 메인테이너와 같은 사내 클럽에 다니지 않았다는 이유로 패치가 거절되는 일은 보지 않길 바란다.”
LLM 코드는 안 받는 GCC, 그래도 LLM을 쓰는 법
GCC 프로젝트는 오랜 논의 끝에 LLM 정책을 정했다. “LLM 생성 콘텐츠를 포함하거나 그로부터 파생된, 법적으로 의미 있는 기여는 거절한다.” 테스트 스위트 추가에는 더 느슨하게 적용되고, 코드 이해·버그 탐색·패치 리뷰 등에는 LLM을 쓸 수 있다. 법이 정리되지 않은 상황에서 저작권 오염을 피하려는 보수적 입장이며, 정기적으로 검토해 곧 바뀔 수도 있다. 2026 GNU Tools Cauldron에서 Jeff Law와 Kyrill Tkachov가 이 제약 안에서 LLM을 어떻게 쓰고 있는지 소개했다(정책 논쟁은 이 세션에서 금지).
Tkachov는 LLM을 가상 비서처럼 대하라고 했다. 모호한 요청을 잘 처리하고, 아이디어를 놓고 논쟁하기보다 일단 해보는 “할 수 있다” 태도가 있으며, 지루해하지 않아 반복 작업을 맡겨도 미안하지 않다. 그가 정리한 활용처는 다음과 같다.
| 용도 | 내용 |
|---|---|
| 버그 찾기 | 특정 코드 영역과 찾을 버그 종류를 지정해야 잘 된다. 틀리거나 빠진 테스트를 특히 잘 찾고, 최소 재현 코드와 깔끔한 버그 리포트를 만든다. 물론 사람 검토는 필수 |
| 근본 원인 추적 | 필요한 컴파일러 릴리스를 직접 빌드하고 LLVM 결과와 비교하며, GIMPLE·RTL 중간 표현을 보고 어느 패스가 깨졌는지 짚는다. 제안하는 수정이 늘 맞진 않지만 좋은 출발점이다 |
| 프로토타이핑·타당성 조사 | 어떤 최적화를 GIMPLE과 RTL 중 어디서 할지 LLM에게 둘 다 시켜보고 실제 효과 수치를 받는다. 방향이 정해지면 코드는 버리고 제대로 다시 쓴다 |
| 기타 | 놓친 최적화 기회 찾기, 빌드 시스템 개선, 데이터 수집, “만약 ~라면” 실험 |
그래도 코드 작성에 쓰는 건 정책이 허용하더라도 위험하다는 게 그의 결론이다. Jeremy Bennett가 LLM 의존이 커지면 코드를 실제로 이해하는 사람을 잃지 않겠냐고 묻자, Tkachov는 위험은 맞다고 인정하면서 자동차에 빗댔다. 예전엔 엔진 원리를 알아야 운전할 수 있었지만 지금은 아니다. 깊은 이해가 필요하면 지루해하지 않는 LLM에게 설명을 시키면 된다. Bennett는 그래도 경력 초기 개발자가 깊은 이해에 도달하지 못할까 걱정된다고 했다. Mathieu Desnoyers는 먼저 자기가 잘 아는 프로젝트에서 LLM의 한계를 익힌 뒤 새 영역으로 넓히고, 질문을 많이 하면 LLM이 스스로 오류를 바로잡기도 한다고 조언했다.
Law의 활용처는 더 구체적이다. 핫 블록을 찾는 QEMU 플러그인으로 컴파일러가 낸 어셈블리를 골라 LLM에게 비효율적인 코드 생성을 평가시킨다. 수년간 들여다본 인기 벤치마크 블록에서도 개선점이 나왔고, 살펴본 모든 벤치마크에서 개선을 찾았다. 가장 어려운 건 좋은 프롬프트였는데, 두 번째 LLM에게 첫 LLM의 프롬프트를 쓰게 해본 시도는 “비참한 실패”였다. 기존 코드 리뷰는 필요한 맥락이 작은 영역에서 잘 된다. match.pd의 패턴 평가가 좋은 예다. 다만 오류 유형을 원하는데 오류 목록을 쏟아내는 경향이 있고, 그래도 전부 진짜 버그였다.
패치 리뷰용으로는 메일 클라이언트에서 바로 돌리는 Thunderbird 플러그인을 만들었지만 쓸모 있는 지적은 20% 정도로 슬롭(slop)이 대부분이었다. 프롬프트에 구체적 지침을 넣을수록 나아졌는데, 그럴수록 Sashiko를 재구현하고 있었다. Sashiko에서 해온 작업 상당수가 GCC에도 일반적으로 적용된다는 뜻이다. 세션은 개발자가 자기 패치 리뷰에 LLM을 써야 하고 프롬프트를 공유할 방법이 있으면 좋겠다는 제안으로 끝났다. 독점 LLM을 자유 소프트웨어 개발에 쓰는 윤리 문제에 대해 Law는 타당한 우려가 있다고 인정하면서도 답은 줄 수 없다고 했다.
GCC에 커널 CFI 검사 추가하기
제어 흐름 무결성(Control-flow integrity, CFI)은 의도된 경로에서 제어 흐름을 빼돌리는 익스플로잇을 막거나 탐지하는 기법이다. 같은 Cauldron에서 Kees Cook은 커널용 forward-edge CFI를 GCC에 구현한 작업을 발표했다. 목표는 임의 메모리 쓰기 버그가 코드 실행 취약점으로 커지는 것을 막는 것이다. 실행 가능 메모리는 이미 쓰기 보호되어 있어 공격자는 기존 코드를 엉뚱하게 재사용하는 쪽, 특히 간접 함수 호출과 함수 반환을 가로채는 쪽에 집중한다.
| 구분 | 대상 | 방식 |
|---|---|---|
| Forward-edge CFI | 간접 호출(쓰기 가능한 메모리·레지스터에 있는 주소로 점프) | 이번 작업. 호출 대상이 호출자가 기대하는 프로토타입으로 정의된 함수인지 검사 |
| Backward-edge CFI | 함수 반환 | 하드웨어가 맡는 게 낫다(이번 발표 범위 밖) |
| 하드웨어 forward-edge (참고) | 함수 진입점 표시 | 함수 중간으로의 점프는 막지만, 완전히 다른 함수로의 점프는 못 잡는다 |
프로토타입 일치만으로 모든 오용을 막을 순 없지만 후보는 크게 줄어든다. 커널의 간접 호출 중 55%는 가능한 대상이 5개 미만이고, 100개를 넘는 경우는 7%뿐이다. 동작 원리는 함수 프로토타입에서 해시로 타입 ID를 만들고, 함수 진입점 바로 앞에 그 해시를, 호출 지점에는 해시의 2의 보수 역수를 넣는 것이다. 간접 호출 시 대상 함수에서 해시를 읽어 로컬 값과 더해 0이면 호출을 진행하고 아니면 트랩을 낸다. 경고만 내고 진행하는 permissive 모드와 패닉시키는 모드가 있다.
Clang은 2022년에 이를 구현했고 커널은 6.1부터 썼다. Cook은 GCC 구현을 오래 요청했지만 아무도 나서지 않아 직접 했고, 그 과정에서 왜 아무도 안 하려 했는지 알게 됐다고 한다. 컴파일러의 거의 모든 층을 건드려야 했기 때문이다.
| 층 | 작업 |
|---|---|
| C 프런트엔드 | -fsanitize=kcfi 옵션, 특정 호출(예: 타입 ID가 없는 BIOS 호출)의 검사를 끄는 속성, 인라인 함수 처리 |
| 타입 ID | Clang과 맞추려 Clang의 Itanium C++ 맹글러를 사용. Clang 쪽 해시도 컴파일러 개발자들이 없애고 싶어 하던 것이라 FNV-1a로 바꾸는 패치를 보냄(암호학적 안전성은 불필요) |
| 중간 층 | 대상 타입 ID를 담은 새 RTL 호출 래퍼, 꼬리 호출(tail call) 처리 |
| 백엔드 | 래핑된 호출을 실제 명령어로 변환하고 함수 프리앰블에 타입 ID 삽입. x86(32·64비트), arm64, RISC-V 지원 |
패치 시리즈의 절반은 회귀 테스트다. 개발하면서 “온갖 방식으로 망가뜨렸고” 그 방식마다 테스트를 하나씩 썼다. 스택 전체를 아우르는 GCC 패치는 드물어 리뷰어를 찾기 어려웠는데, GCC 글로벌 리뷰어 Andrea Pinski가 곧 전체 리뷰를 하겠다고 했다. LLM 사용도 밝혔다. GCC 정책이 LLM 코드를 금지해 불안했는데 테스트가 예외임을 알았고, 시리즈에서 LLM 보조로 만든 건 테스트뿐이다. 작업 리뷰에는 Sashiko가 도움이 됐다.
systemd 현황: 2026년판
All Systems Go! 2026에서 systemd 메인테이너 Luca Boccassi와 Zbigniew Jędrzejewski-Szmek이 연례 “프로젝트 현황” 세션을 진행했고, 이어 Daan De Meyer, 프로젝트 리더 Lennart Poettering이 함께한 라운드 테이블이 열렸다. 2025년에는 메이저 릴리스 2개(v258·v259)와 포인트 릴리스 40개가 나왔고, 기여자 379명의 커밋 6,160개가 머지됐다(2024년 7,372개보다 감소). 올해는 9월 말까지 이미 480명이 기여했는데, 늘어난 이유는 대부분 LLM 코딩 도구다.
v258은 개발에 9개월이 걸렸고 “모두가 불만”이었다. 그래서 2개월 기능 머지, 1개월 안정화·RC로 분기마다 릴리스하기로 했고, 날짜가 1주 안팎으로 밀리긴 해도 올해 v260·v261·v262 세 번을 냈다. 거버넌스도 문서화했다. 규칙 여섯 개와 메인테이너 목록, 프로젝트 리더(물론 Poettering)뿐인 짧은 문서다. Boccassi는 “스머프 마을처럼 파파 스머프가 있고 나머지가 집단으로 결정하고 PR을 머지한다”고 요약했다.
Jędrzejewski-Szmek은 2016년 이후 GitHub 이슈·PR 그래프를 보여줬다. 열린 이슈가 이미 3,000개로 감당 못 할 수준이고, PR도 2025년 중반까지는 잘 따라갔지만 “AI 혁명” 이후 지수적으로 늘고 있다. 반면 머지 속도는 거의 일정하다. 리뷰하는 사람 수가 그대로이기 때문이라는 게 그의 가설이고, 처리량을 늘리려면 프로세스를 바꾸거나 리뷰어를 늘려야 한다. CI 쪽에서는 ARMv7 테스트와 RISC-V 빌드 테스트(에뮬레이션이 느려 유닛 테스트는 아직)를 추가했고, PR 단위로 Open Build Service(OBS) 패키지를 만들어 비기술 사용자도 수정을 시험해볼 수 있게 했다.
보안: 바운티는 닫고, CNA는 열고
독일 Sovereign Tech Agency(STA)는 2025년 systemd에 약 40만 유로를 지원했다. GNOME과 systemd-homed 통합, systemd OS 설치 도구, 시스템 업데이트 서비스 개선이 대상이다. STA는 YesWeHack 플랫폼의 버그 바운티도 지원했는데, 제출이 너무 많아 트리아지 인력이 감당하지 못해 신규 제출을 닫았다. LLM 보조 버그 찾기 때문이고 결과는 “별로”였다.
| 경로 | 접수 | 결과 |
|---|---|---|
| YesWeHack 바운티 | 183건 | 인정 13건, 무효·중복·범위 외 168건, 검토 중 2건. 지급 총액 21,250유로 |
| GitHub 보안 리포트 | 62건 | 보안 권고 15건 공개. “돈을 안 주니 신호 대 잡음비가 낫다” |
| CNA(6월 지정) | – | CVE 2건 발행, 1건 거절. 하류가 허둥대야 하므로 고심각도만 발행 |
지난 1년의 주요 기능
| 버전 | 기능 | 요점 |
|---|---|---|
| v259~v260 | 런타임 의존성 dlopen() 전환 완료 | 직접 링크하는 건 glibc뿐. 선택 의존성 20여 개는 기능이 실제로 필요할 때만 연다. 풀 기능 빌드 하나로 이미지마다 라이브러리 포함 여부를 정할 수 있고, XZ 백도어처럼 링크가 공격 경로가 되는 것도 줄인다 |
| v259 | run0 --empower | “거의 root지만 UID 0은 아닌” 권한. root 권한으로 실행하되 파일은 사용자 UID/GID로 생성 |
| v259 | 사용자별 systemd-machined | 비특권 사용자가 VM·컨테이너 실행 |
| v260 | varlink 레지스트리, metrics/reports | 시스템의 varlink 서비스 탐색, 서명된 시스템 리포트 추출 |
| v261 | systemd-imds | 클라우드 인스턴스 메타데이터 서비스(IMDS) 지원. “아무도 cloud-init을 안 좋아해서” 만든 대체재 |
| v262 | EnqueueUnitJobMany() | D-Bus·varlink 호출 한 번으로 여러 잡을 하나의 트랜잭션으로 큐잉 |
v262 이전에는 아래 명령이 EnqueueUnitJob() D-Bus 호출 두 번으로 처리돼 경쟁 상태의 여지가 있었다.
# systemctl start a.service b.service라운드 테이블: Kubernetes는 안 하고, 어디까지가 systemd인가
첫 질문은 systemd를 원격 시스템까지 관리하는 Kubernetes 대체재로 키울 생각이 있냐는 것이었다. Poettering은 “systemd는 노드를 관리하지 오케스트레이션하지 않는다”고 선을 그었다. systemd-report로 오케스트레이터가 상태를 파악하게 해줄 수는 있지만 스케줄링은 systemd 몫이 아니다. 임베디드 쪽에서는 버전마다 플래시 사용량이 는다는 지적이 나왔다. Jędrzejewski-Szmek은 코드는 늘지만 systemd보다 큰 의존성을 선택 사항으로 만드는 일은 더 잘하고 있다고 답했다. Poettering은 그래서 systemd에 Rust를 쓰기 어렵다고 했다. Rust 생태계에는 의존성을 동적·선택적으로 두고 우아하게 기능을 줄이는 철학이 없고, 모든 걸 거대한 바이너리 하나로 컴파일하는 경향이 있다는 것이다.
“언제 그만 추가하냐”는 질문에 Boccassi는 “누가 Lennart의 GitHub 계정을 뺏지 않는 한 계속 추가할 것”이라고 받아쳤다. Poettering은 타당한 질문이라며, 기준은 “노드를 계속 돌리는 가장 기본적인 것”이지만 그 기본이 바뀐다고 했다. 10년 전엔 없던 플랫폼 무결성이 이제는 OS 설계의 근본이 됐다는 예를 들었다. 유지보수 인력에 대해서는 Amutable(1월 공동 창업 발표) 일이 우선이라 그 회사에 필요 없는 부분은 덜 챙기게 된다고 인정했고, 특히 SELinux 지원이 “매우 부족하다”고 했다. Boccassi는 AI나 Rust를 정면으로 묻는 사람이 없어 아쉬웠다며 세션을 마쳤다.
out-of-tree 트레이서와의 협업이라는 캐치-22
LTTng를 2005년부터 유지해온 Mathieu Desnoyers가 Linux Plumbers Conference 트레이싱 트랙에서 ftrace·perf 같은 커널 내 트레이서와 협업하려다 막힌 문제를 토론에 부쳤다. 진행자인 ftrace 창시자 Steven Rostedt는 “오늘 가장 논란 없는 주제”라고 소개해 웃음을 샀다. 문제는 세 가지 제약이 맞물려 있다는 것이다.
| 제약 | 출처 |
|---|---|
| 트레이서는 모듈이 아니라 코어 커널에 있어야 한다(ftrace·perf는 모듈로 빌드 불가) | 코어 커널 개발자들의 반복된 입장 |
| “트레이싱 모델이 두 개 필요하면 다른 하나는 트리 밖에 있게 된다.” 공유 인프라로 점진적으로 머지하든지, 아니면 없다 | 2025년 7월 토발즈의 메일 |
| 트리 안에 사용자가 없는 심볼은 export하지 않는다 | 커널 가이드라인(Hellwig가 가장 강하게 주장) |
토발즈 말대로 LTTng 기능을 조각조각 업스트림 트레이서에 넣는 데 성공해도, 그 기능은 export되지 않아 LTTng 모듈이 쓸 수 없다. 보상은 같은 기능을 트리 안팎에서 둘 다 유지하는 부담이다. 한 번에 통째로 넣는 건 토발즈가 분명히 거부했다. 실제 예가 SFrame이다. Desnoyers가 2년간 커널 SFrame 지원을 작업해왔는데, 들어가더라도 심볼이 export되지 않으면 LTTng는 그걸로 스택을 풀(unwind) 수 없다. Desnoyers의 요청은 out-of-tree 트레이서도 쓸 수 있게 EXPORT_SYMBOL_GPL()로 기능을 export하도록 허용해달라는 것이다. 그러면 공유 인프라를 만들고 LTTng 모듈 조각을 점진적으로 업스트림할 수 있다.
Rostedt도 화가 나 있었다. 그는 LTTng 기능 일부를 ftrace에 가져오고 싶지만 “드라코니안” 태도에 막혀 있다며, 그렇다면 “리눅스는 오픈소스 친화적이지도 협업 친화적이지도 않다”고 분명히 말하라고 했다. 커널 트레이싱 생태계 전체가 쓰는 tracepoint를 만든 사람이 Desnoyers다. 그는 5월 LSFMM+BPF에서 Hellwig와 이야기했고 이 세션에도 초대했지만 Hellwig는 오지 않았다. 과거 LTTng 머지 시도가 중복 기능을 이유로 무산됐는데, Rostedt는 export된 심볼만 쓸 수 있으니 ftrace가 직접 쓰는 인프라를 LTTng가 따로 구현할 수밖에 없었다고 짚었다. 20년간 통합이 안 됐으니 앞으로도 안 된다는 토발즈의 논리에 대해서는 코드를 공유할 수 없었던 게 통합이 안 된 이유 중 하나라고 반박했다.
새 인터페이스를 영원히 유지해야 하지 않냐는 우려에 Rostedt는 모듈 인터페이스는 사용자 공간 ABI가 아니라고 답했다. Desnoyers도 LTTng는 수년간 인터페이스 변화에 적응해왔다며 “일부러 방해하지 않고, 기여한 인프라를 쓸 수 있다는 기본 보장”만 원한다고 했다. 쓰임새도 다르다. LTTng는 커널·사용자 공간 상관 트레이싱과 오류 감지 시 스냅샷 내보내기에 초점이 있고, 광통신 라우터 같은 통신 장비에서 상시 실행된다. Brendan Gregg는 개인정보를 다루는 서버에서 SSH 접근이 점점 막혀 그런 기능을 살펴보는 중이라고 했다. Rostedt는 토발즈가 “아무도 트레이싱 기능을 원하지 않는다”고 했다며, 컨퍼런스에 오면 “Open Source Summit의 거의 모든 사람”이 원한다는 걸 알 것이라고 했다. 해결책이 없다면 커널은 스스로 “외부 프로젝트 적대적”이라고 선언해야 한다는 게 그의 결론이다.
[vx]swap 대결
스왑 계층은 지난 1년간 많이 바뀌었지만, 스왑 캐시 슬롯이 영구 스왑 파일의 공간과 직접 묶여 있는 문제는 아직 메인라인에서 풀리지 않았다. zswap이 이 문제를 잘 보여준다. zswap은 스왑으로 나갈 folio를 압축해 RAM에 두는데, 그래도 모든 folio가 실제 스왑 장치의 슬롯을 하나씩 할당받아야 한다. zswap이 넘칠 때만 쓰이는 이 공간은 대부분 낭비되고, 대형 데이터센터에서는 아무것도 저장하지 않을 플래시를 대량으로 잡아둬야 한다. 해법이 두 개 경쟁 중이다.
| 항목 | vswap (Nhat Pham) | xswap (Baoquan He, Chris Li) |
|---|---|---|
| 구조 | 기존 스왑 장치 위에 가상화 계층. 스왑 캐시에 들어온 folio에 가상 슬롯을 주고 물리 스왑 슬롯·zswap·(0 페이지는) 슬롯 없음 중 하나로 매핑 | 백킹 스토어가 없는 가상 스왑 장치. 쓰기는 실패하지만 zswap folio에 “물리” 슬롯을 제공 |
| 슬롯 추적 | xarray | 희소 매핑(VM_SPARSE) 주소 범위. 스왑 사용이 적을 때 메모리를 적게 쓴다 |
| 크기 | 워크로드에 따라 동적으로 증감 | 처음에 주소 공간 전체를 예약해야 해 최대 크기(곧 zswap 최대 저장량)가 고정 |
| zswap → 물리 스왑 writeback | 지원 | 9월 버전엔 없었음. 최신 3부작의 2부에서 구현 |
| 장치 간 이동 | 가상 슬롯을 유지한 채 이동. zswap 비우기·스왑 파일 제거 전 대피가 쉽다 | – |
1년 넘게 vswap을 작업해온 Pham은 9월 초 진행 방법을 묻는 긴 메일을 올렸다. 그는 xswap의 희소 매핑이 xarray보다 매력적일 수 있다고 인정하면서도, xswap은 vswap의 큰 설계가 들어간 뒤 얹을 최적화에 가깝다며 vswap을 먼저 넣자고 했다. xswap 쪽은 당연히 반대였다. “VM_SPARSE 배열은 나중에 붙이는 최적화가 아니라 구조적 선택”이며, vswap을 먼저 넣으면 xarray 구조를 곧 걷어내야 하니 단순한 xswap을 기반으로 먼저 넣는 게 낫다는 것이다. 스왑 현대화 작업 상당수를 해온 Kairui Song도 비슷한 주장을 했다.
긴 논의에서 xswap에 대한 지지는 크지 않았다. writeback 부재가 큰 약점으로 여겨졌고, 가장 논쟁적인 건 크기 고정이었다. Johannes Weiner는 관리자가 스왑 영역 크기를 정하게 하는 것 자체가 잘못이라고 했다. zswap에 얼마나 담길지는 워크로드별 압축 효율에 달려 있어 관리자가 알 수 없고, 커널이 기존 메모리 제한 외에 한도를 더할 이유도 없다. 이어진 논의에서 스왑 제한(장치 크기와 cgroup)이 서로 모순되게 쓰이고 있다는 점도 드러났다. 어떤 곳은 프로세스의 최대 가상 크기를, 어떤 곳은 물리 스왑 사용량을 제어하려 한다. 전자라면 zswap 페이지를 제한에 포함하는 게 맞고 후자라면 아니다. zswap이 물리 슬롯에서 분리되면 어느 쪽을 지원할지 정해야 하고, 누군가는 불만을 품고 돌아갈 것이다.
결론은 나지 않았고 화상 회의 일정도 아직 못 잡았다. 그사이 He는 코어 장치, 물리 writeback, 물리 스왑 사용량 계정을 담은 3부작 xswap을 새로 올렸는데, 지금까지 유일한 반응은 자기 아이디어를 출처 표시 없이 가져갔다는 Pham의 불만이다. 스왑 가상화는 여러 오랜 문제를 푸는 다음 단계지만, 몇 년간 그 결과를 안고 살아야 하는 메모리 관리 개발자들은 서두르지 않을 것이다.
Rust 프로젝트 목표 현황
Rust Foundation 프로그램 매니저이자 목표(goals) 팀 공동 리드인 Tomáš Šedovič가 Kangrejos 2026에서 Rust 프로젝트의 목표 프로세스를 소개했다. 변경을 원하고 방법도 안다면 해당 팀과 바로 하면 된다. 어디서 시작할지 모르는 경우 목표 팀이 제안서를 함께 다듬고, 맞는 사람에게 연결하고, 진행을 추적한다. 기능이든 리팩터링이든 테스트·성능 작업이든 제안이 될 수 있고, 구현할 사람이 있어야 하며, 최근에는 자금이 필요한 제안을 후원자와 연결하기 시작했다. 목표는 1년 안팎의 독립 단위이고, 관련 목표를 묶은 장기 계획이 “로드맵”이다. 2024년 Rust for Linux가 처음 낸 목표는 하나였지만 지금 Rust for Linux 로드맵에는 13개가 있다(Rust 프로젝트 목표 사이트).
| 목표 | 내용·커널에서의 의미 |
|---|---|
| Field projections | 잘 쓰인 목표의 예. 담당자 Benno Lossin, 전용 Zulip 채널, 언어 정의·타입 체커·컴파일러·라이브러리·연산 의미론 팀마다 챔피언. 지금까지는 설계 공간을 그리는 작업 위주 |
| Arbitrary self types | 메서드 receiver를 Box·Rc 같은 내장 스마트 포인터 외에 사용자 정의 스마트 포인터로 확장(Ding Xiang Fei). 락이나 RCU 보호를 받으며 자원에 접근하는 API를 편하게 만든다 |
| In-place initialization | 지금은 힙으로 옮길 구조체도 먼저 스택에 만든다. 스택이 작은 커널에선 오버플로 위험. C++처럼 언어 차원 지원(Alice Ryhl) |
| Immovable types와 guaranteed destructors | “꼼수”에 가까운 Pin 대신, 옵트아웃하면 이동 불가가 되는 Move 자동 트레이트 |
| Const traits, full const generics, supertrait 자동 구현 | 컴파일 타임 트레이트 구현 사용, 제한된 의존 타입, 하위 호환을 지키는 트레이트 계층 변경. 컴파일 타임 특수화 코드 생성은 커널에 두루 유용(Ojeda) |
| 불안정 기능 안정화 | 모든 목표의 출발점. 커널이 안정 언어 기능만으로 빌드되게 하는 것 |
얼마나 걸리겠냐는 Ojeda의 질문에 Šedovič는 확답은 못 하지만 “엄청난 진전”을 봤다고 했다. 고무적인 건 Rust for Linux가 처음 요청한 언어 변경 상당수를 CPython에 Rust를 들이려는 Python 기여자들도 요청하고 있다는 점이다. 거대한 C 프로젝트 둘이 같은 기능을 원하고 자원을 모으고 있으니, 현재 목표들이 실현되면 Rust는 기존 C 프로젝트에 통합되기 좋은 언어가 될 것이라는 게 그의 결론이다.
Rust에서 C 타입 소유하기: Owned와 Ownable
Kangrejos에서 Andreas Hindborg는 C 코드가 할당했지만 다 쓴 뒤 정리(해제와는 다를 수 있다)는 Rust가 책임지는 객체를 위한 Ownable 트레이트 패치 시리즈를 이야기했다. 블록 계층에는 동시 요청을 위한 메모리 풀이 있다. 블록 계층은 풀에서 안 쓰는 bio 구조체를 골라 채워 드라이버에 넘기고, 드라이버는 처리 후 비워서 돌려준다. 요청마다 할당·해제를 반복하지 않는 설계인데, 기존 Rust 추상화와 잘 맞지 않는다.
| 타입 | 소유 방식 | 수명 끝에서 | 이 경우 맞지 않는 이유 |
|---|---|---|---|
KBox | 유일 소유 | 메모리 해제 | Rust 쪽에서 할당했다고 가정 |
ARef | 참조 카운트 공유 | 카운트 감소 | I/O 요청이 항상 참조 카운트되는 건 아님 |
Owned(제안) | 유일 소유 | 타입의 release() 호출(예: 서브시스템 풀에 반환) | – |
까다로운 건 기존 추상화와의 상호작용이다. 참조 카운트가 1인 ARef는 Owned로, Owned는 자신을 소비하며 ARef로 바꿀 수 있어야 자연스럽다. 그런데 Owned에서 내장 참조를 얻을 수 있고, 참조 카운트 타입의 내장 참조는 ARef로 승격할 수 있다(참조가 있다면 카운트가 최소 1이므로). 이 둘을 합치면 Owned로 참조를 만들고 → 그걸 ARef로 승격한 뒤 → Owned로 계속 수정하는 동시 수정이 가능해져 건전성(soundness)이 깨진다. 참조 승격을 유지하길 강하게 원하는 사용자들이 있어, Hindborg는 AlwaysRefCounted를 “ARef에 넣을 수 있음”과 “내장 참조를 ARef로 승격 가능” 두 트레이트로 나누고 후자와 Ownable의 동시 구현을 금지하자는 타협안을 냈다.
그의 블록 계층 Rust 바인딩에서 I/O 요청은 블록 계층 소유, 드라이버 소유, 드라이버 내 공유, 드라이버가 보관(parked) 네 상태를 갖는다. 블록 계층은 드라이버에 Owned를 넘기고, 요청을 끝내려면 그걸 돌려받아야 하므로 드라이버가 내부에 참조를 남기지 않았음을 보장할 수 있다. 목표는 올바르게만 쓸 수 있는 인터페이스다. IOMMU 페이지 테이블, Rust binder, USB 드라이버도 쓸 수 있을 것으로 보인다. page 래퍼에 Ownable을 구현하는 건 어렵다. Rust binder가 vm_insert_page()에 넘기려고 내장 참조를 ARef로 승격하는 데다, Ryhl 말대로 페이지 참조 카운트를 올리는 건 일반적으로 허용되는 일이기 때문이다. Kent Overstreet는 splice()와 folio 전환 때문에 페이지 참조 카운트가 특히 민감하다고 했고, Boqun Feng은 메모리 관리 메인테이너들이 새 사용자에게 page 대신 folio를 쓰게 하려 한다며 이는 Rust 쪽만의 문제가 아니라 그들과 논의할 API 문제라고 짚었다.
시리즈는 2025년 초부터 이어져 22번째 버전이고, 요청이 바뀔 때마다 구현이 제자리를 돌았다. Hindborg는 합의만 이뤄지길 바란다며 “제발 함께 해봅시다”라고 했다. Ojeda가 리뷰 맞교환을 제안하자 그는 즉시 “저 얼마든지 팔립니다”라고 답했다.
두 살이 된 KDE Linux
KDE Linux는 KDE의 두 번째 자체 배포판 시도로, 2024년 Akademy에서 Harald Sitter가 “Project Banana”로 처음 소개했고 2025년 첫 알파가 나왔다. Akademy 2026에서 Nate Graham과 Sitter가 근황을 전했다. Ubuntu 기반 KDE neon은 빌드는 나오지만 2025년 10월 이후 블로그 업데이트가 없고 Ubuntu 26.04 대응 여부도 불분명하다. 또 다른 배포판을 만드는 이유로 Graham은 중간자 없는 사용자와의 직접 관계, 패치 없는 “바닐라 Plasma” 경험, 스택 전체 통합 테스트(Flatpak 개선이 다른 프로젝트에도 돌아감), 특정 후원사 배포판을 편들지 않고 추천할 수 있다는 점을 들었다. 다른 배포판을 대체하려는 건 아니다.
| 사용자 반응 | 내용 |
|---|---|
| 좋았던 점 | OS 롤백(“모든 배포판에 넣어달라”), 패키지 충돌이 없는 이미지 기반 업데이트, 8월 추가된 홈 디렉터리 Btrfs 스냅샷(아직 “몇 가지 버릇”이 있음), 백업 도구 Kup, Flatpak을 겁 없이 설치·삭제, 앱·애드온·OS 업데이트를 한곳에서 다루는 Discover |
| 불만 | 패키지 매니저 부재(CLI 도구·빌드 의존성이 필요한 개발자가 떠남), VirtualBox처럼 out-of-tree 커널 모듈이 필요한 앱의 Flatpak화 불가(Sitter가 프로토타입 작업 중), Flatpak 샌드박스 권한·호스트 통합·테마 문제. 패키지 매니저라는 탈출구를 주기보다 Flatpak 쪽 문제를 고치겠다는 입장 |
| 예상보다 문제 아니었던 것 | 프린터(“사람들은 인쇄를 별로 안 한다”), 구형 NVIDIA 독점 드라이버(Nouveau로 충분), zram 스왑(“게을러서” 택했지만 괜찮았다. 언젠가 zswap으로, GNOME OS는 9월에 zswap 전환) |
구조는 Arch Linux 패키지 기반 이미지에 kde-builder로 KDE 소프트웨어를 얹는다. 루트는 스냅샷이 켜진 Btrfs이고, /usr는 속도와 압축의 균형 때문에 고른 읽기 전용 EROFS다. 롤백용으로 /usr 이미지를 4개 보관하는데, 기자의 테스트 시스템 기준 이미지 하나가 약 7.2GB라 합치면 30GB 가까이 된다(성숙하면 개수를 줄일 예정). 이미지는 mkosi로 만들고 UKI의 initrd도 mkosi로 만든다. systemd-repart, systemd-sysupdate 등 “거대한 systemd 서비스 스택”을 쓰고, 델타 업데이트에는 casync 대체 구현 desync를 쓴다.
앞으로는 Arch 대신 Yocto와 비슷한 Apache BuildStream(GNOME OS가 사용)으로 베이스를 직접 조립하는 방안을 검토 중이다. 베이스 완전 통제, “Arch 같을 것”이라는 오해 방지, Arm·RISC-V 빌드, CVE 리포트와 SBOM 생성이 이유다. 다만 기사는 그렇게 되면 지금 Arch에서 물려받는 보안 업데이트 작업을 어떻게 할지는 언급되지 않았다고 지적한다. 아직 알파지만 Graham은 롤백이 있어 주력으로 쓴다고 했고, GitLab 마일스톤 기준 베타까지 85%다. “80-20 법칙은 진짜라 마지막 20%가 10년 걸린다”며 일정은 약속하지 않았다. 질의응답에서는 Flatpak으로 배포되는 KDE PIM과 Plasma의 통합 문제가 나왔고, Kevin Ottens는 이미 개선 작업이 진행 중이라고 했다. 모바일 지원은 계획은 없지만 염두에 둔 목표다.
짧은 소식
- Let’s Encrypt 64일 인증서 — 2027년 2월 10일부터 발급·갱신하는 인증서의 유효기간이 64일이 된다. 마지막 90일 인증서는 2027년 5월 11일 만료될 예정이며 유효한 인증서를 폐기하지는 않는다. CA/Browser Forum 기본 요구사항에 따른 2025년 계획의 두 번째 단계이고, 2028년에는 45일로 줄어든다.
- Nix·Lix 로컬 root 권한 상승 취약점 — 두 프로젝트가 데몬을 통해 root로 권한을 올릴 수 있는 취약점을 공동 공개했다. “신뢰할 수 없는 derivation을 빌드하는 모든 시스템”이 영향을 받으며 수정 릴리스가 나왔다.
- 커널 7.3-rc7 — 10월 12일 릴리스. 토발즈는 “더 작은 rc였으면 했지만 최종 릴리스를 미룰 이유는 없다”며 다음 주말 정식 릴리스를 예고했다. ext4
data=journal모드가 폐기 예정(deprecated)으로 표시됐고 2028년 초 완전히 제거된다. 지금까지 개발자 2,987명(첫 기여자 795명)의 머지 제외 체인지셋 18,533건이 들어갔고, rc2 이후 주당 커밋은 681 → 733 → 598 → 649 → 596 → 447건이다. 10월 11일 7.2.10과 6.18.56 안정 업데이트가 나왔다. - 토발즈의 첫 LLM 보조 패치 시리즈 — 서밋에서 말한 시리즈를 실제로 올렸다. 패치 10개로, 자주 쓰이는 folio의 해제를 RCU 유예 기간 뒤로 미루고, folio 조회뿐 아니라 데이터 접근까지 RCU 아래서 해 페이지 폴트가 없는 사용자 복사 fast path에서는 참조 카운트를 아예 잡지 않는다.
read()위주 벤치마크에서 약 10배(order of magnitude) 속도 향상이 나왔지만, 리뷰에서 이미 경쟁 상태가 발견돼 추가 작업이 필요하다. - Asterinas 0.19.0 — Rust로 새 OS 커널을 만드는 프로젝트. X.org를 돌릴 수 있는 그래픽 서브시스템, “최소한이지만 쓸 만한” arm64 지원, 가상화 지원 개선이 들어갔다.
- LineageOS 24 — 6월 나온 Android 17 기반. 지난 몇 버전간 Google의 대규모 리팩터링에 적응해둔 덕에 예년보다 빨리 리베이스했다. 12월 24일이면 프로젝트 10주년이다.
- KDE Plasma 6.8 — Matthias Ettrich의 KDE 발표 메일 30주년에 맞춰 나왔다. 접근성 개선, Kup 백업 도구 기본 포함, Spectacle 화면 녹화에 시스템 오디오·마이크 입력 포함이 들어갔고, 예고대로 Plasma X11 세션 지원을 끊었다. X11 앱은 XWayland로 계속 돌고, KDE 앱은 “당분간” X11을 지원한다.
- PostgreSQL 19 기능 대량 revert — 코어 팀 Peter Eisentraut는 베타 이후 이례적으로 많은 기능이 빠진 이유로 LLM 보조 코드 리뷰를 꼽았다. 예전 같으면 5년에 걸쳐 조금씩 고쳤을 엣지 케이스 40여 건이 한꺼번에 나오고, 건당 세 줄짜리 수정이라도 고정 비용이 있어 시간이 모자랐다. 문제의 기능 대부분은 LLM 리뷰가 지금만큼 유용하기 전에 쓰였으니 “바이브 코딩” 탓이 아니라는 것이다. 이번 주 보안 인용문에서 Christophe Pettus는 다른 메커니즘을 제시했다. revert 수 자체는 예년과 비슷한데 시점이 기능 동결 직후(300일 무렵)가 아니라 430일(9월 초)에 몰렸다. 올해 PostgreSQL CVE는 44건(작년 약 5건)이고 8월 PG18 업데이트에만 28건이 있었는데, 보안 리포트를 분류하는 사람과 안정화 기간에 커밋된 기능을 사후 리뷰하는 사람이 같은 20여 명이다. 7~8월을 보안 리포트에 쓰니 SQL/PGQ 설계 문제가 4월이 아닌 9월에 발견됐다는 것이다.
- Python 3.15 — 내장 타입
sentinel과frozendict추가, UTF-8 기본 인코딩, 패키지 시작 설정 파일, 실험적 JIT 컴파일러 개선이 들어갔다.
배포판 쪽 인용문으로는 Richard Fontana가 Fedora의 라이선스 정책이 다른 배포판에 미치는 영향은 제한적이고 줄어들었다며, 주요 배포판이 함께 이런 문제를 다루면 좋겠지만 새로운 정치적 역학 없이는 현실적이지 않다고 했다.
행사는 10월 13~15일 프라하 OpenSSL Conference, 14~17일 케이프타운 PyCon South Africa, 16~18일 로마 VideoLAN Developers’ Days, 18~20일 All Things Open, 20~23일 The Matrix Conference(말뫼)와 PostgreSQL Conference Europe(발렌시아)가 이어진다. 10월 30일~11월 1일 베를린 Qubes OS Summit, 11월 3~4일 Open vSwitch and OVN 가을 컨퍼런스, 6~7일 Texas Linux Festival, 12~13일 온라인 Ubuntu Summit 26.10이 있고, 11월 28일에는 서울에서 FOSS for All Conference 2026이 열린다. CFP 마감은 Yocto Project Virtual Summit 2026.12가 10월 26일, Southern California Linux Expo가 11월 1일, AlpOSS 2027이 11월 2일이다.
이번 주 핵심 요약
- 메인테이너 서밋의 방향 전환은 분명하다. 지난 몇 년간 커널은 기여를 쉽게 만드는 데 공을 들였는데, 이제는 “새 기여자는 후순위, LLM을 쓰려면 제대로 쓸 자원을 갖춰라”로 바뀌었다. 커널에 패치를 보낼 생각이라면 실용적인 결론은 이렇다. 체인지로그는 직접 쓰고, 사람 리뷰 전에 Sashiko 지적만 반영한 새 버전을 연달아 보내지 말고, 리뷰 질문에는 사람의 언어로 답한다. 이제 그게 LLM 슬롭과 구별되는 신호다.
Assisted-by폐지는 “숨기라”는 뜻이 아니라 체인지로그 대신 커버 레터에 쓰라는 뜻이다. 어떤 모델을 어느 단계에서 썼고 사람이 무엇을 검증했는지는 여전히 메인테이너가 궁금해한다. 토발즈의 첫 LLM 보조 시리즈에서도 리뷰가 경쟁 상태를 잡았다. 6개월 들여 도구를 길들인 사람의 결과물도 사람 리뷰가 필요하다는 증거다.- GCC 세션에서 가져갈 만한 건 “LLM이 쓴 코드는 버리고 결과만 쓴다”는 활용 패턴이다. 두 가지 최적화 위치를 LLM에게 둘 다 구현시켜 수치만 보고, 방향이 정해지면 직접 다시 쓴다. 저작권이나 품질 문제로 LLM 코드를 받기 어려운 프로젝트에서도 바로 쓸 수 있다. Law의 Thunderbird 플러그인이 결국 Sashiko를 재발명하게 된 이야기는 쓸 만한 LLM 리뷰가 결국 구체적 지침과 단계 분리로 수렴한다는 걸 보여준다.
- GCC가
-fsanitize=kcfi를 갖게 되면 커널 KCFI가 더 이상 Clang 전용이 아니게 된다. 배포판이 GCC로 빌드한 커널에도 forward-edge CFI를 켤 수 있는 길이 열리는 것이다. 타입 ID도 Clang과 같은 맹글링 방식으로 만들도록 맞췄다. 리뷰가 끝나 머지되는 시점을 지켜볼 만하다. - systemd의
dlopen()전환은 임베디드·컨테이너 이미지를 만드는 사람에게 실질적이다. 풀 기능 빌드 하나를 두고 이미지마다 라이브러리를 빼서 크기를 줄일 수 있다. cloud-init을 쓰는 환경이라면systemd-imds를, 여러 유닛을 한 번에 다루는 스크립트라면 v262의 단일 트랜잭션 큐잉을 확인해볼 만하다. 바운티 183건 중 13건이라는 숫자는 지난주 Kroah-Hartman의 79건 분석과 같은 이야기다. - LTTng 문제는 “트리 안에 사용자가 없으면 export하지 않는다”는 규칙이 GPL 프로젝트에도 예외 없이 적용될 때 생기는 비용을 보여준다. 커널 모듈 API는 안정 ABI가 아니라는 원칙과 함께 기억해 둘 만하다. out-of-tree 모듈을 유지하고 있다면 업스트림에 기능을 넣어도 자기 모듈은 그걸 쓸 수 없을 수 있다는 점을 계획에 넣어야 한다.
- zswap을 쓰면서 그만큼 실제 스왑 공간을 잡아두고 있다면 vswap/xswap 논의가 바로 그 낭비에 대한 것이다. 당장 들어올 기미는 없다. 정작 결정을 늦추는 건 “스왑 제한이 가상 크기 제한이냐 물리 스왑 제한이냐”라는 운영 측 정의 문제다. cgroup
memory.swap.max를 어떤 의도로 쓰고 있는지 미리 정리해두면 나중에 동작이 바뀔 때 대응하기 쉽다. - Rust 쪽 두 기사는 같은 방향을 가리킨다. in-place 초기화, arbitrary self types,
Move트레이트는 결국 C와 맞닿은 코드에서 소유권 모델을 덜 억지스럽게 만드는 작업이고,Owned/Ownable은 그걸 지금 언어로 구현하려다 건전성 경계에 부딪힌 사례다. 풀에서 객체를 빌려주고 돌려받는 C API를 Rust로 감쌀 일이 있다면 “참조 → 참조 카운트 승격”이 유일 소유와 공존할 수 없다는 점을 기억해 둘 만하다. - KDE Linux의 EROFS
/usr+ Btrfs +systemd-sysupdate+ mkosi 조합은 이미지 기반 데스크톱의 전형이 되어 가고 있다. 사용자가 가장 아쉬워한 건 패키지 매니저였고 가장 반긴 건 롤백이었다. 불변(immutable) 배포판을 설계한다면 이 두 가지가 무게중심이다.