25년간의 Linux 커널 개발 경험에서 얻은 9가지 교훈에 대한 간략한 토론

원문: 25년간의 Linux 커널 개발에서 얻은 9가지 교훈
작성자: Greg Kroah-Hartman
번역: 옌징한

리눅스 커널 커뮤니티는 2016년에 창립 25주년을 맞이했는데, 많은 사람들이 우리에게 프로젝트의 장수와 성공 비결을 묻기 위해 찾아왔습니다. 저는 보통 웃으면서 농담으로 25년이 흘렀는지 정말 몰랐다고 합니다. 이 프로젝트는 항상 의견 차이와 어려움에 직면해 있었습니다. 그러나 진지하게, 이를 수행하는 우리의 능력은 커뮤니티의 반영 및 변화 능력과 많은 관련이 있습니다.

약 16년 전, 대부분의 커널 개발자들은 서로 만난 적이 없었고 이메일로만 소통했습니다. 그래서 Ted T'so가 커널 서밋 아이디어를 생각해 냈습니다. 이제 매년 커널 개발자들이 함께 모여 기술적인 문제를 해결하고, 더 중요하게는 지난 한 해 동안 우리가 잘한 것과 잘못한 것을 검토합니다. 개발자는 서로 통신하는 방법과 개발 프로세스가 어떻게 작동하는지 공개적으로 논의할 수 있습니다. 그런 다음 프로세스를 개선하고 Git과 같은 새로운 도구를 개발하며 협업 방식을 지속적으로 변경할 것입니다.

Linux 커널 성공의 주요 이유를 모두 완전히 이해하지는 못했지만 여전히 공유할 만한 몇 가지 경험이 있습니다.

1. 출시 주기를 단축하는 것이 중요합니다

Linux 프로젝트 초기 단계에서는 커널의 각 주요 버전이 출시되기까지 수년이 걸렸습니다. 이는 사용자가 새로운 기능을 즐기기 위해 오랜 시간을 기다려야 했다는 것을 의미했으며 이는 사용자와 리셀러에게 상당히 실망스러운 일이었습니다. 그리고 더 중요한 것은 이렇게 긴 주기는 한 번에 많은 코드를 통합해야 한다는 것을 의미합니다. 너무 많은 코드를 하나의 버전으로 통합하는 것은 스트레스를 줍니다.

더 짧은 주기로 이러한 모든 문제를 해결할 수 있습니다. 새로운 코드는 더 짧은 시간에 안정 버전에 통합될 수 있습니다. 새 코드를 거의 안정적인 기준 버전에 통합하면 시스템에 미치는 영향을 최소화하면서 근본적인 변경 사항을 도입할 수 있습니다. 개발자는 이번 릴리스 주기를 놓치면 두 달 후에 또 다른 릴리스 주기가 있다는 것을 알고 있으므로 조기에 코드를 병합하는 경우는 거의 없습니다.

2. 프로세스 확장에는 분산 계층 개발 모델이 필요합니다

오래 전에는 모든 변경 요청이 Linus Torvalds에게 직접 전달되었지만 운영 체제 커널만큼 복잡한 프로젝트를 누구도 완전히 이해할 수 없기 때문에 이는 곧 부적절한 것으로 판명되었습니다. 아주 초기에, 커널의 다양한 영역의 관리자들은 해당 영역에 익숙한 사람들에게 커널의 ​​일부를 할당한다는 아이디어를 내놓았습니다. 예를 들어 네트워킹, 무선, PCI나 USB 같은 드라이버 하위 시스템, ext2나 vfat 같은 파일 시스템 등이 있습니다. 그런 다음 코드 검토 및 통합을 담당하는 수백 명의 관리자로 확장되어 제품 품질을 저하시키지 않고 각 릴리스에 수천 개의 변경 사항을 포함할 수 있습니다.

3. 도구의 중요성

커널 개발은 소스 코드 관리 시스템인 BitKeeper가 등장하기 전까지 개발자의 범위를 확장하려고 노력해 왔으며, 커뮤니티의 관행은 거의 하루아침에 바뀌었고 Git의 등장은 또 다른 도약을 가져왔습니다. 올바른 도구가 없으면 커널과 같은 프로젝트는 제대로 작동하지 않고 자체 무게로 인해 무너질 것입니다.

4. 강력한 여론 지도 모델이 매우 중요합니다

일반적으로 선임 개발자가 제출된 변경 사항을 거부하면 변경 사항이 병합되지 않습니다. 개발자가 몇 달 전에 제출한 코드가 메일링 리스트에서 거부되었다는 사실을 알게 되면 매우 당황스럽습니다. 그러나 이는 또한 커널 개발이 수많은 사용자와 문제에 적응할 수 있도록 보장합니다. 어떤 사용자 커뮤니티도 다른 그룹을 희생시키면서 변경할 수 없습니다. 우리는 마이크로시스템부터 슈퍼컴퓨터까지 모든 것을 지원할 수 있는 코드 베이스를 보유하고 있으며 다양한 시나리오에 적용할 수 있습니다.

5. 강력한 '반품 불가' 규칙도 중요합니다

약 10년 전, 커널 개발 커뮤니티에서는 특정 커널이 특정 환경에서 제대로 실행되면 모든 후속 커널 버전도 해당 환경에서 제대로 실행될 것이라고 약속했습니다. 커뮤니티에서 변경으로 인해 다른 문제가 발생했다는 사실을 발견하면 신속하게 문제를 해결합니다. 이 규칙은 시스템 업그레이드로 인해 원래 시스템이 파괴되지 않을 것임을 사용자에게 약속합니다. 따라서 관리자는 새로운 기능을 개발하는 동안 이 커널을 계속 사용할 의향이 있습니다.

6. 개발 과정에 기업이 참여하는 것이 중요하지만, 어느 기업도 커널 개발을 주도할 수는 없습니다

2014년 12월 커널 버전 번호 3.18이 출시된 이후 약 500개 회사에서 약 5062명의 개인 개발자가 Linux 커널에 기여했습니다. 대부분의 개발자는 자신의 작업에 대한 대가를 받으며, 그들이 수행하는 변경 사항은 자신이 일하는 회사에 도움이 됩니다. 그러나 어떤 회사라도 특정 요구에 따라 커널을 개선할 수는 있지만, 어떤 회사도 다른 회사에 해를 끼치거나 커널의 기능을 제한하는 일을 개발을 주도할 수는 없습니다.

7. 프로젝트에는 내부 경계가 없어야 합니다

커널 개발자는 커널의 특정 부분에 집중해야 하지만, 수정이 정당하다면 모든 개발자는 커널의 어떤 부분이라도 수정할 수 있습니다. 결과적으로 문제가 발생하면 해결되기보다는 문제가 해결됩니다. 개발자들은 커널 전체에 대해 다양하고 다양한 의견을 가지고 있으며, 가장 완고한 유지관리자조차도 특정 하위 시스템에서 필요한 개선을 무한정 보류할 수는 없습니다.

8. 중요한 기능이 조금씩 시작됩니다

원래 버전 0.01 커널에는 코드가 10,000줄밖에 없었습니다. 이제 이틀마다 10,000줄 이상이 추가됩니다. 개발자가 현재 추가하는 일부 기본적이고 작은 기능은 향후 중요한 하위 시스템으로 성장할 수 있습니다.

9. 정리하자면, 25년간의 커널 개발 역사는 지속적인 협력이 단일 그룹으로는 개발할 수 없는 공통 자원을 가져올 수 있음을 보여줍니다

2005년부터 1,300개 이상의 회사에서 약 14,000명의 개인 개발자가 커널에 기여했습니다. 따라서 리눅스 커널은 치열한 경쟁을 벌이는 수많은 기업들의 노력을 통해 대규모 공공자원으로 발전하게 되었다.

위 내용은 25년간의 Linux 커널 개발 경험에서 얻은 9가지 교훈에 대한 간략한 토론의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!