DEVOCEAN

리눅스 운영체제의 1번 프로세스를 책임지는 시스템 데몬과 브라우저 위에서 가구를 그리는 3D CAD 애플리케이션은 겉보기에 접점이 없어 보입니다. 하나는 커널 바로 위에서 부팅 시퀀스와 서비스 수명 주기를 제어하는 전통적인 C 기반 인프라이고, 다른 하나는 사용자의 마우스 궤적을 쫓아 3차원 공간에 다각형을 배치하는 그래픽 도구입니다. 그러나 2026년 11월 9일 공개된 기술 커뮤니티의 두 가지 기록은 서로 다른 계층에서 동일한 엔지니어링 과제를 마주하고 있습니다.

리눅스 코어 시스템을 지탱하는 systemd의 Rust 지원 병합 소식과, Rust와 WebGPU 기반으로 개발된 오픈소스 3D 모델링 도구 KetchUp의 등장은 시스템 소프트웨어가 신뢰성과 성능을 확보하는 방식을 구체적으로 보여줍니다. Rust를 시스템에 도입할 때 진짜 성패를 가르는 기준은 언어 문법이 아니라, 기존 C 빌드 인프라와 표준 라이브러리(std) 제약을 어떻게 타협하고 로컬 샌드박스를 설계하는가에 있습니다.

systemd가 Rust를 품는 방식: meson 유지와 std 배제의 실무

systemd 프로젝트는 오랜 기간 순수 C 언어(GNU C 표준)로 작성된 거대한 모놀리식 코드베이스를 유지해 왔습니다. 수많은 데몬과 명령줄 유틸리티, 공유 라이브러리가 뒤엉켜 있는 환경에서 특정 구성 요소의 메모리 오류는 전체 시스템 장애로 직결됩니다. 이번에 systemd 메인라인에 병합된 변경점의 핵심은 개별 실행 바이너리를 C뿐만 아니라 Rust로도 작성할 수 있도록 빌드 경로를 열었다는 사실입니다.

원문 발췌에 따르면 핵심 공유 라이브러리는 당분간 C로 유지됩니다. 공통 C 코드를 Rust 크레이트로 감싸는 방식을 취해 핵심 API를 공유하며, 구현 언어가 C이든 Rust이든 관계없이 옵션 처리, 도움말 출력, 오류 메시지의 동작을 완벽히 동일하게 유지하도록 규정했습니다. 이는 기존 사용자와 스크립트 환경에 하위 호환성 파괴를 전혀 일으키지 않겠다는 엄격한 원칙을 반영합니다.

주목해야 할 기술적 제약은 빌드 도구와 표준 라이브러리 사용 정책입니다. 일반적인 Rust 프로젝트는 cargo 패키지 관리자를 중심으로 크레이트 생태계(crates.io)에서 수많은 외부 라이브러리를 끌어와 빌드합니다. 그러나 systemd는 일반적인 Rust 개발 관행을 따르지 않습니다. systemd는 Rust 코드를 빌드할 때도 기존 C 프로젝트에서 쓰던 meson 빌드 시스템을 그대로 사용하며, cargo와 Rust 표준 라이브러리(std)를 사용하지 않습니다. 외부 크레이트 의존성 도입에도 지극히 보수적인 정책을 적용하고 있습니다.

표준 라이브러리를 쓰지 않는다는 것은 #![no_std] 환경에서 동작함을 의미합니다. 이는 시스템 레벨 소프트웨어가 지녀야 할 독특한 제약 때문입니다. 일반적인 운영체제 환경에서 동작하는 Rust 프로그램은 메모리 할당 실패 시 패닉(panic!)을 일으키며 프로세스를 즉각 중단합니다. 하지만 PID 1을 다루거나 저수준 시스템 초기화를 담당하는 systemd 바이너리는 OOM(Out of Memory, 메모리 고갈) 상황에서도 프로세스가 강제 종료되는 대신 명시적인 에러 코드(ENOMEM)를 상위 호출자로 반환해야 합니다. 이를 위해 systemd는 메모리 할당 실패를 직접 제어하는 자체 할당자 크레이트를 제공합니다.

표 1. 일반 Rust 프로젝트와 systemd의 빌드·런타임 정책 비교

• 빌드 도구 — 일반 Rust 프로젝트: cargo / systemd: meson (기존 C 빌드 시스템)
• 외부 의존성 — 일반 Rust 프로젝트: crates.io 크레이트 다수 / systemd: 외부 크레이트 도입에 보수적
• 표준 라이브러리 — 일반 Rust 프로젝트: std 사용 / systemd: std 미사용 (no_std)
• 할당 실패 시 — 일반 Rust 프로젝트: panic으로 프로세스 중단 / systemd: ENOMEM 반환 (자체 할당자)
• 패키징 경로 — 일반 Rust 프로젝트: cargo build / systemd: meson compile, ninja

여기에 대한 DEVOTEE의 해석입니다. 흔히 시스템 언어를 Rust로 전환한다고 하면 레거시 C 코드를 전부 재작성(Rewrite-it-in-Rust)하는 장밋빛 구상을 떠올리기 쉽습니다. 그러나 systemd 메인테이너들은 정반대의 길을 택했습니다. 안정적인 C 코드를 단순히 언어를 바꾸겠다는 이유로 재작성하지 않는다는 방침을 분명히 했습니다. 빌드 시스템의 주도권을 여전히 C 기반의 meson에 두고, Rust 컴파일러(rustc)를 C 컴파일러와 대등한 하나의 백엔드 툴체인으로 종속시켰습니다.

실무에서 이러한 설계는 파이프라인 구성 방식에 큰 차이를 만듭니다. 일반적인 Rust 개발자가 익숙한 Cargo.toml 기반 빌드는 배제되며, meson.build 파일 내에서 Rust 소스 파일을 직접 명시하고 컴파일 플래그를 주입해야 합니다.

# systemd 스타일의 meson 기반 Rust 바이너리 빌드 설정 예시
project('systemd-rust-example', 'c', 'rust',
  version : '256.0',
  default_options : ['warning_level=2', 'c_std=gnu11', 'rust_std=2021']
)

# C 공통 유틸리티 라이브러리
libsystemd_c_compat = static_library(
  'systemd_c_compat',
  sources : ['src/basic/util.c', 'src/basic/macro.c'],
  c_args : ['-D_GNU_SOURCE']
)

# C 인터페이스를 바인딩하는 커스텀 Rust 크레이트 구성
# cargo를 호출하지 않고 rustc를 meson이 직접 제어함
executable(
  'systemd-network-helper',
  sources : ['src/network/main.rs'],
  rust_args : [
    '--cfg', 'feature="no_std"',
    '-C', 'panic=abort',
    '-C', 'opt-level=s'
  ],
  link_with : [libsystemd_c_compat],
  install : true,
  install_dir : '/usr/lib/systemd'
)

위 설정에서 보듯, cargo build 명령을 실행하는 일은 발생하지 않습니다. 배포판 패키징 파이프라인(rpm, deb 등)은 오직 meson compile과 ninja만을 거칩니다. 이는 배포판 패키징 도구들이 네트워크가 격리된 샌드박스 빌드 환경에서 수많은 외부 의존성을 사전에 검증해야 하는 요구사항을 충족시키기 위함입니다.

웹과 데스크톱의 경계를 허무는 KetchUp: Rust와 WebGPU가 선택한 격리 방식

운영체제의 밑바닥에서 systemd가 Rust의 안전성을 취하며 런타임을 덜어냈다면, 응용 애플리케이션 계층에서는 KetchUp이 브라우저와 네이티브 데스크톱 환경의 렌더링 파이프라인을 단일 코드베이스로 묶어냈습니다. KetchUp은 목공과 가구 설계를 위한 무료 오픈소스 3D 모델링 도구로, 작업자가 선반, 테이블, 수납장, 작업대 등을 제작하기 전에 정확한 치수로 3차원 설계를 마칠 수 있도록 지원합니다.

원문에 명시된 기술 구성에 따르면 KetchUp은 Rust와 WebGPU(웹 브라우저 및 네이티브 환경에서 현대적인 GPU 연산을 수행하기 위한 차세대 그래픽 표준 규약)를 기반으로 작성되었습니다. 선과 도형으로 면을 만든 뒤 'Push/Pull' 동작으로 두께를 부여하고, 이동, 크기 조절, 오프셋, 색칠 도구로 모델을 편집합니다. 또한 정확한 길이 입력과 스냅, 치수 도구로 실제 가공 오차를 통제하며, 부품들을 그룹 및 재사용 가능한 컴포넌트, 태그로 체계화합니다.

운영 체제 관점에서 주목해야 할 부분은 실행 환경과 데이터 영속성 구조입니다. KetchUp은 Windows, macOS, Linux 같은 네이티브 OS는 물론 데스크톱 웹 브라우저 환경에서도 완벽히 동일한 바이너리 로직으로 실행됩니다. 계정 등록이나 클라우드 데이터베이스 저장소를 강제하지 않고, 브라우저 로컬 저장소와 프로젝트 고유 포맷인 .ketchup 파일 저장을 사용합니다.

여기서 이끌어낼 수 있는 해석은 명확합니다. KetchUp이 WebGPU와 Rust 컴파일 파이프라인(WebAssembly, WASM)을 조합한 이유는 플랫폼별로 분기되는 GUI 렌더링 프레임워크의 오버헤드를 완전히 걷어내기 위함입니다. 과거 Electron 계열 도구들이 3D CAD를 구현할 때 겪었던 자바스크립트의 가비지 컬렉션(GC, Garbage Collection) 지연과 메모리 복사 비용을, Rust의 소유권 모델과 WebGPU의 로우레벨 하드웨어 추상화를 통해 제거했습니다.

실제로 클라우드 서버와의 통신을 배제한 로컬 중심 아키텍처는 데이터 주권과 보안 측면에서도 중요한 시사점을 던집니다. 기업 내부 도면이나 개인 작업 데이터가 외부 SaaS 인프라로 유출될 위험을 원천 차단하며, 네트워크 연결이 끊긴 오프라인 작업장에서도 데스크톱 브라우저만 열려 있다면 즉각적인 3D 연산이 가능합니다.

// WebGPU 렌더링 루프와 메시(Mesh) 할당을 처리하는 Rust 핵심 구조 예시
use std::fs::File;
use std::io::{Write, Read};

// 3D 버텍스 데이터: 메모리 패딩을 엄격하게 제어하여 GPU 버퍼와 직접 매핑
#[repr(C)]
#[derive(Copy, Clone, Debug, bytemuck::Pod, bytemuck::Zeroable)]
pub struct Vertex {
    pub position: [f32; 3],
    pub normal: [f32; 3],
}

pub struct ModelProject {
    pub vertices: Vec<Vertex>,
    pub indices: Vec<u32>,
}

impl ModelProject {
    // 클라우드 의존성 없이 로컬 바이너리 포맷(.ketchup)으로 상태 영속화
    pub fn save_to_local_file(&self, path: &str) -> Result<(), std::io::Error> {
        let mut file = File::create(path)?;
        // 헤더 매직 바이트 검증
        file.write_all(b"KTCH")?;
        let vertex_count = self.vertices.len() as u64;
        file.write_all(&vertex_count.to_le_bytes())?;
        
        let vertex_bytes: &[u8] = bytemuck::cast_slice(&self.vertices);
        file.write_all(vertex_bytes)?;
        
        let index_count = self.indices.len() as u64;
        file.write_all(&index_count.to_le_bytes())?;
        
        let index_bytes: &[u8] = bytemuck::cast_slice(&self.indices);
        file.write_all(index_bytes)?;
        
        file.flush()?;
        Ok(())
    }
}

위 코드처럼 그래픽 메모리에 올라가는 버텍스 구조체(#[repr(C)])를 자바스크립트 오브젝트 레이어를 거치지 않고 직접 바이트 슬라이스로 직렬화하여 파일이나 GPU 버퍼(wgpu::Buffer)에 복사 없이 투영합니다. 이는 systemd가 C와 메모리 레이아웃을 맞추기 위해 사용한 바인딩 기법과 근본적으로 같은 공학적 접근입니다.

시스템 엔지니어링의 공통 분모: 런타임 최소화와 인터페이스 격리

systemd와 KetchUp은 배포 환경과 목적이 완전히 상이하지만, 실무 아키텍처 관점에서 공유하는 핵심 원칙이 세 가지 존재합니다.

표 2. systemd와 KetchUp이 공유하는 세 가지 원칙

• 외부 런타임 의존 최소화 — systemd: cargo·std 배제 / KetchUp: WebAssembly·WebGPU 표준에만 의존
• 기존 자산·표준과 정렬 — systemd: C API 시맨틱·출력 형식 유지 / KetchUp: WebGPU 규격 준수
• 상태의 로컬 완결성 — systemd: 자체 할당자 기반 격리 / KetchUp: .ketchup 파일·브라우저 스토리지

외부 런타임에 대한 의존성을 최소화합니다. systemd는 cargo와 Rust 기본 std를 배제함으로써 런타임의 불확실성을 통제했습니다. 일반적인 언어 생태계가 제공하는 거대한 런타임과 표준 라이브러리는 개발 편의성을 높여주지만, 메모리 제약 환경이나 결정론적 실행이 요구되는 환경에서는 치명적인 통제 불능 요인이 됩니다. KetchUp 역시 클라우드 백엔드나 별도의 무거운 데스크톱 런타임 대신 WebAssembly 컴파일 타깃과 WebGPU 표준 스펙에만 기대어 실행 환경을 단순화했습니다.

기존 자산 및 표준 규약과의 엄격한 정렬입니다. systemd는 기존에 구축된 C 코드베이스의 API 시맨틱을 강제로 바꾸려 하지 않았습니다. Rust 크레이트로 C 헤더를 감싸는 바인딩을 제공하고, 옵션 파싱과 터미널 출력 형식을 C 바이너리와 정확히 일치시켰습니다. KetchUp 또한 독자적인 그래픽 드라이버 통신 방식을 고안하는 대신, W3C 및 크로스 플랫폼 표준인 WebGPU 규격을 준수함으로써 크롬, 파이어폭스, 윈도우, 리눅스 전반에서 동일한 렌더 파이프라인을 재사용합니다.

상태의 로컬 완결성입니다. systemd는 프로세스의 메모리 오류가 시스템 전체로 전파되지 않도록 자체 할당자 기반의 격리를 구축했고, KetchUp은 프로젝트 파일(.ketchup)과 브라우저 내부 스토리지에 데이터를 가둠으로써 외부 네트워크 종속성 없이 단독으로 실행 완결성을 갖췄습니다.

DEVOTEE의 기술 판단과 실무 가이드라인

오늘 살펴본 두 프로젝트에 대한 DEVOTEE의 명확한 판단과 조건은 다음과 같습니다.

1. systemd의 meson 기반 no_std Rust 도입 방식: 지금 써볼 만합니다

대규모 레거시 C 프로젝트를 운영하는 엔지니어링 조직이라면 이 방식을 당장 벤치마킹할 가치가 충분합니다. 수십만 줄의 C 코드가 안정적으로 돌아가는 상황에서 전체를 Rust로 재작성하는 프로젝트는 대부분 실패로 끝납니다.

핵심 공유 라이브러리를 C로 유지한 채 말단 유틸리티 바이너리부터 점진적으로 Rust로 작성하되, cargo를 빌드 파이프라인 전면에 세우지 않고 기존 meson이나 cmake의 서브프로젝트로 통제하는 방식은 가장 실용적인 접근입니다. 특히 메모리 고갈 상황을 직접 처리해야 하는 임베디드 및 시스템 데몬 개발팀은 systemd의 자체 할당자 크레이트 구성 방식을 필수적으로 참고해야 합니다.

2. KetchUp의 Rust + WebGPU 기반 크로스 플랫폼 도구 개발: 조건부로 유효합니다

웹과 데스크톱을 동시에 겨냥하며 고성능 그래픽 연산이 필요한 CAD, 데이터 시각화, 그래픽 에디터 영역에서는 매우 강력한 선택지입니다. 프레임워크 수준의 오버헤드를 지우고 직접 GPU 버퍼를 다루는 설계는 자바스크립트 엔진의 한계를 완전히 극복합니다.

그러나 조건이 붙습니다. WebGPU는 2026년 현재 최신 브라우저와 현대적인 OS 환경에서 폭넓게 지원되고 있으나, 여전히 구형 하드웨어 환경이나 특정 Linux 그래픽 드라이버(예: 일부 독점 드라이버 구성)에서는 비표준 동작이나 셰이더 컴파일 오류를 겪을 수 있습니다. 모바일 웹 브라우저 환경까지 포괄해야 하는 범용 서비스라면 WebGL 폴백 레이어 설계가 병행되어야 하므로 구현 복잡도가 크게 증가합니다.

도입 전 확인할 것: 시스템 소프트웨어의 도구 체인 전환 체크리스트

C 코드베이스에 Rust를 부분 도입하거나, WebGPU 기반으로 네이티브/웹 겸용 애플리케이션을 기획 중인 팀이라면 코드 작성 전 다음 사항들을 먼저 점검해야 합니다.

1. 기존 빌드 시스템의 Rust 컴파일러 제어 가능성: 팀의 CI/CD 파이프라인과 패키징 시스템이 cargo의 네트워크 접근 없이 오프라인 환경에서 rustc 단독 호출 및 의존성 주입을 지원하는지 확인하세요. 지원하지 않는다면 의존성 패키징 미러링 구축이 선행되어야 합니다.
2. 할당 실패 정책의 요구 수준: 애플리케이션이 OOM 발생 시 패닉 중단되어도 무방한 사용자 도구인지, 아니면 반드시 에러 코드를 반환하고 프로세스 상태를 유지해야 하는 시스템 백그라운드 서비스인지 구분하세요. 후자라면 표준 std를 버리고 커스텀 할당자를 구현할 엔지니어링 역량이 확보되어야 합니다.
3. 그래픽 표준 타깃 하드웨어 분포: WebGPU 파이프라인을 채택할 경우 조직의 최종 배포 대상 기기들이 Vulkan, Metal, DirectX 12 중 최소 하나를 하드웨어 레벨에서 안정적으로 지원하는 그래픽 드라이버를 갖추었는지 사전에 진단해야 합니다.

그 밖의 소식

본문 주제로 다루지 않은 오늘자 개발 실무 관련 소식 4건을 요약해 남깁니다.

• Univer 스프레드시트·문서 편집 SDK: 웹 애플리케이션 내에 수식 계산 엔진, 리치 텍스트 편집기 및 AI 에이전트 연동 API를 임베딩하는 SDK가 공유되었습니다. 원문 보기
• RAM Altman 메모리 진단 스크립트: Linux /proc/meminfo를 기반으로 가용 RAM을 측정해 유휴 자원 상태를 확인하는 오픈소스 유틸리티 스크립트가 공개되었습니다. 원문 보기
• AWS HPC 환경의 WRF 기상 시뮬레이션 최적화: 동일한 vCPU 환경에서 MPI 프로세스와 OpenMP 스레드 비율을 튜닝해 최대 22%의 실행 시간 차이를 측정한 실측 분석 기록입니다. 원문 보기
• 회사 두뇌(Company Brain) 지식 기반 아키텍처: AI 에이전트의 환각을 방지하고 정확한 사내 맥락을 제공하기 위해 파인튜닝 대신 실시간 검색과 최신 도구 연동을 설계하는 방법론이 공유되었습니다. 원문 보기