# krabby: 빠른 Rust 컴파일러 만들기

> Clean Markdown view of GeekNews topic #29230. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=29230](https://news.hada.io/topic?id=29230)
- GeekNews Markdown: [https://news.hada.io/topic/29230.md](https://news.hada.io/topic/29230.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-05-07T01:01:01+09:00
- Updated: 2026-05-07T01:01:01+09:00
- Original source: [bal-e.org](https://bal-e.org/speed/krabby/)
- Points: 1
- Comments: 1

## Topic Body

- **Krabby**는 `rustc`의 느린 컴파일 속도를 개선하려는 성능 우선의 **빈 슬레이트 Rust 컴파일러** 구현임
- `rustc`의 체감 성능 개선은 이제 단일 함수 변경보다 **API와 자료구조 변경**에서 나오지만, 큰 코드베이스와 안정성 요구 때문에 대규모 변경이 어려운 상태임
- Krabby는 한 사람이 통제하는 작은 코드베이스에서 안정성을 우선하지 않고 컴파일러 구성요소를 함께 다시 설계해 새로운 **최적화 기회**와 응집력 있는 아키텍처를 찾으려 함
- 목표는 컴파일러 성능을 크게 높이려면 설계를 완전히 다시 생각해야 한다는 가설을 Rust처럼 복잡한 언어에서도 시험하는 데 있음
- 코드는 [Codeberg의 krabby 저장소](https://codeberg.org/bal-e/krabby)에 공개되어 있으며, 진행 상황은 [Fediverse](https://tech.lgbt/@bal4e)에 1~2주에 한 번 이상 올리는 것을 목표로 함

---

### Krabby의 목표와 배경
- **Rust**는 선호하는 언어이지만 `rustc` 컴파일러는 눈에 띄게 느림
- `rustc` 성능 개선에는 이미 많은 사람이 노력 중이며, 단일 함수 변경으로 체감 성능을 올릴 수 있는 개선은 대부분 구현된 상태에 가까움
- 의미 있는 개선은 이제 **API와 자료구조 변경**에서 나오지만, `rustc`처럼 큰 코드베이스에서는 여러 기능 개발과 안정성 요구 때문에 대규모 변경이 사실상 어려움
- Krabby는 성능을 우선순위로 둔 **빈 슬레이트 Rust 컴파일러 구현**이며, `rustc`와 목표가 근본적으로 다름
- 작은 코드베이스를 한 사람이 통제하고 안정성을 우선하지 않기 때문에, 모든 구성요소를 서로 고려해 설계하면서 새로운 최적화 기회를 찾고 더 응집력 있는 아키텍처를 만들려는 접근임
- 컴파일러 성능을 크게 개선하려면 컴파일러 설계를 완전히 다시 생각해야 한다는 가설에서 출발함
- 대규모 아키텍처 최적화는 대상 언어와 관계없이 숨어 있을 수 있으며, 단순한 C 같은 언어뿐 아니라 Rust처럼 복잡한 언어에도 적용 가능하다는 점을 보이려 함
- 결과 설계가 Rust에 특화되더라도, 그 과정에서 배울 가치는 있다고 봄

### 프로젝트 상태와 공개 자료
- Krabby는 매우 큰 프로젝트이며, 완성 가능성이나 본인이 적임자인지는 확신하기 어려움
- 다만 코드 최적화와 완성도를 높이는 과정 자체를 좋아하고, 가치 있다고 여기는 목적을 위해 좋은 코드를 쓰는 즐거움이 현재까지 동력이 되고 있음
- 코드는 [Codeberg의 krabby 저장소](https://codeberg.org/bal-e/krabby)에 공개되어 있음
- 진행 상황은 [Fediverse](https://tech.lgbt/@bal4e)에 1~2주에 한 번 이상 올리는 것을 목표로 하며, 더 깊이 있는 긴 업데이트는 같은 사이트에 게시할 예정임
- 관심 있는 사람은 [메일로 연락](mailto:9kjg1pa9s5n7k5pe@bal-e.org)할 수 있음
- ## 관련 진행 글
  - [identifier interning in 2025](https://bal-e.org/speed/krabby/interning-in-2025): 2026년 4월 20일
  - [a year of krabby](https://bal-e.org/speed/krabby/a-year): 2026년 4월 12일
  - [introducing `takeaway`](https://bal-e.org/speed/krabby/takeaway): 2025년 8월 11일
  - [krabby: for context](https://bal-e.org/speed/krabby/for-context): 2025년 6월 1일
  - [krabby: proof of concept](https://bal-e.org/speed/krabby/proof-of-concept): 2025년 5월 17일
  - [krabby: the architecture](https://bal-e.org/speed/krabby/the-architecture): 2025년 4월 27일
  - [krabby: making an AST](https://bal-e.org/speed/krabby/making-an-ast): 2025년 4월 19일
  - [krabby: trying out parent ptrs](https://bal-e.org/speed/krabby/trying-out-parent-ptrs): 2025년 4월 12일
  - [krabby: motivations](https://bal-e.org/speed/krabby/motivations): 2025년 4월 5일

## Comments



### Comment 56965

- Author: neo
- Created: 2026-05-07T01:01:02+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/zrnuhi/krabby_making_fast_rust_compiler) 
- 다들 자기만의 **허영 라이선스**를 갖고 싶어 하는 듯함 https://codeberg.org/bal-e/krabby/src/commit/a8dbf1176d1676465a71184d1198f39a8fb434ad/LICENSE.md#keypunch-public-license-1-0-1
  - 취미 프로젝트라면 괜찮겠지만, 이 프로젝트가 진지한 쪽보다는 **캐주얼한 프로젝트**라는 신호가 되긴 함  
    이 라이선스는 개인·비상업 목적의 사용과 공유는 무료로 허용하지만, 그 위에 만든 소프트웨어도 같은 조건으로 공유해야 하고, 상업 목적은 30일 동안만 시험 사용 가능하다고 되어 있음  
    Codeberg가 프로젝트 라이선스에 대해 엄격한 libre/오픈소스 조건을 요구하는지 궁금함. Codeberg는 FOSS만 호스팅한다고 알고 있어서 **비상업 사용 제한**이 의외였는데, 최신 상황을 잘 못 따라가고 있을 수도 있음
  - 맞음, 나도 알고 있음... 라이선스 문제로 꽤 오래 고민해 왔고, 아직 혼자 작업 중일 때 **AGPL**로 바꾸는 걸 고려하고 있음

- Rust는 규모가 큼. 이 프로젝트는 “직접 웹 브라우저 만들기”보다는 약간 쉬워 보이지만, 그렇다고 쉬운 건 전혀 아님. 그래도 목표가 큰 점은 높이 삼  
  [krabby: motivations](https://bal-e.org/speed/krabby/motivations/)를 보면 속도가 이 프로젝트의 주된 이유처럼 보임  
  Rust에 대한 내 이해로는 타입 검사, 빌림 검사 등은 이미 매우 빠르고, 병목은 **코드 생성**이며 그중 상당 부분은 Rust 자체보다 LLVM과 관련되어 있음  
  요즘 [Cranelift](https://cranelift.dev/) 쪽은 어떻게 돌아가는지, 코드 생성 속도를 높이는 아이디어와 겹치는 부분이 있는지 궁금함
  - 그 전제는 rustc+LLVM의 전체 구조가 맞고, 이제는 **상수 계수**만 중요하다고 보는 것임  
    개인적으로는 컴파일 파이프라인을 전체로 보면 말이 잘 안 된다고 꽤 확신함. **MIR 전용 rlib**가 필요하고, 무한한 RAM 없이도 전체 세계 최적화를 할 수 있는 백엔드가 필요함([이 댓글](https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilation-times/15183/30) 참고)  
    “Codegen Unit”은 순전히 우발적 복잡성임
  - 무엇을 하느냐에 따라 다름: [Depends on what exactly you're doing](https://kobzol.github.io/rust/rustc/2024/03/15/rustc-what-takes-so-long.html)  
    특히 [libraries](https://kobzol.github.io/assets/posts/compile-sections/libraries.png)와 [binaries](https://kobzol.github.io/assets/posts/compile-sections/binaries.png)의 구체적 분해가 흥미로울 수 있음  
    LLVM이 빠른 편은 아니지만, rustc가 LLVM에 다소 **부풀려진 IR**을 넘기는 경향도 도움이 되지 않았던 것으로 기억함
  - 고마움 :) Rust 컴파일 시간에 대해 사람마다 관점이 꽤 다른 듯함. 어떤 사람은 **타입 검사**를 탓하고, 어떤 사람은 LLVM을 탓함  
    내 중기 목표, 즉 앞으로 약 5년 동안의 목표는 `cargo check`라서 코드 생성은 건드리지 않음  
    그래도 더 나은 병렬성, 진단 코드의 핫 경로 분리, 타입 검사와 빌림 검사 사이의 중복 작업 감소, 핵심 자료구조의 메모리 배치 개선 등에서 최적화 여지가 **아직 많다**고 봄  
    rustc 개발자들과 친해서 코드베이스의 여러 문제를 자주 듣는 점도 도움이 됨
  - rustc에는 [Cranelift backend](https://github.com/rust-lang/rustc_codegen_cranelift)가 있음
  - LLVM이 실제로 느린 부분처럼 보임. Zig 컴파일 시간 논의에서도 그런 양상을 봤고, 자체 호스팅 대응 구현은 LLVM보다 상당히 빠름[1](https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilation-times/15183/19)