▲

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

 (source.dev)
3P by GN⁺ 24시간전 | ★ favorite | 댓글 1개
  • 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 등) 는 일부 빌드 단계만 가속화하고 체크아웃에는 효과 없음
    • 명령행 플래그 파싱에 의존해 예상치 못한 오류 발생 가능성 존재

향후 계획

▲
GN⁺ 24시간전  [-]
Hacker News 의견

  • 팀 일부가 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나 git fuse류를 제품화하려는 건가 싶음

    • 빌드 단계를 시스템 독립적으로 캐싱한다고 주장함
      “이전과 동일한 빌드 단계는 자동으로 건너뛰고 결과를 재사용한다”는 식인데, 너무 좋아 보여서 오히려 믿기 어려움
    • 결국 빌드 출력 캐싱을 좀 더 확장한 형태로 보임

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

    • 하지만 이런 기본 팁들은 이 제품이 주장하는 문제를 해결하지는 못함

  • 안녕하세요, Source.dev 공동창업자 Serban임
    업보트와 토론에 감사함. 초기 스타트업에게 이런 피드백은 정말 큰 힘이 됨
    우리가 만드는 게 진짜로 가치 있다고 느껴져서 기쁨

    • 흥미로워서 묻는데, 혹시 Python의 fabricate처럼 strace로 파일 접근을 추적하는 방식과 비슷한지 궁금함

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

  • 그들의 성능 주장이 내가 써본 분산 Android 빌드 시스템보다 훨씬 앞서 있음
    어떤 비밀 소스가 있는지 궁금함

    • 혹시 그냥 좀 더 화려한 ccache 수준인 건 아닐까 싶음

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

  • 설명을 보면 Android 소스 전용처럼 들림. 왜 그런지, 다른 코드베이스에도 적용 가능한지 궁금함

    • 내 이해로는, 이건 조직이 운영할 수 있는 가장 큰 빌드 머신의 메모리에 코드 전체가 안 들어가는 경우에만 의미가 있음
    • 페이지 자체에 그 이유가 잘 설명되어 있음
답변달기