# SourceFS - 가상 파일시스템으로 2시간 넘는 Android 빌드를 15분으로 단축

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

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=23887](https://news.hada.io/topic?id=23887)
- GeekNews Markdown: [https://news.hada.io/topic/23887.md](https://news.hada.io/topic/23887.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2025-10-24T15:24:13+09:00
- Updated: 2025-10-24T15:24:13+09:00
- Original source: [source.dev](https://www.source.dev/journal/sourcefs)
- Points: 4
- Comments: 2

## Topic Body

- SourceFS는 대규모 **디바이스 코드베이스의 빌드 속도와 효율성 문제**를 해결하기 위해 설계된 고성능 가상 파일시스템   
- **Android 빌드 속도를 최대 9배, 코드 체크아웃 속도를 10배 이상 향상**시키며, 디스크 사용량을 83% 줄이고 컴퓨팅 비용을 14배 절감  
- 핵심 원리는 **파일 가상화와 온디맨드(materialization)** 방식으로, 실제 파일처럼 보이지만 필요한 순간에만 내용을 불러오는 구조  
- 빌드 과정에서는 **입출력·환경을 기록하고 재사용하는 샌드박스 기반 캐싱**을 통해 대부분의 빌드 단계를 즉시 재생(replay)  
  
---  
  
### 느린 빌드와 코드 체크아웃의 문제  
- 현대의 연결된 디바이스는 **수억 줄 규모의 코드베이스**로 구동됨  
  - Linux 커널은 약 4천만 줄, Android AOSP는 1억4천만 줄 이상이며, 실제 디바이스는 하드웨어 지원·커스텀 기능·서비스 코드가 추가되어 2억 줄을 넘김  
  - 전기차(EV)는 5억 줄 이상에 달하며, 소프트웨어 업데이트로 지속적으로 증가  
- 코드 체크아웃 시 수백 GB의 데이터를 내려받고, 빌드는 수십만 단계를 거침  
  - 의존성 그래프의 불완전성으로 인해 작은 변경도 **대규모 재빌드**를 유발하거나 잘못된 결과를 초래  
- 결과적으로 **매일 수시간의 개발자 시간 손실**과 **CI 컴퓨팅 비용의 급증**이 발생  
  
### Source File System (SourceFS)  
- SourceFS는 **새로운 빌드 시스템이 아닌**, 기존 워크플로에 통합 가능한 **고성능 가상 파일시스템**  
  - Android 코드베이스의 체크아웃 및 빌드 속도를 획기적으로 향상시키며, **마이그레이션 부담이 거의 없음**  
  - 핵심 원리는 모든 파일을 가상화하고, 필요할 때만 실체화(materialize)하며, 이 과정을 **투명하게 처리**  
- **체크아웃 가속화**: 전체 코드베이스의 가상 파일 표현을 생성하고, 접근 시점에만 내용을 불러옴  
  - 파일은 실제처럼 보이지만, 대부분의 파일은 가상 상태로 남아 디스크 공간을 절감  
  - Git 및 Repo와 완전 호환  
- **빌드 가속화**: 각 빌드 단계는 **입출력·환경을 기록하는 경량 샌드박스**에서 실행  
  - 동일한 단계는 재실행 없이 결과를 재사용, 변경된 단계만 새로 수행  
  - 컴파일뿐 아니라 링크, 패키징, 문서 생성 등 전체 빌드 프로세스에 적용  
- 내부적으로 **고성능 캐싱·리플레이 알고리듬**, **효율적 샌드박싱**, **Rust 기반 백엔드**를 사용  
  - 거의 제로 오버헤드로 조직 전체에 확장 가능  
  
### 빠른 빌드, 효율적 저장소, 비용 절감  
- SourceFS 환경에서의 **코드 체크아웃은 기존 대비 20배 이상 빠름**  
  - 개발자는 기존 Git 트리와 동일한 워크플로를 유지하면서 SourceFS 폴더에서 작업 가능  
- **디스크 사용량 절감**은 다중 코드베이스를 전환해야 하는 디바이스 개발자에게 큰 이점  
  - 여러 디바이스 버전 간 전환이나 대규모 버그 수정 시에도 **소규모 GitHub 리포지토리처럼 가볍게 작업 가능**  
- **빌드 속도는 최대 9배 향상**, 일반 개발자 머신에서도 대규모 빌드를 신속히 완료  
  - CI 파이프라인의 피드백 루프 단축으로 **개발 생산성 극대화**  
- **비용 절감 효과**는 최대 14배에 달함  
  - 고성능 머신보다 일반 머신에서 SourceFS를 사용하는 편이 더 빠르고 저렴  
  - 동일한 컴퓨팅 예산으로 더 많은 작업 수행 가능  
  
### 기존 대안과의 비교  
- SourceFS는 기존 접근법의 한계를 극복  
  - **Bazel, Buck2 등 새로운 빌드 시스템으로의 마이그레이션**은 대규모 프로젝트에서 현실적으로 어렵고, 다중 OS(예: Yocto, Android, QNX)를 포함한 디바이스 코드베이스에서는 복잡성이 배가  
  - SourceFS는 이러한 마이그레이션 없이도 동일한 성능 향상을 제공  
- **컴파일러 래퍼(REClient, Goma 등)** 는 일부 빌드 단계만 가속화하고 체크아웃에는 효과 없음  
  - 명령행 플래그 파싱에 의존해 **예상치 못한 오류 발생 가능성** 존재  
  
### 향후 계획

## Comments



### Comment 45453

- Author: ganadist
- Created: 2025-10-25T17:09:46+09:00
- Points: 1

이미 안드로이드에서 유사한 걸 사용하는 것 같네요.  
  
* https://github.com/terraform-google-modules/terraform-google-abfs  
* https://docs.google.com/forms/d/e/1FAIpQLSe-nqkIEADve-JqOlJEZf4E1hOyx6FXUXeH6Y64vrW3qj45Ng/viewform

### Comment 45416

- Author: neo
- Created: 2025-10-24T15:24:14+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=45668160) 
- 팀 일부가 **ex-Googler** 출신인 것 같지만, 우리가 알고 있는 Piper 기반의 srcfs와는 다름  
  비슷한 점은 있지만 세부 정보가 거의 없고, **self-hosting 버전**도 “Talk to us” 식 가격 정책이라 아쉬움  
  - Google이나 Meta가 내부의 **magic VFS**를 오픈소스로 공개했으면 함. Meta의 EdenFS가 그나마 가장 가까움  
  - 이거 정말 익숙하게 느껴짐. commit deadbeef 시점에서 전체 트리를 materialize하지 않고도 monorepo의 일부만 빌드할 수 있었음  
    그리고 가격 얘기인데, 수십억 라인짜리 코드베이스를 다루는 팀이라면 “TalkToUs” 가격쯤은 감당 가능하지 않음?  
    Linux 같은 오픈소스도 내 노트북에서 잘 돌아감  

- 이걸 보니 예전 **ClearCase의 MVFS**가 떠오름  
  빌드 시 open(2), getenv(3) 같은 호출을 가로채서 어떤 툴이 어떤 환경에서 어떤 버전의 파일을 썼는지 모두 기록했음  
  동일한 조건이면 기존 결과를 **“winked-in”** 해서 재사용했고, 파일시스템 수준에서 버전 관리도 가능했음  
  예를 들어 file.c@@/trunk/branch/subbranch/3 같은 식으로 접근할 수 있었음  

- 제목에 나온 시간 수치가 좀 과장된 느낌임  
  혹시 [EdenFS](https://github.com/facebook/sapling/blob/main/eden/fs/docs/Overview.md)나 git fuse류를 제품화하려는 건가 싶음  
  - 빌드 단계를 **시스템 독립적으로 캐싱**한다고 주장함  
    “이전과 동일한 빌드 단계는 자동으로 건너뛰고 결과를 재사용한다”는 식인데, 너무 좋아 보여서 오히려 믿기 어려움  
  - 결국 빌드 출력 캐싱을 좀 더 확장한 형태로 보임  

- 그냥 **상업용 콘텐츠 마케팅**처럼 느껴짐. 기술적인 디테일이 거의 없음  
  예전에 빌드 엔지니어로 일했을 때 효과적이었던 몇 가지 팁을 공유하자면,  
  tmpfs에서 빌드하기, 큰 파일은 복사 대신 **symlink/hardlink** 활용, libeatmydata로 불필요한 I/O 줄이기,  
  그리고 교차 컴파일러를 잘 선택하는 것 등이 있었음  
  진짜 중요한 건 빌드 시스템을 최적화하고 **변하지 않는 중간 산출물 캐싱**을 잘 하는 것임  
  - 하지만 이런 기본 팁들은 이 제품이 주장하는 문제를 해결하지는 못함  

- 안녕하세요, Source.dev 공동창업자 **Serban**임  
  업보트와 토론에 감사함. 초기 스타트업에게 이런 피드백은 정말 큰 힘이 됨  
  우리가 만드는 게 진짜로 가치 있다고 느껴져서 기쁨  
  - 흥미로워서 묻는데, 혹시 Python의 **fabricate**처럼 strace로 파일 접근을 추적하는 방식과 비슷한지 궁금함  

- “SourceFS로 빌드 속도가 9배 빨라진다”는 문구를 보고 웃음이 나옴  
  빌드가 오래 걸릴수록 **검술 연습 시간**이 늘어나니까, 느린 빌드도 나름 장점이 있음  

- 그들의 **성능 주장**이 내가 써본 분산 Android 빌드 시스템보다 훨씬 앞서 있음  
  어떤 비밀 소스가 있는지 궁금함  
  - 혹시 그냥 좀 더 화려한 **ccache** 수준인 건 아닐까 싶음  

- 빌드가 “충분히 빠른” 수준에 도달하면, 코드베이스를 이해하기 위한 고통스러운 작업을 할 **비즈니스 동기**가 사라짐  
  이제 10억 라인짜리 코드베이스로 가는 길만 남았음  

- 설명을 보면 Android 소스 전용처럼 들림. 왜 그런지, 다른 코드베이스에도 적용 가능한지 궁금함  
  - 내 이해로는, 이건 조직이 운영할 수 있는 가장 큰 빌드 머신의 메모리에 **코드 전체가 안 들어가는 경우**에만 의미가 있음  
  - 페이지 자체에 그 이유가 잘 설명되어 있음