[Linux Kernel] 리눅스 커널 개발 가이드: Early-stage planning

뭘 하든지 설계가 중요하다 이말이지 암암...

3. Early-stage planning — The Linux Kernel documentation

리눅스 커널 개발을 할때, 바로 코딩부터 시작하려는 욕심이 들 수도 있다. 하지만 대부분의 중요한 프로젝트가 그렇듯, 프로젝트가 성공하기 위한 토대는 코드를 짜기 전에 설계 단계에서 만들어진다. 초기 계획 (Early-stage planning)과 커뮤니케이션에 시간을 투자해야 시간을 절약할 수 있다.

3.1 Specifying the problem

여느 공학적인 프로젝트와 마찬가지로 커널을 개선하려면, 먼저 해결할 문제가 무엇인지 명확하게 정의하는 것이 중요하다. 물론 디바이스 드라이버를 개발하는 것처럼 해결할 문제가 명확한 경우에는 이 단계가 간단하지만, 그 외에는 처음 코딩을 시작하기 전에 해결할 문제를 명확하게 정하고 가야한다.

 

예를 들어서, 몇년 전에 오디오 관련 커널 개발자들은 지나친 지연시간 문제를 해결해야했다. 그 개발자들이 고안한 솔루션은, 리눅스 보안 모듈 (LSM, Linux Security Module) 프레임워크를 후킹하는 커널 모듈을 작성하는 것이었다. 이 모듈은 사용자 어플리케이션이 실시간 스케줄러에 접근할 수 있도록 설정할 수가 있었다. 이 모듈이  linux-kernel 메일링 리스트로 보내졌고, 바로 문제가 생겼다.

 

오디오 개발자들 관점에서는 그 모듈을 만들어서 문제를 해결할 수 있었지만, 커널 전반적으로 봤을 때는 LSM 프레임워크를 잘못된 용도로 사용한 것이었다. (사용자 어플리케이션이 가질 수 없는 권한을 주었기 때문에) 그리고 시스템의 안정성과도 타협을 한 것이다. 

 

하지만 오디오 개발자들은 자기들이 만든 모듈을 버리고싶지 않았고, 다른 해결책을 찾으려고 하지 않았다. 결과적으로 오디오 개발자들이 커널 개발 프로세스에 환멸을 갖게 되었다. 환멸을 오디오 개발자 한 명이 오디오 메일링 리스트로 가서 이렇게 썼다.

 

훌륭한 리눅스 커널 개발자들이 많이 있지만, 그 사람들은 거만한  바보들한테 크게 반발하는 경향이 있다. 거만한 바보들한테 사용자 요구사항을 논하는 것은 시간 낭비다. 그 사람들은 너무 "똑똑해서" 덜 똑똑한 사람들의 말을 듣고싶어하지 않는다. (https://lwn.net/Articles/131776/)

 

하지만 실제 상황은 달랐다. 그들이 아닌 다른 커널 개발자들은 시스템의 안정성과, 오랫동안 유지보수가 가능하도록 하는 것이 더 중요했고, 오디오 개발자들이 만든 모듈보다 더 나은 솔루션을 찾으려고 했다. 이 이야기의 교훈은 코드를 짜기 전에 커널 커뮤니티와 먼저 해결해야 할 문제 자체를 논의해야 한다는 것이다.

 

따라서, 커널 개발 프로젝트를 시작할 때는 다음의 질문에 대답해보자.

- 정확하게 해결할 문제가 무엇인가?

- 이 문제에 영향을 받는 사용자들은 누구인가? 그 사용자들의 어떤 use case를 다루어야 하는가?

- 현재 커널은 그 문제를 해결하기에 무엇이 부족한가?

이 질문들에 답한 후에 해결 방안을 찾는 것이 합리적이다.

 

3.2 Early discussion

커널 개발 프로젝트를 계획할 땐, 구현을 시작하기 전에 커널 커뮤니티와 소통하는 것이 좋다. 초기의 커뮤니케이션은 결과적으로 시간을 아낄 수 있고, 몇몇 문제를 예방할 수 있다:

 

- 이미 커널이 당신이 모르는 방법으로 문제를 해결했을 수도 있다. 리눅스 커널은 규모가 매우 크고, 이해하기 어렵고 문서화되지 않은 기능도 많다. 필자(Jonathan Corbet)는 이미 존재하는 드라이버를 누가 새로 짠 사례를 본 적이 있다. 이렇게 바퀴를 재발명하는 건 낭비일 뿐만 아니라 mainline 커널에도 받아들여지지 않는다.

 

- 누군가 고안한 솔루션이 위의 예시에서 오디오 개발자들이 만든 모듈처럼, mainline에 머지되기에 부적절할 수 있다. 따라서 이런 부분을 미리 논의해보는 것이 좋다.

 

- 이미 누가 그 문제에 대해서 고민해봤을 수 있다. 그 사람들은 더 좋은 솔루션에 대한 아이디어를 주고, 그 아이디어를 실현하는데도 도움을 줄 수 있다.

 

이런 고통스러운 문제들은 초기 단계의 커뮤니케이션에 투자하면 충분히 피할 수 있다.

 

3.3 Who do you talk to?

개발자들이 자신의 프로젝트에 대해 커뮤니티와 소통할 때 짚고 넘어갈 것이 있다. 논의를 어디에서 시작해야 하는가? 정답은 적절한 메일링 리스트와 적절한 메인테이너를 찾는 것이다. 메일링 리스트를 찾는 가장 좋은 방법은 MAINTAINERS 파일에서 메일링 리스트를 찾는 것이다. linux-kernel에서 시작하는 것보단 프로젝트와 관련된 서브시스템의 전문가들과 이야기하는 것이 더 좋다.

 

적절한 메인테이너를 찾는 건 메일링 리스트를 찾는 것보다 조금 더 어렵다. 우선, MAINTAINERS에서 다시 메인테이너를 찾아보자. 하지만 이 파일이 항상 최신으로 유지되지는 않기 때문에, 몇몇 메인테이너는 이 파일에 존재하지 않을 수도 있다. 사실 MAINTAINERS에 메인테이너라고 적혀있는 사람이 지금은 메인테이너의 역할을 하지 않을 수도 있다. 그래서 누구한테 메일을 보내야한다는 것인가? 누구한테 보낼지 고민이 될 때 좋은 방법은 git log로 현재 해당 서브시스템에서 누가 활동하고 있는지 살펴보는 것이다. 패치를 누가 썼는지, 그리고 누가 그 패치에 Signed-off-by 태그를 붙이는지 살펴보자. 이 사람들이 당신의 프로젝트를 도와줄 것이다.

 

적절한 메인테이너를 찾는 건 어려울 때가 많아서 이걸 대신 해주는 스크립트가 있다:

scripts/get_maintainer.pl

이 스크립트는 "-f" 옵션으로 실행하면 주어진 파일이나 디렉토리에 대해 현재 메인테이너가 누구인지 알려준다. 만약 주어진 인자가 패치라면, 그 패치를 누구한테 보내면 좋을지 알려준다. 얼마나 메인테이너를 찾는 게 어려우면 이 스크립트엔 다양한 옵션이 있다. 하지만 옵션을 너무 사용하다보면 관련이 없는 사람한테 메일을 보낼 수도 있으니 주의하자.

 

만약에 이렇게 메인테이너를 찾는 데 모든 노력을 다했는데도 찾지 못했다면, Andrew Morton에게 도움을 구해보자.

3.4 When to post?

가능하면 초기 단계에 메일링 리스트에서 논의를 시작하는 것이 도움이 된다. 해결할 문제가 무엇인지 설명하고, 본인이 생각해둔 계획을 이야기해보자. 당신의 프로젝트에 대해 자세하게 설명할 수록 커뮤니티가 도와줄 수 있는 게 많아진다.

 

논의를 시작했을 때 절망적인 것은, 다른 개발자들이 안 좋게 생각하는 게 아니라 반응 자체가 없는 것이다. 반응이 없는 이유는 (1) 커널 개발자들은 대부분 바쁘고 (2) 계획은 원대한데 코드가 없는 사람들도 많고 (3) 당신의 프로젝트에 대해 리뷰하거나 코멘트를 달아줄 의무가 있는 사람은 없기 때문이다.

 

그리고 그걸 떠나서, 추상적인 설계에서는 드러나지 않는 문제가 구현될 때 발견되는 경우가 많다. 이런 이유로 커널 개발자들은 코드를 보고 싶어하는 경향이 있다.

 

만약에 당신의 계획을 설명하는 RFC 메일이 반응이 없다고 아무도 관심이 없다는 의미로 생각하지는 말자. 그리고 불행하게도, 당신의 아이디어가 잘못되었을 가능성도 있다. 이런 상황에서 최선의 방법은 당신이 프로젝트를 진행하면서 어떻게 진행되는지를 커뮤니티에 공유하는 것이다.

3.5. Getting official buy-in

대부분의 커널 프로젝트처럼, 당신의 프로젝트가 회사 차원에서 진행될 경우 당신은 해당 프로젝트 관련 코드나 계획을 메일링 리스트에서 이야기하기 전에 회사에 먼저 허가를 받아야 한다. 특히 GPL 호환 라이선스가 아닌 코드를 게시하면 문제가 될 수 있다. 허가를 빨리 받을수록 좋다.

 

일부 독자들은 이 시점에서 공식적으로 발표되지 않은 프로젝트를 해야한다는 건가? 라고 생각할 수 있다. 이때 정말 개발 프로젝트를 비밀로 유지해야 하는지를 고민해보는 게 좋다. 종종 그렇게 비밀을 유지할 필요가 없는 경우도 많다.

 

하지만 개발 초기에 회사가 합법적으로 프로젝트를 공개할 수 없는 경우도 있다. 회사 내에 숙련된 커널 개발자가 있는 경우에는, 개발 중에 발생할 수 있는 문제를 해결할 역량이 된다는 가정 하에 오픈 루프 방식으로 개발을 진행할 수 있다. 하지만 회사 내에 그런 숙련된 개발자가 없는 경우에 좋은 방법은 외부에서 개발자를 고용하고 비밀 유지 계약을 하는 것이다. Linux Foundation은 이런 상황을 위해 NDA 프로그램을 운영한다. 더 자세한 건 아래 링크에서 찾아볼 수 있다:

 

https://www.linuxfoundation.org/nda/

 

이런 비공개 리뷰로도 비밀을 유지하면서 충분히 프로젝트에서 발생할 수 있는 문제를 피할 수 있다.