[Linux Kernel] 리눅스 커널 개발 가이드: Followthrough

끝날 때까지 끝난 게 아니다 - 패치도 그렇다. AS를 해야한다.

자, 이제 당신이 작업한 내용을 패치로 보내기까지 했다. 커널 개발자들이 (심지어 숙련된 개발자들도) 가장 많이 실수하는 것은 패치를 보냈다고 모든게 끝났다고 생각하는 것이다. 사실은, 패치를 보내는 것은 다음 단계를 밟는 것이고 아직 할일이 더 남았다.

 

패치를 처음 보내자마자 더 이상 개선할 점이 없고 바로 머지되는 경우는 매우 드물다. 커널 개발 프로세스는 이 사실을 잘 알고, 게시된 패치를 개선한다. 당신은 코드를 작성한 사람으로서 당신의 코드가 커널의 품질에 맞게 개선되도록 책임을 져야한다. 이 단계에서 실패하면 메인라인에 머지되지 않을 것이다.

 

6.1 Working with reviewers

의미가 있는 패치는 다른 개발자들이 코드를 리뷰하면서 코멘트를 남길 것이다. 리뷰어와 함께 일하는 것은 커널 개발 프로세스의 가장 두려운 부분이다. 하지만 몇 가지만 주의하면 괜찮다:

 

- 당신이 패치를 잘 설명했다면, 리뷰어는 패치의 가치와 왜 이 패치를 작성했는지 이해할 것이다. 하지만 가치가 있다고 해서 리뷰어들이 질문을 안 하는 것은 아니다. 5 - 10년 뒤에 당신의 코드를 유지보수하는 건 어떨까? 코딩 스타일 고치기부터 수많은 수정을 하기까지의 모든 과정은, 커널이 십년 뒤에도 개발할 것이라는 가정으로부터 시작된다.

 

- 코드 리뷰는 어려운 작업이다. 그리고 어려운 것에 비해 보상이 적기도 하다. 사람들은 코드를 작성한 사람은 기억하지만 리뷰를 한 사람은 잘 기억하지 않는다. 그래서 리뷰어들은 성격이 나쁘다. (특히 다른 사람들이 같은 실수를 계속해서 반복할때) 만약 화나거나, 모욕적이거나, 노골적으로 공격적인 리뷰를 받는다고 느낄 땐, 똑같이 갚아줘야겠다는 생각은 피하자. 코드 리뷰는 코드에 관한 것이지 당신의 인격을 모독하는 것이 아니다.

 

비슷하게, 리뷰어들은 자신의 고용주의 생각을 당신에게 강요하지 않는다. 커널 개발자들은 몇년 뒤에도 커널을 개발하고 있겠지만, 자신의 고용주가 바뀔 수 있다는 점을 이해하고 있다. 몇 가지 예외를 빼고는 최선을 다해, 고용주의 의견과 관계없이 최고의 커널을 만들려고 노력한다. 그들은 회사의 경쟁자라고 불편함을 주려고 하지 않는다. (대강 리뷰어들이 회사에 치우치지 않고 어느 정도는 독립적이라는 말인듯.)

 

결론적으로 여기서 말하고자 하는 것은, 리뷰어가 당신에게 코멘트를 남기면 그 코멘트를 기술적인 측면으로 이해해야 한다는 것이다. 그들이 표현하는 방법이나, 당신의 자존심에 귀를 기울이는게 아니라. 패치에 대한 코멘트를 리뷰할 때는 시간을 두고 리뷰어가 말하고자 하는 것을 이해하자. 가능하면, 리뷰어가 고쳐달라고 하는 것을 고치고 리뷰어에게 답변해주자. 우선 고마워하고, 그들이 물어보는 것을 어떻게 답변할지 설명해야 한다.

 

하지만 리뷰어가 제안하는 모든 것에 동의할 필요는 없다. 만약 리뷰어가 당신의 코드를 잘못 이해한다고 생각하면, 오해를 풀어주자. 만약 리뷰어가 제안한 것에 대해 기술적으로 반대한다면, 당신의 코드가 정당하다는 것을 설명하자. 만약 당신의 설명이 말이 된다면 리뷰어는 이를 인정할 것이다.

 

하지만 당신의 설명이 설득력이 없다면 (특히 다른 사람들이 리뷰어의 설명에 동의한다면) 당신의 생각이 맞는지 다시 한 번 생각해보자. 당신의 해결방법을 생각하느라 근본적으로 무엇이 잘못되었다는걸 깨닫지 못하거나, 또는 애초에 잘못된 문제를 해결하려고 했을 수도 있다.

 

Andrew Morton은 코드의 변경을 제안하지 않는 코멘트는 코드에 대한 추가적인 코멘트가 되어야한다고 제안한다. 그렇게 함으로써 나중에 다른 리뷰어들이 처음 제기된 질문을 피할 수 있다.

 

한 가지 큰 실수는 리뷰 코멘트를 무시하면 없어질 거라고 생각하는 것이다. 코멘트는 없어지지 않는다. 당신이 코멘트에 답변하지 않고 코드를 다시 보내면 코드는 받아들여지지 않을 것이다.

 

그리고 코드를 다시 보내는 것에 대해 이야기하자면, 당신이 마지막에 코드를 보냈을 때의 모든 디테일을 알지는 못할 수 있다는 걸 주의하자. 따라서 이전에 어떤 이슈가 있었고, 그걸 어떻게 해결했는지 리뷰어들에게 상기시켜주는 것이 필요하다. 패치의 changelog가 그런 내용을 설명하기에 좋다. 리뷰어들이 메일링 리스트를 검색하면서 마지막에 무슨 이야기를 했는지 기억해내는 것보다,  처음부터 당신이 상기시켜주면 더 좋을 것이다.

 

당신의 패치에 전혀 문제가 없는데 아무도 받아주지 않으면 어떻게 하나? 대부분의 기술적으로 동의하지 않는 상황은 토론을 통해 해결할 수 있다. 하지만 옳고 그름을 떠나서 누군가가 단순하게 결정을 해야하는 경우가 있다. 만약 당신이 다른 사람의 결정이 당신에게 불리하다고 믿는다면, 더 높은 권력자에게 호소할 수 있다. 지금 시점에서 더 높은 권력자는 아마도 Andrew Morton일 것이다. 그는 커널 개발 커뮤니티에서 매우 평판이 높다. 따라서 종종 절망적인 상황에서 그가 도와줄 수 있다. 하지만 Andrew Morton에게 호소하는 것을 가볍게 여겨서는 안되며, 다른 모든 대안이 불가능할 때만 그렇게 해야한다. 그리고 그도 당신의 주장에 동의하지 않을 수 있다.

 

6.2 What happens next

만약 패치가 커널에 추가되기에 좋은 것이라면 (그리고 리뷰에서 제기된 이슈가 해결되었다면) 다음 단계는 보통 패치가 서브시스템 메인테이너의 트리로 들어가는 것이다. 이 다음은 각각의 메인테이너마다 일하는 방식이 다르다. 특히 한 서브시스템에서 하나 이상의 트리가 존재할 수도 있다. (아마도 하나는 다음 머지 윈도우를 위한 것이고, 하나는 장기간 작업을 위한 것일 수도 있다.)

 

어느 트리에 적용해야할지 모르겠는 패치는 (예를 들어 메모리 관리) 보통 (Andrew Morton이 관리하는) -mm 트리로 들어간다.  여러 서브시스템에 영향을 주는 패치도 -mm 패치로 들어갈 수 있다.

 

패치가 서브시스템 트리에 추가되면 해당 트리에서 작업하는 사람들이 당신의 패치를 접하기가 더 쉬워진다.  각 서브시스템은 일반적으로 linux-next에 패치를 보내므로, 커널 개발 커뮤니티 사람들 모두가 보게될 것이다. 그렇게 되면 더 많은 리뷰어들의 코멘트를 받을 수 있다. 이전 단계에서 리뷰어들의 코멘트에 답변했듯 여기에도 답변을 해야한다.

 

또 이 단계에서는 패치에 따라 다른 사람의 작업과 충돌할 수도 있다. (API를 수정했는데 그 API를 새로 사용하는 사람이 있다던지) 충돌이 심각한 최악의 경우에는 충돌이 난 패치는 다음으로 미루고 충돌이 없는 패치만 우선 머지될 수도 있다. 종종 충돌이 일어날 때 다른 개발자와 소통하면서 해결해야할 수도 있고, 아마 여러 트리 사이에서 패치를 주고 받으면서 제대로 적용이 되는지 확인해야 할 수도 있다. 이렇게 충돌을 해결하는 작업은 매우 고통스럽다. 하지만 너무 절망하지 말자. linux-next가 존재하기 전에는 이런 충돌이 머지 윈도우때 발견되었고, 머지 윈도우 기간동안 서둘러서 해결을 해야했다. 하지만 지금은 머지 윈도우 이전에 linux-next를 통해서 여유로울 때 미리 해결할 수 있다.

 

여기까지 모든 일이 잘 풀리면 당신이 이메일에 접속했을 때 패치가 메인라인에 머지된 것을 볼 수 있을 것이다. 축하한다! 축하를 하고 나면 (그리고 당신이 MAINTAINERS 파일에 추가되면), 한 가지 중요한 사실을 기억해야 한다: 당신이 할 일은 아직 끝나지 않았다. 메인라인으로 머지되는 것 이후에도 할 일이 있다.

 

이제 linux-next에 패치가 있을 때보다 더 많은 사람들이 당신의 패치를 볼 것이고, 더 많은 사람들이 코멘트를 남길 것이다. 이 사람들의 말을 무시하고 싶을 수 있겠지만... 그러지 말자. 머지된 이후에도 사람들이 궁금증이 있거나 제안을 할 때 잘 답변해주자.

 

그리고 더 중요한 건 메인라인에 당신의 코드가 포함되면 더 많은 사람들이 테스트를 하게 된다. 만약 당신이 존재하지 않던 드라이버를 새로 개발해서 메인라인에 포함되었다면, 수많은 사람들이 당신의 코드를 빌드한다는 것에 당신은 놀라게 될 것이다. 그리고 당연히 테스터가 있으면, 버그 리포트도 있기 마련이다.

 

최악의 버그는 regression이다. 당신의 패치가 regression을 일으킨다면 불편할 정도로 많은 사람들이 당신에게 시선을 집중할 것이다. 당신이 이런 regression을 해결하지 않는다면 코드가 안정화 기간(아마 머지 윈도우 이후 -rc1, -rc2, ..., -stable이 나오기 전까지를 말하는듯 하다.)동안 제거될 확률이 높다. 그리고 당신이 지금껏 한 일이 부정당하는 것 뿐만 아니라 이후에 당신이 작업한 것이 머지되기가 더 힘들어진다.

 

그리고 regression 말고도 다른 일반적인 버그도 많이 발생한다. 안정화 기간동안 최대한 버그를 고쳐서 코드가 최대한 견고한 상태로 릴리즈될 수 있게 준비해야 한다. 따라서 버그 리포트에 잘 답변하고, 가능하면 모두 해결하자. 그러라고 안정화 기간이 존재하는 것이다. 기존에 발생한 문제를 모두 해결해야 새로운 작업도 시작할 수가 있다.

 

그리고 개발 사이클이 끝나도 버그 리포트가 생길 수 있음을 염두하자. 다음 개발 사이클이나, 배포판들이 당신의 패치가 포함된 커널을 선택하는 등의 경우에 말이다. 지속적으로 이런 버그 리포트에 답변하는 것은 당신의 일에 대한 기본적인 자부심의 문제이다. 만약 이렇게 지속적으로 답변하는 것이 동기부여가 되지 않는다면 ㅡ 개발 커뮤니티는 머지된 이후에 관심을 버리는 사람을 기억하게될 것임을 생각해보자. 당신이 다음에 다른 패치를 보냈을 때 사람들은 당신이 머지된 후에 패치를 관리하지 않을거라고 생각할 것이다. (결국 책임 + 평판의 문제!)

6.3 Other things that can happen

누군가 당신에게 당신의 코드에 대한 패치를 보낼 수도 있다. (이건 코드를 공개하는 장점이기도 하다.) 당신이 그 패치에 동의한다면 서브시스템 메인테이너에게 보내면 된다. (다만 패치를 보낸 사람을 From:으로 명시하는 것과 당신의 Signed-off-by: 서명을 포함하는 것을 잊지 말자.) 아니면 메인테이너한테 바로 보내는게 아니라 Acked-by: 태그로 해당 패치에 답장을 하면 메인테이너가 그 패치를 가져갈 것이다.

 

당신이 패치에 동의하지 않는다면 그 이유를 정중하게 설명하자. 그리고 가능하다면 당신이 그 패치를 승락하려면 무엇을 바꿔야 할지도 알려주자. 코드의 메인테이너와 반대되는 코드를 머지하는 것에 저항이 좀 있긴 하지만, 불가능한 것은 아니다. 만약 누군가의 좋은 코드를 불필요하게 거부된다면, 그래도 좋은 코드이기 때문에 메인라인에 어떻게든 들어가게 될 것이다. 리눅스 커널에서는 그 누구도, 어떤 코드에 대해서도 절대적으로 거부할 수 없다. (다만 Linus는 예외이다. 그가 거부하면 메인라인에 포함되지 않을 가능성이 매우 크다.)

 

아주 가끔은 다른 개발자가 당신이 해결하는 문제에 대한 다른 솔루션을 제시할 수도 있다. 그럼 같은 문제에 대해서 두 개의 솔루션이 존재하는데, 둘 중 하나는 머지되지 않을 확률이 크다. "내가 먼저 했어"는 기술적으로 설득력이 없다. 만약 다른 개발자의 패치가 당신 대신 메인라인으로 들어간다면 대응할 방법은 사실상 하나밖에 없다: 문제가 해결되었다는 사실에 기뻐하고 다른 일을 하자. 이런식으로 밀려나는 것은 상처도 받고 낙담할 수도 있지만, 다른 사람들은 누구의 패치가 머지되었는지는 잃어버린 채 당신이 그때 어떻게 반응했는지를 기억할 것이다. (쿨하게 넘어가야 한다!)