리누스 토발즈는 리눅스 커뮤니티를 뒤흔든 결정을 내렸습니다. 바로 메인 리눅스 커널에서 Bcachefs 파일 시스템을 제거하는 것이었습니다. 거의 10년에 걸친 개발과 몇 달간의 긴장 끝에, 곧 출시될 6.18 커널 버전에는 더 이상 Bcachefs 코드가 단 한 줄도 포함되지 않았습니다. 이 하이브리드 시스템을 리눅스 스토리지의 미래로 여겼던 사람들에게는 엄청난 타격이었습니다. 하지만 이 논란의 여지가 있는 결정의 이면에는 이해할 만한 기술적, 인간적 이유가 있습니다. 리누스 토발즈와 리눅스 커널에 대한 엄격한 통제 리누스 토발즈의 업무는 코드 작성에만 국한되지 않습니다. 그는 운영 체제의 핵심을 감독하며, 각 추가 기능이 GNU/리눅스 프로젝트의 매우 엄격한 표준을 충족하는지 확인합니다. 이 핵심 요소인 커널은 안정적이고 효율적이며 일관성을 유지해야 합니다. 6.7 버전에서 실험적으로 도입된 Bcachefs의 기여는 곧바로 뜨거운 논쟁을 불러일으켰습니다. 리누스 토발즈는 높은 기준을 가진 것으로 유명합니다. 그는 개발 과정에서 발생하는 불규칙적인 동작을 거의 용납하지 않습니다. 그러나 Bcachefs 개발은 종종 규칙에서 벗어나곤 했습니다. 개발자인 켄트 오버스트리트는 정해진 기간 외에 패치를 제출했고, 다른 커널 기여자들과 항상 협력하지는 않았습니다. 이러한 긴장된 상황으로 인해 6.17 버전에서 Bcachefs가 빠르게 동결되었다가 6.18 버전에서 완전히 삭제되었습니다. 토발즈에게 이는 프로젝트 자체를 거부하는 것이 아니라, 리눅스의 상당 부분을 관리하는 데 있어 규율을 유지하기 위한 방편이었습니다. 커널 안정성은 타협할 수 없는 이유 리눅스 커널은 데비안, 우분투, 레드햇 등 모든 배포판의 기반입니다. 모든 사용자, 관리자, 또는 회사는 커널의 절대적인 안정성에 의존합니다. 불안정한 파일 시스템은 데이터 손실, 심각한 충돌, 그리고 보안 위협을 초래할 수 있습니다.
Bcachefs는 인상적인 기술적 진보에도 불구하고 여전히 실험적인 버전으로 간주되었습니다. 안정성이 구현되는 데 시간이 걸렸고, 공식 릴리스에 통합될 경우 커널에 대한 사용자의 신뢰가 훼손될 위험이 있었습니다. 이 점은 Bcachefs 제거를 정당화하는 주요 논거였습니다.
Bcachefs: 야심 차지만 논란의 여지가 있는 파일 시스템 Bcachefs는 Ext4, Btrfs, XFS와 같은 기존 시스템의 여러 장점을 결합한 하이브리드 파일 시스템으로 설계되었습니다. 향상된 성능과 견고성을 갖춘 고급 스토리지 관리 기능을 제공한다는 목표였습니다. 개발자가 사실상 단독으로 프로젝트를 진행했기 때문에 초기에는 개발 속도가 더뎠습니다.수년간의 개발에도 불구하고 Bcachefs는 메인 커널의 실험 단계를 넘어서지 못했습니다. 호환성 문제, 버그, 그리고 실험 버전을 완전히 통합된 구성 요소로 변환하는 데 어려움을 겪는 경우가 많았습니다. 일부 개발자는 Bcachefs의 혁신적인 아키텍처, 특히 COW(Copy-On-Write) 방식을 칭찬했지만, 다른 개발자는 만성적인 불안정성과 충분한 커뮤니티 지원 부족을 비판했습니다. 코드 관리 및 작업 방식을 둘러싼 충돌토르발스와 켄트 오버스트리트 간의 갈등은 중요한 전환점이었습니다. 기능 통합 지연과 관리 부실한 롤백을 둘러싼 여러 논쟁이 벌어졌습니다. 오버스트리트는 긴밀한 협력 없이 다른 코드를 변경했다는 비판도 받았습니다.
이러한 논쟁의 이면에는 리눅스 커널의 거버넌스 방식 자체가 부각됩니다. 바로 협력적이면서도 엄격한 모델로, 각 변경 사항은 일련의 내부 검증을 통과해야 합니다. 때로는 어렵게 여겨지는 이러한 엄격함이 리눅스의 장기적인 성공과 안정성의 원천입니다. 토발즈가 반복적인 편차를 용납하지 않자 Bcachefs 프로젝트는 외부 확장 기능으로 전락했고, 현재는 DKMS를 통해 커널 외부에서 관리되고 있습니다. Bcachefs를 DKMS 외부 모듈로 전환
다행히도 Bcachefs 마니아 사용자들에게는 Bcachefs가 완전히 폐기된 것은 아닙니다. DKMS(동적 커널 모듈 지원)를 통해 코드가 외부 모듈로 작동하도록 조정되었습니다. 이러한 접근 방식을 통해 Bcachefs는 6.16 버전부터 다양한 Linux 커널에 설치 및 유지 관리될 수 있습니다.
DKMS는 이미 Debian, Ubuntu, Red Hat과 같은 인기 배포판에서 독점 드라이버(예: Nvidia 카드용 드라이버)를 관리하는 데 널리 사용되고 있습니다. 새 커널을 설치할 때 재컴파일을 통해 자동 모듈 업데이트를 지원합니다.
하지만 외부 모듈 모드로 전환하는 데는 어려움이 따릅니다. 각 배포판에 맞는 특정 조정이 필요하며, 커널 인터페이스의 진화에 따라 달라집니다. 재컴파일 실패로 인해 시스템 부팅이 불가능해질 수 있으며, 특히 모듈이 부팅에 필수적인 경우 더욱 그렇습니다. Linux 배포판 및 사용자에게 미치는 영향 시스템 관리자와 리눅스 마니아들은 이러한 변화에 더욱 주의를 기울여야 합니다. DKMS를 통해 Bcachefs를 유지 관리하려면 모듈 업데이트를 정기적으로 통합하고, 각 커널 버전과의 호환성을 모니터링하며, 문제 발생 시 대체 솔루션을 제공해야 합니다. 주요 배포판들은 이러한 변화를 다소 조심스럽게 받아들였습니다. 데비안과 우분투는 이미 Bcachefs용으로 검증된 DKMS 패키지를 제공하고 있습니다. 페도라는 아직 통합을 시험하고 있습니다. OpenSUSE는 여러 가지 수정이 필요하다는 이유로 여전히 망설이고 있습니다.이러한 외부 지위로의 전환은 강력한 신호를 보냅니다. Linux는 오픈 소스이지만, 파일 시스템을 커널에 영구적으로 통합하려면 완벽한 안정성과 거버넌스가 필요합니다. Linux 생태계에서 Bcachefs의 미래와 교훈 Bcachefs가 Linux 커널에서 제거되었다고 해서 끝이 아니라, 양보다질이 중요하다는 것을 다시 한번 일깨워주는 계기가 될 것입니다. 파일 시스템 개발은 수년간의 테스트, 개선, 그리고 통합이 필요한 복잡한 작업입니다.
Google, Meta, Red Hat과 같은 주요 업체들은 Ext4, Btrfs, XFS 개선을 위해 수백만 달러를 R&D에 투자하고 있습니다. Bcachefs의 과제는 커뮤니티를 설득하고 코드베이스를 안정화하여 언젠가 메인라인 커널로 복귀하는 것입니다.
효율적인 혼합 데이터 관리라는 개념 자체는 유망합니다. 내부 메커니즘이 안정적으로 구축된다면 광범위한 사용자에게 어필할 수 있을 것입니다. 하지만 현재로서는 Bcachefs는 헌신적인 커뮤니티와 효율적인 유지 관리자의 지원을 받으며 커널 밖에서도 계속 발전해야 합니다.
마지막으로 중요한 점은, 이 에피소드가 모든 코드 줄 뒤에 숨겨진 인간적인 측면을 다시 한번 일깨워준다는 것입니다. 리누스 토발즈와 켄트 오버스트리트 뒤에는 때로는 상반된 비전을 가진 사람들이 있습니다. 그들은 남들과는 다른 소프트웨어를 만드는 데 참여하고 있습니다. 리눅스의 역사 또한 이러한 열정, 갈등, 그리고 성공에 필수적인 엄격함의 일부입니다.
Comments
Leave a comment