--- title: "러스트 컴파일러 전체를 C로 번역한 ‘크러스트씨’ 공개" published: 2026-07-02T22:57:35.000Z canonical: https://jeff.news/article/4582 --- # 러스트 컴파일러 전체를 C로 번역한 ‘크러스트씨’ 공개 한 개발자가 rustc 전체를 C 코드로 번역해 GCC와 make로 빌드할 수 있는 데모 ‘crustc’를 공개했어. 핵심은 Rust를 C로 컴파일하는 cilly 툴체인의 쇼케이스로, LLVM이나 GCC가 직접 지원하지 않는 오래되거나 특이한 플랫폼에서도 Rust를 돌릴 가능성을 노린 프로젝트야. ## rustc를 통째로 C로 번역했다 - ‘crustc’는 동작하는 Rust 컴파일러를 C 코드 형태로 빌드할 수 있게 만든 데모임 - GCC와 GNU make로 빌드하면 Rust 컴파일러가 나옴 - 이 컴파일러는 core, alloc, std 같은 Rust 표준 구성 요소도 컴파일할 수 있다고 설명함 - 저장소 자체는 새 툴체인 ‘cilly’의 쇼케이스에 가까움 - 작성자는 지난 3년간 Rust를 C로 컴파일하는 작업을 해왔고, 이번이 14번째 시도라고 밝힘 - 이전에는 rustc_codegen_clr 같은 공개 시도도 있었고, 비공개 실험도 많았다고 함 - cilly는 Rust 코드 생성 라이브러리이자 rustc 백엔드 플러그인으로 동작함 - 즉 사용자는 특정 타깃에 어떤 C 컴파일러를 쓸지만 정하면, cilly가 Rust를 C로 바꿔 그 컴파일러에 넘기는 구조임 > [!IMPORTANT] > 포인트는 “Rust를 C로 예쁘게 변환”이 아니라, LLVM이나 GCC가 직접 지원하지 않는 오래되거나 특이한 플랫폼에도 Rust를 보낼 통로를 만들겠다는 데 있음. ## 이상한 C 컴파일러까지 맞춰주는 방식 - cilly의 핵심 아이디어는 대상 C 컴파일러에 맞춰 코드를 생성하는 것임 - 작성자는 예시로 “이상한 운영체제의 이상한 C 컴파일러”까지 언급함 - 타입 레이아웃, 크기, 정렬, 문자 인코딩, 정수 표현 같은 걸 가정하지 않고 질의함 - 가능한 한 ANSI C 밖의 가정을 피하고, 필요하면 런타임 assert나 문서화로 처리한다고 함 - 이를 위해 ‘증인 프로그램’을 생성해 대상 컴파일러와 플랫폼의 성질을 확인함 - 예를 들어 포인터 왕복 변환, CHAR_BIT 값, 2의 보수 정수 표현 같은 현실적인 가정들을 검사하는 식 - 그래서 생성된 C 코드는 이식 가능한 범용 C라기보다, 특정 컴파일러와 특정 플랫폼에 맞춘 C에 가까움 - ARM64용으로 생성한 C를 그대로 RISC-V 32비트에서 돌리는 식은 안 되고, RISC-V용으로 다시 생성해야 함 - 네트워크 투명성도 꽤 특이한 부분임 - cilly는 TCP 너머의 C 컴파일러와 통신할 수 있음 - 정상적인 리눅스 머신에서 rustc를 돌리고, 특이한 운영체제 쪽에는 작은 C 서버만 띄워서 컴파일을 맡기는 방식이 가능함 - 작성자는 실제로 ARM64 리눅스에서 rustc를 돌리면서 x86 Plan 9 가상머신용 작은 Rust 프로그램을 컴파일해봤다고 함 ```mermaid sequenceDiagram participant 개발자 participant 러스트컴파일러 participant 실리 participant 원격C컴파일러 participant 특이한플랫폼 개발자->>러스트컴파일러: Rust 코드 빌드 요청 러스트컴파일러->>실리: C 코드 생성 백엔드 호출 실리->>원격C컴파일러: 플랫폼 특성 확인용 증인 프로그램 전송 원격C컴파일러-->>실리: 타입 크기와 ABI 정보 반환 실리->>원격C컴파일러: 대상 플랫폼용 C 코드 전달 원격C컴파일러->>특이한플랫폼: 실행 가능한 결과물 생성 ``` ## 아직은 거칠지만, 방향은 선명함 - 이 프로젝트가 노리는 문제는 Rust의 오래된 약점 중 하나임 - 어떤 프로젝트가 C에서 Rust로 옮겨가면 “그럼 Plan 9 같은 플랫폼은?”이라는 반론이 늘 나옴 - LLVM이나 GCC가 없는 오래된 하드웨어, obscure 플랫폼은 Rust 지원에서 밀리기 쉬움 - cilly의 목표는 C 컴파일러만 있는 곳에도 Rust를 가져가는 것임 - 다만 지금 공개된 건 안정적인 제품이 아니라 데모에 가까움 - 빌드에는 특정 nightly Rust, LLVM 라이브러리, GCC, GNU make가 필요함 - 최적화는 켜지 말라고 권장함. 최적화 관련 버그를 추적 중이고, 큰 Rust 파일에서 빌드가 막힐 수 있다고 함 - 빌드된 디렉터리 안에서 실행하면 경로 정규화 문제로 crash가 날 수 있고, 다른 위치에서는 괜찮다는 이상한 제약도 있음 - ABI 호환성도 ‘대부분’이라는 단서가 붙음 - 일반 rustc가 만든 코드와 대체로 ABI 호환이지만, 일부 플랫폼은 Rust ABI를 C로 표현하기 어렵다고 함 - 예를 들어 ARM64에서는 작은 구조체 반환에서 sret 포인터가 C 컴파일러가 고르는 방식과 맞지 않는 문제가 있음 - 이건 단순 번역기가 아니라 실제 컴파일러 백엔드가 얼마나 많은 플랫폼 디테일과 싸워야 하는지 보여주는 대목임 --- ## 기술 맥락 - cilly가 흥미로운 이유는 Rust의 프론트엔드와 분석 능력은 그대로 쓰면서, 마지막 코드 생성 경로를 C로 바꾸려 한다는 점이에요. LLVM이 없는 플랫폼에서도 C 컴파일러는 있는 경우가 많기 때문에, C를 중간 목적지처럼 쓰는 전략이 나오는 거예요. - 그런데 C로 내보낸다고 자동으로 이식성이 생기지는 않아요. C의 타입 크기, 정렬, 구조체 반환 규칙, 문자 인코딩은 컴파일러와 플랫폼마다 달라질 수 있거든요. 그래서 cilly는 증인 프로그램을 만들어 직접 물어보고, 그 결과에 맞춰 코드를 생성해요. - 네트워크로 C 컴파일러와 통신하는 설계도 부트스트랩 문제를 겨냥해요. 특이한 운영체제 위에서 rustc 전체를 돌리기 어렵다면, 강한 머신에서 rustc를 실행하고 대상 시스템에는 작은 C 컴파일 서버만 두는 식으로 우회할 수 있어요. - 가장 큰 트레이드오프는 생성된 C가 범용 산출물이 아니라는 점이에요. 특정 플랫폼의 ABI와 컴파일러 성질에 맞춰 나온 코드라서, 다른 아키텍처에 그대로 들고 가는 방식은 어렵지만, 대신 정말 이상한 타깃까지 맞출 여지를 얻어요. ## 핵심 포인트 - crustc는 C 코드와 일부 사전 빌드된 C++ LLVM 래퍼로 구성된 동작 가능한 Rust 컴파일러 데모 - cilly는 Rust 코드를 C로 바꾸는 컴파일러 백엔드이며, 대상 C 컴파일러와 플랫폼의 타입 크기·정렬·문자 인코딩·정수 표현을 ‘증인 프로그램’으로 조사 - 네트워크 너머의 C 컴파일러와 TCP로 통신해, 로컬 rustc가 원격의 특이한 운영체제용 C 컴파일러를 사용할 수 있음 - 작성자는 이 프로젝트가 3년간의 14번째 시도이며, 아직 공개 소비용으로 안정화되지는 않았다고 밝힘 ## 인사이트 이건 ‘Rust를 C로 바꿔봤다’ 수준보다 훨씬 흥미로움. Rust의 약점으로 자주 나오는 ‘LLVM이 안 가는 플랫폼은 어쩔 건데?’에 정면으로 들이받는 프로젝트라서, 완성도가 올라가면 레거시·임베디드 쪽에서 꽤 큰 얘기가 될 수 있음.