리눅스 커널 패치가 소리 없이 사라지고 있다?

지난 몇 년간 IT 산업이 겪었던 여러 크고 작은 사건 중 혹독한 열병에 속하는 것들이 몇 가지 있다. 대표적인 것이 닷컴으로 대표되는 거품이었고, 같은 맥락에 위치한 리눅스의 부침이다. 최근 몇 년간의 리눅스 관련 보도를 주의 깊게 살펴본 사람이라면 ‘뜨고 지는’ 리눅스의 모습을 생생하게(?) 지켜봤을 것이다. 특히 미국 IT 경제와 동기화가 비교적 빠른 국내 IT 산업 역시 비슷한 열병을 앓았다는 것은 부인할 수 없는 사실이다.한편, 이런 사정을 아는지 모르는지 유럽과 중국, 남미에서는 오픈소스 소프트웨어 사용률이 점점 높아지고 있다. 중국 정부의 리눅스 ‘사랑’은 몇 년 전부터 잘 알려진 사실이지만, 독일에서도 독일 연방의회 전산시스템에 리눅스를 도입하는 것을 두고 독일 사민당과 자민당 의원이 참여하는 온라인 토론회까지 열리는 진풍경이 펼쳐지기도 했다. 비록 현실 시장에서 리눅스 비즈니스가 큰 성공을 거두지는 못했지만 이렇게 사람들의 기억에서 여전히 잊혀지지 않는 것은 수많은 리눅스 개발자들의 보이지 않는 노력 덕분일 것이다. 그러나 최근 리눅스 커널 개발 공동체에서 벌어지는 일련의 논쟁을 보면 앞으로 리눅스가 겪어야 할 도전은 산업적인 것이 아니라 공동체 내부에서 나올 것임을 암시하고 있다.리눅스 커널 개발 문제 많다?리눅스 커널(이하 커널) 공동체에서 최근 긴장을 불러일으킨 논쟁은 바로 커널 개발 과정과 방식에 대한 것이었다. 지난 2월 1일 ZDNet 보도에 소개된 것처럼 현재 커널은 크고 작은 문제와 이를 해결하기 위한 패치로 인한 스트레스가 꽤 높은 수준에 달했다. 롭 랜들리는 이 문제를 해결하기 위해 커널 메일링 리스트에 패치를 관리할 패치 펭귄을 제안했지만 반응은 그다지 좋지 않았다. 리누스 토발즈는 자신이 받아들이지 않은 패치는 정식으로 보내진 것이 아니거나 자신이 신뢰하는 사람이 보낸 것이 아니라고 대답했다. 그리고 리누스 토발즈가 신뢰하는 커널 서브시스템 책임자가 패치를 받아들이지 않았다면 그 패치는 문제가 많은 패치라는 것이다. 리누스 토발즈가 패치를 꺼리기(?) 시작한 것은 커널 2.4를 발표한 직후부터였다. 커널 개발 메일링 리스트에 보낸 메일에서 리누스 토발즈는 모든 패치는 주말에 몰아 작업하고 패치를 적용하기 위해 진지한 검토 과정을 거칠 것이며 따라서 커널 2.4는 이전 버전에 비해 적용되는 패치 수가 줄어들 것이라고 말했다. 역대 사고 기록 갱신(?)커널 2.4는 2.2처럼 많은 기능이 한꺼번에 추가되지는 않았지만 내부적으로 많은 변화가 있었고 2.5 이후 버전을 염두에 두고 튼튼한 기반 구조를 만드는 데 집중한 버전이었다. 하지만 리누스 토발즈가 자신한 것처럼 2.4는 그렇게 튼튼하지 않았다. 2.4는 실제로 버전마다 사고를 일으키는 진기록(?)을 세웠다. 조슈아 드레이크(Joshua Drake)는 자신이 겪은 2.4.6까지의 sync() 버그, 2.4.11까지의 VM 문제를 비롯해 2.4.15에서 발견한 파일 시스템에 손상을 입히는 버그에 대해 이야기한 후 “대형 서버들에 있어서 커널 2.4는 재앙과도 같다”며 커널 2.4의 문제점을 지적했다. 패치 관리 부재는 큰 손실 야기젠투 리눅스 창시자인 다니엘 로빈스 역시 젠투 리눅스 사이트에 올린 「Guru Medication Error-missing pathces」와 「Guru Medication Error Redux」라는 자신의 글에서 커널 개발 과정에 대해 문제를 제기했다(편집자 주: 자신의 글을 인용할 수 있도록 흔쾌히 허락해준 다니엘 로빈스에게 감사의 말을 전한다). 다니엘 로빈스는 애슬론/비아 82c686b 시스템에서 ATAPI ZIP 250 장치가 일으키는 문제를 해결한 패치(맨드레이크에서 2001년 11월 제작)가 꽤 긴 시간이 지났음에도 공식 커널에 적용되지 않은 사례를 소개했다.다니엘 로빈스는 이것이 배포판 제작사의 악의인지 커널 개발자들의 무성의인지 알 수는 없지만 실제 IT 산업 현장에서 리눅스를 잘 쓰기 위해 만들어지는 중요한 패치들을 공동체에서 제때 받아들이지 못하는 것은 큰 문제이며 이렇게 잃어버리는 패치들은 인력과 시간 손실을 야기하는 것은 물론이고 리눅스의 전체적인 질을 떨어뜨릴 것이라고 지적했다. 그리고 커널 개발자들은 실제 세계의 사용자 중심적인 커널 수정에 좀더 많은 관심을 기울이고 제때 받아들여야 한다고 제안했다.「성당과 시장」이란 문서를 통해 오픈소스 전도사로 알려진 에릭 레이몬드 역시 영국 유닉스 사용자 모임에서 행한 강연에서 커널 개발 과정에 약간의 문제가 있음을 시사했다. 실제로 에릭 레이몬드 역시 자신이 작성한 몇 가지 커널 패치를 커널에 포함시키기 위해 서른 세 번이나 보내야 했던 적이 있다고 한다. 에릭 레이몬드는 이 강연에서 사소한 패치뿐만 아니라 향후 커널 발전에 중요한 기능을 할 패치들까지 이유없이 외면당하고 있다고 말했다.적자생존과 자유방임의 한계이런 현상이 왜 발생하는 것일까? 잘 알려진 것처럼 지금까지는 커널에 여러 기능이 제안되거나 비슷한 기능이 충돌할 때 리누스 토발즈는 내버려둠으로써 적자생존하거나 각각의 진화를 통해 개성있게 발전할 수 있도록 유도했다. 정말 중요한 선택의 순간이 오면(에릭 레이몬드의 표현을 빌리자면), 리누스 토발즈는 타고난 감각을 발휘하기도 했다. 1970~80년대의 유닉스라는 문화유산의 세례를 받은 해커들이 자유롭게 사용할 수 있는 유닉스를 구현하기 위한 노력이 리눅스라는 결과물로 나타났던 1990년대에는 이 방식이 유효했다. 하지만 커널 개발을 이끌어온 이 같은 자유방임과 적자생존 방식이 훌쩍 커버린 커널을 유지보수 개발하기에 이제는 더 이상 맞지 않다는 지적이 있다. 패치를 모으는 문제는 리누스 토발즈와 커널 2.4 메인테이너인 Marcelo Tosatti가 비트키퍼라는 CVS와 비슷한 시스템을 도입함으로써 일단락되는 듯 했지만 앞서 예로 든 다니엘 로빈스가 지적한 문제가 앞으로 또 일어나지 않으리라는 보장은 없다. 다시 말하면 분명한 우선순위나 정책, 체계적인 버그 관리가 부족하다는 것이다. 새로운 도전에 직면한 리눅스리눅스가 대중화 양상을 보이기 시작하기 전에는 커널 개발은 분명 ‘그들’의 것이었는지도 모른다. 그러나 최근의 동향은 조금씩 달라지고 있다. 리눅스 비즈니스라 이름 붙은 것들의 침체에도 불구하고 기업 주도의 다양한 리눅스 개발이 진행되고 있다. OSDL(Open Source Developmet Lab)과 주요 통신 관련 기업이 주도하는 캐리어 그레이드 리눅스(Carrier Grade Linux)나 임베디드 리눅스 컨소시엄 등의 활동은 이전보다 리눅스에 거는 기대가 더 커졌고, 활용 분야 역시 점차 더 확대될 것을 전망하게 하는 현상으로 볼 수 있다. 즉, 1990년대가 리눅스에게 순수한 자유 공개 유닉스 구현의 시대였다면 2000년대는 새로운 도전이 시작된 것이다.이런 도전 앞에 최근 커널 개발 공동체가 보여주는 혼란은 썩 반가운 현상만은 아니다. 커널 2.4대에 이르러서 눈에 띄는 현상 중 하나는 독자적으로 커널을 관리하는 사람이 늘어났다는 것이다. 2.2대에도 알렌 콕스 패치 버전이나 각 아키텍처별 패치 버전이 알려져 있기는 했지만 2.4대에 이르면 새로운 VM을 채택한 Andrea Arcangeli 패치 버전, 선점형 커널 패치를 적용한 mjc 패치 버전 등이 나타난다. 물론 이러한 현상은 우려할 만한 것이 아니다. 실험적인 기능이나 아키텍처 의존적인 부분은 별도로 관리되고 충분한 안정화 단계를 거쳐 공식 커널에 도입되는 것이 바람직하다. 문제는 역시 당장 들어가야 할 것들이 들어가지 않고 중요한 것과 중요하지 않은 것의 구분이 모호해지고 커널 개발자들이 그에 대해 참고할 만한 가이드라인이 커널이 점점 커져가는 것에 비하면 부족하다는 것이다. 진화는 계속되어야 한다어쩌면 지금이 커널 개발 방식에 대해 진지하게 고려해야 할 시기인지도 모른다. 리누스 토발즈는 한 인터뷰에서 앞으로는 개발 버전에서 엄청난 변화나 실험은 하지 않을 것이라고 말했다. 최근 혼란에 대해 걱정하는 사람들은 그렇다면 커널 개발은 좀더 체계를 갖춰야 한다고 지적한다. 단순히 메일링 리스트에서 토론하고 비트키퍼에 변경사항기록(Changelog)만 올리는 것이 끝은 아니라는 것이다. 공동체에 새로 들어오는 개인 개발자나 리눅스 응용 개발이나 상용화에 관심이 많은 회사를 위해 합의된 정책도 있어야 할 것이고 특정 개발자에게 부담이 과도하게 집중되는 것도 고쳐져야 한다고 한다. 리눅스를 보는 눈이 많은 만큼 그 눈에서 얻을 수 있는 예리함이나 영감을 소리 없이 흘려보내지 않는 방법을 생각해내는 것이 중요하다는 것이다. @