▲

Git: Rust 도입 및 빌드 시스템에서 필수화 발표

 (lore.kernel.org)
8P by GN⁺ 18시간전 | ★ favorite | 댓글 1개
  • Git 프로젝트는 앞으로 Rust를 코어에 도입하고, Git 3.0부터는 Rust가 빌드 필수 요건이 될 것임을 공식 발표
  • 이번 패치 시리즈는 과거 C99 기능 도입처럼 시험적 도입(test balloon) 성격으로 진행되며, Rust 도입 인프라를 점진적으로 마련하는 목적
  • 첫 단계로 의존성이 거의 없는 varint.c 모듈을 Rust로 변환하여 C-Rust 상호운용성과 빌드 툴링을 검증함
  • 현재는 Meson 빌드만 지원하며, 향후 Makefile 지원과 CI에서 Rust 빌드 검증 및 cargo format 기반 포맷 일관성 검사를 추가할 예정
  • 이는 Git 커뮤니티와 배포자들에게 새로운 Rust 툴체인 요구사항에 적응할 시간을 주면서, 장기적으로 코드 안전성과 확장성을 높이는 중요한 변화임

Rust 도입 배경

  • Git은 안정성과 유지보수를 위해 언어적 진화를 검토해왔음
  • Rust 도입은 메모리 안전성 강화, 현대적 툴체인 활용, 성능 최적화 가능성 확보라는 의미가 있음
  • 아울러 현대적인 언어 도입을 통해 보다 견고한 코드베이스를 구축하고자 함
  • Git 3.0 릴리스 시점에는 Rust가 반드시 필요해짐을 사전 공지하여 생태계 준비 시간을 확보하려는 목적
  • 단계적으로 Rust 코드 적용 범위를 확대하며, 궁극적으로 일부 핵심 기능도 Rust로 재구현할 방침

시험적 패치 시리즈

  • Rust 첫 적용 모듈로 varint.c를 선택
    • 매우 단순하고 의존성이 없음
    • C ↔ Rust interop 검증 가능
    • Git 전체 기능에 영향 없이 실험 가능
  • 모든 테스트는 varint.rs 버전에서 통과함

빌드 시스템 변화

  • 현재는 Meson 빌드 시스템에서만 Rust 지원 추가
  • 향후 Makefile에도 Rust 지원을 추가할 계획임
  • CI 관련 작업도 준비 필요
    • Rust 빌드 및 동작 검증
    • cargo format을 통한 코드 스타일 일관성 확보
    • 기타 툴링 및 유지보수 자동화

향후 계획

  • 이번 작업은 Rust 기능 자체보다 도입 프로세스 실험에 초점이 있음
  • 이후에는 xdiff 모듈을 포함해 더 많은 Git 내부 기능을 Rust로 재작성할 수 있음
  • Rust를 점진적으로 확장 적용하면서 생태계 전체가 Rust 기반 빌드 환경에 적응하도록 유도할 예정

시사점

  • Git은 역사상 가장 중요한 언어적 전환을 준비 중임
  • Rust 필수화를 통해 안전성·유지보수성·장기적 발전 가능성을 확보할 수 있음
  • 배포자 및 개발자들은 향후 Git 생태계에서 Rust 개발 환경 구축이 필수가 될 것임
▲
GN⁺ 18시간전  [-]
Hacker News 의견
  • 다른 스레드에서 Rust를 필수로 도입하자는 논의에 대해, 작성자는 Rust를 바로 필수로 만들기보다 선택적 종속성으로 도입했다가, 나중에 gcc에서 Rust 지원이 추가된 시점에 필수로 바꾸는 게 낫다는 의견을 냄
    관련 논의 링크
    • gcc 컴파일러는 일관성이 떨어진다는 점을 강조함, 예를 들어 gcj(Java용 gcc)는 거의 아무도 사용하지 않음
      Rust 지원도 표준이 없는 언어이다 보니 시간이 지나면 구현이 많이 뒤처지는 일(과거 Java에서처럼)이 생길 것 같다는 의심을 함
  • 왜 Git에 Rust를 도입하려는지 궁금함
    Git은 이미 완성도가 높은 도구로 보이고, 유지보수나 개선 정도만 필요할 뿐, 새로운 언어를 도입할 만큼 대규모 신규 코드가 필요해 보이지 않음
    Linux처럼 계속 새로운 드라이버가 필요한 경우와 달리 Git에는 그럴만한 이유가 보이지 않음
    내가 놓치고 있는 게 있는지 설명해 줄 사람을 원함
    • Git은 눈에 띄지는 않지만 지속적으로 기능이 추가되고 있음
      Git의 변경사항은 RelNotes에서 확인하거나, GitHub 블로그의 Git 카테고리에서 좀 더 보기 쉽게 볼 수 있음
    • jj나 git-branchless 같은 도구를 써보면 git이 완성되었다는 생각이 달라짐
      git-branchless의 경우 Rust로 작성된 메모리 내 병합 등의 기능이 있음
    • 이 글에 여러 답변이 있으니 참고할 만함
      Rust 관련 내용은 해당 메일링 리스트에서 더 찾아보면 됨
      (찬반 평가를 직접 하는 건 아니고, 누군가는 해줄 것이라 이야기함)
    • 오래된 C 프로젝트는 개발자 유입이 점점 줄어드는 중임
      C로 Git을 개발하고 싶은 사람은 거의 없는 반면, Rust로의 재작성에 관심 있는 개발자들은 합류에 열의가 있음
    • C는 안전하지 못함
  • 왜 Rust를 계속 여러 곳에 도입하려는지 의문임
    Git은 완성도가 높아 새로운 코드도 많지 않게 추가될 것 같음
    Rust는 C에 비해 훨씬 복잡함
    정말 객체지향 기능이 필요하다면 C++98 정도만 사용해도 최근 C++이나 Rust보다는 훨씬 간단하고 이해하기 쉬움
  • 제목이 다소 오해를 주는 표현임
    Rust가 향후 패치에 필수가 아니라, 빌드 시스템 내에서 필수가 될 예정임
    • 고마움을 표시하며, 제목에 해당 내용을 반영했다고 얘기함
      만약 틀리다면 다시 수정 가능함
    • 이게 무슨 의미인지 되묻는 질문이 이어짐
      빌드 시스템 자체를 빌드는 데 필요한 건지, 아니면 애플리케이션 빌드에도 필수인지 궁금함
  • 나이가 좀 있어서 변화를 받아들여야 할 시점이라 생각하면서도, 기존에는 C만 알면 Git이나 커널 개발에 참여할 수 있었는데 이제 Rust도 추가로 알아야 하고, 툴체인이 점점 복잡해지는 게 진입장벽을 높인다는 불만이 있음
    Git에 깊이 투자하고 여러 프로젝트를 만들었는데, Git의 해킹 가능성을 잃고 싶지 않음
    • 새로운 걸 배우기 싫어하는 태도는 이 업계에서 적합하지 않다고 생각함
      실제로 Rust는 일반적인 C(특히 버그가 많은 C)보다 배우기 쉽고, Git이나 Linux 소스코드를 익히는 것보다는 확실히 더 쉬움
    • Git 클라이언트와 웹 서버를 직접 만들었다 해도, Git 저장소 포맷은 변경되지 않으니 해킹 가능성에 영향 없을 것임
    • 참고로 Git은 이미 여러 언어로 이뤄져 있음
      GitHub 기준 C 50%, Shell 38%, Perl 4%, 그 나머지는 TCL/Python 등임
      Perl/TCL이 오히려 더 예외적임
      프로젝트가 성장하면서 여기저기 덧붙인 해킹 코드들이 많았고, 이제는 안전성/성능 개선 및 옛 해킹 코드 정리가 필요한 시점임
      Rust는 이에 적합하다고 생각함
    • 소프트웨어 엔지니어라면 여러 언어를 충분히 다룰 줄 아는 것이 보통이므로, 언어 추가는 큰 문제가 아님을 밝힘
    • 나를 비롯해 젊은 개발자 중 Rust를 선호하고 C를 배우고 싶지 않은 사람이 많음
      Git이 Rust를 일부 사용한다고 내가 직접 만든 Git 클라이언트나 서버 개발에 방해가 되지는 않을 거라 생각함
  • Rust 도입이 일부 플랫폼에서는 불가능하고, 다른 곳에서도 어렵다는 의견에 추가 설명 요청이 있음
    • Linux 시스템에서는 어떤 라이브러리든 시스템 라이브러리로 사용해야 하지만, Rust는 안정적인 ABI가 없어서 진짜 공유 라이브러리로 쓸 수 없음
      Debian 릴리스 노트에서도 Rust/Go 패키지 관련 이슈를 명시함
      Rust 패키지를 빌드할 때 정적 링크 문제로 자주 재빌드해야 해서, 실사용에는 불편함이 발생함
      Linux OS에서는 반드시 필요한 안정적 ABI/공유 라이브러리 문제를 Rust 측에서 외면하면 오히려 C보다 더 많은 불만을 만들 수 있음
      대형 소프트웨어 아키텍처에는 좀 더 신중해야 한다고 생각함
    • 드러나지 않은 독점 플랫폼에서는 자체적으로 C 컴파일러를 지원하지만 LLVM 지원이 불가능함
      NonStop 키워드를 이 글에서 검색해 보면 사례를 알 수 있음
    • Rust 컴파일러가 어떤 플랫폼(OS/아키텍처 조합)을 지원하지 않기 때문임
      RESF 등에서는 "플랫폼이 Rust를 지원하지 않는다"고 표현하지만, 실제로는 Rust 컴파일러가 지원해야 진짜 동작함
    • Rust는 LLVM 기반이라 GCC가 지원하는 플랫폼보다 제한적임
    • Rust 공식 문서의 플랫폼 지원 목록에서 'Tier 3' 항목을 참고하라고 안내함
  • git 3.0에서는 어떤 변화가 있을지 궁금함
    git은 2.x로 안정화된 느낌이라 호환성을 깨뜨릴 이유가 없어 보임
    • git 3.0 Breaking Changes 문서를 참고하라는 답변이 이어짐
    • 기본 해시 함수가 SHA-256으로 바뀔 예정임
  • 과거에는 크로스 컴파일 환경에서 빌드, 실행, 코드 편집이 달라지는 상황을 I 기본 전제로 삼았음
    근래 개발 문화는 이런 툴체인 사용법에서 멀어진 것 아닌가 하는 의문이 있음
    소스 컨트롤, 빌드, 실행 환경이 서로 달라 리모트 복사나 원격 실행이 필요했고, 빌드 규칙에도 타겟 플랫폼 감지가 필수였음
    • 오히려 Rust 툴체인은 어떤 컴파일 언어보다 크로스컴파일이 쉽다고 느낌
      --target 플래그 하나로 약 100여 개 플랫폼을 별다른 이슈 없이 빌드할 수 있음
      실제 문제는 일부 Git 개발진이 각자 오래된/고정된 개발 머신 제한을 고수하기 때문으로 봄
    • 대부분 개발자는 실제로 크로스컴파일을 충분히 배우지 않았다고 생각함
      크로스컴파일은 언제나 2등 시민이고 외부 프로젝트에선 정상 동작을 아예 기대하지 않음
      Linux 배포판도 Raspberry Pi 등은 실제 하드웨어에서만 빌드하도록 하는 경우가 있음
      이런 이유로 아무도 이를 제대로 지원할 노력을 하지 않음
    • Rust/Y너와 무관하게 오늘날 크로스컴파일 상태는 ‘재앙’에 가깝다고 봄
      Linux가 특히 심각한데, glibc 구조가 낡아버려서 어느 하드웨어에서도 최소 glibc 타겟팅이 어렵게 됨
      대부분의 프로젝트는 크로스컴파일 지원 자체를 시도조차 하지 않음
      Zig는 이를 개선하고자 노력 중임
  • gcc 관련 Rust 프론트엔드가 충분히 성숙할 때까지 도입을 미루는 게 낫다고 주장함
    Git은 프로젝트 핵심 도구이므로, 변화가 위험 부담이 크고 6개월처럼 짧은 시간 내에 필수 의존성으로 삼는 것은 위험하다고 봄
  • Rust는 함수형 언어와 비슷하게 학습곡선이 크고 복잡함
    이 복잡도는 컴파일 타임에 더 많은 오류를 잡기 위한 목적이지만, 그 결과 언어 자체가 상당히 복잡해짐
    이런 점에서 도입을 추천하지 않음
    커널도 마찬가지로 Rust 도입을 거부했다고 알고 있음
    이미 복잡한 커널에 Haskell 급 타입시스템과 Lisp 수준 매크로 시스템까지 추가하면 복잡성이 늘어남
    serde를 통한 Rust 코드 추적은 어려움
    이와 달리 Go의 Unmarshal은 추적이 훨씬 쉬움
    • 나는 오히려 함수형 언어와 Rust가 C나 Go보다 더 명확하다고 느낌
      컴파일러에 더 많은 정보를 실어둘 수 있어서임
      Serde에서 크게 문제를 겪은 적은 없고, 오히려 Go의 Unmarshal을 디버깅하는 일이 더 많았음
      커널이 Rust를 거부했다는 주장도 실제로는 두 개발자 사이에 헤더 저장 위치를 두고 충돌한 거였음
    • C는 단순하지만, 안전하고 성능 좋은 C는 굉장히 복잡함
      Rust는 진입장벽은 C보다 높지만, '최소한의 Rust'와 '빠르고 안전한 Rust' 사이의 격차는 C에 비해 훨씬 작음
    • Rust는 복잡하다고 했지만, C 역시 만만치 않게 복잡함을 지적함
    • 이런 컴파일 타임 체크의 편의성이 Rust의 차별점임
      borrow checker만큼 중요하게 봄
    • Typescript 경험이 있고, Linter로 참조나 Result 언래핑/에러처리를 익힌 사람에게 Rust는 꽤 배우기 쉬움
      문법도 관대함
      Linux 커널은 실제로 Rust를 거부하지 않았음
답변달기