Blog

이번 주 LWN.net 위클리 에디션(10월 1일자) 주요 내용이다. Kernel Recipes 2026에서 PostgreSQL 성능 작업을 오래 해온 Andres Freund가 커널 쪽에 바라는 것과 막히는 지점을 정리했고, 같은 콘퍼런스에서 Martin Uecker는 C의 미정의 동작(undefined behavior)을 줄여 메모리 안전 언어로 갈 수 있는지를 짚었다. RustConf에서는 GPU를 특별 취급하지 않고 그냥 Rust의 컴파일 타깃으로 만들겠다는 구상과, 3만 원짜리 동글로 항공기 트랜스폰더까지 디코딩하는 SDR 취미 발표가 나왔다. 여기에 X11 지원을 걷어내는 Plasma 6.8, KDE가 공적 자금 130만 유로를 따낸 과정, 구글과 Igalia에서 같은 Chromium을 개발해본 비교까지 다룬다.

• The kernel from a PostgreSQL point of view — PostgreSQL이 커널에서 겪는 병목과 두 프로젝트가 협력할 지점
• Reducing undefined behavior in the C language — 미정의 동작 100개 중 45개를 걷어낸 C2y, 그리고 메모리 안전의 세 갈래
• Native support for Rust on the GPU — GPU를 평범한 컴파일 타깃으로 만들어 일반 Rust 코드를 그대로 돌리는 구상
• Listening to the radio with Rust — $30 RTL-SDR 동글과 Rust로 AM·FM·항공기 트랜스폰더 디코딩
• The year in Plasma and what’s ahead — 머지 리퀘스트 7,903건, 그리고 6.8에서 사라지는 X11
• How KDE got funding to add enterprise features — Sovereign Tech Agency 투자 130만 유로를 따내기까지의 과정과 쓰임새
• Comparing Chromium development at Google and Igalia — 같은 저장소, 같은 도구, 전혀 다른 조직에서 일해본 경험
• 짧은 소식: 파일 알림(inotify) 기반 키스트로크 타이밍·클릭재킹 연구, 커널 7.3-rc5, Git 2.56 정식 릴리스, Firefox 157, GDB 18.1, F-Droid 2.0

PostgreSQL이 보는 커널

Andres Freund는 PostgreSQL 성능 개선에 여러 해를 쏟은 사람이고, 그 작업은 리눅스 커널의 많은 기능과 동작을 상대하거나 우회하는 일이다. Kernel Recipes 2026에서 그는 커널 프로젝트와 일해온 경험, 커널이 PostgreSQL 같은 애플리케이션을 더 잘 받쳐줄 방법, PostgreSQL 쪽 최근 변화를 이야기했다.

시작은 “재미있었던” 경험 목록이다. 2018년에 커널이 I/O 에러에 반응해 데이터를 조용히 잃을 수 있다는 사실이 드러난 사건(“fsyncgate”), 최근에는 멀티프로세스 애플리케이션을 깨뜨린 io_uring 문제들이 있었다. 다만 io_uring 메인테이너 Jens Axboe와는 생산적인 협력 관계라 많은 문제가 해결됐다는 점을 짚었다. 커널 변경에서 비롯된 버그와 크래시, 원인을 추적해야 하는 무작위 성능 변화가 꾸준히 들어온다.

왜 커널 개발자와 상대하는 PostgreSQL 사람이 더 없냐는 질문에 그는 몇 가지 이유를 들었다. 다수가 리눅스를 잘 몰라 질문할 자격이 없다고 느끼고, 커널의 소통 방식이 위협적으로 보인다(나아졌지만 욕을 먹는다는 생각은 여전히 싫다). 문제를 제기하면 커널 개발자들이 서로 모순되는 말을 하는 경우도 많아 누구 의견을 무시해도 되는지 아는 것이 중요하다. 커널을 따라가는 일 자체가 어렵다는 점도 있다. 그는 b4 도구를 이번 콘퍼런스에 와서야 처음 들었다고 했다.

PostgreSQL 쪽 변화 중 커널 개발자가 관심 가질 만한 것들이 있다.

커널에서 “훌륭한 일”도 많이 일어나고 있다. 라이트백과 reclaim이 2~4배 수준으로 좋아졌고, atomic write를 요청하는 RWF_ATOMIC 추가는 큰 개선이며 io_uring도 여러 면에서 좋다. 그리고 문제 목록이 이어진다.

마무리에서 그는 PostgreSQL 개발자와 커널 개발자를 동시에 고용한 회사가 여럿인데 왜 그 커널 개발자들이 PostgreSQL 문제를 더 돕지 않는지 자연스레 의문이 든다고 했다. 자기 회사에서는 PostgreSQL 그룹이 따로 떨어져 있어 회사의 나머지와 교류가 적고, 그래서 다른 자원을 끌어오는 데 영향력이 없다. 다른 회사도 비슷할 것으로 본다.

반대로 PostgreSQL이 커널을 도울 길도 있다. 데이터베이스가 만나는 문제 중 다수는 PostgreSQL에만 해당하지 않으므로 해결하면 많은 사용자가 이득을 본다. PostgreSQL 개발자들이 하는 테스트(그리고 더 할 수 있는 테스트)는 릴리스 전에 회귀를 잡아내는 데 쓸 수 있다. 실제 성능 문제를 더 잘 드러내는 벤치마크를 찾는 일도 함께할 수 있다. 둘 다 오래된 오픈소스 프로젝트이니 공통점이 많고, 더 가까이 일해서 얻을 것도 많다는 것이다.

C의 미정의 동작을 줄이기

생체의학 공학 교수인 Martin Uecker는 Kernel Recipes의 전형적인 발표자상은 아니지만, 오래된 리눅스 사용자이고 MRI 스캐너를 제어하는 자유 소프트웨어를 만든다. 그가 다룬 주제는 C 언어, 특히 미정의 동작 문제, 그리고 C를 메모리 안전 언어로 만들 수 있는지였다.

2026년에 왜 C인가. 여전히 훌륭한 언어라는 게 그의 답이다. 이식성이 있고 장기적으로 안정적이며 컴파일이 빠르고 나온 바이너리도 빠르다. “보이는 것이 얻는 것(What you see is what you get)”이어서 C 코드를 보면 컴퓨터가 실제로 뭘 할지 짐작할 수 있다. 도구가 많고, 필요할 때 언어가 비켜준다.

대신 긴 역사가 오늘의 언어 모습을 결정했다. C89 표준은 부호-크기(signed-magnitude)나 1의 보수 정수 표현, 세그먼트 메모리, 이상한 포인터 표현, 놀라운 타입 크기를 가진 하드웨어까지 상대해야 했다. 예를 들어 어떤 Honeywell 머신은 9비트 바이트를 썼다. 그래서 택한 방식이 언어 의미를 추상 기계(abstract machine)로 정의하는 것이다. 모든 연산은 실제 하드웨어와 정확히 일치하지 않을 수 있는 그 추상 기계에서 실행된 것처럼 수행되어야 하고, 프로그램의 관측 가능한(observable) 동작은 추상 기계가 했을 것과 같아야 한다. “관측 가능”이 핵심이다. 관측 가능으로 정의된 volatile 변수 접근은 추상 기계대로 정확히 일어나야 하지만, 나머지는 최종 결과만 같으면 된다.

문제는 표준이 미정의 동작에 대해 컴파일러가 무엇이든 해도 된다고 허용한다는 점이다. 컴파일러 작성자들의 입장은 프로그램에 미정의 동작이 조금이라도 있으면 그 프로그램에는 기대할 의미가 없다는 것이다. C++23 표준은 그런 프로그램에 아무 요구도 하지 않는다고 명시까지 한다. 그 결과 언어에서 무엇을 기대할 수 있는지를 두고 개발자들 사이에 광범위한 불일치가 생겼다. 구조체 전체를 memset()으로 0으로 밀고 특정 필드만 쓴 뒤 패딩 바이트를 읽으면 무엇이 나오는가 — 2015년 설문에서 이에 대한 합의는 없었다.

발표에서 든 구체적인 예 세 가지가 차이를 잘 보여준다.

extern int x;

int f(int a, int b)
{
    x = b ? 42 : 43;
    return a/b;
}

b가 0이면 return은 0으로 나누기이므로 미정의 동작이다. 그러면 컴파일러가 조건 검사를 아예 빼고 x = 42만 실행해도 되는가. b = 0 경우에 기대할 의미가 없으니 무시해도 되고, 그 경우 x에 대한 저장은 관측 가능한 동작이 아니다. 실제로 그렇게 하는 컴파일러가 있다.

extern void g(int x);

int f(int a, int b)
{
    g(b ? 42 : 43);
    return a/b;
}

같은 상황처럼 보여서 검사를 제거하고 g()에 42를 넘긴 컴파일러들이 있었지만, 이건 컴파일러 버그다. g()가 b가 0일 때 exit()를 호출하는 구현이라면 나누기는 일어나지 않고 프로그램 동작은 미정의가 아니다.

volatile int x;

int foo(int a, int b, bool store_to_x)
{
    if (! store_to_x)
        return a/b;
    x = b;
    return a/b;
}

여기서는 컴파일러가 마지막 나누기를 x 대입 위로 끌어올려도 되는지가 쟁점이다. b = 0에 의미가 없다면 관측 가능한 동작은 바뀌지 않는다. 실제로 그렇게 한 컴파일러가 있었고, C23 표준은 이를 금지하는 “시간 여행 금지(no time travel)” 조항을 넣었다. C++에서는 std::observable_checkpoint() 호출을 끼워 넣어 명시적으로 막아야 한다.

시간 여행 버그는 결국 사라질 것이지만, 표준이 명확한데도 컴파일러 작성자들이 종종 다르게 보는 경우가 많이 남아 있다. 초기화되지 않은 변수 읽기(거의 항상 정의되어 있다), 포인터 동등 비교(항상 정의되어 있지만 Clang과 GCC 모두 잘못 컴파일한다)가 그 예다.

대응은 진행 중이다. C 위원회는 메모리 객체 모델, 메모리 안전, 미정의 동작을 각각 다루는 연구 그룹 세 개를 운영한다. 현재 C 표준에는 미정의 동작 사례가 약 100개 있는데, 작업 중인 C2y 초안은 그중 45개를 제거했다. 컴파일러 경고, 정적 분석기, 새니타이저, LLM 기반 도구, 형식 검증 등 문제를 찾는 도구도 늘고 있다. 정수 오버플로와 use-after-free 가능성에 대한 경고가 좋아졌고, 정적 분석은 컴파일러 안으로 들어오는 추세다(GCC는 여러 버퍼 오버플로 상황을 경고할 수 있다). 새니타이저는 런타임 검사를 삽입해 많은 미정의 동작을 잡고, 트래핑 모드로는 하드닝에도 쓸 수 있다.

메모리 안전은 C의 강점이었던 적이 없지만 개선할 수 있다는 것이 그의 주장이고, 문제를 세 갈래로 쪼갰다.

이 도구와 언어 변경으로 완전한 메모리 안전까지 갈 수 있을까. 문제를 완전히 풀려면 비싼 런타임 검사나 형식 검증이 필요하고, 가까운 미래에 가장 완전한 결과는 제한된 언어와 형식 검증 도구의 조합에서 나올 것이라고 그는 봤다. 결론은 C가 여전히 살아 있고 나아지는 중이라는 것이다. C23은 K&R 구식 함수 정의, 부호-크기와 1의 보수 머신 지원, 트라이그래프 같은 문제적 기능을 제거하고 비트 정밀 정수 타입과 검사되는 정수 연산을 추가했다. C2y는 case 범위, 이름 있는 for 루프, 배열 길이를 구하는 _Countof() 매크로와 많은 “악마 제거(demon removal)”를 더 가져온다. 완전한 메모리 안전에 이르지는 못하지만 결국 가능한 일이고, 시간이 가면 더 실용적이 될 것이라는 전망이다.

GPU를 Rust의 평범한 컴파일 타깃으로

Christian Legnitto는 Rust에서 GPU를 프로그래밍할 수 있게 하는 rust-gpu와 Rust CUDA의 메인테이너다. 그런데 그는 Rust의 현재 GPU 지원 상태에 만족하지 않는다. RustConf 2026 발표에서 그는 특별한 라이브러리나 새 생태계 지원 없이 GPU가 평범한 Rust 코드의 컴파일 타깃이 되는 그림을 설명했다.

기존 라이브러리들의 문제는 접근 순서라는 게 그의 진단이다. GPU의 기능을 먼저 보고 그것을 Rust로 표현하려 들기 때문에, GPU와 Rust의 기대가 어긋나는 지점에서 마찰이 생기고, 더 나쁘게는 생태계가 쪼개진다. 한 라이브러리로 쓴 프로젝트는 보통 다른 라이브러리로 쓴 프로젝트와 호환되지 않는다. 현재 Rust용 GPU 라이브러리들은 암묵적으로 “GPU는 이상하니까 특별 취급이 필요하다”고 가정하는 것 같은데, Legnitto는 그렇게 보지 않는다. “CPU도 정말 이상하다, 우리가 익숙해진 것일 뿐이다.”

그래서 그는 GPU 우선이 아니라 Rust 우선 설계를 택했다. 비효율을 감수하더라도 Rust의 고유 의미(semantics)를 무슨 수를 쓰든 보존하는 것이 목표다. Rust는 이미 여러 CPU 아키텍처를 지원하며 가능한 곳은 비용 없는 추상화로, 아닌 곳은 옵트인 탈출구와 타깃별 컴파일, 인라인 어셈블리로 처리한다. 표준 라이브러리는 여러 면에서 같은 기본 개념의 서로 호환되지 않는 구현들을 가린 외벽이다. GPU도 같은 방식으로 다루면 된다 — GPU가 합리적으로 지원할 수 있는 것은 GPU에서 하고, 파일시스템 접근 같은 나머지 연산은 호스트 CPU로 디스패치한다. 표준 라이브러리가 CPU에서 커널로 넘기는 것과 구조가 같고, 핵심은 애플리케이션 코드가 그걸 알 필요도 신경 쓸 필요도 없다는 점이다.

생각이 더 필요한 부분은 동시성 프리미티브다. GPU를 쓰는 이유 자체가 하드웨어가 더 높은 수준의 병렬성을 지원하는 것인데, Legnitto는 GPU의 병렬성이 Rust 코드의 프로세스·스레드·SIMD에 잘 대응된다고 봤다.

이 방식으로 쓴 코드는 스레드를 띄우고 SIMD 인트린직으로 네 쌍의 숫자를 한 번에 더하는 예제처럼 생긴다.

fn example() {
    let handle = thread::spawn(|| {
        let a = i32x4::from_array([10, 20, 30, 40]);
        let b = i32x4::from_array([1, 2, 3, 4]);
        let result = a + b;
        println!("SIMD Result: {:?}", result.to_array());
    });

    handle.join().unwrap();
}

같은 코드가 CPU에서도 수정 없이 돌아간다는 것이 요점이다. 이론상 지금 방식보다 느리지도 않아서, 여러 스레드를 띄워 모두 SIMD를 쓰는 Rust 프로그램은 직접 작성한 CUDA 코드와 동등한 성능을 내야 한다. 실익은 “평범한 Rust 것들”이 그냥 동작한다는 데 있다. 기존 라이브러리와 언어 기능을 그대로 쓰고, 의미 있는 곳에 스레딩과 SIMD를 점진적으로 도입해 성능을 올릴 수 있으며 그 개선은 CPU 사용자에게도 이득이다. 정말 성능이 중요한 구간은 여전히 인라인 어셈블리로 GPU용 코드를 직접 쓸 수 있다. 그의 말로는 모든 Rust 프로그래머가 새로 배울 것 없이 하룻밤에 GPU 프로그래머가 되는 것이고, 제안이 받아들여지면 Rust가 세계 최대의 GPU 생태계가 된다.

단점도 인정했다. 어떤 하드웨어에서는 Rust 모델과 맞지 않는 더 나은 GPU 프로그램 구조가 있을 수 있고, CPU용으로 쓴 라이브러리가 동작하면 더 나은 GPU 전용 라이브러리를 쓸 동기가 꺾일 수 있다. 컴파일된 바이너리 크기도 문제다. 대개 GPU 코드는 Rust 애플리케이션 전체에 비해 짧고 단순한데, Rust 애플리케이션은 이 문제를 곧바로 만나게 된다(그는 GPU 코드가 해마다 복잡해지고 있으니 결국 모든 GPU가 더 큰 프로그램을 다뤄야 할 것으로 봤다). 질문 시간에 CPU에 최적화된 컴파일러가 정말 쓸 만한 GPU 코드를 내놓는지 묻는 질문에는, GPU 코드의 자동 벡터화가 아직 “꽤 거칠다”고 인정하면서 LLVM을 이렇게 쓰는 것이 처음이니 당연하다고 답했다.

GPU 때문에 생긴 아이디어가 다른 데서도 유용할 수 있다는 점도 짚었다. 배열의 겹치지 않는 여러 부분을 참조하는 “disjoint slice” 타입이나 텐서·행렬 곱 표준 라이브러리 지원은 GPU와 CPU 양쪽에서 유용하다. “GPU에서 유용하다는 게 GPU 전용이라는 뜻은 아니다.”

Rust로 라디오 듣기

Thomas Eckert는 RustConf 2026에서 비교적 싼 하드웨어 동글과 Rust로 무선 전파를 디코딩하는 취미를 발표했다. AM·FM 라디오 청취와 항공기 트랜스폰더 디코딩을 시연했고, 슬라이드와 예제 코드는 GitHub에 올려뒀다.

안테나는 전체 스펙트럼을 한꺼번에 받지만 안테나마다 민감한 대역이 다르다. 단순 선형 안테나라면 이상적인 길이는 파장의 1/4이다. 그가 잠깐 맞춰본 몬트리올 FM 방송국은 파장이 약 3미터여서 이상적인 안테나 길이가 77센티미터였고, 연단의 접이식 안테나를 정확히 그 길이로 뽑아둔 상태였다. 항공기 트랜스폰더(1090MHz)는 약 5센티미터로 떨어져서, 그 안테나는 옥상에 두고 라즈베리파이로 데이터를 중계했다.

그가 쓴 동글은 $30짜리 RTL-SDR Blog V3다. 안테나에서 유도된 전류를 샘플링해 아날로그 파형을 디지털 데이터로 바꾸고, 한 번에 스펙트럼의 비교적 좁은 구간에 초점을 맞추는 튜닝 회로가 들어 있다. 나오는 데이터는 숫자 쌍의 스트림으로, 서로 직각인 두 성분(코사인 = in-phase, 사인 = quadrature)이다. 동글은 이를 부호 없는 바이트의 연속 스트림으로 주고, 코드가 중심을 맞추고 스케일해 -1에서 +1 사이 부동소수점으로 바꾼다. 둘을 복소수로 합치면 I/Q 신호가 되는데, 원점으로부터의 거리가 진폭이고 연속된 샘플이 원점을 도는 속도가 주파수다. 동글의 칩은 원래 TV 수신기용이라 신호를 그대로 디지털화할 뿐 AM/FM 검출 회로가 없다. 디코딩은 전부 코드에서 한다.

Rust를 택한 이유는 실시간 제약이다. 동글이 초당 100만 샘플 이상을 주니 샘플 하나당 분석에 쓸 시간이 1마이크로초이고, 사운드 카드는 새 값이 왔든 안 왔든 링 버퍼에서 계속 재생한다. 몇 밀리초만 멈춰도 출력에 들리는 구멍이 생기므로, 성능이 좋고 예측 가능한 언어가 필요하다.

ADS-B 쪽은 샘플링 한계가 아슬아슬하다. 동글의 최대 샘플링 주파수인 2.4MHz에서 half-slot 하나가 1.2샘플 폭이라 제대로 디코딩할 수 있는 경계선에 걸린다. 그의 코드는 프리앰블과 맞는 구간을 찾고, 각 비트의 두 반쪽을 샘플해 서로 빼서 신호의 상수 바이어스를 제거한 뒤, 나온 비트를 여러 메시지 종류를 담은 Rust 구조체로 파싱한다. 그 구조화된 데이터를 작은 웹 애플리케이션으로 보내 항공기의 식별자·위치·속도를 지도에 찍는다. 첫 구현은 신호에 있는 정보의 1/6 정도만 찾아냈고, 간섭과 샘플링 오차에 견디는 구현을 만드는 데 고민이 꽤 들었다고 한다. 그는 이것이 좋은 취미인 이유로 스펙트럼을 쓰는 것이 너무 많아 늘 새로 볼 게 있다는 점을 들었다. 아날로그 신호의 기본 디코딩은 큰 노력 없이 되고, 더 나은 디코딩 방법이나 새로운 신호 종류로 얼마든지 깊이 들어갈 수 있다. 기상 정보와 기상도, 편파 변조 디지털 신호, 햄 라디오 등이 남아 있다.

Plasma의 지난 1년과 다음

2007년부터 KDE에 기여해온 Marco Martin이 Akademy 2026에서 Plasma 6.4(2025년 6월)부터 10월 중순 KDE 30주년에 맞춰 나올 6.8까지, 대략 네 번의 포인트 릴리스를 정리했다. 먼저 “지루한 숫자”부터다.

다만 Martin은 “순전히 LLM이 생성한 머지 리퀘스트가 늘고 있다”고 경고했다. 설명과 코드가 전부 LLM 생성이고 제출자가 패치가 뭘 하는지 모르는 것이 분명한 경우다. “아직 그렇게 많지는 않다”면서도, 메인테이너가 기댈 수 있고 기여 희망자에게 가리킬 수 있는 명시적 AI 정책이 필요하다고 했다. Nate Graham이 그런 정책 작업을 시작했으나 온라인 비판의 표적이 된 뒤 중단된 것으로 보이고, 누가 다시 이어갈지는 불확실하다.

기능 쪽에서 그가 “완전히 임의로” 고른 변화들이다.

X11 제거가 구체적으로 무엇을 쉽게 만들었냐는 질문에 Martin은 Plasma 패널을 들었다. “위치 지정, 자동 숨김 같은 것을 X11과 Wayland에서 관리하는 코드 경로가 완전히 둘로 나뉘어 있었다.” 같은 기능의 구현이 두 개여서 코드가 “전혀 우아하지 않았고”, 다중 모니터와 화면 설정 변경 처리도 경로가 달라 복잡했다. “Wayland 쪽에서만 재현 가능한 깔끔한 자동 테스트를 만들 수 있었다. X11 쪽은 좀 YOLO였다. 그 코드가 전부 죽었고 나는 아주 기쁘다.” 사용자가 겪는 가장 큰 불편을 묻는 질문에는 Plasma와 Dolphin 같은 주요 애플리케이션의 기본값은 좋지만, 설정에 들어가 기본값을 바꾸려 하면 “복잡함이 한꺼번에 쏟아진다”는 점을 들었다. 다중 화면 설정도 아직 “완벽하지는 않다”.

KDE가 기업용 기능 개발 자금을 따낸 방법

독일의 Sovereign Tech Agency(STA)가 2027년까지 KDE에 130만 유로에 가까운 금액을 투자한다. Akademy 2026에서 Nate Graham과 Kevin Ottens가 이 투자를 어떻게 받아냈는지, 비슷한 기관에 어떻게 접근해야 하는지, 그 돈이 KDE를 어떻게 개선하게 되는지를 설명했다. Graham은 KDE 전문 개발 컨설팅 Techpaladin Software의 공동 소유자이자 CEO이고, Ottens는 개발 에이전시 enioka Haute Couture의 테크 리드이자 파트너다.

Graham은 이것이 최근 몇 년 사이 최대 규모 외부 투자 중 하나라면서도 “필수적인 것”은 아니라고 했다. “여기 있는 우리 모두 몇 년씩 훌륭한 KDE 작업을 해왔다. 외부 투자의 목적은 우리가 하는 일을 가능하게 만드는 게 아니라 가속하는 것이다.” 출발은 Harald Sitter가 만든 KDE Linux 프로젝트였고, 야심 찬 목표를 실현하려면 외부 투자가 더 필요하다는 판단이었다. Ottens 쪽은 사정이 달랐다. 고객 요청은 주로 Plasma, Frameworks, 오피스 애플리케이션에 몰리고 KDE PIM(KMail·KOrganizer 등 Kontact 묶음) 관련 요청은 거의 없었는데, 정작 회사 사람들이 KDE PIM을 좋아했다. “한때 인기가 있었지만 사람들이 포기하고 Thunderbird로 가는 걸 보고 있다.” NLnet 재단 그랜트로 간을 봤지만 되지 않았고, STA 제안서를 준비하던 중 KDE e.V. 이사회와의 논의에서 “더 큰 게 끓고 있다”는 걸 알게 돼 e.V.와 Techpaladin과 힘을 합쳤다.

Graham이 강조한 것은 사회적 관계다. 독일에 있는 STA는 KDE가 이미 평판 좋은 기관으로 자리 잡은 곳이라 KDE를 알고 있었고, “우리가 훌륭한 일을 하고 친절하고 우호적이어서” 좋아했다. 2025년 Akademy에 STA 사람들을 초청한 것이 자금 논의의 출발점이 됐다. 그다음은 각도를 찾는 일이었다. KDE Linux와 KDE PIM 양쪽에 돈이 가게 하려면, 운영체제와 생산성 소프트웨어에 가장 관심이 많은 쪽인 큰 기관을 노려야 했다. “요즘 애들은 대부분 휴대폰에서 Gmail을 쓰지만, 기업은 이 두 가지 모두에 신경 쓴다.” 그래서 제안서의 비전은 기업이 MDM으로 프로비저닝한 이미지 기반 KDE Linux 노트북을 직원에게 배포하고, 직원이 첫 부팅에서 이메일과 비밀번호만 넣으면 메일·캘린더·기본 애플리케이션이 자동 설정되는 그림이 됐다.

Graham의 표현으로 정말 어려운 부분은 그다음이다.

하고 싶은 일에 대한 비전을 갖는 건 쉽지만, 그것을 실행 가능한 단계와 구체적인 프로젝트, 작업 패키지로 쪼개는 건 아주 어려울 수 있다. 그래서 시간이 오래 걸렸다. 전부 그럴듯해 보이고 목표가 달성 가능해 보이도록 구조를 잡아야 했다.

산정 과정은 Ottens가 설명했다. 비전을 글머리 목록으로 표현하면 그것이 작업 패키지가 되고, 작업 패키지를 태스크로 쪼개 소요 시간을 평가한다. “견적을 낼 때가 보통 우리 개발자들이 비명을 지르며 방을 뛰쳐나가는 지점”이지만 삼점 추정(three-point estimate) 같은 기법이 도움이 된다. 그는 태스크별로 최선·최악·가장 그럴듯한 시나리오를 잡아 구현 비용을 뽑는다. 예를 들어 KDE PIM의 기본 CalDAV 지원 테스트를 만드는 일은 가장 그럴듯한 경우 5일, 아주 잘되면 3일, 문제가 생기면 7일로 계산한다. 이 작업에는 “가벼운 조사”가 필요하다. “실제 구현 작업을 할 필요는 없지만 분석에는 들어가야 한다.” 가정을 반박해줄 다른 사람과 함께 분석하고, 남의 견적에서 날림의 패턴(예상치를 내고 최선은 절반, 최악은 세 배로 곱하는 식)을 찾는다. STA가 이 정도 견적을 전부 요구하는 것은 아니지만 비용 추정은 요구하고, 제공하는 제안서 템플릿은 그가 겪어본 중 “가장 친절한 편”이다.

게이트키핑이 아니다. 그들은 당신이 성공하길 원하고, Sovereign Tech Agency 직원들은 가능한 한 실제로 도와준다. 우리끼리 구석에서 뭘 하고 그걸 그들에게 정당화하는 느낌이 아니었다. 정말 그 제안서를 함께 작업하는 느낌이었다.

참여 주체가 여럿이어도 투자는 단일 주체인 KDE e.V.에 지급된다. e.V.가 행정 지원과 작업 검토, 일부 엔지니어링 지원을 맡고, 작업이 끝나면 STA에 청구해 enioka·Techpaladin 등 계약자에게 분배한다. 자금이 들어간 항목은 다음과 같다.

기대하는 결과는 기술적인 것(더 나은 QA, 덜 깨지는 Plasma 세션, 더 안정적이고 설정하기 쉬운 소프트웨어)도 있지만, Ottens는 생태계 효과를 더 강조했다. KDE가 “주택 담보와 청구서를 낼 돈을 벌 수 있는 생태계”가 되면 파이가 커지고, 배포가 늘면 필요가 늘고, 필요가 늘면 개선 요청이 늘어 눈덩이처럼 굴러간다는 것이다. STA 프로젝트는 2027년 3분기까지 진행되고 그 뒤 자금이 끝나므로, 커뮤니티가 계속 밀어야 한다고 했다. 질의응답에서는 KDE PIM 인스턴트 메시징 지원 계획은 서버 쪽이 “유동적”이라 넣지 않았고, JMAP 지원은 “맨땅에서 시작해야 해서” 가격이 너무 높아 빠졌다는 설명이 나왔다. Graham의 마무리가 이 부분의 요지다. “이런 작업을 할 때 하고 싶은 걸 아무거나 담는 보따리로 만들 수는 없다. 제안서를 지켜야 한다.”

구글과 Igalia에서 Chromium을 개발하기

Sharon Yang은 구글에서 6년간 Chrome을, 지금은 Igalia에서 Chromium을 개발한다. FOSSY 2026 마지막 날 발표에서 두 회사가 어떻게 다르게 돌아가고 그것이 코드베이스 작업에 어떤 영향을 주는지 비교했다. 두 곳 모두 좋았다는 입장이라 불평을 늘어놓는 발표가 아니라, 꽤 다른 두 회사의 느낌을 전하려는 발표였다.

제목은 “From Corporate to Co-op”이었다. 직원 수는 구글 약 18만 명, Igalia 약 180명이고, 작년 매출은 구글 4,000억 달러 이상, “Igalia는 훨씬 작으니 10억 달러 이하라고만 해두자”(객석 웃음). 구글은 기관 투자자 소유, Igalia는 직원 소유다(객석 박수). 구글의 보상 범위는 CEO의 6억 달러 패키지부터 그가 받던 10만~30만 달러대까지 걸쳐 있는데, Igalia는 위아래 없이 전 세계 모든 직원이 같은 급여를 받는다.

그는 Chrome과 Chromium이 “같기도 하고 아니기도 하다”고 설명했다. Chrome은 구글 브랜딩과 색이 붙은 구글 제품이고, Chromium은 누구나 브라우저를 만들 수 있는 오픈소스 프로젝트다. Chromium에는 DRM, “AI 통합”, 일부 코덱 같은 비공개(proprietary) 조각이 빠져 있고 “그리고 파란색이다”. 구글 Chrome 팀원 대부분은 작업의 대부분 또는 전부를 Chromium 저장소에서 하며, 비공개 부분을 거의 건드리지 않는다. 그는 구글에서 일하던 막바지에 간단한 작업 하나를 하려고 비공개 부분이 사는 “완전히 다른 우주”에 접근할 도움을 받아야 했다고 했다.

같은 저장소, 같은 도구, 같은 사람들과 일하는데 외부인이 되면서 생기는 마찰이 있다.

• Chromium을 빠르게 빌드하는 시스템(“안 쓰면 빌드하는 데 시간을 다 쓴다”)은 구글 직원에게는 바로 열려 있지만 외부 사용자는 접근을 요청해야 한다
• 보안 버그가 아니면 누구에게나 열려 있어야 할 버그 리포트 중, 몇 년 전 버그 트래커 이전 때문에 구글 직원만 볼 수 있는 것들이 있다. “악의적인 게 아니고” 고치기도 쉽지만 일주일에 한 번쯤 해야 하는 추가 작업이다
• 공개될 수 있는 정보가 공유되지 않은 Google Docs에 들어 있는 경우가 있다. 공개 보장이 “최선 노력 사항이고 사람들은 잊는다”
• 버그 트래킹 같은 도구가 전부 구글이 구글을 위해 유지하므로, 외부인은 피드백이나 기능 요청을 할 길이 없다. “비교적 작은 마찰”이지만 “이제 내가 이것과 분리되어 있구나” 하고 느끼게 하기에는 충분하다

한 달쯤 지나자 오히려 비슷한 점이 더 보였다고 한다. 팀원들과는 같은 채널(예: Slack)로 연락하고, Igalia가 하는 일 일부는 직간접적으로 구글에서 온다. 그가 맡은 Chromium 프로젝트도 구글이 회원인 Linux Foundation을 거쳐 들어온 것이다. “같은 저장소에서 일하고, 같은 도구를 쓰고, 구글에서 돈을 받는다. 뭐가 바뀐 거지?”

답은 프로젝트의 종류에서 나온다. 구글에서는 관리 체인에 있는 사람들에게 중요한 프로젝트, 흔히 새 기능이나 “개선하고 싶은 화려한 지표”를 했고 그것은 엔지니어와 보고 체인의 승진을 겨냥한 일이 많았다. Igalia에 들어오는 프로젝트는 기술 인력에서 직접 오기 때문에 “코드 건강이나 기술 부채 성격의 프로젝트”가 되는 편이다. Igalia는 Chromium 코드베이스 컴포넌트화 작업을 했고 현재 프로젝트는 “브라우저 간 web-platform-test 상호운용성 개선”이다. 중요하고 해야 할 일이지만 “구글에 있는 누군가가 그걸 본업으로 한다고 상상하기는 정말 어렵다”. “우선순위가 매겨지거나 보상받는 종류의 일이 아니다.” 구글에서 함께 일한 많은 사람이 그 일을 하고 싶어 한다. “코드베이스를 아끼고 좋게 만들고 싶은 사람들인데, 본업에 그럴 여지가 없다. 안타까운 일이다.”

조직 구조의 차이가 가장 컸다. 일반 기업 조직도에서 엔지니어는 위계의 맨 아래 잎 노드이고, 아래는 어떤 언어를 쓸지 같은 기술 결정을, 위는 회사 방향과 비전을 정하며 중간 사람들이 뭘 하는지는 “누가 알겠나”(웃음). “위에 있는 사람들이 아래 있는 사람들보다 훨씬 많이 받는다.” Igalia의 조직도는 “의도적으로 평평하고” 관리자가 없다. Chromium 팀, 리눅스 커널 팀 같은 팀들이 있고, 평평한 위계 때문에 “큰 회사의 잎 노드 직원이라면 보통 하지 않을 일”을 전 직원이 많이 한다. 어떤 프로젝트를 받을지, 인원을 늘릴지, 휴가는 얼마나 둘지 같은 회사 결정이 그렇다. 협동조합이라 이런 질문은 투표로 정한다. “큰 회사에서는 전혀 영향을 줄 수 없는 결정들이다.” 결정하는 사람이 그 결정에 영향받는 사람이라는 점이 좋은데, 정리해고가 가장 분명한 예라고 했다. 대가는 그 결정을 위한 회의가 유럽 시간대로 이틀씩 이어진다는 것이다. 구글에서는 자신이 지배적 시간대(미국 태평양)에 있었고 다른 지역 팀원들이 이상한 시간에 회의를 해야 했으니 업보처럼 느껴진다면서도, “근본적으로 다르고 기분 좋은” 구조를 위해 치르는 “작은 대가”라고 했다.

가장 크게 체감한 변화는 승진이 없다는 점이다. 모두 같은 급여를 받는 평평한 조직에는 승진이 존재하지 않는다. 신입 때는 승진이 기대되는 것이라 거기에 집중했고(“Meta는 정해진 기간에 정해진 레벨에 도달하지 못하면 문자 그대로 해고한다”), 올바른 프로젝트에서 “올바른 역량을 입증”하려 애쓰는 일은 스트레스였고 노력도 많이 들었다. 그 상당 부분이 엔지니어의 손을 떠나 관리자에게 달려 있다. 구글에서 좋은 관리자를 만나 운이 좋았지만, 좋은 관리자라도 여러 명을 보고받는다. “당신에게는 당신의 직업 인생 전체인데, 그들에게는 해야 할 백만 가지 중 하나다.” 균일 급여 구조도 환영할 변화였다. 급여 격차가 없다는 것은 여성이자 한때 비자로 일했던 사람에게 “아주 현실적인 걱정”이었고 “이제 그게 전부 사라졌다”. 같은 운동장에 서면 신뢰와 협업이 늘어난다는 것이다. “재미있게 들린다면 협동조합에 들어가거나 하나 만들어라.”

짧은 소식

• 파일 알림을 이용한 공격 연구 — 그라츠 공과대학 연구진이 안드로이드·리눅스·macOS·윈도우에서 사용자 활동을 엿보는 파일 알림 공격 연구를 공개했다. 리눅스에서는 디렉터리 안 파일에 읽기 권한이 없어도 inotifywatch로 디렉터리를 감시해 키 입력 간 타이밍 공격을 할 수 있다. KDE 5와 6에서는 /usr/bin/pkexec를 감시해 Polkit이 인증 프롬프트를 띄우는 순간을 탐지하고, 진짜 창 위에 가짜 비밀번호 창을 그려 자격증명을 수집하는 UI 리드레스(클릭재킹) 공격이 가능하다. 두 결함은 지금도 남아 있으며, 커널은 1월에 나온 5.10.248·5.15.198·6.1.160·6.6.120·6.12.65·6.18.3에서 부분적으로 완화했을 뿐이다.
• 커널 7.3-rc5 — 9월 27일 릴리스. 리누스 토발즈는 “‘크다’ 말고는 특별한 패턴이 없는 것 같다. 하지만 딱히 경계할 만한 것도 없고, diffstat에도 불구하고 늘 그렇던 그대로라고 본다”고 했다. 지금까지 개발자 2,811명의 머지 제외 체인지셋 17,633건이 들어갔고 그중 690명이 첫 기여자다. 9월 25일에는 7.2.8과 6.18.54 안정 업데이트가 나왔다.
• Git 2.56.0 정식 릴리스 — 6월 2.55 이후 개발자 104명(첫 기여자 39명)이 올린 머지 제외 커밋 748건이 들어갔다. 충돌 해결을 위한 더 안전한 워크플로, 더 작아진 path-walk repack, 새 git history drop 서브커맨드 등이 포함된다. 2026 Git Contributors’ Summit 논의 요약도 올라왔는데, Git 3.0, 보안 프로세스, 문서화, 플러그형 객체 데이터베이스, LLM 사용 등이 주제였다.
• Kernel Report 2026 — 2년 공백 뒤 LWN의 Jonathan Corbet이 Kernel Recipes에서 Kernel Report 개정판을 발표했다. 가속되는 변화의 시기에 커널 커뮤니티가 어떻게 대응하고 있는지, 앞으로 어디로 갈지를 다뤘고 영상이 공개됐다. Kernel Recipes 전체 영상도 올라왔다.
• Linux Foundation TAB 선거 — Linux Plumbers Conference가 끝난 뒤 전자 투표로 진행된다. 후보 지명 마감은 10월 7일이고 이번에 채울 자리는 다섯 개인데, 그중 하나는 세상을 떠난 Dan Williams의 자리다.
• Firefox 157.0 / GDB 18.1 / F-Droid 2.0 — Firefox는 “수년 만의 최대 시각적 개편”과 WebRTC 통화의 하드웨어 AV1 디코딩을 넣었다. GDB 18.1은 하위 프로세스 환경을 조작하는 새 명령, 명령 히스토리를 파일로 저장하는 기능, 새 타깃 지원, Python API 추가가 들어갔다. F-Droid 2.0은 공식 앱을 전면 재설계해 앱 탐색과 검색을 개선했고, 핵심 컴포넌트를 Kotlin Compose로 재작성했다.

이번 주 인용문으로는 Jakub Kicinski의 관찰이 눈에 띈다. 요즘 전반적인 코드 품질에 깊은 인상을 받았고 회귀가 아주 드물며, “사람들이 보내는 생각 없는 슬롭(slop)조차 2년 전에 우리가 머지하던 코드보다 자릿수 단위로 낫다”는 것이다. 더 중요한 것은 머지되는 패치마다 여러 프런티어 모델이 리뷰하면서 회귀 위험의 계산이 꽤 달라졌다는 지적이다. 반대편에는 Richard W.M. Jones의 배포판론이 있다. 패키지마다 버전 하나로 일관된 배포판을 만들고 라이브러리는 안정된 API와 하위 호환을 염두에 두고 빌드하며 변경은 업스트림으로 보내고 보안 취약점은 한 번만 고치는 쪽(“좋은 방식”, 일이 더 많고 사람들이 실제로 전문 엔지니어처럼 행동해야 한다)과, 되는 대로 전부 쓸어 담아 장기 부채와 심각한 보안 문제를 숨기는 쪽(“나쁜 방식”)의 대비다. Debian 쪽에서는 커널 보안 권고 하나에 CVE 1,264개가 생략 표기로 들어간 사례가 “several(몇 개)”의 정의를 다시 썼다는 농담도 나왔다.

행사는 프라하 주간이다. 10월 2~4일 GNU Tools Cauldron, 3~4일 Linux Days와 openSUSE.Asia Summit(욕야카르타), 5~7일 Linux Plumbers Conference, 6일 Yocto Project Developer Day와 Real-time Linux User Forum, 7~9일 Open Source Summit Europe과 Embedded Linux Conference Europe, 8일 Linux Security Summit Europe, 10~11일 GStreamer Conference, 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이 이어진다. CFP 마감은 OpenALT가 10월 4일, OLF Conference가 10월 9일, Southern California Linux Expo가 11월 1일이다.

이번 주 핵심 요약

• Freund의 목록은 PostgreSQL만의 이야기가 아니라 “큰 메모리와 많은 동기화를 쓰는 서버 애플리케이션”의 공통 과제다. 당장 확인해볼 것 두 개를 꼽자면, 클라이언트 수 대비 처리량이 중간에 꺼지는 패턴이 보이면 cpuidle을 의심해볼 것, 그리고 cgroup 안에서 vm.overcommit_memory=2가 의도대로 동작하지 않는다는 점이다. 후자는 컨테이너로 DB를 돌리는 구성에서 조용히 전제를 깨뜨린다.
• C의 미정의 동작은 “표준이 애매해서”가 아니라 “표준이 명확한데 컴파일러가 다르게 본다”는 쪽이 더 골치다. 포인터 동등 비교가 GCC·Clang 모두에서 잘못 컴파일된다는 지적이 그 예다. 실무에서 가져갈 것은 C2y를 기다리는 게 아니라 지금 쓸 수 있는 것들이다. 유연 배열 멤버에는 counted_by를 붙이고, 새니타이저를 테스트 빌드에 넣고, 하드닝이 필요하면 트래핑 모드를 검토할 것.
• Rust on GPU 구상의 매력은 “같은 코드가 CPU에서도 돈다”는 것이고, 비용은 커널 인스턴스 대부분을 busy loop로 재워두는 설계에 다 들어 있다. 스레드 생성을 공유 리스트 + 플래그로 모사하는 방식이라 동기화 비용과 바이너리 크기가 실제 성능을 가를 것이다. 아직 프로토타입이고 자동 벡터화도 거친 단계이니, CUDA·wgpu 대체를 지금 검토할 단계는 아니다.
• SDR 발표는 “싼 하드웨어 + 복소수 기초 + 적당한 언어”면 시작할 수 있다는 좋은 입문 지도다. 특히 샘플당 1마이크로초라는 제약과, 첫 ADS-B 구현이 정보의 1/6만 잡았다는 고백이 현실적이다. 2.4MHz 샘플링에서 half-slot이 1.2샘플이라는 수치는 이 취미에서 하드웨어 한계가 어디서 오는지 바로 보여준다.
• Plasma 6.8의 X11 제거는 기능 제거가 아니라 “같은 기능의 구현 두 벌 중 하나를 버리는” 정리다. Martin이 든 패널 코드 경로 예시처럼, 유지보수 부담과 테스트 불가 영역이 함께 사라진다. X11 세션에 묶여 있는 환경이 있다면 6.8 업그레이드 전에 Wayland 전환 가능성을 먼저 점검해둘 것.
• KDE의 STA 자금 사례에서 재사용할 수 있는 것은 돈 액수가 아니라 절차다. 비전 → 작업 패키지 → 태스크 → 삼점 추정으로 내려가며 가격표를 붙이는 과정이 “작업을 끝낼 역량이 있다”는 신호가 됐다. 그리고 QA 인프라를 가장 먼저 세운 선택이 양쪽 작업 패키지에서 공통적이었다는 점도 눈여겨볼 만하다. Graham의 경고도 같이 기억할 것 — 제안서는 하고 싶은 걸 담는 보따리가 아니다.
• Yang의 비교에서 가장 쓸 만한 통찰은 조직 구조가 어떤 작업이 가능한지를 결정한다는 것이다. 컴포넌트화나 테스트 상호운용성 같은 코드 건강 작업은 구글 안에서는 승진에 연결되지 않아 본업이 되기 어렵고, 그래서 외부 조직이 돈을 받고 하게 된다. 오픈소스 프로젝트의 기술 부채를 누가 갚을지 생각할 때 참고할 구조다.

원문: LWN.net Weekly Edition for October 1, 2026