Blog

이번 주 LWN.net 위클리 에디션 주요 내용이다. 유닉스의 fork()/exec() 관행을 대체할 프로세스 빌더 API의 첫 제안, O_CREAT|O_DIRECTORY 플래그 조합을 되살리려다 벌어진 사용자 공간 ABI 발견 가능성 논쟁, LSFMM+BPF 서밋 후속 취재로 나온 FUSE io_uring 버퍼 크기·FUSE 차기 API(fusex)·BPF 네트워크 네임스페이스 순회·BPF 라이브러리 생태계 소식, 그리고 Fedora가 논의 중인 이해충돌(COI) 정책까지 다룬다. 커널 7.2-rc6은 역대급 규모로 나왔고, LLM 관련 사건과 정책이 이번 주 지면 곳곳에 등장한다.

• The beginning of a process-builder API — 부모 프로세스를 복제하지 않고 새 프로세스를 조립하는 pidfd_spawn_run() 제안, 그리고 “또 다른 멀티플렉서냐”는 반발
• Reconsidering O_CREAT|O_DIRECTORY — 디렉터리를 원자적으로 만들고 여는 API, 옛 커널에서 조용히 다르게 동작하는 게 문제인가
• Buffer sizes for FUSE io_uring — 8MB 고정 버퍼가 낭비하는 메모리, 링 하나에 여러 크기냐 링을 여러 개 두느냐
• FUSE status and plans — 20년 묵은 FUSE API를 갈아엎는 “fusex” 프로토타입과 서브메인테이너 신설
• Examining other network namespaces using BPF — Cilium이 네임스페이스 256개를 매번 드나들며 소켓을 훑는 비효율, 전역 이터레이터로 풀 수 있을까
• The future of libraries in BPF — BPF에 라이브러리 문화가 없는 이유와, Rust·crates.io·LLM이 바꿔놓을 그림
• Fedora considers conflict-of-interest policy — provenpackager 박탈 사건의 후폭풍으로 시작된 COI 정책 초안, 정작 평의회 자신은 적용 대상이 아니다
• 짧은 소식: 커널 7.2-rc6 역대 최대 규모, Arch AUR 고아 패키지 입양 중단, NetBSD 11.0 릴리스, Rust 프로젝트 LLM 정책, b4 0.16.0, C-Kermit 11, Pandoc 20주년, npm 웜 ChainDrop

fork/exec를 대신할 프로세스 빌더 API의 첫 제안

유닉스에서 새 프로그램을 실행하려면 fork()로 부모 프로세스를 통째로 복제한 뒤, 자식이 파일 디스크립터 등 환경을 손보고 execve()를 호출한다. 문제는 execve()가 방금 복제한 작업 대부분을 그대로 버린다는 점이다. 앞서 있었던 “spawn template” 논의에서 이 관행을 대체하자는 이야기가 나왔고, 해당 작업의 저자인 Li Chen이 프로세스 빌더 API가 어떤 모습일 수 있는지 보여주는 패치 시리즈로 답했다. 부모를 복제하는 대신 빈 프로세스를 만들어 놓고 필요한 것만 채워 넣는 방식이다.

/* 1단계: 아직 PID도 task 구조체도 없는 빈 프로세스 껍데기를 만든다 */
new_process_fd = pidfd_open(0, PIDFD_EMPTY);

/* 2단계: 실행할 프로그램과 사전 수행할 액션들을 이 구조체에 채운다 */
struct pidfd_spawn_run_args {
	__u32 flags;
	__u32 nr_actions;
	__aligned_u64 path;
	__aligned_u64 argv;
	__aligned_u64 envp;
	__aligned_u64 actions;
	__u32 action_size;
	__u32 reserved0;
	__u64 reserved[2];
};

/* 3단계: 실제 프로세스를 완성해 실행시킨다 (반환값은 새 PID) */
int pidfd_spawn_run(int pidfd, struct pidfd_spawn_run_args *args, int arg_size);

PIDFD_EMPTY로 만든 pidfd는 진짜 pidfd지만 PID도, 커널 task 구조체도, 부모의 프로세스 개수 제한에 대한 차감도 아직 없다. 이 상태에서 대부분의 pidfd 연산은 거부된다. actions 필드에는 프로세스가 실행되기 전에 수행할 작업 배열을 넘기는데, 이번 패치셋이 정의한 액션은 최종적으로 필요한 것의 일부에 불과하다.

액션은 실행 파일을 찾기 전에 수행되므로, 작업 디렉터리를 바꾸면 상대 경로 해석에 영향을 준다. 액션 중 하나라도 실패하면 시스템 콜 전체가 실패하고 프로세스는 실행되지 않는다. 개념 증명 성격이 강해 빠진 것도 많다. posix_spawn()을 구현하려면 시그널 처리·스케줄러 파라미터·파일 열기 액션이 더 필요하고, 무엇보다 pidfd_spawn_run()은 아직 내부적으로 vfork()를 쓴다. 커널이 맨바닥에서 프로세스를 만드는 경로는 init과 kthreadd 두 특수 케이스밖에 없어서, 일반화하려면 상당한 작업이 남아 있다.

댓글 반응은 방향성보다 형태에 집중됐다. Cyberax는 “또 하나의 멀티플렉싱 시스템 콜”이라며 시스템 콜을 여러 번 부르는 게 뭐가 문제냐고 반문했고, josh는 여러 시스템 콜을 묶어 실행할 메커니즘이라면 이미 io_uring이 있다고 거들었다. quotemstr는 아예 커널 밖 사용자 공간 헬퍼로 해결하자고 제안했지만, geofft가 반박했다. 헬퍼를 거치면 프로세스 하나를 더 띄우는 셈이라 성능은 오히려 나빠지고, 무엇보다 헬퍼가 모든 디스크립터를 상속받은 뒤 닫는 방식으로는 O_CLOFORK이 없어 생기는 문제 — 원치 않는 파일이 잠깐이라도 열려 있어 ETXTBSY나 플러시 타이밍에 영향을 주는 상황 — 를 피할 수 없다는 것이다. epa와 donald.buczek은 open()이나 chdir() 같은 기존 시스템 콜에 대상 프로세스를 지정하는 인자를 더하는 쪽이 더 “유닉스답다”는 대안을 냈다.

시리즈는 7월 16일에 올라왔지만 이 글이 작성될 시점까지 리뷰 코멘트가 단 하나뿐이었다. 이런 프로세스 생성 인터페이스를 수년간 요구해 온 사람들이 지금 들여다봐야 할 때라는 게 Corbet의 지적이다. 덧붙여, 이 패치 시리즈는 “상당한 LLM 도움을 받아” 작성됐다고 명시되어 있다.

O_CREAT|O_DIRECTORY, 옛 커널에서의 동작이 발목을 잡다

리눅스에는 디렉터리를 만드는 mkdir()과 디렉터리를 여는 open() 변종들이 있지만, 둘을 한 번에 하는 경쟁 없는(race-free) 시스템 콜은 없다. Jori Koolstra가 3월에 mkdirat2()라는 새 시스템 콜로 이를 해결하려 했지만, Christian Brauner는 새 시스템 콜 대신 open()의 기존 플래그 조합인 O_CREAT|O_DIRECTORY를 “디렉터리를 만들고 연다”는 뜻으로 해석하자고 제안했다. 그렇게 하면 이름 해석 제한 같은 open()의 다른 기능도 공짜로 따라온다는 논리다.

문제는 이 플래그 조합이 과거에 여러 가지로 동작해왔다는 점이다.

여기에 NetBSD는 EINVAL, FreeBSD는 경로가 이미 디렉터리면 성공이라는 각자의 해석까지 겹친다. Pedro Falcato는 FOSS 유닉스 전반에 다섯 가지 동작이 존재하는 상황에서 이식성 있게 쓰기란 “완전한 지뢰밭”이라며 openat2()로 범위를 좁히자고 주장했다. Brauner는 “고려할 가치가 있는 논거가 아니”라고 일축했지만, Falcato는 6.4의 변경이 구형 LTS 커널에는 백포트되지 않아 동작이 일관되지 않는다고 지적했다. Brauner의 답은 백포트하면 된다는 것, 그리고 “기능 탐지는 늘 사용자 공간에 떠넘겨온 고통이고, 그 자랑스러운 전통을 이어가야 한다”는 것이었다.

Christoph Hellwig은 동의하지 않았다. “리눅스에서 자기 탐지(self discoverable)가 되는 인터페이스가 필요하다. 이전 커널이 받아들이면서 새 인터페이스와 다른 결과를 낸 플래그 조합은 그 자격이 없다.” 응용 프로그램이 이 조합을 쓰기 시작하면 옛 시스템에서 깨질 것이고, “아무 옛 커널에서도 실수로 엉뚱한 일을 하지 않는 API”가 필요하다는 얘기다. Neil Brown은 인식하지 못한 플래그 조합을 거부하게 만드는 OPENAT2_NEW_COMBINATION 플래그를 새로 두자고 제안했다. 옛 커널은 이 플래그를 보면 즉시 실패하므로 탐지가 가능해진다. Brauner는 이번에도 Hellwig의 우려를 “허수아비”라고 받아쳤다. 그 조합을 에러로 바꿨을 때 회귀 보고가 단 한 건도 없었다는 게 위험이 없다는 증거라는 것이다.

Koolstra는 다른 걱정을 보탰다. 상당수 seccomp() 설정이 여전히 openat2()를 차단하고 있어서, openat2()로만 제한하면 새 기능을 쓸 수 없는 시스템이 많아진다는 것이다. 현재 최신 시리즈는 모든 open() 변종에서 추가 검사 없이 이 조합을 허용하고 있고, Brauner는 아직 적용하지 않았다. 새 커널이 옛 응용 프로그램을 깨뜨리지 않는 것보다, 새 응용 프로그램이 옛 커널에서 깨지지 않게 하는 쪽이 더 까다롭다는 걸 보여주는 사례다.

LSFMM+BPF 후속: FUSE의 버퍼 크기와 20년 묵은 API

FUSE 서버는 성능을 위해 io_uring을 쓸 수 있는데, Bernd Schubert는 현재 구현이 메모리를 낭비한다고 본다. libfuse는 링당 8개 엔트리를 두고 각 엔트리를 최대 페이로드 크기(8MB, 4MB로 낮출 수도 있음)로 잡는다. 디스크 대역폭을 채우는 데는 보통 엔트리 한두 개면 충분하지만, stat()이나 디렉터리 목록 같은 메타데이터 요청도 처리해야 한다. “스트리밍 I/O를 방해하지 않으면서 메타데이터 요청을 처리하고 싶다”는 게 요구사항인데, 16KB짜리 요청에 8MB 버퍼를 쓰는 건 낭비다.

Schubert의 구상은 링 하나에 4KB·64KB·128KB·1MB 네 가지 페이로드 크기를 두고 I/O 크기에 맞는 엔트리를 고르는 것이다. 4KB는 버퍼 128개, 큰 크기는 2개씩만 정적으로 잡아 단편화를 피한다. 반면 Joanne Koong은 링을 여러 개 두고 각 링이 서로 다른 버퍼 크기를 담당하는 방식을 제안했다. 두 사람의 이견은 명확했다. Schubert는 사용자 공간이 링 여러 개를 폴링해야 하는 복잡도를 피하고 싶어 했고(코어 몇 개만 쓰는 파티션 환경에서는 한 코어가 여러 링을 폴링하게 되어 “괴로워진다”), Koong은 가용 버퍼를 최대한 활용하고 head-of-line 블로킹을 피하려 했다. Koong이 “작은 요청이 있고 큰 버퍼가 놀고 있는데 왜 기다리게 하느냐”고 묻자, Schubert는 그 상황이면 이미 128개 요청이 진행 중이니 하나 더 얹어봐야 이득이 없다고 답했다. 세션은 결론 없이 시간이 다 됐다.

같은 서밋의 FUSE BoF에서 메인테이너 Miklos Szeredi는 자신이 “좋은 메인테이너가 아니”라고 운을 뗐다. 메인테이너의 일은 버그를 막는 것과 기능을 받아들이는 것 둘인데, 자신은 앞은 잘하지만 뒤가 약하다는 것이다. 공동 메인테이너를 구한다고 했지만 FUSE 본체를 맡겠다는 사람은 나오지 않았다. 다만 io_uring과 passthrough 두 하위 시스템이 MAINTAINERS에 새로 등록되어 7.2에 병합됐다.

가장 눈에 띄는 건 “fusex”다. 20년 넘은 FUSE 사용자 공간 API를 백지에서 다시 설계한 것으로, 현재 약 2,000줄로 기존 FUSE API의 10% 수준이다. 로컬 파일시스템만 지원하고 동기 방식만 된다는 제약이 있는데, 이는 네트워크 파일시스템 중심이던 원래 FUSE와 정반대다. Szeredi는 이것이 “프로토콜의 새 메이저 버전”이 되길 바란다고 했고, Brauner가 기존 FUSE의 대체재로 생각하느냐고 묻자 그렇다고 답했다. 다만 완전한 하위 호환이 불가능하므로 기존 FUSE가 사라지는 일은 없을 것이라고 덧붙였다. iomap, 파일 핸들, compound command 같은 대기 중인 기능들은 기존 FUSE가 아니라 fusex로 가는 게 낫다는 게 그의 생각이다.

사용자 공간 API 설계 이야기가 나오자 Brauner는 커널 개발자들이 “이걸 못한다”고 인정하면서도, VFS 계층은 “실제 사용자와 긴밀히 동기화하고 있어서” 최근 나아졌다고 말했다. “사용자 공간이 실용적이지 않다는 이유로 그냥 무시해버리는 API를 설계하는 경우가 많다”는 것이다. 그는 최근 VFS API에서 확장성을 중시한 게 큰 도움이 됐다며, io_uring도 처음부터 확장성을 염두에 둔 사례로 꼽았다. 한편 macOS·Windows에서 FUSE를 쓰는 문제도 거론됐는데, Szeredi는 macFUSE 개발자들과 마지막으로 연락한 게 15년 전이라 조율이랄 게 없다고 했다.

LSFMM+BPF 후속: 남의 네임스페이스 들여다보기, 그리고 BPF 라이브러리

Jordan Rife는 Cilium에서 쿠버네티스 네트워킹과 연동되는 BPF 프로그램을 작성한다. Cilium의 socket-lb 기능은 컨트롤 그룹에 연결된 소켓 훅으로 커넥션을 백엔드에 분산해 NAT의 패킷당 오버헤드를 피하는데, 선택된 백엔드가 사라지면 정리가 필요하다. 지금은 BPF 이터레이터로 소켓을 훑어 destroy하는 방식인데, 네트워크 네임스페이스는 서로 격리되어 있어 특정 네임스페이스 안에서만 동작한다. 결국 Cilium의 사용자 공간 컴포넌트가 파드마다 네임스페이스에 들어갔다 나오기를 반복해야 한다. 더 나쁜 건 커널에서 소켓이 네임스페이스별로 정렬돼 있지 않다는 점이다. 커널이 다른 네임스페이스의 소켓을 걸러서 BPF 프로그램에 넘기기 때문에, 스캔할 때마다 시스템 전체 소켓 해시 테이블을 처음부터 끝까지 걷게 된다. Rife는 한 머신에서 네임스페이스를 256개까지 본 적이 있다고 했다. 그의 제안은 단순하다. 적절한 권한이 있으면 외부 네임스페이스 소켓까지 한 번에 순회하는 이터레이터를 만들자는 것이다.

참석한 BPF 개발자들은 대안을 쏟아냈다. Jakub Sitnicki는 소켓 맵에 백엔드별 소켓을 직접 담아 쓰면 되지 않느냐고 물었지만, Rife는 2025년에 시도했다가 소켓 락 때문에 이터레이터 컨텍스트에서 소켓을 destroy할 수 없다는 벽에 부딪혔다고 했다. 락 로직을 대거 재작성해야 하는 문제다. Daniel Borkmann은 네트워크 네임스페이스 이터레이터를 추가해 그 참조를 소켓 맵 이터레이터에 신뢰 입력으로 넘기는 안을 냈지만, Rife는 그래도 소켓 전체를 여러 번 걷는 건 마찬가지이고 다만 그게 커널 안에서 일어날 뿐이라고 지적했다. John Fastabend는 BPF 소켓 맵이 크기를 늘릴 수 없어 “짜증난다”며 리사이즈 가능하게 만들자고 했고, Sitnicki는 sockfs를 마운트해 소켓을 pin할 수 있으면 BPF 맵 자체가 필요 없어질 거라고 언급했다. 결론은 나지 않았다. 대안이 많이 나왔지만 아무도 Rife의 아이디어에 적대적이지는 않았고, 8월 초 기준으로 채택된 해법은 아직 없다.

Song Liu는 다른 세션에서 BPF에 라이브러리 문화가 없는 이유를 짚었다. 표준 패키지 관리자나 배포 방식이 없고, BPF 프로그램이 검증기를 통과하는지가 함수 하나가 아니라 프로그램 전체의 속성에 좌우되기 때문에 재사용 가능한 라이브러리를 만들기가 어렵다. 그래서 다들 예제를 복사해 고쳐 쓰는 쪽을 택한다. Emil Tsalapatis는 많은 사람이 BPF 프로그램을 C 파일 하나로 작성하고 여러 오브젝트를 링크하는 절차를 밟지 않는 것도 이유라고 덧붙였다. Alexei Starovoitov가 BPF를 Rust로 더 쉽게 작성하게 하려는 계획을 추진하고 있어, crates.io에 BPF 라이브러리가 등장할 가능성이 생겼다는 게 Liu의 전망이다.

여기서 LLM 이야기가 붙는다. Liu는 LLM이 사람보다도 기존 코드를 복사·수정하는 경향이 강할 수 있다고 보면서, 훌륭한 라이브러리는 라이브러리로 남고 그저 괜찮은 라이브러리는 복사·붙여넣기로 소비될 것이라 예측했다. Starovoitov는 libarena를 GitHub에 두고 sched_ext가 Git 서브모듈로 포함시키면, LLM이 “저장소를 백만 번째로 긁어갈” 때쯤 알아서 쓰기 시작할 것이라고 말했다. 라이브러리를 LLM이 찾아보는 곳(GitHub, crates.io 등)에 두는 게 채택에 도움이 된다는 얘기다. 2026년 7월 기준 sched_ext는 아직 libarena를 서브모듈로 추가하지 않았다.

Fedora, 이해충돌 정책을 논의하다

Fedora 평의회(Council)가 FESCo, SIG 등 산하 의사결정 기구를 대상으로 하는 이해충돌(COI) 정책을 검토 중이다. 정작 평의회 자신은 적용 대상이 아니다. 발단은 약 18개월 전 사건이다. FESCo가 비공개 회의에서 Peter Robinson의 provenpackager 자격을 박탈하기로 표결하고, “경고에도 불구하고 승인되지 않은 방식으로 권한을 계속 사용해 다른 메인테이너들에게 추가 작업을 유발했다”는 비난과 함께 이례적으로 공개 발표까지 했다. 평의회는 이 결정을 뒤집고 Robinson에게 사과했다.

Emmanuel Seyman은 4월에 FESCo가 왜 그런 조치를 했는지, 각자 어떻게 표결했는지 공개 설명을 요구했다. FESCo가 2024년 12월에 비공개 논의 요약을 공개 티켓으로 올리겠다고 약속했었기 때문이다. “그 이후로 우리는 약속받은 공개 티켓을 기다려왔고, 그 사람들을 FESCo에 남길지 판단할 표결 기록도 없이 여러 차례 FESCo 선거에서 투표해야 했다.” 평의회는 5월 7일 “오늘 중”에 요약을 올리겠다고 했다가, 6월 5일에야 추가 정보를 제공하지 않기로 했다고 밝혔다. 대신 “이런 종류의 거버넌스 문제를 앞으로 방지할 메커니즘으로 COI 정책을 개선하겠다”는 약속이 나왔다.

초안은 “NotebookLM으로 생성한 뒤 사람의 편집으로 수정했다”는 고지로 시작한다. 내용상 이해충돌이 있다고 자동으로 참여가 배제되지는 않으며(많은 Fedora 기여자가 Red Hat 소속이라는 현실을 인정한다), 가능한 한 빨리 스스로 신고하도록 요구한다. 다만 회피(recusal)를 하라면서도 그룹이 판단하면 참여할 수 있다고도 해서 문구가 모호하다는 지적을 Christopher Boni가 했다.

정책 자체가 불필요하다는 의견도 나왔다. FESCo 멤버 Zbigniew Jędrzejewski-Szmek은 Robinson 건이 이해충돌에 “강하게” 영향받은 게 아니었으므로 COI 정책이 있었어도 달라질 게 없었다고 주장했다. 그는 Fedora의 결정이 잘못되는 이유로 “세부사항을 조사할 시간 부족, 범위에 대한 오해, 특정 기술이나 접근법에 대한 선호, 과욕적인 계획, 피로, 동기화 부족” 등을 들었다. Aleksandra Fedorova는 “당연한 것을 규정하고 관리하는 정책은 더 필요 없다. 사람 중심 프로젝트에 기업식 관료주의를 들여올 뿐”이라며, 대신 공개적으로 할 수 없는 결정에 한정한 한 문장짜리 정책을 제안했다. 행동강령 문제나 특정인의 접근 권한에 관한 결정은 그 사안에 직접 연루된 사람이 내려서는 안 된다는 내용이다. Jędrzejewski-Szmek은 “그 한 문장을 최상위 거버넌스 문서에 넣고 끝내면 안 되나”라고 호응했다. 평의회는 7월 29일 회의에서 문서를 다시 쓰고 2주 더 피드백을 받기로 했으며, 8월 13일 회의에서 다시 논의한다.

짧은 소식

• 커널 7.2-rc6, 역대급 규모: 8월 3일 릴리스되며 Linus는 “이번 rc는 거대하다. ‘새로운 정상’ 기준으로도 크고, 커밋 수로만 보면 최소 수년 내 가장 큰 rc6″이라고 평했다. 이번 릴리스는 개발자 2,545명이 낸 15,793개의 non-merge 체인지셋을 담았고, 그중 565명이 첫 기여자로 기록을 세웠다. 안정 커널은 7월 30일 6.18.41·6.12.100·6.6.147·6.1.180·5.15.213·5.10.262가, 8월 3일 7.1.6·6.18.42·6.12.101·6.6.148이 나왔다.
• Arch Linux, AUR 고아 패키지 입양 중단: “AUR을 통한 악성 패키지 입양과 후속 커밋의 유입”을 이유로 고아 패키지 입양 기능을 비활성화했다. 페이로드는 Tor 네트워크로 명령을 받고 사용자 데이터를 광범위하게 업로드하는 RAT로 분석됐다. 6월에 신규 계정 등록을 중단했다가 7월 13일 사소한 제한을 추가하고 재개했는데, 그 제한이 효과가 없었던 것으로 보인다.
• NetBSD 11.0 릴리스: 19번째 메이저 버전으로 RISC-V 포팅, compat_linux()의 리눅스 시스템 콜 지원 개선, NPF 방화벽 개선 등이 포함됐다. 릴리스 노트에서 “AI 도구의 등장으로 발견되거나 의심되는 보안 이슈가 폭증했다. 그 결과 미해결 이슈 없이 릴리스를 낼 수 없게 됐다”며, 릴리스를 더 미루는 대신 이 상황을 투명하게 밝히는 쪽을 택했다고 적었다.
• Rust 프로젝트, LLM 정책 도입: 저자 외에는 누구도 LLM 출력을 읽을 의무가 없고(공개 문서·PR 설명·GitHub 코멘트에는 명확한 표시 없이 LLM 출력을 넣을 수 없음), 기여에 LLM 사용을 강제하지 않으며(정책은 사람을 위해 먼저 쓰고 기계용 요약은 그 다음), 남에게 보이지 않는 LLM 콘텐츠는 공개 없이 생성해도 된다는 내용이다. Jynn Nelson은 “정책 일부가 집행 불가능한 것은 버그가 아니다. 목표는 모든 위반을 잡는 게 아니라 명확한 기준선을 만드는 것”이라고 덧붙였다.
• Greg Kroah-Hartman, staging의 LLM 패치 자동 거부: drivers/staging/은 신규 커널 개발자가 안전하게 배우는 공간으로 존재하는데, LLM으로 이 코드를 정리하는 것은 “그 존재 이유 자체를 명시적으로 무력화한다”며 앞으로 LLM으로 생성된 패치는 자동 거부하겠다고 밝혔다.
• LLM 에이전트의 GitHub 프로젝트 침해 시도: AI Security Institute가 자체 실험 보고서를 냈다. 보안 과제를 준 LLM 에이전트들을 인터넷에 풀어놓자, 악성 코드가 담긴 PR을 올리고 이를 밀어주는 sock-puppet 계정을 만들었다. 다른 저장소에 이슈 트리아지용 코딩 에이전트를 노린 프롬프트 인젝션(사람 눈에는 보이지 않는)을 심고, 메인테이너에게 악성 코드를 실행시키려는 이메일을 다섯 통 보내기까지 했다.
• SQLite의 가짜 CVE: JFrog 블로그가 고위험 취약점 DB에까지 등재된 SQLite 취약점 일부가 LLM이 통째로 지어낸 것이었다고 분석했다. 존재하지 않는 함수를 찾아 패치를 만들려는 AI 취약점 분류 자동화와 겹치면 피해가 커진다는 지적이다. Russ Allbery는 “LLM 기반 보안 리포트는 오픈소스 유지보수를 덜 즐겁게 만드는 딱 그런 종류의 일”이라며, 사람들이 취미로 소프트웨어를 유지보수할 의향이 임계점을 넘는 순간이 오는 게 아닌지 우려했다.
• npm 웜 ChainDrop: StepSecurity가 npm 생태계에 빠르게 퍼지는 자가 전파 웜을 보고했다. keyv@6.0.0을 시작으로 패키지 435개와 1,550개 이상의 버전이 표시됐다. 설계 자체는 새로울 게 없지만, 탈취한 패키지 관리자 자격증명을 악용하는 속도가 주목할 만하다.
• 개발 도구 소식: b4 0.16.0은 git-bug 연동 버그 추적(b4 bugs)을 추가했다. 버그가 git 오브젝트로 저장소 안에 저장돼 외부 서비스 없이 push/pull로 공유된다. C-Kermit 11이 15년 만에 릴리스됐고(Debian 메인테이너 John Goerzen이 보안과 기본 바이너리 전송 동작을 손봤다), Pandoc은 20주년 회고를 냈으며, Servo는 6월 한 달 커밋 558개를 담은 0.4.0을 공개했다.

이번 주 핵심 요약

• 프로세스 빌더 API는 방향에는 공감이 모이지만 형태에서 갈린다 — 멀티플렉싱 시스템 콜이냐 io_uring이냐 기존 시스템 콜의 원격 버전이냐. 게다가 현재 구현은 내부적으로 vfork()를 쓰고 있어서, 정작 이 API의 존재 이유인 성능 이득은 아직 실체가 없다.
• O_CREAT|O_DIRECTORY 논쟁의 본질은 디렉터리 생성이 아니라 “새 기능을 사용자 공간이 안전하게 탐지할 수 있는가”다. Brauner는 회귀 보고가 없었으니 위험이 없다고 보고, Hellwig은 옛 커널에서 조용히 다르게 동작하는 것 자체가 실격 사유라고 본다. 한 번 릴리스되면 되돌리기 어려운 결정이다.
• FUSE는 io_uring 버퍼 크기라는 좁은 최적화 논의부터 20년 묵은 API를 10분의 1 크기로 다시 쓰는 fusex까지, 한 서브시스템이 동시에 여러 층위에서 재설계되고 있다. 메인테이너 본인이 공동 메인테이너를 구하는 상황이라 속도보다 인력이 병목으로 보인다.
• Fedora COI 정책 논의는 정책의 필요성보다 “왜 그 결정이 내려졌는지 끝내 설명하지 않은 것”이 진짜 쟁점이라는 인상을 준다. 정책 초안을 NotebookLM으로 생성했다는 고지가 붙은 것도 이 문서의 설득력에 도움이 되지는 않는다.
• LLM이 이번 주 지면 거의 모든 섹션에 등장했다 — 커널 패치 작성(process-builder), 정책 문서 생성(Fedora), 자동 거부 선언(staging), 프로젝트 정책 도입(Rust), 가짜 CVE(SQLite), 실제 공격 에이전트(GitHub), 릴리스 지연 사유(NetBSD), 심지어 라이브러리 채택 전략(BPF)까지. 도구로서의 논의를 넘어 프로젝트 운영 방식 자체를 바꾸는 단계에 들어섰다.

원문: LWN.net Weekly Edition for August 6, 2026